Meno ri­don­dan­ze grazie alla nor­ma­liz­za­zio­ne dei database

Uno dei concetti fon­da­men­ta­li della mo­del­la­zio­ne dei dati re­la­zio­na­li è la nor­ma­liz­za­zio­ne. Nei modelli di database re­la­zio­na­le un buon design di database si con­trad­di­stin­gue per una bassa ri­don­dan­za e la ragione è che i dati ri­don­dan­ti portano ad anomalie se­man­ti­che. A propria volta queste anomalie ap­pe­san­ti­sco­no l’ela­bo­ra­zio­ne au­to­ma­ti­ca dei dati e la gestione del database. La nor­ma­liz­za­zio­ne è una strategia per eliminare le ri­don­dan­ze nei database re­la­zio­na­li. In questo articolo vi mostriamo come procedere.

Che cos’è la nor­ma­liz­za­zio­ne?

Con nor­ma­liz­za­zio­ne si intende un approccio al design di database che serve a evitare le ri­don­dan­ze nei database re­la­zio­na­li.

Il modello di database re­la­zio­na­le è la tipologia più diffusa per la gestione in­for­ma­tiz­za­ta dei dati. Nei database re­la­zio­na­li le in­for­ma­zio­ni vengono ar­chi­via­te come record in tabelle, che sono connesse le une alle altre grazie a chiavi. Un record di dati è co­sti­tui­to dai valori che vengono assegnati a de­ter­mi­na­ti attributi tramite le colonne della tabella.

La seguente tabella mostra i dati di fat­tu­ra­zio­ne ar­chi­via­ti di un fornitore fittizio di una fabbrica: Geronimo Scatandro ha ordinato 10 monitor, 12 tappetini per il mouse e 1 sedia da ufficio per la propria attività, mentre l’ordine di Gioia Rinace consiste in 2 computer portatili e 2 cuffie.

Nel database del negozio online vengono assegnati i dati di fat­tu­ra­zio­ne agli attributi numero di fattura (nr. fatt.), data, cliente, numero cliente (nr. cliente), indirizzo, numero posizione fattura (nr. pos.), articolo, numero articolo (nr. art.), quantità e prezzo. Ogni riga della tabella rap­pre­sen­ta un record di dati, che viene indicato anche come tupla.

La sezione di database mostrata sopra è il perfetto esempio di un design di database non riuscito: le ri­don­dan­ze della tabella si notano già al primo sguardo. Inoltre le colonne cliente e indirizzo con­ten­go­no dati che hanno più valori. In questi casi si parla di un database non nor­ma­liz­za­to.

Il maggiore svan­tag­gio dei database non nor­ma­liz­za­ti è la necessità di un maggiore spazio di ar­chi­via­zio­ne, reso appunto ne­ces­sa­rio dai valori ri­don­dan­ti. Inoltre gli attributi che hanno dati con più valori sono difficili da leggere e da collegare gli uni agli altri.

Esempio: entrambi i clienti nella sezione di database mostrata hanno sede a Roma. Tuttavia, poiché queste in­for­ma­zio­ni non vengono con­si­de­ra­te se­pa­ra­ta­men­te, i database avrebbero una notevole dif­fi­col­tà nel filtrare ad esempio i clienti pro­ve­nien­ti da uno stesso luogo.

Per evitare in­ter­val­li di valori doppi o mul­ti­va­lo­re, nell’ambito dei modelli di database re­la­zio­na­li sono state svi­lup­pa­te tre forme normali che si sus­se­guo­no pro­gres­si­va­men­te au­men­tan­do i requisiti.

La forma normale indica lo stato che si vuole rag­giun­ge­re e ogni forma normale ha dei par­ti­co­la­ri requisiti che devono essere sod­di­sfat­ti per rag­giun­ge­re appunto questo stato. Esistono tre tipi di forme normali (prima, seconda e terza) e per ciascuna sono necessari requisiti diversi.

Nor­ma­liz­za­zio­ne: come si nor­ma­liz­za un database

Per il­lu­stra­re il processo che porta un database re­la­zio­na­le nella prima, seconda e terza forma normale, diamo un’occhiata alle singoli fasi della nor­ma­liz­za­zio­ne usando un esempio. Il punto di partenza è la porzione di database pre­sen­ta­ta nell’esempio sopra.

Prima forma normale (1FN)

Una tabella di un database re­la­zio­na­le rientra nella prima forma normale (1FN) quando sono sod­di­sfat­ti i seguenti requisiti:

