Progettazione di basi di dati: Progettazione Concettuale e Progettazione Logica

Transcript

1 Progettazione di basi di dati: Progettazione Concettuale e Progettazione Logica

2 Progettazione di basi di dati È 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

3 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento 03/04/2006 3

4 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 4

5 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 03/04/2006 5

6 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 03/04/2006 6

7 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 03/04/2006 7

8 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 03/04/2006 8

9 Progettazione concettuale COME : progettazione Requisiti della base di dati Schema concettuale Progettazione logica Schema logico Progettazione fisica CHE COSA : analisi Schema fisico 03/04/2006 9

10 I prodotti della varie fasi sono schemi di alcuni modelli di dati: Schema concettuale Schema logico Schema fisico 03/04/

11 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 03/04/

12 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/

13 Due tipi (principali)) di modelli 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 03/04/

14 Modelli concettuali, perché? 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/

15 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) 03/04/

16 Architettura (semplificata)) di un DBMS utente Schema logico Schema interno BD 03/04/

17 Progettazione concettuale Progettazione logica Progettazione fisica 03/04/

18 Progettazione Concettuale 03/04/

19 Modello Entity-Relationship (Entità-Relazione) Il più diffuso modello concettuale Ne esistono molte versioni, (più o meno) diverse l una dall altra 03/04/

20 I costrutti del modello E-RE Entità Relationship Attributo Identificatore Generalizzazione. 03/04/

21 Entità Classe di oggetti (fatti, persone, cose) della applicazione di interesse con proprietà comuni e con esistenza autonoma Esempi: impiegato, città, conto corrente, ordine, fattura 03/04/

22 Relationship 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/

23 Uno schema E-R, E graficamente Studente Esame Corso 03/04/

24 Entità: : schema e istanza 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/

25 Rappresentazione grafica di entità Impiegato Dipartimento Città Vendita 03/04/

26 Entità,, commenti Ogni entità ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare 03/04/

27 Relationship Legame logico fra due o più entità, rilevante nell applicazione di interesse Esempi: Residenza (fra persona e città) Esame (fra studente e corso) Chiamata anche: relazione, correlazione, associazione 03/04/

28 Rappresentazione grafica di relationship Studente Esame Corso Impiegato Residenza Città 03/04/

29 Relationship,, commenti Ogni relationship ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare sostantivi invece che verbi (se possibile) 03/04/

30 Esempi di occorrenze E1 S3 S1 S2 E2 E3 C1 C2 S4 E4 C3 Studente Corso 03/04/

31 Relationship,, occorrenze 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 03/04/

32 Relationship corrette? Studente Esame Corso Paziente Visita Medico 03/04/

33 Due relationship sulle stesse entità Sede di lavoro Impiegato Residenza Città 03/04/

34 Relationship n-aria Fornitore Fornitura Prodotto Dipartimento 03/04/

35 Relationship ricorsiva: coinvolge due volte la stessa entità Conoscenza Persona 03/04/

36 Relationship ricorsiva con ruoli Successione Successore Sovrano Predecessore 03/04/

37 Relationship ternaria ricorsiva Superficie Migliore Confronto Peggiore Tennista 03/04/

38 Attributo Proprietà elementare di un entità o di una relationship, di interesse ai fini dell applicazione Associa ad ogni occorrenza di entità o relationship un valore appartenente a un insieme detto dominio dell attributo 03/04/

39 Attributi, rappresentazione grafica Cognome Nome Data Voto Titolo Studente Esame Corso Matricola Codice 03/04/

40 Attributi composti Raggruppano attributi di una medesima entità o relationship che presentano affinità nel loro significato o uso Esempio: Via, Numero civico e CAP formano un Indirizzo 03/04/

41 Rappresentazione grafica Cognome Impiegato Età Indirizzo Via Numero CAP 03/04/

