Basi di dati. Progettazione di basi di dati: Metodologie e modelli

Transcript

1 Basi di dati Progettazione di basi di dati: Metodologie e modelli

2 Perché preoccuparci? 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.) il modello relazionale è rigido 2

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

4 Studio di fattibilità Il ciclo di vita Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento 4

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

6 Progettazione 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 6

7 Analisi & Progettazione Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento 7

8 Metodologia di progetto 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 8

9 Studio di fattibilità Raccolta e analisi dei requisiti Progettazione Realizzazione Validazione e collaudo Funzionamento 9

10 Analisi & Progettazione: dettagli Requisiti della base di dati Progettazione concettuale CHE COSA : analisi Schema concettuale Progettazione logica COME : progettazione Schema logico Progettazione fisica Schema fisico 10

11 Modelli di dati: concettuale, logico e fisico I prodotti della varie fasi sono schemi di alcuni modelli di dati: Schema concettuale Schema logico Schema fisico 11

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

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

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

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

16 Modelli concettuali, perché? servono per ragionare sulla realtà di interesse, indipendentemente dagli aspetti realizzativi permettono di rappresentare le classi di oggetti di interesse e le loro correlazioni prevedono efficaci rappresentazioni grafiche (utili anche per documentazione e comunicazione) 16

17 Architettura (semplificata) di un DBMS utente Schema logico Schema interno BD 17

18 Progettazione: evoluzione Progettazione concettuale Progettazione logica Progettazione fisica 18

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

20 I costrutti del modello E-R Entità Relationship Attributo Identificatore Generalizzazione. 20

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

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) 22

23 Uno schema E-R, graficamente Studente Esame Corso 23

24 Entità (2) Classe di oggetti (fatti, persone, cose) della realtà di interesse con proprietà comuni e con esistenza autonoma Esempi: impiegato, città, conto corrente, ordine, fattura 24

25 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 ) 25

26 Rappresentazione grafica di entità Impiegato Dipartimento Città Vendita 26

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

28 Relationship (2) 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 28

29 Rappresentazione grafica di relationship Studente Esame Corso Impiegato Residenza Città 29

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

31 Esempi di occorrenze E1 S3 S1 S2 E2 E3 C1 C2 S4 Studente E4 Esame C3 Corso 31

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

33 Relationship corrette? Studente Esame Corso Paziente Visita Medico 33

34 Attenzione E5 E1 S3 S1 S2 E2 E3 C1 C2 S4 E4 C3 Esame Studente Corso 34

35 "Promuoviamo" la relationship Studente Esame Corso La relazione Esame non è in grado di descrivere che uno Studente abbia sostenuto più volte lo stesso esame relativo a quel Corso Studente Esame Corso La soluzione sta nel rappresentare Esame come entità, collegata mediante relazioni a Studente e Corso 35

36 Con l entità Esame S3 S1 S2 E5 E1 C1 C2 S4 Studente Esame C3 Corso 36

37 Due relationship sulle stesse entità Sede di lavoro Impiegato Residenza Città 37

38 Relationship n-aria Fornitore Fornitura Prodotto Dipartimento 38

39 Esempi di occorrenze Fornitura f1 F1 F2 F3 F4 f2 f4 f3 P1 P2 P3 Fornitore Prodotto Dipartimento D1 D3 D2 39

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

41 Relationship ricorsiva con ruoli Successione Successore Ministro Predecessore 41

42 Esempi di occorrenze (2) successore:s2,predecessore: S3 successore:s1,predecessore: S2 S2 Successore S1 S3 Predecessore 42

43 Relationship ternaria ricorsiva Superficie Migliore Confronto Peggiore Tennista 43

44 Esempi di occorrenze (3) S1 S2 T1 è migliore di T2 su S2 T2 è migliore di T1 su S1 T3 è migliore di T2 su S1 T1 T2 T3 44

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

46 Attributi, rappresentazione grafica Cognome Nome Data Voto Titolo Studente Esame Corso Matricola Codice 46

