La normalizzazione è tutto ciò che è necessario per garantire l'integrità dei dati e il reporting di qualità?

Ci sono due aspetti della domanda, ognuno con preoccupazioni leggermente diverse.

Is a correctly normalized database the only consideration when attempting to deliver a data store with solid data integrity, and that is easily reported on?

No. L'integrità dei dati richiede anche constraints .

• I vincoli della chiave primaria identificano univocamente un record. Ciò aiuta a prevenire i duplicati, ma non li impedisce necessariamente.

• I vincoli delle chiavi esterne aiutano a garantire che i dati correlati siano mantenuti sincronizzati: una tabella per "numeri di telefono dei clienti" dovrebbe avere un "cliente" corrispondente, ad esempio. I record orfani e i dati mancanti danneggiano l'integrità dei dati.

• I vincoli di campo / colonna possono aiutare a garantire che i dati siano validi. Ad esempio, forse un numero di telefono è memorizzato in un campo VARCHAR ma non deve memorizzare lettere o formattazione, solo numeri . Un vincolo può garantire che se i dati esistono, soddisfa criteri arbitrari che lo rendono valido per lo schema dato.

If so, does more normalization tend to lead to more reportable data?

La normalizzazione tende a portare a dati meno riferibili. Il motivo è che un tipico schema RDBMS è progettato attorno a ORM, che significa "oggetti applicazione". Quello che sembra un oggetto può richiedere più tabelle:

• Una classe che utilizza l'ereditarietà (ad esempio ha sottoclassi) richiede in pratica una tabella per livello di ereditarietà perché i membri dati secondari non sono applicabili alla superclasse e dovrebbero avere la propria tabella.

• Gli oggetti correlati possono avere la propria tabella. Un cliente con più numeri di telefono potrebbe essere List<String> nell'applicazione, ma i numeri di telefono potrebbero trovarsi nella propria tabella nello schema che forma una relazione 0..* .

I rapporti spesso sono basati su record dove un record è specifico del rapporto. Spesso denormalizzano i dati per dare una vista di una tabella specifica con i dati correlati mescolati. Questo è normalmente in contrasto con la normalizzazione e l'ORM.

Ciò significa che un oggetto che si utilizza abbastanza facilmente nell'applicazione potrebbe esplodere in molte tabelle nello schema del database, aggiungendo relazioni con cardinalità variabile. Ciò richiede join quando si scrive una query di report, alcuni dei quali potrebbero essere complessi o richiedere subquery. Ho visto query SQL di report con dieci o più join, subquery correlate, aggregati e altre funzionalità intermedie e avanzate di SQL che aggiungono complessità e possono danneggiare le prestazioni delle query.

Il modo tipico per affrontare questo come ho visto professionalmente è avere un set separato di tabelle di reporting denormalizzate create per i tuoi report. Utilizzare i trigger o le stored procedure per popolarli. Questo è più lavoro durante la persistenza, ma consente di risparmiare un sacco di tempo e di tirare i capelli quando scrivi SQL per i tuoi rapporti.

Puoi anche usare il codice dell'applicazione: quando salvi un oggetto e lo hai in memoria e i suoi oggetti correlati, costruisci una query per inserire o aggiornare un record nelle tue tabelle di rapporto. Questo potrebbe essere più facile e avere prestazioni di runtime più veloci rispetto a fare affidamento sui trigger.

"Normalizzazione" ha più significati e portano a risposte diverse per la tua domanda.

La normalizzazione che si impara nelle classi di database è un concetto teorico ben definito. Ogni volta che leggete dei dati che si trovano in "1 ° modulo normale", "2 ° modulo normale" ecc., Questo è il significato. Questo è fondamentalmente una buona cosa per diversi motivi, ma non è sempre la cosa migliore da fare per semplificare i rapporti. Al contrario, un enorme archivio di dati (data warehouse) potrebbe essere deliberatamente de-normalizzato in modo che i report funzionino meglio. (Esempio: un sistema completamente normalizzato potrebbe contenere ogni vendita e la sua quantità come un singolo record da qualche parte, ma per i report annuali è molto più efficiente avere le somme mensili precalcolate e archiviate pure.)

Ma l'integrità dei dati può anche significare i dati che sono esenti da duplicati spurie, errori di ortografia, campi mancanti, ecc. Ogni volta che si hanno record dei clienti sia per "Wiley Coyote" che per "Wiley E. Coyote", probabilmente si tratta di un errore che diminuisce la qualità dei tuoi dati, e probabilmente anche la qualità dei tuoi report, anche se nessun algoritmo di normalizzazione lo catturerà. Liberarsi da tali problemi può anche essere chiamato normalizzazione (o deduplicazione, o molte altre cose). È molto più difficile, ma migliora quasi sempre il valore dei tuoi dati - la domanda è se migliora abbastanza per pagare lo sforzo.