Het sterrenschema

Tegenwoordig zijn rapporten en analyses bijna net zo belangrijk als de kernactiviteiten. Rapporten kunnen worden opgebouwd uit uw live data; vaak zal deze aanpak het lukken voor kleine en middelgrote bedrijven zonder veel data. Maar wanneer de zaken groter worden - of de hoeveelheid gegevens dramatisch begint toe te nemen - is het tijd om na te denken over het scheiden van uw operationele en rapportagesystemen.

Voordat we beginnen met basisgegevensmodellering, hebben we wat achtergrondinformatie nodig over de betrokken systemen. We kunnen systemen grofweg in twee categorieën indelen:operationele en rapportagesystemen. Operationele systemen worden vaak Online Transaction Processing (OLTP) genoemd. Rapportage- en analysesystemen worden Online Analytical Processing (OLAP) genoemd. OLTP-systemen ondersteunen bedrijfsprocessen. Ze werken met "live" operationele gegevens, zijn sterk genormaliseerd en reageren zeer snel op gebruikersacties. Aan de andere kant is het primaire doel van de OLAP-systemen analyse. Deze systemen gebruiken samengevatte gegevens, die meestal in een gedenormaliseerde datawarehousing-structuur worden geplaatst, zoals het sterschema. (Wat is denormalisatie? Simpel gezegd, het hebben van redundante gegevensrecords omwille van betere prestaties. Lees meer.)

Nu we een beetje over de systemen weten, gaan we beginnen met het onderzoeken van het datawarehouse en zijn onderdelen en processen.

Datawarehouses versus datamarts

Een datawarehouse (DWH) is een systeem dat wordt gebruikt om informatie op te slaan voor gebruik bij gegevensanalyse en rapportage. Datamarts zijn gebieden van een datawarehouse die worden gebruikt om informatie op te slaan die nodig is voor een enkele afdeling of zelfs voor een individuele gebruiker. (Denk aan het DWH als een gebouw, en datamarts als kantoren in het gebouw.)

Waarom zijn datamarts nodig? Alle relevante gegevens worden opgeslagen binnen het bedrijf DWH. De meeste gebruikers hebben echter alleen toegang tot bepaalde subsets van gegevens, zoals die met betrekking tot verkoop, productie, logistiek of marketing. Datamarts zijn belangrijk vanuit zowel een beveiligingsstandpunt (het beperken van onnodige toegang) als vanuit het oogpunt van de gebruiker (we willen ze niet verwarren of hen dwingen om door externe gegevens te waden).

Er zijn twee verschillende benaderingen van de relatie tussen datawarehouse en datamart:

Van boven naar beneden :Datamarts worden aangemaakt vanuit het datawarehouse. (Dit is iets waar Bill Inmon, de "vader van het datawarehouse", het mee eens zou zijn, samen met het idee dat magazijnen in 3NF zouden moeten zijn.)
Van onderaf :Eerst worden datamarts gemaakt en vervolgens gecombineerd tot een datawarehouse. (Deze benadering ligt dichter bij wat Ralph Kimball, een datawarehouse- en dimensionale modelleringsexpert, bepleit.)

Het ETL-proces wordt gebruikt om regelmatig "nieuwe" gegevens aan het OLAP-systeem toe te voegen. ETL is een afkorting voor Extract, Transform en Load. Zoals de naam al aangeeft, extraheren we gegevens uit een of meer operationele databases, transformeren deze zodat ze passen in onze magazijnstructuur en laden de gegevens in de DWH.

Dimensionale modellering , dat deel uitmaakt van het ontwerp van het datawarehouse, resulteert in de creatie van het dimensionale model. Er zijn twee soorten tabellen bij betrokken:

Afmetingstabellen worden gebruikt om de gegevens te beschrijven die we willen opslaan. Bijvoorbeeld:een winkelier wil misschien de datum, winkel en medewerker opslaan die bij een specifieke aankoop zijn betrokken. Elke dimensietabel is een eigen categorie (datum, medewerker, winkel) en kan een of meer attributen hebben . Voor elke winkel kunnen we de locatie opslaan op stad-, regio-, staats- en landniveau. Voor elke datum kunnen we het jaar, de maand, de dag van de maand, de dag van de week, enz. opslaan. Dit heeft te maken met de hiërarchie van attributen in de dimensietabel.

In het sterschema zullen we meestal zien dat sommige attributen een subset zijn van andere attributen in dezelfde record. Deze redundantie is opzettelijk en gedaan in naam van betere prestaties. We kunnen datum-, locatie- en verkoopagentdimensies gebruiken om te aggregeren (het transformatiegedeelte van het ETL-proces) en gegevens op te slaan in DWH. Bij dimensionale modellering is het erg belangrijk om de juiste afmetingen te definiëren en de juiste granulatie te kiezen.
Feitentabellen bevatten de gegevens die we in rapporten willen opnemen, geaggregeerd op basis van waarden in de gerelateerde dimensietabellen. Een feitentabel heeft alleen kolommen waarin waarden en externe sleutels zijn opgeslagen die verwijzen naar de dimensietabellen. Het combineren van alle externe sleutels vormt de primaire sleutel van de feitentabel. Een feitentabel kan bijvoorbeeld een aantal contacten bevatten en het aantal verkopen dat uit deze contacten voortvloeit.

Met deze informatie op zijn plaats, kunnen we nu graven in het sterrenschema-gegevensmodel.

Het sterrenschema

Het sterrenschema is het eenvoudigste model dat in DWH wordt gebruikt. Omdat de feitentabel in het midden van het schema staat met daaromheen dimensietabellen, ziet hij er ongeveer uit als een ster. Dit is vooral duidelijk wanneer de feitentabel wordt omgeven door vijf dimensietabellen. Een variant van het sterschema het duizendpootschema , waarbij de feitentabel wordt omgeven door een groot aantal tabellen met kleine afmetingen.

Sterrenschema's worden veel gebruikt in datamarts. We kunnen ze relateren aan de top-down datamodelbenadering. We zullen twee sterrenschema's (datamarts) analyseren en ze vervolgens combineren om één model te maken.

Voorbeeld sterschema:verkoop

Het verkooprapport is een van de meest voorkomende rapporten van vandaag. Zoals we eerder vermeldden, konden we in de meeste gevallen verkooprapporten genereren vanuit het live systeem. Maar als data of bedrijfsomvang dit te omslachtig maken, moeten we een datawarehouse of een datamart bouwen om het proces te stroomlijnen. Na het ontwerpen van ons sterschema, een ETL proces haalt de gegevens uit de operationele database(s), zet de gegevens om in het juiste formaat voor de DWH en laadt de gegevens in het magazijn.

Het hierboven gepresenteerde model bevat één feitentabel (lichtrood gekleurd) en vijf dimensietabellen (lichtblauw gekleurd). De tabellen in het model zijn:

fact_sales – Deze tabel bevat verwijzingen naar de maattabellen plus twee feiten (prijs en verkochte hoeveelheid). Merk op dat alle vijf buitenlandse sleutels samen de primaire sleutel van de tabel vormen.
dim_sales_type – Dit is een dimensietabel van het verkooptype met slechts één attribuut, “type_name ”.
dim_employee – Dit is een werknemersdimensietabel waarin de basiskenmerken van werknemers zijn opgeslagen:volledige naam en geboortejaar.
dim_product – Dit is een productdimensietabel met slechts twee attributen (anders dan de primaire sleutel):productnaam en producttype.
dim_time – Deze tabel behandelt de tijddimensie. Het bevat vijf attributen naast de primaire sleutel. De gegevens op het laagste niveau zijn verkopen op datum (action_date ). De action_week attribuut is het nummer van de week in dat jaar (d.w.z. de eerste week van januari krijgt het nummer 1, de laatste week van december krijgt het nummer 52, enz.) De actual_month en actual_year attributen slaan de kalendermaand en het jaar op waarin de verkoop plaatsvond. Deze kunnen worden geëxtraheerd uit de action_date attribuut. De action_weekday attribuut slaat de naam op van de dag waarop de verkoop plaatsvond.
dim_store – Dit is een winkeldimensie. Voor elke winkel slaan we de stad, regio, staat en land op waar deze zich bevindt. Hier kunnen we duidelijk zien dat het sterschema gedenormaliseerd is.

