1.1 I componenti di un DBMS... 5

Transcript

1 Indice 1 Introduzione ai DBMS Scopi di un DBMS Modelli dei dati Schemi e Istanze Linguaggi per basi di dati Data Definition Language Data Manipulation Language Architettura di un DBMS Progettazione Concettuale Introduzione Uno strumento per la progettazione concettuale: il modello E/R Entità Relazioni o Associazioni Attributi Costruzione di schemi con i costrutti di base Cardinalità delle relazioni Cardinalità degli attributi Identificatori o chiavi delle entità Generalizzazioni Documentazione degli schemi E/R Ulteriori usi degli schemi E/R Regole di progettazione concettuale Esercizi Esercizio Esercizio

2

3 Elenco delle figure 1.1 I componenti di un DBMS Alcuni esempi di entità Un esempio di Relazione Tra le stesse entità vi possono essere diverse relazioni Tra le istanze di una relazione non vi possono essere ennuple ripetute Due esempi di relazione ricorsiva Un esempio di relazione ternaria Esempio di attributi Esempio di attributo composto Esempio di schema complesso Esempio di cardinalità di relazione Vari tipi di cardinalità Esempio di cardinalità di attributo Modellazione alternativa di alcune cardinalità di attributi Rappresentazione degli identificatori in uno schema E/R Rappresentazione di una chiave esterna in uno schema E/R Raffinamento dello schema complesso di Figura Rappresentazione delle generalizzazioni

4

5 Elenco delle tabelle 2.1 Dizionario delle Entità Dizionario delle Relazioni Annotazioni allo schema E/R

6

7 1 Introduzione ai DBMS Questo capitolo ha lo scopo di introdurre lo studente al mondo dei database. Innanzitutto verranno esaminati gli scopi di un database; successivamente verranno introdotti alcuni concetti fondamentali, quali quelli di modello dei dati, schemi e istanze, linguaggi per basi di dati. La lezione si chiude con una descrizione, semplificata, dell architettura di un DBMS. 1.1 Scopi di un DBMS Un DataBase Management System (DBMS) consiste in una collezione di dati correlati e in un insieme di programmi per accedere questi dati. Le collezioni dei dati, generalmente denominati database, contengono informazioni su una determinata organizzazione. Il primo scopo di un DBMS è quello di fornire un ambiente che è sia conveniente che efficiente da usare nel recupero e nella memorizzazione delle informazioni. I DBMS sono stati progettati per gestire grandi quantità di informazioni. La gestione delle informazioni comporta tanto la definizione di strutture per la loro memorizzazione che di meccanismi per la loro manipolazione. Inoltre, un DBMS deve gestire la sicurezza delle informazioni memorizzate, ovvero deve essere capace di far fronte sia a crash del sistema che ad accessi non autorizzati. Un DBMS deve essere capace di gestire, in modo corretto ed efficiente, la condivisione dei dati tra diversi utenti. Per comprendere meglio tutte queste problematiche consideriamo il seguente esempio. Supponiamo di dover gestire l informatizzazione di una filiale di una banca che mantiene informazioni sui clienti e sui conti. Un modo per mantenere l informazione su un computer è quello di memorizzarla in file permanenti. Per consentire agli utenti di manipolare le informazioni, il sistema deve avere un certo numero di programmi applicativi che manipolano i file corrispondenti; tra questi programmi dovranno necessariamente essere presenti: un programma per la gestione dei depositi e dei prelievi; un programma per aggiungere un nuovo conto; un programma per calcolare il saldo di un conto; un programma per generare gli estratti conto. Questi programmi applicativi vengono scritti da programmatori in risposta alle necessità della banca. Nuovi programmi applicativi vengono aggiunti al sistema mano a mano che nascono nuove necessità (si pensi, ad esempio, ai programmi per la gestione dei conti on line). Così, con il passare del tempo, più file e più programmi applicativi vengono aggiunti al sistema. I file che compongono il sistema sono supportati da un sistema operativo convenzionale. Le informazioni di interesse vengono memorizzate in vari file; inoltre, vengono scritti diversi programmi applicativi per estrarre o inserire nuovi dati nei file appropriati. Prima dell avvento dei DBMS le organizzazioni memorizzavano le informazioni utilizzando tipicamente tali sistemi.

