Progettazione logica - Obiettivi del progetto

2.4 Obiettivi del progetto

4.1.3 Progettazione logica

L’obiettivo della progettazione logica è quello di costruire uno schema logico in grado di descrivere, in maniera corretta ed efficace, tutte le informazioni

contenute nello schema Entità-Relazione prodotto nella fase di progettazione concettuale.

Diciamo subito che non si tratta di una semplice traduzione da un modello ad un altro perché, prima di passare allo schema logico, lo schema Entità- Relazione va ristrutturato per soddisfare due esigenze: quella di semplificare la traduzione e quella di ottimizzare il progetto. La semplificazione dello schema si rende necessaria perché non tutti i costrutti del modello Entità- Relazione hanno una traduzione naturale nei modelli logici. Per esempio, mentre un’entità può essere facilmente rappresentata da una relazione nel modello relazionale, per le generalizzazioni esistono varie alternative. Inoltre, mentre la progettazione concettuale ha come obiettivo la rappresentazione ac- curata e naturale dei dati di interesse dal punto di vista del significato che hanno nell’applicazione, la progettazione logica costituisce la base per l’effet- tiva realizzazione dell’applicazione e deve tener conto, per quanto possibile, delle sue prestazioni: questa necessità può portare a una ristrutturazione dello schema concettuale che renda più efficiente l’esecuzione delle operazioni previste. Pertanto, è necessario prevedere sia un’attività di ristrutturazione, sia un’attività di traduzione (dal modello concettuale a quello logico) [Atzeni 09].

La fase di ristrutturazione dello schema E-R si compone di quattro fasi: 1. Eliminazione delle generalizzazioni

2. Analisi ed eventuale eliminazione delle ridondanze 3. Partizionamento/accorpamento di entità e relazioni

4. Scelta degli identificatori primari Eliminazione delle generalizzazioni

Il modello relazionale non è in grado di rappresentare direttamente le generalizzazioni, diventa quindi necessario scomporre tali costrutti in una combinazione di costrutti più semplici, ovvero un insieme di entità e relazioni. Tale scomposizione può essere eseguita in tre modalità differenti a seconda delle caratteristiche che l’applicazione obiettivo dovrà avere [Atzeni 09].

a) Accorpamento delle figlie della generalizzazione nel genitore. Si ag- giunge al genitore un attributo che indichi il “tipo” dell’individuo (a quale entità figlia eventualmente appartiene) Si aggiungono al padre gli attributi e le associazioni dei figli, che diventano opzionali Questa modalità è sempre applicabile, ma comporta la presenza di attributi e associazioni opzionali e l’aggiunta di vincoli.

b) Accorpamento del genitore della generalizzazione nelle figlie Per l’ere- ditarietà, attributi e associazioni del genitore vanno aggiunti a tutti i figli. Tale scelta è possibile solo se la generalizzazione è totale ed esclusiva.

c) Sostituzione della generalizzazione con relazioni Si aggiungono nuo- ve relazioni che rappresentano la generalizzazione. I figli partecipano obbligatoriamente all’associazione, il genitore opzionalmente.

Lo schema E-R prodotto dalla progettazione concettuale ha al suo interno tre generalizzazioni, tutte complete ed esclusive. Queste generalizzazioni sono

ENTITA’ PADRE ENTITA’ FIGLIE Captazione Fiume Lago Pozzo Sorgente Impianto Captazione Potabilizzatore Pompaggio Accumulo Rete Adduzione_{Distribuzione}

Tabella 4.3: Generalizzazioni dello schema d’acquedotto.

indicate nella Tabella 4.3. Analizziamo ognuna di esse per capire quale scelta è più adatta a garantire l’efficienza e l’integrità del database.

Dato che tutti i padri sono coinvolti in relazioni con altre entità e i figli possiedono numerosi attributi non comuni tra loro, la scelta più conveniente è la sostituzione delle generalizzazioni con delle relazioni 1 a 1. La scelta garan- tisce la diponibilità di tutte le istanze del padre senza ricorrere a giunzioni con i figli e permette il soddisfacimento dei vincoli di integrità referenziale sulle entità padre. È infatti impossibile creare una tabella che riferisca contemporaneamente a più tabelle.

