Cos’è la normalizzazione (o normalizzazione)?

Perché i ragazzi della banca dati vanno avanti sulla normalizzazione?

Che cos’è? Come aiuta?

Si applica a qualsiasi cosa al di fuori dei database?

La normalizzazione consiste fondamentalmente nella progettazione di uno schema di database tale da evitare l’uso di dati duplicati e ridondanti. Se alcuni dati vengono duplicati in diversi punti del database, c’è il rischio che venga aggiornato in un posto, 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 forma normale descrive come eliminare alcuni problemi specifici, in genere correlati 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 di avere una riga separata per auto:

 UserId | Car --------------------- 1 | Toyota 2 | Ford 2 | Cadillac 

Il problema di avere più valori in una cella è che è difficile aggiornarlo, difficile da consultare e non è ansible applicare indici, vincoli e così via.

(2) Avere dati non chiave ridondanti (cioè dati ripetuti inutilmente in più file). Esempio:

 UserId | UserName | Car ----------------------- 1 | John | Toyota 2 | Sue | Ford 2 | Sue | Cadillac 

Questo design è un problema perché il nome viene ripetuto per ogni colonna, anche se il nome è sempre determinato dall’ID utente. Ciò rende teoricamente ansible cambiare il nome di Sue in una riga e non l’altra, che è la corruzione dei dati. Il problema si risolve dividendo la tabella in due e creando una chiave primaria / relazione di 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 indipendentemente, quindi l’integrità è sicura.

È importante? Sì, è molto importante. Avendo un database con errori di normalizzazione, si apre il rischio di ottenere dati non validi o corrotti nel database. Poiché i dati “vivono per sempre” è molto difficile liberarsi dei dati corrotti quando sono entrati nel database per primi.

Non aver paura della normalizzazione . Le definizioni tecniche ufficiali dei livelli di normalizzazione sono abbastanza ottuse. Sembra che la normalizzazione sia un complicato processo matematico. Tuttavia, la normalizzazione è fondamentalmente solo il buonsenso, e scoprirai che se si progetta uno schema di database usando il buon senso, di solito sarà completamente normalizzato.

Ci sono molti malintesi sulla normalizzazione:

  • alcuni credono che i database normalizzati siano più lenti e la denormalizzazione migliori le prestazioni. Questo è vero solo in casi molto speciali comunque. 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 forms normali al di sopra del 3 ° NF sono problemi piuttosto rari, in primo luogo, quindi è probabile che lo schema sia già in 5NF.

Si applica a qualsiasi cosa al di fuori dei database? Non direttamente, no. I principi di normalizzazione sono abbastanza specifici per i database relazionali. Tuttavia, il tema generale sottostante – che non si dovrebbero avere dati duplicati se le diverse istanze possono non essere sincronizzate – può essere applicato in senso lato. Questo è fondamentalmente il principio SECCO .

Le regole della normalizzazione (fonte: sconosciuto)

  • La chiave ( 1NF )
  • L’intera chiave ( 2NF )
  • e nient’altro che la chiave ( 3NF )

… quindi aiutami Codd.

Soprattutto serve per rimuovere la duplicazione dai record del database. Ad esempio, se hai più di una posizione (tabelle) in cui potrebbe trovarsi il nome di una persona, sposta il nome in una tabella separata e fai riferimento ad essa in qualsiasi altro punto. In questo modo, se è necessario modificare il nome della persona in un secondo momento, è sufficiente modificarlo in un unico punto.

È fondamentale per la corretta progettazione del database e in teoria dovresti usarlo il più ansible per mantenere l’integrità dei tuoi dati. Tuttavia, quando si recuperano informazioni da molte tabelle, si perdono alcune prestazioni ed è per questo che a volte è ansible visualizzare tabelle di database denormalizzate (chiamate anche appiattite) utilizzate in applicazioni con prestazioni critiche.

Il mio consiglio è di iniziare con un buon grado di normalizzazione e fare solo la de-normalizzazione quando veramente necessario

PS controlla anche questo articolo: http://en.wikipedia.org/wiki/Database_normalization per leggere di più sull’argomento e sulle cosiddette forms normali

Normalizzazione una procedura utilizzata per eliminare la ridondanza e le dipendenze funzionali tra le colonne in una tabella.

Esistono diverse forms normali, generalmente indicate da un numero. Un numero più elevato significa meno ridondanze e dipendenze. Qualsiasi tabella SQL è in 1NF (prima forma normale, praticamente per definizione) Normalizzare significa cambiare lo schema (spesso suddividendo le tabelle) in modo reversibile, dando un modello che è funzionalmente identico, tranne che con meno ridondanza e dipendenze.

La ridondanza e la dipendenza dei dati non sono desiderabili perché possono causare incongruenze nella modifica dei dati.

Ha lo scopo di ridurre la ridondanza dei dati.

Per una discussione più formale, consultare la Wikipedia http://en.wikipedia.org/wiki/Database_normalization

Darò un esempio un po ‘semplicistico.

Assumi 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 un tavolo di famiglia

 ID, address 27 123 Main St. 

La normalizzazione quasi completa (BCNF) di solito non è utilizzata in produzione, ma è un passaggio intermedio. Una volta inserito il database in BCNF, il passo successivo è di solito normalizzarlo in modo logico per velocizzare le query e ridurre la complessità di alcuni inserti comuni. Tuttavia, non puoi farlo bene senza prima normalizzarlo correttamente.

L’idea è che le informazioni ridondanti sono ridotte a una singola voce. Ciò è particolarmente utile in campi come gli indirizzi, dove Mr. Chris invia il suo indirizzo come Unit-7 123 Main St. e Mrs. Chris elenca Suite-7 123 Main Street, che apparirebbero 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: Theory IS pratico.

Le partenze dalla normalizzazione determineranno alcune anomalie nel tuo database.

Le partenze dal primo modulo normale causeranno anomalie di accesso, il che significa che devi decomporre e scansionare i singoli valori per trovare quello che stai cercando. Ad esempio, se uno dei valori è la stringa “Ford, Cadillac” data da una precedente risposta, e stai cercando tutte le occorrenze di “Ford”, dovrai aprire la stringa e guardare il sottostringhe. Questo, 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 le differenze non devono interessarti. Se si progettano le tabelle SQL utilizzando il modello di dati relazionali, le tabelle saranno automaticamente in 1NF.

Le partenze da Second Normal Form e oltre causeranno anomalie di aggiornamento, perché lo stesso fatto è memorizzato in più di un posto. Questi problemi rendono imansible memorizzare alcuni fatti senza memorizzare altri fatti che potrebbero non esistere, e quindi devono essere inventati. O quando i fatti cambiano, potrebbe essere necessario individuare tutti i fattori in cui è memorizzato un fatto e aggiornare tutti quei luoghi, per non finire con un database che si contraddice. E, quando si va a cancellare una riga dal database, si può scoprire che, se lo si fa, si sta 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 è ansible aggirare queste anomalie di aggiornamento mediante un’attenta programmazione. A volte (spesso) è meglio prevenire i problemi in primo luogo aderendo alle forms normali.

Nonostante il valore di ciò che è già stato detto, va detto che la normalizzazione è un approccio dal basso verso l’alto, non un approccio top-down. Se segui determinate metodologie nell’analisi dei dati e nel tuo progetto iniziale, puoi essere certo che il design sarà conforms almeno al 3NF. In molti casi, il design sarà completamente normalizzato.

Nei casi in cui si desideri realmente applicare i concetti insegnati in fase di normalizzazione si ha quando vengono dati dati legacy, da un database precedente o da file costituiti da record, ei dati sono stati progettati in completa ignoranza delle forms normali e delle conseguenze dell’abbandono da loro. In questi casi potrebbe essere necessario scoprire le partenze dalla normalizzazione e correggere il progetto.

Attenzione: la normalizzazione viene spesso insegnata con toni religiosi, come se ogni allontanamento dalla piena normalizzazione fosse un peccato, un’offesa contro Codd. (piccolo gioco di parole lì). Non comprarlo. Quando impari davvero, davvero, il design del database, non solo saprai come seguire le regole, ma anche sapere quando è sicuro romperle.

Prima di passare direttamente all’argomento “Normalizzazione del database e relativi tipi”, è necessario comprendere la ridondanza dei dati, le anomalie di inserimento / aggiornamento / cancellazione, la dipendenza parziale e la dipendenza funzionale transitiva.

Che cos’è la ridondanza dei dati e l’anomalia di aggiornamento / modifica?

La ridondanza dei dati è la duplicazione non necessaria dei dati in più tabelle all’interno del database o anche all’interno della stessa tabella. Aumenta inutilmente le dimensioni del database e diminuisce l’efficienza del database causando incoerenza dei dati.