8 2 1 Introduzione ai DBMS Questo modo di gestire le informazioni comporta, però, alcuni grossi svantaggi. Più specificatamente, vi possono essere: Ridondanze ed inconsistenze dei dati. Dal momento che i file e i programmi applicativi vengono scritti, nel tempo, da programmatori differenti, i vari file avranno probabilmente formati differenti e i programmi possono essere scritti in diversi linguaggi di programmazione. Inoltre, la stessa informazione può essere duplicata in diversi posti. Per esempio, l indirizzo e il numero di telefono di un particolare cliente può apparire nel file dei conti e, ad esempio, nel file dei depositi. Tale ridondanza porta a dei costi di memorizzazione e di accesso più alti. Inoltre, essa può portare ad inconsistenza dei dati, ovvero le varie copie degli stessi dati potrebbero differire. Ad esempio, il cambiamento dell indirizzo di un cliente può essere stato registrato nel file dei conti e non in quello dei depositi. Difficoltà nell accedere ai dati. Si supponga che uno degli impiegati bancari debba selezionare i nomi di tutti i clienti che vivono nella parte di città con CAP L impiegato chiede al dipartimento di elaborazione dei dati di generare tale lista. Poichè tale richiesta non è stata prevista quando il sistema originale è stato progettato, non vi è alcun programma applicativo già pronto per soddisfarlo. C è, tuttavia, un programma applicativo per generare la lista di tutti i clienti. L impiegato bancario ha ora due scelte: o ottiene la lista di tutti i clienti ed estrae da questa manualmente l informazione desiderata oppure chiede al dipartimento di elaborazione dei dati di scrivere un opportuno programma applicativo. Entrambe le alternative sono, ovviamente, insoddisfacenti. Si supponga che tale programma sia stato scritto e che, alcuni giorni dopo, lo stesso impiegato deve aggiornare la lista per includere solo quei clienti che hanno un saldo maggiore di euro. Chiaramente, un programma per aggiornare tale lista non esiste. Ancora una volta l impiegato ha le due opzioni precedenti, nessuna delle quali è soddifacente. Il punto qui è che i tradizionali ambienti per l elaborazione dei file non permettono un recupero conveniente ed efficiente delle informazioni di interesse. Isolamento dei dati. Poichè i dati sono distribuiti su più file e questi possono avere formati differenti, è difficile scrivere nuovi programmi applicativi per recuperare le informazioni desiderate. Problemi di integrità. I valori dei dati memorizzati nel database devono soddisfare alcuni vincoli di integrità. Per esempio, il bilancio di un conto in banca non può mai scendere al di sotto di un valore prescritto (diciamo, 25 euro). Per controllare che tali vincoli vengano rispettati, gli sviluppatori dovranno aggiungere del codice appropriato nei vari programmi applicativi. Tuttavia, se vi è la necessità di aggiungere nuovi vincoli, sarà necessario cambiare i programmi aggiungendo nuovo codice per controllare che i vincoli stessi vengano rispettati. Ciò risulta essere molto difficile. Tale attività diventa particolarmente complessa quando i vincoli coinvolgono diversi dati provenienti da file differenti. Problemi di atomicità. Un computer, come qualunque altro dispositivo meccanico o elettronico, è soggetto a guasto. In molte applicazioni è cruciale assicurarsi che, una volta che è avvenuto un guasto e che lo stesso è stato individuato, i dati vengano riportati all ultimo stato consistente esistente prima del guasto. Si consideri, a titolo di esempio, un programma per trasferire 50 euro dal conto A al conto B. Se accade un guasto nel sistema durante l esecuzione del programma è possibile che 50 euro vengano rimossi dal conto A ma non accreditati nel conto B, comportando una inconsistenza nel database. Chiaramente è essenziale, per la consistenza del database, che vengano registrati sia gli accrediti che gli addebiti oppure che non vengano registrati nessuno dei due. In altre parole, il trasferimento dei fondi deve essere un operazione atomica, cioè deve avvenire nella sua interezza o non deve avvenire affatto. È difficile assicurare tale proprietà con un file system tradizionale. Anomalie nell accesso concorrente. Affinchè si possa migliorare la performance complessiva del sistema, ottenendo un tempo di risposta alle interrogazioni minore, molti sistemi consentono a più utenti di aggiornare simultaneamente i dati. In tali ambienti l interazione di aggiornamenti concorrenti può portare a dati inconsistenti. Si consideri un conto A che contiene 500 euro. Se due clienti prelevano soldi (diciamo 50 euro e 100 euro, rispettivamente) dal conto A nello stesso istante, il risultato dell esecuzione concorrente può lasciare il conto in uno stato incorretto (o inconsistente).

9 1.3 Schemi e Istanze 3 Si supponga che i programmi che gestiscono il prelievo leggano il vecchio saldo, riducono il valore della quantità da prelevare e riscrivano il risultato. Se i due programmi vengono eseguiti concorrentemente essi possono entrambi leggere il valore 500 euro e scrivere di nuovo 450 euro e 400 euro, rispettivamente. A seconda di chi scrive il valore, il conto può contenere 450 euro oppure 400 euro, piuttosto che il valore corretto di 350 euro. Per affrontare tale problema il sistema deve mantenere qualche forma di supervisione. Poichè i dati possono essere acceduti da programmi applicativi che non sono stati precedentemente coordinati, la supervisione è difficile da garantire. Problemi di sicurezza. Non tutti gli utenti del DBMS dovrebbero essere capaci di accedere a tutti i dati. Per esempio, in un sistema bancario, il personale che gestisce i pagamenti deve vedere solo la parte del database che contiene informazioni sui vari impiegati bancari. Esso non deve accedere ad informazioni sui conti dei clienti. Tali vincoli di sicurezza possono essere difficilmente garantiti con una gestione basata sui file dal momento che che, in questo caso, è difficile controllare tutti i programmi ad-hoc che, via via, vengono aggiunti al sistema. Queste difficoltà, tra le altre, hanno stimolato lo sviluppo dei DBMS. 1.2 Modelli dei dati Un modello dei dati è un formalismo matematico composto da due parti: una notazione per descrivere i dati; un insieme di operazioni per manipolare i dati. I modelli si suddividono in: Modelli concettuali; essi vengono utilizzati per descrivere i dati in maniera completamente indipendente dalla struttura del DBMS sottostante; tali modelli non sono disponibili su DBMS commerciali. Il loro nome deriva dal fatto che essi tendono a descrivere i concetti del mondo reale, piuttosto che i dati utili a rappresentarli. I modelli concettuali vengono utilizzati durante la fase preliminare del processo di progettazione di basi di dati, per analizzare nel modo migliore la realtà di interesse, senza preoccuparsi del DBMS con cui questa viene successivamente rappresentata. Il più importante modello concettuale è il modello Entità/Relazione. Modelli logici; essi sono gli effettivi modelli di riferimento per i vari DBMS; essi descrivono la realtà avendo come riferimento una strutturazione concreta dei dati (ad alberi, a grafi, a tabelle, ad oggetti). Modelli logici molto comuni sono il modello gerarchico, quello reticolare, quello relazionale e quello orientato agli oggetti. Il modello gerarchico è basato sull utilizzo di strutture ad albero, e quindi di gerarchie. Esso è stato definito agli albori della teoria delle basi di dati. Il modello reticolare (detto anche CODASYL, dal comitato di standardizzazione che lo definì con precisione) è stato sviluppato successivamente al modello gerarchico ed è basato sull uso dei grafi. Il modello relazionale rappresenta la realtà di interesse per mezzo di relazioni. Una relazione si può rappresentare mediante una tabella le cui righe rappresentano specifiche istanze e le cui colonne corrispondono a specifiche proprietà; l ordine delle righe e delle colonne è sostanzialmente irrilevante. Il modello ad oggetti, sviluppato negli anni 80 come evoluzione del modello relazionale, estende alle basi di dati il paradigma di programmazione orientata agli oggetti. 1.3 Schemi e Istanze Nelle basi di dati esiste una parte sostanzialmente invariante nel tempo, detta schema della base di dati, che definisce le caratteristiche e la struttura dei dati, ed una parte variabile nel tempo, detta istanza o stato della base di dati, che memorizza i valori effettivi. Ad esempio, consideriano un fornitore. Il corrispondente schema è dato dal codice, dal nome e dall indirizzo. Scriveremo:

