Il modello relazionale, proposto dal matematico americano Codd, si basa sul concetto di relazione matematica. Il modello relazionale e' un modello teorico, alla base c'e' una teoria con una sua algebra e con i suoi operatori.
1 Definizione di Relazione
Si definisce prodotto cartesiano di due insiemi A e B, A×B l’insieme delle coppie ordinate (a,b), dove: a∈A, b∈B.
Si definisce relazione (binaria) sugli insiemi A e B, detti domini della relazione, un insieme 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.
Si definisce relazione sugli insiemi D1, D2,...,Dn, detti domini, un sottoinsieme finito del prodotto
cartesiano D1×D2×...×Dn.
Il grado della relazione e' il numero n degli insiemi componenti del prodotto cartesiano; ad ogni dominio si associa un attributo.
La cardinalità della relazione e' il numero di n-uple che compaiono nella relazione.
2 Relazione ed Attributi
La relazione che descrive i Libri di è un sottoinsieme di: stringa × stringa × stringa × stringa × reale × intero
| 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, per cui:
Attributi, Schema, Tuple
3 Relazione e Tabelle
Una relazione viene rappresentata con una tabella. Lo schema della relazione e' la parte costante della tabella, l'istanza della relazione sono le righe della tabella. Quando rappresento una relazione con una tabella, la sequenza di valori assunti da un attributo genera una colonna della tabella, mentre una tupla della relazione genera una riga della tabella. Il grado della relazione diventa il numero delle colonne della tabella, la cardinalita' della relazione diventa il numero delle righe della tabella.
| 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 |
Relazione Libri, Grado(Libri) = 6, Cardinalita'(Libri) = 3
In ogni tabella non esistono due righe uguali per la presenza di un attributo speciale detto chiave primaria (PK=Primary Key), che individua univocamente una tupla dalle altre. Nello schema della relazione si sottolinea l’attributo chiave.
4 Dal diagramma E/R allo schema relazionale
Questo paragrafo tratta le regole per la traduzione dallo schema concettuale nello schema logico. Nel diagramma ER ci sono entita', attributi e associazioni di vario tipo, applicando le cosiddette regole di derivazione si ottengono le relazioni a partire da entita' ed associazioni.
4.1 Rappresentazione delle entità e degli attributi
Ogni entita' diventa una relazione, rappresentata tramite una tabella. Ad esempio, si hanno le tabelle Treni, una tabella Orari, una tabella Tratte, ecc.
Ogni attributo dell’entità diventa un attributo della relazione, rappresentato mediante una colonna della tabella. L’attributo chiave dell’entità diventa l’attributo chiave della relazione.
Eventuali attributi composti vengono sostituiti con gli attributi componenti. Ad esempio l'attributo indirizzo e' un attributo composto da via, numero civico e CAP, per cui nella tabella ci vanno tre attributi: via, civico e CAP, oppure via e civico li metto insieme.
Nel caso di attributi multipli si procederà alla normalizzazione della relazione.
Ad esempio, se sto modellando l'entita' persona, l'attributo hobby e' un attributo multiplo, perche' una persona potrebbe avere come hobby: giardinaggio, lettura, teatro. Allora, come si vede nel processo della normalizzazione, un attributo multiplo viene staccato dall'entita', si forma una entita' a se stante e fra le due entita' si crea una associazione 1:N.
Nel caso dell'entita libro, un libro puo' avere piu' autori. Se sto progettando una database per la gestione di una biblioteca si deve normalizzare la relazione, perche' nella ricerca dei libri si vuole andare per autore, per cui creo una nuova relazione chiamata Autori e la collego con la relazione libro. A quel punto diventa una relazione molti a molti, perche' un libro puo' essere scritto da piu' autori e un autore puo' scrivere piu' libri.
Quando si pone il problema della ricerca per un attributo, quell'attributo deve essere semplice e non puo' essere ne' composto ne' multiplo.
4.2 Rappresentazione delle associazioni binarie 1:1
Le due entità si fondono in un’unica relazione, avente gli attributi di entrambe le entità. Ad esempio, PresideScuola, PersonaCodiceFiscale: il codice fiscale diventa un attributo della persona e il preside diventa un attributo della scuola.
4.3 Rappresentazione delle associazioni binarie 1:N
Si consideri l'associazione 1:N Persona:Auto: una persona puo' possedere piu' auto, ma un'auto puo' essere intestata solo ad una persona.
/\
_____________ / \ _____________
| | / \ | |
| PERSONA |_________ POSSIEDE _________| AUTO |
|_____________| (0,N) \ / (1,1) |_____________|
\ /
\/
Due entità A e B legate da una associazione di tipo 1:N (lato 1 su A e lato N su B) vengono tradotte nel modello relazionale in:
- una relazione RA avente gli attributi di A;
- una relazione RB avente gli attributi di B piu' l’attributo chiave di RA, (KA) che prende il nome di chiave esterna (FK = Foreign Key);
Così facendo si crea fra RA e RB un vincolo referenziale, nel senso che tutti i valori della chiave esterna KA in RB devono essere presenti anche nella chiave primaria KA in RA.
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))
In ogni tupla della tabella Automobili la chiave primaria assume un valore diverso: non si ripete mai. Questo non vale per la chiave esterna, in quanto che se 5 auto appartengono alla stessa persona, per queste 5 tuple il valore CodFiscale e' lo stesso.
Una volta, l'associazione Squadre:Giocatori era un esempio di associazione 1:N, perche' nell'arco del campionato una squadra possedeva piu' giocatori e un giocatore poteva appartenere ad una sola squadra; adesso, con l'introduzione della sessione invernale del mercato dei giocatori, Squadre:Giocatori e' diventato un esempio di associazione N:N e hanno dovuto riconvertire i database.
Consideriamo l'associazione opzionale 1:N Professore:Cassetto: un professore puo' possedere uno o piu' cassetti, un cassetto appartiene al piu' ad un professore.
/ \
____________ / \ ___________
| | / \ | |
| PROFESSORE |__________ POSSIEDE ___________| CASSETTO |
|____________| (1,N) \ / (0,1) |___________|
\ /
\ /
In questo caso, nella relazione si deve specificare che la chiave esterna puo' essere NULL, cioe' si deve rimuovere il vincolo referenziale fra RA e RB. In generale, questo e' pericoloso per l'integrita' referenziale del database; se questo ci da' noia, basta trasformare l'associazione da opzionale in obbligatoria.
4.4 Rappresentazione delle associazioni binarie molti a molti
Due entità A e B legate da una associazione C di tipo N:N, vengono tradotte nel modello relazionale con tre relazioni: due relazioni per le due entita' e una relazione per l'associazione. Quindi si sostituisce l'associazione C con una entita' che diventa una relazione.
- una relazione RA, avente gli attributi di A;
- una relazione RB, avente gli attributi di B;
- una relazione RC, avente, oltre agli attributi propri, l’attributo chiave KA di RA e l’attributo chiave KB di RB (le due chiavi esterne nella relazione RC)
Così facendo si crea in RC un vincolo referenziale, nel senso che tutti i valori della chiave esterna
KA (KB) presente in RC DEVONO essere presenti anche nella chiave primaria in
KA (KB) nella relazione RA (RB).
La chiave primaria coincide con l’unione degli identificatori delle entità collegate
Esempio: associazione Articolo:Fornitore.
L'associazione Fornitore:Articolo e' di tipo N:N; per esempio, al supermercato, un fornitore fornisce uno o piu' prodotti e un prodotto viene fornito da piu' fornitori.
Si traduce nelle tre relazionali:
Articoli(CodArt (PK), Descrizione, Prezzo) Fornitori(CodForn (PK), Nome, Via, Citta, Cap, PartitaIVA) Forniture(CodArt (FK), CodForn (FK), Data, Quantità, PrezzoUnit)
La terza relazione contiene gli attributi che sono propri dell'associazione Forniture: quantita', prezzo unitario e data di fornitura, perche' sono valori che si determinano al momento in cui gli articoli sono forniti. (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. Se una (entrambe) le associazioni 1:N sono parziali basterà specificare come indefinito (NULL) il valore di una (entrambe) delle chiavi esterne; ma in pratica conviene introdurre un vincolo referenziale e dire che ogni tupla di forniture deve avere un valore preciso della chiave esterna legata ad un articolo e un valore preciso della chiave esterna legata ad un fornitore
Esempio: associazione Proprietario:Immobile
L'associazione Proprietario:Immobile e' di tipo molti a molti, perche' marito e moglie posseggono un immobile al 50%, e due immobili (un appartamento e un box) sono posseduti da un proprietario. Allora, l'associazione si modella con tre relazioni: Proprietari, Immobili e una terza relazione, che chiamo RelImmobiliProprietari, che contiene le due chiavi primarie delle due relazioni.
La relazione Immobili gia' possiede naturalmente una sua chiave primaria 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 non se ne interessa e
fa una chiave IdImmobile che e' un numero progressivo.
Se non si sa come nominare la terza relazione, il professore usa la convenzione di dare come nome la concatenazione delle due relazioni piu' il prefisso "Rel". Si noti che, in MySQL, il linguaggio di interrogazione e' case-sensitive per i nome delle tabelle e case-insensitive per i nomi dei campi; per cui e' bene stabilire una regola per i nomi delle tabelle: o tutte in minuscolo o tutto in maiuscolo.
Immobili(IdImmobile, vani, metriQuadri, prezzo, via, citta, CAP) Proprietari(CodiceFiscale, cognome, nome, ... ) RelImmobiliProprietari(IdImmobile, CodiceFiscale, quotaPossesso)
La relazione RelImmobiliProprietari, ha come attributi la sua chiave primaria, le due chiavi esterne IdImmobile e CodiceFiscale, e un attributo proprio di nome quotaPossesso. Per cui se moglie e marito posseggono un immobile, vedro' nella tabella RelImmobiliProprietari due tuple, con lo stesso IdImmobile ma diverso CodiceFiscale.
4.5 Associazioni di generalizzazioni
Nell'associazione per generalizzazione una entita' figlia e' la specializzazione di una entita' padre. Abbiamo visto l'esempio del concessionario di automobili che gestisce sia il parco auto nuove che il parco auto usate. L'auto ha delle caratteristiche comuni che sono nell'entita' padre (marca, modello, cilindrata), l'entita figlia "nuovo" ha l'attributo optional e l'entita' figlia "usato" ha gli attributi km percorsi, anno di immatricolazione e le riparazioni.
Come si traduce una associazione 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 figlie nel padre
Le entità figlie vengono eliminate ed i loro attributi, assieme ad eventuali partecipazioni, vengono aggiunti all’entità padre. All’entità padre viene inoltre aggiunto un attributo numerico (che chiamo Tipo) per distinguere se ciascuna tupla appartiene ad F1 oppure ad F2, etc.
Operiamo questa traduzione quando le operazioni sulla base di dati non fanno molta distinzione tra tuple di una figlia o di un’altra. Il vantaggio e' che si accede ad una sola tabella, lo svantaggio e' che si ha uno spreco di memoria, dovuto alla presenza di valori nulli per alcuni attributi.
Ad esempio, nella generalizzazione Automobili, scomposta nelle figlie Nuove e Usate, possiamo accorpare le figlie nel padre. Se l'attributo TipoAuto vale 1 la tupla individua un'auto nuova, se vale 2 individua un'auto usata.
Automobili(CodAuto, Marca, Modello, AnniGaranzia, KmPercorsi,..., TipoAuto, CodProp)
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 mi invento 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 del padre nelle figlie
Se le entita' figlie sono diverse tra loro, cioe' non hanno attributi in comune, non posso accorpare le figlie nel padre, perche' si avrebbe un grosso spreco di memoria, nella tabella si avrebbero delle tuple con parecchi valori NULL. Allora l’entità padre P viene eliminata, i suoi attributi e le associazioni vengono aggiunti alle figlie e ogni entita' figlia diventa un relazione. Questa traduzione è possibile solo se la generalizzazione è totale, cioè se ogni tupla di P è una tupla di F1, o di F2,..., o di Fn.
Tale traduzione è conveniente se ci sono operazioni sulla base di dati che si riferiscono solo a tuple di una figlia o solo a tuple dell’altra figlia, facendo distinzione tra le entità figlie. In questo caso abbiamo, rispetto alla soluzione 1, un risparmio di memoria ed un accesso alla memoria ottimizzato.
AutoNuove(CodAuto, Marca, Modello, AnniGaranzia,..., CodProp) AutoUsate(CodAuto, Marca, Modello, AnniGaranzia, KmPercorsi,..., CodProp)
4.5.3 Sostituzione della generalizzazione con associazioni di tipo 1:1
La generalizzazione viene tradotta in tante associazioni 1:1 quante sono le entità figlie. Non si vuole perdere la generalizzazione e si mantengono sia l'entita' padre che l'entita' figlie, le entita' figlie generano delle relazioni che sono dettaglio della relazione padre. La chiave primaria dell’entità padre è usata anche come chiave primaria delle entità figlie.
Automobili(CodAuto, Marca, Modello, AnniGaranzia, CodProp) Nuove(CodAuto, ...) Usate(CodAuto, KmPercorsi, AnnoImm,...)
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 campi NULL.
La relazione Automobili contiene solo gli attributi generali in comune a tutti e due, le relazioni Nuove ed Usate contiene solo gli attributi in piu' delle entita' figlie. Se voglio conoscere tutte le automobili nuove, accedo alle tabelle Automobili e Nuove e le metto insieme con la chiave primaria CodAuto. Se la tabella Automobili ha 20 righe, di cui 15 per nuove e 5 per usate, allora la tabella Nuove ha 15 righe e la tabella Usate 5 righe: la tabella Automobili contiene le informazioni generali, le altre due tabelle contiene i dettagli.
Usa la soluzione 1 se le figlie sono simili tra loro, la soluzione 2 se le figlie sono diverse tra loro. La soluzione 3 rappresenta un compromesso tra le prime due.
4.6 Auto Associazioni
Le auto associazioni possono essere di tipo 1:N e di tipo N:M.
4.6.1 Auto associazioni di tipo 1:N.
Consideriamo l'entita' Persona e l'associazione PadreDi, una persona puo' essere il padre di altre N persone.
_________________
| |
______| PERSONA |______
| |_________________| |
| |
| |
| |
| /\ |
| / \ |
| / \ |
|__________ PADRE DI____________|
1 \ / N
\ /
\/
Ad esempio, consideriamo le famiglie che abitano in un condominio e supponiamo di mettere in relazione le entita' persone che abitano nel condominio attraverso l'associazione PadreDi, cioe' si mettono in relazione i padri e i figli. Si ha lo schema relazionale:
Persona(CodFiscale (PK), Cognome, Nome, CodFiscalePadre (FK))
Per tradurre una auto associazione, nella relazione la chiave esterna si riferisce alla chiave primaria. Questa e' una associazione parziale, perche' in un condominio, ci possone essere persone che non sono il padre di nessuno, in quel caso il codice fiscale padre e' NULL. Supponiamo che nel condominio esiste la persona Mario Rossi che e' padre di due figli, allora Mario Rossi e' una tupla della relazione Condominio per cui CodFiscalePadre vale NULL. Nella relazione compaiono anche due tuple per figli di Mario Rossi, in cui il campo CodFiscalePadre e' valorizzato con 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))
Il campo luogo di nascita e' un comune di nascita, se lo metto in formato testuale e' soggetto a mofiche, puo' provocare delle inconruenze, perche' indurrebbe in errore l'operatore, il quale 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, i comuni italiani sono tabellati e sono circa 10 mila. La stessa cosa si puo' fare anche per le vie delle citta', infatti se cambia il nome di una via, non conviene cambiare il campo via nelle tuple della Anagrafe, ma e' sufficiente cambiare il nome della via nella tabella esterna Vie. Ragion per cui si crea una tabella Comuni con tutti i nomi dei comuni e in Anagrafe si aggiunge la chiave esterna che chiamo CodComuneNascita. Lo stesso si fa per le Via: si crea una tabella Vie, contenente il codiceVia, la descrizione e il CAP.
La tabella contiene anche il campo IDCapoFamiglia, che traduce una associazione dell'anagrafe con se stessa e l'associazione si intitola anagrafe.persona e' capofamiglia di. Questa relazione lega una tupla con altre tuple: il capofamiglia e' quello che ha nel campo IDCapoFamiglia lo stesso Id di IdPersona,
| 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 Auto associazioni di tipo N:M
Consideriamo l'entita' Persona e l'associazione AbitaCon, una persona puo' abitare con altre N persone.
_________________
| |
______| PERSONA |______
| |_________________| |
| |
| |
| |
| / \ |
| / \ |
| / \ |
|__________ ABITA CON___________|
N \ / N
\ /
\ /
Consideriamo le persone che abitano in un condominio che vogliamo mettere in relazione attraverso l'associazione AbitaCon. In questo caso, la traduzione nello schema relazionale e' piu' difficile rispetto a prima e non me la posso cavare aggiungendo una chiave esterna, perche' una persona abita sempre con altre N persone. L'auto associazione molti a molti si traduce con due relazioni: Persona e AbitaCon. L'associazione AbitaCon e' una relazione con due chiavi esterne: la prima chiave esterna indica il codice fiscale della persona, la seconda indica il codice fiscale della persona con cui abita.
Persona(CodFiscale, Cognome, Nome) AbitaCon(CodFiscale1, CodFiscale2)
Se ho tre persone che abitano insieme, allora nella tabella Persone ho tre tuple e nella tabella AbitaCon ho due tuple.
Esempio: Auto Associazione Partita
_________________
| |
______| SQUADRA |______
| |_________________| |
| |
| |
| |
| / \ |
| / \ |
| / \ |
|__________ PARTITA ____________|
N \ / N
\ /
\ /
L' associazione Squadra:Squadra e' un esempio di auto associazione molti a molti, quindi l'associazione partita diventa la relazione Partite, contenente gli ID della squadra in casa e di quella fuori casa. Infatti una squadra in una partita puo' giocare in casa o fuori casa.
Squadre(IdSquadra , Nome) Partite(RetiSquadraInCasa, RetiSquadraTrasferta, IdSquadraInCasa (FK), IdSquadraTrasferta (FK))
4.7 Associazione Ternaria
Le associazioni con piu' entita' non sono molto comuni e di solito non si va oltre all'associazione con tre entita'. Consideriamo l'associazione ternaria Progetto:Prodotto:Fornitore.
/ \
______________ / \ ______________
| | / \ | |
| PROGETTO |______ FORNITURA ______| PRODOTTO |
|______________| \ / |______________|
\ /
\ /\
| quantita'
|
_______|_______
| |
| FORNITORE |
|_______________|
L'associazione ternaria viene tradotta nel modello relazionale: le tre entita diventano tre relazioni e l'associazione ternaria diventa la relazione Forniture con tre chiavi esterne:
Progetti(codProgetto (PK), ...) Prodotti(codProdotto (PK), ...) Fornitori(idFornitore (PK), ...) Forniture(codProgetto (FK), codProdotto (FK), idFornitore (FK), Quantita)
5 Esempio: Sistema per la prenotazione per gli spettacoli al teatro
Realizzare uno schema ER per la gestire un sistema di prenotazione di un teatro di 1000 posti, suddivisi in 25 file di 40 poltrone ognuna. Ogni poltrona e' individuata da una lettera per la fila e da un numero.
Svolgimento. Un cliente prenota un posto per uno spettacolo. Un cliente puo' fare piu' prenotazioni o per piu' spettacoli o per piu' posti. La prenotazione ha gli attributi: data e annullata.
Il modello concettuale si traduce nello schema relazione:
Clienti(codCliente, ...) Spettacoli(idSpettacolo, ...) Posti(idPosto, ...) Prenotazioni(idPrenotazione, ... , codCliente (FK), idSpettacolo (FK)) Rel_PostiPrenotazioni(idPrenotazione (FK), idPosto (FK))
In queso modello concettuale una prenotazione e' relativa ad uno o piu' posti. Se una agenzia prenota 100 posti per uno spettacolo, si ha una solo n-pla per la relazione Prenotazioni e 100 n-ple nella relazione Rel_PostiPrenotazioni.
La relazione Rel_PostiPrenotazioni non contiene attributi dell'associazione. Se invece stessi trattando l'associazione N:N Prodotto:Fornitore, allora avrebbe piu' senso tradurre l'associazione con una entita di dettaglio, di nome fornitura, la quale conterrebbe i dettagli della fattura, come numero e data.
Vedere il PDF con gli esercizi svolti del professore
6 Esempio: Il sistema per la gestione degli orari dei treni
Le entita Treno e Fermata rappresentano la parte statica del database, le entita Trenoreale e FermataReale rappresentano la parte dinamica del database; la parte dinamica tiene traccia dei ritardi compiuti dai treni.
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