In altre parole, affinché si possano utilizzare vincoli di integrità riferiti a tutte le entità figlie di una generalizzazione dovrò obbligatoriamente mantenere una tabella che raccolga tutte le istanze dell’entità padre. Tale soluzione porta ad una ridondanza, il codice dell’impianto sarà infatti presente sia nel- l’entità padre che nelle entità figlie. Il mantenimento della ridondanza, anche se causa uno spreco di spazio, si giustifica sia con un più efficiente accesso alle istanze dell’entità padre sia con una piu alta qualità della base di dati

dovuta all’utilizzo massimizzato di vincoli di integrità referenziale. Analisi ed eventuale rimozione delle ridondanze

Una ridondanza in uno schema E-R è una informazione significativa, ma derivabile da altre. Nello schema E-R di partenza è presente una sola ridondanza. L’entità sostanze è in relazione sia con l’entità impianti che con l’entità reti e a loro volta queste due entità sono in relazione tra loro. Dato che AIT è interessata sia alle sostanze presenti negli impianti sia a quelle presenti nelle reti, con particolare riguardo alle reti di distribuzione, si opta per il mantenimento di tale ridondanza. Ricavare le sostanze presenti in una rete dalle sostanze presenti negli impianti che ne fanno parte rischierebbe di creare incongruenze e relativa confusione su un argomento di rilevante interesse per AIT. Potrebbe infatti accadere che una sostanza presente nell’acqua trattata da un potabilizzatore non rimanga nella rete una volta effettuato il trattamento.

Partizionamento ed accorpamento di entità e associazioni Tali ristrutturazioni si effettuano per rendere più efficienti determinate operazioni, ovvero per diminuire il numero di accessi richiesti [Atzeni 09].

Nel nostro particolare caso non ci troviamo a dover effettuare scelte di questo genere. Essendo partiti da ciò che AiT richiede, effettuare partizio- namenti ed accorpamenti causerebbe ovviamente un lavoro supplementare al momento della creazione del report complessivo richiesto.

Scelta degli identificatori primari

Tale operazione è fondamentale per la traduzione nel modello relazionale. Anche in questo caso sfruttando la documentazione fornitoci da AiT si capisce la convenienza nel mantenere i codici scelti, onde evitare inutili operazioni di

adattamento successive.

Nello schema E-R ristrutturato (Fig. 4.7) prodotto in questa prima fase della progettazione logica , si vedono le scelte fatte per l’eliminazione delle generalizzazioni e per la scelta degli identificatori primari.

Ristrutturato lo schema E-R affinché possa essere rappresentato tramite un modello relazionale, passiamo a tradurre una ad una ogni associazione in modo che venga mantenuta integrità e coerenza nell’informazione. Per comodità, nello spiegare le logiche di traduzione , omettiamo le lunghe liste di attributi anagrafici che AiT richiede per caratterizzare ogni entità e uti- lizziamo pseudo codice per definire chiaramente gli identificatori primari e i vincoli di integrità referenziale.

Partiamo dall’associazione tra impianti e nodi. Essendo un’associazione uno a uno inseriamo nella tabella impianti un attributo che indica il nodo in cui l’impianto è localizzato. Costituiamo su questo attributo aggiunto un vincolo di integrità nei confronti dell’identificatore della tabella nodi.

Impianti: • ids_codice (PK) • numNodo (FK) • altri attributi Nodi: • idNodo (PK) Vincoli integrità referenziale:

• Impianti.numNodo references to Nodi.idNodo

Continuiamo ad analizzare le associazioni sulla tabella Impianti. Le pompe sono collegate a impianti con associazione uno a molti. Abbiamo tradot- to questa associazione aggiungendo alla tabella Pompe un attributo che ne indichi l’impianto di appartenenza.

Pompe:

• ids_codice (PK) • idImpianto (FK) • altri attributi

Vincoli di integrità referenziale:

• Pompe.idImpianto references to Impianti.ids_codice

L’associazione tra impianti e sostanze è diversa da quelle appena tradotte. Infatti la cardinalita dell’associazione è molti a molti. Per tradurre in modo corretto questo tipo di associazione si utilizza una tabella aggiuntiva che riferisce sia alla tabella impianti sia alla tabella sostanze.

Rilevazione:

• idSostanza (PK) (FK) • idImpianto (PK) (FK) • altri attributi

• idSostanza (PK) • altri attributi