10 4 1 Introduzione ai DBMS FORNITORE(Codice, Nome, Indirizzo) Le istanze rappresentano gli effettivi fornitori. Ad esempio: 1 Rossi Reggio Calabria 2 Bianchi Cosenza 3 Verdi Roma Lo schema prende anche il nome di componente intensionale della base di dati mentre le istanze rappresentano la sua componente estensionale. 1.4 Linguaggi per basi di dati Ad un DBMS possono essere associate due diverse tipologie di linguaggi: una tipologia viene utilizzata per definire lo schema della base di dati mentre l altra viene utilizzata per gestire l aggiornamento dei dati e la loro interrogazione Data Definition Language Uno schema di basi di dati viene specificato mediante un insieme di definizioni espresso mediante uno speciale linguaggio denominato Data Definition Language (DDL). Il risultato della compilazione delle istruzioni DDL è un insieme di tabelle che viene memorizzato in un file speciale denominato dizionario dei dati o directory dei dati. Un dizionario dei dati è un file che contiene metadati, ovvero dati sui dati. Tale file deve essere consultato dalle applicazioni prima che esse leggano o modifichino i dati effettivi del database Data Manipulation Language Per manipolazione dei dati intendiamo: l estrazione delle informazioni memorizzate nel database; l inserimento di nuove informazioni nel database; la cancellazione di informazioni dal database; la modifica di informazioni precedentemente memorizzate nel database. Un Data Manipulation Language (DML) è un linguaggio che permette agli utenti di accedere e manipolare i dati. Esistono fondamentalmente due tipologie di DML: I DML procedurali che richiedono ad un utente di specificare non solo quali sono i dati desiderati ma anche le modalità tramite cui recuperarli. I DML non procedurali che richiedono ad un utente di specificare quali sono i dati desiderati senza dover indicare le modalità tramite cui recuperarli. I DML non procedurali sono generalmente più facili da imparare e da utilizzare rispetto a quelli procedurali. Tuttavia, dal momento che un utente non deve specificare come recuperare i dati, essi possono generare codice che non è così efficiente come quello prodotto dai linguaggi procedurali. Una query è un istruzione che richiede l estrazione di informazioni. La porzione di un DML che si occupa dell estrazione delle informazioni viene denominata Query Language. Sebbene non sia tecnicamente corretto, è pratica comune utilizzare i termini Query Language e Data Manipulation Language come sinonimi.

11 1.5 Architettura di un DBMS 5 Istruzioni dell Utente Programma Applicativo Schema del Database Tabella delle Autorizzazioni Query Language Processor Database Manager Compilatore DDL Tabelle di Descrizione Tabella per il Controllo della Concorrenza File Manager Database Fisico Figura 1.1. I componenti di un DBMS 1.5 Architettura di un DBMS La Figura 1.1 illustra come interagiscono i linguaggi e i vari componenti di un DBMS. In alto a destra vediamo lo schema del database che, sottoposto al compilatore DDL, produce una descrizione interna del database. Le modifiche allo schema del database sono molto rare, rispetto alla frequenza con cui vengono eseguite le interrogazioni o altre manipolazioni. In un database multi-utente di notevoli dimensioni, tali modifiche vengono normalmente effettuate da un Database Administrator. Nella figura vediamo anche il Query Language Processor che riceve i programmi di manipolazione dei dati da due fonti: una fonte è costituita dalle istruzioni dell utente (per effettuare interrogazioni oppure operazioni di manipolazione) immesse direttamente dal terminale. La seconda fonte è data dai programmi applicativi, nei quali le istruzioni di interrogazione e di manipolazione dei dati vengono inserite in un linguaggio host e sottoposte al pre-processore per essere successivamente eseguite. Le parti di un programma applicativo scritte in un linguaggio host vengono gestite dal compilatore di tale linguaggio. Le parti di un programma applicativo costituite da istruzioni del linguaggio di manipolazione dei dati vengono gestite dal Query Language Processor che è responsabile dell ottimizzazione delle istruzioni stesse. Le istruzioni DML che estraggono i dati dal database, specialmente le query, sono spesso trasformate in modo significativo dal Query Language Processor in modo tale che possano essere eseguite più efficientemente rispetto a quanto accadrebbe se venissero eseguite così come sono scritte. Dalla figura si vede che il Query Language Processor accede alle tabelle di descrizione del database: queste sono state create dal compilatore DDL per avere alcune informazioni utili per l ottimizzazione delle interrogazioni, in particolare per conoscere l esistenza o meno di determinati indici. Al di sotto del Query Language Processor opera il Database Manager, il cui ruolo è quello di ricevere i comandi espressi ad alto livello di astrazione e di tradurli in comandi espressi a basso livello, in modo tale che gli stessi possano essere compresi dal File Manager. Il Database Manager gestisce la Tabella delle Autorizzazioni e la Tabella per il Controllo della Concorrenza. La Tabelle delle Autorizzazioni permette al Database Manager di controllare che l utente abbia il permesso di eseguire l interrogazione proposta o di modificare il database. Le variazioni a questa tabella vengono effettuate dal Database Manager in risposta a comandi effettuati da utenti adeguatamente autorizzati. La Tabella per il Controllo della Concorrenza consente di gestire l accesso contemporaneo agli stessi dati da parte di più programmi di interrogazione e manipolazione. Più specificatamente, qualunque istruzione volta a modificare una relazione deve poter bloccare (lock) la relazione stessa fino al suo completamento; è necessario, cioè, evitare che vi possano essere istruzioni simultanee e in conflitto tra di loro. La Tabella per il Controllo della Concorrenza viene utilizzata proprio per memorizzare i lock attivi.

