Quando dovresti denormalizzare?

Penso che tutti abbiamo familiarità con la normalizzazione del database .

La mia domanda è: quali sono alcune linee guida che usi quando vuoi denormalizzare le tabelle?

Denormalizza quando si tratta di operazioni OLAP, normalizza quando OLTP (dall'articolo collegato nella sezione Denormalizzazione)

I database destinati all'elaborazione delle transazioni online (OLTP) sono in genere più normalizzati rispetto ai database destinati all'elaborazione analitica online (OLAP). Le applicazioni OLTP sono caratterizzate da un elevato volume di piccole transazioni come l'aggiornamento di un record di vendite presso una cassa di un supermercato. L'aspettativa è che ogni transazione lasci il database in uno stato coerente. Al contrario, i database destinati alle operazioni OLAP sono principalmente database "letti principalmente". Le applicazioni OLAP tendono ad estrarre dati storici che si sono accumulati per un lungo periodo di tempo. Per tali database, i dati ridondanti o "denormalizzati" possono facilitare le applicazioni di business intelligence. In particolare, le tabelle dimensionali in uno schema a stella spesso contengono dati denormalizzati. I dati denormalizzati o ridondanti devono essere attentamente controllati durante l'elaborazione di estrazione, trasformazione, caricamento (ETL) e agli utenti non dovrebbe essere consentito di vedere i dati fino a quando non si trovano in uno stato coerente. L'alternativa normalizzata allo schema a stella è lo schema a fiocco di neve. In molti casi, la necessità di denormalizzazione è diminuita man mano che i computer e il software RDBMS sono diventati più potenti, ma poiché i volumi di dati sono generalmente aumentati insieme alle prestazioni hardware e software, i database OLAP spesso utilizzano ancora schemi denormalizzati.

La denormalizzazione viene anche utilizzata per migliorare le prestazioni su computer più piccoli come nei registratori di cassa informatici e sui dispositivi mobili, poiché questi possono utilizzare i dati solo per la ricerca (ad es. Ricerche di prezzo). La denormalizzazione può essere utilizzata anche quando non esiste un RDBMS per una piattaforma (come Palm), oppure non è necessario apportare modifiche ai dati e una risposta rapida è fondamentale.

Normalizza fino a quando non fa male, denormalizza fino a quando non funziona (ovvero: le prestazioni diventano accettabili) :)

Un motivo potenzialmente sensato per applicare la denormalizzazione controllata è se consente di applicare un vincolo di integrità ai dati che altrimenti non sarebbe possibile. La maggior parte dei DBMS SQL ha un supporto estremamente limitato per i vincoli multi-tabella. In SQL a volte l'unico modo efficace per implementare determinati vincoli è garantire che gli attributi coinvolti nel vincolo siano tutti presenti nella stessa tabella, anche quando la normalizzazione impone che appartengano a tabelle separate.

Denormalizzazione controllata significa che vengono implementati meccanismi per garantire che non possano sorgere incoerenze a causa di dati ridondanti. Il costo di questi controlli extra e il rischio di dati incoerenti devono essere considerati quando si decide se la denormalizzazione è utile.

Un altro motivo comune per la denormalizzazione è consentire alcune modifiche alle strutture di archiviazione o consentire altre ottimizzazioni fisiche che il DBMS non consentirebbe altrimenti. Secondo il principio di indipendenza dei dati fisici, un DBMS dovrebbe disporre dei mezzi per configurare le strutture di archiviazione interne senza alterare inutilmente la rappresentazione logica dei dati nel database. Sfortunatamente molti DBMS sono molto restrittivi delle opzioni di implementazione fisica disponibili per ogni dato schema di database. Tendono a compromettere l'indipendenza fisica del database supportando solo un'implementazione non ottimale del modello logico desiderato.

Dovrebbe essere ovvio, ma deve ancora essere detto: in ogni caso sono solo i cambiamenti nelle funzionalità di implementazione fisica che possono dettare le prestazioni, come strutture interne di dati, file, indicizzazione, hardware e così via. La normalizzazione e la denormalizzazione non hanno nulla a che fare con l'ottimizzazione delle prestazioni o dell'archiviazione.

Denormalizza se accedi frequentemente ai dati calcolati, come suggerito nelle risposte a questa domanda . Il costo per l'archiviazione e la gestione dei dati calcolati sarà spesso inferiore al costo di ripeterli ripetutamente se il profilo di carico è pesante.

Denormalizzo sistematicamente in modo da poter applicare l'integrità dei dati con vincoli. Un esempio è una domanda recente su questo sito : replica una colonna in un'altra tabella, in modo da poter utilizzare un vincolo CHECK per confrontarlo con un'altra colonna. Un altro esempio di questa tecnica è il mio post sul blog .

Non è possibile utilizzare i vincoli CHECK per confrontare colonne in righe diverse o in tabelle diverse, a meno che non si avvolga tale funzionalità in UDF scalari invocati da un vincolo CHECK. Che cosa succede se devi effettivamente confrontare colonne in righe diverse o in tabelle diverse per applicare una regola aziendale? Ad esempio, supponiamo che tu conosca l'orario di lavoro di un medico e desideri assicurarti che tutti gli appuntamenti rientrino nell'orario di lavoro? Naturalmente, è possibile utilizzare un trigger o una procedura memorizzata per implementare questa regola aziendale, ma né un trigger né una procedura memorizzata possono garantire al 100% che tutti i dati siano puliti: qualcuno può disabilitare o rilasciare il trigger, inserire alcuni dati sporchi e riattivare o ricreare il trigger. Inoltre, qualcuno può modificare direttamente la tabella ignorando le stored procedure.

Consentitemi di dimostrare come implementare questa regola aziendale utilizzando solo i vincoli FK e CHECK - ciò garantirà che tutti i dati soddisfino la regola aziendale purché tutti i vincoli siano attendibili.

Ancora un altro esempio è un modo per far rispettare che i periodi di tempo non hanno lacune e sovrapposizioni .