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/2006 2 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/2006 3 03/04/2006 4 1
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/2006 5 03/04/2006 6 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/2006 7 03/04/2006 8 2
Requisiti della base di dati Progettazione concettuale COME : progettazione Schema concettuale Progettazione logica Schema logico Progettazione fisica CHE COSA : analisi Schema fisico 03/04/2006 9 I prodotti della varie fasi sono schemi di alcuni modelli di dati: Schema concettuale Schema logico Schema fisico 03/04/2006 10 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/2006 11 03/04/2006 12 3
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/2006 13 03/04/2006 14 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/2006 15 03/04/2006 16 4
Progettazione concettuale Progettazione Concettuale Progettazione logica Progettazione fisica 03/04/2006 17 03/04/2006 18 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/2006 19 03/04/2006 20 5
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/2006 21 03/04/2006 22 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/2006 23 03/04/2006 24 6
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/2006 25 03/04/2006 26 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/2006 27 03/04/2006 28 7
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/2006 29 03/04/2006 30 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/2006 31 03/04/2006 32 8
Due relationship sulle stesse entità Relationship n-aria Sede di lavoro Fornitore Fornitura Prodotto Impiegato Residenza Città Dipartimento 03/04/2006 33 03/04/2006 34 Relationship ricorsiva: coinvolge due volte la stessa entità Relationship ricorsiva con ruoli Conoscenza Successione Persona Successore Sovrano Predecessore 03/04/2006 35 03/04/2006 36 9
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/2006 37 03/04/2006 38 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/2006 39 03/04/2006 40 10
Rappresentazione grafica Cognome Direzione Telefono Cognome Impiegato Codice Afferenza Dipartimento Nome Impiegato Età Via Partecipazione Composizione Indirizzo Numero CAP 03/04/2006 41 Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/2006 42 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/2006 43 03/04/2006 44 11
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/2006 45 03/04/2006 46 Occorrenze di Residenza Cardinalità di Residenza R1 S1 C1 S2 C2 S3 R2 S4 R3 R4 C3 C4 Studente Città 03/04/2006 47 (1,1) (0,N) Studente Residenza Città 03/04/2006 48 12
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/2006 49 03/04/2006 50 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/2006 51 03/04/2006 52 13
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/2006 53 03/04/2006 54 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/2006 55 03/04/2006 56 14
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/2006 57 03/04/2006 58 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/2006 59 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/2006 60 15
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/2006 61 03/04/2006 62 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/2006 63 03/04/2006 64 16
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/2006 65 03/04/2006 66 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/2006 67 03/04/2006 68 17
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/2006 69 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/2006 70 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/2006 71 03/04/2006 72 18
Progettazione Logica Progettazione concettuale Requisiti della base di dati Schema concettuale 03/04/2006 73 Progettazione logica Schema logico Progettazione fisica Schema fisico 03/04/2006 74 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/2006 75 03/04/2006 76 19
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/2006 77 03/04/2006 78 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/2006 79 Attività di Traduzione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari 03/04/2006 80 20
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/2006 81 03/04/2006 82 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/2006 83 03/04/2006 84 21
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/2006 85 03/04/2006 86 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/2006 87 03/04/2006 88 22
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/2006 89 03/04/2006 90 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/2006 91 03/04/2006 92 23
Nome Agenzia Indirizzo Città Città Nome (1,1) Agenzia Utenza Numero Telefono Telefono Indirizzo 03/04/2006 93 03/04/2006 94 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/2006 95 03/04/2006 96 24
acquisto Ruolo Giocatore Cognome Composizione acquisto (0,1) cessione Città Squadra Nome 03/04/2006 97 Ruolo Giocatore Cognome (1,1) Comp. attuale acquisto Comp. passata cessione Squadra Nome Città 03/04/2006 98 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/2006 99 03/04/2006 100 25
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/2006 101 03/04/2006 102 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/2006 103 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/2006 104 26
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/2006 105 Composto Componente Prodotto Costo Nome Codice Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) 03/04/2006 106 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/2006 107 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/2006 108 27
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/2006 109 Cognome Studente Matricola AnnoDiCorso (1,1) Iscrizione Nome Indirizzo Città Università Studente(Matricola, Università, Cognome, AnnoDiCorso) Università(Nome, Città, Indirizzo) con vincolo 03/04/2006 110 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/2006 111 03/04/2006 112 28
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/2006 113 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/2006 114 Schema finale Impiegato(Codice, Cognome, Dipartimento*, *) Dipartimento(Nome, Città, Telefono, Direttore) Sede(Città, Via, CAP) Progetto(Nome, Budget) Partecipazione(Impiegato, Progetto) 03/04/2006 115 29