Progettazione Logica di un Database: Entita', Relazioni e Integrità Referenziale, Dispense di Ingegneria del Software

Scarica Progettazione Logica di un Database: Entita', Relazioni e Integrità Referenziale e più Dispense in PDF di Ingegneria del Software solo su Docsity!

La Progettazione

dei database

relazionali

Crescenzio GALLO

Università di Foggia

PARTE PRIMA

Il Modello Logico dei Dati

1. I DATI E LA LORO FORMALIZZAZIONE

Durante il loro utilizzo in uno schema informativo organizzato, i dati subiscono diverse modificazioni: la loro analisi fornisce alcuni spunti interessanti per la comprensione della natura degli stessi. Si possono indivi- duare tre stadi distinti attraverso i quali i dati transitano: dati di input , prima che essi vengano introdotti stabil- mente nello schema, quando sono ancora isolati e le loro associazioni non sono ancora stabilizzate; a caricamento effettuato i dati occupano il posto loro destinato nello schema informativo ed attivano le associazioni logiche da essi realizzate: in questa fase si parlerà di dati operazionali. Quando lo schema informativo viene interrogato, e vengono ricercati i dati opportuni navigando attraverso lo schema e le sue associazioni logiche, ed infine i dati richiesti vengono presentati abbiamo i dati di output. In prima approssimazione possiamo dire che un database è una collezione di dati operazionali memoriz- zati ed utilizzati dalle applicazioni di un’organizzazione. I dati operazionali possono riguardare prodotti, fatti amministrativi, pazienti di un ospedale, studenti di un’università, pianificazioni di un’organizzazione. I dati di input diventano operazionali quando si integrano col resto del contenuto del database. I dati di output sono deri- vati da quelli operazionali per elaborazione (ordinamento, classificazione, aggregazione, selezione, etc.). I dati operazionali sono tali perché collegati tra di loro tramite associazioni, che sono dunque parte integrante dei dati. I dati sono concettualmente separati nelle loro componenti costitutive essenziali: entità ed associazioni. Le entità sono gli oggetti fisici, i documenti, le persone; le associazioni i fatti che le coinvolgono. Il modello ispi- rato a queste considerazioni è noto come “modello entità-associazioni” (Entity-Relationship Model, la cui data di nascita risale al 1976, anno della pubblicazione su ACM TODS di un famoso articolo di Peter Chen) ed è uno dei più potenti nel catturare il significato dei dati, indipendentemente dal modello concettuale di database (gerarchi- co, reticolare, relazionale) impiegato, e consente di progettare le basi di dati con un margine molto ridotto di in- determinazione semantica.