Voorbeeld sterschema:leveringsorders

Er zijn veel overeenkomsten tussen dit hieronder getoonde model en het verkoopmodel.

Dit model is bedoeld om de historie van geplaatste bestellingen op te slaan. We hebben één feitentabel en vier dimensietabellen. De dimensietabellen dim_employee , dim_product en dim_time zijn precies hetzelfde als in het verkoopmodel. De volgende tabellen zijn echter anders:

fact_supply_order – bevat geaggregeerde gegevens over de geplaatste bestellingen.
dim_supplier – is een dimensietabel die leveranciersgegevens op dezelfde manier opslaat als dim_store bewaargegevens bewaard in het verkoopmodel.

Voor- en nadelen van het sterrenschema

Er zijn tal van voordelen aan het gebruik van het sterrenschema. De feitentabel is gerelateerd aan elke dimensietabel door precies één relatie, en we hebben geen extra woordenboeken nodig om dimensietabellen te beschrijven. Dat vereenvoudigt query's en verkort de uitvoeringstijd van query's. We zouden hetzelfde rapport rechtstreeks vanuit ons OLTP-systeem kunnen produceren, maar de query zou veel complexer zijn en de algehele prestaties van het systeem kunnen aantasten. De volgende voorbeeldquery voor het verkoopmodel retourneert de hoeveelheid van alle typen telefoonproducten die in 2016 in Berlijnse winkels zijn verkocht:

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

Het grootste nadeel van het sterschema is redundantie. Elke dimensie wordt opgeslagen in een aparte dimensietabel en dit veroorzaakt denormalisatie. In ons voorbeeld hoort een stad bij een regio of staat, die bij een land hoort; die relatie slaan we niet standaard op in onze database, maar herhalen we voortdurend. Dit betekent dat we meer schijfruimte verbruiken en een risico op gegevensintegriteit hebben.

Het Melkwegschema

We kunnen de twee voorgaande modellen zien als twee datamarts, één voor de verkoopafdeling en de andere voor de bevoorradingsafdeling. Elk van hen bestaat uit slechts één feitentabel en enkele dimensionale tabellen. Als we wilden, zouden we deze twee datamarts kunnen combineren in één model. Dit type schema, dat meerdere feitentabellen bevat en enkele dimensietabellen deelt, wordt een galaxy-schema genoemd. . Het delen van dimensietabellen kan de databasegrootte verkleinen, vooral wanneer gedeelde dimensies veel mogelijke waarden hebben. Idealiter worden in beide datamarts de afmetingen op dezelfde manier gedefinieerd. Als dat niet het geval is, moeten we de afmetingen aanpassen aan beide behoeften.

Een sterrenstelselschema, opgebouwd uit onze twee voorbeelddatamarts, wordt hieronder weergegeven:

Het sterrenschema is een benadering voor het organiseren van een datawarehouse. Het is heel eenvoudig en wordt het meest gebruikt in datamarts. Als we ons geen zorgen hoeven te maken over schijfruimte en we goed zorgen voor de gegevensintegriteit, dan is het sterschema een haalbare eerste en beste keuze. Zo niet, dan moeten we een andere aanpak bedenken. Een daarvan is het sneeuwvlokschema, dat we in een volgend artikel zullen bespreken.