12 6 1 Introduzione ai DBMS Il Database Manager traduce i programmi sottomessi dal Query Language Processor in operazioni sui file, che vengono gestite dal File Manager. Questo può essere un File System general purpose dotato di tutte le operatività del sistema, oppure un sistema specializzato. Per esempio, un File Manager specializzato può provare a porre in un unico cilindro di un disco quelle parti di un file a cui è probabile si acceda come ad un unica entità. Ciò minimizza il tempo di accesso ai dati dal momento che è possibile leggere l intera unità spostando la testina del disco soltanto una volta. Come altro esempio di File Manager specializzato consideriamo un File Manager che ottimizza la gestione della concorrenza. Tale tipologia di File Manager sarebbe particolarmente interessante in quanto, se è possibile associare lock a dati con granularità fine, si consentirà a più processi concorrenti di accedere al database. Se, per esempio, si pone un lock a livello dei singoli blocchi che costituiscono un grande file, diversi processi saranno in grado di accedere e modificare simultaneamente il file, se i dati di loro interessi si trovano in blocchi diversi del file.

13 2 Progettazione Concettuale In questo capitolo viene trattata la progettazione concettuale di una base di dati. Dopo una breve introduzione, ci concentreremo sullo strumento ancora più utilizzato per gestire tale progettazione, ovvero il modello E/R. Dopo di ciò esamineremo il Diagramma delle Classi di UML che, oramai, sta affiancando, ed in alcuni casi sostituendo, il modello E/R. Al termine illustreremo le regole da adottare per condurre con successo la progettazione concettuale di una specifica realtà. 2.1 Introduzione La progettazione concettuale di una base di dati consiste nella costruzione di uno schema concettuale in grado di descrivere al meglio la realtà di interesse. Anche nel caso di applicazioni non particolarmente complesse, lo schema che si ottiene può contenere molti concetti correlati in una maniera piuttosto complicata. Ne consegue che la costruzione dello schema finale è, necessariamente, un processo graduale: il nostro schema concettuale viene progressivamente raffinato e arricchito attraverso una serie di trasformazioni ed eventuali correzioni. La progettazione vera e propria è preceduta dalla raccolta e dall analisi dei requisiti. Questa fase non è completamente separata dalla progettazione, ma procede in molti casi parallelamente ad essa. Possiamo, infatti, definire uno schema concettuale quando non abbiamo ancora terminato di raccogliere e analizzare tutti i requisiti, per poi arricchirlo progressivamente man mano che le informazioni in nostro possesso aumentano. Il modello concettuale che noi utilizzeremo è il modello Entità/Relazione; questo è, sicuramente, il modello concettuale più utilizzato da coloro che operano in questo contesto. Esamineremo, comunque, anche il Diagramma delle Classi di UML che oramai sta affiancando, e in alcuni casi sostituendo, il modello Entità/Relazione. 2.2 Uno strumento per la progettazione concettuale: il modello E/R Il modello Entità/Relazione (E/R) è un modello concettuale di dati e fornisce una serie di strutture, detti costrutti, atte a descrivere la realtà di interesse in modo facilmente comprensibile e prescindendo dai criteri di organizzazione dei dati negli elaboratori. I costrutti messi a disposizione del modello E/R vengono utilizzati per definire schemi che rappresentano una specifica realtà secondo un determinato modello. Per ciascun costrutto del modello E/R esiste una rappresentazione grafica; essa consente di definire uno schema E/R mediante un opportuno diagramma che ne facilita la sua comprensione Entità Un entità è una classe di oggetti (fatti, persone) che hanno proprietà comuni ed esistenza autonoma ai fini dell applicazione di interesse; esempi di entità sono Città, Impiegato, Dipartimento. Un istanza di entità è un oggetto della classe rappresentata dall entità. Ad esempio, Roma e Milano sono istanze di Città mentre Rossi è istanza di Impiegato.

14 8 2 Progettazione Concettuale Un istanza di entità ha un esistenza ed un identità indipendente dalle proprietà ad essa associate. In questo senso, il modello E/R differisce da altri modelli, quali quello relazionale, in cui un oggetto è rappresentato dall insieme delle sue proprietà. In uno schema, ciascuna entità ha un nome che la identifica univocamente e viene rappresentata graficamente mediante un rettangolo con il nome dell entità all interno. In Figura 2.1 viene mostrata la rappresentazione grafica di alcune entità. Città Impiegato Dipartimento Vendita Figura 2.1. Alcuni esempi di entità Relazioni o Associazioni Le relazioni o associazioni rappresentano legami logici tra due o più entità. Risiede è un esempio di relazione che può sussistere tra Città e Impiegato. Un istanza di relazione è un ennupla (coppia nel caso più frequente di relazione binaria) costituita da istanze di entità, una per ciascuna delle entità coinvolte. La coppia di oggetti composta dall impiegato Rossi e dalla città di Roma è un esempio di istanza della relazione Risiede. In uno schema E/R ciascuna relazione ha un nome che la identifica univocamente e viene rappresentata graficamente mediante un rombo, con il nome della relazione all interno e con linee che lo connettono a ciascuna delle entità coinvolte (Figura 2.2). Città Risiede Impiegato Figura 2.2. Un esempio di Relazione Possono esistere relazioni diverse che coinvolgono le stesse entità, come le relazioni Risiede e Lavora tra le entità Città e Impiegato (Figura 2.3). Risiede Impiegato Città Lavora Figura 2.3. Tra le stesse entità vi possono essere diverse relazioni Tra le istanze di una relazione del modello E/R non vi possono essere ennuple ripetute. Questo aspetto ha importanti conseguenze. Per capire una delle più importanti consideriamo la Figura 2.4: in questo caso la relazione Segue non è in grado di descrivere il fatto che un determinato studente ha seguito più volte lo stesso corso. In tal caso, la frequenza andrebbe rappresentata mediante una entità legata mediante relazioni alle entità Studente e Corso. È anche possibile avere relazioni ricorsive, ovvero relazioni tra un entità e se stessa. Per esempio, nella Figura 2.5, la relazione ricorsiva Conosce sull entità Persona connette coppie di persone che si

