Perché molti progetti ignorano la normalizzazione in RDBMS?

Ho visto molti progetti secondo cui la normalizzazione non era la prima considerazione nella fase decisionale.

In molti casi questi progetti includevano più di 30 colonne e l'approccio principale era "mettere tutto nello stesso posto"

Secondo ciò che ricordo la normalizzazione è una delle prime cose più importanti, quindi perché a volte viene lasciata cadere così facilmente?

Modificare:

È vero che buoni architetti ed esperti scelgono un design denormalizzato mentre gli sviluppatori non esperti scelgono il contrario? Quali sono gli argomenti contro l'avvio del tuo progetto con in mente la normalizzazione?

La cosa interessante di questo thread di domande e risposte è che in realtà ci sono 3 domande. Tutti hanno risposto a una diversa, e quasi nessuno ha risposto alla prima:

1. Perché non sono alcuni database in natura normalizzate?
2. Perché / quando un database normalizzato dovrebbe essere denormalizzato ?
3. In quali situazioni è dannoso o non necessario in primo luogo normalizzare?

I lettori attenti noteranno che si tratta di domande molto diverse e cercherò di rispondere a ciascuna di esse separatamente evitando troppi dettagli. Con "troppo" intendo che non penso che questo sia il contesto appropriato in cui svolgere un ampio dibattito sul merito di vari argomenti a favore o contro la normalizzazione; Spiegherò semplicemente quali sono questi argomenti, magari elencherò alcune avvertenze e salverò la filosofia per domande più specifiche, se mai dovessero emergere.

Inoltre, in questa risposta presumo che la "normalizzazione" implichi "BCNF, 3NF o almeno 2NF" , poiché questo è il livello di normalizzazione che i progettisti generalmente mirano a raggiungere. È più raro vedere disegni 4NF o 5NF; sebbene non siano certamente obiettivi impossibili, si preoccupano della semantica delle relazioni piuttosto che della loro rappresentazione , che richiede una conoscenza considerevolmente maggiore sul dominio.

Quindi, verso l'alto e verso l'alto:

1. Perché alcuni database in the wild non sono normalizzati?

La risposta a questo potrebbe essere "perché non dovrebbero essere", ma fare quell'assunto fin dall'inizio è un lavoro investigativo piuttosto scadente. Non faremmo grandi progressi come società se operassimo sempre sul presupposto che qualunque cosa sia, dovrebbe essere.

Le vere ragioni per cui i database non vengono normalizzati in primo luogo sono più complicate. Ecco i primi 5 che ho incontrato:

• Gli sviluppatori che l'hanno progettato non sapevano o non capivano come normalizzare. La prova evidente di ciò si presenta sotto forma di molte altre scelte di progettazione di accompagnamento, come l' uso di colonne varchar per tutto o avere un pasticcio di spaghetti con nomi di tabelle e colonne insignificanti . E ti assicuro che ho visto database "reali" che sono altrettanto dannosi di quelli degli articoli TDWTF.

• Agli sviluppatori che lo hanno progettato non importava o erano attivamente contrari alla normalizzazione in linea di principio . Nota, qui non sto parlando di casi in cui è stata presa una decisione deliberata di non normalizzare sulla base di analisi contestuali, ma piuttosto team o aziende in cui la normalizzazione è più o meno compresa ma semplicemente ignorata o evitata per abitudine. Ancora una volta, sorprendentemente comune.

• Il software è / è stato fatto come un progetto Brownfield . Molti puristi ignorano questo business perfettamente legittimo piuttosto che una ragione tecnica per non normalizzare. A volte in realtà non riesci a progettare un nuovo database da zero, devi agganciarti a uno schema legacy esistente e tentare di normalizzare a quel punto comporterebbe troppo dolore. 3NF non fu inventato fino al 1971 e alcuni sistemi - in particolare i sistemi finanziari / contabili - hanno le loro radici ancora più indietro di così!

• Il database era originariamente normalizzato , ma un accumulo di piccole modifiche per un lungo periodo di tempo e / o un team ampiamente distribuito hanno introdotto sottili forme di duplicazione e altre violazioni di qualunque forma normale fosse originariamente in atto. In altre parole, la perdita di normalizzazione è stata accidentale e troppo poco tempo è stato dedicato al refactoring.

• È stata presa una deliberata decisione aziendale di non dedicare alcun tempo all'analisi aziendale o alla progettazione di database e semplicemente "farlo". Questa è spesso una falsa economia e alla fine diventa una forma crescente di debito tecnico , ma a volte è una decisione razionale, almeno basata su informazioni che erano conosciute all'epoca - ad esempio, il database potrebbe essere stato inteso come un prototipo ma è finito essere promosso all'uso della produzione a causa di vincoli di tempo o cambiamenti nell'ambiente aziendale.

2. Perché / quando un database normalizzato dovrebbe essere denormalizzato?

Questa discussione si presenta spesso quando un database è normalizzato per cominciare. O le prestazioni sono scadenti o c'è molta duplicazione nelle query (join) e il team ritiene, giustamente o erroneamente, di aver fatto tutto il possibile con il progetto attuale. È importante notare che la normalizzazione migliora le prestazioni per la maggior parte del tempo e ci sono diverse opzioni per eliminare i join in eccesso quando la normalizzazione sembra funzionare contro di te, molti dei quali sono meno invasivi e rischiosi rispetto al semplice passaggio a un modello denormalizzato:

• Crea viste indicizzate che incapsulano le aree problematiche più comuni. I DBMS moderni sono in grado di renderli inseribili o aggiornabili (ad esempio INSTEAD OFtrigger di SQL Server ). Questo ha un leggero costo per le dichiarazioni DML sulle tabelle / indici sottostanti, ma è generalmente la prima opzione che dovresti provare perché è quasi impossibile sbagliare e non costa quasi nulla da mantenere. Naturalmente, non tutte le query possono essere trasformate in una vista indicizzata: le query aggregate sono le più problematiche. Il che ci porta al prossimo articolo ...

• Creare tabelle aggregate denormalizzate che vengono automaticamente aggiornate dai trigger. Queste tabelle esistono in aggiunta alle tabelle normalizzate e formano una sorta di modello CQRS . Un altro modello CQRS, più popolare in questi giorni, è quello di utilizzare pub / sub per aggiornare i modelli di query, il che offre il vantaggio dell'asincronia, sebbene ciò non sia adatto in casi molto rari in cui i dati non possono essere obsoleti.

• A volte, le visualizzazioni indicizzate non sono possibili, le velocità di transazione e i volumi di dati sono troppo elevati per ammettere trigger con prestazioni accettabili e le query devono sempre restituire dati in tempo reale. Queste situazioni sono rare - immagino che potrebbero applicarsi a cose come il trading ad alta frequenza o database di forze dell'ordine / intelligence - ma possono esistere. In questi casi non hai davvero altra scelta che denormalizzare le tabelle originali.

3. In quali situazioni è dannoso o non necessario in primo luogo normalizzare?

Ci sono, infatti, diversi buoni esempi qui:

• Se il database viene utilizzato solo per report / analisi. In genere questo implica che esiste un database aggiuntivo e normalizzato utilizzato per OLTP, che viene periodicamente sincronizzato con il database di analisi tramite ETL o messaggistica.

• Quando si applica un modello normalizzato richiederebbe un'analisi inutilmente complessa dei dati in arrivo. Un esempio di ciò potrebbe essere un sistema che deve memorizzare i numeri di telefono raccolti da diversi sistemi o database esterni. Si potrebbe denormalizzare il codice di chiamata e la zona, ma che avrebbe dovuto conto per tutti i diversi formati possibili, i numeri di telefono non validi, numeri di vanità (1-800-GET-STUFF), per non parlare di diversi locali. Di solito è più un problema di quanto non valga la pena, e i numeri di telefono vengono solitamente inseriti in un singolo campo a meno che tu non abbia una specifica esigenza aziendale per il prefisso.

