Datové sklady a BI aplikace

Datové sklady a BI aplikace

MFF – část 2

Říjen 2004

Ing. David Pirkl

3. Přednáška

Téma

Dimenzionální modelování

Agenda BDLC

Plán projektu a projektový management Business požadavky Dimenzionální modelování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Projektový management

Projektový plán

Definice

uživatelských

požadavků

Technická architektura

Výběr produktůinstalace

Dimensionální modelování

Fyzická úroveň

ETL procesy Nasazení

Údržba a růst

Uživatelské aplikace

specifikace


vývoj

Projektový managementProjektový management

Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


Údržba a růst


specifikace


vývoj


Dimenzionální modelování je rozdílné od klasického ERD datového modelování

ERD Normalizace Odstranění redundantnosti Málo srozumitelné člověku Optimalizován na vkládáni dat a update

Dimensionální modelování Důraz na srozumitelnost pro uživatele Dosaženo standardní strukturou – fakta a dimenze Základní přístup – denormalizace, redundance Optimalizován na vyhledávání dat a složité analýzy Základy položeny v 60. tých letech (General Mills and Dartmount

University, Nielson Marketing Research)


Výhody dimenzionálního modelu Standardní – navazují na to OLAP aplikace, tvůrci

reportingových aplikací, … Dobře rozšiřitelný (bez dopadu na aplikace)

Přidání nových fakt se stejnou granualitou Přidání dimenze Přidání atributu dimenze

Standardní způsoby modelování reálných problémů SCD Sledování událostí (Factless fact table) Heterogenní produkty …


Základní přístup k modelování dat v datovém skladě Oproti klasickému relačnímu modelu dochází k

denormalizaci Proč dimenzionální modelování:

Přehledné, uživatelsky pochopitelné Důraz na obchodní logiku Denormalizace

Menší počet tabulek, spojení Rychlejší odezva Většina údajů v jedné tabulce Indexy


Základní myšlenka multidimenzionálního modelování

Prodej

Rok

Typproduktu

Region

Kategorieproduktu

Kvartál

Produkt

3 dimenze

Granualita

Základní typy tabulek

V datovém skladě se vyskytují dva hlavní typy tabulek: Faktové tabulky Dimenzionální tabulky


Nejužitečnější fakta – jsou často numerická a aditivní

Dimenze tvoří vstupní bod do DW Omezení v dotazech Hlavičky řádků v reportech

Dimensionální tabulky

Dimensionální tabulky zachycují úhel pohledu na sledované ukazatele

Představují vlastně „číselníky“ Typické dimenze jsou:

Čas Zákazník Produkt Prodejna Smlouva


Atributy v dimenzi: Textové hodnoty (nebo se

chovají jako textové) Diskrétní Slouží pro definici omezení

a agregace v výstupech

K výstupům lze využít všechny atributy dimenzí Jednoduché SQL (Select

…group by…order by) Month BrandDollarsSold

Unitssold

Jan Doodads 150 57

Jan Widgets 75 51

Feb Doodads 140 32

Feb Widgets 68 44

Grouping column Additive facts

Sales fact table

Time

Product

Store

Dollar_sold

Units_sold

Dollars_cost

Dimension

Time

Day

Month

Fiscal

Dimension

Store

Name

Location

Type

Dimension

Product

Description

Brand

Category

Flavor

Drag

Drag

Dimenzionální tabulky

Každá dimenzionální tabulka obsahuje jeden jednoznačný identifikátor a popisné atributy

Dimenzionální tabulka je denormalizovaná

D_CAS

ID_Cas (*)

Datum

Rok

Kvartal

Mesic

Den

Víkend

…

D_Zakazník

ID_Zakaznik (*)

Jmeno

Pohlavi

Rok narozeni

Země

Kraj

Okres

Obec

…

D_Produkt

ID_Produkt (*)

Nazev

Kategorie

Subkategorie

…


Atributy v dimenzi: Hierarchické (kategorie –

subkategorie – produkt) Nehierarchické

(barva_produktu)

Výstupy většinou kombinují oba typy atributů

Muže existovat i více hierarchií

Product dimension

Product key

Description

Marketing brand

Marketing subcategory

Marketing category

Financial brand

Financial subcategory

Financial category

Flavour

Package type

Hierarchie 1

Hierarchie 2

Atributy vžádnéhierarchii

Hierarchie v dimenzi

Dimenzionální tabulka v sobě nese různé hierarchie – vztahy 1:M mezi atributy dimenze

Hierarchie mají vždy stromovou strukturu Příklady hierarchie:

Rok -> Kvartál -> Měsíc -> Den Rok -> Týden -> Den Země -> Kraj -> Okres -> Obec Kategorie produktu -> Sub kategorie -> Produkt

Hierarchie – zápis

Způsob zápisu hierarchie v dimenzi:

DenDen

Kalendářní rokKalendářní rok

Kalendářní měsíc

Kalendářní měsíc

PrázdninyPrázdniny

Fiskální týdenFiskální týden

Fiskální rokFiskální rok

Kalendářní kvartál

Kalendářní kvartál

Den v týdnuDen v týdnu

VíkendVíkend

ProduktProdukt

Produkt skupinaProdukt skupina

Typ produktuTyp produktu

Produkt kategorie

Produkt kategorie


Dimensionální atributy jsou důležité (vstupní brána do DW)

Mají být Popisné Nepoužívat kódy Bez chybějících (null) hodnot – nahradit např.

Neuvedeno Zajištění kvality (bez překlepů, nemožných hodnot,

zastaralé, sirotci…) Standardizace (např. standardní zápis adresy)

Výběr dimenzí

Počet dimenzí by se měl pohybovat okolo 5 až 15 Méně dimenzí – něco chybí, zda nelze dodat:

