Chiarimenti sul modello Entity/Relationship

Transcript

1 Chiarimenti sul modello Entity/Relationship Breve riassunto sul modello Entity-Relationship e le sue conseguenze sul modello Relazionale 17/11/2011 Ing. Damiano FanelliAdmin 0

2 CHIARIMENTI SUL MODELLO ENTITY-RELATINOSHIP CARDINALITA NELLE RELAZIONI In questi appunti vogliamo spiegare in dettaglio il significato delle cardinalità nelle relazioni presenti nel modello Entity-Relationship, e la traslazione dal modello concettuale al modello fisico. Innanzitutto consideriamo le Binary Aggregation (aggregazioni binarie) che sono delle corrispondenze tra elementi di due insiemi, dove ad un elemento di un insieme corrispondono un o più elementi dell altro insieme (l aggregazione è binaria in quanto gli insiemi in corrispondenza tra loro sono due). Per esempio, se consideriamo l aggregazione USA tra gli insiemi PERSONE ed IMMOBILI, stabiliamo una corrispondenza tra elementi degli insiemi stessi. Questa corrispondenza significa che ad ogni elemento di PERSONE corrispondono, attraverso la relazione USA, elementi di IMMOBILI. Ovviamente noi interpretiamo questa corrispondenza (aggregazione binaria) nel fatto che una data persona usa un dato immobile. Ad esempio, GUIDA è una aggregazione binaria tra i due insiemi PERSONE ed AUTOMOBILI, con una chiara interpretazione. Molte aggregazioni binarie possono essere stabilite tra due insiemi, ad esempio possiamo considerare l aggregazione binaria POSSIEDE sempre tra gli insiemi PERSONE ed IMMOBILI, stabilendo quindi una corrispondenza di possesso tra elementi degli insiemi stessi. Possiamo rappresentare questa aggregazione con due insiemi PERSONE ed IMMOBILI e delle linee da un insieme all altro. Le linee rappresentano l aggregazione binaria esistente tra i due insiemi. Aggregazione binaria USA Aggregazione binaria POSSIEDE Persone Immobili Persone FIG 1 FIG 2 Immobili 1 Ing. Damiano Fanelli

3 Confrontando le due figure, possiamo notare che le corrispondenze o aggregazioni (USA e POSSIEDE) tra i due insiemi, sono caratterizzate da diverse proprietà; per esempio ogni persona USA un immobile, ma solo alcune persone POSSIEDONO un immobile. Ancora, ogni immobile può essere usato da più persone, ma ogni immobile è posseduto solo da una persona. Questa osservazione ci porta al concetto di CARDINALITA delle corrispondenze (aggregazioni binarie) tra due insiemi. CARDINALITA MINIMA (MinCard) Consideriamo l aggregazione A tra due insiemi C1 e C2. La CARDINALITA MINIMA indicata con MinCard( C1, A) è il minimo numero di corrispondenze nelle quali ogni elemento di C1 può partecipare. Similmente, MinCard( C2, A ) è il minimo numero di corrispondenze nelle quali ogni elemento di C2 può partecipare. Questa corrispondenza significa che ad ogni elemento di C1 corrispondono, attraverso la relazione A, elementi di C2. Consideriamo allora l aggregazione USA e POSSIEDE tra gli insiemi PERSONE e IMMOBILI: 1. Se assumiamo che ogni persona usa almeno un edificio, allora la MinCard(PERSONA,USA)=1 2. Se assumiamo che qualche immobile è disabitato, cioè non è usato da nessuno, allora la MinCard(PERSONA,USA)=0 3. Se assumiamo che alcune persone non possiedono un edificio, allora la MinCard(PERSONA,POSSIEDE)=0 4. Se assumiamo che alcune persone devono possedere un edificio, allora la MinCard(PERSONA,POSSIEDE)=1 Questi esempi mostrano come i valori importanti della cardinalità minima sono zero (0) oppure uno (1). Se la MinCard( C1, A ) = 0, diciamo che C1 ha PARTECIPAZIONE PARZIALE nella aggregazione, perché esistono degli elementi dell insieme C1 che non hanno una corrispondenza, attraverso la relazione A, ad elementi dell insieme C2. 2 Ing. Damiano Fanelli

