Prima di tutto è necessario rimuovere le gerarchie ISA (Is-A). Per risolvere questo problema sono possibili le seguenti soluzioni:
- mantenimento delle entità: vengono mantenute tutte le entità, le figlie vengono associate al padre e identificate esternamente tramite l’associazione
- collasso verso l’alto: le entità figlie vengono rimosse, tutti i loro attributi diventano attributi opzionali per l’entità padre ed è necessario l’utilizzo di selettori per indicare di quale sotto entità si tratta - collasso verso il basso: viene eliminata l’entità padre e tutti gli attributi e le associazioni legate ad
essa vengono replicate per ogni entità figlia
È importante sottolineare che tutte le gerarchie coinvolte nel presente progetto sono di tipo totale (coinvolgono tutte le casistiche previste dalla realtà di interesse) ed esclusivo (le entità figlie sono distinte tra loro); le scelte descritte in seguito hanno tenuto in considerazione questo aspetto.
____________________________________________________________________________________________________________________ Gerarchia Log Interno
La gerarchia che sussiste tra le entità Log Interno (padre), LogAdmin e Log Script (figlie), definisce un raggruppamento logico tra i log riguardanti gli interventi interni – ovvero da parte degli amministratori, eventualmente mediante l’esecuzione di script.
Analizzando lo storico dei Log Interni del database originario, è emerso che le operazioni effettuate dagli utenti amministratori costituiscono solo una piccolissima parte del totale; infatti, i log interni sono principalmente relativa all’esecuzione di script automatici (di backup e di importazione dei tracciati record). Per tali ragioni, si opta per un collasso verso l’alto, mediante l’aggiunta di un campo TipoLog atto a distinguere le due tipologie. Gli altri attributi dell’entità Log Interno derivano, in realtà, da un'altra gerarchia (sull’entità Log), che verrà analizzata nel seguente paragrafo.
Segue il diagramma ER risultante (Figura 3.24):
43 Gerarchia Log
La gerarchia che sussiste tra le entità Log (padre), LogInterno (derivanti dall’eliminazione della gerarchia su tale entità), LogInstallatore, LogProdotture e LogLettura (figlie), definisce un raggruppamento logico tra i log riguardante le operazioni effettuate da utenti e script.
Gli attributi delle entità figlie derivano dall’entità padre, Log; le entità figlie non presentano ulteriori attributi. Appare evidente che il collasso verso il basso è la soluzione più appropriata per questa gerarchia. Segue il diagramma ER risultante (Figura 3.25):
____________________________________________________________________________________________________________________ Gerarchia Utenti
La gerarchia che sussiste tra le entità Utente (padre), UtenteAdmin, UtenteLettura, UtenteInstallatore ed UtenteProduttore (figlie), definisce un raggruppamento logico tra le tipologie di utenti che possono interagire con il sistema software.
Gli attributi delle entità figlie derivano dall’entità padre, Utente; le entità figlie non presentano attributi aggiuntivi.
Il collasso verso il basso risulta essere la soluzione più appropriata per questa gerarchia. Segue il diagramma ER risultante (Figura 3.26):
44
3.5.2 – Selezione delle Chiavi Primarie ed Eliminazione degli Identificatori Esterni
In questa sezione della presente documentazione sono descritte le motivazioni che hanno portato alla scelta delle chiavi primarie per le varie entità.È importante sottolineare che la scelta degli identificatori primari è stata effettuata prediligendo la scelta di campi numerici seriali per motivi prestazionali; verranno, in ogni caso, mantenuti gli identificatori scelti durante la fase di analisi dei requisiti (oggetto del Capitolo 3.2) e durante la realizzazione del Diagramma ER (Capitolo 3.4) poiché permettono agli utenti del sistema di approcciarsi ai dati mediante l’utilizzo di identificatori e nomi più semplici ed espressivi (come i codici di listino – ad esempio, il codice 1_4_2). Verranno, di seguito, analizzate solo le entità che presentano più identificatori, chiavi composte ed identificatori esterni.
Categoria e SottoCategoria
L’entità Categoria presenta un’associazione ricorsiva su sé stessa, con i ruoli di Categoria Padre e Categoria Figlia, che descrive le SottoCategorie.
Per motivi prestazionali, e per una esplicita richiesta del committente (Multitraccia), si opta per la scomposizione di Categoria e SottoCategoria in due entità distinte. SottoCategoria avrà gli stessi attributi dell’entità Categoria, più un identificatore esterno che farà riferimento alla Categoria Padre. Questa scelta evita la possibilità della formazione di cicli tra le sottocategorie, ed impone (mediante il vincolo di chiave esterna) che una SottoCategoria possa fare riferimento ad una sola Categoria padre.
Segue lo schema risultante (Figura 3.27):
45
____________________________________________________________________________________________________________________ Listino Base
L’entità Listino Base presenta ben quattro identificatori: un id numerico seriale interno, un codice di listino, un codice composto ed un codice composto anno (di tipo stringa).
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Gli altri tre campi vengono utilizzati dai Produttori e dagli Installatori per identificare i record, e rimarranno quindi campi univoci a valori non nulli.
Segue lo schema risultante (Figura 3.28):
____________________________________________________________________________________________________________________ Produttore
L’entità Produttore presenta due identificatori: un id numerico seriale interno e la P.IVA.
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Il campo P.IVA rimarrà univoco a valori non nulli.
Segue lo schema risultante (Figura 3.29):
Figura 3.27 – Diagramma ER Chiavi: Categoria e SottoCategoria
46
____________________________________________________________________________________________________________________ Listino Personalizzato
L’entità Listino Personalizzato presenta ben cinque identificatori: un id numerico seriale interno, un codice composto, un codice composto anno, la composizione degli identificatori delle entità Listino Base e Produttore (chiavi esterne), e la composizione dell’identificatore dell’entità Produttore (chiave esterna) e del Vecchio Codice di Listino.
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Gli altri campi vengono utilizzati dai Produttori e dagli Installatori per identificare i record, e rimarranno quindi campi univoci a valori non nulli.
Segue lo schema risultante (Figura 3.30):
____________________________________________________________________________________________________________________ Ordine
L’entità Ordine presenta due identificatori: un id numerico seriale interno ed un codice ordine (di tipo stringa) utilizzato da Produttori ed Installatori per identificare gli ordini.
Per ragioni prestazionali, si opta per la scelta del campo id come chiave primaria dell’entità. Il campo codice ordine rimarrà a valore univoco e non nullo.
Di seguito (Figura 3.31) lo schema risultante:
Figura 3.29 – Diagramma ER Chiavi: Produttore
47
____________________________________________________________________________________________________________________ Modulo
L’entità Modulo presenta tre identificatori: un id numerico seriale interno, un codice di sistema ed un codice modulo PIVA.
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Gli altri campi vengono utilizzati dai Produttori e dagli Installatori per identificare i record, e rimarranno quindi campi univoci a valori non nulli.
Segue lo schema risultante (Figura 3.32):
____________________________________________________________________________________________________________________ Installatore
L’entità Installatore presenta due identificatori: un id numerico seriale interno e la P.IVA.
Si procede in modo analogo a quanto fatto con l’entità Produttore: si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Il campo P.IVA rimarrà univoco a valori non nulli.
Segue lo schema risultante (Figura 3.33):
Figura 3.31 – Diagramma ER Chiavi: Ordine
48
____________________________________________________________________________________________________________________ Nazione
L’entità Nazione presenta due identificatori: un id numerico seriale interno ed il codice ISTAT.
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Il campo codice ISTAT rimarrà univoco a valori non nulli.
Segue lo schema risultante (Figura 3.34):
____________________________________________________________________________________________________________________ Comune
L’entità Comune presenta tre identificatori: un id numerico seriale interno, il codice ISTAT, ed un identificatore composto dal CAP e dall’identificatore dell’entità Nazione (mediante vincolo di chiave esterna).
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Gli altri campi vengono utilizzati rimarranno campi univoci a valori non nulli.
Segue lo schema risultante (Figura 3.35):
Figura 3.33 – Diagramma ER Chiavi: Installatore
Figura 3.34 – Diagramma ER Chiavi: Nazione
49 Utenti
L’entità Utente Admin, Utente Installatore, Utente Produttore ed Utente Lettura (derivate dal collasso verso il basso della gerarchia sulla tabella Utenti – Capitolo 3.5.1) presentano, ciascuna due identificatori: un id numerico seriale interno, ed uno username (di tipo stringa).
Si sceglie di utilizzare l’id come chiave primaria dell’entità, per motivi prestazionali. Il campo username resterà univoco a valori non nulli.
Segue lo schema risultante per l’entità Utente Admin (Figura 3.36), del tutto identico per le altre tre entità: