Tutorials

  • Presto on-line...

About ...

  • ... questo sito
  • ... me


Introduzione ai Database

database
Giusto qualche parola per famigliarizzare con i concetti di base spingendoci fino alle relazioni molti a molti!

Un Database è semplicemente una collezione di dati.
Nel mondo cartaceo esistono tantissimi esempi di comunissimi database, basti pensare ad un dizionario o al classico elenco telefonico. La cosa più importante da notare è che entrambi gli esempi fatti hanno una particolarità in comune: le singole voci che compongono la collezione sono organizzate in qualche modo per facilitarne la ricerca. Possiamo quindi raffinare la definizione di Database indicando che è una collezione organizzata di dati.

Il passaggio dal mondo cartaceo al mondo elettronico ha fatto nascere una nuova categoria di programmi, chiamati DBMS (Database Management System), per la gestione dei dati (il nostro Database).

Cos’è un Database Relazionale

Raffinando ulteriormente la definizione di Database si arriva a quella di Database Relazionale: una collezione di dati organizzata in tabelle.
Sembra una specifica di poco conto ma in realtà da qui si è sviluppata tutta una scienza di Database Design.

Un piccolo esempio

Per evitare di trattare questa introduzione in maniera troppo accademica proviamo a ragionare su un esempio e a introdurre alcuni importanti concetti man mano che li incontriamo nel discorso…
Supponiamo di voler gestire una rubrica telefonica dei nostri conoscenti dove per ogni persona vogliamo catalogare il nome, l’indirizzo ed il telefono.
Costruiamo una tabella adatta ai nostri scopi. Ogni tabella ha un nome ed è composta da alcune colonne, una per
ogni singola proprietà dei nostri dati. Nell’esempio, ogni persona corrisponde ad una riga (detta anche tupla
o record o entity), le cui colonne (attributi) contengono i singoli dati caratteristici di ogni elemento (entity) che vogliamo archiviare.

Schematizzando:

Nome tabella: RUBRICA
Attributi: NOME, INDIRIZZO, TELEFONO

RUBRICA:

NOME         INDIRIZZO                TELEFONO
Paolo        Via Lanzo 12 (TO)        011 123456
Luca         Corso Roma 1 (TO)        011 999888
Sara         Via dei Mille 17 (MI)    02 767676
Lucia        Via Fiori 214 (MI)       02 9877896

Questa tabella contiene 4 entity.
A questo punto potrebbe essere interessante raggruppare le persone in base ad una classificazione che esprima il genere di rapporto esistente con una data persona tipo: AMICI, LAVORO, FAMIGLIA… introduciamo quindi il concetto di relazione.

Primary Key

A questo scopo occorre imporre un nuovo attributo alle nostre entity: The Unique Identifier o l’identificatore unico.... spesso chiamato ID.

Ecco come si presenta la nostra tabella modificata:

Nome tabella: RUBRICA
Attributi: ID, NOME, INDIRIZZO, TELEFONO

RUBRICA:

ID      NOME         INDIRIZZO                TELEFONO
1       Paolo        Via Lanzo 12 (TO)        011 123456
2       Luca         Corso Roma 1 (TO)        011 999888
3       Sara         Via dei Mille 17 (MI)    02 767676
4       Lucia        Via Fiori 214 (MI)       02 9877896

Questo identificatore (ID), chiamato anche chiave primaria o Primary Key, è caratterizzato da 3 importanti proprietà:


  • 1 - E’ unico tra tutte le entity: non possono esistere due righe aventi lo stesso valore nella colonna ID.

  • 2 - Non può essere nullo (NULL): è obbligatoria la presenza di un valore ben definito.

  • 3 - Il suo valore non può cambiare per tutta la vita di una entity: se per esempio può cambiare l’indirizzo di una persona o il suo numero di telefono, non può cambiare il suo identificatore.

Tornando alla classificazione che vogliamo implementare, possiamo immaginare di utilizzare una seconda tabella di questo tipo:
Nome tabella: GRUPPO
Attributi: ID, DESCRIZIONE

GRUPPO:

ID      DESCRIZIONE
1       Amico
2       Collega
3       Parente

Possiamo facilmente immaginare (nel caso più semplice) che ogni persona rientri in esattamente una categoria e che per ogni categoria si abbia un insieme di persone.

Foreign Key