• Quando il database relazionale è principalmente lì per fornire supporto transazionale per un database aggiuntivo, non relazionale. Ad esempio, è possibile che si stia utilizzando il database relazionale come coda di messaggi o per tenere traccia dello stato di una transazione o di una saga, quando i dati primari vengono archiviati in Redis o MongoDB o altro. In altre parole, i dati sono "dati di controllo". Di solito non ha senso normalizzare i dati che in realtà non sono dati aziendali .

• Architetture orientate ai servizi che condividono un database fisico. Questo è un po 'di uno strano, ma in una vera e propria SOA, si avrà di tanto in tanto bisogno di avere dati duplicati fisicamente perché i servizi non sono autorizzati a query di dati direttamente l'un l'altro. Se si trovano a condividere lo stesso database fisico, i dati sembreranno non essere normalizzati, ma in generale, i dati di proprietà di ogni singolo servizio sono ancora normalizzati a meno che non sia presente uno degli altri fattori attenuanti. Ad esempio, un servizio di fatturazione potrebbe essere proprietario dell'entità fattura, ma il servizio di contabilità deve ricevere e archiviare la data e l'importo della fattura per includerla nelle entrate di quell'anno.

Sono sicuro che ci sono più ragioni che non ho elencato; quello a cui sto arrivando, in sostanza, è che sono abbastanza specifici e saranno abbastanza ovvi quando verranno in pratica. Database OLAP sono supposti a schemi utilizzo stelle, SOA sono suppone di avere alcuni doppioni, ecc Se si sta lavorando con un modello di architettura noto che semplicemente non funziona con la normalizzazione, allora non normalizzare; in generale, il modello di architettura ha la precedenza sul modello di dati.

E per rispondere all'ultima domanda:

È vero che buoni architetti ed esperti scelgono un design denormalizzato mentre gli sviluppatori non esperti scelgono il contrario? Quali sono gli argomenti contro l'avvio del tuo progetto con in mente la normalizzazione?

No, questo è completo e completo. BS È anche BS che gli esperti scelgono sempre un design normalizzato . Gli esperti non seguono solo un mantra. Ricercano, analizzano, discutono, chiariscono e ripetono, e quindi scelgono qualsiasi approccio abbia più senso per la loro situazione particolare.

Il database 3NF o BCNF è di solito un buon punto di partenza per l'analisi perché è stato provato e dimostrato con successo in decine di migliaia di progetti in tutto il mondo, ma poi di nuovo, così ha C. Ciò non significa che utilizziamo automaticamente C in ogni nuovo progetto. Le situazioni del mondo reale potrebbero richiedere alcune modifiche al modello o l'uso di un modello completamente diverso. Non lo sai finché non ti trovi in quella situazione.

Il presupposto integrato nella domanda e in alcune delle risposte è che la normalizzazione è anche una buona progettazione del database. Questo in realtà spesso non è il caso. La normalizzazione è un modo per raggiungere un determinato insieme di obiettivi di progettazione e un requisito se si fa molto affidamento sul database per applicare "regole commerciali" sulle relazioni tra gli elementi di dati.

La normalizzazione offre alcuni vantaggi chiave:

1. Riduce al minimo la quantità di dati ridondanti.
2. Massimizza la misura in cui i meccanismi di integrità integrati nel database (vincoli di chiave esterna, vincoli di unicità) possono essere sfruttati per garantire l'integrità dei dati.
3. Riduce il numero di colonne per riga aumentando l'efficienza di IO in alcuni casi. Le file di grandi dimensioni richiedono più tempo per essere recuperate.

Detto questo, ci sono molte ragioni valide per denormalizzare:

1. Le prestazioni, in particolare per l'analisi, possono essere paralizzate dalla normalizzazione. Per l'analisi rispetto a database relazionali, i modelli dimensionali denormalizzati sono l'approccio standard.
2. Il vantaggio di imporre l'integrità dei dati all'interno del database sta iniziando a diminuire. Poiché sempre più lo sviluppo si concentra sul livello intermedio orientato agli oggetti che spesso impone l'applicazione di regole aziendali, è meno importante fare affidamento sui vincoli relazionali nel database.
3. Come altri hanno già detto, la normalizzazione complicherà le query necessarie per recuperare i dati rilevanti.

Non è chiaro che la normalizzazione sia un segno di un buon design. In alcuni casi, la normalizzazione è un artefatto di un tempo in cui lo spazio di archiviazione era un premio e quando gran parte della responsabilità per la codifica delle regole aziendali risiedeva nel database (si pensi alle applicazioni client-server a 2 livelli con la maggior parte se non tutta la logica aziendale in procedura di archiviazione). È possibile che molti progetti si discostino dalla normalizzazione sulla base di buone decisioni architettoniche piuttosto che di una scarsa comprensione dei principi di progettazione del database.

L'articolo di Jeff Atwood a cui si fa riferimento nei commenti sopra fornisce alcune buone discussioni dettagliate: "Forse la normalizzazione non è normale" .

1. Molti sviluppatori non conoscono né si preoccupano della normalizzazione, della modellazione dei dati o del database.
2. Per alcuni lavori non è davvero importante.
3. A volte c'è una buona ragione per de-normalizzare, ad esempio per far funzionare bene un carico di lavoro particolarmente difficile.
4. I concetti relativi al database relazionale sono recentemente meno alla moda rispetto agli anni '90 e 2000. Gli sviluppatori tendono ad essere influenzati dalla moda, anche se affermano di essere molto razionali. Non ha senso discutere del gusto.

La normalizzazione è anche, storicamente, un territorio per argomenti quasi religiosi, quindi esito a dire molto di più.

Nei grandi progetti, e specialmente quelli nei mainframe, non è così. Infatti se cerchi siti di lavoro vedrai diverse posizioni per i modellatori di dati. Inoltre, avere molte colonne su una singola tabella non va contro la normalizzazione. Tuttavia, la tua osservazione è valida per alcuni progetti.

La progettazione di database è una delle competenze necessarie per costruire sistemi di qualità. Detto questo, alcuni sviluppatori non conoscono abbastanza la progettazione del database e continuano a essere assegnati al compito di modellizzazione dei dati e progettazione del database. Alcuni progetti saltano persino la modellazione dei dati. L'attenzione su molti progetti è principalmente sulla codifica e sul design front-end.

Un altro fattore per la cattiva progettazione del database è il fatto che la normalizzazione non è un argomento banale specialmente quando si tratta di 4 ° NF, 5 ° NF, ecc. La maggior parte dei libri che ho visto non sono stati in grado di spiegare chiaramente queste forme. Di solito ci sono cattivi esempi e troppa teoria. Questo rende l'argomento meno popolare di quanto dovrebbe.

Gli errori nella progettazione del database sono difficili da trovare se non li cerchi o li incontri durante i test. Non avere uno standard per la qualità di progettazione del database consente che gli errori si verifichino più probabilmente.

Aggiungete a ciò il fatto che alcuni progetti non seguono una rigorosa metodologia di sviluppo (che promuove la progettazione di database), di conseguenza, le responsabilità si mescolano e le attività si perdono tra l'analista aziendale, gli sviluppatori e i DBA. Gli sviluppatori parlano in OO e UML in cui i DBA parlano in DD e alcuni in ERD e probabilmente molti non ottengono UML o OO. In breve, la colpa è della mancanza di conoscenza, della mancanza di buone risorse chiare, della mancanza di un linguaggio unificato per descrivere i dati e della mancanza di metodologia.