4 Se la MinCard( C1, A ) = 1, diciamo che C1 ha PARTECIPAZIONE OBBLIGATORIA nella aggregazione, perché esistono degli elementi dell insieme C1 che hanno obbligatoriamente una corrispondenza, attraverso la relazione A, ad elementi dell insieme C2 (ad un elemento di C1 deve corrispondere, per forza, almeno un elemento di C2) Nell esempi di fig1 abbiamo che IMMOBILE ha una partecipazione PARZIALE nella relazione USA, mentre ha una partecipazione OBBLIGATORIA nella relazione POSSIEDE. CARDINALITA MASSIMA (MaxCard) Consideriamo l aggregazione A tra due insiemi C1 e C2. La CARDINALITA MASSIMA indicata con MaxCard( C1, A ) è il numero massimo di corrispondenze nelle quali ogni elemento di C1 può partecipare. Similmente, MaxCard( C2, A ) è il massimo numero di corrispondenze nelle quali ogni elemento di C2 può partecipare. Consideriamo ancora le aggregazioni USA e POSSIEDE tra gli insiemi PERSONE ed IMMOBILI: 1. Se assumiamo che ogni persona USA molti immobili, allora la CardMax(PERSONA,USA) = N. Con N vogliamo intendere un numero qualsiasi, anche molto grande!! 2. Se assumiamo che ogni immobile può essere usato da molte persone, allora CardMax(IMMOBILE, USA) = N 3. Se assumiamo che ogni persona può possedere molti immobili, allora CardMax(PERSONA, POSSIEDE) = N 4. Se assumiamo che ogni immobile è posseduto esattamente da una persona, allora CardMax(IMMOBILE, POSSIEDE) = 1 e CardMin(PERSONA, POSSIEDE)=1 Considerando sempre i due insiemi C1, C2 e una aggregazione binaria A tra loro, abbiamo che la cardinalità massima può avere due valori, uno (1 ) e molti (N); N rappresenta qualunque numero e indica che ogni elemento di C1 può essere aggregato (sempre attraverso la relazione A) ad un numero molto grande di elementi di C2. Se MaxCard( C1, A ) = 1 e MaxCard( C2, A ) = 1, diciamo che l aggregazione è uno-a-uno. Se MaxCard( C1, A ) = 1 e MaxCard( C2, A ) = N, diciamo che l aggregazione è uno-a-molti. Se MaxCard( C1, A ) = N e MaxCard( C2, A ) = 1, diciamo che l aggregazione è molti-a-uno. Se MaxCard( C1, A ) = N e MaxCard( C2, A ) = N, diciamo che l aggregazione è molti-a-molti. 3 Ing. Damiano Fanelli

5 Elementi del Modello E/R Gli elementi base del modello E/R sono le ENTITA, le RELAZIONI e gli ATTRIBUTI. Da notare che usiamo i termini entità e relazioni per denotare insiemi di elementi del mondo reale! Alcuni autori usano i termini tipo entità e tipo relazione. ENTITA Le entità rappresentano insiemi del mondo reale, come ad esempio PERSONE, UOMINI, DONNE, IMPIEGATI e CITTA, possono essere entità di una base di dati di persone. Le entità sono graficamente rappresentate da rettangoli con il nome dell insieme che rappresentano. RELAZIONI Le relazioni rappresentano aggregazioni di due o più entità. Come esempio di relazione in un data base di gestione delle persone, c è la relazione NATO_IN tra persone e città, la quale mette in corrispondenza una persona con la città nella quale è nata. Un altra relazione binaria tra persone e città è la relazione VIVE_IN che mette in relazione (corrispondenza) una persona con la citta nella quale vive. NATA_IN PERSONA CITTA VIVE_IN FIG 3 RELAZIONI RICORSIVE Le relazioni ricorsive rappresentano aggregazioni tra una entità e se stessa. Ad esempio la relazione indicante che un impiegato gestisce altri impiegati è rappresentata da una relazione ricorsiva: GESTISCE_GLI IMPIEGATO GESTISCE GESTITO_DA FIG 4 4 Ing. Damiano Fanelli