Esempio:

inserisci la descrizione dell'immagine qui

Qui lo ‘student_age’ per lo studente Alex viene ripetuto inutilmente, il che aumenta naturalmente la ridondanza dei dati. Quando la colonna ‘student_age’ deve essere cambiata in futuro, allora l’aggiornamento deve essere eseguito su entrambe le righe dello studente Alex come nella tabella sopra. Questo scenario è noto come anomalia di aggiornamento. Se l’utente aggiorna solo una riga e si dimentica di aggiornare l’altra riga causerà incoerenza dei dati.

Cos’è l’anomalia di inserimento?

L’anomalia di inserimento si verifica quando determinati valori per un attributo * non possono essere inseriti in una tabella senza l’esistenza dei dati aggiuntivi relativi a quel particolare valore.

Esempio:

inserisci la descrizione dell'immagine qui

Qui si assume che ‘student_name’ e ‘exam_registered’ siano una chiave primaria composta (chiave primaria che contiene più colonne). La chiave primaria deve essere sempre univoca, non deve contenere valori NULL e deve identificare in modo univoco ogni riga di una tabella. Supponiamo ora che il liceo stia cercando di introdurre un nuovo esame chiamato Chimica. All’inizio nessuno studente è stato registrato in questo corso. Poiché la tabella sopra non accetterà il valore NULL nella colonna ‘nome_allievo’, è necessario attendere che almeno uno studente sia stato registrato per effettuare l’iscrizione all’esame Chimica nella tabella sopra.

Cos’è l’anomalia di cancellazione?

L’anomalia di eliminazione si verifica quando alcuni importanti valori di un attributo * vengono persi a causa della cancellazione di altri valori non richiesti.

Esempio:

inserisci la descrizione dell'immagine qui

Qui si assume che ‘student_name’ e ‘exam_registered’ siano una chiave primaria composta (chiave primaria che contiene più colonne). La chiave primaria deve essere sempre univoca e non deve contenere valori NULL e deve identificare in modo univoco ogni riga di una tabella. Supponiamo ora che lo studente di nome John abbia cancellato la sua registrazione per l’esame denominato inglese. Dal momento che la colonna ‘student_name’ non può contenere il valore NULL, saremo costretti a cancellare l’intera riga che ci è costata la perdita dell’esame denominato inglese dalla nostra tabella. Ma il liceo offre ancora la possibilità di sostenere l’esame di inglese ai propri studenti.

Qual è la dipendenza parziale?

Si dice che una tabella è in dipendenza parziale quando un attributo chiave non primario in quella tabella dipende completamente da una parte dell’attributo chiave primaria composta in quella tabella.

Esempio:

inserisci la descrizione dell'immagine qui

Prendi in considerazione una tabella con 3 colonne denominate ‘student_name’, ‘student_age’ e ‘exam_registered’ come sopra. Qui ‘student_name’ e ‘exam_registered’ possono insieme formare una chiave primaria composita. Normalmente ogni colonna chiave non primaria in una tabella ben normalizzata deve sempre dipendere dal set completo di chiave primaria composta. Qui ‘student_age’ dipende solo da ‘student_name’ e non è correlato a ‘exam_registered’ che fa sì che questa tabella sia in dipendenza parziale.

Qual è la dipendenza funzionale transitoria?

Si dice che una tabella si trovi nella dipendenza funzionale transitiva quando un attributo chiave non primario in quella tabella dipende in misura maggiore da un altro attributo chiave non primario in quella tabella.

Esempio:

inserisci la descrizione dell'immagine qui

Nella tabella sopra riportata la relazione tra l’attributo chiave non primario ‘codice_postale’ e un altro attributo chiave non primario ‘Città’ è molto più forte della relazione tra l’attributo chiave primaria ‘student_id’ e l’attributo chiave non primario ‘codice_postale’. Questo fa sì che la tabella sopra sia in dipendenza funzionale transitiva.

Con la migliore comprensione dei concetti di cui sopra possiamo ora tuffarci nella normalizzazione delle tabelle nei database.

I dati dipendono dalla chiave [1NF], dall’intera chiave [2NF] e nient’altro che dalla chiave [3NF]

Tabella senza normalizzazione

Di seguito viene riportata una tabella denormalizzata di esempio che verrà normalizzata nei passaggi incrementali in questo articolo.

