Come si determina fino a che punto normalizzare un database?

Question

Quando si crea una struttura di database, quali sono le buone linee guida da seguire o i buoni modi per determinare fino a che punto un database dovrebbe essere normalizzato?Dovresti creare un database non normalizzato e suddividerlo man mano che il progetto avanza?Dovresti crearlo completamente normalizzato e combinare le tabelle secondo necessità per le prestazioni?

Answer 1

Vuoi iniziare a progettare un database normalizzato fino alla terza forma normale.Man mano che sviluppi il livello della logica aziendale potresti decidere di dover denormalizzare un po', ma mai mai andare sotto il 3° modulo.Mantenete sempre conformi il 1° e il 2° modulo.Vuoi denormalizzare per semplicità del codice, non per prestazioni.Usa indici e procedure memorizzate per questo :)

Il motivo per cui non "normalizza mentre procedi" è che dovresti modificare il codice che hai già scritto la maggior parte ogni volta che modifichi la progettazione del database.

Ci sono un paio di buoni articoli:

http://www.agiledata.org/essays/dataNormalization.html

Answer 2

@GrizzlyGuru Un uomo saggio una volta mi disse "normalizza finché non fa male, denormalizza finché non funziona".

Non mi ha ancora deluso :)

Non sono d'accordo sull'iniziare con esso in una forma non normalizzata, tuttavia, nella mia esperienza è stato più semplice adattare l'applicazione per gestire un database meno normalizzato rispetto a uno più normalizzato.Potrebbe anche portare a situazioni in cui funziona "abbastanza bene" in modo da non riuscire mai a normalizzarlo (fino a quando non è troppo tardi!)

Answer 3

Normalizzare significa eliminare i dati ridondanti.In altre parole, un database non normalizzato o denormalizzato è un database in cui le stesse informazioni verranno ripetute in più posti diversi.Ciò significa che devi scrivere istruzioni di aggiornamento più complesse per assicurarti di aggiornare gli stessi dati ovunque, altrimenti otterrai dati incoerenti che a loro volta significano che l'output delle query non è attendibile.

Questo è un problema piuttosto grosso, quindi direi che la denormalizzazione fa male, non il contrario.

In alcuni casi potresti decidere deliberatamente di denormalizzare parti specifiche di un database, se ritieni che il vantaggio superi il lavoro aggiuntivo nell'aggiornamento dei dati e il rischio di corruzione dei dati.Ad esempio con i datawarehouse, dove i dati vengono aggregati per motivi di prestazioni e i dati, se spesso non vengono aggiornati dopo l'immissione iniziale, riducono il rischio di incoerenze.

Ma in generale sii stanco di denormalizzare per le prestazioni.Ad esempio, il vantaggio in termini di prestazioni di un join denormalizzato può in genere essere ottenuto utilizzando visione materializzata (chiamato anche vista indicizzata), che sarà veloce quanto eseguire una query su una tabella denormalizzata, ma protegge comunque la coerenza dei dati.

Answer 4

Jeff ha una panoramica abbastanza buona della sua filosofia sul suo blog: Forse la normalizzazione non è normale.La cosa principale è:non esagerare con la normalizzazione.Ma penso che un punto ancora più importante da tenere a mente sia che probabilmente non ha molta importanza.A meno che tu non stia utilizzando il prossimo Google, probabilmente non noterai molta differenza finché la tua applicazione non crescerà.

Answer 5

La normalizzazione del database ritengo sia una forma d'arte.

Non vuoi normalizzare eccessivamente il tuo database perché avrai troppe tabelle e ciò farà sì che le tue query, anche di oggetti semplici, richiedano più tempo del dovuto.

Una buona regola pratica che seguo è normalizzare le stesse informazioni ripetute più e più volte.

Ad esempio, se stai creando un'applicazione di gestione dei contatti, avrebbe senso avere l'indirizzo (via, città, stato, CAP, ecc.).) come tabella propria.

Tuttavia, se hai solo 2 tipi di contatti, aziendali o personali, hai bisogno di una tabella dei tipi di contatti se sai che ne avrai solo 2?Per me no.

Inizierei prima cercando di capire i tipi di dati di cui hai bisogno.Utilizzare un programma di modellazione per aiutare come Visio.Non vuoi iniziare con un database non normalizzato perché alla fine lo normalizzerai.Inizia inserendo gli oggetti nei raggruppamenti logici, poiché vedi che i dati ripetuti li portano in una nuova tabella.Continuerei a seguire questo processo finché non senti di aver progettato il database.