42 Cognome Impiegato Codice Partecipazione Direzione Afferenza Data Telefono Dipartimento Nome Composizione Sede Progetto Via Budget Nome CAP Indirizzo Città 03/04/

43 Altri costrutti del modello E-RE Cardinalità di relationship di attributo Identificatore interno esterno Generalizzazione 03/04/

44 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/

45 Esempio di cardinalità Impiegato (1,5) (0,50) Assegnamento Incarico 03/04/

46 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/

47 Occorrenze di Residenza S1 R1 C1 S3 S2 R2 C2 S4 Studente R3 R4 C4 C3 Città 03/04/

48 Cardinalità di Residenza Studente (1,1) (0,N) Residenza Città 03/04/

49 Tipi di relationship Con riferimento alle cardinalità massime, abbiamo relationship: uno a uno uno a molti molti a molti 03/04/

50 Due avvertenze Attenzione al "verso" nelle relationship uno a molti le relationship obbligatorie-obbligatorie sono molto rare 03/04/

51 Relationship molti a molti Studente (0,N) Esame (0,N) Corso Montagna (0,N) Scalata (1,N) Alpinista Macchinista (1,N) Abilitazione (1,N) Locomotore 03/04/

52 Relationship uno a molti (0,1) (0,N) Persona Impiego Azienda Cinema (1,1) (0,N) Ubicazione Località Comune (1,1) (1,N) Ubicazione Provincia 03/04/

53 Relationship uno a uno (0,1) (0,1) Professore Titolarità Cattedra Professore di ruolo (1,1) (0,1) Titolarità Cattedra Professore di ruolo (1,1) (1,1) Titolarità Cattedra coperta 03/04/

54 Cardinalità di attributi E possibile associare delle cardinalità anche agli attributi, con due scopi: indicare opzionalità ("informazione incompleta") indicare attributi multivalore 03/04/

55 Rappresentazione grafica (0,N) Telefono Impiegato Nome (0,1) Numero patente 03/04/

56 Identificatore di una entità 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/

57 Identificatori interni Targa Automobile Modello Data Nascita Persona Indirizzo Cognome Nome 03/04/

58 Identificatore esterno Cognome Matricola Nome Studente (1,1) (0,N) Iscrizione Università Anno di corso Indirizzo 03/04/

59 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/

60 Cognome (0,1) Direzione (1,1) Telefono (1,N) Codice Impiegato (0,N) Partecipazione (1,N) (0,1) (0,N) Afferenza (0,1) Data Dipartimento (1,1) Composizione (1,N) Nome Progetto Via Budget Nome CAP Sede Indirizzo Città 03/04/

61 Generalizzazione mette in relazione una o più entità E1, E2,..., En con una entità E, che le comprende come caso particolare E è generalizzazione di E1, E2,..., En E1, E2,..., En sono specializzazioni (o sottotipi) di E 03/04/

62 Rappresentazione grafica Dipendente Impiegato Funzionario Dirigente 03/04/

63 Proprietà delle generalizzazioni 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 03/04/

64 Città (0,N) Nascita (1,1) Persona Codice fiscale Nome Stipendio Età Lavoratore Studente 03/04/

65 Ereditarietà tutte le proprietà (attributi, relationship, altre generalizzazioni) dell entità genitore vengono ereditate dalle entità figlie e non rappresentate esplicitamente 03/04/

66 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/

67 CF Cognome Persona Stipendio Età Matr. Uomo Donna Impiegato Studente Militare Segretario Direttore Progettista Responsabile 03/04/

68 Documentazione associata agli schemi concettuali dizionario dei dati entità relationship vincoli non esprimibili 03/04/

69 Cognome (0,1) Direzione (1,1) Telefono (1,N) Codice Impiegato (0,N) Partecipazione (1,N) (0,1) (0,N) Afferenza (0,1) Data Dipartimento (1,1) Composizione (1,N) Nome Progetto Via Budget Nome CAP Sede Indirizzo Città 03/04/

