Traduzione. Scelta degli identificatori principali

Transcript

1 Scelta degli identificatori principali E molto importante per l importanza rivestita dalle chiavi nel modello relazionale Bisogna scegliere una chiave principale secondo i seguenti criteri: Escludere gli attributi con valori nulli Preferire identificatori con pochi attributi Preferire identificatori interni rispetto ad identificatori esterni Utilizzare identificatori che vengono utilizzati da molte operazioni per accedere alle occorrenze di una entità Se nessun identificatore soddisfa i criteri, è consigliabile crearne uno (codice identificativo) Una volta riorganizzato lo schema si può passare alla traduzione dal modello E-R a quello relazionale di associazioni molti a molti Tipicamente, passando dal modello E-R a quello relazionale, si procede nel modo seguente: ogni entità diventa una relazione sugli attributi dell entità ogni associazione diventa una relazione definita sugli attributi dell associazione più gli identificatori delle entità coinvolte, che costituiranno la chiave della relazione Si instaura un vincolo di integrità referenziale fra gli identificatori delle entità coinvolte e i corrispondenti attributi dell associazione In alcuni casi (es associazioni ricorsive) è necessario ridenominare gli attributi con vincoli di integrità referenziale fra Matricola in Partecipazione e la chiave di Impiegato Codice in Partecipazione e la chiave di Progetto 1

2 Associazioni n-arie Partita IVA Genere Codice di associazioni uno a molti (0,N) Fornitura Dipartimento Telefono In questo caso si possono tradurre sia l associazione che l entità per la quale l associazione può applicarsi una sola volta in un unica relazione (tabella) La chiave sarà l identificatore dell entità Es giocatore, squadra e contratto: ogni giocatore può avere un solo contratto, quindi il concetto di contratto viene associato (inglobato) in quello di giocatore (PartitaIVA, ) (Codice, Genere) Dipartimento(, Telefono) Fornitura(,, Dipartimento, ) Si instaura un vincolo di integrità referenziale fra la chiave della relazione (es squadra) che può avere occorrenza N nell associazione e il corrispondente attributo della relazione che traduce sia l altra entità che l associazione di entità con identificatore esterno Poiché un entità identificata esternamente tramite un associazione partecipa all associazione con cardinalità minima e massima pari ad uno, si ricade nel caso precedente della relazione uno a molti L associazione e l entità che la utilizza per avere un identificatore esterno vengono tradotti con la stessa relazione Es Meglio (più compatto): Giocatore (Cognome, Nasc, Ruolo, Squadra, Ingaggio) Squadra (, Città, ColoriSociali) con vincolo di integrità referenziale fra Squadra in Giocatore e la chiave di Squadra Se la cardinalità minima della relazione è 0, allora Squadra in Giocatore deve ammettere valore nullo 2

3 di associazioni uno a uno Se la partecipazione è obbligatoria per entrambe le entità, si può operare come nella traduzione delle associazioni uno a molti, però possiamo scegliere quale entità tradurre in una stessa relazione insieme all associazione Se è opzionale per una sola entità, è preferibile scegliere di effettuare la fusione in modo da non avere valori nulli, inglobando quindi l associazione nell entità con partecipazione obbligatoria Se è opzionale per entrambe, con una traduzione mediante 3 relazioni separate si può evitare la presenza di valori nulli In termini di procedura globale, se si devono tradurre schemi complessi, si può procedere per gradi: traduzione delle entità traduzione delle entità con identificazioni esterne traduzione delle associazioni rimaste (alcune sono già state tradotte al punto precedente) Progettare una base di dati che permetta di gestire il problema descritto nel seguito, nei seguenti punti: 1 Definire uno schema Entità/Relazione che descriva il problema 2 Definire uno schema logico secondo il modello relazionale, derivato da una ristrutturazione, se necessaria, del diagramma E/R, esteso con gli eventuali vincoli necessari a garantire la consistenza della base di dati Un negozio di elettrodomestici vende diversi prodotti, ciascuno dei quali ha alcune caratteristiche descrittive in comune con gli altri (prezzo di acquisto, marca, dimensioni, prezzo di vendita, data di vendita) ma, in funzione del tipo, ha anche caratteristiche specifiche La base di dati deve quindi consentire di gestire diverse categorie di prodotti e, quindi, di associare loro le rispettive caratteristiche Il negozio ha un solo fornitore per ogni componente (ma può comprare più componenti dallo stesso fornitore) Inoltre ha un anagrafe clienti che permette di stabilire, a fine anno, l importo di un buono acquisto da offrire in omaggio a ciascuno di essi, di valore pari al 2% del valore degli acquisti che quest ultimo ha fatto durante l anno Un negozio di elettrodomestici vende diversi prodotti, ciascuno dei quali ha alcune caratteristiche descrittive in comune con gli altri (prezzo di acquisto, marca, dimensioni, prezzo di vendita, data di vendita) ma ha anche caratteristiche specifiche La base di dati deve quindi consentire di gestire diverse categorie di prodotti e, quindi, di associare loro le rispettive caratteristiche Il negozio ha un solo fornitore per ogni prodotto (ma può comprare più prodotti dallo stesso fornitore) Inoltre ha un anagrafe clienti che permette di stabilire, a fine anno, l importo di un buono acquisto da offrire in omaggio a ciascuno di essi, di valore pari al 2% del valore degli acquisti che quest ultimo ha fatto durante l anno 3

4 Entità Marca Modello Dim Relazioni vendita acquisto Schema scheletro Premio annuale vendita Marca Modello Dim acquisto (1,1) Anno NB La relazione è di tipo molti a molti in quanto un prodotto può essere acquistato più volte in date diverse Esiste anche una relazione 1:N tra e, logicamente distinta dall acquisto, che potrebbe ad es chiamarsi Fornitura Generalizzazioni Eliminazione generalizzazioni e attributi multivalore CF Marca Modello Marca Modello Dim Codice PI Specifica 1 2 N C 11 C 12 C 1n C 21 C 22 C 2n C N1 C N2 C Nn Caratteristica 4

5 (1,1) Premio annuale PI CF Anno vendita acquisto Codice Marca Modello Specifica Caratteristica Schema logico (CF,, Cognome, Indirizzo, ) (PI,, Cognome, Indirizzo, ) (Codice, Marca, Modello, L, H, P,, PI) Specifica(Caratteristica, CodiceProd, ) (CodiceProd, CF, vendita,, ) (CodiceProd, PI, acquisto,, ) (, Anno, CF) Caratteristica() NB La tabella caratteristica è utile solo se si vuole imporre un vincolo di integrità referenziale fra Specificacaratteristica e Caratteristica 5