Normalizzazione (informatica)

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca
In una base di dati relazionale una corretta progettazione dello schema è fondamentale per evitare anomalie di funzionamento che possono compromettere l'integrità dei dati o la disponibilità del servizio

In informatica la normalizzazione è un procedimento volto alla mitigazione di una serie di difetti sistematici di una base di dati relazionale.

Esistono vari livelli di normalizzazione, via via più stringenti, che se applicati correttamente portano la base di dati in una delle cosiddette "forme normali". Ovvero uno stato in cui risultano rispettati una precisa serie di vincoli di integrità, che garantiscono l'assenza, dimostrabile formalmente, di determinate classi di problemi.

Problemi delle basi di dati non normalizzate

[modifica | modifica wikitesto]

Quando si tenta di modificare (aggiornare, inserire in o cancellare da) una base di dati non normalizzata potrebbero verificarsi una serie di situazioni indesiderate che compromettono la normale operatività del sistema:

Anomalie di inserimento
Un'anomalia di inserimento: finchè al nuovo membro della facoltà, il Dr. Newsome, non verrà assegnato almeno un insegnamento, i suoi dettagli non potranno essere registrati

Rientrano nelle anomalie di inserimento tutte quelle situazioni che impediscono la registrazione di informazioni normalmente accettate dalla base di dati.

Per esempio, consideriamo una tabella "Faculty and their courses" che contiene i campi Faculty ID, Faculty Name, Faculty Hire Date, e Course Code. In questo caso i dettagli di ogni membro della facoltà che eroga almeno un insegnamento possono essere registrati, ma un neoassunto a cui non è stato ancora assegnato nessun insegnamento non può essere registrato, a meno di non impostare il Course Code a NULL.

Anomalie di aggiornamento
Un'anomalia di aggiornamento: all'impiegato 519 sono associati più indirizzi su righe diverse

Rientrano nelle anomalie di aggiornamento tutte quelle situazioni in cui una modifica normalmente lecita della base di dati porta questa in uno stato inconsistente.

Questo accade tipicamente quando la stessa informazione può essere espressa su più di una riga. Per esempio consideriamo una tabella "Employees' Skills" che contenere i campi Employee ID, Employee Address, e Skill; cambiare correttamente l'indirizzo di un particolare impiegato potrebbe implicare l'aggiornamento di multiple righe (in questo caso una per ogni Skill associata all'impiegato). Se l'aggiornamento va a buon fine solo parzialmente – l'indirizzo dell'impiegato viene aggiornato su alcune righe ma non su tutte – allora la tabella viene lasciata in uno stato inconsistente. In particolare la base di dati restituisce risposte conflittuali quando interrogata a proposito dell'indirizzo dell'impiegato.

Anomalie di cancellazione
Un'anomalia di cancellazione: tutte le informazioni sul Dr. Giddens vengono perse se temporanamente non gli viene associato nessun corso

Rientrano nelle anomalie di cancellazione tutte quelle situazioni in cui la cancellazione di alcuni dati implica la perdita di informazioni correlate che invece si desidererebbe mantenere.

La tabella "Faculty and Their Courses" descritta sopra è soggetta a questo tipo di anomalie: se un membro della facoltà cessa temporaneamente di insegnare (non gli vengono assegnati corsi) le righe in cui la persona appare vanno cancellate, effettivamente cancellando tutte le informazioni sulla sua esistenza, a meno di impostare il campo Course Code a NULL.

Forme normali

[modifica | modifica wikitesto]

Si può dire che una base di dati si trova in una data forma normale quando tutte le relazioni ivi contenute soddisfano i requisiti della forma normale, ergo esse stesse si trovano in forma normale. Di seguito vengono indicate le definizioni delle forme normali per le relazioni.

Prima forma normale (1NF)

Si dice che una relazione è in 1NF se e solo se:

  • ogni attributo è definito su un dominio con valori atomici, ovvero indivisibili;
  • ogni istanza di attributo contiene un singolo valore del dominio di riferimento.
Seconda forma normale (2NF)

Si dice che una relazione è in 2NF se e solo se:

  • soddisfa i requisiti della 1NF;
  • tutti gli attributi non-chiave presentano una dipendenza funzionale dalla chiave nella sua interezza, ovvero non dipendono solo da una parte della chiave.
Terza forma normale (3NF)

Si dice che una relazione è in 3NF se e solo se:

  • soddisfa i requisiti della 2NF;
  • tutti gli attributi non-chiave dipendono soltanto dalla chiave, ovvero non esistono dipendenze funzionali tra attributi non-chiave.
Forma normale di Boyce e Codd (BCNF)

Si dice che una relazione è in BCNF se e solo se:

  • soddisfa i requisiti della 3NF;
  • per ogni dipendenza funzionale non banale , è una superchiave.

Limiti di 4NF e 5NF

[modifica | modifica wikitesto]

La quarta e quinta forma normale, in realtà, raramente vengono utilizzate, in quanto ad un incremento di rigore nell'eliminazione della ridondanza corrisponde un degrado delle prestazioni (query di selezione o, peggio, modifica dei dati, richiedono molto più tempo per l'esecuzione).