Kauzální dimenzi (promoce, kontrakt, počasí, podmínky obchodu, …) Další časové dimenze (hlavně u faktových tabulek zachycující položky

celku (např. objednávka -> objednané produkty) Dimenzi ve více rolích (např. místo odkud se volalo, kam se volalo) Status dimenzi – označující současný status dimenze nebo snímku (např.

nový zákazník) Auditní dimenzi Degenerovanou dimenzi Junk dimenzi

Přidání dimenzí často nezmění granualitu původní faktové tabulky Lze přidat i do provozujícího datového skladu

Výběr dimenzí

Více jak 20 až 30 dimenzí ukazuje na možnost jejich spojení Nejsou nezávislé – spojit do jedné

Obchodně patří k sobě (např. značka, kategorie, oddělení) Korelace (viz –Junk dimenze)

Faktové tabulky

Faktové tabulky slouží k uchování informací o sledovaných ukazatelích

Mezi typické ukazatele lze zařadit: Počet prodaných kusů Hodnotu prodaného zboží (v Kč) Počet zákazníků Počet smluv Výše škody Délka hovoru

Z hlediska datového se většinou jedná o číselné údaje, které lze agregovat

Faktové tabulky

Granualita faktové tabulky: míra podrobnosti sledovaných ukazatelů, jejich přesný význam Např.: počet prodaných kusů za den daného zboží v

dané prodejně

Přiřazený dimenzí: Popisy, které nabývají jedné hodnoty pro jeden

záznam ve faktové tabulce (s danou granualitou) Při více hodnotách (M:N vztah) řešit přes pomocné

tabulky

Typy ukazatelů

Ukazatele máme tří typů: Aditivní – agregovatelné (sčítáním) přes všechny

dimenze (např. prodej v ks) Semiaditivní – agregovatelné (sčítáním) jen přes

některé dimenze (např. stav zásob v ks) Nutné agregovat jinými agregačními funkcemi např. průměr POZOR nelze vždy použít funkci AVG v SQL – problém

prázdných období (kdy nebyla transakce)

Neaditivní – neagregovatelné (např. některá textová fakta – počasí při nehodě)

Faktová tabulka

Z datového hlediska: Faktová tabulka obsahuje cizí klíče dimenzionálních

tabulek Tyto cizí klíče tvoří primární klíč faktové tabulky Navíc obsahuje faktová tabulka jednotlivé ukazatele

Kimball’s law: Každý vztah M:N je faktová tabulka, z definice

Ukazatele v faktové tabulce

Existují dva způsoby zápisu ukazatelů do faktové tabulky:

F_Prodej

ID_Cas

ID_Produkt

ID_Zakaznik

…

Prodej v ks

Prodej v kč

Náklady v Kč

…

F_Prodej

ID_Cas

ID_Produkt

ID_Zakaznik

…

ID_Ukazatele

Hodnota ukazatele

Ukazatel

ID_Ukazatele (*)

Nazev

Typy faktových tabulek Transakční

Zachycuje jednotlivé transakce, jednotlivé akce v daný časový okamžik Zachycuje jen transakce jež se udály (jestliže zákazník nic nekoupil

nebude v faktové tabulce) Obvyklý fakt: Množství (v dané transakci) Obvykle se po naplnění dále neprovádí update Ukazuje chování, vývoj v čase

Snímková Zachycuje stav k určitému časovému okamžiku (periodicky) Většinou měsíční Obvykle existuje jeden záznam pro všechny kombinace významných

dimenzí Sledovaná fakta – často složité výpočty, někdy vhodné přebírat z OLTP

systémů (již ověřená čísla) Umožňuje efektivně generovat výstupní reporty s často složitě

vypočitatelnými ukazateli Není efektivní je generovat přímo z transakcí

Typy faktových tabulek

Akumulovaná Zachycuje stav v daný okamžik Většinou obsahuje několik časových dimenzí (kdy byl

záznam naposledy updatován, datum jednotlivých sledovaných fází)

Řada obsahuje „null“ hodnoty, které jsou postupně vyplňovány Potřeba umělých klíčů v časové dimenzi na hodnotu „Dosud

neznámo“ Dochází k update v faktové tabulce při změně stavu

Pro sledovanou událost jeden záznam ve faktové tabulce, který je postupně updatován

Vhodná tam kde sledovaná událost má daný čas trvání

Typy faktových tabulek

Vhodné začít s snímkovou nebo akumulovanou fakt tabulkou

Postupně lze přidat i transakční Pro pokročilé analýzy chování


Čtyři kroky tvorby faktové tabulky Výběr datového tržiště

Jeden datový zdroj vs. Více Začít s řešením kde jeden datový zdroj

Určení granuality dat Měla by být co nejdetailnější Potřeba přesně vydefinovat, určuje co bude v fakt tabulce uloženo Určení typy faktové tabulky

Výběr dimenzí Vychází z určení granuality plus další dimenze vyhovující navržené

granualitě Granualita dimenze nemůže být nižší než granualita faktové tabulky

Určení faktů (ukazatelů) Vychází z granuality a typu faktové tabulky Ukazatele s rozdílnou granualitou vytvořené např. z důvodu urychlení

výpočtu je třeba uložit do zvláštní faktové tabulky (např. součty pro výpočet procent z detailních ukazatelů, …)

Různá granualita fakt

Fakta s různou granualitou musí být uloženy v různých faktových tabulkách

Často je potřeba alokovat fakta s vyšší granualitou na nižší pro možnost srovnaní Např. alokovat náklady objednávky na jednotlivé

produkty pro porovnání s výnosy Viz dále Parent-child modelování

Uspořádání tabulek

Existují dvě základní schémata uspořádání faktových a dimenzionálních tabulek: Hvězda Sněhová vločka

Hvězda

F_Prodej

ID_Cas

ID_Produkt

ID_Zakaznik

Prodej v ks

Prodej v kč

Náklady v Kč

D_CAS

ID_Cas (*)

Datum

Rok

Kvartal

Mesic

Den

Vikend

…

D_Zakazník

ID_Zakaznik (*)

Jmeno

Pohlavi

Rok narozeni

Země

Kraj

Okres

Obec

…

D_Produkt

ID_Produkt (*)

Nazev

Kategorie

Subkategorie

…

Vločka

F_Prodej

ID_Cas

ID_Produkt

ID_Zakaznik

Prodej v ks

Prodej v kč

Náklady v Kč

D_CAS

ID_Cas (*)

Datum

Rok

Kvartal

Mesic

Den

Vikend

…

D_Zakazník

ID_Zakaznik (*)

Jmeno

Pohlavi

Rok narozeni

Země

Kraj

Okres

Obec

…

D_Produkt

ID_Produkt (*)

Nazev

ID_Kategorie

…

Kategorie

ID_Produkt (*)

Nazev

ID_Subkategorie

…

Výhody/Nevýhody uspořádání

Hvězda Preferované uspořádání Přehlednější uspořádání z hlediska uživatele Snadněji udržovatelé Méně spojení než u vločky

Vločka Méně přehledné Náročnější na údržbu Nutné pro napojitelnost dalších faktových tabulek (BUS

architektura)


Doporučuje se používat star schéma Snowflake – není tak srozumitelné uživateli Na druhou stranu je někdy vhodné při napojení jiných

faktových tabulek s rozdílnou granualitou Použijeme-li fyzicky snowflake – je vhodné odstínit

uživatele pomocí views Snowflake ušetří trochu místa ale většinou

zanedbatelné (hlavní velikost je ve faktech) Existují výjimky – extra velké dimenze (např. zakaznici)

Kdy Snowflakes

Před uživatelem je možné Snowflakes skrýt za pomoci views Fyzický design – řízen rychlostí, efektivností Logický design – řízen uživatelskou přívětivostí, jednoduchostí

Např. dimenze zákazník Klasický zákazník (20%) Návštěvník www (80%)

Společné atributy: Shopper surrogate key Shopper ID (fixed ID for each physical shopper) Recency Frequency

Klasický zákazník Five name attributes 10 location attributes 10 behavior attributes 25 demographic attributes.

Kdy Snowflakes

Příklad:

Base shopper dimension

Surrogate_key

Shopper_id

Recency

Frequency

Intensity

Snowflake_key

Snowflake shopper subdimension

Snowflake_key

50 customer attributes

Kdy Snowflakes

Finanční produkty Mnoho produktů, některé atributy společné, jiné rozdílné Jedna dimenze – mnoho null hodnot v nevyplněných atributech

Snowflake key lze nahradit umělým klíčem společným přes všechny tabulky (viz unity dimension)

Uživatele lze odstínit pomocí views

Base financial product dimension

Surrogate_key

Core product atributtes

Snowflake_key

Separate subdimension for each product type

Snowflake_key

Product typ 1 atributtes


Snowflake_key



Snowflake_key


Kdy Snowflakes

Časová dimenze – různé kalendáře v různých organizacích

Pozor: Subdimenze má větší kardinality než dimenze Primární klíč subdimenze je snowflake_key a Organization Potřeba specifikovat organizaci při spojení tabulek (pak 1:1)

Base calendar dimension

Surrogate_key

Common calendar atributtes

Snowflake_key

Snowflake calendar subdimension with organization key

Snowflake_key

Organization

Organization calendar atributtes

Pojmy Drill-down, ….

Drill-down: ukaž mi větší detail Přidání sloupce z dimenze do výstupu

Drill-up: ukaž mi agregaci Odebrání sloupce z výstupu

Drill-across: spojení dvou a více faktových tabulek se stejnou granualitou

Drill-around: podobné jako drill-across, ale pro nelineární uspořádání

Slice-dice: řez multidimenzionální kostkou, omezení výběru Slice – výběr dimenze (zákazník, produkt, čas) Dice – výběr hodnoty v dimenzi (za rok = 2004 a produkt = chleba)


Příklad drill-across: obchodní řetězec Zásoba, objednávka, dodávka, prodej Samostatné fact tabulky spojené časovou a produktovou

dimenzí (dimenze jsou „conformed“ vůči faktovým tabulkám) Výsledný dotaz využívá outer-join

Time dimesion

Product dimesion

Customer dimesion

Finished goods inventory

Orders

Shipments

Customer sales

Customer inventory


Drill-around: příklad zdravotnictví, conformed dimenze pacient

Patient

Hospital

Laboratory

Medicard

Clinic

Long term care

Physician office

Employer

Insurence company

Pharmaceutical manufacturer

Pharmacy

4. Přednáška

Dimensionální modelování BUS architektura

Zajišťuje napojení jednotlivých etap (datových tržišť) navzájem a tak zajišťuje vytvoření celistvého DW

Datová tržiště by měla obsahovat co nejvíce podrobná atomická data Vytvořena za pomoci Conformed dimensions a standard fact

Conformed dimensions Dimenze, která znamená to samé ve všech faktových tabulkách na které může být

připojena Je stejná ve všech datových tržištích Klasickým příkladem: Zákazník, Produkt, Region, Čas Potřeba identifikovat tyto dimenze, udržovat je, publikovat a dodržovat Data pro conformed dimenzi často z více zdrojů Fyzicky jsou implementovány jednou tabulkou napojitelnou na všechny relevantní

faktové tabulky Dovoluje tedy operaci drill across Návrh většinou na co nejdetailnější úrovni Využívat umělé klíče

Větší flexibilita Nezávislost na OLTP SCD


Conformed standard fact Aby zaručilo bezchybné drill across Stejná fakta musí být stejně uložena ve všech datových tržištích

(např. příjem) Stejné měrné jednotky (ne jednou v jednotkách, jednou v

krabicích) Lze ztěží porovnat v reportech Uložit oboje

Označuje-li jiné věci, pojmenovat rozdílně Není-li třeba provázanosti, je někdy možné vytvářet

nezávislé datové tržiště (např. prodáváme-li rychlé občerstvení a traktory, nemusí mít cenu zákazníky sdružovat do jedné dimenze)


Praktické zkušenosti: Obvykle 4 – 15 dimenzí na faktovou tabulku

Fakt – je něco co není známo většinou předem, co pozorujeme, co vychází z chování trhu, …

Dimenze Často záleží na rozhodnutí designera Lze dimenze produkt a obchod

Prodávají-li se produkty ve všech obchodech (nezávislé) Nebo jednu dimenzi obchod-produkt

Prodávají-li se určité produkty v určitém obchodě (závislé) Taková dimenze je výhodnější – nese informaci o tom kde se co

prodává – lze tuto informaci získat přímo prohlížením (browsing) dimenze

Praktický příklad 3

Vytvořte multidimenzionální model 1. vrstvy datového skladu: Uživatelé chtějí sledovat:

Prodej zboží v korunách a kusech Prodeje v jednotlivých dnech Prodeje podle produktů, jejich kategorií a subkategorií Analyzovat využití dopravců – počet přepraveného zboží Analyzovat prodejce Analyzovat prodeje podle jednotlivých zákazníků a skupin

zákazníků (dle geografického umístění)

Praktický příklad 3


Modelovací řešení Slowly Changing Dimensions Rychle se měnící dimenze

(RCD) Surrogate Keys Pomocné tabulky (vztahy M:N)

Složité hierarchie v dimenzi Degenerovaná dimenze Junk dimension Heterogenní produkty Spojení fakt tabulek Transakční dimenze Audit dimenze Časová dimenze Mnohonásobné měrné jednotky

Různě měny Intervalový reporting Změny v dimenzi Velké dimenze Causal dimension Role Many Alternate Realities Unity dimension Faktová tabulka bez faktů Vztahy parent-child On-line DW Sledování zákazníka

Slowly Changing Dimensions

Problém uchování historie v datech OLTP systémy často neřeší

Přepsání hodnot Odmazání historických dat

Příklad: Změna názvu produktu, ID produktu se nemění

Tři možnosti řešení Přepsání Vytvoření nového záznamu Vytvoření atributu s aktuální hodnotou

SCD – Typ 1

Nejednoduší a nejrychlejší Neudržuje historii Stará hodnota pro nás není významná

Např. byla špatně zadaná

SCD – Typ 2

Nejpoužívanější technika

Time_key

Product_key

Shipto_key

Shipmade_key

Shipfrom_key

Invoice_num

Qty_shipped

Lineitem_value

Time dimension

Ship to dimension

Ship made dimension

Ship from dimension

Product dimension

Product_key

Description

Brand

Category

Flavor

Pkg_type

SKU

…

SCD – Typ 2

Pro každou změnu neklíčového atributu (jehož historii chceme sledovat) se vytvoří nový záznam

Pro záznamy v dimenzi jsou využity dva klíče IDU – Umělý identifikátor, mění se s změnou atributu, odkazuje do

faktové tabulky IDS – konstantní ID

Je vhodné doplnit do dimenze atributy Platnost od Platnost do

Výhody/Nevýhody Umožňuje přesně sledovat vývoj v historii Zvětšuje dimenzionální tabulku

SCD – Typ 3

Vhodné jestliže chceme sledovat vývoj jak podle staré tak nové hodnoty

Přidají se atributy Aktuální hodnota Předchozí hodnota

Sales team dimension

Salesteam_key

Team_name

Team_leader

Region

Sales team dimension

Salesteam_key

Team_name

Team_leader

Previous_region

Current_region

Rychle se měnící dimenze (RCD)

Velké dimenze, kterých probíhají časté změny Velký nárůst dat

Např. Dimenze Zákazník a několik atributů scorujících zákazníka (Dobrý, Brzy odejde, …) Mění se každý měsíc

Řešení: Jsou-li měnící se atributy textové a používají se pro

tvorbu reportů -> Vytvořit pro ně novou dimenzi přímo napojenou na fakt tabulku

Jsou-li numerické – převést je na fakta

Surrogate Keys Surrogate Keys – umělé klíče, používané v DW místo přirozených

primárních klíčů Je doporučováno – všechny přirozené klíče nahradit umělými

Všechny join do fakt tabulek přes umělé klíče Umělé klíče – integer datový typ

4 byte – 2 miliardy hodnot Důvody

Flexibilní, nezávislé na změnách v OLTP systémech Označení hodnoty „Nevím“ v dimenzi SCD Rychlejší join Většinou menší nároky na místo než u přirozených klíčů

I časová dimenze by měla mít umělý klíč Nespojovat přes DATE-TIME (datový typ) atribut

Surrogate Keys

Umělé klíče: přiřazené každé dimenzi Hodnoty 1, 2, 3, ….

Přiřazení hodnot umělého klíče: První načtení Následné načtení Využití look-up tabulek

Original complete set ofdimension records

Production_key

Description

Brand

Category

Package_type

Size

…

Original set of loadable dimension records

Surrogate_key

Production_key

Description

Brand

Category

Package_type

Size

…

Generate surrogatekeys startingwith key = 1

Data loader

Surrogate Keys

Look-up tabulka

Production_key Current_surrogate_key

SKU43WERT567 2345

SKU653TYH7889 4567

SKU34RTB567MM 5436

SKU34ERA23UJ4 2376

… …

Surrogate Keys

Nakonec je třeba aktualizovat look-up tabulky

Jestliže OLTP systémy podporují sledování změn (datum, odpovědnost) nemusí se provádět náročné porovnání položek záznamu.

Existingdimension

recordLookup table

Incomingdimesion

record

Test unknowproduction

key

Surrogate key

Fields change

CompareIncoming

Fields With currentfields

Get currentSurrogate key

Get newSurrogate key

OverwriteDimension

RecordIn DBMS

Load DBMS

Type 2

Type 1

No

Yes

Surrogate Keys

Po dimenzích následuje faktová tabulka

Sales fact tableProduction ID

Time_id

Product_id

Store_id

Dollar_sold

Units_sold

Dollars_cost

Plan_dollars_sold

Plan_units_sold

Plan_dollars_cost

Most recent key map

product_id

product_key

Most recent key map

store_id

store_key

Most recent key map

time_id

time_key

Sales fact tableSurrogate key

Time_key (FK)

Product_key (FK)

Store_key (FK)

Dollar_sold

Units_sold

Dollars_cost

Plan_dollars_sold

Plan_units_sold

Plan_dollars_cost

Replace ID umělým klíčem



Load fact tabledo RDBMS

Pomocné tabulky

Pro řešení vztahu M:N mezi dimenzí a faktovou tabulkou Jednomu záznam ve faktové tabulce neodpovídá jeden

záznam v dimenzi Např.: dimenze diagnóza u sledování pacientů Řešení:

Vypustit dimenzi Vybrat jednu hlavní hodnotu a ostatní vypustit Vytvořit pevný počet dimenzí – diagnózy (každá dimenze pro

jednu diagnózu) Zvětšit granualitu faktové tabulky Využít pomocnou tabulku (Helper table)

Pomocné tabulky Pomocná tabulka Weight_Faktor zaručuje správné výsledky ve výstupech

Fakta jsou násobena Weight_Faktor Součet Weight_Faktor pro jednu skupinu se rovna 1 Zde nastavit proporcionálně pro celou skupinu

Impact report Není využit Weight_Faktor k násobení Nelze potom agregovat

Patient billing fact table

Calendar_date_key

Patient_key

Doctor_key

Location_key

Service_key

Diagnosis_group

Payer_key

Amount

Diagnosis grouphelper table

Diagnosis_group

Diagnosis_key

Weight_factor

Diagnosis dimension table

Diagnosis_key

Description

Type

Category

Pomocné tabulky

Pro uživatele je možné připravit schéma Hvězdy Využit views Spojit pomocnou tabulku na faktovou tabulku Vynásobit fakta Weight_Faktor Výsledek je přímo napojený na dimenzi Diagnóza

Pomocné tabulky se využijí i v např: Bankovnictví – více vlastníků účtu

Pomocné tabulky

Příklad:

Monthly account fact

Account_key (FK)

Month_key (FK)

Balance

Interest_paid

Tees

Activity_count

Account dimension

Account_type (PK)

Type

Category

Primary holder

Overdraft policy

Behavioral profile

Account to customer map (helper table)

Account_key (FK)

Customer_key (FK)

Begin_date (FK)

End_date (FK)

Weight_factor

Customer dimension

Customer_key (PK)

Name

Address

Demographics …

Pomocné tabulky

Pomocná tabulka obsahuje umělé klíče do tabulek Klient a Účet Při každé SCD2 změně v některé z těchto tabulek je

nutné přidat záznam do pomocné tabulky BeginDate a EndDate v pomocné tabulce ukazují

interval v němž byl klient majitelem účtu a obě dimenze se neměnily

Architektura umožňuje komplexní analýzu S jednoduchými SQL dotazy

Dopad na složitost ETL: doplnit EndDate do předchozího záznamu

Pomocné tabulky

Klient účtu ABC123: SELECT customer.name

FROM account, map, customer

WHERE account.accountkey = map.Accountkey

AND customer.customerkey = map.Customerkey

AND account.naturalid = 'ABC123'

AND '7/18/2001' BETWEEN map.begindate AND map.enddate

Pomocné tabulky Weight_Faktor:

K alokaci aditivních faktů na jednotlivé položky dimenzionální tabulky Pro daný účet součet roven 1

Balance na účtu ABC123 SELECT customer.name, fact.balance*weightingfactor

FROM fact, account, map, customer, monthWHERE fact.accountkey = account.Accountkey

AND fact.monthkey = month.MonthkeyAND account.accountkey = map.AccountkeyAND customer.customerkey = map.CustomerkeyAND account.naturalid = 'ABC123'AND month.monthdate = 'July, 2001'

Bez faktoru – impact report – pro každého majitele účtu stejná hodnota balance Není možné agregovat na zjištění balance účtu Ukazuje s kolika skutečně penězi může klient disponovat

Pomocné tabulky

Pomocná tabulka musí být aktualizovaná: Při změně v dimenzi Účet, Klient Při přidání klienta k účtu, při odebrání klienta z účtu Při úpravě Weight_Faktor (součet 1)

Pro zjednodušení je vhodné znovu zapsat všechny klienty pro daný účet do pomocné tabulky (stejný BeginDate)

Složité hierarchie v dimenzi

Využití pomocné tabulky pro sledování složitých hierarchií v dimenzi Standardní SQL

Uvažujme příklad: Konzultantská firma prodává svým zákazníkům Prodeje mohou být provedeny jedné firmě ale na

různých úrovních Uživatelé chtějí sledovat jak prodeje celé firmě tak i

jednotlivým oddělením


Klasický rekurzivní atribut (join tabulky zákazníků samu na sebe) neřeší problém: Není možné využít jednoduché SQL pro dotazy

Revenue fact table

Date_of_service_key

Customer_key

Consulting_service_key

Consulting_manager_key

Project_status_key

Invoice_number

Billed_revenue

Billed_hours

Customer dimension table

Customer_key

Customer_name

Customer_address

Customer_type

Customer_industry

Parent_keyThe two additive facts

Tempting to add this recursive pointer


Hierarchie The supremeParent organization

An intermediateParent organization

A lowest-levelOrganization or subsidary


Řešení přes pomocnou tabulku Nijak neovlivní dosavadní model Obsahuje záznam pro každou cestu z uzlu na

sebe sama a na uzly pod sebou Atributy:

Parent Customer Key Subsidiary Customer Key Depth From Parent Lowest Flag Topmost Flag


Umožňuje jednoduchým SQL získat pro daný uzel informace o všech potomcích

Obrácením spojení se můžete dívat na nadřízené, např: Depth = 1 nadřízený Topmost = True - nejvyšší

Revenue fact table

Date_of_service_key

Customer_key

Consulting_service_key

Consulting_manager_key

Project_status_key

Invoice_number

Billed_revenue

Billed_hours

Customer dimension table

Customer_key

Customer_name

Customer_address

Customer_type

Customer_industry

Parent_customer_key

Subsidary_customer_key

Depth_from_parent

Lowest_flag

Topmost_flag


Řešení je možné rozšířit o přidání atributů do pomocné tabulky: Začátek_Platnosti Konec_Platnosti

Umožňuje sledovat změny v hierarchii Je-li více rodičů v hierarchii je možné řešit

přidáním Weight_Faktor do pomocné tabulky Součet pro uzel musí být roven 1

Degenerovaná dimenze

Degenerovaná dimenze: Většinou se objeví v případě popisu reality objekt –

položky objektu (např. objednávka – položky objednávky)

Faktová tabulka na úrovni položek objednávky Kam s číslem objednávky? Jedná se o degenerovanou dimenzi – je

zapsaná ve faktové tabulce a nemá přímou napojitelnost na žádnou dimenzionální tabulku

Vhodná je pro tvorbu reportů, napojení na provozní systémy, …

Junk dimension

Při analýze zdrojových dat zůstanou atributy, které nelze přiřadit k některé dimenzi Např. 10 atributů označujících kód transakce, ….

Co s nimi? Vytvořit deset dalších dimenzí – může být nepřehledné pro

uživatele Spojit všechny atributy do jedné junk dimense

Junk dimenze – vhodné uskupení náhodných indikátorů a různých atributů

Pozor aby Junk dimense neobsahovala příliš mnoho záznamů

Junk dimension

Má-li např. každý atribut 100 různých hodnot a jsou plně nezávislé pak může mít dimenze až 10010 záznamů

Řešení: Rozdělit atributy do skupin korelovaných atributů Např. má-li A1 100 různých hodnot a A2 1000 různých hodnot, kolik

různých hodnot nabývá kombinace atributů A1 a A2

1000 – A1 je rodičem A2

100 000 – A1 nezávislé na A2 – rozdělit do dvou dimenzí

10 000 – lze A1 do dimenze s A2

Nabývají-li např. jen 3 různých hodnot lze vytvořit dimenzi se všemi deseti atributy (maximálně 310 záznamů)

Heterogenní produkty

Heterogenní produkty Řešení v businessu kde řada produktů s různými

charakteristikami Potřeba sledovat celkový obraz i jednotlivé produkty

Řešení Základní faktová tabulka – pro všechny produkty Faktové tabulky pro jednotlivé produkty


Time_keyAccount_keyBranch_keyHousehold_keyBalanceFees PaidFees EarnedNum_transaction

Základní dimenze Account

Household dimenze

Časová dimenze

Branch dimenze


Time_keyAccount_keyBranch_keyHousehold_keyBalanceFees PaidFees EarnedNum_transactionKlíč k faktům

Základní dimenze AccountKlíč do rozšířené tabulky

Household dimenze

Časová dimenze

Branch dimenze

Klíč rozšířené tabulkyAtributy daného

produktu

KlíčDalší ukazatelé pro daný produkt

5. Přednáška

Spojení fakt tabulek

Pozor při tvorbě dotazů spojujících jednu dimenzi s více než jednou faktovou tabulkou Není možné použít jednoduchý join

Audit dimenze

Pro sledování auditních informací o plnění faktových tabulek Lze rozšířit na vybrané dimenze i celý datový sklad

V případě že dochází k update faktové tabulky je třeba (vztah M:N mezi faktovou tabulkou a auditní dimenzí) je třeba přidat mezi faktovou tabulku a auditní dimenzi pomocnou tabulku (vazební)

Audit dimenze

SW run log fact table

Audit_key (PK)

Module_key (PK)

Execution_date_time (PK)

Module_name

Module_revision

Records_processed

Run_status

Audit dimension

Audit_key (PK)

Load_completion_date_time

Load_status

Load_records_rejected

Clean_completition_date_time

Clean_status

Records_corrected

Extract_completition_date_time

Extract_status

Total_records_extracted

Example shipments fact table

Time_key (FK)

Product_key (FK)

Ship_to_key (FK)

Ship_from_key (FK)

Ship_mode_key (FK)

Contract_key (FK)

Audit_key (FK)

Invoice_num (degenerate)

Quantity_shipped

Extended_amount

Při potřebě zachytit podrobnější informace

Časová dimenze

Vyskytuje se téměř u všech faktových tabulek

Lze uvažovat dva přístupy Pouze hodnota v faktové

tabulce (date-time) Vlastní plnohodnotná dimenze

Druhá možnost podporuje analýzu SQL funkce nejsou tak

komplexní aby zachytily veškerou časovou logiku (např. finanční rok, kalendářní rok, sezónnost, …)

Time_key

Day_of_week

Day_number_in_month

Day_number_overall

Month

Month_number_overall

Quarter

Fiscal_period

Season

Holiday_flag

Weekday_flag

Last_day_in_month

…

Časová dimenze

Data jsou plněna „ručně“ Např. makro v Excelu Naplnit několik let (10 – 20)

Většinou granualita denní, v některých případech až na sekundy Vhodné rozdělit, sekundy jako numerická fakta (date-

time atribut ve fakt tabulce) + klasická denní časová dimenze

Časová dimenze Základní dimenze v každém datovém skladě

Předpokládejme nejprve denní Na první pohled jednoduchá, predikovatelná

Kalendářní dny, 365 dní za rok Vyrůstající otázka okolo časových intervalů Příkladem transakce na účtu (otevření účtu, transakce –výběr,

uložení, uzavření účtu) Otázky bez problémů:

Ukaž všechny transakce za daný časový úsek Urči zda daná transakce nastala v daném časovém úseku Umožni pokročilou časovou analýzu při využití informací o svátcích,

prázdninách, víkendech, … Předchozí otázky vyžadují klasickou časovou dimenzi Vhodné doplnit atributy:

Poslední den v časovém intervalu (např. poslední den v čtvrtletí) Hodnoty Ano/Ne

Čas dne

Je-li třeba zachytit přesný čas je vhodné ho oddělit od denní časové dimenze Přesný čas je uvažován spíše jako fakt I když může existovat jeho interpretace (čas oběda,

čas uzávěrky, …)

Potřebujeme-li sledovat více časových zón lze přidat více časových dimenzí

Čas dne

Sales fact table

Date_key (FK)

GMT_data_key (FK)

Product_key (FK)

Customer_key (FK)

Call_center_key (FK)

Service_rep_key (FK)

Promotion_key (FK)

Time_of_day

GMT_time_of_day

Dollars_sold

Unit_sold

Dollar_cost

Časová dimenze Složitější situace:

Ukaž všechny, kteří jsou zákazníky v daném časovém intervalu. Ukaž poslední transakci zákazníka v daném časovém intervalu Ukaž stav účtu zákazníka v libovolném časovém okamžiku

K odpovědi vystačíme s jednou časovou dimenzí Dotazy jsou ovšem komplexní a složité Neefektivní dotazy Koncové programy je těžko automaticky definují

Řešení: Dvě časové dimenze Počátek a konec intervalu

Odpovědi na otázky: Nalézt všechny účty s cas_zacatek transakce otevření účtu před koncem intervalu

a cas_konec transakce zavření účtu po začátku daného intervalu Najdi transakci s cas_zacatek v nebo před koncem intervalu a cas_konec v nebo

po konci intervalu Najdi transakci s cas_zacatku v nebo před daným okamžikem a cas_konce v nebo

po daném okamžiku Vystačíme s BETWEEN klauzulí

Časová dimenze

Dopady dvou dimenzí: Musíte navštívit každý záznam v faktové tabulce dvakrát

Při prvním insertu (cas_konce nastaven na neurčito, ne null) Při následujícím insertu na účtu k správnému nastavení

předcházejícího cas_zacatku Problém s větší granualitou

Lze využít dvě dimenze Nelze využít klasickou předpřipravenou časovou dimenzi – mnoho

záznamů (31 milionu sekund za rok) Řešení:

Čtyři dimenze, dvě s denní granualitou, dvě s sekundovou (pouze date/time ve faktové tabulce)

Dynamická časová dimenze (pro daný záznam ve faktové se vygeneruje záznam v časové dimenzi)

Různě měny

Pro sledování různých měn Lze uložit fakta v různých měnách Nebo využít speciální faktovou tabulku pro konverzi

Multinational sales fact table

Date_key (FK)

Product_key (FK)

Store_key (FK)

Reporting_country_key (FK)

Customer_key (FK)

Promotion_key (FK)

Quantity_sold

Local_currency_tendered

US_dollar_equivavelnt_tendered

Daily currency conversion fact table

Date_key (FK)

Buying_country_key (FK)

Selling_counry_key (FK)

Conversion_rate

Intervalový reporting

Je-li potřeba vytvořit report stylu:

Není jednoduché v SQL Možno využít CASE, …není transparentní

Lze využít speciální design Join přes spodní a horní meze intervalu Do reportu název intervalu Využívá indexy na faktech

Balancerange

Number of Accounts

Total of Balances

0 - 1000 456 123

1001 - 2000 678 234

2001 - 3000 345 125

3001 and up 123 23

Intervalový reporting

Monthly account balance fact table

Month_key (FK)

Account_key (FK)

Branch_key (FK)

Product_key (FK)

Household_key (FK)

Ending_balance

Average_daily_balance

Number_transaction

Fees_paid

Fees_earned

Band definition table

Band_group_name (PK)

Band_name

Band_sort_number (PK)

Band_lower_value

Band_upper_value

>=

<

Změny v dimenzi

V reálném DW nevystačíme pouze s faktovými a dimenzionálními tabulkami

Potřeba zachytit změnu v prostředí Řešení SCD (typ 2) Co když ale chceme prohlížet dimenzi odděleně

od faktové tabulky? Kdy se zákazník oženil? Kdy poprvé si potom zakoupil zboží? Které další atributy se u zákazníka změnily? Které atributy se obvykle mění společně?

Změny v dimenzi

Řešení:

Customer

Customer_key

Trans effective date

Trans end date

Last trans flag

Customer SCD group key

First name

Last name

Marital status

Address

City

State

….

Customer SCD group


Customer SCD column key

Customer SCD column


SCD column name

Column business name

Změny v dimenzi

Customer SCD column mohou zároveň sloužit jako metadata pro vývojáře ETL – co sledovat za změny (typ 2)

Customerkey

Trans effective date

Trans end date

Last trans flag


First name

Last name

Marital status City State

1 1.4.2004 15.6.2004 N 0 Mary Smith Single New York NY

2 15.6.2004 12.7.2004 N 501 Mary Jones Married New York NY

3 12.7.2004 31.12.9999 Y 502 Mary Jones Married Westport CT



0 0

501 1

501 2

502 3

502 4

CustomerSCDcolumn key

SCD column name

Column business name

0 New record New record

1 Last_name Last name

2 Marital_status Marital status

3 City City

4 State State

Customer Dimension

Customer SCD group Customer SCD column

Změny v dimenzi

0 pomáhá identifikovat kdy zákazník byl vložen do systému

V obrázku je využita technika dvou časových dimenzí cas_zacatku, cas_konce efektu transakce

Last_Trans_Flag – pro nalezení poslední transakce – aktuálního profilu zákazníka

Technika je využitelná nejen pro dimenzi zákazník (produkt, dodavatel, zaměstnanec)

Velké dimenze

Některé dimenze mohou být opravdu velké Zákazníci Produkty (500 000)

Nutné využít bitmapové indexy Rozdělit velké dimenze

Stabilní část Proměnlivá – SCD (rozdělit na intervaly, naplnit všemi možnostmi) Obě dimenze napojené na fakt tabulku Nebo neimplementovat SCD

Problémy: Ztráta informace při převodu na intervaly Proměnlivá dimenze nesmí být moc velká – řešení vytvořit jich několik Zpomalení prohlížení dimenze, nutné přes faktovou tabulku Změna pouze při zápisu do faktové tabulky – řešení vytvořit umělý typ

transakce změna atributu, kdy se změní atributy v proměnlivé dimenzi

Causal dimension

Zachycuje důvody proč došlo k zápisu do faktové tabulky Příklad: Prodej v obchodním řetězci

Proč zákazník nakoupil Důvody: Platí sleva, promo akce, ochutnávka, …

Obdobně telekomunikace: sleva na volaní, akce na víkend, nej číslo, …

Vhodné nalézt tyto informace a dodat do modelu Podpora marketingových analýz

Nemá vliv na původní faktovou tabulku Nemění její granualitu

Causal dimension

Důležité je nezapomenout na hodnotu: Žádná promoce

Transaction fact table

(Existing keys)

Causal key

(Existing facts)

New causal dimension table

Causal key

Condition name

Price treatment type

Price discount

Ad type

Ad media name

Ad size

Display type

Display provider

Display size

Role

Výskyt dimenzionální tabulky ve více rolích Např.: Akumulovaná fakt tabulka objednávek

Dimenze: Datum objednávky, Datum balení, Datum dodávky, Datum platby, …, Zákazník, Produkt

Není možné napojit vše na jednu časovou dimenzi Fyzicky je možné udržovat pouze jednu dimenzi Využít view, kopie, materializované view – každá dimenze své

jméno (i atributy) Podobně je možné řešit např. výskyt Regionu v různých

dimenzích (Zakaznik, Dodavatel, …) Pouze jedna dimenze Region Napojení přes Sněhovou vločku na dimenze ostatní

Many Alternate Realities Pro sledování SCD – jestliže je třeba sledovat vedle sebe současné i

historické atributy dimenze Něco mezi SDC 2 a SCD 3

Příklad 1: Prodejci rozděleni do jednotlivých prodejních regionů Příklad 1a – Distribuční sít se mění ročně - uživatelé chtějí sledovat:

Prodeje v daném roce podle distribuční mapy daného roku Prodeje v daném roce podle distribuční mapy jiného roku Prodeje za několik let podle distribuční mapy z vybraného roku

Příklad 1b – Distribuční sít se mění kdykoliv - uživatelé chtějí sledovat: Prodeje v minulosti dle platné distribuční mapy Prodeje podle aktuální distribuční mapy Prodeje podle vybrané alternativní distribuční mapy

Řešení je možné využít např. pro sledování Regionální dimenze Změny zařazení obcí, okresů, …

Many Alternate Realities Příklad 1a Atributy:

Sales Team Key Sales Team Name Sales Team Physical Address (stays constant) District1999 (the district assignment for the team in 1999) District1998 (the district assignment for the team in 1998) District1997 District1996 District1995 District1994 District1993 District1992 Distric t1991 District1990 … plus other unrelated sales team attributes

Many Alternate Realities

Příklad 2b Atributy

Sales Team Key Sales Team Name Sales Physical Address (remains unchanged) District (the district assignment valid between the following dates) Begin Effective Date (the first date this record is valid) End Effective Date (the last date this record is valid) Obsolete District1 (a selected obsolete definition) Obsolete District2 (a different obsolete definition) Current District (the most current district assignment; periodically

overwritten) … plus other unrelated sales team attributes

Unity dimension

V případě, že dimenze může vystupovat v několika různých rolích

Např.: sledování toku zboží mezi zákazníkem, výrobcem, dodavatelem, skladem

Obsahuje Všechny tabulky sdílí jednu sekvenci umělých

klíčů Faktová tabulka obsahuje umělý klíč do unit dimenze a

dané komponentní dimenze Podobné řešení např. pro různé typy účtů

Unity dimension

Příklad: Shipping_points

Shipping_points_uid

Type_code

Name

Address

…

Shipment_facts

Sp_original_uid (FK)

Sp_destination_uid (FK)

Customers

Customer_uid (FK)

Customer_id

Customer_type

Name

Address

…

Vendors

Vendors_uid (FK)

Vendor_id

Name

Address

Temrs

…

Storage_location

Location_uid (FK)

Location_id

Name

Address

…

Plants

Plant_uid (FK)

Plant_id

Name

Address

…

Faktová tabulka bez faktů

Faktová tabulka bez ukazatelů Faktová tabulka zaznamenávající události (Events)

Např. Studentova přítomnost na výuce

Data dimension Course dimension

Facility dimension

Student dimensionTeacher dimension

Fact table

Date_key

Student_key

Course_key

Teacher_key

Facility_key


Umožňuje odpovídat na dotazy typu: Která výuka je nejvíce navštěvovaná? Který učitel učí nejvíce studentů? Který učitel učí na jiné katedře než z které pochází? Která učebna je nejvíce využívaná?

Někdy se přidává atribut „Zučasnil_se“ vždy vyplněný 1 Čitelnější SQL, vhodné pro OLAP Např.:

SELECT COURSE, SUM(ATTENDANCE) FROM FACT_TABLE COURSE_DIMENSION, ETC. WHERE ... GROUP BY COURSE

Podobně lze např. využít pro pojistné události Dimenze: Date of Collision Insured Party Insured Auto Claimant

Claimant Auto Bystander Witness Claim Type


Dalším typem jsou Factless Coverage Table

Např. Faktová tabulka bez faktů společně s faktovou tabulkou prodejů odpovídá na otázku: „Které výrobky byly v promoci ale neprodaly se?“

Sales fact table

Time_key (FK)

Product_key (FK)

Store_key (FK)

Promotion_key (FK)

Dollar_sold

Units_sold

Dollars_cost

Data dimension

Product dimension

Store dimension

Promotion dimension

Store dimension

Promotion dimensionProduct

dimension

Data dimensionSales fact table

Time_key (FK)

Product_key (FK)

Store_key (FK)

Promotion_key (FK)


Coverage table se vyskytuje tam kde je klasická faktová tabulka řídká

Klasická faktová tabulka nedokáže odpovědět na otázku „Co se nestalo?“

Dva kroky dotazu: Zjistit které zboží bylo v promoci Zjistit které zboží se prodalo Rozdíl je výsledek

Co se nestalo?

Analýza situací, které se nestaly Obecně faktové tabulky zachycují co se stalo

Lze využít Coverage factless table Lze zapsat i do původní faktové tabulky jako speciální

událost, která nenastala Např. studenti, kteří nenavštívili výuku

Factless fakt tabulka (Zučastnil_se = 0) Vhodné řešení, jestliže nedojde k výraznému růstu faktové tabulky Vhodné jestliže nenastání události má stejnou dimenzionalitu jako

nastání

Vztahy parent-child Mnoho vztahu v obchodním světě je parent-child

Objednávka – objednané zboží Pojistná smluva – pojištěná rizika Dodejka – dodané zboží

Příklad: Faktura Faktura

Four regular dimensions: date of overall invoice, sales agent, customer, and payment terms

One degenerate dimension: invoice number (more on this later) Five additive facts: total net price from the line items, total invoice-level

discounts representing promotional allowances, total freight charges, total tax, and grand total

Položky faktury Two dimensions: product and promotion Four additive facts: number of units of product, extended gross price (units 3

price), extended net price [units 3 (unit price - promotional discount)], and unit price of product and promotional discount for this specific product (more on this later)

The "context" from the overall invoice (the five parent dimensions)

Vztahy parent-child Jednoduchá úvaha vede na dvě faktové tabulky

Problém: nelze sledovat ukazatele na produkt (např. co s celkovou cenou vč. nákladů)

Modelovat jednou faktovou tabulkou na nejnižší úrovni (položky faktury) Atributy celé faktury rozpočítat na nižší úroveň

Dimenze Date of overall invoice (dimension) Sales agent (dimension) Customer (dimension) Payment terms (dimension) Product (dimension) Promotion (dimension).

Číslo faktury v faktové tabulce jako degenerovaná dimenze (nemá odpovídající dimenzionální tabulku)

Vztahy parent-child

Ukazatele: Number of units of product (additive fact) Gross extended product price (additive fact) Net extended product price (additive fact) Allocated invoice-level promotional discounts (additive fact) Allocated freight charges (additive fact) Allocated tax (additive fact)

Cenu zboží lze vypočítat z množství a celkové ceny Na základě degenerované dimenze číslo faktury lze

vytvořit součty za celou fakturu Plně nahradí faktovou tabulku pro celou faktury Žádná informace tak není alokací ztracena

Vztahy parent-child

Jak alokovat? Např. náklady dodávky. Dle: Množství Hmotnosti Hodnoty Objem

Je to politická otázka Některá oddělení odpovědná za určitý druh zboží mohou potom

vypadat více profitabilní (nesou menší náklady)

Vhodné provést alokaci podle více atributů (více ukazatelů ve faktové tabulce)

On-line DW

Velice složité z hlediska náročnosti ETL Vhodné rozdělit na

Statické tabulky – plněné v pravidelných intervalech Dynamické – plněné on-line a navazatelné na statické

Potřeba omezit indexy, agregace

Sledování zákazníka

Vhodné sledovat zákazníka podle tří hledisek (RFI) Recency – doba od posledního nákupu, interakce Frekvenci – jak často zákazník nakoupil, přišel do obchodu Intensity – jak produktivní to bylo, počet prodaného zboží

Sledují se za dané časové období, např. měsíc Lze definovat segmenty (data mining)

A: High-volume, repeat customer, good credit, few product returns B: High-volume, repeat customer, good credit, but many product returns C: Recent new customer, no established credit pattern D: Occasional customer, good credit E: Occasional customer, poor credit F: Former good customer, hasn't been seen recently G: Frequent window shopper, mostly unproductive H: Other


Jednotlivé segmenty jsou textová fakta o zákazníkovy

Lze sledovat časové řady vývoj zákazníka John Doe: C C C D D A A A B B Podařilo se zákazníka převést z nového zákazníka,

přes příležitostného k velmi profitabilnímu zákazníkovi. Ale poslední dobou začal vracet produkty. Hrozí, že je s produkty nespokojen a bude chtít přejít ke konkurenci.


Jak modelovat: 1. Záznam ve faktové tabulce pro každého zákazníka za každý

měsíc s textovým ukazatelem segmentu Problematické porovnávat vývoj zákazníka

2. SCD typ 2 – Segment – atribut podléhající SCD 2. Nový záznam o zákazníkovi je generován každý měsíc.

Problematické porovnávat vývoj zákazníka 3. Jednoduchá dimenze zákazníka s 24 atributy (časová řada 24

údajů o segmentu do historie) – SCD typ 3 Vhodné řešení, problém co po 24 měsících (předpokládáme, že se

zákazník scoruje každý měsíc) Lze kombinovat s SCD 2 pro sledování změny ostatních atributů – je

třeba doplnit nové score do všech záznamů zákazníka

6. Přednáška

Agenda BDLC

Plán projektu a projektový management Business požadavky Dimenzionální modelování – metodika

pokračování Architektura Fyzický design ETL Uživatelské aplikace Nasazení Správa a růst DW

Projektový management

Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


Údržba a růst


specifikace


vývoj

Projektový managementProjektový management

Projektový plán

Definice

uživatelských

požadavků




Fyzická úroveň


Údržba a růst


specifikace


vývoj

Budování dimensionálního modelu

Začít s maticí datová tržiště proti použité dimenze Datová tržiště zde volně chápáno jako skupina ukazatelů (faktu),

které má smysl sdružit dohromady (např. ukazatele obratu a aktivity na účtu)

Většinou datové tržiště z jednoho obchodního procesu (je jednodušší) s jedním datovým zdrojem

Lze potom kombinovat tržiště dohromady na složitější Datový tržiště (DM) se mohou překrývat (společná fakta)

Pro větší organizaci 10 až 30 DM Idea: Rozděl a panuj Ne vše do jednoho velkého tržiště Větší počet už se většinou hodně překrývá


Potřeba vzít v úvahu business potřeby a dostupné datové zdroje Vyvážení mezi aktuálními potřebami (ukazateli) a nejlépe dostupnými

zdroji -> umění DW Datová tržiště:

Začít od jednodušších – rychlí přínos pro uživatele Nejprve uvést jednoduší (jeden hlavní zdroj dat) Pak až složitější (více zdrojů dat – např. profitabilita)

Dimenze Ve sloupcích matice Pro každý DM

V buňkách matice je označeno zda se dimenze v DM používá Potřeba zjistit zda danou dimenzi je možné navázat na fakta (existuje

vazba ve zdrojových datech) Popis dimenzí a datových tržišť (description)


Data Mart Date BillingDate

Resolution Date

Time Customer Product …

Customer Usage Billing X X X X

Call Detail Tracking X X X X X

Vendor Contracts X X

Purchased Product Tracking X

Materials Inventory X

Service Call Tracking X X X

… X X X


Dimension Name Dimension Description

Date Contains all of the attributes associated with the date that activity occurred.

Time Contains attributes about the time when an activity occurred.

Billing Date Contains all of the attributes associated with the date that products and/or services were billed to the customer.

… …

Data Mart Name Data Mart Description

Customer Usage Billing Represents monthly customer billing at the product and price package grain.

Call Detail Tracking Detailed customer call activity that is included in customer usage billing.

Vendor ContractsSpecifics about the relationship between Telco and suppliers of products and services. This includes both parts and products sold to customers and items purchased for internal use (office supplies etc.)

… ...


Z matice je možné identifikovat conformed dimenze (BUS architektura)

Matice je základ pro politické schválení podoby jednotlivých conformed dimenzí všemi útvary, které ji budou používat Je navržena podoba všech dimenzí a schválena Podoba na obecné úrovni, problémy zdrojů dat a kvality se řeší ve

fázi implementace ETL Potom se přistoupí k návrhu faktových tabulek

Výběr DM Urči granualitu Vyber dimenze Urči ukazatele (fakta)


Při návrhu vycházet z podoby zdrojových dat jak jsou ne jak by měly být

Začít s jednoduchými DM (jeden zdroj dat) Deklarovat přesně granualitu faktové tabulky Výběr dimenzí

Určen zvolenou granualitou Každá dimenze která nabývá jediné hodnoty pro danou granualitu

faktů je kandidátem Jestliže dimenze nevyhovuje granualitě je možně

Vynechat dimenzi Změnit granualitu faktové tabulky Uvažovat o vztahu M:N a použití pomocné tabulky


Určit fakta s danou granualitou – nevkládat fakta s jinou granualitou Zmatek při tvorbě reportů

Výběr názvu dimenzí, DM, atributů a faktů by měl odrážet obchodní zvyklosti (terminologii uživatelů) V této fázi projektu se používají názvy, které potom

uvidí uživatelé

Stejné dimenze s různou rolí pojmenuj různě (např. čas začátku volání, čas konce volání)


Výsledky zdokumentovat Využít grafické prvky

Tabulku DM vs. Dimenze Diagram faktové tabulky Detail faktové tabulky Detail dimenzionální tabulky

Diagram faktové tabulky

Grafický obrázek a popis faktové tabulky a dimenzí DM Faktová tabulka obsahuje název a popis granuality Dimenze

Napojené na faktovou tabulku Nenapojené z daného DM

Složí pro kontrolu, aby uživatelé viděli, které dimenze nepůjde s danou faktovou tabulkou využít

Názvy a popis dimenzí pod obrázkem Slouží

Pro komunikaci s uživateli Pro školení uživatelů

Umístění stejných dimenzí by mělo být na všech diagramech na stejném místě Přehlednější

Diagram faktové tabulky

Billingmonth

Employee

Internalorganization

Localserviceprovider

Ratecategory

Product

Customer

Accountstatus

Location

Longdistanceprovider

Equipmenttype

Weather

Supplier

Callingparty

Calledparty

Customer billingline item fact

Table

Grain:line item oncustomer bill

Detail faktové tabulky

Zaznamenat Fakta Odvozená fakta Další možná fakta vypočítána z předchozích skupin Potencionální fakta (nejsou pro ně zdroje)

Uživatelé vidí, že jejich názor byl vyslyšen

Agregace fakt (sum, semiaditive, neagregovatelné, …)

Detail dimenzionální tabulky

Ukazuje pro dimenzi Atributy Základní granualitu Kardinalitu atributů dimenze Hierarchie Potencionální atributy (nejsou zatím v řešení)

Popis diagramu zahrnuje Název atributu Popis atributu Kardinalitu Ukázku hodnot SCD politiku (typ 1, 2 nebo 3)


Den (365)Den (365)

Kalendářní rok (1)Kalendářní rok (1)

Kalendářní Měsíc (12)

Kalendářní Měsíc (12)

Prázdniny (14)Prázdniny (14)

Fiskální týden (52)Fiskální týden (52)

Fiskální rok (1)Fiskální rok (1)

Kalendářní Kvartál (4)

Kalendářní Kvartál (4)

Den v týdnu (7)Den v týdnu (7)

Víkend (52)Víkend (52)

Hodina (8 760)Hodina (8 760)

Budoucí možná granualita

Budoucí možný atribut

Granualita dimenze

Atributy

Více hierarchií


Lze zaznamenat vztahy M:N Řešeno pomocnou tabulkou

Lze zaznamenat SCD

ZákazníkZákazník

RodinaRodina

StavStav

MěstoMěsto

PříjemPříjem

VozidloVozidlo

M:NSCD

Budování dimensionálního modelu Vytvořit odpovídající model je interaktivní a týmová práce

Zkoumání zdrojových dat, změna granuality, spojení dimenzí, … Doporučeno nejprve vytvořit draft návrhu

Setkání zainteresovaných pracovníků Brainstorming, flip chart, … Specifické dotazy zaznamenat ale nezatěžovat se s nimi a vytvořit první

návrh Ten zdokumentovat a další pracovník mezitím hledá odpovědi na

položené otázky Pak se znovu sejit nad řešením

Postup tvorby draftu Identifikace DM Identifikace dimenzí (ty se pravděpodobně budou časem ještě měnit) Pro každý DM vyber dimenze a urči jejich granualitu Urči fakta pro DM Znovu překontroluj dimenze (objev nové dimenze, rozděl, spoj dimenze,

…)


Typy faktů (ukazatelů) Základní Odvozené a agregovatelné z základních

Lze je „uložit“ do faktové tabulky – mají stejnou granualitu Odvozené semiaditivní

S rozdílnou granualitou než faktová tabulka Např. sum prodeje od začátku roku do dnes

Potřeba zajistit že všechny odvozená fakta mají být z čeho spočtena Zjistit přesnou podobu výpočtu

Postup Identifikovat fakta (s reportů, od uživatelů, …) Odstranit duplicity Rozdělení na základní a odvoditelné Zjistit a zdokumentuj kalkulace odvozených faktů Zajistit že pro výpočet odvozených faktů jsou opravdu všechny základní

fakta v seznamu Schválení seznamu uživateli


Dokumentace faktů by měla zahrnovat Datové tržiště Název Popis Typ (základní, odvozený, odvozený semiaditivní, …) Agregační pravidlo (sum, avg, …) Způsob výpočtu

Budování dimensionálního modelu Prezentuj výsledky IS pracovníků – kontrola z jejich strany Prezentuj klíčovým uživatelům

Zapisovat poznámky a otázky Představit koncept a postupně detaily

Příklady analytických otázek, na které model může odpovědět Vyburcovat uživatele k interakci

Ptát se na názory Pojmenování Jak by chtěli s daty pracovat …

Po úpravách prezentace širokému spektru uživatelů Nebuď zklamán když uživatelé nebudou nadšení z perfektně

odvedené práce Je to model jejich business a tak když je správný není pro ně překvapující Překvapení spíš bude, když model bude špatně Překvapeni budou až dostanou prví data, rychle a jednoduše


Všechny připomínky a otázky zaznamenat a řešit Obvykle jich může být až kolem 100

Jak mají vypadat hierarchie? Co znamená tento atribut? Nebude skutečně tento atribut důležitý pro analýzu? Nemá být tato dimenze rozdělena/spojena? Jak se tyto dva atributy liší? Umožní model uživatelům vidět co chtějí? Uvědomují si uživatelé smysl daného atributu? Že tento atribut

nepokrývá určitou oblast? Využil jsem všechny informace z provozních databází? Mají všechny atributy zdrojová data?


Aby bylo možno vytvořit dobrý model je třeba porozumět Uživatelským potřebám Zdrojovým systémům a datům

Zdrojová data Zdrojové systémy Ale často i personální databáze uživatelů (Excel, …)

Pro každá zdrojová data (ZD) Jaká dat obsahuje Jak jsou dostupná Kdo je za ně zodpovědný

Detailně poznat hlavní ZD a ZD určená pro první etapu Conformed dimenze většinou pocházejí z více zdrojů

(např. zákazník)


Seznam datových zdrojů by měl být výstupem fáze získávání uživatelských požadavků

Pro každý DZ popsat Název Odpovědný pracovník z business hlediska (kvalita dat) IS správce Platforma Umístění Popis

Vhodné je aby správci provozních databází byli vtaženi do procesu tvorby DW: Rychleji jsou tak předávány informace o změnách OLTP systémů Vhodnou formou je definování datového rozhraní (extraktů), které

správce provozního systému připravuje pro načtení do DW Extrakty jsou stejné ať se změní model provozní databáze Odpovědnost je přesunuta na správce (tvůrce) provozní databáze


Vhodné je začít projekt nad jednou provozní databází (pro jednoduchost) Conformed dimenze plněny případně z více zdrojů Někdy může být náročné integrovat (např. zákazníky –

odstranění duplicit, customer matching, householding ) Potom je vhodné začít zjednodušeně a postupně

zpřesňovat Je-li více možností odkud vzít data pak se

rozhodujeme dle Dostupnosti dat Kvality dat


Je třeba provést detailní analýzu datových zdrojů pro první etapu Využít datové modely, extrakty výběru dat, dokumentaci, …

Popsat IS správce Business správce Platforma Typ databáze (MS SQL, ORACLE, Excel, soubor) Fyzická lokace Objem dat, přírůstky (počet vět, MB) Primární a cizí klíče (integritní pravidla) Fyzické charakteristiky atributů (datové typy, délka, přesnost) Minulé snahy o integraci (proč neuspěly) Budoucnost zdroje (Nebude vyměněn za nový)


Vytvořit tabulku o mapování zdrojových dat na data v DW Mělo by zahrnovat:

Název tabulky Název sloupce Datový typ (logický pro DW – znak, číslo, datum) Délku Popis sloupce Zdrojová tabulka (soubor) Zdrojový sloupec Transformace (co je dosud známo, detailně bude až v dalších fázích –

ETL) Datového tržiště

Může být více zdrojů pro jeden atribut v DW Zahrnout i atributy, které zatím nemají zdroj dat (pro budoucí použití)


Rada: Tato fáze je velmi únavná pro celý tým Řešit hlavní problémy a otázky

Složité otázky zaberou v řešení kolik času jako prvních 50 otázek a mohou mít jen malý dopad

Nastavit priority Datově kritické Politicky kritické (business rozhodnutí jak řešit problém) Otázky pro budoucí řešení (bylo by hezké je vyřešit dnes ale

stálo by to mnoho úsilí)


Řešení by mělo být rozšiřitelné do budoucnosti Prohlédnout na konceptuální úrovni datové zdroje

pro další etapy Jak zapadají do modelu první etapy Všechny otázky sepsat a předložit odpovědným

pracovníkům (business sponzor, …) Buď rozhodnou pokračovat nebo se vrátit zpět a znovu měnit

analýzu (vytvořený model)


Pro modelování využít CASE modelovací nástroje Umožňují dokumentovat, tvorbu scriptů, některé i

transformace, …. Pro odhad velikosti databáze potřeba určit počet

řádek v každé tabulce Maximální velikost faktové tabulky a dimenzí:

Vynásobit počet řádků ve všech dimenzích x velikost řádku faktové tabulky plus velikost dimenzí.

Ve skutečnosti je ale faktová tabulka řidší (nejsou všechny kombinace) – potřeba odhadnout (např. analýzou zdrojových dat)


Je třeba navrhnout i agregace faktových a dimenzionálních tabulek (pro zvýšení výkonu – někdy nahrazuj OLAP) Agregace jsou uloženy ve vlastních faktových tabulkách Dimenze agregačních tabulek jsou uřezané verze dimenzí

původních tabulek

Odhadovaná doba této fáze (2 týdny až 12 měsíců) Záleží na rozsahu řešení, složitosti dat, složitosti odvětví,

dostupnosti a otevřenosti uživatelů, …

Děkujeme za pozornost

Ing. David [email protected]

Datové sklady a BI aplikace

Documents

Transcript of Datové sklady a BI aplikace