6 Ogni relazione ha uno specifico significato, quindi dobbiamo selezionare nomi significativi per le relazioni. Per esempio, se il nome AT viene usato per denotare una relazione che connette le entità PERSONA e CITTA, lo schema non esprimerebbe se la relazione è una relazione di NASCITA o di RESIDENZA. Le relazioni sono espresse in termini di minima e massima cardinalità, come già visto. Nell esempio di Fig3 abbiamo le seguenti cardinalità: 1. MinCard( PERSONA, VIVE_IN) =1, una persona vive solo in una città 2. MaxCard( PERSONA, VIVE_IN ) = 1, una persona può vivere solo in una città 3. MinCard( CITTA, VIVE _IN) = 0, in una città può non vivere una certa persona 4. MaxCard( CITTA, VIVE_IN ) = N, in una città vivono molte persone Sulla base delle precedenti cardinalità, abbiamo che la relazione VIVE_IN tra PERSONE e CITTA è una relazione UNO-A-MOLTI. La partecipazione di PERSONA, nella relazione, è obbligatoria, mentre la partecipazione di CITTA, nella relazione, è parziale. Noi sintetizziamo la cardinalità minima e massima con una coppia di valori: Card(PERSONA, VIVE_IN)= (1,1) e Card(CITTA, VIVE_IN)= (0, N) (1,1) NATA_IN (0,N) PERSONA CITTA VIVE_IN (1,1) (0,N) 5 Ing. Damiano Fanelli

7 DALLO SCHEMA CONCETTUALE ALLO SCHEMA FISICO Ricordo che i passi per la progettazione di una base di dati secondo il modello E/R sono i seguenti: Descrizione del problema Schema Concettuale Schema Logico Schema Fisico Una volta progettato lo schema concettuale, dove, ricordiamo, l obiettivo principale è la completezza e l espressività dello schema, che rappresentano alcuni elementi per definire la qualità di uno schema concettuale (tra gli altri ci sono: Correttezza, Minimalità, Leggibilità, Estensibilità, Normalità ). La definizione è la seguente. 1. Completezza: Uno schema è completo quando rappresenta tutte le informazioni rilevanti del dominio applicativo. La completezza può essere controllata: a. guardando in dettaglio a tutti i requisiti del dominio applicativo, e controllando se questi requisiti sono stati rappresentati tutti quanti, da qualche parte sullo schema (in questo caso diciamo che lo schema è completo rispetto ai requisiti); b. controllando, lo schema per vedere se ogni concetto è menzionato nei requisiti (in questo diciamo che i requisiti sono completi rispetto allo schema) 2. Espressività: Uno schema è espressivo quando rappresenta i requisiti in un modo naturale che può essere capito facilmente attraverso il significato degli elementi e dei costrutti dello schema E/R, senza ulteriori spiegazioni. La progettazione logica si propone di ottenere una rappresentazione che usa nel modo più efficiente possibile, le caratteristiche del DBMS di destinazione per la strutturazione dei dati e la modellazione dei vincoli disponibile nel modello logico. Una volta realizzato lo schema logico, il passaggio allo schema fisico, cioè le tabelle della base di dati, il passaggio è immediato. Il passaggio dallo schema concettuale a quello logico si divide in due fasi: 1. schema logico INDIPENDENTE dal modello, cioè indipendente dal DBMS target 2. schema logico DIPENDENTE dal modello, cioè dipendente dal DBMS target ( Per DBMS target intendiamo lo specifico strumento per la costruzione del data base, come per esempio ACCESS, MySQL, SQL Server, Inforimx, Oracle, ecc.. ) 6 Ing. Damiano Fanelli

8 La metodologia per la realizzazione dello schema logico dipendente dal modello è governato da una stima del carico applicativo, cioè da una valutazione di quanti record andranno caricati nelle varie entità e relazioni e il loro numero medio, in base a questa stima vedremo come semplificare lo schema concettuale eliminando le gerarchie di generalizzazione, partizionando entità e relazioni, oppure fondendo assieme le entità e le relazioni. Comunque, per gli scopi del corso, non è il caso di addentrarci troppo nella metodologia, che potrebbe risultare complessa, fermo restando che alcune direttive vanno seguite per realizzare delle buone basi di dati. Faremo degli esempi solamente con le gerarchie di generalizzazione. 7 Ing. Damiano Fanelli