70 Dizionario dei dati (entità) Entità Descrizione Attributi Identificatore Impiegato Dipendente Codice, Codice dell'azienda Cognome, Stipendio Progetto Progetti Nome, Nome aziendali Budget Dipartimento Struttura Nome, Nome, Sede aziendale Sede dell'azienda Telefono Città, Indirizzo Sede Città 03/04/

71 Dizionario dei dati (relationship( relationship) Relazioni Descrizione Componenti Attributi Direzione Direzione di un dipartimento Impiegato, Dipartimento Afferenza Afferenza a un Impiegato, Data dipartimento Dipartimento Partecipazione Partecipazione a un progetto Impiegato, Progetto Composizione Composizione dell'azienda Dipartimento, Sede 03/04/

72 Vincoli non esprimibili 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/

73 Progettazione Logica 03/04/

74 Progettazione concettuale Requisiti della base di dati Schema concettuale Progettazione logica Schema logico Progettazione fisica Schema fisico 03/04/

75 Obiettivo della progettazione logica "tradurre" lo schema concettuale in uno schema logico che rappresenti gli stessi dati in maniera corretta ed efficiente D ora in poi. Per semplificare non ci occuperemo dell efficienza 03/04/

76 Dati di ingresso e uscita Ingresso: schema concettuale Uscita: schema logico documentazione associata 03/04/

77 Non si tratta di una pura e semplice traduzione alcuni aspetti non sono direttamente rappresentabili 03/04/

78 Schema E-R Traduzione nel modello logico Schema logico 03/04/

79 Cognome (0,1) Direzione (1,1) Telefono (1,N) Codice Impiegato (0,N) Partecipazione (1,N) (0,1) (1,N) Afferenza (0,1) Data Dipartimento (1,1) Composizione (1,N) Nome Progetto Via Budget Nome CAP Sede Indirizzo Città 03/04/

80 Attività di Traduzione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relationship Scelta degli identificatori primari 03/04/

81 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 03/04/

82 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/

83 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 03/04/

84 A11 A21 (0,1) (0,1) A01 E0 A02 R1 E3 TIPO (0,..) R2 E4 03/04/

85 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 03/04/

86 R11 R12 E3 E1 E2 R2 A01 A11 A02 A01 A21 A02 E4 03/04/

87 A01 A02 E0 R1 E3 E1 E2 R2 A11 A21 E4 03/04/

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

89 Attività di Traduzione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari 03/04/

90 Ristrutturazioni, casi principali partizionamento verticale di entità partizionamento orizzontale di relationship eliminazione di attributi multivalore accorpamento di entità/ relationship 03/04/

91 Cognome Indirizzo Data nascita Codice Impiegato Livello Stipendio Ritenute 03/04/

92 Cognome Codice Stipendio Livello Dati anagrafici (1,1) (1,1) R Dati lavorativi Indirizzo Data nascita Ritenute 03/04/

93 Nome Indirizzo Agenzia (1,N) Città Telefono 03/04/

94 Città Nome Numero Agenzia (1,N) (1,1) Utenza Telefono Indirizzo 03/04/

95 Cognome Codice fiscale Interno Indirizzo Persona (0,1) (1,1) Intestazione Appartamento Indirizzo Data nascita 03/04/

96 Cognome Indirizzo Data nascita Codice fiscale Persona Interno (0,1) Indirizzo (0,1) 03/04/

97 Ruolo Cognome Città Nome Giocatore (1,N) (1,N) Composizione Squadra Data acquisto (0,1) Data cessione 03/04/

98 Ruolo Data acquisto (1,1) Comp. (1,N) attuale Nome Giocatore Squadra Cognome (1,N) Comp. passata (1,N) Città Data acquisto Data cessione 03/04/

99 Attività della ristrutturazione Analisi delle ridondanze Eliminazione delle generalizzazioni Partizionamento/accorpamento di entità e relazioni Scelta degli identificatori primari 03/04/

100 Scelta degli identificatori principali operazione indispensabile per la traduzione nel modello relazionale Criteri assenza di opzionalità semplicità 03/04/

101 Se nessuno degli identificatori soddisfa i requisiti visti? Si introducono nuovi attributi (codici) contenenti valori speciali generati appositamente per questo scopo 03/04/

102 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/

103 Entità e relationship molti a molti Cognome Matricola Data inizio Codice Nome (0,N) (1,N) Impiegato Partecipazione Progetto Stipendio Budget Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) 03/04/