2. L’ARCHITETTURA ANSI / SPARC Nel 1972 il comitato X3 dell’ANSI (American National Standard Institute) su proposta dello SPARC (System Planning and Requirements Committee) ha costituito un gruppo di studio con lo scopo di fornire alcuni standard nella realizzazione degli aspetti funzionali di un DBMS (Database Management System): senza entrare nel dettaglio delle implementazioni fisiche, il gruppo ANSI/SPARC ha infine nel 1978 fornito una visione unita- ria delle interfacce dei DBMS e dei meccanismi di visibilità logica delle entità fisiche che compongono un data- base (vedi fig.1) nel noto documento “The ANSI/X3/SPARC DBMS Framework: Report of the Study Group on Database Management Systems”. L’indicazione fondamentale derivata da tale studio è il concetto di architettura a tre livelli per i database: il livello di riferimento è la definizione (schema) concettuale del database; a questo corripondono (da parti opposte) il livello del database fisico ospite della macchina e del suo software di base, ed il livello esterno attraverso il quale il database viene percepito dagli utenti. 3. IL MODELLO ENTITÀ-ASSOCIAZIONI Lo scopo del modello entità-associazioni (Entity/Relationship, E/R) è quello di permettere la descrizione dello schema concettuale, senza preoccuparsi dell’efficienza o della progettazione del database fisico. Un’ entità è un qualcosa che può essere distintamente riconosciuto. Le entità possono essere classificate in tipi di entità , come ad es. PARTI e PROGETTI in fig.2; nei diagrammi E/R un’entità è rappresentata da un rettangolo. Ci sono molte “cose” nel mondo reale: alcune di interesse per l’organizzazione da modellare, altre no. È responsabilità del pro- gettista del DB decidere quali sono di interesse e quali no per la base dei dati da rappresentare e gestire. Le asso- ciazioni (da non confondere con le tabelle o relazioni del modello di database relazionale, come si vedrà nella parte seconda) possono esistere tra entità. Per esempio l’associazione MATRIMONIO è una relazione tra due tipi di entità di persone. Le associazioni possono essere classificate in tipi di associazioni. Ad esempio, PROG-IMP e PROG-DIR sono due differenti tipi di associazioni tra due tipi di entità (impiegati e progetti). Nei diagrammi E/R un’associazione è rappresentato da una figura romboidale con delle linee connesse alle entità relazionate. Pos- siamo considerare vari tipi di associazioni, come evidenziato in fig.2. La nozione di n e di 1 presente nell’associazione PROG-DIR indica che il progetto ha un solo direttore, ma che un impiegato può essere il diret-

PROGETTI PROG- IMPIEGATI

DIR

PROGETTI IMPIEGATI

PROG-

IMP

Fig. 2 - Entità e Associazioni

n 1 m (^) n

relazione originale scomposizione della relazione originale in tre relazioni binarie PART FORN PROG 25 4 1 25 4 2 25 5 1 25 5 2 10 4 2 10 4 3 “non fatti” } informazione generata da un join delle tre relazioni binarie PART FORN PROG 25 4 1 25 5 2 10 4 2 10 4 3 17 2 5 17 5 1 PART FORN 24 4 25 5 10 4 17 2 17 5 FORN PROG 4 1 4 2 4 3 5 1 2 1 PROG PART 1 25 1 17 2 10 2 25 3 10

Fig. 3 - Scomposizione di relazioni

È anche possibile che tale dipendenza di esistenza sia di tipo molti-a-molti. Si ha una dipendenza ID quando un’entità non è univocamente determinata dai suoi propri attributi e deve essere determinata anche da al- tre entità. Ad esempio, una strada è unica solo in una città, una città solo in uno stato. Per cui, per identificare l’indirizzo di un luogo, oltre al nome della strada, bisogna specificare il nome della città ed il nome dello stato. PROGETTI IMPIEGATI PROG- IMP data-inizio 7/4/ 5/9/ 4/12/

IMPIEGATI

0401 0411 0428 34465 32789 978510 35 42 52 matricola

n.ro tel.

Fig. 4 - Attributi di Entità ed Associazioni

E

IMPIEGATI

m n

E

IMPIEGATI

n BAMBINI (^) BAMBINI

Fig. 5 - Dipendenza di Esistenza

anche se il padre lascia la ditta, il bambino viene ancora considera- to se la madre è impiegata.

4. TRADUZIONE DEL MODELLO ENTITÀ-ASSOCIAZIONI

La traduzione del diagramma E/R in un diagramma per strutture di dati avviene molto semplicemente. Questa volta si useranno solo forme rettangolari per tipi di record (intesi nella terminologia classica dei file) o tabelle (nella terminologia dei database relazionali). La freccia in tali casi rappresenta gli insiemi di strutture dei dati e connette sempre due tipi di record. Il record in cui la freccia è originata viene detto record owner, e quello in cui la freccia termina viene detto member della struttura di dati. In questi insiemi di strutture il record member ha esattamente un solo record owner, mentre il record owner può avere zero, uno o più record member. Ci sono diverse regole basilari per tale traduzione, basate sul tipo di relazione tra entità. Esse possono essere così riassun- te. 4.1. Relazioni definite su due differenti tipi di entità a) Se la relazione è uno-a-molti (oppure uno-a-uno) come quella mostrata in fig.7a, essa può essere trasformata in una equivalente come quella in fig.7b. In questo caso i tipi di entità sono trattati come record, mentre la re- lazione è rappresentata da una freccia. DIP - IMP

