Domanda

Perché i ragazzi del database continuano la normalizzazione?

Che cos'è? Come aiuta

Si applica a qualsiasi cosa al di fuori dei database?

È stato utile?

Soluzione

La normalizzazione consiste essenzialmente 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, esiste il rischio che vengano aggiornati in un punto ma non nell'altro, con conseguente danneggiamento dei dati.

Esistono diversi livelli di normalizzazione da 1. forma normale a 5. forma normale. Ogni modulo normale descrive come sbarazzarsi di alcuni problemi specifici, generalmente legati 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 il " Car " colonna (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 eliminando una riga separata per macchina:

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

Il problema di avere diversi valori in una cella è che è difficile aggiornarlo, è difficile interrogarlo e non è possibile applicare indici, vincoli e così via.

(2) Avere dati non chiave ridondanti (ad es. dati ripetuti inutilmente in più righe). 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 da UserId. Ciò rende teoricamente possibile cambiare il nome di Sue in una riga e non nell'altra, che è corruzione 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 sono 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 apre il rischio di ottenere dati non validi o corrotti nel database. Poiché i dati "vivono per sempre" è molto difficile sbarazzarsi di dati corrotti quando è entrato 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 processo matematico complicato. Tuttavia, la normalizzazione è fondamentalmente solo il buonsenso e scoprirai che se si progetta uno schema di database usando il buonsenso sarà in genere completamente normalizzato.

Esistono diverse idee sbagliate sulla normalizzazione:

  • alcuni ritengono che i database normalizzati siano più lenti e la denormalizzazione migliora le prestazioni. 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 fermare". 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 qualsiasi cosa al di fuori dei database? Non direttamente, no. I principi della normalizzazione sono abbastanza specifici per i database relazionali. Tuttavia, il tema generale sottostante - che non dovresti avere dati duplicati se le diverse istanze non possono essere sincronizzate - può essere applicato in modo ampio. Questo è fondamentalmente il principio DRY .

Altri suggerimenti

Le regole di 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 un posto (tabelle) in cui il nome di una persona potrebbe apparire, sposta il nome in una tabella separata e fai riferimento in qualsiasi altro luogo. In questo modo, se è necessario modificare il nome della persona in un secondo momento, è necessario modificarlo in un solo 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 informazioni da molte tabelle, si stanno perdendo alcune prestazioni ed è per questo che a volte è possibile 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 fare de-normalizzazione solo quando veramente necessario

P.S. 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 in 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 (prima forma normale, praticamente per definizione) Normalizzare significa cambiare lo schema (spesso partizionando le tabelle) in modo reversibile, dando un modello che è funzionalmente identico, tranne con meno ridondanza e dipendenze.

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

Ha lo scopo di ridurre la ridondanza dei dati.

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

Faccio un esempio un po 'semplicistico.

Presumi 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 tabella familiare

ID, address
27 123 Main St.

La normalizzazione quasi completa (BCNF) di solito non viene utilizzata nella produzione, ma è una fase intermedia. Una volta inserito il database in BCNF, il passaggio successivo è in genere De-normalizzare in modo logico per accelerare 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 siano ridotte a una singola voce. Ciò è particolarmente utile in campi come gli indirizzi, in cui il signor Chris presenta il suo indirizzo come Unit-7 123 Main St. e la signora Chris elenca Suite-7 123 Main Street, che verrebbe visualizzata nella tabella originale come due indirizzi distinti.

In genere, la tecnica utilizzata è quella di 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 Data: la teoria è pratica.

Le deviazioni dalla normalizzazione comporteranno alcune anomalie nel 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" come dato da una risposta precedente e stai cercando tutte le occorrenze di "Ford", dovrai aprire la stringa e guardare le sottostringhe. Questo, in una certa misura, vanifica lo scopo di archiviare i dati in un database relazionale.

La definizione di First Normal Form è cambiata dal 1970, ma per ora quelle differenze non ti riguardano. Se si progettano le tabelle SQL utilizzando il modello di dati relazionali, le tabelle saranno automaticamente in 1NF.

Le partenze dalla seconda forma normale e oltre causeranno anomalie di aggiornamento, poiché lo stesso fatto è archiviato in più di una posizione. Questi problemi rendono impossibile archiviare alcuni fatti senza memorizzare altri fatti che potrebbero non esistere e che pertanto devono essere inventati. O quando i fatti cambiano, potrebbe essere necessario individuare tutte le possibilità in cui è archiviato un fatto e aggiornare tutti quei luoghi, per non finire con un database che si contraddice. E, quando vai a cancellare 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 di spazio. A volte è possibile aggirare queste anomalie di aggiornamento attraverso un'attenta programmazione. A volte (spesso) è meglio prevenire i problemi in primo luogo aderendo alle forme 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 dall'alto verso il basso. Se segui determinate metodologie nell'analisi dei dati e nella progettazione iniziale, puoi essere certo che la progettazione sarà conforme almeno a 3NF. In molti casi, il design sarà completamente normalizzato.

Il punto in cui potresti voler applicare i concetti insegnati durante la normalizzazione è quando ti vengono dati dati legacy, da un database legacy o da file costituiti da record, e i dati sono stati progettati in completa ignoranza delle forme normali e conseguenze della loro partenza. In questi casi potrebbe essere necessario scoprire le partenze dalla normalizzazione e correggere il design.

Avvertenza: la normalizzazione viene spesso insegnata con sfumature religiose, come se ogni deviazione dalla piena normalizzazione fosse un peccato, un'offesa contro Codd. (piccolo gioco di parole lì). Non comprarlo. Quando imparerai davvero la progettazione del 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 significa specificamente 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 alcuni problemi di sincronizzazione sono vicine allo zero, sai sempre dove sono i tuoi dati, ecc. Ma, probabilmente, il tuo numero di tabelle crescerà e avrai problemi a incrocia i dati e per ottenere alcuni risultati di riepilogo.

Quindi, alla fine, finirai con una progettazione di database che non è pura normalizzazione, con una certa ridondanza (sarà in alcuni dei possibili livelli di normalizzazione).

  

Che cos'è la normalizzazione?

La normalizzazione è un processo formale saggio che ci consente di scomporre le tabelle del database in modo tale che sia ridondanza dei dati sia anomalie di aggiornamento sono minimizzate.

Processo di normalizzazione
inserisci qui la descrizione dell'immagine Courtesy

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: - il dominio per la colonna del genere è: "M", "F".).

Il primo modulo 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, ovvero tutti gli attributi non chiave dipendono completamente dalla chiave primaria.

Terza forma normale = 2NF + nessuna dipendenza transitiva, vale a dire tutti gli attributi non chiave dipendono completamente dal DIRECTLY solo dalla chiave primaria.

Forma normale di Boyce-Codd (o BCNF o 3.5NF) è una versione leggermente più potente della terza forma normale (3NF).

Nota: - Le forme normali di Second, Third e Boyce – Codd riguardano le dipendenze funzionali. Esempi

Quarta forma normale = 3NF + rimuovi dipendenze multivalore

Quinta forma normale = 4NF + rimuovi dipendenze join

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

Tuttavia, può avere un impatto negativo sulle prestazioni.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top