15 2.2 Uno strumento per la progettazione concettuale: il modello E/R 9 Studente Segue Corso Figura 2.4. Tra le istanze di una relazione non vi possono essere ennuple ripetute conoscono, mentre la relazione Succede sull entità Sovrano associa a ciascun sovrano di una dinastia il suo immediato successore. Conosce Predecessore Succede Successore Persona Sovrano Figura 2.5. Due esempi di relazione ricorsiva Va osservato che la relazione Succede non è simmetrica. In questo caso è necessario specificare i due ruoli che l entità coinvolta gioca nella relazione: ciò può essere fatto associando degli identificatori (nel nostro caso Successore e Predecessore) alle linee uscenti dalla relazione ricorsiva. È possibile, infine, avere relazioni che coinvolgono più di due entità. Un esempio di ciò si ha nella Figura 2.6; la relazione Fornisce tra le entità Fornitore, Prodotto e Dipartimento descrive il fatto che ciascun fornitore può fornire un determinato prodotto ad un determinato dipartimento. Un possibile insieme di istanze di questa relazione potrebbe stabilire che la ditta Rossi fornisce Stampanti al dipartimento Vendite e Calcolatori al dipartimento Sviluppo, mentre la ditta Bianchi fornisce Calcolatori al dipartimento Ricerca e Fotocopiatrici al dipartimento Vendite. Fornitore Prodotto Fornisce Dipartimento Figura 2.6. Un esempio di relazione ternaria Attributi Gli attributi descrivono proprietà elementari di entità o relazioni di interesse ai fini dell applicazione. Per esempio, Cognome, Stipendio ed Età sono possibili attributi dell entità Impiegato, mentre Data e Voto lo sono per la relazione Segue tra Studente e Corso. Un attributo associa a ciascuna istanza di entità (o di relazione) un valore appartenente ad un insieme, detto dominio dell attributo, che contiene i valori ammissibili. Per esempio, l attributo Cognome dell entità Impiegato può avere come dominio l insieme delle stringhe di 20 caratteri. Nella Figura 2.7 viene mostrata la rappresentazione grafica degli attributi. I domini non vengono riportati nello schema ma sono generalmente descritti nella documentazione associata Può risultare comodo raggruppare attributi di una medesima entità o relazione che presentano affinità nel loro significato o uso: l insieme di attributi che si ottiene in questo modo viene denomi-

16 10 2 Progettazione Concettuale Data Esame Voto Matricola Anno di Iscrizione Studente Segue Corso Nome Anno di Corso Figura 2.7. Esempio di attributi nato attributo composto. Possiamo, per esempio, raggruppare gli attributi Via, Numero Civico e CAP dell entità Persona per formare l attributo composto Indirizzo. La rappresentazione grafica di un attributo composto viene mostrata nella Figura 2.8. Cognome Persona Età Sesso Via Indirizzo Numero Civico CAP Figura 2.8. Esempio di attributo composto Per ridurre la complessità degli schemi, nel seguito, gli attributi composti verranno usati raramente, preferendo usare, per quanto possibile, attributi atomici Costruzione di schemi con i costrutti di base I tre costrutti del modello E/R visti fino a questo momento ci consentono già di costruire schemi per descrivere realtà di una certa complessità. Si consideri, ad esempio, lo schema E/R di Figura 2.9. Dirige Codice Cognome Stipendio Età Impiegato Dipartimento Nome Telefono Afferisce Data Inizio Partecipa Data Afferenza Composta da Nome Budget Data Consegna Progetto Sede Città Via Numero Civico CAP Figura 2.9. Esempio di schema complesso Si comprende facilmente che questo schema rappresenta alcune informazioni di carattere organizzativo relative ad un azienda con diversi siti. Partendo dall entità Sede e procedendo in senso antiorario si può vedere che una sede dell azienda è dislocata in una città e ha un certo indirizzo (attributi Città e Indirizzo). Ciascuna sede è organizzata in dipartimenti (relazione Composta Da) e ciascun dipartimento ha un nome e un numero di telefono. A questi dipartimenti afferiscono, a partire da una certa data, gli impiegati dell azienda (relazione Afferisce e relativo attributo); vi sono impiegati che dirigono tali dipartimenti (relazione Dirige). Per gli impiegati vengono rappresentati il cognome, lo stipendio, l età e un codice che serve ad identificarli (entità Impiegato e relativi attributi).