9 RIMOZIONE DELLE GERARCHIE DI GENERALIZZAZIONE Il modello relazionale non permette la rappresentazione delle gerarchie di generalizzazione, questo perché i DBMS attuali non hanno strumenti per la loro gestione! Quindi se nel nostro schema concettuale abbiamo usato queste gerarchie (spesso vanno usate per rendere lo schema sufficientemente ESPRESSIVO della realtà che stiamo rappresentando), esse vanno eliminate. Per una facile discussione chiamiamo super-entity e sub-entity le entità facenti parte della generalizzazione, con ovvio significato. La metodologia consiste nello scegliere tra le seguenti tre alternative: 1. Collassare le sub-entity nella super-entity, migrando tutti gli attributi delle sub-entity nella super-entity, aggiungendo un attributo per distinguere le sub-entity. 2. Eliminare la super-entity propagando i suoi attributi nelle sub-entity. 3. Lasciare la super-entity e le sub-entity stabilendo una relazione tra super-entity e subentity. Gerarchia di generalizzazione modellata come una sola entità (punto 1) In questo caso gli attributi delle sub-entity migrano verso la super-entity, aggiungendo un attributo (laureando?) per distinguere i laureandi dagli altri studenti: Num. Matricola Num. Matricola Studente Cognome Cognome Titolo Tesi Titolo Tesi Studente Laureando Matricola (iscritti 1 anno) (1,1) (0,1) (0,1) (0,1) Laureando? Seguito E Greco Seguito E Greco (1,N) (1,N) (1,N) Consulente di Facoltà (1,N) Confraternita Dei greci Consulente di Facoltà Confraternita Dei greci Schema Concettuale Schema Logico Nota: per matricola si intende lo studente iscritto per la prima volta ad un corso di laurea 8 Ing. Damiano Fanelli

10 Gerarchia di generalizzazione modellata dalle sole sub-entity (punto 2) In questo caso gli attributi delle super-entity migrano verso le sub-entity, la chiave primaria della super-entity diventa chiave primaria delle sub-entity, inoltre la relazione esistente sulla super-entity si sdoppia in due o più relazioni, una per ogni sub-entity: Città Nato_in Città Titolo Tesi Laureando Studente Num. Matricola Cognome Matricola (iscritti 1 anno) (1,1) (0,1) Cognome Titolo Tesi Nato_in_1 Laureando Num. Matricola Cognome Nato_in_2 Matricola (iscritti 1 anno) Num. Matricola (1,1) (0,1) Seguito E Greco Seguito E Greco (1,N) Consulente di Facoltà (1,N) Confraternita Dei greci (1,N) Consulente di Facoltà (1,N) Confraternita Dei greci Schema Concettuale Schema Logico 9 Ing. Damiano Fanelli

11 Gerarchia di generalizzazione modellata stabilendo una relazione tra super-entity e sub-entity (punto 3) Questa soluzione è la più generale di tutte e tre ed è applicabile in tutti i casi che possono presentarsi. In questo caso ogni entità mantiene i suoi attributi e le proprie chiavi primarie, però occorre stabilire delle relazioni tra la super-entity e tutte le sub-entity: Progetto Cod Progetto Progetto (1, N) (1, N) Ha Membri progetto Software Hardware Subappalto Linguaggio Piattaforma Usa (1, N) Imporenditore Principale (0, N) Componenti Hardware Schema Concettuale Progetto Cod Progetto Progetto (1, N) (1, N) Ha Membri progetto (0, 1) (0, 1) (0, 1) Ha_Software Ha_Hardware Ha_Subappalto (1, 1) Piattaforma (1, 1) (1, 1) Software Hardware Subappalto (1, N) Linguaggio Usa Imporenditore Principale (0, N) Componenti Hardware Schema Logico 10 Ing. Damiano Fanelli