104 Entità e relationship molti a molti Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) con vincoli di integrità referenziale fra Matricola in Partecipazione e (la chiave di) Impiegato Codice in Partecipazione e (la chiave di) Progetto 03/04/

105 Nomi più espressivi per gli attributi della chiave della relazione che rappresenta la relationship Impiegato(Matricola, Cognome, Stipendio) Progetto(Codice, Nome, Budget) Partecipazione(Matricola, Codice, DataInizio) Partecipazione(Impiegato, Progetto, DataInizio) 03/04/

106 Relationship ricorsive (0,N) Composizione Quantità (0,N) Composto Prodotto Componente Costo Nome Codice Prodotto(Codice, Nome, Costo) Composizione(Composto, Componente, Quantità) 03/04/

107 Nome Relationship n-arie Partita IVA Quantità Genere Codice Fornitore (0,N) Fornitura (1,N) Prodotto (1,N) Dipartimento Nome Telefono Fornitore(PartitaIVA, Nome) Prodotto(Codice, Genere) Dipartimento(Nome, Telefono) Fornitura(Fornitore, Prodotto, Dipartimento, Quantità) 03/04/

108 Relationship uno a molti Cognome Data Ingaggio nascita Città Nome (1,1) (0,N) Giocatore Contratto Squadra Ruolo Colori sociali Giocatore(Cognome, DataNascita, Ruolo) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) corretto? 03/04/

109 Soluzione più compatta Giocatore(Cognome, DataNascita, Ruolo) Contratto(CognGiocatore, DataNascG, Squadra, Ingaggio) Squadra(Nome, Città, ColoriSociali) Giocatore(Cognome, DataNasc, 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/

110 Entità con identificazione esterna Cognome Matricola Nome Città Studente (1,1) (1,N) Iscrizione Università AnnoDiCorso Indirizzo Studente(Matricola, Università, Cognome, AnnoDiCorso) Università(Nome, Città, Indirizzo) con vincolo 03/04/

111 Relationship uno a uno Data inizio Cognome Codice Sede Nome (1,1) (1,1) Direttore Direzione Dipartimento Stipendio Telefono varie possibilità: fondere da una parte o dall'altra fondere tutto? 03/04/

112 Una possibilità privilegiata Data inizio Cognome Codice Sede Nome (0,1) (1,1) Direttore Direzione Dipartimento Stipendio Telefono Impiegato (Codice, Cognome, Stipendio) Dipartimento (Nome, Sede, Telefono, Direttore, InizioD) con vincolo di integrità referenziale, senza valori nulli 03/04/

113 Un altro caso Data inizio Cognome Codice Sede Nome (0,1) (0,1) Direttore Direzione Dipartimento Stipendio Telefono 03/04/

114 Cognome (0,1) Direzione (1,1) Telefono Codice Impiegato (0,N) Partecipazione (1,N) (0,1) (1,N) Afferenza (0,1) Data Dipartimento (1,1) Composizione (1,N) Nome Progetto Via Budget Nome CAP Sede Indirizzo Città 03/04/

115 Schema finale Impiegato(Codice, Cognome, Dipartimento*, Data*) Dipartimento(Nome, Città, Telefono, Direttore) Sede(Città, Via, CAP) Progetto(Nome, Budget) Partecipazione(Impiegato, Progetto) 03/04/