• tutti i dati hanno valori atomici;
• tutte le colonne della tabella con­ten­go­no valori dello stesso tipo.

Un record di dati si definisce atomico quando ogni in­for­ma­zio­ne è at­tri­bui­ta ad un campo di dati separato.

Di seguito trovate la nostra tabella sui dati di fat­tu­ra­zio­ne nella quale abbiamo evi­den­zia­to in rosso i campi che o non sono atomici o che non con­ten­go­no dati equi­va­len­ti.

Le numerose ri­don­dan­ze mostrano che la nostra tabella di partenza viola entrambe le con­di­zio­ni, non rien­tran­do nella prima forma normale.

Per nor­ma­liz­za­re il database al livello della prima forma normale, è richiesta la seguente procedura:

1. separate i dati con più valori in colonne separate;
2. con­trol­la­te che i valori di ogni colonna abbiano la stessa unità di misura o che siano dello stesso tipo.

Per portare i record di dati nella forma atomica, gli attributi cliente e indirizzo devono essere separati negli attributi specifici cognome, nome, via, numero civico, codice di av­via­men­to postale (CAP) e città.

Nella colonna “prezzo” si trovano i valori espressi in euro e in centesimi. Occorre perciò decidere a quale tipo di unità di misura attenersi per avere in­ter­val­li di valore dello stesso tipo.

Il risultato è una tabella che cor­ri­spon­de alla prima forma normale, che però a causa di valori doppi non consente ancora un’ela­bo­ra­zio­ne ef­fi­cien­te dei dati. Si consiglia perciò di portare la tabella alla seconda forma normale, per rimuovere le ri­don­dan­ze.

Seconda forma normale (2FN)

Una tabella conforme alla seconda forma normale deve sod­di­sfa­re tutti i requisiti della prima forma normale e in aggiunta il seguente:

• ogni attributo non chiave deve essere com­ple­ta­men­te di­pen­den­te a livello fun­zio­na­le dalla chiave primaria.

Nell’in­tro­du­zio­ne si è definito un database re­la­zio­na­le come un sistema di singole tabelle connesse tra loro grazie a chiavi.

Le chiavi nei database re­la­zio­na­li hanno il ruolo di iden­ti­fi­ca­re in modo univoco record di dati (tuple). Una chiave che consiste in un sot­toin­sie­me di attributi che con­sen­to­no di nominare ine­qui­vo­ca­bil­men­te le singole righe di una tabella di database è chiamata su­per­chia­ve. Questo tipo di chiave può risultare dai valori di una singola colonna o dalla somma dei valori di più colonne.

Nel nostro esempio una possibile su­per­chia­ve si configura ad esempio negli attributi numero di fattura (nr. fatt.), numero cliente (nr. cliente) e numero posizione (nr. pos.). Nella tabella seguente abbiamo evi­den­zia­to la su­per­chia­ve con un colore diverso.

Una chiave ottenuta da numero di fattura, numero cliente e numero posizione con i valori {124, 12, 1} consente ad esempio di iden­ti­fi­ca­re in modo in­con­tro­ver­ti­bi­le il record cor­ri­spon­den­te all’acquisto del computer portatile da parte di Gioia Rinace:

Tuttavia per una iden­ti­fi­ca­zio­ne univoca non sono necessari tutti gli elementi della su­per­chia­ve se­le­zio­na­ta: già una com­bi­na­zio­ne di numero di fattura e numero posizione, quindi di una parte della su­per­chia­ve, sarebbe suf­fi­cien­te a iden­ti­fi­ca­re il singolo record di dati. Tali chiavi con un numero minimo di attributi vengono chiamate chiavi candidate o chiavi al­ter­na­ti­ve.

Nor­mal­men­te viene scelta una chiave candidata per tabella, ideal­men­te con una nu­me­ra­zio­ne pro­gres­si­va. Una chiave simile viene indicata come chiave primaria e specifica l’ordine dei record.

La chiave primaria, come ogni candidato chiave, può sus­si­ste­re come pezzo unico o, come nel nostro esempio, come chiave composta. La nostra tabella di esempio utilizza una chiave primaria composta, che consiste nel numero di fattura e nel numero posizione.

Per portare una tabella di database nella seconda forma normale non è tuttavia suf­fi­cien­te de­ter­mi­na­re la chiave primaria e tutti gli attributi non chiave, ma anche la loro relazione reciproca. Per questo bisogna attenersi alla seguente procedura:

1. Ac­cer­ta­te­vi che tutti gli attributi non chiave siano pie­na­men­te di­pen­den­ti dalla chiave primaria. Questo tipo di di­pen­den­za avviene soltanto quando tutti gli attributi della chiave primaria sono necessari per iden­ti­fi­ca­re in modo univoco gli attributi non chiave. Ciò significa anche che le tabelle con chiavi primarie di un solo pezzo cor­ri­spon­do­no au­to­ma­ti­ca­men­te alla seconda forma normale, se tutti i requisiti della prima forma normale sono sod­di­sfat­ti.
2. Ar­chi­via­te tutti gli attributi non chiave che non sono com­ple­ta­men­te di­pen­den­ti dalla chiave primaria intera in tabelle separate.

Se osservate con at­ten­zio­ne la tabella di esempio, vi renderete conto che i requisiti per la seconda forma normale non sono raggiunti, per i seguenti motivi: la colonna data è di­pen­den­te soltanto da quella numero di fattura (nr. fatt.), ma non da quella numero posizione (nr. pos.). Lo stesso vale per i dati cliente nome, cognome, via, numero civico, CAP e città.

Per portare una tabella alla seconda forma normale ar­chi­via­mo perciò in una tabella separata, che chia­me­re­mo “fattura”, tutti gli attributi che sono di­pen­den­ti soltanto dal numero di fattura.

Chiamiamo poi la tabella con i dati rimanenti “posizione fattura”.

Dopo la nor­ma­liz­za­zio­ne il numero di fattura si trova in entrambe le tabelle e le collega l’una all’altra. Mentre l’attributo nella tabella “fattura” funge da chiave primaria, nella tabella “posizione fattura” svolge la funzione di chiave esterna e allo stesso tempo è parte della chiave primaria composta della tabella.

I dati di esempio sod­di­sfa­no ora la seconda forma normale, ma non si può dire che tutte le ri­don­dan­ze siano state eliminate: questo è proprio il fine della terza forma normale.

Terza forma normale (3FN)

Per portare una tabella alla terza forma normale occorre na­tu­ral­men­te che soddisfi in­nan­zi­tut­to i pre­re­qui­si­ti della prima e della seconda forma normale e in aggiunta il seguente:

• gli attributi non chiave non possono essere di­pen­den­ti in modo tran­si­ti­vo da una chiave candidata.

Una di­pen­den­za tran­si­ti­va si ha quando un attributo non chiave è di­pen­den­te da un altro attributo non chiave e perciò in­di­ret­ta­men­te (appunto per la proprietà tran­si­ti­va) dalle sue chiavi candidate.

Il nostro schema di database tra­sgre­di­sce i requisiti della terza forma normale in più di un punto:

Nella tabella “fattura” il nome e il cognome, come gli attributi strada, numero civico, CAP e città, sono di­pen­den­ti non soltanto dalla chiave primaria (il numero fattura), ma anche dal numero cliente.

Nella tabella “posizione fattura” gli attributi “articolo” e “prezzo” non dipendono soltanto dalla chiave primaria, data da numero di fattura e numero posizione, ma anche dal numero dell’articolo. Anche qui viene intaccato il requisito specifico della terza forma normale.

Per eliminare tutte le di­pen­den­ze tra attributi non chiave, col­lo­chia­mo i ri­spet­ti­vi attributi in tabelle separate, che si possono collegare l’una all’altra at­tra­ver­so le chiavi esterne. Ci sono così le quattro tabelle nor­ma­liz­za­te “fattura”, “cliente”, “posizione fattura” e “articolo”.

La chiave primaria della tabella “fattura” è un numero di fattura pro­gres­si­vo. A ogni numero di fattura viene assegnata la data della fattura e un numero cliente.

Maggiori in­for­ma­zio­ni sui singoli clienti sono salvati nella tabella “cliente”. Le tabelle “fattura” e “cliente” sono collegate tra loro at­tra­ver­so il numero cliente, che funge nella tabella “cliente” da chiave primaria e nella tabella “fattura” come chiave esterna.

Una tabella centrale nel nostro database di esempio è quella “posizione fattura”, che contiene l’in­for­ma­zio­ne su quali articoli debbano essere assegnati alla ri­spet­ti­va fattura e su quanti articoli sono stati ordinati. La chiave primaria pro­gres­si­va della tabella “posizione fattura” si ottiene anche dal numero di fattura e dal numero posizione. Gli articoli in questione sono elencati solamente come numeri di articoli che fungono da chiavi esterne e collegano la tabella “posizione fattura” alla tabella “articoli”.

Infine la tabella “articoli” contiene in­for­ma­zio­ni det­ta­glia­te sui ri­spet­ti­vi articoli, come il numero dell’articolo e il prezzo. La chiave primaria è il numero dell’articolo pro­gres­si­vo.

Antonio GuillemShut­ter­stock

Nel nostro esempio può sembrare poco ef­fi­cien­te il fatto di dividere in quattro tabelle quello che stava in due, senza contare che in realtà le ri­don­dan­ze relative ai dati di soltanto due clienti pesano davvero poco. Ma provate ad im­ma­gi­na­re di avere a che fare con diverse centinaia di migliaia di record ri­guar­dan­ti i clienti o il vostro as­sor­ti­men­to e di volerli elaborare in un database re­la­zio­na­le in modo coerente e senza con­trad­di­zio­ni! Ciò nor­mal­men­te può accadere soltanto con uno schema di database conforme alla terza forma normale

Anche quando la nor­ma­liz­za­zio­ne dei database comporta un grande sforzo di pro­gram­ma­zio­ne, la terza forma normale è ritenuta ge­ne­ral­men­te lo standard per i database re­la­zio­na­li, da cui ci si discosta solo in casi ec­ce­zio­na­li. Per esempio può capitare che i database che si trovano nella terza forma normale vengano de­nor­ma­liz­za­ti nella seconda forma normale. Questo accade perché uti­liz­za­re join su più tabelle può com­por­ta­re un grande dispendio di tempo, mentre at­tra­ver­so la de­nor­ma­liz­za­zio­ne si di­mi­nui­sce il numero di tabelle e perciò si abbrevia il tempo della query.

Altre forme normali

Di solito la nor­ma­liz­za­zio­ne termina con la terza forma normale. Le seguenti forme normali si ri­fe­ri­sco­no a database con con­di­zio­ni speciali e sono pertanto uti­liz­za­te solo in casi ec­ce­zio­na­li.

Boyce-Codd normal form (3.5NF)

La Boyce-Codd normal form è un af­fi­na­men­to della terza forma normale, il cui requisito ag­giun­ti­vo rispetto alle prime due, come già men­zio­na­to, è:

• gli attributi non chiave non possono essere di­pen­den­ti tran­si­ti­va­men­te da una chiave candidata.

Nella Boyce-Codd normal form, invece, vale la regola che:

• nessun attributo può dipendere in modo tran­si­ti­vo da una chiave candidata, a meno che non si tratti di una di­pen­den­za banale.

Quindi sono rimosse tutte le ri­don­dan­ze basate sulla di­pen­den­za fun­zio­na­le, anche se possono permanere ri­don­dan­ze di altro tipo.

La forma normale Boyce-Codd è rilevante esclu­si­va­men­te per le tabelle di database che hanno più chiave candidate composte in cui le chiavi si so­vrap­pon­go­no, quindi nel caso in cui lo stesso attributo sia un sot­toin­sie­me di due chiavi candidate.

Le tabelle di database che cor­ri­spon­do­no alla terza forma normale e non hanno chiavi candidate composte sod­di­sfa­no così i requisiti della Boyce-Codd normal form.

La tabella che segue mostra due chiavi candidate, composte ciascuna da due attributi:

• numero del fornitore e numero articolo
• fornitore e numero articolo

Entrambe le chiavi con­sen­to­no l’iden­ti­fi­ca­zio­ne di ogni singolo record di dati. L’unico attributo non chiave è il numero. Poiché l’attributo “numero” non ha di­pen­den­ze tran­si­ti­ve da alcuna chiave candidata, la tabella segue la terza forma normale.

La forma normale Boyce-Codd, invece, non è raggiunta perché esiste una di­pen­den­za tra gli attributi “numero fornitore” e “fornitore”. L’attributo “numero fornitore” è perciò di­pen­den­te in modo tran­si­ti­vo dalla chiave candidata che risulta dal fornitore e dal numero articolo; mentre l’attributo “fornitore”, al contrario della chiave candidata, risulta dal numero fornitore e dal numero articolo.

Si possono evitare le di­pen­den­ze tran­si­ti­ve se dividiamo la tabella di origine nelle tabelle “numero” e “fornitore”, in modo che non ci siano chiavi candidate che si so­vrap­pon­ga­no.

La forma normale Boyce-Codd evita le ri­don­dan­ze che derivano dal fatto che l’iden­ti­fi­ca­zio­ne degli attributi deve essere eseguita più volte at­tra­ver­so chiavi candidate che si so­vrap­pon­go­no. Nell’esempio sopra la tra­spo­si­zio­ne alla forma normale 3.5NF evita i doppi valori nella colonna “fornitore”.

Quarta forma normale

Una tabella di database è conforme alla quarta forma normale se soddisfa le con­di­zio­ni della forma normale Boyce-Codd e in aggiunta la seguente:

• non ci sono di­pen­den­ze mul­ti­va­lo­re a meno che non siano banali.

Una di­pen­den­za mul­ti­va­lo­re (mul­ti­va­lued de­pen­den­cy) si ha quando due attributi che non sono collegati tra loro sono di­pen­den­ti da uno stesso attributo.

Esem­pli­fi­chia­mo il concetto con un esempio:

La seguente tabella mostra quali articoli siano stati ac­qui­sta­ti da ogni cliente e a quale indirizzo debbano essere con­se­gna­ti.

PannawatShut­ter­stock

Il cliente con il numero 234 per esempio ha ordinato gli articoli 1-0023-D e 2-0023-D, che devono essere con­se­gna­ti al suo indirizzo con codice di av­via­men­to postale 12345. Per il cliente 567 occorre con­se­gna­re gli articoli 1-0023-D, 3-0023-D, 4-0023-D e 5-0023-D al codice di av­via­men­to postale 56789.

I record di dati si possono iden­ti­fi­ca­re soltanto con una su­per­chia­ve data da tutti e tre gli attributi, cioè numero cliente, numero articolo e codice di av­via­men­to postale. Poiché non ci sono attributi non chiave, si tratta di una 3FN. Inoltre non ci sono di­pen­den­ze tran­si­ti­ve non banali. Per cui anche la 3.5NF è sod­di­sfat­ta. Tuttavia ci sono di­pen­den­ze mul­ti­va­lo­re: sia l’attributo numero articolo che l’attributo codice di av­via­men­to postale sono di­pen­den­ti dall’attributo numero cliente (nr. cliente), non avendo però alcun col­le­ga­men­to tra di loro.

Lo svan­tag­gio di un simile design di database è che ogni volta che viene ordinato un nuovo articolo per un cliente, occorre anche inserire un codice di av­via­men­to postale nel database, per cui ci sono dati ri­don­dan­ti.

Queste ri­don­dan­ze si possono ridurre portando la tabella alla quarta forma normale. Per farlo occorre dividere le tabelle in modo che non ci siano di­pen­den­ze mul­ti­va­lo­re banali o rimangano solo quelle. Creiamo perciò due tabelle separate, il che è possibile perché il numero articolo e il codice di av­via­men­to postale non hanno alcuna relazione tra di loro.

Come mostra l’esempio, la quarta forma normale evita la ri­don­dan­za derivante dalle di­pen­den­ze mul­ti­va­lo­re, che in questo caso par­ti­co­la­re riguarda la colonna codice di av­via­men­to postale (CAP).

5FN: quinta forma normale

Una tabella di database cor­ri­spon­de alla quinta forma normale se soddisfa tutti i requisiti della quarta e in aggiunta:

• la tabella non si può ul­te­rior­men­te sud­di­vi­de­re senza perdere in­for­ma­zio­ni.

Con un esempio vi mostriamo ora in quali cir­co­stan­ze si verifica un caso simile. Sup­po­nia­mo che l’azienda gestisca un sito web sulla base di TYPO3 e un negozio online con Magento. Tre di­pen­den­ti hanno l’incarico di gestire i progetti software: Maria Bianchi, Antonio Rossi e Gisella Martucci, ognuno dei quali ha diverse qua­li­fi­che.

La tabella di esempio mostra quale qualifica ha quale col­la­bo­ra­to­re e in quale progetto software, nonché quale qualifica sia ne­ces­sa­ria per quale progetto.

Maria Bianchi usa le proprie co­no­scen­ze di PHP e SQL nel progetto Magento e ricorre a SQL e a Ja­va­Script per il sito web TYPO3. Anche Antonio Rossi si occupa della pro­gram­ma­zio­ne PHP su Magento e lavora con Ja­va­Script su TYPO3. Infine Gisella Martucci si occupa soltanto del progetto TYPO3 e si fa carico da sola della pro­gram­ma­zio­ne PHP. Così dalla tabella si deduce che per Magento sono ne­ces­sa­rie co­no­scen­ze di PHP e SQL, mentre per il progetto con TYPO3 sono richieste com­pe­ten­ze di PHP, SQL e Ja­va­Script.

La tabella possiede soltanto una chiave composta da tutti e tre gli attributi e che quindi cor­ri­spon­de almeno alla terza forma normale e alla Boyce-Codd normal form. Inoltre, poiché non ci sono di­pen­den­ze tra tutti e tre gli attributi, la tabella è a pieno diritto nor­ma­liz­za­ta alla quarta forma normale.

Ora bisogna ve­ri­fi­ca­re se anche la 5FN è sod­di­sfat­ta. Co­min­cia­mo a dividere la tabella di partenza “Qua­li­fi­che dei di­pen­den­ti per i progetti assegnati” in tre tabelle: “progetto”, “qualifica col­la­bo­ra­to­re” e “requisiti del progetto”.

La tabella “progetto” mostra quale col­la­bo­ra­to­re è impiegato in quale progetto software.

La tabella “qualifica col­la­bo­ra­to­re” permette di vedere quale col­la­bo­ra­to­re pa­dro­neg­gia quale lin­guag­gio di pro­gram­ma­zio­ne o di database.

Quale qualifica sia ne­ces­sa­ria per quale progetto risulta invece chiaro nella tabella “requisiti del progetto”.

A un primo sguardo la parte di database presa in con­si­de­ra­zio­ne dopo la divisione sembra molto più chiara. Ma nell’ambito della nor­ma­liz­za­zio­ne queste tabelle for­ni­sco­no anche lo stesso della tabella iniziale?

Per ac­cer­tar­ce­ne dobbiamo uti­liz­za­re un join, cioè eseguire una query del database su tutte e tre le tabelle. Il risultato vi sor­pren­de­rà!

Nella ri­co­stru­zio­ne della tabella iniziale dobbiamo per forza assumere che ogni di­pen­den­te che prende parte al progetto con­tri­bui­sca con la propria qualifica al progetto, se il progetto lo richiede. L’in­for­ma­zio­ne che Martucci si fa in carico da sola della pro­gram­ma­zio­ne PHP per il progetto TYPO3 è andata persa. La tabella iniziale quindi non si può ul­te­rior­men­te sud­di­vi­de­re senza perdite, perciò ri­spec­chia già la quinta forma normale.

In pratica è molto raro incappare in schemi di database che sod­di­sfi­no i requisiti della 4FN ma non quelli della 5. La 5NF è tuttavia im­por­tan­te per quei casi di ap­pli­ca­zio­ne in cui bisogna ottenere nuove in­for­ma­zio­ni dai dati di­spo­ni­bi­li.

L’esempio mostra che sia Bianchi che Rossi pos­sie­do­no co­no­scen­ze PHP che, siccome sono legate al progetto TYPO3, possono essere uti­liz­za­te in futuro anche in quell’ambito. Questa in­for­ma­zio­ne può essere utile alle aziende per or­ga­niz­za­re in modo più ef­fi­cien­te lo sviluppo software in questo progetto.

Vantaggi e svantaggi della nor­ma­liz­za­zio­ne

Il fine della nor­ma­liz­za­zio­ne è la riduzione dei valori doppi. Se portate il vostro database a una delle forme normali, avrete il vantaggio che lo schema raggiunto pre­sen­te­rà meno ri­don­dan­ze rispetto a quello di partenza. La nor­ma­liz­za­zio­ne in questo modo al­leg­ge­ri­sce il carico del vostro database.

D’altra parte la nor­ma­liz­za­zio­ne comporta la col­lo­ca­zio­ne degli attributi in tabelle separate e ciò potrebbe ri­chie­de­re l’in­te­gra­zio­ne di chiavi esterne e portare perciò a ri­don­dan­ze nelle chiavi. Tuttavia lo svan­tag­gio prin­ci­pa­le è il fatto che i dati lo­gi­ca­men­te associati non sono più salvati insieme nei database nor­ma­liz­za­ti. Se si desidera riunire i dati che sono stati suddivisi in diverse tabelle, è ne­ces­sa­rio un join.

Grazie ai join si possono filtrare in­for­ma­zio­ni complesse nelle query del database, ma bisogna tener conto che l’im­ple­men­ta­zio­ne dei join è più com­pli­ca­ta rispetto alle semplici in­ter­ro­ga­zio­ni. In ogni caso serve molto più tempo quando vengono eseguiti dei join tramite mol­te­pli­ci tabelle del database.