Stjärnschemat

Idag är rapporter och analyser nästan lika viktiga som kärnverksamheten. Rapporter kan byggas av dina livedata; ofta kommer detta tillvägagångssätt att göra susen för små och medelstora företag utan massor av data. Men när saker och ting blir större – eller mängden data börjar öka dramatiskt – är det dags att tänka på att separera dina operativa och rapporteringssystem.

Innan vi tar itu med grundläggande datamodellering behöver vi lite bakgrund om de inblandade systemen. Vi kan grovt dela in system i två kategorier:operativa system och rapporteringssystem. Operativa system kallas ofta Online Transaction Processing (OLTP). Rapporterings- och analyssystem kallas för Online Analytical Processing (OLAP). OLTP-system stödjer affärsprocesser. De arbetar med "live" driftsdata, är mycket normaliserade och reagerar mycket snabbt på användaråtgärder. Å andra sidan är det primära syftet med OLAP-systemen analys. Dessa system använder sammanfattade data, som vanligtvis placeras i en denormaliserad datalagerstruktur som stjärnschemat. (Vad är denormalisering? Enkelt uttryckt är det att ha redundanta dataposter för bättre prestanda. Läs mer.)

Nu när vi vet lite om systemen, låt oss börja undersöka datalagret och dess delar och processer.

Data Warehouses vs Data Marts

Ett datalager (DWH) är ett system som används för att lagra information för användning i dataanalys och rapportering. Datamarts är områden i ett datalager som används för att lagra information som behövs av en enskild avdelning eller till och med av en enskild användare. (Tänk på DWH som en byggnad och datamarts som kontor inne i byggnaden.)

Varför behövs datamarts? All relevant data lagras inom företaget DWH. De flesta användare behöver dock bara komma åt vissa delmängder av data, som de som rör försäljning, produktion, logistik eller marknadsföring. Datamars är viktiga både ur säkerhetssynpunkt (begränsar onödig åtkomst) och ur användarsynpunkt (vi vill inte förvirra dem eller tvinga dem att ta sig igenom ovidkommande data).

Det finns två olika tillvägagångssätt för relationen datalager-datamart:

• Uppifrån och ner :Datamars skapas från datalagret. (Detta är något som Bill Inmon, "datalagrets fader", skulle hålla med om, tillsammans med idén att lager skulle vara i 3NF.)
• Bottom-Up :Datamars skapas först och kombineras sedan till ett datalager. (Detta tillvägagångssätt ligger närmare vad Ralph Kimball, ett datalager och expert på dimensionsmodellering, förespråkar.)

ETL-processen används för att lägga till "nya" data till OLAP-systemet regelbundet. ETL är en förkortning för Extract, Transform och Load. Som namnet antyder kommer vi att extrahera data från en eller flera operativa databaser, omvandla dem för att passa vår lagerstruktur och ladda data till DWH.

Dimensionsmodellering , som är en del av data warehouse design, resulterar i skapandet av den dimensionella modellen. Det finns två typer av tabeller inblandade:

• Dimensionstabeller används för att beskriva den data vi vill lagra. Till exempel:en återförsäljare kanske vill lagra datum, butik och medarbetare som är involverade i ett specifikt köp. Varje dimensionstabell är sin egen kategori (datum, anställd, butik) och kan ha ett eller flera attribut . För varje butik kan vi spara dess plats på stads-, region-, delstats- och landsnivå. För varje datum kan vi lagra år, månad, dag i månaden, veckodag, etc. Detta är relaterat till hierarkin av attribut i dimensionstabellen.

  I stjärnschemat ser vi vanligtvis att vissa attribut är en delmängd av andra attribut i samma post. Denna redundans är avsiktlig och görs i namn av bättre prestanda. Vi skulle kunna använda dimensioner för datum, plats och försäljningsagent för att aggregera (transformeringsdelen av ETL-processen) och lagra data i DWH. I dimensionsmodellering är det mycket viktigt att definiera rätt dimensioner och välja rätt granulering.

• Faktatabeller innehålla de data vi vill inkludera i rapporter, sammanställda baserat på värden i de relaterade dimensionstabellerna. En faktatabell har bara kolumner som lagrar värden och främmande nycklar som refererar till dimensionstabellerna. Att kombinera alla främmande nycklar bildar den primära nyckeln i faktatabellen. En faktatabell kan till exempel lagra ett antal kontakter och antalet försäljningar som härrör från dessa kontakter.

Med denna information på plats kan vi nu gräva i stjärnschemadatamodellen.

Stjärnschemat

stjärnschemat är den enklaste modellen som används i DWH. Eftersom faktatabellen är i mitten av schemat med dimensionstabeller runt den ser den ungefär ut som en stjärna. Detta är särskilt tydligt när faktatabellen är omgiven av femdimensionella tabeller. En variant av stjärnschemat tusenfotingsschemat , där faktatabellen omges av ett stort antal små dimensionstabeller.

Stjärnscheman används mycket ofta i datamarts. Vi kan relatera dem till top-down datamodellmetoden. Vi kommer att analysera två stjärnscheman (datamars) och sedan kombinera dem för att skapa en enda modell.

Exempel på stjärnschema:Försäljning

Försäljningsrapporten är en av dagens vanligaste rapporter. Som vi nämnde tidigare kunde vi i de flesta fall generera försäljningsrapporter från livesystemet. Men när data eller företagsstorlek gör detta för besvärligt måste vi bygga ett datalager eller en datamarknad för att effektivisera processen. Efter att ha utformat vårt stjärnschema, en ETL processen hämtar data från operationella databaser, omvandlar data till rätt format för DWH och laddar data till lagret.

Modellen som presenteras ovan innehåller en faktatabell (färgad ljusröd) och fem dimensionstabeller (färgad ljusblå). Tabellerna i modellen är:

• fact_sales – Den här tabellen innehåller hänvisningar till dimensionstabellerna plus två fakta (pris och såld kvantitet). Observera att alla fem främmande nycklar tillsammans bildar den primära nyckeln i tabellen.
• dim_sales_type – Det här är en dimensionstabell av försäljningstyp med endast ett attribut, "type_name ”.
• dim_employee – Det här är en dimensionstabell för anställda som lagrar grundläggande anställdas attribut:fullständigt namn och födelseår.
• dim_product – Det här är en produktdimensionstabell med endast två attribut (förutom primärnyckeln):produktnamn och produkttyp.
• dim_time – Den här tabellen hanterar tidsdimensionen. Den innehåller fem attribut förutom primärnyckeln. Den lägsta nivån är försäljning efter datum (action_date ). action_week attribut är veckans nummer i det året (dvs. den första veckan i januari skulle ges siffran 1; den sista veckan i december skulle få siffran 52 osv.) actual_month och actual_year attribut lagrar kalendermånaden och året då försäljningen skedde. Dessa kan extraheras från action_date attribut. action_weekday attribut lagrar namnet på dagen då försäljningen ägde rum.
• dim_store – Det här är en butiksdimension. För varje butik sparar vi staden, regionen, staten och landet där den ligger. Här kan vi tydligt märka att stjärnschemat är denormaliserat.

Exempel på stjärnschema:leveransordrar

Det finns många likheter mellan denna modell, som visas nedan, och försäljningsmodellen.

Denna modell är avsedd att lagra historiken för gjorda beställningar. Vi har en faktatabell och fyra dimensionstabeller. Dimensionstabellerna dim_employee , dim_product och dim_time är exakt samma som i försäljningsmodellen. Följande tabeller är dock annorlunda:

• fact_supply_order – innehåller aggregerad information om de gjorda beställningarna.
• dim_supplier – är en dimensionstabell som lagrar leverantörsdata på samma sätt som dim_store lagrade butiksdata i försäljningsmodellen.

Fördelar och nackdelar med stjärnschemat

Det finns många fördelar med att använda stjärnschemat. Faktatabellen är relaterad till varje dimensionstabell med exakt en relation, och vi behöver inga ytterligare ordböcker för att beskriva dimensionstabeller. Det förenklar frågor och minskar exekveringstiden. Vi skulle kunna producera samma rapport direkt från vårt OLTP-system, men frågan skulle vara mycket mer komplex och det skulle kunna påverka systemets övergripande prestanda. Följande exempelfråga för försäljningsmodellen kommer att returnera kvantiteten av alla telefontyper som säljs i butiker i Berlin under 2016:

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

Den största nackdelen med stjärnschemat är redundans. Varje dimension lagras i en separat dimensionstabell, och detta orsakar denormalisering. I vårt exempel tillhör staden en region eller stat, som tillhör ett land; vi lagrar inte den relationen som regel i vår databas, men vi upprepar den kontinuerligt. Det betyder att vi kommer att spendera mer diskutrymme och har en risk för dataintegritet.

Galaxschemat

Vi kan se på de två tidigare modellerna som två datamarts, en för försäljningsavdelningen och den andra för leveransavdelningen. Var och en av dem består av endast en faktatabell och några dimensionella tabeller. Om vi ​​ville kunde vi kombinera dessa två datamarts till en modell. Den här typen av schema, som innehåller flera faktatabeller och delar vissa dimensionstabeller, kallas ett galaxschema . Att dela dimensionstabeller kan minska databasens storlek, särskilt där delade dimensioner har många möjliga värden. Idealt sett definieras dimensionerna i båda datamartserna på samma sätt. Om så inte är fallet måste vi justera måtten för att passa båda behoven.

Ett galaxschema, byggt av våra två exempeldatamarts, visas nedan:

Stjärnschemat är ett sätt att organisera ett datalager. Det är väldigt enkelt och används oftast i datamarts. Om vi ​​inte behöver oroa oss för diskutrymme och vi tar väl hand om dataintegriteten, är stjärnschemat ett gångbart första och bästa val. Om inte, bör vi tänka på ett annat tillvägagångssätt. Det ena är snöflingans schema, som vi kommer att diskutera i en kommande artikel.