Free Press

Modelarea dimensională (DM) face parte din metodologia Business Dimensional Lifecycle, dezvoltată de Ralph Kimball, care include un set de metode, tehnici și concepte pentru utilizarea în proiectarea depozitelor de date. Abordarea se concentrează pe identificarea proceselor de afaceri cheie din cadrul unei întreprinderi și pe modelarea și implementarea acestora mai întâi înainte de a adăuga procese de afaceri suplimentare, o abordare ascendentă.

Care sunt obiectivele modelării depozitului de date?

Obiectivele, stabilite de Ross și Kimball, sunt simple:

• face informația ușor accesibilă
• prezintă informația în mod consecvent
• adaptabil și receptiv la schimbare
• prezintă informația în timp util
• protejează activele informaționale

.

• servesc ca o bază autorizată și de încredere pentru îmbunătățirea procesului decizional (sursă unică de adevăr în limbajul ingineriei datelor)
• VIP-urile trebuie să vă accepte sistemul

Dacă ați lucrat sau ați folosit un sistem ETL, ați fi observat că consistența informațiilor se realizează prin măsuri de conformare, promptitudinea asigurată de ciclurile ETL și adaptabilitatea depinde, de asemenea, în mare măsură de proiectarea ETL.

De ce modelare?

În calitate de inginer de date, cunoașteți SQL foarte bine și probabil că puteți scrie interogări SQL pentru toată ziua. Dar nu puteți presupune că utilizatorul final tipic va fi un expert în scrierea de interogări SQL. Așadar, obiectivul nostru este de a construi un DW atât de ușor pentru analiști încât să scrie rapid și eficient interogări de analiză.

Lucruri pe care nu ați vrea ca analiștii dvs. să le facă:

• Cercetare pe baza ID-ului
• Joncțiuni exterioare în cascadă (nici măcar dvs. nu ați vrea să faceți asta)
• Subinterogări multiple grupate sau alăturate
• Subinterogări recursive (vizitați doar Hackerrank SQL și veți înțelege durerea)
• Corelarea subinterogărilor: preluarea datelor de pe mai multe coloane în subinterogări diferite

Joncțiuni fără PK/FK: chiar și pentru mine(1.5 ani de experiență în DE), este greu de vizualizat.

Cele pe care le-ați putea și ar trebui să le așteptați de la analiștii dvs:

• unități simple
• colonii cu nume și text cuprinzător
• agregare simplă
• funcții analitice cu ferestre
• DISTINCT

Rețineți, punctele de mai sus nu sunt cele mai ușoare și că sistemul dvs. ar trebui să fie suficient de scalabil pentru toate aceste tipuri de interogări.

Bazele de date OLTP sunt transformate în fapte și dimensiuni datorită obiectivelor menționate mai sus.

Tranziția de la baze de date tranzacționale la fapte

Majoritatea întreprinderilor își măsoară succesul și eficiența prin măsurarea anumitor tipuri de date. Aceste date captează activitățile și progresul real al afacerii. Aceste date se numesc fapte.

Bazele de date orientate OLTP înregistrează tranzacțiile la un moment dat, un fel de flux de evenimente, dar centralizat în jurul tranzacțiilor. DW este diferit. DW nu trebuie să înregistreze detalii la nivel tranzacțional. DW trebuie să aibă fapte pe diferite criterii ale afacerii dumneavoastră. DW trebuie să agregheze (sau să lase analiștii să agregheze) informațiile necesare pentru a îmbunătăți afacerea. Și astfel, redundanța este un păcat de neiertat în DW.

Ce sunt măsurile și de ce ar trebui să vă umpleți tabelele de fapte cu ele?

Într-un depozit de date, o măsură este o proprietate asupra căreia se pot face calcule.

Factele pe care le obținem din depozitele de date operaționale vin cu unele date suplimentare care sunt de obicei însumate în analiza noastră. Acestea sunt aspectele unui fapt care permit analistului, sau executivului care vizualizează analiza, să vadă valoarea faptului.

De ce trebuie să mențineți o granulație consistentă?

Pentru a vă asigura că sistemul dvs. poate corela și agrega în mod legitim mai multe fapte.

Dar nu este întotdeauna posibil să aveți date la niveluri atomice. Deci, pentru a acoperi acest decalaj, există două metode:

• Tabele de fapte cu instantanee periodice
• Tabele de fapte cu instantanee de acumulare

Tabele de fapte cu instantanee periodice

După cum sugerează și numele, acestea sunt colectate la intervale regulate de timp. Consumul de gaz, auditul și inspecțiile sunt câteva exemple de colectare de date care au instantanee periodice activate pentru ele.

Accumulating Snapshot Fact Tables

Când un indicator de performanță a afacerii este o rată de finalizare a unui proces de afaceri în mai multe etape, este posibil să doriți să capturați la grămadă întreaga totalitate a procesului și să înregistrați începutul, finalizarea și etapele dintre ele. Acest lucru poate fi la nivel de tranzacție, dar are o mulțime de măsuri între ele. Așadar, folosiți tabele de fapte instantanee de acumulare pentru a răspunde la întrebări complexe în business intelligence, unde există trecerea timpului între fapte. Un bun exemplu ar fi un rând de tabel de fapte în care ați comandat un sandviș cu pui și rândul de tabel de fapte în care punga este înmânată prin geamul mașinii la McDonald’s drive-thru.

Localizarea faptelor prin intermediul dimensiunilor

Voi și analiștii voștri trebuie să știți cum să interogați și să filtrați faptele pentru a obține informații de afaceri din ele. Acest scop este servit de dimensiuni.

Desenarea dimensiunilor din datele de referință și datele meta brute

Dimensiunile sunt aproape întotdeauna create cu o cheie surogat; cheia surogat, în mod natural, este referită de cheia (sau cheile) externă (sau cheile) din tabelul de fapte. Căutăm în tabel căutând dimensiunile care ne interesează. Toate celelalte date care descriu faptele noastre, cum ar fi marcajele de timp, agenții clienților, locația magazinului, produsul și clientul, sunt cele pe care le transformăm în dimensiuni.

Frumusețea modelării dimensionale este că faptele nu sunt definite de cheile primare sau de orice fel de identificator unic, în schimb, ele sunt definite de combinația de dimensiuni. Acest lucru dă naștere la Star Schema.

Este foarte important să avem o unicitate în dimensiunile noastre. Atunci când ajungem la interogări între fapte, dublurile între combinațiile de dimensiuni se vor transforma într-un dezastru. Dacă nu puteți, atunci adăugați sau agregați dimensiuni pentru a le face unice.

Hierarhia în dimensiuni

Considerați următoarele două imagini.

Un analist va avea o viață ușoară dacă configurați pentru el/ea tabelul cu a doua dimensiune.

Atunci, cu al doilea tabel, aveți următoarea ierarhie:

Există tot felul de ierarhii – ierarhii multiple, ierarhii unice, etc. Nu le abordez în această postare pe blog.

Un lucru pe care aș dori să îl subliniez este că dimensiunea timp este o adevărată pacoste. Trebuie să vă ocupați de zilele magice, de calendarul fiscal, de fusurile orare, de cicluri(tipuri de profit pe trimestre). Și nu fiți prost sau prea încrezător în acest sens, nici măcar bazele de date cu serii de timp nu vă vor ajuta în ierarhii dacă ETL-ul dvs. este dat peste cap. Poate doriți să aruncați o privire la dimensiunile Outrigger. Există, de asemenea, ocazii în care o dimensiune este dependentă în mod natural de alta. Într-un astfel de caz, proiectanții pot pune o cheie străină de la una la cealaltă. Aceasta este ceea ce constituie o „dimensiune outrigger”. În cazul dimensiunilor calendaristice, acest lucru este foarte frecvent.

Nu puteți utiliza o dată la un grâu diferit într-un outrigger față de datele pe care le utilizați în tabelul de date. Nu puteți permite agregarea peste dimensiunile outrigger. Dacă este necesar, mascați valorile numerice din outrigger cu prefixe sau sufixe textuale pentru a obstrucționa acest lucru.

Modificarea lentă a dimensiunilor

Oricât de mult mi-aș dori să scriu despre asta, tot cred că este mai bine ca cititorii mei să înțeleagă temeinic acest concept de aici.

Nu discut despre dimensiunile Snowflake, dar, doar pentru a sublinia, acestea sunt încă în uz cu bazele de date OLAP.

Integrați Big Data în sistemul ETL

Vă veți trata Big Data-ul tabular ca și cum ar fi fost achiziționat prin una dintre fazele standard de extracție. Astfel, îi veți aplica aceiași pași pe care i-ați aplicat în transformare:

1. Curățarea datelor
2. Conformarea unităților și formatelor
3. Depublicarea
4. Restructurarea
5. Stadificarea

Rezumat

Am vrut să înțeleg aspectele teoretice ale proiectării bazelor de date, ceea ce m-a determinat să citesc cartea, Ross și Kimball. Apoi, am devenit curios să extrag diferențe și analogii între metodele lor și cele ale principalelor companii de astăzi care se bazează pe date, cum ar fi Netflix, Airbnb, Uber etc.

În această căutare, pot spune cu îndreptățire că formatul structurat de modelare dimensională este preferat unui ETL pur și simplu hardcore. Pentru că, în acest fel, eliminați dependența de dumneavoastră, echipa BI nu vă sună pe Slack pentru a crea un nou DAG pentru fiecare altă perspectivă, în schimb, cu o modelare corectă, le permiteți să acționeze și să exploreze liber fără a avea nevoie de dumneavoastră.

Vă rog să lăsați un feedback despre cum aș putea îmbunătăți, sunt sigur că nu a fost cea mai bună lectură. Vă mulțumesc pentru timpul acordat.

Notele de subsol

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross și Kimball, cap. 2 și cap. 18

Kimball/Ross pp103-109

.