47 Esempi di occorrenze (4) Matricola: Cognome: Rossi Nome: Mario Data: 25/07/2004 Voto: 26 E1 Codice: Inf205 Titolo: Basi di dati Matricola: S1 S2 E2 C1 C2 Cognome: Neri Nome: Piero Studente Esame Corso 47

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

49 Rappresentazione grafica Cognome Impiegato Età Indirizzo Via Numero CAP 49

50 Cognome Impiegato Codice Partecipazione Direzione Afferenza Data Telefono Dipartimento Nome Composizione Budget Progetto Nome Via CAP Sede Indirizzo Città 50

51 Altri costrutti del modello E-R Cardinalità di relationship di attributo Identificatore interno esterno Generalizzazione 51

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

53 Esempio di cardinalità Impiegato (1,5) (0,50) Assegnamento Incarico Ad un Impiegato deve essere assegnato almeno 1 incarico ma non più di 5 Ogni Incarico può non essere assegnato a nessuno (0) oppure può essere assegnato a un numero inferiore o uguale a 50 impiegati 53

54 Cardinalità 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 54

55 Occorrenze di Residenza S1 R1 C1 S3 S2 R2 C2 S4 Studente R3 R4 C4 C3 Città 55

56 Cardinalità di Residenza Studente (1,1) (0,N) Residenza Città 56

57 Tipi di relationship Con riferimento alle cardinalità massime, abbiamo relationship: uno a uno uno a molti molti a molti 57

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

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

60 Due avvertenze Attenzione al "verso" nelle relationship uno a molti le relationship obbligatorie-obbligatorie sono molto rare 60

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

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

63 Rappresentazione grafica (0,N) Telefono Impiegato Nome (0,1) Numero patente 63

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

65 Identificatori interni (1) Targa Automobile Modello L attributo Targa è identificatore interno dell entità Automobile in quanto non posso esistere due automobili con la stessa targa 65

66 Identificatori interni (2) Data Nascita Persona Indirizzo Cognome Nome L insieme degli attributi: Nome, Cognome e Data di nascita costituiscono l identificatore interno dell entità Persona in quanto non possono esistere (nel nostro caso) due persone aventi nome, cognome e data di nascita identici 66

67 Identificatore esterno Cognome Matricola Nome Studente (1,1) (0,N) Iscrizione Università Anno di corso Indirizzo L attributo Matricola e l entità Università rappresentano l identificatore esterno in quanto possiamo avere studenti con lo stesso numero di matricola, ma appartententi ad università diverse 67

68 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? perché è opportuno privilegiare l inserimento di attributi nelle entità piuttosto che nelle relationship 68

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

70 Attenzione Differenze apparentemente piccole in cardinalità e identificatori possono cambiare di molto il significato 70

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

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

73 Identificatori esterni e cardinalità Nel primo schema E-R (slide 71) viene assegnato ad ogni Dipartimento una ed una sola Sede: possiamo avere quindi anche dipartimenti con lo stesso Nome, l importante è che la Città dove ha sede il dipartimento sia diversa Viceversa nel secondo schema E-R (slide 72) viene assegnato ad ogni Sede uno ed un solo Dipartimento: quindi possiamo avere nella stessa Città più dipartimenti ma con Nome diverso 73

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

75 Rappresentazione grafica Dipendente Impiegato Funzionario Dirigente 75

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

77 Proprietà delle generalizzazioni: esempio Città (0,N) Nascita (1,1) Persona Codice fiscale Nome Stipendio Età Lavoratore Studente 77

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

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

80 Generalizzazione esclusiva parziale Persona Disoccupato Lavoratore 80

81 Generalizzazione esclusiva totale Persona Uomo Donna 81

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

83 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) 83

84 CF Cognome Schema concettuale Persona Stipendio Età Matr. Uomo Donna Impiegato Studente Militare Progettista Direttore Segretario Responsabile 84

85 Documentazione associata agli schemi concettuali dizionario dei dati entità relationship vincoli non esprimibili 85

86 Cognome Schema concettuale (2) (0,1) (1,1) Direzione Telefono (1,N) Impiegato (0,1) (0,N) Dipartimento Codice (0,N) Partecipazione (1,N) Afferenza Data (0,1) (1,1) Composizione (1,N) Nome Progetto Via Sede Budget Nome CAP Indirizzo Città 86

