Free Press

A dimenziós modellezés (DM) a Ralph Kimball által kifejlesztett Business Dimensional Lifecycle módszertan része, amely egy sor módszert, technikát és fogalmat tartalmaz az adattárház tervezéséhez. A megközelítés a vállalkozáson belüli kulcsfontosságú üzleti folyamatok azonosítására, és a további üzleti folyamatok hozzáadása előtt először ezek modellezésére és megvalósítására összpontosít, azaz egy alulról felfelé irányuló megközelítésre.

Melyek az adattárház modellezésének céljai?

A Ross és Kimball által megfogalmazott célok egyszerűek:

• az információk könnyen hozzáférhetővé tétele
• az információk következetes bemutatása
• a változásokhoz való alkalmazkodóképesség és fogékonyság
• az információk időben történő bemutatása
• az információs eszközök védelme

.

• megbízható és hiteles alapként szolgál a jobb döntéshozatalhoz (az igazság egyetlen forrása Data Engineering nyelven)
• a VIP-knek el kell fogadniuk a rendszerét

Ha ETL rendszeren dolgozott vagy használt, észrevehette, hogy az információk konzisztenciáját a megfelelő intézkedésekkel érik el, az ETL-ciklusok által biztosított időszerűség és az alkalmazkodóképesség is nagyban függ az ETL kialakításától.

Miért modellezés?

Adatmérnökként nagyon jól ismeri az SQL-t, és valószínűleg egész nap SQL-lekérdezéseket tud írni. De nem feltételezheti, hogy a tipikus végfelhasználó szakértője az SQL-lekérdezések írásának. A célunk tehát az, hogy olyan DW-t építsünk, amely megkönnyíti az elemzők számára az elemzési lekérdezések gyors és hatékony írását.

Azok, amiket nem szeretné, ha az elemzői csinálnának:

• azonosítón alapuló lekérdezések
• Kaszkádos külső egyesítések (még ön sem szeretné ezt megtenni)
• csoportosított vagy egyesített több al-lekérdezések
• rekurzív al-lekérdezések (csak látogasson el a Hackerrank SQL-be, és megérti a fájdalmat)
• Al-lekérdezések korrelációja:
• Joins PK/FK nélkül: még nekem is(1.5 év DE tapasztalat), nehéz vizualizálni.

Az elemzőktől elvárható és elvárható dolgok:

• egyszerű joins
• névvel és átfogó szöveggel ellátott oszlopok
• egyszerű aggregálás
• analitikus ablakos függvények
• DISTINCT

Megjegyzem, a fenti pontok nem a könnyűek és a rendszerednek elég skálázhatónak kell lennie mindezen típusú lekérdezésekhez.

Az OLTP-adatbázisok a fent említett célok miatt átalakulnak tényekké és dimenziókká.

Tranzakciós adatbázisokról tényekre való áttérés

A legtöbb vállalkozás bizonyos típusú adatok mérésével méri sikerét és hatékonyságát. Ezek az adatok a valós üzleti tevékenységeket és az előrehaladást rögzítik. Ezeket az adatokat nevezzük tényeknek.

Az OLTP-orientált adatbázisok egyszerre rögzítik a tranzakciókat, olyasmi, mint az eseményfolyam, de a tranzakciók köré központosítva. A DW másképp működik. A DW-nek nem kell tranzakciós szinten rögzítenie a részleteket. A DW-nek az üzleti tevékenység különböző kritériumaira kiterjedő tényekre van szüksége. A DW-nek aggregálnia kell (vagy hagynia kell, hogy az elemzők aggregálják) az üzleti tevékenység javításához szükséges információkat. Ezért a redundancia megbocsáthatatlan bűn a DW-ben.

Mi az intézkedés, és miért kell megtölteni vele a ténytáblákat?

Az adattárházban az intézkedés egy olyan tulajdonság, amelyen számításokat lehet végezni.

A működési adattárolókból származó tényekhez további adatok tartoznak, amelyeket az elemzés során jellemzően összegezünk. Ezek a ténynek azok a szempontjai, amelyek lehetővé teszik az elemző vagy az elemzést megtekintő vezető számára, hogy meglássa a tényben rejlő értéket.

Miért kell konzisztens szemcséket fenntartani?

Azért, hogy a rendszerünk jogszerűen korrelálhasson és aggregálhasson a tények között.

De nem mindig lehetséges, hogy az adatok atomi szinten legyenek. Ezért, hogy áthidaljuk ezt a szakadékot, két módszer létezik:

• Periodikus pillanatfelvétel ténytáblák
• Akkumuláló pillanatfelvétel ténytáblák

Periodikus pillanatfelvétel ténytáblák

Amint a neve is mutatja, ezeket rendszeres időközönként gyűjtik. A gázfogyasztás, az audit és az ellenőrzések az adatgyűjtés néhány olyan példája, amelyekhez engedélyezve vannak az időszakos pillanatfelvételek.

Akumuláló pillanatfelvétel ténytáblák

