Progettazione di basi di dati: Metodologie e modelli

Transcript

1 Progettazione di basi di dati: Metodologie e modelli

2 Progettazione di basi di dati Fino a questo punto si sono analizzate le modalità (modelli) di descrizione e di manipolazione di una base di dati supponendo l esistenza della base di dati con la quale interagire. Il problema preliminare è: progettare una base di dati a partire dai suoi requisiti e quindi definire struttura, caratteristiche e contenuto Le fasi della metodologia di riferimento: progettazione concettuale, progettazione logica e progettazione fisica 24/05/2006 2

3 Esempio Base di dati bibliografica Si vogliono organizzare i dati di interesse per automatizzare la gestione dei riferimenti bibliografici 24/05/2006 3

4 Base di dati bibliografica Si vogliono organizzare i dati di interesse per automatizzare la gestione dei riferimenti bibliografici, con tutte le informazioni da riportarsi in una bibliografia. Per ogni pubblicazione deve esistere un codice identificante costituito da sette caratteri, indicanti le iniziali degli autori, l'anno di pubblicazione e un carattere aggiuntivo per la discriminazione delle collisioni. 24/05/2006 4

5 Base di dati bibliografica Si vogliono organizzare i dati di interesse per automatizzare la gestione dei riferimenti bibliografici, con tutte le informazioni da riportarsi in una bibliografia. Le pubblicazioni sono di due tipi, monografie (per le quali interessano editore, data e luogo di pubblicazione) e articoli su rivista (con nome della rivista, volume, numero, pagine e anno di pubblicazione); per entrambi i tipi si debbono ovviamente riportare i nomi degli autori. Per ogni pubblicazione deve esistere un codice identificante... 24/05/2006 5

6 Un esempio più articolato Società di formazione (1) Si vuole realizzare una base di dati per una società che eroga corsi, di cui vogliamo rappresentare i dati dei partecipanti ai corsi e dei docenti. Per gli studenti (circa 5000), identificati da un codice, si vuole memorizzare il codice fiscale, il cognome, l'età, il sesso, il luogo di nascita, il nome dei loro attuali datori di lavoro, i posti dove hanno lavorato in precedenza insieme al periodo, l'indirizzo e il numero di telefono, i corsi che hanno frequentato (i corsi sono in tutto circa 200) e il giudizio finale. 24/05/2006 6

7 Società di formazione (2) Rappresentiamo anche i seminari che stanno attualmente frequentando e, per ogni giorno, i luoghi e le ore dove sono tenute le lezioni. I corsi hanno un codice, un titolo e possono avere varie edizioni con date di inizio e fine e numero di partecipanti. Se gli studenti sono liberi professionisti, vogliamo conoscere l'area di interesse e, se lo possiedono, il titolo. Per quelli che lavorano alle dipendenze di altri, vogliamo conoscere invece il loro livello e la posizione ricoperta. 24/05/2006 7

8 Società di formazione (3) Per gli insegnanti (circa 300), rappresentiamo il cognome, l'età, il posto dove sono nati, il nome del corso che insegnano, quelli che hanno insegnato nel passato e quelli che possono insegnare. Rappresentiamo anche tutti i loro recapiti telefonici. I docenti possono essere dipendenti interni della società o collaboratori esterni. 24/05/2006 8

9 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 24/05/2006 9

10 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 24/05/

11 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento 24/05/

12 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 24/05/

13 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione dei dati Realizzazione Validazione e collaudo Funzionamento 24/05/

14 Progettazione concettuale COME : progettazione Requisiti della base di dati Schema concettuale Progettazione logica Schema logico Progettazione fisica CHE COSA : analisi Schema fisico 24/05/

15 I prodotti della varie fasi sono schemi di alcuni modelli di dati: Schema concettuale Schema logico Schema fisico 24/05/

16 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 24/05/

17 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 24/05/

18 Società di formazione (1) Si vuole realizzare una base di dati per una società che eroga corsi, di cui vogliamo rappresentare i dati dei partecipanti ai corsi e dei docenti. Per gli studenti (circa 5000), identificati da un codice, si vuole memorizzare il codice fiscale, il cognome, l'età, il sesso, il luogo di nascita, il nome dei loro attuali datori di lavoro, i posti dove hanno lavorato in precedenza insieme al periodo, l'indirizzo e il numero di telefono, i corsi che hanno frequentato (i corsi sono in tutto circa 200) e il giudizio finale. Società di formazione (2) Rappresentiamo anche i seminari che stanno attualmente frequentando e, per ogni giorno, i luoghi e le ore dove sono tenute le lezioni. I corsi hanno un codice, un titolo e possono avere varie edizioni con date di inizio e fine e numero di partecipanti. Se gli studenti sono liberi professionisti, vogliamo conoscere l'area di interesse e, se lo possiedono, il titolo. Per quelli che lavorano alle dipendenze di altri, vogliamo conoscere invece il loro livello e la posizione ricoperta. Società di formazione (3) Per gli insegnanti (circa 300), rappresentiamo il cognome, l'età, il posto dove sono nati, il nome del corso che insegnano, quelli che hanno insegnato nel passato e quelli che possono insegnare. Rappresentiamo anche tutti i loro recapiti telefonici. I docenti possono essere dipendenti interni della società o collaboratori esterni. 24/05/

19 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) 24/05/

20 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à 24/05/

21 Progettazione concettuale Progettazione logica Progettazione fisica 24/05/

22 Società di formazione (1) Si vuole realizzare una base di dati per una società che eroga corsi, di cui vogliamo rappresentare i dati dei partecipanti ai corsi e dei docenti. Per gli studenti (circa 5000), identificati da un codice, si vuole memorizzare il codice fiscale, il cognome, l'età, il sesso, il luogo di nascita, il nome dei loro attuali datori di lavoro, i posti dove hanno lavorato in precedenza insieme al periodo, l'indirizzo e il numero di telefono, i corsi che hanno frequentato (i corsi sono in tutto circa 200) e il giudizio finale. Società di formazione (2) Rappresentiamo anche i seminari che stanno attualmente frequentando e, per ogni giorno, i luoghi e le ore dove sono tenute le lezioni. I corsi hanno un codice, un titolo e possono avere varie edizioni con date di inizio e fine e numero di partecipanti. Se gli studenti sono liberi professionisti, vogliamo conoscere l'area di interesse e, se lo possiedono, il titolo. Per quelli che lavorano alle dipendenze di altri, vogliamo conoscere invece il loro livello e la posizione ricoperta. Società di formazione (3) Per gli insegnanti (circa 300), rappresentiamo il cognome, l'età, il posto dove sono nati, il nome del corso che insegnano, quelli che hanno insegnato nel passato e quelli che possono insegnare. Rappresentiamo anche tutti i loro recapiti telefonici. I docenti possono essere dipendenti interni della società o collaboratori esterni. 24/05/

23 24/05/

24 Schema Relazionale Abilitazione(CodCorso, CFDocente) Corso(Codice, Nome) DipendenzaP(CodPartecipante, NomeSocietà, DataInizio, DataFine) DipPubblici(CodPartecipante, Livello, Posizione) Docente(CF, Cognome, Età, CittàNascita, Telefono, Tipo) Docenza(CodEdCorso, CFDocente) Edizione(Codice, DataInizio, DataFine, CodCorso) Lezione(Ora, Aula, Giorno, CodEdCorso) Partecipante(Codice, CF, Cognome, Età, Sesso, CittàNascita, Società, DataInizio) Partecipazione(CodEdCorso, CodPartecipante, Votazione) Professionisti(CodPartecipante, Area, Titolo) 24/05/

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

26 I costrutti del modello E-RE Entità Relationship Attributo Identificatore Generalizzazione. 24/05/

27 Entità Classe di oggetti (fatti, persone, cose) della applicazione di interesse con proprietà comuni e con esistenza autonoma Esempi: studente, città, corso, conto corrente, ordine, fattura Graficamente Studente Corso 24/05/

28 Relationship Legame logico fra due o più entità, rilevante nell applicazione di interesse Esempi: Residenza (fra persona e città) Esame (fra studente e corso) Graficamente: Studente Esame Corso 24/05/

29 Uno schema E-R, E graficamente Entità 1 Associazione Entità 2 24/05/

30 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 ) 24/05/

31 Rappresentazione grafica di entità Impiegato Dipartimento Città Vendita 24/05/

32 Entità,, commenti Ogni entità ha un nome che la identifica univocamente nello schema: nomi espressivi opportune convenzioni singolare 24/05/

33 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 24/05/

34 Rappresentazione grafica di relationship Studente Esame Corso Impiegato Residenza Città 24/05/

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

36 Esempi di occorrenze E1 S3 S1 S2 E2 E3 C1 C2 S4 E4 C3 Studente Corso 24/05/

37 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 24/05/

38 Due relationship sulle stesse entità Sede di lavoro Impiegato Residenza Città 24/05/

39 Relationship n-aria Fornitore Fornitura Prodotto Dipartimento 24/05/

40 Relationship ricorsiva: coinvolge due volte la stessa entità Conoscenza Persona 24/05/

41 Relationship ricorsiva con ruoli Successione Successore Sovrano Predecessore 24/05/

42 Relationship ternaria ricorsiva Superficie Migliore Confronto Peggiore Tennista 24/05/

43 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 24/05/

44 Attributi, rappresentazione grafica Cognome Nome Data Voto Titolo Studente Esame Corso Matricola Codice 24/05/

45 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 24/05/

46 Rappresentazione grafica Cognome Impiegato Età Indirizzo Via Numero CAP 24/05/

47 Cognome Impiegato Codice Partecipazione Direzione Afferenza Data Telefono Dipartimento Nome Composizione Sede Progetto Via Budget Nome CAP Indirizzo Città 24/05/

48 Altri costrutti del modello E-RE Cardinalità di relationship di attributo Identificatore interno esterno Generalizzazione 24/05/

49 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 (1,5) (0,50) Impiegato Assegnamento Incarico 24/05/

50 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 24/05/

51 Occorrenze di Residenza S1 R1 C1 S3 S2 R2 C2 S4 Studente R3 R4 C4 C3 Città 24/05/

52 Cardinalità di Residenza Studente (1,1) (0,N) Residenza Città 24/05/

53 Tipi di relationship Con riferimento alle cardinalità massime, abbiamo relationship: uno a uno uno a molti molti a molti 24/05/

54 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 24/05/

55 Due avvertenze Attenzione al "verso" nelle relationship uno a molti le relationship obbligatorie-obbligatorie sono molto rare 24/05/

56 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 24/05/

57 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 24/05/

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

59 Rappresentazione grafica (0,N) Telefono Impiegato Nome (0,1) Numero patente 24/05/

60 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 24/05/

61 Identificatori interni Targa Automobile Modello Data Nascita Persona Indirizzo Cognome Nome 24/05/

62 Identificatore esterno Cognome Matricola Nome Studente (1,1) (0,N) Iscrizione Università Anno di corso Indirizzo 24/05/

63 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) 24/05/

65 Generalizzazione mette in relazione una o più entità E1, E2,..., En con una entità E, che le comprende come casi particolari E è generalizzazione di E1, E2,..., En E1, E2,..., En sono specializzazioni (o sottotipi) di E 24/05/

66 Rappresentazione grafica Dipendente Impiegato Funzionario Dirigente 24/05/

67 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 24/05/

68 Città (0,N) Nascita (1,1) Persona Codice fiscale Nome Stipendio Età Lavoratore Studente 24/05/

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

70 Tipi di generalizzazioni totale se ogni occorrenza dell'entità genitore è occorrenza di almeno una delle entità figlie, altrimenti è parziale esclusiva se ogni occorrenza dell'entità genitore è occorrenza di al più una delle entità figlie, altrimenti è sovrapposta consideriamo (senza perdita di generalità) solo generalizzazioni esclusive e distinguiamo fra totali e parziali 24/05/

71 Persona Uomo Donna 24/05/

72 Veicolo Motocicletta Automobile 24/05/

73 Persona Studente Lavoratore 24/05/

74 Altre proprietà possono esistere gerarchie a più livelli e multiple generalizzazioni allo stesso livello un'entità può essere inclusa in più gerarchie, come genitore e/o come figlia se una generalizzazione ha solo un entità figlia si parla di sottoinsieme alcune configurazioni non hanno senso il genitore di una generalizzazione totale può non avere identificatore, purché 24/05/

75 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) 24/05/

76 CF Cognome Persona Stipendio Età Matr. Uomo Donna Impiegato Studente Militare Segretario Direttore Progettista Responsabile 24/05/

77 Documentazione associata agli schemi concettuali dizionario dei dati entità relationship vincoli non esprimibili 24/05/

79 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à 24/05/

80 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 24/05/

81 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 24/05/