Progettazione di basi di dati. Progettazione di basi di dati: Progettazione Concettuale e Progettazione Logica. Fasi (tecniche) del ciclo di vita

Transcript

1 Progettazione di basi di dati Progettazione di basi di dati: Progettazione Concettuale e Progettazione Logica È una delle attività del processo di sviluppo dei sistemi informativi va quindi inquadrata in un contesto più generale: il ciclo di vita dei sistemi informativi: Insieme e sequenzializzazione delle attività svolte da analisti, progettisti, utenti, nello sviluppo e nell uso dei sistemi informativi attività iterativa, quindi ciclo 03/04/ Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento Fasi (tecniche) del ciclo di vita Studio di fattibilità: definizione costi e priorità Raccolta e analisi dei requisiti: studio delle proprietà del sistema Progettazione: di dati e funzioni Realizzazione Validazione e collaudo: sperimentazione Funzionamento: il sistema diventa operativo 03/04/ /04/

2 La progettazione di un sistema informativo riguarda due aspetti: progettazione dei dati progettazione delle applicazioni Ma: i dati hanno un ruolo centrale i dati sono più stabili Studio di fattibilità Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 03/04/ /04/ Studio di fattibilità Per garantire prodotti di buona qualità è opportuno seguire una metodologia di progetto, con: articolazione delle attività in fasi criteri di scelta modelli di rappresentazione generalità e facilità d'uso Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 03/04/ /04/

3 Requisiti della base di dati Progettazione concettuale COME : progettazione Schema concettuale Progettazione logica Schema logico Progettazione fisica CHE COSA : analisi Schema fisico 03/04/ I prodotti della varie fasi sono schemi di alcuni modelli di dati: Schema concettuale Schema logico Schema fisico 03/04/ Modello dei dati insieme di costrutti utilizzati per organizzare i dati di interesse e descriverne la dinamica componente fondamentale: meccanismi di strutturazione (o costruttori di tipo) come nei linguaggi di programmazione esistono meccanismi che permettono di definire nuovi tipi, così ogni modello dei dati prevede alcuni costruttori ad esempio, il modello relazionale prevede il costruttore relazione, che permette di definire insiemi di record omogenei Schemi e istanze In ogni base di dati esistono: lo schema, sostanzialmente invariante nel tempo, che ne descrive la struttura (aspetto intensionale) nel modello relazionale, le intestazioni delle tabelle l istanza, i valori attuali, che possono cambiare anche molto rapidamente (aspetto estensionale) nel modello relazionale, il corpo di ciascuna tabella 03/04/ /04/

4 Due tipi (principali)) di modelli Modelli concettuali, perché? modelli logici: utilizzati nei DBMS esistenti per l organizzazione dei dati utilizzati dai programmi indipendenti dalle strutture fisiche esempi: relazionale, reticolare, gerarchico, a oggetti modelli concettuali: permettono di rappresentare i dati in modo indipendente da ogni sistema cercano di descrivere i concetti del mondo reale sono utilizzati nelle fasi preliminari di progettazione il più noto è il modello Entity-Relationship Proviamo a modellare una applicazione definendo direttamente lo schema logico della base di dati: da dove cominciamo? rischiamo di perderci subito nei dettagli dobbiamo pensare subito a come correlare le varie tabelle (chiavi etc.) i modelli logici sono rigidi 03/04/ /04/ Modelli concettuali, perché? servono per ragionare sulla realtà di interesse, indipendentemente dagli aspetti realizzativi permettono di rappresentare le classi di dati di interesse e le loro correlazioni prevedono efficaci rappresentazioni grafiche (utili anche per documentazione e comunicazione) Architettura (semplificata)) di un DBMS utente Schema logico Schema interno BD 03/04/ /04/

5 Progettazione concettuale Progettazione Concettuale Progettazione logica Progettazione fisica 03/04/ /04/ Modello Entity-Relationship (Entità-Relazione) Il più diffuso modello concettuale Ne esistono molte versioni, (più o meno) diverse l una dall altra I costrutti del modello E-RE Entità Relationship Attributo Identificatore Generalizzazione. 03/04/ /04/

6 Entità Relationship Classe di oggetti (fatti, persone, cose) della applicazione di interesse con proprietà comuni e con esistenza autonoma Esempi: impiegato, città, conto corrente, ordine, fattura Legame logico fra due o più entità, rilevante nell applicazione di interesse Esempi: Residenza (fra persona e città) Esame (fra studente e corso) 03/04/ /04/ Uno schema E-R, E graficamente Entità: : schema e istanza Studente Esame Corso Entità: classe di oggetti, persone, "omogenei" Occorrenza (o istanza) di entità: elemento della classe (l'oggetto, la persona,, non i dati) nello schema concettuale rappresentiamo le entità, non le singole istanze ( astrazione ) 03/04/ /04/

7 Rappresentazione grafica di entità Entità,, commenti Impiegato Città Dipartimento Vendita Ogni entità ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare 03/04/ /04/ Relationship Rappresentazione grafica di relationship Legame logico fra due o più entità, rilevante nell applicazione di interesse Esempi: Residenza (fra persona e città) Esame (fra studente e corso) Studente Esame Corso Chiamata anche: relazione, correlazione, associazione Impiegato Residenza Città 03/04/ /04/

8 Relationship,, commenti Esempi di occorrenze Ogni relationship ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare sostantivi invece che verbi (se possibile) S1 S2 S3 S4 E1 E2 E4 E3 C1 C2 C3 Studente Corso 03/04/ /04/ Relationship,, occorrenze Relationship corrette? Una occorrenza di una relationship binaria è coppia di occorrenze di entità, una per ciascuna entità coinvolta Una occorrenza di una relationship n-aria è una n-upla di occorrenze di entità, una per ciascuna entità coinvolta Nell'ambito di una relationship non ci possono essere occorrenze (coppie, ennuple) ripetute Studente Paziente Esame Visita Corso Medico 03/04/ /04/

9 Due relationship sulle stesse entità Relationship n-aria Sede di lavoro Fornitore Fornitura Prodotto Impiegato Residenza Città Dipartimento 03/04/ /04/ Relationship ricorsiva: coinvolge due volte la stessa entità Relationship ricorsiva con ruoli Conoscenza Successione Persona Successore Sovrano Predecessore 03/04/ /04/

10 Relationship ternaria ricorsiva Attributo Superficie Proprietà elementare di un entità o di una relationship, di interesse ai fini dell applicazione Migliore Confronto Peggiore Associa ad ogni occorrenza di entità o relationship un valore appartenente a un insieme detto dominio dell attributo Tennista 03/04/ /04/ Attributi, rappresentazione grafica Attributi composti Cognome Nome Voto Titolo Raggruppano attributi di una medesima entità o relationship che presentano affinità nel loro significato o uso Studente Esame Corso Esempio: Via, Numero civico e CAP formano un Indirizzo Matricola Codice 03/04/ /04/

11 Rappresentazione grafica Cognome Direzione Telefono Cognome Impiegato Codice Afferenza Dipartimento Nome Impiegato Età Via Partecipazione Composizione Indirizzo Numero CAP 03/04/ Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/ Altri costrutti del modello E-RE Cardinalità di relationship di attributo Identificatore interno esterno Generalizzazione Cardinalità di relationship Coppia di valori associati a ogni entità che partecipa a una relationship specificano il numero minimo e massimo di occorrenze delle relationship cui ciascuna occorrenza di una entità può partecipare 03/04/ /04/

12 Impiegato Esempio di cardinalità (1,5) (0,50) Assegnamento Incarico per semplicità usiamo solo tre simboli: 0 e 1 per la cardinalità minima: 0 = partecipazione opzionale 1 = partecipazione obbligatoria 1 e N per la massima: N non pone alcun limite 03/04/ /04/ Occorrenze di Residenza Cardinalità di Residenza R1 S1 C1 S2 C2 S3 R2 S4 R3 R4 C3 C4 Studente Città 03/04/ (1,1) (0,N) Studente Residenza Città 03/04/

13 Tipi di relationship Due avvertenze Con riferimento alle cardinalità massime, abbiamo relationship: uno a uno uno a molti molti a molti Attenzione al "verso" nelle relationship uno a molti le relationship obbligatorie-obbligatorie sono molto rare 03/04/ /04/ Relationship molti a molti Relationship uno a molti (0,N) (0,N) (0,1) (0,N) Studente Esame Corso Persona Impiego Azienda Montagna (0,N) Scalata Alpinista Cinema (1,1) (0,N) Ubicazione Località (1,1) Macchinista Abilitazione Locomotore Comune Ubicazione Provincia 03/04/ /04/

14 Relationship uno a uno Cardinalità di attributi Professore (0,1) (0,1) Titolarità Cattedra E possibile associare delle cardinalità anche agli attributi, con due scopi: Professore di ruolo (1,1) (0,1) Titolarità Cattedra indicare opzionalità ("informazione incompleta") indicare attributi multivalore Professore di ruolo (1,1) (1,1) Titolarità Cattedra coperta 03/04/ /04/ Rappresentazione grafica Identificatore di una entità Impiegato (0,N) (0,1) Telefono Nome Numero patente strumento per l identificazione univoca delle occorrenze di un entità costituito da: attributi dell entità identificatore interno (attributi +) entità esterne attraverso relationship identificatore esterno 03/04/ /04/

15 Identificatori interni Identificatore esterno Automobile Targa Modello Nascita Cognome Matricola (1,1) (0,N) Studente Iscrizione Nome Università Persona Cognome Indirizzo Nome Anno di corso Indirizzo 03/04/ /04/ Alcune osservazioni ogni entità deve possedere almeno un identificatore, ma può averne in generale più di uno una identificazione esterna è possibile solo attraverso una relationship a cui l entità da identificare partecipa con cardinalità (1,1) perché non parliamo degli identificatori delle relationship? 03/04/ Cognome (0,1) (1,1) Telefono Direzione Impiegato Dipartimento (0,1) (0,N) Afferenza Codice (0,N) (1,1) Nome (0,1) Partecipazione Composizione Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/

16 Generalizzazione mette in relazione una o più entità E1, E2,..., En con una entità E, che le comprende come caso particolare Rappresentazione grafica Dipendente E è generalizzazione di E1, E2,..., En E1, E2,..., En sono specializzazioni (o sottotipi) di E Impiegato Funzionario Dirigente 03/04/ /04/ Proprietà delle generalizzazioni Città Se E (genitore) è generalizzazione di E1, E2,..., En (figlie): ogni proprietà di E è significativa per E1, E2,..., En ogni occorrenza di E1, E2,..., En è occorrenza anche di E Stipendio (0,N) Nascita (1,1) Persona Codice fiscale Nome Età Lavoratore Studente 03/04/ /04/

17 Ereditarietà tutte le proprietà (attributi, relationship, altre generalizzazioni) dell entità genitore vengono ereditate dalle entità figlie e non rappresentate esplicitamente Esercizio Le persone hanno CF, cognome ed età; gli uomini anche la posizione militare; gli impiegati hanno lo stipendio e possono essere segretari, direttori o progettisti (un progettista può essere anche responsabile di progetto); gli studenti (che non possono essere impiegati) un numero di matricola; esistono persone che non sono né impiegati né studenti (ma i dettagli non ci interessano) 03/04/ /04/ CF Cognome Persona Stipendio Età Matr. Documentazione associata agli schemi concettuali Uomo Donna Impiegato Studente Militare Segretario Direttore Progettista dizionario dei dati entità relationship vincoli non esprimibili Responsabile 03/04/ /04/

18 Cognome (0,1) (1,1) Telefono Direzione Impiegato Dipartimento (0,1) (0,N) Afferenza Codice (0,N) (1,1) Nome (0,1) Partecipazione Composizione Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/ Dizionario dei dati (entità) Entità Descrizione Attributi Identificatore Impiegato Dipendente Codice, Codice dell'azienda Cognome, Stipendio Progetto Progetti aziendali Nome, Budget Nome Dipartimento Struttura aziendale Nome, Telefono Nome, Sede Sede Sede dell'azienda Città, Indirizzo Città 03/04/ Dizionario dei dati (relationship( relationship) Vincoli non esprimibili Relazioni Descrizione Componenti Attributi Direzione Direzione di un dipartimento Impiegato, Dipartimento Afferenza Afferenza a un Impiegato, dipartimento Dipartimento Partecipazione Partecipazione a un progetto Impiegato, Progetto Composizione Composizione dell'azienda Dipartimento, Sede Vincoli di integrità sui dati (1) Il direttore di un dipartimento deve a afferire a tale dipartimento (2) Un impiegato non deve avere uno stipendio maggiore del direttore del dipartimento al quale afferisce (3) Un dipartimento con sede a Roma deve essere diretto da un impiegato con più di dieci anni di anzianità (4) Un impiegato che non afferisce a nessun dipartimento non deve partecipare a nessun un progetto 03/04/ /04/

19 Progettazione Logica Progettazione concettuale Requisiti della base di dati Schema concettuale 03/04/ Progettazione logica Schema logico Progettazione fisica Schema fisico 03/04/ Obiettivo della progettazione logica "tradurre" lo schema concettuale in uno schema logico che rappresenti gli stessi dati in maniera corretta ed efficiente Dati di ingresso e uscita Ingresso: schema concettuale Uscita: schema logico documentazione associata D ora in poi. Per semplificare non ci occuperemo dell efficienza 03/04/ /04/

20 Non si tratta di una pura e semplice traduzione alcuni aspetti non sono direttamente rappresentabili Schema E-R Traduzione nel modello logico Schema logico 03/04/ /04/ Cognome (0,1) (1,1) Telefono Direzione Impiegato Dipartimento (0,1) Codice (0,N) Partecipazione Progetto Budget Nome Afferenza (1,1) Nome (0,1) Composizione Sede Via Indirizzo CAP Città 03/04/ Attività di Traduzione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari 03/04/

21 Eliminazione delle gerarchie il modello relazionale non può rappresentare direttamente le generalizzazioni entità e relazioni sono invece direttamente rappresentabili si eliminano perciò le gerarchie, sostituendole con entità e relazioni Tre possibilità 1. accorpamento delle figlie della generalizzazione nel genitore 2. accorpamento del genitore della generalizzazione nelle figlie 3. sostituzione della generalizzazione con relazioni 03/04/ /04/ A01 E0 A02 R1 E3 A01 (0,1) A11 E0 A21 (0,1) TIPO A02 R1 E3 E1 E2 R2 (0,..) R2 A11 A21 E4 E4 03/04/ /04/

22 A01 A02 R11 E0 R1 E3 R12 E3 E1 E2 R2 E1 E2 R2 A11 A21 E4 A01 A11 A02 A01 A21 A02 E4 03/04/ /04/ A01 A02 A01 A02 E0 R1 E3 E0 R1 E3 RG1 (0,1) (1,1) (0,1) (1,1) RG2 E1 E2 R2 E1 E2 R2 A11 A21 E4 A11 A21 E4 03/04/ /04/

23 Attività di Traduzione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari Ristrutturazioni, casi principali partizionamento verticale di entità partizionamento orizzontale di relationship eliminazione di attributi multivalore accorpamento di entità/ relationship 03/04/ /04/ Cognome Indirizzo nascita Codice Impiegato Livello Stipendio Ritenute Cognome Dati anagrafici Indirizzo Codice nascita (1,1) (1,1) R Stipendio Livello Dati lavorativi Ritenute 03/04/ /04/

24 Nome Agenzia Indirizzo Città Città Nome (1,1) Agenzia Utenza Numero Telefono Telefono Indirizzo 03/04/ /04/ Cognome Persona Codice fiscale (0,1) (1,1) Intestazione Interno Indirizzo Appartamento Cognome Indirizzo Codice fiscale Persona Interno (0,1) Indirizzo nascita nascita Indirizzo (0,1) 03/04/ /04/

25 acquisto Ruolo Giocatore Cognome Composizione acquisto (0,1) cessione Città Squadra Nome 03/04/ Ruolo Giocatore Cognome (1,1) Comp. attuale acquisto Comp. passata cessione Squadra Nome Città 03/04/ Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari Scelta degli identificatori principali operazione indispensabile per la traduzione nel modello relazionale Criteri assenza di opzionalità semplicità 03/04/ /04/

26 Se nessuno degli identificatori soddisfa i requisiti visti? Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per questo scopo Traduzione verso il modello relazionale idea di base: le entità diventano relazioni sugli stessi attributi le associazioni (ovvero le relazioni E-R) diventano relazioni sugli identificatori delle entità coinvolte (più gli attributi propri) 03/04/ /04/ Entità e relationship molti a molti Cognome Matricola inizio Codice Nome (0,N) Impiegato Partecipazione Progetto Stipendio Budget Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, Inizio) 03/04/ Entità e relationship molti a molti Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, Inizio) con vincoli di integrità referenziale fra Matricola in Partecipazione e (la chiave di) Impiegato Codice in Partecipazione e (la chiave di) Progetto 03/04/

27 Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Relationship ricorsive Quantità (0,N) (0,N) Composizione Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, Inizio) Partecipazione(Impiegato, Progetto, Inizio) 03/04/ Composto Componente Prodotto Costo Nome Codice Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) 03/04/ Nome Partita IVA Quantità Genere Codice Fornitore Relationship n-arie (0,N) Fornitura Dipartimento Prodotto Nome Telefono Fornitore(PartitaIVA, Nome) Prodotto(Codice, Genere) Dipartimento(Nome, Telefono) Fornitura(Fornitore, Prodotto, Dipartimento, Quantità) 03/04/ Cognome Ingaggio nascita Città Nome (1,1) (0,N) Giocatore Contratto Squadra Ruolo Relationship uno a molti Colori sociali Giocatore(Cognome, Nascita, Ruolo) Contratto(CognGiocatore, NascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) corretto? 03/04/

28 Soluzione più compatta Entità con identificazione esterna Giocatore(Cognome, Nascita, Ruolo) Contratto(CognGiocatore, NascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) Giocatore(Cognome, Nasc, Ruolo, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) con vincolo di integrità referenziale fra Squadra in Giocatore e la chiave di Squadra se la cardinalità minima della relationship è 0, allora Squadra in Giocatore deve ammettere valore nullo 03/04/ Cognome Studente Matricola AnnoDiCorso (1,1) Iscrizione Nome Indirizzo Città Università Studente(Matricola, Università, Cognome, AnnoDiCorso) Università(Nome, Città, Indirizzo) con vincolo 03/04/ Relationship uno a uno inizio Cognome Codice Sede Nome Una possibilità privilegiata inizio Cognome Codice Sede Nome (1,1) (1,1) (0,1) (1,1) Direttore Direzione Dipartimento Direttore Direzione Dipartimento Stipendio varie possibilità: fondere da una parte o dall'altra fondere tutto? Telefono Stipendio Telefono Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) con vincolo di integrità referenziale, senza valori nulli 03/04/ /04/

29 Un altro caso Cognome (0,1) (1,1) Direzione Telefono inizio Cognome Codice Sede Nome Direttore Stipendio (0,1) (0,1) Direzione Dipartimento Telefono 03/04/ Impiegato Dipartimento (0,1) Afferenza Codice (0,N) (1,1) Nome (0,1) Partecipazione Composizione Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/ Schema finale Impiegato(Codice, Cognome, Dipartimento*, *) Dipartimento(Nome, Città, Telefono, Direttore) Sede(Città, Via, CAP) Progetto(Nome, Budget) Partecipazione(Impiegato, Progetto) 03/04/