Progettazione concettuale usando il modello Entità-Relazione (ER)

Transcript

1 Progettazione concettuale usando il modello Entità-Relazione (ER) 1

2 Introduzione alla progettazione delle basi di dati Progettazione concettuale (in questa fase si usa il modello ER) Quali sono le entità e le relazioni dell organizzazione? Quali informazioni su queste entità e relazioni dovrebbero essere memorizzate nella base di dati? Quali sono i vincoli di integrità o le business rules in vigore? Uno schema di base di dati nel modello ER può essere rappresentato graficamente (diagrammi ER) Si può tradurre un diagramma ER in uno schema relazionale Raffinamento dello schema (normalizzazione): controllo dello schema relazionale per trovare ridondanze e relative anomalie Progettazione fisica e ulteriore raffinamento dello schema: si considerano il carico di lavoro e le prestazioni del sistema per effettuare ulteriori modifica sullo schema 2

3 Introduzione alla progettazione delle basi di dati Il progetto di una base di dati ha dunque tre fasi: Progettazione Concettuale. Output: Schema concettuale esprimibile tramite il modello ER Progettazione Logica Output: Schema logico esprimibile tramite modello relazionale Progettazione Fisica Output: Schema fisico esprimibile tramite modello relazionale 3

4 Introduzione alla progettazione delle basi di dati Schema concettuale, logico e fisico: Schema concettuale Rappresentazione del dominio dell applicazione e di cosa rappresentare nella base di dati Schema logico Definisce l organizzazione dei dati secondo un modello logico (relazionale) Schema fisico Schema logico con scelte connesse al carico implementativo ed alla tecnologia di supporto 4

5 Costrutti fondamentali del modello Entità-Relazione Entità Attributi di entità Relazioni Attributi di relazione Ruoli Vincoli di cardinalità IS-A e Generalizzazioni Altri vincoli 5

6 ER e UML I costrutti del modello ER sono analoghi a quelli usati in altri modelli concettuali, ad esempio i diagrammi delle classi di UML Entità Relazioni Attributi Cardinalità ER IS-A e Generalizzazioni Classi UML Associazioni/aggregazioni Attributi Cardinalità IS-A e Generalizzazioni Identificatori Operazioni Il modello ER è specializzato alla rappresentazione dei dati 6

7 Basi del modello ER: Entità e Attributi Entità: insieme di oggetti del mondo reale Una entità è descritta da un insieme di attributi Ogni entità ha una chiave Ciascun attributo ha un dominio (tipicamente non rappresentato) attributo/dominio Cf/stringa Nome/stringa PP/intero chiave Impiegati entità 7

8 Entità e istanze d entità Una entità (nello schema concettuale S) denota un insieme (o classe) di oggetti simili Una istanza dell entità (in una istanza di S) denota un oggetto dell insieme rappresentato dall entità Nota: nello schema concettuale rappresentiamo le entità, non le singole istanze ( astrazione ) 8

9 Entità e istanze d entità Se un entità E possiede un attributo A, allora tutte le istanze di E devono avere un valore per A (del dominio di A) Livello intensionale (entità) Livello estensionale (istanze di entità) Cf/stringa Nome/stringa PP/intero <123,Mario,7> <456,Marco,10> Impiegati <789,Anna,9> 9

10 Esempio di traduzione di entità Si può tradurre facilmente un entità in una tabella relazionale cf nome Impiegati pp CREATE TABLE Impiegati (cf CHAR(15), nome CHAR(20), pp INTEGER, PRIMARY KEY (cf)) 10

11 Relazione Una relazione (o associazione) si definisce su due o più entità, e rappresenta un legame fra tali entità. Il numero di entità coinvolte in una relazione determina il suo grado Esempi Residenza (tra Persona e Città) Afferenza (tra Impiegato e Dipartimento) 11

12 Relazione nome dal rnome cf pp rid budget Impiegati Lavora_In Reparti Ogni relazione ha un nome che la identifica in modo univoco nello schema, ed è rappresentata nel diagramma che descrive lo schema da un rombo collegato alle entità sulle quali è definita la relazione Un istanza di una relazione R che collega E1 ed E2 (relazione binaria) è un sottoinsieme del prodotto cartesiano delle istanze di E1 ed E2, ovvero istanze(r) istanze(e1) istanze(e2) 12