Metodologie di normalizzazione

[modifica | modifica wikitesto]

Decomposizione delle relazioni

[modifica | modifica wikitesto]

Questo processo si fonda su un semplice criterio: se una relazione presenta più concetti tra loro indipendenti, la si decompone in relazioni più piccole, una per ogni concetto. Questo tipo di processo non è sempre applicabile in tutte le tabelle, dato che in alcuni casi potrebbe comportare una perdita d'informazioni.

Una decomposizione dovrebbe sempre soddisfare due proprietà:

  • la decomposizione senza perdita, che garantisce la ricostruzione delle informazioni originarie
  • la conservazione delle dipendenze, che garantisce il mantenimento dei vincoli di integrità originari.

Per "decomposizione senza perdita" si intende l'atto della manipolazione di una relazione R volta ad ottenere (eventualmente) due o più relazioni (ad esempio R1 e R2) che oltre a conservare le dipendenze funzionali verificano anche la seguente condizione:

Teorema: Sia data una relazione R(X), con X insieme degli attributi di R, e due sottoinsiemi A, B di X tali che A unito B coincide con X; siano inoltre R1 e R2 due relazioni rispettivamente su A e su B. Allora è condizione sufficiente affinché la decomposizione su A e B sia senza perdita se, detto C l'insieme intersezione tra A e B, è superchiave per R1(A) o R2(B).

Denormalizzazione

[modifica | modifica wikitesto]

La denormalizzazione è un'operazione applicata su una base di dati precedentemente normalizzata per ottenere un aumento delle prestazioni, attraverso l'introduzione calcolata di caratteristiche altrimenti eliminate attraverso la normalizzazione. Genericamente consiste nell'aggiunta di copie ridondanti dei dati o nell'aggregazione di concetti strettamente correlati in un'unica tabella.[1] Questo porta generalmente un aumento considerevole delle prestazioni in lettura, a fronte di una leggera perdita di prestazioni in scrittura.[2][3]

La denormalizzazione è un'operazione motivata da problemi di prestazioni e scalabilità che appaiono in quei DBMS relazionali che tendono ad eseguire operazioni di lettura in volumi notevolmente superiori a quelli di scrittura. Un caso tipico è quello dello dei data warehouse.[2]

Le forme denormalizzate differiscono in modo importante dalle forme non-normalizate, in quanto i benefici della denormalizzazione possono essere ottenuti solo su modelli dei dati che sono stati precedentemente normalizzati e che, al netto dei mirati interventi di denormalizzaione, rimangono tali.

Compromessi delle forme denormalizzate

[modifica | modifica wikitesto]

Strategie di denormalizzazione

[modifica | modifica wikitesto]

A livello logico

[modifica | modifica wikitesto]

Un primo approccio potrebbe essere la denormalizzazione delle relazioni a livello logico. Uno svantaggio di questo metodo è che l'onere del mantenimento dell'integrità dei dati ricade parzialmente sul progettista: questo viene fatto programmando delle procedure (trigger) nella base di dati che si occupano di imporre la coerenza delle copie ridondanti dei dati.

A livello fisico

[modifica | modifica wikitesto]

Volendo mantenere il modello logico normalizzato, è possibile permettere al DBMS di memorizzare dati ridondanti a livello fisico, sfruttando la geometria della memoria e gli effetti di cache in modo da ridurre i tempi di risposta alle interrogazioni. In questo caso il mantenimento della correttezza delle operazioni di aggiornamento dei dati è completamente delegata al DBMS.

Questo metodo è spesso implementato utilizzando il concetto di tabella virtuale ("vista indicizzata" in Microsoft SQL Server, "vista materializzata" in Oracle e PGSQL).

  • Paolo Atzeni, Stefano Ceri, Piero Fraternali, Stefano Paraboschi e Riccardo Torlone, Basi di dati, 5ª ed., Milano, McGraw-Hill, 2018, ISBN 978-88-386-9445-5.

Voci correlate

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica