Cos'è la normalizzazione (o normalizzazione)?
Risposte:
La normalizzazione consiste fondamentalmente nel progettare uno schema di database in modo tale da evitare dati duplicati e ridondanti. Se alcuni dati vengono duplicati in più punti del database, c'è il rischio che vengano aggiornati in un punto ma non nell'altro, causando il danneggiamento dei dati.
Esiste un numero di livelli di normalizzazione da 1. forma normale a 5. forma normale. Ogni modulo normale descrive come sbarazzarsi di qualche problema specifico, solitamente legato alla ridondanza.
Alcuni tipici errori di normalizzazione:
(1) Avere più di un valore in una cella. Esempio:
UserId | Car
---------------------
1 | Toyota
2 | Ford,Cadillac
Qui la colonna "Car" (che è una stringa) ha diversi valori. Ciò offende la prima forma normale, che dice che ogni cella dovrebbe avere un solo valore. Possiamo normalizzare questo problema avendo una riga separata per macchina:
UserId | Car
---------------------
1 | Toyota
2 | Ford
2 | Cadillac
Il problema di avere più valori in una cella è che è difficile da aggiornare, difficile da interrogare e non è possibile applicare indici, vincoli e così via.
(2) Disporre di dati non chiave ridondanti (ovvero dati ripetuti inutilmente su più righe). Esempio:
UserId | UserName | Car
-----------------------
1 | John | Toyota
2 | Sue | Ford
2 | Sue | Cadillac
Questa struttura è un problema perché il nome viene ripetuto per ogni colonna, anche se il nome è sempre determinato da UserId. Ciò rende teoricamente possibile cambiare il nome di Sue in una riga e non nell'altra, che è il danneggiamento dei dati. Il problema viene risolto dividendo la tabella in due e creando una relazione chiave primaria / chiave esterna:
UserId(FK) | Car UserId(PK) | UserName
--------------------- -----------------
1 | Toyota 1 | John
2 | Ford 2 | Sue
2 | Cadillac
Ora può sembrare che abbiamo ancora dati ridondanti perché gli UserId vengono ripetuti; Tuttavia, il vincolo PK / FK garantisce che i valori non possano essere aggiornati in modo indipendente, quindi l'integrità è sicura.
È importante? Sì, è molto importante. Avendo un database con errori di normalizzazione, si corre il rischio di ottenere dati non validi o corrotti nel database. Poiché i dati "vivono per sempre", è molto difficile sbarazzarsi dei dati corrotti quando sono entrati per la prima volta nel database.
Non aver paura della normalizzazione . Le definizioni tecniche ufficiali dei livelli di normalizzazione sono piuttosto ottuse. Sembra che la normalizzazione sia un complicato processo matematico. Tuttavia, la normalizzazione è fondamentalmente solo il buon senso e scoprirai che se progetti uno schema di database usando il buon senso, in genere sarà completamente normalizzato.
Ci sono una serie di idee sbagliate sulla normalizzazione:
alcuni credono che i database normalizzati siano più lenti e la denormalizzazione migliori le prestazioni. Tuttavia, questo è vero solo in casi molto speciali. In genere un database normalizzato è anche il più veloce.
a volte la normalizzazione è descritta come un processo di progettazione graduale e devi decidere "quando fermarti". Ma in realtà i livelli di normalizzazione descrivono solo diversi problemi specifici. Il problema risolto dalle forme normali sopra il 3 ° NF sono problemi piuttosto rari in primo luogo, quindi è probabile che il tuo schema sia già in 5NF.
Si applica a qualcosa al di fuori dei database? Non direttamente, no. I principi di normalizzazione sono abbastanza specifici per i database relazionali. Tuttavia, il tema generale sottostante, ovvero che non si dovrebbero avere dati duplicati se le diverse istanze possono non essere sincronizzate, può essere applicato ampiamente. Questo è fondamentalmente il principio DRY .
Le regole di normalizzazione (fonte: sconosciuta)
... Allora aiutami Codd.
Soprattutto, serve a rimuovere la duplicazione dai record del database. Ad esempio, se hai più di un posto (tavoli) in cui potrebbe apparire il nome di una persona, sposta il nome in una tabella separata e fai riferimento ad esso ovunque. In questo modo, se devi cambiare il nome della persona in un secondo momento, devi solo cambiarlo in un posto.
È fondamentale per una corretta progettazione del database e in teoria dovresti usarlo il più possibile per mantenere l'integrità dei tuoi dati. Tuttavia, quando si recuperano le informazioni da molte tabelle si stanno perdendo alcune prestazioni ed è per questo che a volte si potrebbero vedere tabelle di database denormalizzate (chiamate anche appiattite) utilizzate in applicazioni critiche per le prestazioni.
Il mio consiglio è di iniziare con un buon grado di normalizzazione e di eseguire la denormalizzazione solo quando realmente necessario
PS controlla anche questo articolo: http://en.wikipedia.org/wiki/Database_normalization per saperne di più sull'argomento e sulle cosiddette forme normali
Normalizzazione una procedura utilizzata per eliminare la ridondanza e le dipendenze funzionali tra le colonne di una tabella.
Esistono diverse forme normali, generalmente indicate da un numero. Un numero più alto significa meno ridondanze e dipendenze. Qualsiasi tabella SQL è in 1NF (la prima forma normale, più o meno per definizione) Normalizzare significa cambiare lo schema (spesso partizionando le tabelle) in modo reversibile, dando un modello funzionalmente identico, tranne che con meno ridondanza e dipendenze.
La ridondanza e la dipendenza dei dati non sono desiderabili perché possono portare a incongruenze durante la modifica dei dati.
Ha lo scopo di ridurre la ridondanza dei dati.
Per una discussione più formale, vedere Wikipedia http://en.wikipedia.org/wiki/Database_normalization
Darò un esempio un po 'semplicistico.
Supponiamo che il database di un'organizzazione che di solito contiene membri della famiglia
id, name, address
214 Mr. Chris 123 Main St.
317 Mrs. Chris 123 Main St.
potrebbe essere normalizzato come
id name familyID
214 Mr. Chris 27
317 Mrs. Chris 27
e una tavola familiare
ID, address
27 123 Main St.
Normalmente la normalizzazione quasi completa (BCNF) non viene utilizzata nella produzione, ma è una fase intermedia. Dopo aver inserito il database in BCNF, il passaggio successivo è solitamente quello di denormalizzarlo in modo logico per velocizzare le query e ridurre la complessità di alcuni inserimenti comuni. Tuttavia, non puoi farlo bene senza prima normalizzarlo correttamente.
L'idea è che le informazioni ridondanti siano ridotte a una singola voce. Ciò è particolarmente utile in campi come gli indirizzi, in cui il Sig. Chris invia il suo indirizzo come Unit-7 123 Main St. e la Sig.ra Chris elenca Suite-7 123 Main Street, che verrebbe visualizzata nella tabella originale come due indirizzi distinti.
In genere, la tecnica utilizzata consiste nel trovare elementi ripetuti e isolare quei campi in un'altra tabella con ID univoci e sostituire gli elementi ripetuti con una chiave primaria che fa riferimento alla nuova tabella.
Citando CJ Date: La teoria è pratica.
Eventuali deviazioni dalla normalizzazione comporteranno alcune anomalie nel database.
Le deviazioni dalla prima forma normale causeranno anomalie di accesso, il che significa che devi scomporre e scansionare i singoli valori per trovare quello che stai cercando. Ad esempio, se uno dei valori è la stringa "Ford, Cadillac" fornita da una risposta precedente e stai cercando tutte le occorrenze di "Ford", dovrai rompere la stringa e guardare sottostringhe. Ciò, in una certa misura, vanifica lo scopo di memorizzare i dati in un database relazionale.
La definizione di First Normal Form è cambiata dal 1970, ma per ora queste differenze non devono riguardarti. Se progetti le tue tabelle SQL utilizzando il modello di dati relazionali, le tue tabelle saranno automaticamente in 1NF.
Le deviazioni dalla seconda forma normale e oltre causeranno anomalie di aggiornamento, perché lo stesso fatto è memorizzato in più di un posto. Questi problemi rendono impossibile memorizzare alcuni fatti senza memorizzare altri fatti che potrebbero non esistere e quindi devono essere inventati. O quando i fatti cambiano, potresti dover individuare tutti i luoghi in cui un fatto è memorizzato e aggiornare tutti quei luoghi, per evitare di ritrovarti con un database che contraddice se stesso. E, quando elimini una riga dal database, potresti scoprire che se lo fai, stai eliminando l'unico posto in cui è memorizzato un fatto che è ancora necessario.
Questi sono problemi logici, non problemi di prestazioni o problemi di spazio. A volte è possibile aggirare queste anomalie di aggiornamento mediante un'attenta programmazione. A volte (spesso) è meglio prevenire i problemi in primo luogo aderendo a forme normali.
Nonostante il valore di quanto già detto, va detto che la normalizzazione è un approccio dal basso verso l'alto, non un approccio dall'alto verso il basso. Se segui determinate metodologie nella tua analisi dei dati e nel tuo progetto iniziale, puoi essere certo che il progetto sarà conforme almeno a 3NF. In molti casi, il design sarà completamente normalizzato.
Dove potresti davvero voler applicare i concetti insegnati durante la normalizzazione è quando ti vengono forniti dati legacy, da un database legacy o da file costituiti da record, ei dati sono stati progettati nella completa ignoranza delle forme normali e delle conseguenze della partenza da loro. In questi casi potrebbe essere necessario scoprire gli scostamenti dalla normalizzazione e correggere il progetto.
Attenzione: la normalizzazione viene spesso insegnata con sfumature religiose, come se ogni allontanamento dalla piena normalizzazione fosse un peccato, un'offesa contro il Codd. (piccolo gioco di parole lì). Non comprarlo. Quando impari davvero, davvero la progettazione di database, non solo saprai come seguire le regole, ma saprai anche quando è sicuro infrangerle.
La normalizzazione è uno dei concetti di base. Significa che due cose non si influenzano a vicenda.
Nei database in particolare significa che due (o più) tabelle non contengono gli stessi dati, ovvero non hanno ridondanza.
A prima vista è davvero buono perché le tue possibilità di fare qualche problema di sincronizzazione sono vicine allo zero, sai sempre dove sono i tuoi dati, ecc. Ma, probabilmente, il tuo numero di tabelle aumenterà e avrai problemi ad incrociare i dati e per ottenere alcuni risultati di sintesi.
Quindi, alla fine, finirai con la progettazione del database che non è puramente normalizzata, con un po 'di ridondanza (sarà in alcuni dei possibili livelli di normalizzazione).
Cos'è la normalizzazione?
La normalizzazione è un processo formale graduale che ci consente di scomporre le tabelle del database in modo tale da ridurre al minimo sia la ridondanza dei dati che le anomalie di aggiornamento .
Cortesia del processo di normalizzazione
Prima forma normale se e solo se il dominio di ogni attributo contiene solo valori atomici (un valore atomico è un valore che non può essere diviso), e il valore di ogni attributo contiene solo un singolo valore da quel dominio (esempio: - dominio per il la colonna del sesso è: "M", "F".).
La prima forma normale applica questi criteri:
- Elimina i gruppi ripetuti nelle singole tabelle.
- Crea una tabella separata per ogni set di dati correlati.
- Identifica ogni set di dati correlati con una chiave primaria
Seconda forma normale = 1NF + nessuna dipendenza parziale cioè Tutti gli attributi non chiave sono completamente funzionali dipendenti dalla chiave primaria.
Terza forma normale = 2NF + nessuna dipendenza transitiva cioè Tutti gli attributi non chiave sono completamente funzionali e dipendono DIRETTAMENTE solo dalla chiave primaria.
La forma normale di Boyce – Codd (o BCNF o 3.5NF) è una versione leggermente più forte della terza forma normale (3NF).
Nota: - Le forme normali Second, Third e Boyce-Codd riguardano le dipendenze funzionali. Esempi
Quarta forma normale = 3NF + rimuove le dipendenze multivalore
Quinta forma normale = 4NF + rimuove le dipendenze del join
Come dice Martin Kleppman nel suo libro Designing Data Intensive Applications:
La letteratura sul modello relazionale distingue molte diverse forme normali, ma le distinzioni sono di scarso interesse pratico. Come regola generale, se stai duplicando valori che potrebbero essere memorizzati in un solo posto, lo schema non viene normalizzato.
Aiuta a prevenire dati duplicati (e peggio, in conflitto).
Tuttavia, può avere un impatto negativo sulle prestazioni.