13 Relazione nome dal rnome cf pp rid budget Impiegati Lavora_In Reparti Una relazione è n-aria se coinvolge n entità Un entità può essere coinvolta in più di una relazione Una relazione può avere degli attributi 13

14 Relazione: Ruoli cf nome pp Impiegati subordinato supervisore Dipende_da Problema: nell istanza dell associazione Dipende_da chi è l impiegato subordinato e chi il supervisore? Nelle relazioni che coinvolgono una stessa entità necessità di specificare i ruoli Il ruolo di un istanza di un entità in una relazione è un etichetta che permette di dirimere ambiguità 14

15 Esempio di traduzione di relazione Nel tradurre una relazione ER in una tabella relazionale, gli attributi della tabella devono includere: chiavi per ciascun insieme di entità partecipante (come chiavi esterne) questo insieme di attributi forma la superchiave per la relazione tutti gli attributi descrittivi CREATE TABLE Lavora_In( cf CHAR(15), rid INTEGER, dal DATE, PRIMARY KEY (cf, rid), FOREIGN KEY (cf) REFERENCES Impiegati, FOREIGN KEY (rid) REFERENCES Reparti) 15

16 Vincoli di cardinalità I vincoli di cardinalità definiscono il massimo (minimo) numero di istanze della relazione cui partecipa una istanza dell entità Persona Cardinalità massima (1,1) (1,n) Vive Città Cardinalità minima Nota: cardinalità graficamente invertite rispetto ad UML 16

17 Cardinalità maggiormente utilizzate Le cardinalità di interesse sono tipicamente tre: 0, 1, n. Per la cardinalità minima: 0 significa partecipazione opzionale 1 significa partecipazione obbligatoria Per la cardinalità massima: 1 significa: l entità partecipa al più una volta sola alla relazione n significa: l entità partecipa un numero qualsiasi di volte alla relazione La mancanza del vincolo di cardinalità è equivalente alla coppia (0,n) 17

18 Vincoli di cardinalità 1-a-1 1-a-Molti Molti-a-1 Molti-a-molti 18

19 Vincoli di chiave Vincolo di chiave su Dirige: un reparto ha al più un direttore nome dal rnome cf pp rid budget Impiegati Dirige Reparti Vincolo di chiave 19

20 Traduzione dei diagrammi ER con vincoli di chiave Tradurre una relazione in una tabella: notate che adesso la chiave è rid! separare le tabelle per Impiegati e Reparti Poiché ciascun reparto ha un unico direttore, possiamo invece combinare Dirige e Reparti CREATE TABLE Dirige( cf CHAR(15), rid INTEGER, dal DATE, PRIMARY KEY (rid), FOREIGN KEY (cf) REFERENCES Impiegati, FOREIGN KEY (rid) REFERENCES Reparti) CREATE TABLE Rep_Dir( Rid INTEGER, Rnome CHAR(20), Budget REAL, Cf CHAR(15), Dal DATE, PRIMARY KEY (rid) FOREIGN KEY (cf) REFERENCES Impiegati) 20

21 Vincoli di partecipazione C è un direttore per ogni reparto? Se sì, questo è un vincolo di partecipazione: la partecipazione di Reparti in Dirige viene detta totale (piuttosto che parziale) Ogni valore rid nella tabella Reparti deve apparire in una riga della tabella Dirige (con un valore di cf non nullo!) nome dal rname cf pp rid budget Impiegati Dirige Reparti Lavora_In T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. dal2011/2012, Sapienza Università di Roma 21

22 Vincoli di partecipazione in SQL Possiamo catturare i vincoli di partecipazione che coinvolgono un entità in una relazione binaria, ma poche altre cose (senza ricorrere a vincoli CHECK) CREATE TABLE Rep_Dir( Rid INTEGER, Rnome CHAR(20), Budget REAL, Cf CHAR(15) not null, Dal DATE, PRIMARY KEY (rid), FOREIGN KEY (cf) REFERENCES Impiegati, ON DELETE NO ACTION) 22

23 cf nome pp Aggregazione Impiegati Usata quando dobbiamo modellare una relazione che coinvolge (insiemi di entità e) un insieme di relazioni L aggregazione ci permette di trattare un insieme di relazioni come un insieme di entità allo scopo di permetterne la partecipazione in (altre) relazioni Controllori è tradotta con una tabella come qualunque altro insieme di relazioni pid Iniziato_il Progetti Controllori pbudget Sponsors Aggregazione verso Relazione ternaria: Controllori è una relazione distinta, con un attributo descrittivo Inoltre, possiamo dire che ogni sponsorizzazione è monitorata da al più un impiegato rid Fino_al rnome Reparti budget 23