12 Modello relazionale Progettazione dello schema fisico Il modello relazionale è stato proposto per la prima volta da Edgar F. Codd, per gestire in modo semplice le interrogazioni sulle basi di dati. Lentamente, ma continuamente questo modello si è affermato come strumento principale per la gestione delle basi di dati. Il modello relazionale dei dati è semplice, potente e rappresenta un metodo formale per la rappresentazione della realtà di interesse. Esso fornisce una solida base che permette di risolvere molti problemi relativi alla gestione delle basi di dati, come per esempio la ridondanza delle informazioni, la distribuzione del DB ed altro, in modo formale e preciso. Il formalismo e le basi matematiche sono il supporto scientifico per lo sviluppo della teoria dei database relazionali. L elemento base del modello è la Relazione (Tabella) e lo schema di un database relazionale è una collezione di relazioni. Lo schema di ogni relazione è una aggregazione di informazioni, ciascuna delle quali appartiene ad uno stesso dominio (i domini sono ad esempio le date di nascita, nomi delle città ecc..) Nota: nello schema fisico il termine Relazione non ha lo stesso significato che ha nel modello E/R che abbiamo già visto. Qui il termine relazione è sinonimo di tabella fisica del data base. Una relazione, è una Tabella con righe e colonne, le colonne corrispondono agli attributi della tabella, mentre le righe sono una collezione di attributi, chiamate tuple, oppure record. Il grado di una tabella è dato dal numero di colonne della tabella, mentre la cardinalità è data dal numero di righe della tabella. Schema: STUDENTE(, Età, Sesso ) NOME ETA SESSO John Smith 19 M Sally Boyce 26 F Tom Hagen 22 M Bill Ballucci 28 M 11 Ing. Damiano Fanelli

13 Nell esempio abbiamo che il grado è 3, mentre la cardinalità è 4. Nel modello relazionale, il concetto di chiave è definito nello stesso modo del concetto di identificatore del modello E/R. Una chiave in una tabella è un insieme di attributi della tabella che unicamente identificano ogni tupla (record ) nella tabella stessa. Questa è chiamata chiave primaria della tabella. Lo scopo delle chiavi primarie è quello di identificare in maniera univoca i record della tabella. La semplicità del modello relazionale deriva dal fatto che tutte le tabelle sono definite in modo indipendente l una dall altra, non esiste il concetto di gerarchia o connessione o link tra una tabella e l altra del modello. Comunque le corrispondenze (relazioni come nel modello E/R) tra una tabella e l altra viene fatta attraverso il concetto di equi-join, cioè il collegamento tra gli attributi di una tabella e gli attributi di un altra tabella, lo vedremo per bene nel linguaggio SQL. Vincoli di integrità I vincoli di integrità sullo schema relazionale, rappresentano delle proprietà che devono essere soddisfatte sulle istanze delle basi di dati. Ogni vincolo può essere visto come un predicato che può assumere il valore vero o falso. Se la proprietà è vera, allora il vincolo è soddisfatto, altrimenti non è soddisfatto. Le istanze della base di dati per cui il vincolo è soddisfatto saranno ritenute valide, le altre no. Vincolo di integrità sulla tabella Questo vincolo afferma che nessuna chiave primaria può avere valore nullo (NULL Value), questo perché, se più record hanno il valore null, questi non possono essere più identificati. Vincolo di integrità referenziale sulla tabella Questo vincolo è definito tra due tabelle, ed è usato per mantenere la consistenza tra le righe delle due tabelle. Informalmente il vincolo di integrità referenziale afferma che un record in una tabella deve riferirsi ad uno o più record di un altra tabella. 12 Ing. Damiano Fanelli

