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 LEZIONE 1 – LA MODELLAZIONE DEI DATI E LE ENTITÀ ........................................................4 3.2 LEZIONE 2 – LA CARDINALITÀ DELLE ASSOCIAZIONI............................................................7 3.3 LEZIONE 3 – ATTRIBUTI E CHIAVI PRIMARIE.........................................................................9 3.4 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 Individuo Introduciamo ora un’altra nozione: quella di associazione.

�������������������� ��������� � �����

� �������������� � � � ������� �������������������������

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 Possiede Carta d’indentità 1 1 Persona Possiede Automobile 1 N Scuola Assume Insegnante N M 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 redige ordine contiene articolo 1 N M M 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 redige testata ordine 1 N 1 comprende N riga ordine contiene articolo N 1 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 Possiede Carta d’indentità 1 1

�������������������� ��������� � �����

� �������������� � � � ������� �������������������������

10

Persona Possiede Automobile 1 N Scuola Assume Insegnante N M 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. 1 N M 1 Dipendente Possiede Incarico E’ svolto in 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, “trucchi” e prime nozioni sulla normalizzazione

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.