bdd-2020-alexandria/4-1-eliminazione-gerarchie.md

Eliminazione delle gerarchie

Per effettuare la progettazione logica è necessaria come prima cosa eliminare le gerarchie IsA createsi durante la fase di progettazione concettuale.

Si ricorda che in Alexandria sono presenti due gerarchie: una relativa agli Elementi e una relativa alle Edizioni dei Libri.

Gerarchia delle Edizioni

La gerarchia delle Edizioni è una gerarchia totale ed esclusiva; gli approcci possibili sono dunque 4:

• Mantenimento delle entità: Un'opzione sempre possibile, ma che porta a un numero di accessi maggiore e quindi a una velocità di interrogazione minore rispetto alle due alternative.

• Collasso verso l'alto: Essendo una relazione esclusiva, collassarla verso l'alto porterebbe ad almeno un 50% di valori nulli nella tabella Edizione risultante, portando a un significativo spreco di memoria.

• Collasso verso l'alto con unione: Sarebbe possibile effettuare il collasso verso l'alto unendo però le coppie di attributi {"Copertina", "Immagine"} e {"Pagine", "Durata"} (facendo riferimento rispettivamente alle pagine del libro e ai secondi dell'audiolibro) per rendere 0 i valori nulli introdotti nella tabella, a costo di parte dell'integrità della base di dati.

• Collasso verso il basso: Porterebbe alla duplicazione dell'entità Edizione e delle associazioni 1 a N con cardinalità N dal lato di Edizione; si creerebbe un nuovo tipo di Elemento, "Elemento (audiolibro)".

Si è deciso di collassare la gerarchia verso il basso perchè si è reputato importante mantenere integra, veloce e compatta la base di dati, anche a costo di maggiore complessità progettuale.

Gerarchia degli Elementi

La gerarchia degli Elementi è non totale ed esclusiva. Possiamo dunque applicare i seguenti approcci:

• Mantenimento delle entità: Un'opzione sempre possibile, ma che porta a un numero di accessi maggiore e quindi a una velocità di interrogazione minore rispetto alle due alternative.

• Collasso verso l'alto: Collassare direttamente verso l'alto sarebbe l'opzione peggiore, in quanto aggiungerebbe 12 nuovi attributi con almeno il 75% dei valori nulli (più un selettore), sprecando più memoria del necessario.

• Collasso verso l'alto con unione: Per minimizzare i valori nulli, si potrebbero unire gli attributi {"Provenienza", "Stato"} in uno unico, verificando che vengano inseriti valori validi attraverso vincoli di integrità; in questo caso, si introdurrebbero solo 4 nuovi attributi ("istanza di"), con però comunque almeno il 75% di valori nulli, costando memoria (ma meno di quanta se ne sarebbe spesa in un normale collasso).

• Collasso verso il basso: Porterebbe alla creazione di quattro tabelle Elemento e a quattro tabelle Recensione relative a ogni tipo di Elemento, aumentando la complessità progettuale.

Anche qui si è deciso di collassare la gerarchia verso il basso, in quanto il collasso verso il basso favorisce le entità molto specializzate come gli Elementi; inoltre, adottare il collasso verso il basso permette di espandere con facilità il database in futuro per aggiungerci altri tipi di Elementi, in quanto basterà poi creare due nuove tabelle Elemento e Recesione per ogni tipo che si vorrà aggiungere.