87 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à 87

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

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

90 Modellazione dei dati in UML UML viene talvolta utilizzato in alternativa al modello ER per la rappresentazione concettuale dei dati Si fa uso dei diagrammi delle classi Cambia la rappresentazione diagrammatica ma non l approccio alla progettazione Vediamo come sia possibile rappresentare schemi concettuali con UML 90

91 Classi Impiegato Codice Cognome Stipendio Età Progetto Nome Budget Data consegna 91

92 Associazioni Studente Matricola Anno Iscrizione Esame Corso Nome Anno corso Sede di lavoro Impiegato Cognome Stipendio Età Residenza Città Nome Numero abitanti 92

93 Classe di associazione Studente Matricola Anno Iscrizione Data Voto Esame Corso Nome Anno corso La classe Esame è una classe di associazione che usiamo per rappresentare gli attributi Voto e Data dell associazione tra la classe Studente e la classe Corso 93

94 Associazione ternaria Dipartimento Nome Telefono Fornitore Denominazione Indirizzo Prodotto Codice Prezzo Fornitura Quantità E rappresentata da un rombo con le classi che vi partecipano (Fornitore, Dipartimento e Prodotto), facendo uso di una classe di associazione (Fornitura) per assegnare attributi all associazione tra queste classi 94

95 Reificazione di associazione Dipartimento Nome Telefono Fornitore Denominazione Indirizzo Fornitura Quantità Prodotto Codice Prezzo Le associazioni n-arie sono poco usate nei diagrammi delle classi e, per questo, le reifichiamo ovvero trasformiamo l associazione (Fornitura) in una classe legata alle classi originarie con associazioni binarie 95

96 Aggregazione e composizione Team Tecnico Un Tecnico fa parte di un Team. Esso può essere rappresentato indipendentemente dal Team di cui fa parte (aggregazione semplice) Azienda Filiale Una Filiale è parte di un Azienda. Essa non può essere rappresentata indipendentemente dall Azienda (composizione) 96

97 Associazioni con molteplicità Ordine 1 Vendita 0..1 Fattura Un Ordine può avere 0 o al massimo 1 Fattura di vendita associata. Viceversa una Fattura ha 1 solo Ordine di vendita Persona * Residenza Città L assenza di molteplicità sottintende 1..1, quindi una Persona può essere residente in una ed una sola Città. Viceversa una Città può avere 0 o al massimo N persone residenti Turista * Prenotazione 1..* Viaggio Un Turista può prenotare 1 o al massimo N viaggi. Viceversa un Viaggio può essere prenotato da 0 o al massimo N turisti 97

98 Identificatori Automobile Targa {id} Modello Colore Persona Data Nascita {id} Cognome {id} Nome {id} Indirizzo Targa è identificatore della classe Automobile L insieme di attributi Data Nascita, Cognome e Nome costituiscono l identificatore per la classe Persona 98

99 Identificatore esterno Studente Università Matricola {id} Anno Iscrizione Cognome 1..* Iscrizione <<identificante>> 1 Nome {id} Città Indirizzo Lo stereotipo <<identificante>> serve ad indicare che l associazione tra Studente e Università è appunto identificante in quanto insieme all attributo Matricola identifica uno studente 99

100 Esclusiva Totale Generalizzazioni Persona Codice Fiscale {id} Cognome Età Esclusiva Parziale Uomo Situazione Militare Donna Professionista Partita IVA {id} Indirizzo {parziale, esclusiva} Avvocato Ingegnere Dottore Specializzazione 100

101 Uno schema concettuale in UML 1 Direzione 0..1 Impiegato Codice {id} Cognome Stipendio Età 1..* 1..* Partecipazione Data inizio Afferenza Data afferenza 0..1 Dipartimento Nome {id} Telefono 1..* Composizione <<identificante>> 1..* * Progetto Nome {id} Budget Data consegna 0..1 Progetti aziendali nei quali lavorano gli impiegati Sede Città {id} Indirizzo 1 101