Lascia che i test ti dicano se è necessario combinare le tabelle.Una query ben scritta può coprire qualsiasi normalizzazione eccessiva.

Answer 6

Credo che iniziare con un database non normalizzato e passare alla normalizzazione man mano che si procede sia solitamente più semplice per iniziare.Alla domanda su quanto normalizzare, la mia filosofia è normalizzare finché non inizia a far male.Potrebbe sembrare un po’ irriverente, ma generalmente è un buon modo per valutare fino a che punto spingersi.

Answer 7

Avere un database normalizzato ti darà la massima flessibilità e la manutenzione più semplice.Inizio sempre con un database normalizzato e poi lo normalizzo solo quando c'è un problema nella vita reale che deve essere risolto.

Lo considero in modo simile alle prestazioni del codice, ad es.scrivi codice flessibile e gestibile e scendi a compromessi per le prestazioni quando tu Sapere che c'è un problema di prestazioni.

Answer 8

Il poster originale non descriveva mai in quale situazione verrà utilizzato il database.Se si tratta di un qualsiasi tipo di progetto di data warehousing in cui a un certo punto avrai bisogno di cubi (OLAP) che elaborano dati per alcuni front-end, sarebbe più saggio iniziare con lo schema a stella (tabelle dei fatti + dimensione) piuttosto che esaminare normalizzazione.I libri di Kimball saranno di grande aiuto in questo caso.

Answer 9

Sono d'accordo che in genere è meglio iniziare con un DB normalizzato e poi denormalizzarlo per risolvere problemi molto specifici, ma probabilmente inizierei da Forma normale di Boyce-Codd invece della terza forma normale.

Answer 10

La verità è che "dipende". Dipende da molti fattori tra cui:

• Codice (codificato manualmente o gestito da strumenti (come i pacchetti ETL))
• Applicazione primaria (elaborazione delle transazioni, data warehousing, reporting)
• Tipo di database (MySQL, DB/2, Oracle, Netezza, ecc.)
• Architettura del database (tabellare, colonnare)
• Qualità DBA (proattivo, reattivo, inattivo)
• Qualità dei dati prevista (vuoi applicare la qualità dei dati a livello di applicazione o a livello di database?)

Answer 11

Sono d'accordo che dovresti normalizzare il più possibile e denormalizzare solo se assolutamente necessario per le prestazioni.E con viste materializzate o schemi di memorizzazione nella cache questo spesso non è necessario.

La cosa da tenere a mente è che normalizzando il tuo modello stai fornendo al database maggiori informazioni su come vincolare i tuoi dati in modo da poter eliminare il rischio di anomalie di aggiornamento che possono verificarsi in modelli normalizzati in modo incompleto.

Se denormalizzi, devi convivere con il fatto che potresti ottenere anomalie di aggiornamento oppure devi implementare tu stesso la convalida dei vincoli nel codice dell'applicazione.Ciò elimina molti vantaggi dell'utilizzo di un DBMS che consente di definire questi vincoli in modo dichiarativo.

Quindi, presupponendo la stessa qualità del codice, la denormalizzazione potrebbe non offrire prestazioni migliori.

Un'altra cosa da menzionare è che l'hardware è economico al giorno d'oggi, quindi utilizzare una potenza di elaborazione aggiuntiva per risolvere il problema è spesso più conveniente che accettare i costi potenziali per la pulizia dei dati danneggiati.

Answer 12

Spesso se normalizzi per quanto gli altri software ti consentono, avrai finito.

Ad esempio, quando utilizzi la tecnologia di mappatura relazionale a oggetti, disporrai di un ricco set di semantica per varie relazioni molti-a-uno e molti-a-molti.Sotto il cofano fornirà tabelle di join con effettivamente 2 chiavi primarie.Anche se relativamente rara, la vera normalizzazione spesso fornisce relazioni con 3 o più chiavi primarie.In casi come questo, preferisco attenermi all'O/R e eseguire il rollio del mio codice per evitare le varie anomalie del DB.

Answer 13

Cerca solo di usare il buon senso.

Inoltre alcuni dicono - e sono d'accordo con loro - che, se ti ritrovi a unire 6 tabelle (il numero magico) insieme nella maggior parte delle tue query - escluse quelle relative ai report -, allora potresti prendere in considerazione l'idea di denormalizzare un po'.

Answer 14

Non dimenticare La madre di tutti i dibattiti sulla normalizzazione dei database sul Coding Horror (riassunto nel blog High Scalability).