17 2.2 Uno strumento per la progettazione concettuale: il modello E/R 11 Gli impiegati lavorano su progetti a partire da una certa data (relazione Partecipa e relativo attributo). Ciascun progetto ha un nome, un budget e una data di consegna (entità Progetto e relativi attributi) Cardinalità delle relazioni Le cardinalità delle relazioni vengono specificate per ciascuna entità che partecipa ad una relazione e descrivono il numero minimo e massimo di istanze di relazione a cui le istanze delle entità coinvolte possono partecipare. Esse dicono, quindi, quante volte, in una relazione tra entità, un occorrenza di una di queste entità può essere legata a occorrenze delle altre entità coinvolte nella relazione. Si consideri, ad esempio, la Figura In essa ad un impiegato deve essere assegnato almeno un incarico ma non più di cinque. Un determinato incarico può non essere assegnato a nessun impiegato oppure può essere assegnato a un numero di impiegati inferiore o uguale a 50. Impiegato (1,5) (0,50) Assegnato a Incarico Figura Esempio di cardinalità di relazione La cardinalità minima e massima delle entità di una relazione in uno schema E/R vengono specificate tra parentesi. Le cardinalità delle relazioni costituiscono dei vincoli di integrità, ovvero proprietà che occorrenze di entità e di relazioni devono soddisfare per poter essere considerate valide. In linea di principio è possibile assegnare un qualunque intero non negativo a una cardinalità di una relazione con l unico vincolo che la cardinalità minima deve essere minore o uguale di quella massima. In realtà, nella maggior parte dei casi, è sufficiente utilizzare solo tre valori: 0, 1 o il simbolo N (che indica, genericamente, un intero maggiore di 1). Per la cardinalità minima, i valori generalmente adottati sono 0 oppure 1; nel primo caso si dice che la partecipazione dell entità relativa è opzionale, nel secondo si dice che tale partecipazione è obbligatoria. Per la cardinalità massima, i valori generalmente utilizzati sono 1 oppure N. Consideriamo la Figura Osservando le cardinalità massime, è possibile classificare le relazioni binarie in base al tipo di corrispondenza che viene stabilita tra le istanze delle entità coinvolte. Ordine (0,1) (1,1) Relativo a Fattura Persona (1,1) (0,N) Risiede Città Turista (1,N) Prenota (0,N) Viaggio Figura Vari tipi di cardinalità Le relazioni aventi cardinalità massima pari ad 1 per entrambe le entità coinvolte, come la relazione Relativo a, definiscono una corrispondenza 1 ad 1 tra tali entità e vengono, quindi, denominate relazioni uno ad uno. In maniera analoga, le relazioni aventi un entità con cardinalità massima pari ad 1 e l altra con cardinalità massima pari ad N, come la relazione Risiede, vengono denominate relazioni uno a molti. Le relazioni aventi cardinalità massima pari ad N per entrambe le entità coinvolte, come la relazione Prenota, vengono denominate relazioni molti a molti.

18 12 2 Progettazione Concettuale Per le cardinalità minime va detto, invece, che il caso di partecipazione obbligatoria per tutte le entità coinvolte è piuttosto raro, perchè quando si aggiunge una nuova istanza di entità molto spesso non sono note le corrispondenti istanze di entità collegate attraverso relazioni. Per esempio, quando si riceve un nuovo ordine, non esiste ancora una fattura ad esso relativa e non è, quindi, possibile costruire un occorrenza della relazione Vende che contiene il nuovo ordine. Nelle relazioni n-arie le entità coinvolte partecipano quasi sempre con cardinalità massima pari ad N. Un esempio concreto viene fornito dalla relazione ternaria Fornisce; in questo esempio le istanze di ciascuna delle entità coinvolte partecipano a più istanze di tale relazione. Nel caso in cui un entità partecipa ad una relazione n-aria con cardinalità massima pari ad 1, si ha che che ogni sua occorrenza può essere legata ad una sola occorrenza della relazione e, quindi, ad un unica n-upla di occorrenze delle altre entità coinvolte nella relazione. Ciò implica che è possibile eliminare la relazione n-aria mediante delle procedure di normalizzazione che vedremo successivamente Cardinalità degli attributi Le cardinalità di un attributo descrivono il numero minimo e massimo di valori dell attributo associati a ciascuna occorrenza di entità o di relazione. Nella maggior parte dei casi la cardinalità di un attributo è pari a (1,1) e viene omessa. In questi casi l attributo rappresenta sostanzialmente una funzione che associa ad ogni occorrenza di entità uno ed un solo valore. Il valore per un certo attributo può essere nullo oppure possono esistere diversi valori di un determinato attributo associati ad un occorrenza di entità. Queste situazioni possono essere rappresentate associando all attributo in questione una cardinalità minima pari a 0 nel primo caso ed una cardinalità massima pari ad N nel secondo. Si consideri l esempio di Figura 2.12; in esso una persona ha uno ed un solo cognome, può avere o non avere un numero di patente, ma se ne ha uno è unico, può non avere automobili, ma può anche possedere più di una. Persona (0,N) (0,1) Targa automobile Cognome Numero patente Figura Esempio di cardinalità di attributo Le cardinalità degli attributi costituiscono dei vincoli di integrità, ovvero proprietà che occorrenze di entità e di relazione devono soddisfare per poter essere considerate valide. Un attributo con cardinalità minima pari a 0 è opzionale per la relativa entità, mentre è obbligatorio se la cardinalità minima è pari ad 1. Diremo, infine, che l attributo è multivalore se la sua cardinalità massima è pari ad N. In molte situazioni reali accade che alcune informazioni non sono disponibili ed è, quindi, utile avere la possibilità di specificare attributi opzionali. Gli attributi multivalore vanno, invece, utilizzati con maggiore cautela, perchè essi rappresentano situazioni che possono essere modellate, in alcune occasioni, con entità a sè, legate da relazioni uno a molti (o molti a molti) con l entità cui si riferiscono. Ad esempio, abbiamo detto che una persona può avere più automobili. L automobile è comunque un concetto a sè e può essere condiviso da altre entità: può risultare, quindi, più naturale modellarlo con un entità a parte legata all entità Persona da una relazione uno a molti (si veda la Figura 2.13). Il discorso verrà approfondito successivamente. Nome Numero Patente (0,1) Persona (0,N) Possiede (0,1) Automobile Figura Modellazione alternativa di alcune cardinalità di attributi

