Basi di dati: Schema logico di un database

Lo schema logico (o schema relazionale) non è indipendente ed astratto come lo schema concettuale.

Praticamente partendo dallo schema concettuale lo impoverisco per essere adattato alla realtà relazionale che è fatta solo di entità ed attributi e non ha legami di classi (superclassi, sottoclassi).

Analisi dei dati derivati

Ovvero i dati "derivabili da altri dati" (ad esempio numero di posti liberi in una sala da cinema (derivabile dal n° di prenotazioni)

Il progettista per decidere se tenere un dato derivato deve paragonare i "costi" fra averlo e non averlo. Ovvero la differenza di costo tra mantenere il dato derivato o calcolarlo quando serve.

I tipi di dati derivati sono ridondanti (appunto derivabili da un'altra fonte) possono essere di varia natura:

• direttamente derivabili (es. durata sapendo ora inizio e ora fine)
  
• derivabili tramite conteggio attraverso la relazione tra due entità (es: importo totale dell'acquisto se ho ho già gli oggetti acquistati ed il loro singolo prezzo)
  
• derivabili tramite conteggio attraverso una relationship (es. n° di posti prenotati/liberi per le varie sale di un cinema)
  
• ridondanti per ciclo di associazioni: potrebbe esserci addirittura una relationship ridonandante (ad esempio: avendo già gli studenti iscritti ad un corso e il docente che tiene il corso sarebbe ridondante avere una relationship diretta tra studente e professore del tipo "insegna a").
  

Gerarchie di generalizzazione

Ovvero la rappresentazione di una gerarchia

Possono essere ristrutturate in 3 modi:

1. Mantenimento delle sole entità superclasse (generica)
   Esempio: Tengo impiegato al posto di avere impiegato, ingegnere, segretario, direttore. Gli attributi "extra" diventano opzionali in impiegato
   
2. Mantenimento delle sole entità sottoclasse (specifica)
   Esempio: tengo le classi impiegato, ingegnere, segretario, direttore e gli attributi comuni (impiegato) li metto in ciascuna sottoclasse
   
3. Mantenimento di entrambe le classi
   Ad esempio realizzerò la classe impiegato e le varie sottoclassi le realizzerò come entità "differenziali": ovvero munite dei soli attributi che estendono il concetto di impiegato, oltre, ovviamente, ad una relazione verso l'entità impiegato che viene effettuato mediante l'unica chiave primaria (unico gruppo di attributi ripetuto in ogni tabella. Ad es. codice fiscale). Nella entità impiegato ci sarà un campo booleano che indica l'appartenenza ad una sottoclasse (ad esempio attributi come ingegnere, segretario, direttore). Dovrò implementare un vincolo che non permetta di avere più di un attributo di sottoclasse attivo nel DB.
   

Normalmente la alternativa 3 è consigliabile.

Se ho (quasi) solo accessi che mi chiedono TUTTI gli attributi indipendentemente dalla sottoclasse di appartenenza conviene la 1 perché riduce gli accessi al DB (che altrimenti dovrebbero essere 1 per la superclasse e 1 per la sottoclasse).

Se invece ho (quasi) solo query che accedono a tutti gli attributi DIPENDENTEMENTE dalla sottoclasse di appartenenza (es.: non voglio mai vedere l'elenco di tutto il personale, ma solo separatamente quello di ingegneri, direttori, segretari ed impiegati) allora l'alternativa 2 è conveniente.

Scelta dell'identificatore primario

Se ci sono più identificatori che possono essere chiavi candidate devo scegliere.

• Escludere quelli che possono avere valori nulli (ad es. se non sempre inserisco subito il codice fiscale lo devo evitare)
  
• Evitare le chiavi composte
  
• Scegliere una chiave che abbia un valore semantico se possibile (non un ID creato apposta)
  

Togliere attributi multi valore e attributi complessi

Trasformarli in entità associata (ad esempio il n° di telefono) che conserva la stessa cardinalità (ad es. 1-n)

Attributi composti possono essere "espansi" sull'entità stessa o possono essere messi in una nuova entità collegata (ad es. indirizzo come composito da via, CAP, città). Potrebbero anche essere tenuti e collassati in un solo attributi (ad es. indirizzo stringa unica).

Trasformazione delle relazioni

Molti a molti: si devono necessariamente trasformare in relazioni. Le relazioni così formate avranno la chiave primaria costituita dall'insieme degli attributi di PK delle due relazioni che associa più tutti i campi necessari a descrivere gli attributi di associazione.

Uno a uno: inserisco all'interno dell'una o dell'altra relazione la chiave esterna che riferisce all'altra entità. Dove definisco la chiave esterna metto anche gli attributi di relazione. Di solito bisogna pensare al tipo di query che verrà effettuato in modo da minimizzare il numero di join. Bisognerebbe cercare di evitare valori nulli (quindi se una relazioni ha cardinalità (0;1) (1;1) conviene mettere la chiave sterna a destra).

Uno a molti: inserisco all'interno della relazione che sta dalla parte con cardinalità massima 1 la chiave esterna (tra persona e indirizzi su indirizzi).

Ina caso di associazione tra più di 2 tabelle è necessario ricorrere al caso molti-a-molti illustrato qui sopra.

 
 

 
 

 
 

 
 

Contenuti gestiti da Michele Bernardi. Non mi assumo alcuna responsabilità sulla correttezza di questi dati, usateli a vostro rischio e pericolo.