14 Vediamo adesso la traslazione delle relazioni dello schema concettuale in tabelle dello schema fisico, partendo dalle relazioni uno a uno, uno a molti e molti a molti. Il processo di traslazione è anche influenzato dalla cardinalità minima della relazione. Traslazione di relazioni Uno a Uno Le due entità partecipano nella relazione separatamente, altrimenti le avremmo potuto fondere in una sola entità. Adesso, dobbiamo distinguere se la partecipazione delle entità nella relazione è totale o parziale. Abbiamo quindi i due casi: 1. Collassare le due entità in una sola tabella. Questa opzione è valida quando la partecipazione delle due entità nella relazione è totale a. Caso 1: Entrambe le entità hanno la stessa chiave primaria. In questo caso le due entità sono fuse in una sola entità con gli attributi di tutte e due le entità di provenienza e includendo la chiave primaria una volta sola. Codice_Cliente Indirizzo Codice_Cliente Indirizzo Codice_Cliente CLIENTE (1,1) (1,1) CON SPEDIZIONI CLIENTE_SPEDIZIONI CLIENTE_SPEDIZIONI( CODICE_CLIENTE, NOME, INDIRIZZO ) NOME b. Caso 2: Le due entità hanno differente chiave primaria. Anche in questo caso le due entità vengono collassate in una sola entità con gli attributi di entrambe le entità di origine, comprese le chiavi primarie di entrambe le entità considerate come attributi semplici (no chiavi). Per quanto riguarda la chiave primaria, possiamo scegliere arbitrariamente una sola delle due chiavi primarie. Codice_Cliente Indirizzo Codice_Spedizione Indirizzo Codice_Cliente CLIENTE (1,1) (1,1) CON SPEDIZIONI CLIENTE_SPEDIZIONI NOME Codice_Spedizione CLIENTE_SPEDIZIONI( CODICE_CLIENTE, NOME, INDIRIZZO, CODICE_SPEDIZIONE ) 13 Ing. Damiano Fanelli

15 2. Definizione di tabelle separate. Questa opzione è valida quando una o entrambe le relazioni hanno una partecipazione parziale UOMINI_CF DATA DURATA NOME DONNE_CF UOMINI (0,1) (0, 1) SPOSATI DONNE UOMINI( UOMINI_CF, NOME ) DONNE( DONNE_CF, NOME ) SPOSATI( UOMINI_CF, DONNE_CF, DATA, DURATA ) Traslazione di relazioni Uno a Molti Consideriamo due entità E1 e E2 e la relazione tra esse è uno a molti. Allora le tabelle (schema fisico ) sono ottenute includendo la chiave primaria di E2 (lato molti) nella tabella corrispondente ad E1 (lato uno) come chiave secondarie. Due casi sono possibili: 1. L entità dalla parte molti ha partecipazione obbligatoria. POPOLAZIONE NOME PRESIDENTE NOME_STATO CITTA (1, 1) (1, N) APPARTIENE STATO CITTA( NOME, NOME_STATO, POPOLAZIONE) STATO( NOME_STATO, PRESIDENTE ) 2. L entità dalla parte molti ha partecipazione parziale. TELEFONO NOME SCONTO DATA NUM_ORDINE COMMESSO (0, N) PREPARA (1, 1) ORDINI COMMESSO( NOME, TELEFONO ) ORDINI(NUM_ORDINE, DATA, NOME_COMMESSO ) 14 Ing. Damiano Fanelli

16 Se realizziamo una traslazione come nella fig. precedente, possiamo avere un numero molto grande di valori NULL, in quanto la partecipazione di COMMESSO nella relazione è parziale. Per evitare questo, si usa il seguente schema (è il caso più generale ): COMMESSO( NOME, TELEFONO ) ORDINI(NUM_ORDINE, DATA ) PREPARA( NUM_ORDINE, NOME_COMMESSO, SCONTO) Traslazione di relazioni Molti a Molti Per le relazioni molti a molti, la soluzione non dipende dalla cardinalità minima delle relazioni. NOME MATRICOLA SEMESTRE NOME_CORSO NUM_CORSO STUDENTI (1, N) INSCRITTI (1, N) CORSO STUDENTI( MATRICOLA, NOME ) CORSO(NUM_CORSO, NOME_CORSO ) ISCRITTI(MATRICOLA_STUDENTE, NUM_CORSO, SEMESTRE ) Per le relazioni ternarie abbiamo: DESCRIZIONE CODICE_PARTE QUANTITA NOME COD_PRODOTTO PARTI (1, N) FORNITURA (1, N) PRODOTTI FORNITORE (1, N) COD_FORNITORE DESCRIZIONE TEL NOME PRODOTTI( COD_PRODOTTO, NOME, DESCRIZIONE) PARTI( CODICE_PARTE, DESCRIZIONE ) FORNITORE(CODICE_FORNITORE, NOME, TEL ) FORNITURA(CODICE_PARTE, CODICE_FORNITORE, COD_PRODOTTO, QUANTITA ) FINE (per adesso. ) 15 Ing. Damiano Fanelli