19 2.2.7 Identificatori o chiavi delle entità 2.2 Uno strumento per la progettazione concettuale: il modello E/R 13 Gli identificatori o chiavi delle entità descrivono i concetti dello schema che permettono di identificare in maniera univoca le occorrenze delle entità. In molti casi, uno o più attributi di un entità sono sufficienti ad individuare un identificatore: si parla, in questo caso, di identificatore interno (detto anche chiave). Per esempio, la targa è chiave per un automobile e gli attributi nome, cognome e data di nascita formano una chiave per una persona. In uno schema E/R gli identificatori si rappresentano come specificato nella Figura Targa Cognome Automobile Modello Persona Nome Data di Nascita Colore Indirizzo Figura Rappresentazione degli identificatori in uno schema E/R Alcune volte, però, gli attributi di un entità non sono sufficienti ad identificare univocamente le sue occorrenze. Si consideri, per esempio, l entità Studente in Figura Può sembrare, a prima vista, che l attributo Matricola possa essere un identificatore per tale entità; tuttavia, ciò non è vero: lo schema descrive, infatti, studenti iscritti a varie università e due studenti iscritti ad università diverse possono avere lo stesso numero di matricola. In questo caso, per identificare univocamente uno studente serve, oltre al numero di matricola, anche la relativa università. Quindi, un identificatore corretto per l entità Studente in questo schema è costituito dall attributo Matricola e dall entità Università. Questa identificazione è resa possibile dalla relazione uno a molti tra le entità Università e Studente, che associa ad ogni studente una ed una sola università. Quindi un entità E può essere identificata da altre entità solo se queste ultime sono coinvolte in relazioni a cui E partecipa con cardinalità (1,1). Nei casi in cui l identificazione di un entità è ottenuta utilizzando altre entità si parla di identificatore esterno. La rappresentazione diagrammatica di un identificatore esterno è riportata nella Figura Matricola Anno Cognome Studente (1,1) (1,N) Iscritto Università Nome Città Indirizzo Figura Rappresentazione di una chiave esterna in uno schema E/R Un identificazione esterna può coinvolgere diverse entità (purchè legate con relazioni cui l entità partecipa con cardinalità pari a (1,1)). Un identificazione esterna può coinvolgere un entità che è, a sua volta, identificata esternamente, purchè non vengono generate, in questo modo, cicli di identificazioni esterne (perchè, in questo caso, non sarebbe più possibile identificare alcuna entità). Concludendo il nostro discorso sugli identificatori osserviamo che ogni entità deve avere almeno un identificatore (interno o esterno), ma ne può avere in generale più di uno; nel caso di più identificatori, gli attributi e le entità coinvolte in alcune identificazioni (tranne una) possono essere opzionali (ovvero, possono avere cardinalità minima uguale a zero). Riportando i concetti visti finora nello schema di Figura 2.9 si ottiene una sua versione più raffinata illustrata in Figura Si può osservare che il nome di una città identifica una sede dell azienda: questo vuol dire che non c è più di una sede nella stessa città. Un dipartimento è invece identificato dal nome e dalla sede di cui fa parte (dalle cardinalità si evince che una sede ha diversi dipartimenti ma ogni dipartimento fa parte di una sola sede). Un dipartimento ha almeno un numero di telefono, ma può averne più di uno. Un impiegato (identificato da un codice) può afferire a un solo dipartimento (ma può accadere che non afferisca a nessun dipartimento, per esempio se appena assunto) e può dirigere o zero o un dipartimento. Viceversa, ogni dipartimento ha un solo direttore e uno o più impiegati. Sui progetti (identificati univocamente dal loro nome) lavorano diversi impiegati (almeno uno) e ogni impiegato

20 14 2 Progettazione Concettuale (0,1) Dirige (1,1) Codice Cognome Stipendio Età Impiegato (0,N) Dipartimento (1,1) (1,N) Telefono Nome (0,1) Afferisce (1,N) Data Inizio Partecipa Data Afferenza Composta da (1,N) (1,N) Nome Budget Data Consegna (0,1) Progetto Sede Indirizzo Città Via Numero Civico CAP Figura Raffinamento dello schema complesso di Figura 2.9 lavora in generale su più progetti (ma può accadere che non lavori a nessun progetto). Infine, la data di scadenza di un progetto può non essere nota Generalizzazioni Le generalizzazioni rappresentano legami logici tra un entità E, detta entità padre, e una o più entità E 1, E 2,..., E n, dette entità figlie, di cui E è più generale. Si dice in questo caso che E è generalizzazione di E 1, E 2,..., E n e che le entità E 1, E 2,..., E n sono specializzazioni dell entità E. Per esempio, l entità Persona è una generalizzazione delle entità Uomo e Donna mentre Professionista è una generalizzazione delle entità Ingegnere, Medico e Avvocato. Le entità Uomo e Donna sono specializzazioni dell entità Persona. Ogni occorrenza dell entità figlia è anche un occorrenza dell entità padre. Per esempio, un occorrenza di Avvocato è anche un occorrenza di Professionista. Ogni proprietà dell entità padre (attributi, identificatori, relazioni e altre generalizzazioni) è anche una proprietà delle entità figlie. Per esempio se l entità Persona ha attributi Cognome ed Età, anche le entità Uomo e Donna possiedono questi attributi. Inoltre, l identificatore di Persona è un identificatore valido anche per le entità Uomo e Donna. Questa proprietà delle generalizzazioni è nota sotto il nome di ereditarietà. Le generalizzazioni vengono rappresentate graficamente mediante delle frecce che congiungono le entità figlie con l entità padre. Per le entità figlie, le proprietà ereditate non vengono rappresentate esplicitamente. Alcuni esempi di generalizzazioni vengono riportati in Figura Una stessa entità può essere coinvolta in più generalizzazioni diverse. Possono esserci, inoltre, generalizzazioni su più livelli: si parla in questo caso di gerarchia di generalizzazioni. Infine, una generalizzazione può avere una sola entità figlia: si parla in questo caso di sottoinsieme o di relazione isa. A titolo di esempio, in Figura 2.17, il legame che esiste tra l entità Responsabile di Progetto e Progettista rappresenta una relazione isa Documentazione degli schemi E/R È buona norma corredare uno schema E/R con una documentazione di supporto che possa facilitare l interpretazione dello schema stesso e possa descrivere proprietà dei dati rappresentati che non possono essere espressi direttamente dai costrutti del modello. I concetti rappresentati in uno schema possono essere descritti facendo uso di un dizionario dei dati. Esso è composto da due tabelle: la prima presenta le entità dello schema (in particolare, il nome), una descrizione informale, l elenco degli attributi e degli identificatori (si veda la Tabella 2.1);

