INTRODUZIONE ALLA TEORIA DEI DATABASE
Autore: ing. Mauro Pullin
2
INDICE
1
INTRODUZIONE .......................................................................................................................3
2
SCHEMA DEL PERCORSO ...................................................................................................3
3
SVILUPPO DELLE LEZIONI ..................................................................................................4
3.1
3.2
3.3
3.4
LEZIONE 1 – LA MODELLAZIONE DEI DATI E LE ENTITÀ ........................................................4
LEZIONE 2 – LA CARDINALITÀ DELLE ASSOCIAZIONI............................................................7
LEZIONE 3 – ATTRIBUTI E CHIAVI PRIMARIE.........................................................................9
LEZIONE 4 – REGOLE DI DERIVAZIONE E CENNI SULLA NECESSITÀ DELLA
NORMALIZZAZIONE..........................................................................................................................12
3.5
LEZIONE 5 – CONSIGLI, “TRUCCHI” E PRIME NOZIONI SULLA NORMALIZZAZIONE .............18
3
1 INTRODUZIONE
La teoria dei database è un argomento molto vasto e la sua importanza è notevolissima,
pertanto il ciclo di lezioni descritto nella presente dispensa riguarda esclusivamente
l’introduzione alla tematica.
La trattazione di seguito descritta si inserirà quindi in un percorso più ampio che prevede
gli argomenti referenziati nella mappa concettuale di seguito rappresentata.
Nella figura seguente, sono evidenziati con il colore giallo gli argomenti a cui ci si riferisce
maggiormente nella presente dispensa.
2 SCHEMA DEL PERCORSO
Per sviluppare il tema dell’introduzione alla teoria dei database, si è pensato di proporre gli
argomenti di seguito elencati.
•
•
Lezione 1 – La modellazione dei dati e le entità
Lezione 2 – La cardinalità delle associazioni
4
•
•
•
Lezione 3 – Attributi e chiavi primarie
Lezione 4 – Regole di derivazione e cenni sulla necessità della normalizzazione
Lezione 5 – Consigli, “trucchi” e prime nozioni sulla normalizzazione
3 SVILUPPO DELLE LEZIONI
3.1 Lezione 1 – La modellazione dei dati e le entità
Fin dall’antichità l’uomo ha sempre avuto bisogno di memorizzare ed elaborare
informazioni. Che fossero parole o numeri poco importava, quello che serviva era uno
strumento per far sì che queste informazioni non fossero affidate solo alla memoria
umana, ma continuassero ad esistere e ad essere disponibili a tutti.
Prima dell’avvento dei computer l’unico supporto su cui era possibile memorizzare i dati
era la carta (fogli, libri, ecc.) con tutte le limitazioni che essa comportava.
Con l’introduzione dei computer le cose migliorarono decisamente, in quanto si
cominciarono a studiare metodi e sistemi di gestione delle informazioni tali da ottimizzarne
la ricerca e l’elaborazione. Si sentì quindi il bisogno di organizzare il contenuto dei file in
maniera organica; perché ciò fosse possibile furono realizzati dei programmi che
generavano database, vale a dire dei file in cui i dati erano memorizzati secondo precisi
criteri di omogeneità e sequenzialità. Sulla base di tali criteri i suddetti programmi furono
poi in grado di ricercare ed elaborare i dati con notevole velocità.
In informatica, un’attività molto importante consiste nella modellazione dei dati.
Modellare i dati significa costruire una rappresentazione semplificata della realtà osservata
o di un problema riguardante – in genere – un’azienda, un ente pubblico o uno studio
professionale, individuandone gli elementi caratterizzanti ed i legami intercorrenti tra essi.
Riflettiamo su un fatto molto importante: in tutte le scienze applicate si è soliti procedere
per modelli. Pensiamo, ad esempio, a come lavora un studio di architettura: si fa un
modello su carta dell’edificio che si vuole costruire e questo modello è composto da vari
disegni. Altro esempio: una casa automobilistica realizza il progetto della nuova
automobile che intende mettere in produzione e anche questo progetto consiste in realtà
in un modello, che viene esplicitato tramite un insieme di disegni.
La progettazione di un modello di dati avviene a livelli diversi.
•
•
•
C’è, innanzi tutto, il livello concettuale, che rappresenta la realtà dei dati e le
relazioni intercorrenti tra essi; lo si visualizza per mezzo di uno schema.
Si passa poi al livello logico, che rappresenta il modo attraverso il quale i dati sono
organizzati negli archivi elettronici: esso descrive, quindi, la composizione ed il
formato dei dati nel loro aspetto di struttura logica di dati. Il livello logico viene
derivato dal livello concettuale applicando alcune semplici regole di trasformazione.
Alla fine si giunge al livello fisico, che rappresenta l’effettiva installazione degli
archivi elettronici: esso indica l’ubicazione dei dati nelle memorie di massa (dischi).
5
Il livello fisico è quindi l’implementazione del livello logico sui supporti per la
registrazione fisica dei dati: partizioni, puntatori, blocchi fisici, cluster, indici.
L’attività di progettazione consente, prima di tutto, di costruire una rappresentazione
astratta della realtà in modo indipendente dalla struttura dei dati.
Fin dagli inizi l’informatica si occupò della memorizzazione elettronica di informazioni, ma
non esistevano metodologie di progettazione degli archivi di dati e questo portava ad
innumerevoli svantaggi e problemi. Un’analisi dettagliata di questi problemi portò il
matematico Peter P. Chen – del Massachusetts Institute of Technology – a formulare, nel
1976, il modello Entità/Associazioni, in inglese Entity/Relationship. Si tratta di uno
strumento per analizzare le caratteristiche di una qualsiasi realtà in modo indipendente
dagli eventi che in essa accadono, cioè per costruire un modello concettuale dei dati
indipendente dalle applicazioni, quindi indipendente dai programmi che con esso
interagiranno.
Il modello Entità/Associazioni si avvale di una rappresentazione grafica, detta schema
E/R, che mette in evidenza gli aspetti fondamentali del modello concettuale, consentendo
di porre in evidenza gli aspetti fondamentali del modello concettuale, con i dati
caratterizzanti e le associazioni tra essi. Tra l’altro, gli schemi E/R risultano di facile
comprensione anche per le persone che non sono specialisti di informatica e questo è
importantissimo nei contesti aziendali. Va inoltre sottolineato che il modello E/R è
sostenuto da alcuni concetti e regole che lo rendono preciso e rigoroso.
Gli elementi di un modello Entità/Associazioni sono: le entità, le associazioni e gli attributi.
Definizione. “L’entity set o insieme di entità (che è tradotto semplicemente – e un po’
impropriamente – con la parola entità), è un oggetto concreto o astratto, rilevante per il
sistema informativo, che ha un significato anche quando viene considerato in modo isolato
ed è di interesse per la realtà che si vuole modellare. Graficamente un entity set viene
rappresentato con un rettangolo, contenente il nome all’interno”.
Le entità possono essere classificate secondo un certo criterio di omogeneità, definendo il
tipo di entità attraverso un nome.
Per esempio, gli studenti di una scuola sono classificabili nel tipo entità Studente, i diversi
modelli di automobile sono classificabili nel tipo entità Automobile. Sottolineiamo alla
classe che, nel ragionamento fatto, ciascuno studente rappresenta un’istanza dell’entità
studente.
A titolo di esempio, consideriamo le tre entità seguenti:
Studente
Automobile
Introduciamo ora un’altra nozione: quella di associazione.
Individuo
6
Definizione. “L’associazione (in inglese relationship) è un legame che stabilisce
un’interazione tra le entità”.
L’associazione è identificata, in genere, mediante un verbo transitivo (oppure una perifrasi
o locuzione equivalente). In alcuni libri di testo il verbo è scritto all’interno di un rombo,
posto tra le due entità collegate; in altri, invece, il verbo viene riportato sopra oppure a
fianco di un segmento che connette le due entità collegate.
Persona
Possiede
Automobile
Analizziamo un esempio di schema E/R molto “classico”.
Esempio di schema E/R
Lo schema E/R che si vuole analizzare si riferisce ad un problema importantissimo e
‘classico’: l’emissione degli ordini di acquisto dei clienti nei confronti di un’azienda.
cliente
redige
ordine
contiene
articolo
Osserviamo che ciascun ordine comprende una testata ed una o più righe; in ogni riga è
referenziato un articolo, il cui codice è presente in una opportuna tabella degli articoli.
Schematizziamo ora quanto analizzato.
cliente
redige
testata ordine
comprende
riga ordine
contiene
articolo
7
3.2 Lezione 2 – La cardinalità delle associazioni
Cerchiamo ora di comprendere quali differenze ci sono tra le tre situazioni di seguito
rappresentate.
Persona
Possiede
Carta d’indentità
Persona
Possiede
Automobile
Scuola
Assume
Insegnante
Osserviamo che:
•
•
•
nel primo caso, ad una istanza dell’entità Persona corrisponde un’istanza dell’entità
Carta d’identità e viceversa;
nel secondo caso, ad una istanza dell’entità Persona possono corrispondere una o
più istanze dell’entità Automobile, ma ad una istanza dell’entità Automobile
corrisponde una sola istanza dell’entità Persona;
nel terzo caso, ad una istanza dell’entità Scuola corrispondono più istanze
dell’entità Insegnante e ad una istanza dell’entità Insegnante possono
corrispondere più istanze dell’entità Scuola (ad esempio, all’istanza “I.T.I.S. Severi”
dell’entità Scuola corrispondono circa oltre istanze dell’entità Insegnante, ad alcune
istanze dell’entità Insegnante possono corrispondere anche tre istanze dell’entità
Scuola.
E’ ora possibile proporre la definizione seguente.
“La molteplicità di un’associazione è il numero di possibili istanze di un’entità che viene
messo in corrispondenza con un’istanza dell’altra entità che partecipa all’associazione.
Il numero minimo e massimo di possibili istanze vengono rappresentati simbolicamente
mediante una coppia di valori separati dai due punti: 1:1, 1:N, N:M. Esistono quindi un
valore minimo (che in genere è 1) ed un valore massimo (che è 1, N oppure M). Il valore
massimo definisce la cardinalità della partecipazione all’associazione. Esso assume, in
genere, uno dei due valori 1 oppure N (M), per indicare una o molte partecipazioni
all’associazione.
La cardinalità può quindi essere ‘a uno’ oppure ‘a molti’ e pertanto le associazioni tra due
entità si classificano nei tipi seguenti:
8
•
•
•
associazione ‘uno a uno’ o biunivoca, indicata con 1:1 (è il caso del legame tra
l’entità Persona e l’entità Carta d’identità);
associazione ‘uno a molti’, indicata con 1:N (è il caso del legame tra l’entità
Persona e l’entità Carta d’identità);
associazione ‘molti a molti’, indicata con N:M (è il caso del legame tra l’entità
Scuola e l’entità Insegnante).
C’è anche la possibillità che un’associazione sia opzionale. Per comprendere questo
concetto analizziamo, ad esempio, il legame esistente tra l’entità Persona e l’entità
Patente di Guida. Una patente di guida APPARTIENE ad una persona, ma una persona
PUO’ POSSEDERE una patente di guida (non è detto che ce l’abbia, la mia bisnonna – ad
esempio – non l’ha mai conseguita!). Il legame è obbligatorio dal lato Persona, ma è
opzionale dal lato Patente di Guida. Vediamo, di seguito, come si può rappresentare tale
fatto.
Persona
Possiede
Patente di Guida
Consideriamo nuovamente le tre situazioni precedentemente analizzate. Scriviamo in ogni
schema le cardinalità delle associazioni.
Persona
Persona
Scuola
1
1
N
Possiede
Possiede
Assume
1
N
M
Carta d’indentità
Automobile
Insegnante
Continuiamo con l’analisi dello schema E/R relativo al problema dell’emissione degli ordini
di acquisto che i clienti formulano nei confronti di un’azienda.
Le cardinalità delle varie associazioni presenti in esso sono date dallo schema di seguito
raffigurato:
9
cliente
1
redige
N
ordine
M
contiene
M
articolo
Infatti, ogni cliente può redigere più ordini, ma un ordine può essere redatto da un solo
cliente; ogni ordine può contenere più articoli, ed ogni articolo può essere contenuto in più
ordini.
Vediamo, di seguito, cosa accade alle cardinalità se l’ordine viene scomposto in testata e
righe.
cliente
1
redige
N
testata ordine
1
comprende
N
riga ordine
N
contiene
1
articolo
Con queste prime due lezioni sono stati introdotti i concetti più importanti del modello
relazionale.
Nel corso della terza lezione saranno trattati i concetti di attributo e chiave primaria.
3.3 Lezione 3 – Attributi e chiavi primarie
Riprendiamo quindi l’analisi di tre situazioni già viste la lezione precedente, delle quali
vengono riproposti, di seguito, gli schemi già presentati.
Persona
1
Possiede
1
Carta d’indentità
10
Persona
Scuola
1
N
Possiede
Assume
N
M
Automobile
Insegnante
Si può osservare che mancano del tutto le proprietà delle entità e delle associazioni.
E’ possibile, a questo punti, introdurre la definizione di attributo.
Definizione. “Si definiscono attributi le proprietà delle entità e delle associazioni”.
Le caratteristiche di ogni attributo sono il formato (testo, numero intero, numero a virgola
mobile, data/ora, ecc.), la dimensione (50, 100, ecc.) e l’opzionalità (cioè se si tratta di un
dato obbligatorio oppure no).
Gli attributi saranno rappresentati con dei pallini, collegati alla rispettiva entità mediante un
arco o un segmento di retta.
Vediamo ora qualche esempio di attributi di entità.
Tipo di scuola
Denominazione
Indirizzo
Scuola
Cognome
Nome
Materia insegnata
Insegnante
Si può osservare che le caratteristiche dell’attributo ‘Tipo scuola’ devono prevedere che
esso dovrà poter contenere dei testi (cioè stringhe di caratteri alfanumerici), con lunghezza
opportuna (10 caratteri sono senz’altro troppo pochi; anche 20 caratteri sono troppo pochi;
30 caratteri forse bastano).
11
L’attributo ‘Denominazione’, invece, dovrà poter contenere dei testi (cioè stringhe di
caratteri alfanumerici), con lunghezza opportuna: 100 caratteri dobrebbero bastare.
Per esercizio, il lettore potrà individuare le caratteristiche degli altri attributi.
Per quanto riguarda la necessità del concetto di “chiave primaria”, si può osservare che è
necessario caratterizzare in modo univoco le singole istanze di un’entità, individuando uno
o più attributi i cui valori consentano di reperire una ed una sola istanza di un’entità;
informalmente, per “chiave primaria” si intende un sottoinsieme dei suoi attributi che
identifica univocamente ogni istanza dell’entità stessa. In pratica, fissato il valore alla
chiave primaria deve essere individuata, al massimo, una sola istanza dell’entità.
Il motivo per cui è necessario individuare una chiave primaria può essere giustificato
osservando la realtà.
Consideriamo, ad esempio, gli articoli venduti in un supermercato: per motivi di praticità,
deve essere possibile distinguere in modo esatto e senza ambiguità un qualsiasi tipo di
articolo da tutti gli altri, quindi ad essi sono applicati i codici a barre; dato un codice a
barre, esiste uno ed un solo tipo di articolo che lo possiede.
Il problema dell’identificazione, però, non ce l’hanno solo i supermercati: guardando il retro
di un qualsiasi libro di testo, si può osservare che anche in questo caso è stampato il
codice a barre. Anche lo Stato usa questo tipo di tecnica. Pensiamo, ad esempio, l’entità
CONTRIBUENTE: il codice fiscale identifica in modo certo e preciso il singolo contribuente
in quanto, dato un certo codice fiscale, esiste uno ed un solo contribuente che lo possiede.
Dopo questi ragionamenti, si può proporre la definizione di chiave primaria.
Definizione. “Si indica con il termine chiave o chiave primaria (primary key) un insieme
minimale di attributi che permettono di distinguere tra loro le istanze di una stessa entità”.
Gli attributi si possono rappresentare con dei pallini vuoti, che recano a fianco il nome,
collegati all’entità con segmenti di linea curva o segmenti di retta. La chiave primaria può
invece essere rappresentata con pallini anneriti.
Codice fiscale
Cognome
Nome
Contribuente
Codice articolo
Denominazione
Prezzo
Articolo
12
Le relazioni (relation set) dello schema concettuale vengono rappresentate nello schema
logico facendo uso delle cosiddette ‘chiavi esterne’. Una chiave esterna (foreign key) di
una tabella è un insieme di attributi che corrispondono a quelli che costituiscono la chiave
primaria di un’altra tabella, e stabiliscono quindi un riferimento tra le righe delle due
tabelle.
Ad esempio, nell’associazione esistente tra ‘testata ordine’ e ‘riga ordine’
precedentemente analizzata e studiata, ogni istanza dell’entità ‘riga ordine’ sarà associata
alla corrispondente istanza dell’entità ‘testata ordine’, perché in essa sono presenti gli
attributi che corrispondono alla chiave primaria di ‘testata ordine’. Supponiamo che la
chiave primaria di ‘testata ordine’ sia composta dagli attributi ANNO e NUMERO ORDINE;
anche ‘riga ordine’ avrà questi attributi, che però non corrisponderanno alla chiave
primaria di ‘riga ordine’; per ogni istanza di quest’ultima entità questi due attributi
conterranno dei valori che saranno uguali ai valori che questi attributi hanno nell’istanza
corrispondente di ‘testata ordine’”.
3.4 Lezione 4 – Regole di derivazione e cenni sulla necessità della
normalizzazione
Lo scopo di questa lezione è comprendere quali sono le regole e le modalità con cui si può
effettuare il passaggio dal modello concettuale al modello logico dei dati e fornire alcuni
esempi di database. Per ottenere questo risultato, analizzeremo – in particolare – il
contenuto di alcune tabelle di esempio.
Dal modello concettuale dei dati, studiato nel corso delle lezione precedente, è possibile
ottenere il cosiddetto modello logico dei dati, che ora andremo ad analizzare.
Esso consente di definire la struttura degli archivi adatti a contenere e ad organizzare i
dati. Nel modello logico le entità corrispondono a tabelle. Le tabelle si possono
rappresentare per mezzo di matrici in cui ogni colonna, detta anche campo, corrisponde
ad un attributo dell’entità ‘di partenza e ogni riga, detta anche record, corrisponde ad
un’istanza della suddetta entità.
Passiamo ora ad analizzare alcuni esempi.
Consideriamo un’azienda: essa avrà – ovviamente – dei clienti e dei fornitori. Una tabella
dei clienti, ad esempio, può contenere i seguenti campi che descrivono le caratteristiche di
ciascun cliente: codice cliente; nome; cognome; indirizzo; città; CAP.
Vediamo ora una possibile tabella dei clienti.
13
Ci si può chidere se qualcosa potrebbe essere migliorato nella tabella proiettata (per
essere maggiormente precisi: ci sono dati in più?).
Nota per il lettore esperto.
E’ chiara, a questo punto, l’intenzione di far scoprire al lettore non esperto la necessità di normalizzare i dati;
infatti le colonne denominate “città” e “CAP” possono contenere dati potenzialmente ripetuti. In questa
lezione non verranno date le definizioni rigorose riguardanti la normalizzazione, ma è importante che il
lettore non esperto inizi a porsi il problema.
Cercando di ottimizzare le modalità di accesso ai database, ci si accorse ben presto che i
database, se li strutturiamo in modo ‘naturale’, contengono talvolta molti dati inutilmente
ripetuti. Dovendo archiviare gli ordini dei clienti, ad esempio, sarebbe necessario ripetere
per ogni ordine i dati anagrafici dei clienti che hanno effettuato più di un ordine, come si
può osservare vedere nella situazione che viene esposta di seguito.
Se, in aggiunta, si desiderano memorizzare le fatture emesse dall’azienda, ecco che i dati
anagrafici dei clienti debbono essere di nuovo ripetuti, con un evidente spreco di tempo
degli operatori e di spazio sui dischi dei computer, ma soprattutto creando possibili
anomalie a seguito di operazioni di aggiornamento e ciò a causa della ridondanza.
14
Pensiamo, ad esempio, al fatto che il nome ‘Mario’ ed il cognome ‘Rossi’ devono essere
inseriti più volte. Può accadere ad un terminalista distratto di inserire per errore, qualche
volta (magari a causa della fretta), il cognome o il nome in modo errato: ‘Marrio’, ‘Rosi’,
ecc.; è chiaro che questo errore non sarebbe possibile se, anziché dover inserire ogni
volta il nome ed il cognome per intero, fosse sufficiente scrivere il codice del cliente.
Per ovviare a questo inconveniente, si cercò il modo di progettare delle strutture o
database in grado di archiviare i dati in ‘contenitori’ differenti, in base alla loro natura: nel
modello concettuale sono le entità, che nel modello logico divengono le tabelle; tali entità o
tabelle dovranno essere poste in relazione tra loro, secondo le necessità.
Nacquero così i cosiddetti RDBMS, acronimo che significa ‘Relational Data Base
Management System’ (Sistemi per la Gestione di Database Relazionali)”.
Analizziamo ora, di seguito, un’altra situazione importante.
Nella figura precedente, si può osservare una cosa importante.
Nelle varie tabelle ciascun record è contraddistinto da un campo contenente un
identificatore univoco (un dato che compare una volta soltanto nell’intera tabella); questo
identificatore viene utilizzato nelle altre tabelle, invece di ripetere per intero il record che lo
contiene.
15
Se ad esempio, ogni cliente contenuto nella tabella anagrafica dei clienti viene identificato
da un numero progressivo, detto ID Cliente (ID sta per IDentificatore), nella tabella degli
ordini e in quella delle fatture emesse sarà sufficiente inserire questo numero invece di
ripetere ogni volta tutti i dati anagrafici del cliente.
Si può ora procedere al seguente:
Ripasso del modello relazionale
Il modello relazionale presuppone il riconoscimento dei tipi di legame, cioè la natura delle
associazioni, che collegano le diverse entità del fenomeno che si intende rappresentare.
Costruire un database relazionale significa quindi:
•
•
•
•
•
individuare i dati elementari;
identificare le entità (che diverranno le tabelle);
individuare, per ogni entità, la chiave;
scoprirne le relazioni;
creare un modello della realtà che faccia riferimento alle entità individuate ed alle loro
relazioni.
16
Il modello relazionale garantisce espandibilità e flessibilità nella costruzione del modello e
delle applicazioni che ne derivano; esso elimina la necessità di duplicare i dati; pensiamo,
a titolo di esempio, al caso degli ordini (cliente, testata d’ordine, riga d’ordine, articolo):
cerchiamo di analizzare e comprendere cosa accadrebbe se l’ordine non fosse scisso in
testata e riga/righe e se l’articolo non fosse “codificato” per mezzo dell’entitò articolo, ad
esso corrispondente..
Ripasso dei concetti di entità e tabella
Le informazioni relative ad una entità vengono memorizzate in una struttura chiamata
tabella. La tabella è organizzata in righe (dette anche “record”) e colonne (dette anche
“campi”).
Ogni campo identifica una proprietà dell’entità ed assume in ogni record un valore
specifico appartenente al relativo dominio e soddisfacente eventuali vincoli di integrità;
ogni riga identifica un elemento dell’insieme delle entità. In ogni riga viene registrata
l’informazione relativa a una specifica entità.
Ripasso della nozione di associazione
Per costruire un modello relazionale bisogna poter associare, se due tabelle (entità) sono
in relazione, ogni record di una tabella con il record corrispondente della tabella collegata.
Ripasso delle associazioni “uno a uno”
Ad ogni record di una tabella principale è associato al più un record della tabella
relazionata. Per richiamarci ad un esempio analizzato, pensiamo al legame esistente tra
l’entità ‘Persona’ e l’entità ‘Carta di Identità’.
Ripasso delle associazioni “uno a molti”
Ad ogni record di una tabella possono essere associati nessuno o molti record di una
tabella collegata, ma ad ogni record di questa è associato sempre un’unico record di
quella d’origine.
In ogni record della tabella relazionata si deve inserire il riferimento al record
corrispondente della tabella principale
17
Ripasso/approfondimento delle associazioni “molti a molti”
Ogni record di una tabella può essere associato a molti record della tabella collegata, e
viceversa. Nelle relazioni molti a molti bisogna creare una tabella intermedia, legata con
una relazione “uno a molti” con entrambe le tabelle originarie.
Vediamo, ad esempio, il legame esistente tra l’entità Dipendente e l’entità Filiale di
un’azienda, che – considerato nella sua evoluzione temporale – è di tipo “molti a molti”,
perché una persona, nel corso degli anni, può aver lavorato in filiali diverse e quindi può
avere ricoperto diversi incarichi:
Si giungerà alla situazione di seguito rappresentata.
Dipendente
1
Possiede
N
Incarico
M
E’ svolto in
1
Filiale
Le relazioni (relation set) dello schema concettuale vengono rappresentate nello schema
logico facendo uso delle cosiddette ‘chiavi esterne’. Una chiave esterna (foreign key) di
una tabella è un insieme di attributi che corrispondono a quelli che costituiscono la chiave
primaria di un’altra tabella, e stabiliscono quindi un riferimento tra le righe delle due
tabelle.
18
3.5 Lezione 5 – Consigli,
normalizzazione
“trucchi”
e
prime
nozioni
sulla
Regole per una buona modellazione dei dati
Per eseguire una buona modellazione dei dati, è consigliabile seguire le regole di seguito
elencate.
1. Leggere più volte e attentamente il testo prima di decidere il modello dei dati.
2. L’ambito del problema non è un’entità (per esempio in un problema come il
seguente: “In un Istituto scolastico si vogliono gestire con un database le
informazioni sui docenti e gli studenti…” l’istituto non è un’entità)
3. Alcune regole che valgono (quasi) sempre: i sostantivi corrispondono alle entità, gli
aggettivi e le proprietà corrispondono agli attributi, i verbi alle associazioni.
4. Leggere attentamente anche le richieste di output e il testo delle interrogazioni, per
determinare correttamente e in modo completo gli attributi delle entità.
5. Gli attributi descrittivi che si ripeteranno con valori uguali per istanze diverse della
stessa entità, per esigenze di normalizzazione, devono diventare entità (per
esempio, Comuni, causali, tipologie, ecc.) legate da un’associazione 1:N con l’entità
che devono descrivere. Esse saranno poi derivate in tabelle di decodifica (codice,
descrizione).
6. Motivare, se necessario, le scelte fatte, spiegandone le ragioni ed evidenziando
ipotesi aggiuntive e vincoli introdotti.
7. Nella scelta del tipo di associazioni, la cardinalità 1:1 è molto rara, talvolta (ma non
sempre) si risolve con una sola entità con gli attributi opportuni; la cardinalità 1:N è
la più frequente; la cardinalità N:M può esserci, oppure si può spezzare già nella
fase di modellazione in due associazioni 1:N; in questo caso le due entità di
partenza vanno vicino a 1 e l’entità “di legame” va vicino a N. In caso contrario, dal
modello E/R con associazione N:N, la regola di derivazione crea tre tabelle: la terza
tabella contiene la chiave della prima entità, la chiave della seconda e gli eventuali
attributi dell’associazione.
8. Le entità di tipo “dinamico” (o movimenti) hanno sicuramente una data di
registrazione; inoltre possono essere opportunamente caratterizzate da una chiave
autoincrementale (ID di tipo contatore), numerico progressivo (numero di
registrazione).
Note sulle descrizioni dei dati
1. I campi che non vengono usati in calcoli sono di tipo testo (stringa); per esempio,
telefono, partita IVA, CAP, pur essendo composti da cifre sono di tipo testo.
2. Per facilitare la comprensione a se stessi e al docente, si possono esplicitare alcuni
dati di esempio per ciascuna delle tabelle.
19
Primi cenni sulla normalizzazione
Come accennato due lezioni fa, se la definizione dello schema della base di dati non è
fatto ad hoc, può succedere che si abbiano delle anomalie nel database, quali, per
esempio, la ripetizione delle informazioni con spreco di tempo (per l’inserimento dei dati) e
di spazio (memoria) ed il rischio di errori/inconsistenza. La teoria della normalizzazione ha
come scopo quello di fornire metodi per progettare basi di dati senza anomalie. In pratica
la normalizzazione consente di verificare se la definizione dello schema corrisponde a dei
“canoni standard” di correttezza della base di dati. Dopo aver definito lo schema, si
devono seguire alcune regole per rendere le tabelle in quelle che sono chiamate le forme
normali, cioè per fare in modo che lo schema corrisponda a dei “canoni standard”.
La teoria della normalizzazione è un argomento ampio, complesso e la sua trattazione
esula dagli scopi della presente dispensa introduttiva.