Nell’esempio seguente per student_id = 2, ci sono 2 voci a causa di diversi ID padre. Qui possiamo assumere come Parent_id = 1 rappresenta il padre e Parent_id = 3 rappresenta la madre di questo studente cui student_id = 2.

Esempio:

inserisci la descrizione dell'immagine qui

Prima forma normale (1NF)

Regole: 1. Gli attributi devono contenere solo valori atomici 2. Nessuna riga di dati deve contenere un gruppo di informazioni ripetitivo 3. Ogni tabella deve avere una chiave primaria

Passo 1:

inserisci la descrizione dell'immagine qui

La regola 1 è soddisfatta nel passaggio precedente ma continua a non soddisfare la regola 2 e la regola 3.

Passaggio 2: le tabelle seguenti ora soddisfano la regola 1, la regola 2 e la regola 3 di 1NF.

inserisci la descrizione dell'immagine qui

Second Normal Form (2NF)

Regole:

  1. Le tabelle devono soddisfare la prima forma normale (1NF)
  2. Non ci dovrebbe essere alcuna dipendenza parziale all’interno delle tabelle

Tranne la prima tabella tutte le altre tabelle da 1NF soddisfano 2NF. Nella prima tabella la colonna ‘età’ dipende solo dalla colonna ‘student_id’. Questo viola la regola 2 di 2NF. Perché tutte le colonne non chiave devono dipendere completamente dalle colonne della chiave primaria. Quindi le tabelle normalizzate come da 2NF sono riportate di seguito.

inserisci la descrizione dell'immagine qui

Terza forma normale (3NF)

Di solito una tabella di database relazionale viene spesso descritta come ‘normalizzata’ se soddisfa 3NF. La maggior parte delle tabelle 3NF sono libere da inserire, aggiornare ed eliminare anomalie.

Regole:

  1. Le tabelle devono soddisfare la seconda forma normale (2NF)
  2. Non dovrebbero esserci delle dipendenze funzionali transitive all’interno delle tabelle

Tranne l’ultima tabella tutte le altre tabelle della 2NF soddisfano 3NF. Ciò è dovuto al fatto che la colonna “città” dipende in misura maggiore dalla colonna “codice postale” rispetto alla chiave primaria “student_id”, il che rende la colonna “città” funzionale alla transitiva in base alla colonna “id_studente”. Quindi le tabelle normalizzate finali come per 3NF sono date come sotto.

inserisci la descrizione dell'immagine qui

*Attributo:

– Considera una tabella di studenti. Qui student_name, età ecc. Sono considerati gli attributi che saranno il titolo delle colonne corrispondenti.

================================================== ====================== Semplici esempi: normalizzazione del database

La normalizzazione è uno dei concetti di base. Significa che due cose non influiscono l’una sull’altra.

Nei database significa in particolare che due (o più) tabelle non contengono gli stessi dati, cioè non hanno ridondanza.

A prima vista è davvero buono perché le possibilità di fare alcuni problemi 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 attraversare i dati e per ottenere alcuni risultati sumri.

Quindi, alla fine terminerai con un progetto di database che non è puro normalizzato, con qualche ridondanza (sarà in alcuni dei possibili livelli di normalizzazione).

Cos’è la normalizzazione?

La normalizzazione è un processo formale graduale che consente di scomporre le tabelle del database in modo tale da ridurre al minimo la ridondanza dei dati e le anomalie di aggiornamento .

Processo di normalizzazione
inserisci la descrizione dell'immagine qui Cortesia

Prima forma normale se e solo se il dominio di ciascun attributo contiene solo valori atomici (un valore atomico è un valore che non può essere diviso) e il valore di ciascun attributo contiene solo un singolo valore da quel dominio (esempio: – dominio per il dominio la colonna di genere è: “M”, “F”.).

La prima forma normale applica questi criteri:

  • Elimina i gruppi ripetuti nelle singole tabelle.
  • Creare una tabella separata per ogni serie di dati correlati.
  • Identificare ogni serie 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, ovvero tutti gli attributi non chiave dipendono completamente dal funzionamento DIRETTAMENTE solo sulla 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 forms normali di Second, Third e Boyce-Codd riguardano le dipendenze funzionali. Esempi

Quarta forma normale = 3NF + rimuovi dipendenze multivalore

Quinta forma normale = 4NF + rimuovi le dipendenze del join

Aiuta a prevenire i dati duplicati (e peggio, in conflitto).

Tuttavia, può avere un impatto negativo sulle prestazioni.