Il modello relazionale, proposto dal matematico britannico Edgar F. Codd nel 1970, si basa sul concetto matematico di relazione.
È un modello teorico fondato sulla teoria degli insiemi e sulla logica del primo ordine, ed è corredato da una propria algebra, detta algebra relazionale, costituita da un insieme di operatori che consentono di interrogare e manipolare i dati. La maggior parte dei DBMS relazionali si basano sul modello relazionale.
1 Definizione di Relazione
Dal punto di vista matematico una relazione deriva dal prodotto cartesiano di più insiemi.
Si definisce prodotto cartesiano di due insiemi A e B, indicato con A×B, l'insieme di tutte le coppie ordinate (a, b), dove a appartiene ad A e b appartiene a B.
Una relazione binaria tra due insiemi A e B (detti domini della relazione) un qualsiasi sottoinsieme del loro prodotto cartesiano: R ⊆ A × B.
Esempio:
A = {7, 8}, B = {16, 49, 64}; A×B = { (7,16), (7,49), (7,64), (8,16), (8,49), (8,64) }
R = { (7,49), (8,64) } è una relazione su A e B che si può indicare con il nome RadiceQuadrataDi
Le definizioni di prodotto cartesiano tra due insiemi e di relazione binaria si estendono al caso di n insiemi.
Data una famiglia di domini D₁, D₂, ..., Dₙ, una relazione è un sottoinsieme del loro prodotto cartesiano:
R ⊆ D₁ × D₂ × ... × Dₙ
Il grado (o arità) di una relazione è il numero dei domini che la compongono.
La cardinalità di una relazione è il numero di tuple contenute nella relazione.
2 Relazione ed Attributi
La relazione LIBRI è un sottoinsieme del prodotto cartesiano dei domini associati ai suoi attributi:
ISBN × Titolo × Autore × CasaEditrice × Prezzo × Anno
dove ciascun dominio rappresenta l'insieme dei valori ammessi per il relativo attributo.
Nota: nel modello relazionale un dominio non coincide con il tipo di dato di un linguaggio di programmazione, ma rappresenta un insieme di valori ammissibili. Ad esempio, il dominio CAP non è semplicemente una stringa o un numero, ma l'insieme di tutti i codici di avviamento postale validi.
| 88-298-2245-0 | Informatica generale | Rossi P. | Minerva | 15,90 | 2003 |
| 88-296-2254-0 | Elettronica digitale | Bianchi S. | Atlas | 19,50 | 2000 |
| 88-111-3153-0 | Linguaggio SQL | Gallo P. Salerno F. | Petrini | 15,00 | 2002 |
Una relazione è un insieme e, come tale, possiede le seguenti proprietà:
- Le tuple della relazione non sono ordinate
- Le tuple della relazione sono distinte l’una dall’altra
(Nota: nel modello relazionale teorico una relazione non può contenere tuple duplicate. Alcuni DBMS consentono tuttavia risultati temporanei contenenti duplicati (ad esempio una query SQL senza la clausola DISTINCT), ma tali risultati non rappresentano, dal punto di vista teorico, una relazione. - Ogni valore contenuto in una tupla è associato a uno specifico attributo della relazione. Nel modello relazionale gli attributi sono identificati dal loro nome e non dalla loro posizione. Nei DBMS, invece, le colonne vengono visualizzate secondo un determinato ordine, scelto per ragioni pratiche.
Nota: nella letteratura più datata sulle basi di dati è frequente trovare il termine n-upla (o n-pla) per indicare una riga di una relazione. Nella terminologia moderna si usa quasi esclusivamente il termine tupla, che verrà adottato anche nel seguito di queste note.
Attributi, Schema, Tuple
- Nel modello relazionale a ogni dominio è associato un nome, detto attributo, che identifica il significato dei valori appartenenti a quel dominio.
- Il nome della relazione seguito dall'elenco dei suoi attributi costituisce lo schema della relazione. Ad esempio:
LIBRI(ISBN,Titolo,Autore,CasaEditrice,Prezzo,Anno)rappresenta lo schema della relazione. L'insieme delle tuple presenti in un determinato momento costituisce invece l'istanza della relazione. - Ogni riga della relazione prende il nome di tupla.
- Per riferirsi in modo univoco a un attributo si utilizza la cosiddetta dot notation: NomeRelazione.NomeAttributo. Ad esempio:
Libri.Titoloindica l'attributo Titolo della relazione LIBRI. - Poiché gli attributi sono identificati dal loro nome, nel modello relazionale l'ordine con cui vengono elencati non ha significato logico. La posizione delle colonne è invece una caratteristica della rappresentazione tabellare adottata dai DBMS
3 Relazione e Tabelle
Nel modello relazionale una relazione viene normalmente rappresentata mediante una tabella. È importante distinguere i due concetti: la relazione è un oggetto logico del modello relazionale, mentre la tabella è la sua rappresentazione grafica utilizzata dai DBMS.
Lo schema della relazione descrive la sua struttura, cioè il nome della relazione e i suoi attributi. L'istanza della relazione è invece costituita dall'insieme delle tuple presenti in un determinato momento.
Nella rappresentazione tabellare:
- ogni attributo corrisponde a una colonna;
- ogni tupla corrisponde a una riga.
Di conseguenza:
- il grado della relazione coincide con il numero delle colonne;
- la cardinalità della relazione coincide con il numero delle righe.
| ISBN | TITOLO | AUTORE | EDITORE | PREZZO | ANNO |
|---|---|---|---|---|---|
| 88-298-2245-0 | Informatica generale | Rossi P. | Minerva | 15,90 | 2003 |
| 88-296-2254-0 | Elettronica digitale | Bianchi S. | Atlas | 19,50 | 2000 |
| 88-111-3153-0 | Linguaggio SQL | Gallo P. Salerno F. | Petrini | 15,00 | 2002 |
La relazione Libri, ha grado 6 e cardinalita' 3
Nel modello relazionale teorico una relazione non può contenere tuple duplicate. Nella pratica, nei DBMS relazionali, per identificare in modo univoco ciascuna tupla, si definisce normalmente una chiave primaria (Primary Key o PK). La chiave primaria è costituita da uno o più attributi il cui valore identifica univocamente ogni tupla della relazione.
4 Dal diagramma E-R allo schema relazionale
Questo paragrafo illustra le regole di trasformazione di uno schema concettuale Entita-Associazione (E/R) in uno schema logico relazionale. Nel diagramma E-R sono presenti entità, attributi e associazioni. Applicando le regole di derivazione è possibile ottenere le relazioni che costituiranno lo schema relazionale della base di dati.
4.1 Rappresentazione delle entità e degli attributi
In generale, ogni entità del modello E-R viene tradotta in una relazione dello schema relazionale. Ad esempio, in un database ferroviario si possono ottenere le relazioni: TRENI, ORARI, TRATTE, ecc.
Ogni attributo dell'entità diventa un attributo della relazione e viene rappresentato da una colonna della tabella. L'identificatore dell'entità diventa normalmente la chiave primaria della relazione.
Gli attributi composti vengono sostituiti dagli attributi che li costituiscono. Ad esempio, l'attributo composto Indirizzo può essere scomposto nei seguenti attributi: Via e NumeroCivico, CAP, Città.
Un attributo multivalore non può essere rappresentato direttamente nel modello relazionale.
In questo caso si introduce una nuova relazione collegata all'entità originaria mediante una relazione uno-a-molti.
Ad esempio, consideriamo l'entita' PERSONA, se una persona può avere più hobby, si ottengono le relazioni: PERSONA(IdPersona, Nome,...) e HOBBY(IdPersona, Hobby). In questo modo ogni hobby viene rappresentato da una tupla distinta.
Un altro esempio è rappresentato dalla relazione tra LIBRO e AUTORE. Poiché un libro può avere più autori e un autore può aver scritto più libri, l'associazione è di tipo molti-a-molti (N:N) e deve essere rappresentata mediante una relazione di collegamento. Non è quindi opportuno utilizzare un unico attributo Autori contenente l'elenco degli autori del libro. Supponiamo, ad esempio, di voler cercare tutti i libri scritti da un determinato autore. Quando un'informazione deve essere frequentemente ricercata, ordinata o utilizzata come criterio di selezione, è opportuno rappresentarla mediante attributi semplici oppure mediante relazioni dedicate, evitando di incorporarla in attributi composti o multivalore. Se gli autori fossero memorizzati all'interno di un unico attributo Autori, le ricerche risulterebbero più complesse, poiché sarebbe necessario fare una ricerca per una parte dell'attributo autori.
4.2 Rappresentazione delle associazioni binarie 1:1
Una relazione uno-a-uno può essere tradotta in diversi modi.
Normalmente si sceglie una delle seguenti soluzioni:
- accorpare le due entità;
- mantenere entrambe le relazioni introducendo una chiave esterna;
- fondere le due relazioni quando rappresentano la stessa entità logica.
La scelta dipende dalla cardinalità minima dell'associazione e dai requisiti dell'applicazione.
Ad esempio, PERSONA(CodiceFiscale,Nome,...) e CARTA_IDENTITA(Numero,DataRilascio,CodiceFiscale), il campo CodiceFiscale della relazione CARTA_IDENTITA è una chiave esterna che fa riferimento alla relazione PERSONA e, poiché l'associazione è uno-a-uno, il suo valore deve essere univoco. (Il vincolo UNIQUE su CodiceFiscale è ciò che garantisce che una persona non possa essere associata a due carte di identità contemporaneamente).
Un altro esempio è rappresentato dalle entità PERSONA e PATENTE, anch'esse normalmente collegate da un'associazione uno-a-uno.
4.3 Rappresentazione delle associazioni binarie 1:N
Si consideri l'associazione 1:N Persona:Auto: una persona può possedere più automobili, mentre ogni automobile appartiene a una sola persona.
/\
_____________ / \ _____________
| | / \ | |
| PERSONA |_________ POSSIEDE _________| AUTO |
|_____________| (0,N) \ / (1,1) |_____________|
\ /
\/
Nella traduzione di un'associazione uno-a-molti (1:N), la chiave primaria della relazione posta sul lato "uno" viene inserita come chiave esterna (Foreign Key o FK) nella relazione posta sul lato "molti". In questo modo si realizza un vincolo di integrità referenziale tra le due relazioni.
Ad esempio nell’associazione 1:N Persone:Automobili si ha:
Persone(CodFiscale (PK), Nome, Cognome, Via, Cap, Citta) Automobili(NumeroTelaio (PK), Marca, Modello,..., CodFiscale (FK))
La chiave primaria identifica in modo univoco ogni tupla della relazione PERSONE e, di conseguenza, ogni suo valore compare una sola volta. La chiave esterna, invece, può comparire in più tuple della relazione AUTOMOBILI. Se una persona possiede cinque automobili, il suo CodiceFiscale comparirà come chiave esterna in tutte e cinque le tuple corrispondenti.
La relazione tra SQUADRA e GIOCATORE puo' essere modellata come un'associazione 1:N, poiché durante una stagione sportiva un giocatore appartiene normalmente a una sola squadra. Dopo l'introduzione della sessione di trasferimento invernale dei giocatore, il database deve essere riprogettato perche deve conservare anche la cronologia dei trasferimenti, la relazione diventa naturalmente di tipo molti-a-molti (N:N), poiché nel corso di una stagione un giocatore può appartenere a più squadre e una squadra può avere numerosi giocatori.
Le associazioni possono essere obbligatorie oppure facoltative. Consideriamo l'associazione Giocatore–Penalità. Un giocatore può non aver ricevuto alcuna penalità oppure averne ricevute una o più. Ogni penalità, invece, è necessariamente associata a un solo giocatore. L'associazione è quindi: facoltativa dal punto di vista del giocatore; obbligatoria dal punto di vista della penalità.
/ \
___________ / \ ___________
| | / \ | |
| Giocatore |________ Assegnazione ________| Penalita' |
|___________| (0,N) \ / (1,1) |___________|
\ /
\ /
Consideriamo ora l'associazione facoltativa 1:N PROFESSORE–CASSETTO. Un professore può possedere uno o più cassetti, mentre un cassetto può anche non essere assegnato ad alcun professore.
/ \
____________ / \ ___________
| | / \ | |
| PROFESSORE |__________ POSSIEDE ___________| CASSETTO |
|____________| (1,N) \ / (0,1) |___________|
\ /
\ /
In questo caso la chiave esterna presente nella relazione CASSETTO può assumere il valore NULL.
Ciò non significa che venga eliminato il vincolo di integrità referenziale: il vincolo continua a esistere, ma viene verificato solo quando la chiave esterna assume un valore diverso da NULL. La possibilità che una chiave esterna assuma valore NULL dipende esclusivamente dalle regole del dominio applicativo e non rappresenta una scelta di progettazione arbitraria, cioe' non posso trasformare una relazione opzionale in obbligatoria.
4.4 Rappresentazione delle associazioni binarie molti-a-molti (N:N)
Due entità A e B collegate da un'associazione di tipo molti-a-molti (N:N) vengono tradotte nel modello relazionale mediante tre relazioni:
- una relazione che rappresenta l'entità A;
- una relazione che rappresenta l'entità B;
- una terza relazione, detta relazione di collegamento (o relazione associativa), che rappresenta l'associazione tra A e B.
La relazione di collegamento contiene almeno:
- la chiave primaria della relazione A, che diventa una chiave esterna;
- la chiave primaria della relazione B, che diventa una chiave esterna;
- gli eventuali attributi propri dell'associazione.
Le due chiavi esterne realizzano i vincoli di integrità referenziale verso le rispettive relazioni (nel senso che tutti i valori della chiave esterna DEVONO essere presenti anche nella chiave primaria delle relazioni A e B)
Nella maggior parte dei casi, la chiave primaria della relazione di collegamento è costituita dalla combinazione delle due chiavi esterne, anche se in alcuni casi può essere introdotta una chiave artificiale (surrogata).
Esempio: associazione Articolo:Fornitore.
Un esempio classico è rappresentato dall'associazione N:M tra ARTICOLO e FORNITORE. Per esempio, un fornitore può fornire molti articoli ad un supermercato e uno stesso articolo può essere fornito da più fornitori.
Si ottengono quindi le seguenti relazioni:
ARTICOLI(CodArticolo (PK), Descrizione, Prezzo) FORNITORI(CodFornitore (PK), Nome, Via, Citta, Cap, PartitaIVA) FORNITURE(CodArticolo (FK), CodFornitore (FK), DataFornitura, Quantità, PrezzoUnitario)
La relazione FORNITURE contiene gli attributi propri dell'associazione, cioè le informazioni che hanno significato solo quando un determinato fornitore fornisce un determinato articolo. (L'attributo composto indirizzo e' sostituito da via+numero, citta' e Cap).
Un’associazione di tipo N:M viene quindi scomposta in due associazioni di tipo 1:N. Nella pratica, una tupla della relazione di collegamento rappresenta l'esistenza stessa dell'associazione tra due entità. Per questo motivo entrambe le chiavi esterne sono normalmente obbligatorie e non assumono valore NULL. La partecipazione facoltativa di una delle due entità è rappresentata semplicemente dall'assenza della relativa tupla nella relazione di collegamento.
Esempio: associazione molti-a-molti PROPRIETARIO e IMMOBILE
Un proprietario può possedere più immobili e uno stesso immobile può appartenere a più proprietari. Si ottengono quindi tre relazioni: IMMOBILI, PROPRIETARI, PROPRIETARI_IMMOBILI. L'attributo quotaPossesso appartiene all'associazione e non alle singole entità, poiché descrive la percentuale di proprietà di uno specifico proprietario relativamente a uno specifico immobile.
La relazione IMMOBILI gia' possiede una sua chiave naturale che e' la codifica catastale (foglio, numero e subalterno) ma, poiche' il Catasto non ce la fa ad assegnare sempre in tempo queste informazioni, il progettista di basi di dati usa un identificatore numerico progressivo (chiave surrogata) IdImmobile anziché una chiave naturale complessa, semplificando così la gestione delle relazioni.
IMMOBILI(IdImmobile, vani, metriQuadri, prezzo, via, citta, CAP) PROPRIETARI(CodiceFiscale, cognome, nome, ... ) PROPRIETARI_IMMOBILI(IdImmobile, CodiceFiscale, quotaPossesso)
La relazione PROPRIETARI_IMMOBILI contiene gli attributi IdImmobile, CodiceFiscale e QuotaPossesso. Gli attributi IdImmobile e CodiceFiscale sono chiavi esterne verso le relazioni IMMOBILI e PROPRIETARI e, nella soluzione più comune, costituiscono insieme la chiave primaria della relazione.
Se, ad esempio, marito e moglie possiedono in comproprietà lo stesso immobile, nella tabella PROPRIETARI_IMMOBILI saranno presenti due tuple con lo stesso IdImmobile ma con un diverso CodiceFiscale. L'attributo QuotaPossesso consentirà di rappresentare la quota di proprietà di ciascun proprietario (ad esempio 50% e 50%).
È buona norma adottare una convenzione uniforme per i nomi delle tabelle e delle colonne (ad esempio utilizzare sempre nomi minuscoli oppure sempre maiuscoli). In questo modo il codice risulta più leggibile e si evitano problemi di portabilità tra sistemi operativi e configurazioni diverse di MySQL.
Oggi, nelle linee guida di molti progetti (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle), la convenzione più diffusa è:
- nomi delle tabelle in minuscolo (
libri,autori,forniture); - parole separate da underscore (
libri_autori,ordini_clienti); - nomi delle colonne anch'essi in minuscolo (
id_libro,titolo,anno_pubblicazione).
Questa convenzione evita molti problemi quando si passa da un DBMS ad un altro.
4.5 Generalizzazione e specializzazione
La generalizzazione rappresenta una relazione di ereditarietà tra un'entità più generale (detta padre o supertipo) e una o più entità più specifiche (dette figlie o sottotipi). Le entità figlie ereditano gli attributi e le associazioni dell'entità padre e possono possedere attributi propri.
Ad esempio, in una concessionaria automobilistica si può modellare l'entità AUTOMOBILE come entità padre e le entità AUTO_NUOVA e AUTO_USATA come entità figlie. L'entità AUTOMOBILE contiene gli attributi comuni, come Marca, Modello e Cilindrata. L'entità AUTO_NUOVA può avere attributi specifici, come AnniGaranzia, mentre AUTO_USATA può avere attributi quali ChilometriPercorsi, AnnoImmatricolazione e NumeroProprietari.
Come si traduce una relazione di generalizzazione:
Una entità padre P ed n entità figlie F1, F2, ..., Fn possono essere relazionate in tre modi diversi, a seconda delle circostanze e cioè come:
- accorpamento delle figlie nel padre;
- accorpamento del padre nelle figlie;
- sostituzione della generalizzazione con associazioni di tipo 1:1;
4.5.1 Accorpamento delle entità figlie nell'entità padre
In questa soluzione le entità figlie vengono eliminate e i loro attributi vengono aggiunti all'entità padre. Per distinguere le diverse specializzazioni si introduce un attributo discriminante, ad esempio TipoAuto.
Ad esempio:
AUTOMOBILI( CodAuto, Marca,Modello, TipoAuto, AnniGaranzia, KmPercorsi, AnnoImmatricolazione, CodProprietario)
L'attributo TipoAuto consente di distinguere se una tupla rappresenta un'auto nuova oppure un'auto usata.
Questa soluzione è particolarmente conveniente quando le entità figlie condividono la maggior parte degli attributi e vengono interrogate frequentemente nel loro insieme. Lo svantaggio principale è la presenza di numerosi valori NULL negli attributi che appartengono solo ad alcune specializzazioni.
Ad esempio, supponiamo che stiamo creando un database per la gestione degli abbonamenti in uno stabilimento balneare, che offre lo stagionale, il mensile, il quindicinale, il settimanale e un giorno. Le entita' figlie sostanzialmente hanno tutti gli attributi in comune, non si distinguono tra loro in modo significativo, per cui si accorpano le figlie nel padre. Nel padre inserisco un attributo che chiamo TipoAbbonamento e si definisce una codifica: se vale 1 significa stagionale, se vale 2 significa mensile, 3 quindicinale, ecc. Quindi, modellizando la base di dati, si hanno le entita' Cliente, Abbonamento, e l'associazione N:N Cliente:Abbonamento. L'abbonamento contiene l'attributo multiplo attivita', che descrive tutte le attivita' svolte dal cliente. L'associazione Cliente:Abbonamento ha gli attributi data inizio e data fine.
4.5.2 Accorpamento dell'entità padre nelle entità figlie
Quando le entità figlie presentano caratteristiche molto diverse tra loro, può risultare conveniente eliminare l'entità padre e trasferire i suoi attributi in ciascuna entità figlia. (Non conviene accorpare le figlie nel padre, perche' nella tabella si avrebbero delle tuple con parecchi valori NULL) In questo caso ogni entità figlia viene trasformata in una relazione distinta contenente sia gli attributi ereditati dall'entità padre sia quelli specifici della specializzazione.
Questa soluzione è applicabile solo quando la generalizzazione è totale, cioè quando ogni istanza dell'entità padre appartiene necessariamente a una delle entità figlie.
Ad esempio:
AutoNuove( CodAuto, Marca, Modello, AnniGaranzia, ..., CodProp) AutoUsate( CodAuto, Marca, Modello, KmPercorsi, AnnoImmatricolazione, ..., CodProp)
Questa soluzione è particolarmente adatta quando le operazioni della base di dati riguardano quasi sempre una singola specializzazione. Questa soluzione rispetto alla precedente riduce la presenza di valori NULL
4.5.3 Mantenimento dell'entità padre e delle entità figlie
In questa soluzione vengono mantenute sia l'entità padre sia le entità figlie. L'entità padre genera una relazione contenente gli attributi comuni a tutte le specializzazioni, mentre ogni entità figlia genera una relazione contenente soltanto gli attributi specifici.
La chiave primaria della relazione padre viene utilizzata anche come chiave primaria delle relazioni figlie e, contemporaneamente, costituisce una chiave esterna verso la relazione padre.
Ad esempio:
AUTO(CodAuto, Marca, Modello, CodProp) AUTO_NUOVE(CodAuto, AnniGaranzia) AUTO_USATE(CodAuto, KmPercorsi, AnnoImmatricolazione)
Le relazioni AUTO_NUOVE e AUTO_USATE rappresentano il dettaglio della relazione AUTOMOBILI. Quando è necessario ricostruire tutte le informazioni relative a un'automobile, è sufficiente unire la relazione AUTOMOBILI con la corrispondente relazione figlia mediante la chiave primaria CodAuto.
Questo approccio si usa se le entita' figlie hanno molti attributi e si vuole suddividere le informazioni, non c'e' spreco di memoria perche' non ci sono tuple con attributi NULL.
In sintesi:
l'accorpamento delle entità figlie nell'entità padre è conveniente quando le specializzazioni sono molto simili tra loro;
l'accorpamento dell'entità padre nelle entità figlie è preferibile quando le specializzazioni sono molto diverse e vengono utilizzate separatamente;
il mantenimento sia dell'entità padre sia delle entità figlie rappresenta una soluzione intermedia, che evita inutili valori NULL e consente di conservare esplicitamente la struttura della generalizzazione.
4.6 Autoassociazioni
Un'autoassociazione è un'associazione nella quale la stessa entità partecipa più volte ricoprendo ruoli diversi. Le autoassociazioni possono essere di tipo uno-a-molti (1:N) oppure molti-a-molti (N:N).
4.6.1 Autoassociazioni di tipo 1:N.
Consideriamo l'entità PERSONA e l'associazione PadreDi. Una persona può essere padre di più persone, mentre ogni persona ha al più un padre biologico.
_________________
| |
______| PERSONA |______
| |_________________| |
| |
| |
| |
| /\ |
| / \ |
| / \ |
|__________ PADRE DI____________|
1 \ / N
\ /
\/
Nella traduzione allo schema relazionale si introduce una chiave esterna che fa riferimento alla chiave primaria della stessa relazione. Si ottiene quindi una relazione del tipo:
PERSONA(CodFiscale (PK), Cognome, Nome, CodFiscalePadre (FK))
L'attributo CodiceFiscalePadre è una chiave esterna che fa riferimento alla chiave primaria della stessa relazione PERSONA. Questa e' una associazione parziale: se una persona non ha il padre registrato nella base di dati oppure il dato non è noto, l'attributo CodiceFiscalePadre può assumere il valore NULL. Al contrario, per ogni figlio il campo CodiceFiscalePadre contiene il codice fiscale del padre registrato nella stessa relazione.
Ad esempio, se Mario Rossi è il padre di due figli, nella relazione PERSONA sarà presente una tupla relativa a Mario Rossi con il campo CodiceFiscalePadre uguale a NULL. Saranno inoltre presenti due tuple relative ai figli, nelle quali il campo CodiceFiscalePadre conterrà il codice fiscale di Mario Rossi.
Esempio: Anagrafe del comune di Firenze
Nell'anagrafe ci sono una serie di informazioni anagrafiche, per ogni persona c'e' una tupla che contiene un ID numero progressivo, per ogni famiglia ha interesse conoscere il capo famiglia e risalire al nucleo familiare. Nella tabella anagrafica devo estrarre le informazioni di una persona, capire se e' capomiglia e risalire al suo nucleo familiare.
Si codifica l'auto associazione 1:N con una relazione sulla stessa entita', perche' ad una persona sono legate piu' figli, ma un figlio e' legato un solo padre.
Anagrafe(
IdPersona (PK),
Nome,
Cognome,
DataNascita,
StatoFamiliare,
CodComuneNascita,
CodVia,
Civico,
IDCapoFamiglia (FK))
L'attributo luogo di nascita e' un comune di nascita, il nome di un comune può cambiare nel tempo oppure può essere scritto in modi differenti e provocare delle inconruenze, infatti l'operatore ad esempio potrebbe scrivere Sesto Fiorentino oppure S. Fiorentino oppure Sesto Fior. oppure Sesto F.NO. Invece l'operatore dovrebbe scegliere il comune da una lista. Per evitare incongruenze è preferibile memorizzare i comuni in una relazione dedicata, ad esempio COMUNI, e fare riferimento ad essi mediante una chiave esterna. In questo modo il nome del comune viene memorizzato una sola volta e può essere modificato senza intervenire su tutte le persone registrate. Lo stesso principio può essere applicato alle vie. Invece di memorizzare il nome della via in ogni tupla dell' Anagrafe, è possibile creare una relazione VIE contenente il codice della via, la descrizione e il CAP. La relazione ANAGRAFE conterrà solamente la chiave esterna che identifica la via.
L'attributo IdCapoFamiglia realizza un'autoassociazione sulla relazione ANAGRAFE. Per ogni componente della famiglia esso contiene l'identificativo della persona che svolge il ruolo di capofamiglia. La tupla relativa al capofamiglia contiene invece il proprio identificativo anche nel campo IdCapoFamiglia (oppure, in altri modelli, il valore NULL, a seconda delle scelte progettuali).
| IDPERSONA | COGNOME | NOME | ... | IDCAPOFAMIGLIA |
|---|---|---|---|---|
| 100 | Rossi | Mario | ... | 100 |
| 200 | Verdi | Paola | ... | 100 |
| 300 | Bianchi | Luca | ... | 300 |
| 400 | Dini | Franco | ... | 400 |
| ... | ... | ... | ... | ... |
Consideriamo l'istanza della tabella Anagrafe sopra: si vede che Rossi Mario e Verdi Paola sono legate insieme, cioe' appartengono allo stesso nucleo familiare, con capo famiglia Rossi Mario. Invece, Bianchi Luca sta da solo e Dini Franco sta da solo.
4.6.2 Autoassociazioni di tipo N:N
Consideriamo l'entità PERSONA e l'associazione AbitaCon. Una persona può abitare con più persone e, viceversa, ogni persona può abitare con più persone. Si tratta quindi di un'autoassociazione di tipo molti-a-molti (N:N).
_________________
| |
______| PERSONA |______
| |_________________| |
| |
| |
| |
| / \ |
| / \ |
| / \ |
|__________ ABITA CON___________|
N \ / N
\ /
\ /
La traduzione nel modello relazionale richiede una relazione di collegamento:
PERSONA(
CodiceFiscale (PK),
Cognome,
Nome
)
ABITA_CON(
CodiceFiscale1 (FK),
CodiceFiscale2 (FK)
)
Entrambi gli attributi della relazione ABITA_CON sono chiavi esterne che fanno riferimento alla relazione PERSONA; la prima chiave esterna indica il codice fiscale della persona, la seconda indica il codice fiscale della persona con cui abita.
Ogni tupla della relazione ABITA_CON rappresenta una specifica associazione tra due persone. Se ho tre persone che abitano insieme, se ABITA_CON rappresenta una relazione di convivenza simmetrica, tre persone che convivono generano normalmente tre coppie (A-B, A-C, B-C).
Un altro esempio di autoassociazione molti-a-molti è rappresentato dall'entità SQUADRA e dall'associazione PARTITA. Una partita mette infatti in relazione due squadre, una con il ruolo di squadra di casa e l'altra con il ruolo di squadra ospite.
_________________
| |
______| SQUADRA |______
| |_________________| |
| |
| |
| |
| / \ |
| / \ |
| / \ |
|__________ PARTITA ____________|
N \ / N
\ /
\ /
Lo schema relazionale può essere rappresentato come segue:
SQUADRE(
IdSquadra,
Nome
)
PARTITE(
IdSquadraCasa (FK),
IdSquadraOspite (FK),
RetiSquadraCasa,
RetiSquadraOspite
)
4.7 Associazione Ternaria
Le associazioni che coinvolgono più di due entità sono relativamente poco frequenti. Nella pratica si incontrano soprattutto associazioni ternarie, cioè associazioni che collegano tre entità. Consideriamo l'associazione: PROGETTO — PRODOTTO — FORNITORE. Essa descrive il fatto che un determinato fornitore fornisce uno specifico prodotto nell'ambito di un determinato progetto.
/ \
______________ / \ ______________
| | / \ | |
| PROGETTO |______ FORNITURA ______| PRODOTTO |
|______________| \ / |______________|
\ /
\ /\
| quantita'
|
_______|_______
| |
| FORNITORE |
|_______________|
La traduzione nel modello relazionale genera quattro relazioni: le tre entità diventano tre relazioni e l'associazione diventa una quarta relazione.
PROGETTI(
CodProgetto (PK),
...
)
PRODOTTI(
CodProdotto (PK),
...
)
FORNITORI(
IdFornitore (PK),
...
)
FORNITURE(
CodProgetto (FK),
CodProdotto (FK),
IdFornitore (FK),
Quantità
)
5 Esempio: Sistema per la prenotazione per gli spettacoli al teatro
Vediamo ora un esempio completo di progettazione concettuale e della sua traduzione nello schema relazionale. Si vuole progettare una base di dati per la gestione delle prenotazioni di un teatro composto da 1000 posti, suddivisi in 25 file da 40 posti ciascuna. Ogni posto è identificato dalla fila e dal numero. Un cliente può effettuare una o più prenotazioni. Ogni prenotazione è relativa ad uno spettacolo e può comprendere uno o più posti. La prenotazione possiede inoltre attributi propri, come la data di prenotazione e l'eventuale stato di annullamento.
Il modello concettuale si traduce nello schema relazione:
CLIENTI(codCliente, ...) SPETTACOLI(idSpettacolo, ...) POSTI(idPosto, ...) PRENOTAZIONI(idPrenotazione, ... , codCliente (FK), idSpettacolo (FK)) POSTI_PRENOTAZIONI(idPrenotazione(FK), idPosto(FK))
Una prenotazione può comprendere uno o più posti. Per questo motivo la relazione tra PRENOTAZIONI e POSTI è di tipo molti-a-molti e viene rappresentata mediante una relazione di collegamento. Se, ad esempio, un'agenzia prenota 100 posti per lo stesso spettacolo, nella relazione PRENOTAZIONI sarà presente una sola tupla, mentre nella relazione POSTI_PRENOTAZIONI saranno presenti 100 tuple, una per ciascun posto prenotato.
In questo esempio, la relazione POSTI_PRENOTAZIONI non possiede attributi propri. Se la relazione di collegamento rappresentasse invece una fornitura tra un prodotto e un fornitore, potrebbe contenere attributi propri, come la quantità, il prezzo unitario o la data della fornitura.
(Vedere il PDF con gli esercizi svolti del professore)
Nota mia: l'entità SPETTACOLO rappresenta il titolo dello spettacolo. Poiché uno stesso spettacolo può essere rappresentato più volte in date diverse, è opportuno introdurre un'entità REPLICA contenente la data e l'ora della rappresentazione. La PRENOTAZIONE farà quindi riferimento a una specifica replica dello spettacolo.
6 Esempio: Il sistema per la gestione degli orari dei treni
Consideriamo ora un esempio leggermente più articolato, nel quale alcune informazioni sono permanenti, mentre altre cambiano continuamente nel tempo. Le entità Treno, Stazione e Fermata rappresentano la parte statica della base di dati, cioè informazioni che cambiano raramente. Le entità TrenoReale e FermataReale rappresentano invece la parte dinamica, cioè i dati che variano durante l'esercizio ferroviario, come i ritardi e gli orari effettivi di transito.
Il modello concettuale si traduce nello schema relazione:
Treno(CodTreno, StazionePartenza (FK), StazioneArrivo (FK), ...) TrenoReale(ID, CodiceTreno (FK), ...) Stazione(Codice, CodiceComune (FK), ...) Comune(Codice, ...) Fermata(CodTreno, CodStazione, ...) FermataReale(IdTrenoReale, CodStazione, ...)
No comments:
Post a Comment