Quando si crea un database Relazionale, come Microsoft Access, e si definiscono delle tabelle collegate, la scelta di una chiave primaria per una relazione è molto importante. Poiché il Modello Relazionale viene implementato direttamente all’interno del database, bisogna tenere presente che gli RDBMS indicizzano le chiavi primarie in modo da velocizzare notevolmente la ricerca di una specifica riga all’interno delle tabelle.
Esistono quindi dei casi in cui è opportuno inserire delle chiavi primarie "surrogate", realizzate cioè con campi che non contengono un particolare attributo della tupla (ad esempio nome e cognome per una tabella "studenti"), ma che vengono creati ad-hoc per far fronte a due comuni scenari:
· la difficoltà di avere n campi che garantiscano l’univocità della chiave
· la complessità di gestione per la macchina di chiavi complesse.
Ad esempio se riprendiamo l’esempio del Film immaginiamo che esistano due attori diversi, ma con lo stesso nome e cognome. Se usassimo la coppia nome e cognome come chiave primaria potremmo inserire nella nostra base di dati uno solo di essi. Poiche pero gli omonimi esistono, nella realtà spesso si utilizza il codice fiscale (è già una chiave surrogata!).
Supponiamo di avere una chiave formata da parecchi campi e ci sono altre tabelle che sono collegate alla tabella in questione attraverso chiavi esterne, ovviamente con lo stesso numero di campi. Ma cosi facendo le prestazioni del sistema possono subire un degrado.
Allora è sufficiente inserire un nuovo campo, costituito da un numero intero crescente e chiamato ID ovvero "identificativo", che diventa la chiave primaria della tabella. Gli elementi della tabella verranno identificati quindi da un semplice numero intero.
In questo modo la chiave primaria sarà costituita da un unico campo, contenente un numero facile da gestire per la macchina. Inoltre non ci saranno rischi di chiavi duplicate poiché basta incrementare tale numero ad ogni inserimento di una nuova riga nella tabella.
Normalizzazione del database
Quando ci si appresta a trasformare il Modello E-A nel Modello Relazionale anche se si presta particolare attenzione, possono sorgere dei problemi. Esistono a riguardo dei sistemi di verifica che, applicati sul Modello Relazionale, stabiliscono il grado di normalizzazione della stessa, ovvero il grado di immunità alle ridondanze ed alle inconsistenze dei dati.
Il processo di normalizzazione serve a verificare la struttura della base di dati ed eventualmente indica le relazioni contenenti attributi a ben vedere indipendenti. Questo processo si effettua attraverso la suddivisione dei dati tra Tabelle tra loro collegate. Dal discorso sinora fatto sembra quindi che la qualità di una base di dati aumenti all’aumentare della suddivisione dei dati in relazioni. La questione in realtà è più complessa poiché più si suddividono i dati in relazioni e più è oneroso il compito di ricostruire le informazioni originarie e quindi si può presentare una riduzione della velocità nel reperimento dei dati.
Si parla di denormalizzazione, l’operazione che porta ad accorpare attributi appartenenti a relazioni diverse in un’unica relazione.
Nasce quindi la necessità di equilibrare la normalizzazione dei database ad un livello soddisfacente sia per la gestione dei dati che per la velocità di reperimento degli stessi.
Se hai delle domande o precisazioni che vuoi approfondire mandami una mail all’indirizzo info@creaprogrammando.com
A presto
Paolo Bellesia
P.s. Se ancora non lo hai fatto e vuoi scaricare il primo Special Report gratuito "Crea il tuo programma" iscriviti nel box a fianco potrai cosi cominciare a progettare in modo semplice e divertente i tutti i tuoi programmi. Inoltre riceverai le indicazioni di tutti gli articoli che periodicamente inseriamo nel Blog.
0 commenti:
Posta un commento