DIPARTIMENTI

n IMPIEGATI

Fig. 7a - Diagramma E/R

DIPARTIMENTI

IMPIEGATI

Fig. 7b - Diagramma Dati

b) Se la relazione è di tipo molti-a-molti (come la relazione in fig.8a) essa verrà trasformata in una relazione equivalente come quella in fig.8b. In questo caso il tipo di relazione non è trasformato in una freccia, ma piuttosto come un tipo di record. Cioè se un tipo di relazione è una corrispondenza molti-a-molti essa sarà tradotta in un tipo di record con due frecce che provengono dalle entità relazionate. DIP - IMP

PROGETTI

m n IMPIEGATI

Fig. 8a - Diagramma

E/R

PROGETTI

DIP - IMP

Fig. 8b - Diagramma Dati

IMPIEGATI

4.3. Relazioni binarie definite sullo stesso tipo di entità Una relazione binaria definita sullo stesso tipo di entità (come la relazione MATRIMONIO in fig.10a) potrà esse- re trasformata in un diagramma di strutture dati in due diverse maniere, come in fig.10b e fig.10c. Nel caso in cui una particolare implementazione di databse non permetta allo stesso tipo di record (tabella) di essere usato allo stesso tempo sia come owner che come member, si farà solo uso della fig.10c per tradurre la situazione descritta in fig.10a. Essa si usa anche nel caso di relazioni molti-a-molti.

Fig.10a Fig.10b Fig.10c

Diagramma E/R Diagramma Dati Diagramma Dati

PERSONA

DIRETTA-

DA

1 n

PERSONA PERSONA

DIRETTA-DA

PROGETTI

DIPARTIMENTI

IMPIEGATI

DIP-IMP

PROG-

IMP

PROG-DIR FORNITORI PROG-FORN- PARTI POTEN-FORN (^) PARTI PARTI- COSTITUT. INVENTARIO MAGAZZINI n 1 m 1 n n m p n m n m n n m

Fig. 11 - Diagramma E/R azienda manifatturiera

Fig. 12 - Attributi per le entità DIPARTIMENTI e IMPIEGATI e

l’associazione DIP-IMP

NUM_IMP DATA_NAS TELEFONO

DIPARTIMENTI IMPIEGATI

BILANCIO DIP-IMP NUM_DIP attuale ultimo BILANCIO STIPENDIO c a s a u f f i c i o NUM_DIP NUM_IMP STIPENDIO DATA NUM_TEL

alto livello basso livello NUME- RO_PRO G NOME_ PROG BILANCIO 1 n IMPIEGATI PROGETTI PROG- IMP data_inizio DATA PROG- DIR m n PASSIVO

Fig. 13 - Attributi per le entità IMPIEGATI e PROGETTI e le

associazioni PROG-DIR e PROG-IMP

alto livello basso livello n MAGAZZINI (^) m

PARTI

a disposizione necessaria QUANTITÀ INVENTA- RIO m n INDIRIZ- ZOO

Fig. 15 - Attributi per le entità MAGAZZINI e PARTI e le as-

sociazioni INVENTARIO e PARTI-COSTITUTIVE

NUM_MAG PARTI- COSTITUT.

DIPARTIMENTI^ • IMPIEGATI PROGETTI PROG- IMP

FORNITORI

PROG-FORN-

PART

PARTI

PARTI- COSTITUT. INVENTARIO POTEN- FORN

MAGAZZINI

Fig. 16 - Il diagramma di struttura dei dati per la fig.