Più formalmente si può dire che una persona è in relazione uno a uno con un gruppo e che un gruppo è in relazione uno a molti con le persone.
Per esempio: se Paolo è un amico, Luca è un Parente, Sara è un Collega e Lucia è un Amico (relazioni 1:1) allora Amico è in relazione con Paolo e Lucia (relazione 1:M).
Per esplicitare queste relazioni si fa uso delle chiavi esterne o Foreign Key (FK).
Ecco come si potrebbe modificare la prima tabella aggiungendo una Foreign Key (GRUPPO_ID):

Nome tabella: RUBRICA
Attributi: ID, NOME, INDIRIZZO, TELEFONO, GRUPPO_ID

RUBRICA:

ID  NOME    INDIRIZZO                TELEFONO       GRUPPO_ID
1   Paolo   Via Lanzo 12 (TO)        011 123456     1
2   Luca    Corso Roma 1 (TO)        011 999888     3
3   Sara    Via dei Mille 17 (MI)    02 767676      2
4   Lucia   Via Fiori 214 (MI)       02 9877896     1

In questo modo esplicitiamo il fatto che Paolo è in relazione con l’entity avente ID=1 della tabella GRUPPO.
Un ultimo passo verso le relazioni molti a molti:
Generalizzando un minimo il nostro esempio, possiamo notare che Luca, oltre ad essere un Parente, potrebbe essere anche un collega.
In questo caso, la relazione persona -> gruppo diventa del tipo molti a molti (un insieme di più persone può appartenere a più di un gruppo) mentre quella inversa gruppo -> persona rimane sempre del tipo uno a molti.
Per esplicitare questa logica dovremmo modificare la nostra tabella RUBRICA
in questo modo:
RUBRICA:

ID  NOME     INDIRIZZO                TELEFONO       GRUPPO_ID
1   Paolo    Via Lanzo 12 (TO)        011 123456     1
2   Luca     Corso Roma 1 (TO)        011 999888     3,2
3   Sara     Via dei Mille 17 (MI)    02 767676      2
4   Lucia    Via Fiori 214 (MI)       02 9877896     1

Ma questo non è possibile! La colonna GRUPPO_ID può contenere
un solo valore e non una lista di valori! (vedi la entity di ID = 2)
Occorre quindi intervenire in maniera più drastica sulla definizione
delle tabelle per trasformare la relazione molti a molti (M:M) in due relazioni uno
a molti
(1:M).
Questa trasformazione viene effettuata modificando la tabella RUBRICA
(semplificandola) e mediante la creazione di una terza tabella di servizio
appositamente creata.
La tabella RUBRICA viene semplificata eliminando la colonna GRUPPO_ID
e diventa:
RUBRICA:

ID      NOME         INDIRIZZO                TELEFONO
1       Paolo        Via Lanzo 12 (TO)        011 123456
2       Luca         Corso Roma 1 (TO)        011 999888
3       Sara         Via dei Mille 17 (MI)    02 767676
4       Lucia        Via Fiori 214 (MI)       02 9877896

Mentre la nuova tabella (che chiamiamo TAB_RELAZIONI) è semplicemente composta da due sole colonne e precisamente da una colonna per la chiave primaria di RUBRICA e una colonna per la chiave primaria di GRUPPO:
Nome tabella: TAB_RELAZIONI
Attributi: RUBRICA_ID, GRUPPO_ID

TAB_GRUPPI:

RUBRICA_ID      GRUPPO_ID
1               1
2               3
2               2
3               2
4               1

Come si legge questa tabella?
La prima riga dice che l’entity di ID = 1 della tabella RUBRICA è in relazione con la entity di ID = 1 della tabella GRUPPO (cioè: Paolo è un amico).
Più interessante la seconda e la terza riga che indicano che l’entity di ID = 2 della tabella RUBRICA è in relazione sia con entity di ID = 3 della tabella GRUPPO che con la entity di ID = 2 della tabella GRUPPO (cioè Luca è sia un parente che un collega).
Ecco che la relazione molti a molti presente tra RUBRICA e GRUPPO viene implementata tramite due relazioni: una relazione uno a molti tra RUBRICA e TAB_GRUPPI e una seconda relazione uno a molti tra TAB_GRUPPI e GRUPPO.

Per approfondimenti:

Qui mi fermo! Se siete interessati ad approfondire l’argomento, non vi resta che scegliere un buon libro o un buon sito…

Posted on Sep 23, 2003 - 04:47 AM


Ricerca:


Adv:

ApplePro :
Vuoi acquistare un prodotto dalla Apple? Sei un utente Pro (cioè hai la partita IVA)? Se vuoi supportare il nostro sito, passa da qui: apple pro.