database-design - relational vs non relational database




Database relazionali vs. dimensionali, qual è la differenza? (3)

Sto cercando di conoscere OLAP e il data warehousing e sono confuso sulla differenza tra la modellazione relazionale e quella dimensionale. La modellazione dimensionale è fondamentalmente una modellazione relazionale, ma consente di ottenere dati ridondanti / non normalizzati?

Ad esempio, supponiamo di avere dati di vendita storici su (prodotto, città, n. Vendite). Capisco che quanto segue sarebbe un punto di vista relazionale:

Product | City | # Sales
Apples, San Francisco, 400
Apples, Boston, 700
Apples, Seattle, 600
Oranges, San Francisco, 550
Oranges, Boston, 500
Oranges, Seattle, 600

Mentre il seguente è un punto di vista più dimensionale:

Product | San Francisco | Boston | Seattle
Apples, 400, 700, 600
Oranges, 550, 500, 600

Ma sembra che entrambi i punti di vista sarebbero comunque implementati in uno schema a stella identico:

Fact table: Product ID, Region ID, # Sales
Product dimension: Product ID, Product Name
City dimension: City ID, City Name

E non è fino a quando non inizi ad aggiungere alcuni dettagli aggiuntivi a ciascuna dimensione che le differenze iniziano a spuntare. Ad esempio, se si desidera tenere traccia delle regioni, un database relazionale tende ad avere una tabella di regione separata, al fine di mantenere tutto normalizzato:

City dimension: City ID, City Name, Region ID
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

Mentre un database dimensionale consentirebbe la denormalizzazione per mantenere i dati della regione all'interno della dimensione della città, al fine di semplificare la suddivisione dei dati:

City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

È corretto?


Ho letto di recente la differenza tra Dimensional e Relational Data Modeling poiché utilizziamo principalmente modelli relazionali nella mia azienda in cui archiviamo un Enterprise Data Warehouse (EDW).

Secondo Steve Hoberman nel suo libro "Data Modeling Made Simple" la distinzione tra i 2 tipi di modelli è questa:

  • I modelli di dati relazionali acquisiscono la soluzione aziendale per il funzionamento di una parte dell'azienda, ovvero i processi aziendali
  • Dati dimensionali I modelli catturano i dettagli di cui l'azienda ha bisogno per rispondere a domande su come sta andando bene

Si può sostenere che un modello relazionale può essere utilizzato anche come base su cui rispondere alle domande di business, ma a livello tattico. "Quanti ordini sono in uno stato insoddisfatto per il cliente x a causa della stretta creditizia?" Ma la distinzione è quella in cui la domanda di segnalazione richiede il "grana nativo" della tabella e quando la domanda di rapporto può essere risolta con dati riepilogati.

Nei due esempi sopra riportati sono in realtà entrambi esempi di modellazione dati dimensionale poiché nessuna delle due tabelle memorizza l'ordine di vendita nella sua "grana nativa" e pertanto non acquisisce il processo aziendale di creazione di un ordine di vendita. L'unica differenza tra i 2 tavoli è che nella seconda tabella la dimensione della città è stata trasposta nella tabella dei fatti.


Ho trovato la descrizione che ho trovato su http://www.orafaq.com/node/2286 per essere molto utile quando si arriva agli schemi a stella da una prospettiva relazionale.

Prendi in considerazione un modello di dati completamente normalizzato. Ora pensa esattamente al contrario, dove denormalizzi completamente il tuo modello di dati relazionale in modo da avere solo un record piatto come un foglio di calcolo big'ol con una riga molto ampia. Ora esegui il backup di questo record flat solo un po 'in modo da avere un modello di dati che ha solo due livelli di profondità; un grande tavolo e diversi tavolini a cui punta il grande tavolo. Questo è uno schema STAR. Quindi un vero modello di dati a stella ha due attributi, ha sempre due livelli di profondità e un modello di stella reale contiene sempre solo una tabella grande che è il punto focale del modello.


Uno schema a stella si trova davvero all'intersezione del modello relazionale dei dati e del modello dimensionale dei dati. È davvero un modo per iniziare con un modello dimensionale e mapparlo in tabelle SQL che assomigliano in qualche modo alle tabelle SQL che si ottengono se si parte da un modello relazionale.

Dico in qualche modo come se molte metodologie di progettazione relazionale risultassero in un progetto normalizzato, o almeno un progetto quasi normalizzato. Uno schema a stella avrà delle partenze significative dalla piena normalizzazione.

Ogni deviazione dalla piena normalizzazione porta con sé una conseguente anomalia nell'aggiornamento dei dati. (Sto includendo le anomalie sulle operazioni di inserimento, aggiornamento ed eliminazione sotto un unico ombrello). Queste anomalie non hanno nulla a che fare con quale modello di dati hai iniziato.

Il commento su OLTP contro OLAP è pertinente qui. Le anomalie di aggiornamento avranno impatti diversi sulle prestazioni e / o difficoltà di programmazione in queste due situazioni.

Oltre a uno schema a stella in una base dati SQL, ci sono prodotti di database dimensionale là fuori che memorizzano i dati in una forma fisica che è unica per quel prodotto. Con questi prodotti, non si vede uno schema a stella così come si vede un'implementazione diretta del modello dimensionale e un'interfaccia che potrebbe essere peculiare del prodotto. Alcune di queste interfacce consentono alle operazioni OLAP di essere completamente point-and-click.

Proprio come una divagazione dalla tua domanda, una volta ho creato uno schema a stella come passaggio intermedio tra un database OLTP che supportava un'applicazione basata sulle transazioni e una data block all'interno di Cognos PowerPlay. Utilizzando le tecniche ETL standard, il trasferimento combinato dal database OLTP allo schema a stella e quindi dallo schema a stella al cubo di dati ha sovraperformato il trasferimento diretto dal database OLTP al datacube. Questo è stato un risultato inaspettato.

Spero che questo ti aiuti.







non-relational-database