24 Entità deboli Una entità debole può essere indentificata univocamente solo considerando la chiave primaria di un altra entità (proprietario) L insieme di entità proprietarie e l insieme di entità deboli devono partecipare in un insieme di relazioni uno-a-molti (1 proprietario, molte entità deboli) L insieme di entità deboli deve avere partecipazione totale in questo insieme di relazioni identificanti nome cf pp costo pnome età Impiegati Polizza Familiari 24

25 Traduzione di insiemi di entità deboli Un insieme di entità deboli e l insieme di relazioni identificanti sono tradotte in una tabella singola Quando l entità proprietaria viene cancellata, anche tutte le sue entità deboli devono essere cancellate CREATE TABLE Polizza_familiari( pnome CHAR(20), età INTEGER, costo REAL, cf CHAR(15) NOT NULL, PRIMARY KEY (pnome, cf) FOREIGN KEY (cf) REFERENCES Impiegati, ON DELETE CASCADE) 25

26 Relazione ISA Se dichiariamo E1 ISA E2, ogni istanza dell entità E1 è anche un istanza dell entità E2 La relazione ISA si rappresenta nel diagramma dello schema concettuale mediante una freccia dalla sottoentità alla entità padre Persona ISA Studente Si dice che Studente è in relazione ISA con Persona, o, in alternativa, che Studente ISA Persona 26

27 Relazione ISA Una entità può avere al massimo una entità padre. In altre parole, il modello ER non ammette ereditarietà multipla Esempio Studente Lavoratore ISA ISA StudenteLavoratore Questo schema è scorretto 27

28 Relazione ISA Una entità può avere ovviamente diverse entità figlie Le istanze di due entità che sono figlie della stessa entità possono avere istanze in comune Questo significa che, al contrario di UML, nel modello ER uno stesso oggetto può essere istanza di diverse classi più specifiche Persona ISA Studente ISA Lavoratore Studente Persona Lavoratore 28

29 Generalizzazione La relazione ISA che stabilisce che l entità padre è più generale della sottoentità Talvolta, però, l entità padre può generalizzare diverse sottoentità rispetto ad un unico criterio. In questo caso si parla di generalizzazione. Una generalizzazione può essere di due tipi: Completa: l unione delle istanze delle sottoentità è uguale all insieme delle istanze dell entità padre Non completa 29

30 Generalizzazione Livello intensionale Livello estensionale non completa C C A B A B completa C C A B A B 30

31 ISA e generalizzazioni tra relazioni La relazione ISA può essere definita anche tra relazioni, ma con la seguente regola: si può definire la relazione ISA tra la relazione R (relazione figlia) e la relazione Q (relazione padre) in uno schema S solo se R e Q hanno lo stesso grado hanno gli stessi ruoli per ogni ruolo U, l entità corrispondente ad U in R è una entità figlia dell entità corrispondente ad U in Q Analogamente, si possono definire generalizzazioni tra relazioni 31

32 Esempio di relazione ISA tra relazioni Il direttore di un dipartimento deve lavorare in quel dipartimento Persona Lavora Dipartimento ISA Dirige 32

33 Traduzione Gerarchie ISA cf nome pp Impiegati Paghe_orarie Ore_lavorate ISA idcontratto Imp_A_Ore Imp_A_Contratto 33

34 Traduzione delle gerarchie ISA in tabelle relazionali Approccio generale: 3 relazioni: Impiegati, Imp_A_Ore e Imp_A_Contratto Imp_A_Ore: ogni impiegato è registrato in Impiegati. Per gli impiegati a ore, informazioni aggiuntive sono registrate in Imp_A_Ore (paghe_orarie, ore_lavorate, CF); bisogna cancellare le tuple di Imp_A_Ore se viene cancellata la relativa tupla di Impiegati Le interrogazioni che coinvolgono tutti gli impiegati sono facili, quelle che coinvolgono solo Imp_A_Ore richiedono un join per leggere alcuni attributi Alternativa: solo Imp_A_Ore e Imp_A_Contratto Imp_A_Ore: cf, nome, pp, paghe_orarie, ore_lavorate Ciascun impiegato deve appartenere a una di queste due sottoclassi 34