Ha egy üzleti teljesítménymutató egy többlépcsős üzleti folyamat befejezésének aránya, akkor érdemes a folyamat egészének szemcséjénél rögzíteni, és rögzíteni a kezdetet, a befejezést és a közte lévő lépéseket. Ez lehet, hogy tranzakció-szemcsés, de sok intézkedés van a kettő között. Tehát az üzleti intelligencia összetett kérdéseinek megválaszolására halmozódó pillanatfelvétel-ténytáblákat használ, ahol a tények között időmúlás van. Jó példa lehet egy ténytábla sora arról, hogy Ön csirkés szendvicset rendel, és a McDonald’s drive-thru-nál a kocsi ablakán keresztül átadott táska ténytábla sora.

Tények keresése dimenziókon keresztül

Önnek és az elemzőinek tudniuk kell, hogyan kell lekérdezni és szűrni a tényeket, hogy üzleti intelligenciát nyerjenek belőlük. Ezt a célt szolgálják a dimenziók.

Dimenziók rajzolása referencia- és nyers metaadatokból

A dimenziókat szinte mindig helyettesítő kulccsal hozzák létre; a helyettesítő kulcsra természetesen a ténytábla idegen kulcsa (vagy kulcsai) hivatkoznak. A táblázatban úgy keresünk, hogy a minket érdeklő dimenziókra keresünk rá. A tényeinket leíró összes többi adatot, például az időbélyegeket, az ügyfélügynököket, az üzlet helyét, a terméket és az ügyfelet dimenziókká alakítjuk.

A dimenziós modellezés szépsége, hogy a tényeket nem az elsődleges kulcsok vagy valamilyen egyedi azonosító határozza meg, hanem a dimenziók kombinációja. Ebből adódik a Star Schema.

Nagyon fontos, hogy a dimenzióinkban legyen egyediség. Amikor a tényekre vonatkozó lekérdezésekhez jutunk, a dimenziókombinációk közötti duplikációk katasztrófává válnak. Ha ez nem lehetséges, akkor adjunk hozzá vagy aggregáljunk dimenziókat, hogy egyedivé tegyük őket.

Hierarchia a dimenziókban

Nézzük meg a következő két képet.

Egy elemzőnek könnyű dolga lesz, ha beállítja a második dimenziós táblázatot.

A második táblával tehát a következő hierarchiát kapjuk:

Mindenféle hierarchia létezik – többszörös hierarchia, egyszeres hierarchia stb. Ezekkel nem foglalkozom ebben a blogbejegyzésben.

Egy dolgot szeretnék kiemelni: az idődimenzió egy igazi nyűg. Gondoskodni kell a mágikus napokról, a pénzügyi naptárról, az időzónákról, a ciklusokról(profit over quarter típusok). És ebben ne légy pocsék vagy túlbuzgó, még az idősoros adatbázisok sem segítenek a hierarchiákban, ha az ETL-ed el van szúrva. Érdemes megnézni az Outrigger dimenziókat. Vannak olyan esetek is, amikor az egyik dimenzió természetesen függ a másiktól. Ilyen esetben a tervezők idegen kulcsot helyezhetnek el az egyikből a másikba. Ez az, ami egy “kiugró dimenziónak” minősül. A naptári dimenziókban ez nagyon gyakori.

Egy outriggerben nem használhat más szemcsenagyságú dátumot, mint a ténytáblában használt dátumokat. Nem engedélyezheti az aggregációt az outrigger dimenziók felett. Ha szükséges, az outriggerben lévő numerikus értékeket szöveges előtagokkal vagy utótagokkal maszkolja, hogy ezt megakadályozza.

Lassan változó dimenziók

Bármennyire is szeretnék erről írni, mégis úgy gondolom, hogy az olvasóimnak jobb, ha ezt a fogalmat alaposan megértik innen.

A Snowflake dimenziókról most nem beszélek, de csak hogy rámutassak, az OLAP-adatbázisoknál még mindig használatban vannak.

Integrálja a Big Data-t az ETL-rendszerébe

A táblázatos Big Data-t úgy fogja kezelni, mintha a szokásos Extract fázisok egyikén keresztül szerezte volna meg. Így ugyanazokat a lépéseket fogja alkalmazni rá, mint a transzformáció során:

1. Adattisztítás
2. Megfelelő egységek és formátumok
3. De-duplikáció
4. Újraszerkesztés
5. Staging

Összefoglalás

Az adatbázis-tervezés elméleti aspektusait akartam megérteni, ami arra késztetett, hogy elolvassam Ross és Kimball könyvét. Ezután kíváncsi lettem arra, hogy különbségeket és analógiákat vonjak le az ő módszereik és a mai vezető adatvezérelt vállalatok, például a Netflix, az Airbnb, az Uber stb. módszerei között.

Ezzel a törekvéssel tisztességesen ki tudom jelenteni, hogy a dimenzió alapú modellezés strukturált formája előnyösebb, mint a csak hardcore ETL. Mert így megszünteted a tőled való függőséget, a BI-csapatod nem csörög rád a Slacken, hogy minden második felismeréshez új DAG-ot hozz létre, hanem a helyes modellezéssel lehetővé teszed számukra, hogy szabadon, a te igényed nélkül cselekedjenek és felfedezzenek.

Kérem, hagyjon visszajelzést arról, hogyan tudnék javítani, biztos vagyok benne, hogy ez nem volt a legjobb olvasmány. Köszönöm, hogy időt szánt rám.

Lábjegyzetek

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

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

Ross and Kimball, ch 2 and ch 18

Kimball/Ross pp103-109