Database
 sql >> Database >  >> RDS >> Database

Schema a stella e schema a fiocco di neve

Nei due articoli precedenti, abbiamo considerato i due modelli di data warehouse più comuni:lo schema a stella e lo schema a fiocco di neve. Oggi esamineremo le differenze tra questi due schemi e ti spiegheremo quando è meglio utilizzare l'uno o l'altro.

Lo schema a stella e lo schema a fiocco di neve sono modi per organizzare data mart o interi data warehouse utilizzando database relazionali. Entrambi utilizzano tabelle delle dimensioni per descrivere i dati aggregati in una tabella dei fatti .

Tutti vendono qualcosa, che si tratti di conoscenza, di un prodotto o di un servizio. Anche la memorizzazione di queste informazioni, sia in un sistema operativo che in un sistema di reporting, è una necessità. Quindi possiamo aspettarci di trovare un qualche tipo di modello di vendita all'interno del data warehouse di quasi tutte le aziende.

Diamo un'altra occhiata al modello di vendita negli schemi sia a stella che a fiocco di neve.

Lo schema a stella



La caratteristica più ovvia dello schema a stella è che le tabelle dimensionali non sono normalizzate. Nel modello sopra, il rosa fact_sales la tabella memorizza i dati aggregati creati dai nostri database operativi. I tavoli azzurri sono tabelle dimensionali. Abbiamo deciso di utilizzare queste cinque dimensioni perché dobbiamo creare report utilizzandole come parametri. La granulazione all'interno di ogni dimensione è determinata anche dalle nostre esigenze di reporting.

Da questo modello, possiamo facilmente capire perché questo schema è chiamato "schema a stella":sembra una stella, con le tabelle delle dimensioni che circondano la tabella dei fatti centrale.

Lo schema del fiocco di neve



Questo schema del fiocco di neve memorizza esattamente gli stessi dati dello schema a stella. La tabella dei fatti ha le stesse dimensioni dell'esempio dello schema a stella. La differenza più importante è che le tabelle delle dimensioni nello schema del fiocco di neve sono normalizzate. È interessante notare che il processo di normalizzazione delle tabelle dimensionali è chiamato fiocco di neve.

Ancora una volta, visivamente lo schema del fiocco di neve ricorda il suo omonimo, con diversi strati di tabelle dimensionali che creano una forma irregolare simile a un fiocco di neve.

La prima differenza:normalizzazione

Come accennato, la normalizzazione è una differenza fondamentale tra gli schemi a stella e a fiocco di neve. A questo proposito, ci sono un paio di cose da sapere:

  • Gli schemi Snowflake utilizzeranno meno spazio per memorizzare le tabelle delle dimensioni. Questo perché di norma qualsiasi database normalizzato produce molti meno record ridondanti.
  • I modelli di dati denormalizzati aumentano le possibilità di problemi di integrità dei dati. Questi problemi complicheranno anche le modifiche e la manutenzione future.
  • Agli esperti di modellazione di dati, lo schema del fiocco di neve sembra organizzato in modo più logico rispetto allo schema a stella. (Questa è la mia opinione personale, non un dato di fatto. :) )

Passiamo alla seconda grande differenza tra questi due schemi.

La seconda differenza:complessità delle query

Nei nostri primi due articoli, abbiamo dimostrato una query che potrebbe essere utilizzata sul modello di vendita per ottenere la quantità di tutti i prodotti di tipo telefono venduti nei negozi di Berlino nel 2016.

La query dello schema a stella ha il seguente aspetto:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id

WHERE 
  dim_time.action_year = 2016
  AND dim_store.city = 'Berlin'
  AND dim_product.product_type = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Per ottenere lo stesso risultato dallo schema del fiocco di neve, dobbiamo usare questa query:

SELECT 
  dim_store.store_address,
  SUM(fact_sales.quantity) AS quantity_sold

FROM 
  fact_sales
  INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
  INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_type_id
  INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
  INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
  INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
  INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id

WHERE 
  dim_year.action_year = 2016
  AND dim_city.city = 'Berlin'
  AND dim_product_type.product_type_name = 'phone'

GROUP BY 
  dim_store.store_id,
  dim_store.store_address

Ovviamente, la query dello schema del fiocco di neve è più complessa. Poiché le tabelle dimensionali sono normalizzate, è necessario scavare più a fondo per ottenere il nome del tipo di prodotto e della città. Dobbiamo aggiungere un altro JOIN per ogni nuovo livello all'interno della stessa dimensione.

Nello schema a stella, uniamo la tabella dei fatti solo alle tabelle delle dimensioni di cui abbiamo bisogno. Al massimo, avremo un solo JOIN per tabella dimensionale. E se non stiamo usando una tabella dimensionale, non dobbiamo nemmeno preoccuparcene. Nella query dello schema del fiocco di neve, non sappiamo quanto dovremo andare in profondità per ottenere il livello di dimensione corretto, quindi ciò complica il processo di scrittura delle query.

L'unione di due tabelle richiede tempo perché il DMBS impiega più tempo per elaborare la richiesta. Il dim_store e dim_city le tabelle sono posizionate in stretta vicinanza nel nostro modello, ma potrebbero non essere posizionate in nessuna parte l'una vicino all'altra sul disco. Esiste una migliore possibilità che i dati siano fisicamente più vicini sul disco se risiedono all'interno della stessa tabella.

Fondamentalmente, una query eseguita su un data mart dello schema del fiocco di neve verrà eseguita più lentamente. Ma nella maggior parte dei casi questo non rappresenta un problema:non importa molto se otteniamo il risultato in un millisecondo o un secondo.

Accelerare le cose

Per velocizzare i rapporti, possiamo:

  • Aggiungi i dati al livello di cui abbiamo bisogno nei rapporti. Ciò comprimerà i dati in modo significativo. Avremo bisogno di creare procedure che trasformeranno i nostri dati in tempo reale per adattarli alla struttura dello schema di reporting (il processo ETL).
  • Costruisci un'area di archiviazione centrale per tutti i dati aggregati dell'azienda, non solo i dati di vendita.
  • Fornisci agli utenti solo i dati di cui hanno bisogno per analisi e rapporti.

Schemi fiocco di neve e stella:quale utilizzare?

Ora che abbiamo esaminato la teoria e la velocità delle query, entriamo nel vivo della questione:come fai a sapere quale schema utilizzare su un determinato progetto?

Prendi in considerazione l'utilizzo dello schema del fiocco di neve :

  • Nei data warehouse. Poiché il magazzino è Data Central per l'azienda, potremmo risparmiare molto spazio in questo modo.
  • Quando le tabelle dimensionali richiedono una quantità significativa di spazio di archiviazione. Nella maggior parte dei casi, le tabelle dei fatti saranno quelle che occupano la maggior parte dello spazio. Probabilmente cresceranno anche molto più velocemente delle tabelle dimensionali. Ma ci sono alcune situazioni in cui ciò non si applica. Ad esempio, le tabelle delle dimensioni potrebbero contenere molti attributi ridondanti ma necessari. Nel nostro esempio, abbiamo usato la città attributo per descrivere la città in cui si trova il negozio. E se volessimo una descrizione molto più dettagliata della città, inclusi popolazione, codice postale, dati demografici, ecc.? Descrivere altre sottodimensioni, ad esempio negozio , regione , stato e paese – con più attributi girerebbe il dim_store tabella dimensionale in un'unica grande tabella con molta ridondanza.
  • Se utilizzi strumenti che richiedono uno schema di fiocchi di neve in background. (Fortunatamente, la maggior parte degli strumenti moderni supporta sia gli schemi che persino lo schema della galassia.)

Prendi in considerazione l'utilizzo dello schema a stella :

  • Nei data mart. I data mart sono sottoinsiemi di dati prelevati dal data warehouse centrale. Di solito sono creati per diversi reparti e non contengono nemmeno tutti i dati storici. In questa impostazione, il risparmio di spazio di archiviazione non è una priorità.

    D'altra parte, lo schema a stella semplifica l'analisi. Non si tratta solo dell'efficienza delle query, ma anche della semplificazione delle azioni future per gli utenti aziendali. Possono comprendere i database e sapere come scrivere query, ma perché complicare le cose e includere più join se possiamo evitarlo? Un utente aziendale potrebbe avere una query modello che unisce la tabella dei fatti con tutte le tabelle delle dimensioni. Quindi devono solo aggiungere le selezioni e i raggruppamenti appropriati. (Questo approccio è simile alle tabelle pivot di Excel.)

  • Se utilizzi strumenti che richiedono uno schema a stella in background. (Di nuovo, questo di solito non è un problema.)

Sia lo schema a stella che lo schema a fiocco di neve sono modelli relazionali utilizzati per organizzare data warehouse e/o data mart. Non importa quanto siano simili, dimostrano due approcci diversi e hanno i loro vantaggi e svantaggi. Personalmente, userei lo schema del fiocco di neve quando si implementa un data warehouse (per risparmiare spazio di archiviazione) e con lo schema a stella per i data mart (per semplificare la vita agli utenti aziendali).