Free Press

Dimensionale modellering (DM) maakt deel uit van de Business Dimensional Lifecycle-methodologie die is ontwikkeld door Ralph Kimball en die een reeks methoden, technieken en concepten omvat voor gebruik bij het ontwerpen van datawarehouses. De aanpak is gericht op het identificeren van de belangrijkste bedrijfsprocessen binnen een bedrijf en het eerst modelleren en implementeren van deze processen alvorens aanvullende bedrijfsprocessen toe te voegen, een bottom-up benadering.

Wat zijn de doelstellingen van Data Warehouse Modeling?

De doelstellingen, die door Ross en Kimball zijn uiteengezet, zijn rechttoe rechtaan:

• informatie gemakkelijk toegankelijk maken
• informatie consistent presenteren
• aanpasbaar en ontvankelijk voor verandering
• informatie tijdig presenteren
• informatie-activa beschermen
• als gezaghebbende en betrouwbare basis dienen voor betere besluitvorming (single source of truth in Data Engineering-taal)
• de VIP’s moeten uw systeem accepteren

Als u aan een ETL-systeem hebt gewerkt of het hebt gebruikt, zou je gemerkt hebben dat informatieconsistentie wordt bereikt door conforme maatregelen, tijdigheid door ETL-cycli en aanpassingsvermogen hangt ook grotendeels af van het ETL-ontwerp.

Waarom modelleren?

Als data engineer ken je SQL heel goed en kun je waarschijnlijk de hele dag door SQL queries schrijven. Maar je kunt er niet van uitgaan dat de typische eindgebruiker een expert is in het schrijven van SQL queries. Dus, ons doel is om een DW te bouwen dat zo gemakkelijk is voor analisten om snel en effectief analyse queries te schrijven.

Dingen die je je analisten niet zou willen laten doen:

• Queries gebaseerd op ID
• Cascading outer joins(zelfs jij zou dat niet willen doen)
• gegroepeerde of samengevoegde meervoudige subqueries
• recursieve subqueries(ga maar eens naar Hackerrank SQL en je zou de pijn begrijpen)
• Subquery correlatie: fetching data across multiple columns in different subqueries
• Joins zonder PK/FK: zelfs voor mij(1.5 jaar DE ervaring), is het moeilijk te visualiseren.

Dingen die je van je analisten zou kunnen en mogen verwachten:

• eenvoudige joins
• kolommen met namen en uitgebreide tekst
• eenvoudige aggregatie
• analytische windowed functies
• DISTINCT

Merk op, dat de bovenstaande punten niet de gemakkelijke zijn en dat uw systeem schaalbaar genoeg moet zijn voor al deze soorten queries.

De OLTP-databases worden getransformeerd in feiten en dimensies vanwege de bovengenoemde doelstellingen.

Omzetting van transactionele databases naar feiten

De meeste bedrijven meten hun succes en efficiëntie door bepaalde soorten gegevens te meten. Deze gegevens geven de werkelijke bedrijfsactiviteiten en voortgang weer. Deze gegevens worden feiten genoemd.

De OLTP-georiënteerde databases registreren transacties per keer, een soort event streaming maar dan gecentraliseerd rond transacties. Het DW is anders. Het DW hoeft geen details op transactieniveau vast te leggen. Het DW moet feiten hebben over verschillende criteria van je bedrijf. Het DW moet de informatie samenvoegen (of analisten laten samenvoegen) die nodig is om het bedrijf te verbeteren. Daarom is redundantie een onvergeeflijke zonde in DW.

Wat zijn maatregelen en waarom zou je je feitentabellen ermee vullen?

In een datawarehouse is een maatregel een eigenschap waarop berekeningen kunnen worden uitgevoerd.

De feiten die we ontlenen aan de operationele gegevensopslag gaan gepaard met een aantal aanvullende gegevens die typisch worden opgeteld in onze analyse. Dit zijn de aspecten van een feit die de analist, of de leidinggevende die de analyse bekijkt, in staat stellen de waarde in het feit te zien.

Waarom moet je een consistente korrel aanhouden?

Om ervoor te zorgen dat je systeem op legitieme wijze feiten kan correleren en aggregeren.

Maar het is niet altijd mogelijk om gegevens op atomaire niveaus te hebben. Dus, om deze kloof te overbruggen, zijn er twee methoden:

• Periodic Snapshot Fact Tables
• Accumulating Snapshot Fact Tables

Periodic Snapshot Fact Tables

Zoals de naam al doet vermoeden, worden ze verzameld met regelmatige tussenpozen. Verbruik van gas, audit, en inspecties zijn enkele voorbeelden van gegevensverzameling waarvoor periodieke snapshots zijn ingeschakeld.

Accumulerende Snapshot Fact Tables

Wanneer een bedrijfsprestatie-indicator een voltooiingspercentage is van een bedrijfsproces dat uit meerdere stappen bestaat, wilt u wellicht het gehele proces vastleggen en de start, de voltooiing, en de stappen daartussen registreren. Dit kan transactie-gedetailleerd zijn, maar er zitten veel maatregelen tussen. Je gebruikt dus accumulating snapshot fact tables om complexe vragen in business intelligence te beantwoorden waarbij er tijd verstrijkt tussen feiten. Een goed voorbeeld zou zijn een feitentabel rij van je bestelling van een broodje kip en de feitentabel rij van het zakje wordt overhandigd door het raam van de auto bij McDonald’s drive-thru.

Feiten lokaliseren via dimensies

U en uw analisten moeten weten hoe feiten te bevragen en te filteren om business intelligence af te leiden uit hen. Dit doel wordt gediend door dimensies.

Dimensies tekenen uit referentie- en ruwe-metagegevens

Dimensies worden bijna altijd gemaakt met een surrogaat-sleutel; de surrogaat-sleutel wordt natuurlijk gerefereerd door de foreign key (of sleutels) in de feitentabel. We doorzoeken de tabel door te zoeken in de dimensies waarin we geïnteresseerd zijn. Alle andere gegevens die onze feiten beschrijven, zoals tijdstempels, klantagenten, winkellocatie, product en klant, maken we tot dimensies.

Het mooie van dimensioneel modelleren is dat feiten niet worden gedefinieerd door de primaire sleutels of een soort unieke identificatiecode, maar door de combinatie van dimensies. Dit geeft aanleiding tot Star Schema.

Het is zeer belangrijk dat we een uniciteit in onze dimensies hebben. Wanneer we query’s over feiten gaan uitvoeren, zullen doublures tussen dimensiecombinaties een ramp worden. Als dat niet kan, voeg dan dimensies toe of aggregeer ze om ze uniek te maken.

Hiërarchie in dimensies

Kijk eens naar de volgende twee afbeeldingen.

Een analist heeft het makkelijk als je de tweede dimensietabel voor hem/haar opzet.

Met de tweede tabel hebt u dus de volgende hiërarchie:

Er zijn allerlei soorten hiërarchieën – meervoudige hiërarchieën, enkelvoudige hiërarchieën, enzovoort. Ik ga daar in deze blogpost niet op in.

Eén ding dat ik wel wil opmerken is dat de tijdsdimensie een echte pijn in de nek is. Je moet zorgen voor de magische dagen, de fiscale kalender, de tijdzones, de cycli (winst over kwartaal types). En wees niet belabberd of overmoedig in deze, zelfs tijdreeks databases zullen je niet helpen in hiërarchieën als je ETL verknoeid is. Je zou eens kunnen kijken naar Outrigger dimensies. Er zijn ook gelegenheden waarbij een dimensie van nature afhankelijk is van een andere. In zo’n geval kunnen ontwerpers een foreign key van de ene naar de andere zetten. Dit is wat een “outrigger dimension” is. In kalenderdimensies is dit heel gebruikelijk.

U kunt in een outrigger geen datum in een andere gradatie gebruiken dan de datums die u in de feitentabel gebruikt. U kunt geen aggregatie over outrigger-dimensies toestaan. U kunt numerieke waarden in de afdrukker eventueel maskeren met tekstvoorvoegsels of -suffixen om dit te verhinderen.

Slowly Changing Dimensions

Hoe graag ik er ook over zou willen schrijven, toch denk ik dat het voor mijn lezers beter is om dit concept vanaf hier goed te begrijpen.

Ik heb het niet over Snowflake-dimensies, maar om erop te wijzen dat ze nog steeds in gebruik zijn bij OLAP-databases.

Integreer je Big Data in je ETL-systeem

Je behandelt je Big Data in tabelvorm alsof ze zijn verkregen via een van je standaard Extract-fasen. U past er dus dezelfde stappen op toe als bij Transform:

1. Data cleansing
2. Conforming units and formats
3. De-duplication
4. Restructuring
5. Staging

Summary

Ik wilde de theoretische aspecten van databaseontwerp begrijpen, wat me ertoe bracht het boek van Ross en Kimball te lezen. Ik werd toen nieuwsgierig om verschillen en analogieën te trekken in hun methoden en die van de toonaangevende data-gedreven bedrijven van vandaag, zoals Netflix, Airbnb, Uber, enz.

In deze zoektocht, kan ik eerlijk zeggen dat de gestructureerde vorm van dimensionale modellering de voorkeur verdient boven gewoon een hardcore ETL. Want op deze manier verwijder je de afhankelijkheid van jou, je BI-team belt je niet op Slack om een nieuwe DAG te maken voor elk ander inzicht, in plaats daarvan stel je hen met de juiste modellering in staat om vrij te handelen en te verkennen zonder dat jij dat nodig hebt.

Laat alstublieft feedback achter over hoe ik het kan verbeteren, ik weet zeker dat dit niet uw beste leeswerk was. Dank u voor uw tijd.

Voetnoten

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