21 2.2 Uno strumento per la progettazione concettuale: il modello E/R 15 Persona Codice Fiscale Cognome Nome Età Uomo Donna Impiegato Studente Numero Parti Stipendio Matricola Orario Segretario Direttore Progettista Responsabile dei Progetti Figura Rappresentazione delle generalizzazioni ENTITÀ DESCRIZIONE ATTRIBUTI IDENTIFICAZIONE Impiegato Impiegato che lavora Codice, Cognome, Codice nell azienza Stipendio, Età Tabella 2.1. Dizionario delle Entità RELAZIONE DESCRIZIONE ENTITÀ COINVOLTE ATTRIBUTI Dirige Associa un dipartimento Impiegato (0,1), - al suo direttore Dipartimento (1,1) Tabella 2.2. Dizionario delle Relazioni la seconda presenta le relazioni dello schema (in particolare il nome), una descrizione informale, l elenco degli attributi e le entità coinvolte (si veda la Tabella 2.2). Un aspetto molto importante che uno schema E/R non riesce a documentare è la presenza di vincoli di integrità sui dati. Ad esempio un impiegato può essere direttore solo del dipartimento a cui afferisce: questa proprietà non può essere espressa direttamente sullo schema perchè fa riferimento a due concetti (Dirige e Afferisce) che sono indipendenti e non possono essere correlati. Come ulteriore esempio, un vincolo di integrità potrebbe stabilire che un impiegato non può avere uno stipendio maggiore del direttore del dipartimento al quale afferisce. In questi casi si aggiungono allo schema delle annotazioni che completano la descrizione delle proprietà associate ai concetti presenti nello schema e non esprimibili altrimenti. Un esempio di tali annotazioni è rappresentato nella Tabella 2.3. Identif. Regola Regola A1 Il direttore di un dipartimento deve afferire a tale dipartimento A2 Un impiegato non deve avere uno stipendio maggiore del direttore del direttore del dipartimento al quale afferisce A3 Un dipartimento con sede a Roma deve essere diretto da un impiegato con più di dieci anni di anzianità A4 Un impiegato che non afferisce a nessun dipartimento non deve partecipare a nessun progetto Tabella 2.3. Annotazioni allo schema E/R

22 16 2 Progettazione Concettuale Ulteriori usi degli schemi E/R Abbiamo detto più volte che gli schemi E/R costituiscono utili strumenti nelle attività di progettazione delle basi di dati. In realtà, tali schemi, fornendo rappresentazioni astratte dei dati di un applicazione, possono essere utilizzati con profitto anche per attività non strettamente legate alla progettazione. Si possono fare a tale riguardo diversi esempi: gli schemi E/R possono essere utilizzati a scopo documentativo, poichè sono facilmente comprensibili anche da non specialisti di basi di dati; gli schemi E/R possono essere utilizzati per descrivere i dati di un sistema informativo già esistente (per esempio per integrarlo con altri) e, nel caso di sistema costituito da diversi sottosistemi, c è il vantaggio di poter rappresentare le varie componenti con un linguaggio astratto e, quindi, unificante; gli schemi E/R possono essere utilizzati per comprendere, in caso di modifica dei requisiti di un applicazione, in quali porzioni del sistema si deve operare e in che cosa consistono le modifiche da effettuare. 2.3 Regole di progettazione concettuale Qualunque sia la strategia prescelta, è possibile stabilire alcuni criteri generali per tradurre una specifica informale in un costrutto del modello entità-relazione. Spesso non esiste una rappresentazione univoca di un insieme di specifiche, perchè la stessa realtà può essere rappresentata in modi differenti e non comparabili. Comunque, quando ci si trova davanti a diverse possibilità, è utile avere delle indicazioni sulle scelte più opportune. Se un concetto ha proprietà significative e/o descrive classi di oggetti con esistenza autonoma, è opportuno rappresentarlo con un entità. Per esempio, è naturale rappresentare il concetto di docente con un entità, in quanto possiede diverse proprietà (cognome, età, data di nascita) e la sua esistenza è, in qualche modo, indipendente dagli altri concetti. Chiaramente, lo stesso discorso vale anche per concetti astratti come, ad esempio, quello di corso. Se un concetto ha una struttura semplice e non possiede proprietà rilevanti associate, è opportuno rappresentarlo come attributo di un altro concetto a cui si riferisce. Per esempio, il concetto di età è certamente da rappresentare come attributo dei partecipanti ai corsi. In effetti, in questa applicazione, anche il concetto di città, che a prima vista può sembrare un concetto autonomo e strutturato, è opportuno che sia rappresentato come attributo perchè, oltre al nome, non è di interesse nessuna altra proprietà. Se sono state individuate due (o più) entità e nei requisiti compare un concetto che le associa, esso può essere rappresentato da una relazione. Per esempio, nella nostra applicazione, il concetto di partecipazione a un corso è certamente rappresentabile da una relazione tra le entità che rappresentano i partecipanti e i corsi. È importante sottolineare il fatto che questo vale solo nel caso in cui il concetto in questione non abbia, esso stesso, le caratteristiche delle entità. Un esempio tipico e già citato è il concetto di esame relativo a studenti e corsi. Questo concetto può essere rappresentato con una relazione tra studente e corso nel caso in cui interessa, per esempio, solo la votazione. Ma se dell esame sono di interesse anche la data, la sessione, la commissione e, soprattutto, vogliamo descrivere il fatto che lo stesso studente può sostenere più volte un esame per lo stesso corso, allora l esame va rappresentato con un entità collegata da relazioni uno a molti con le entità che rappresentano gli studenti e i corsi. Se uno o più costrutti risultano essere casi particolari di un altro, è opportuno rappresentarli facendo uso di una generalizzazione. 2.4 Esercizi Esercizio Si effettui la progettazione concettuale di un sistema informativo per la gestione di un hotel capace di gestire almeno le seguenti informazioni: