Design databáze DW Ing. Jan Přichystal, Ph.D..

Prezentace na téma: "Design databáze DW Ing. Jan Přichystal, Ph.D.."— Transkript prezentace:

1 Design databáze DW Ing. Jan Přichystal, Ph.D.

2 Úvod Design databáze popisuje přepis logického modelu na fyzický
Implementace se v různých DB systémech liší Design vychází a je dán možnostmi DB a dalších nástrojů Design potvrzuje správný návrh ETL procesů a obráceně

3 Definice standardů Při návrhu DW je nutné definovat množinu standardů pro jednotlivé části To umožní jednotlivým koncovým uživatelům orientovat se ve struktuře DW Lze vycházet z již definovaných, ty ovšem mohou respektovat odlišnou filozofii (OLTP)

4 Konvence názvů Tabulky a atributy by měly mít shodné pojmenování jako v logickém modelu Názvy by měly být konzistentní, popisné a orientované na koncového uživatele Vhodné např.: [Customer Name] Pozor na problémy s mezerami, velikostí písmen a zvyky vývojářů

5 Použití NULL V dimenzionálních tabulkách je vhodné se vyhnout NULL hodnotám Zbytečně matou koncové uživatele Vhodnější je např.: „N/A“ nebo „Unknown“ Problém může nastat v dim. Datum Lze využít speciální hodnotu přes klíč Namapovat NULL na nepoužívané datum

6 STAGE tabulky ETL proces obvykle vyžaduje použití STAGE tabulek.
Jejich množství závisí i na typu DB systémů, ze kterých získáváme data STAGE tab. je vhodné umístit do zvláštní instance databáze Usnadní to správu i zvýší flexibilitu při případném přesunu na jiný server

7 Umístění souborů Je třeba definovat umístění souborů zdrojových kódů, skriptů a DB souborů Vhodné je využívat systém správy verzí a týmové spolupráce DB soubory by měly být umístěny na zvláštní diskové oddíly Logové soubory je vhodné umístit také zvlášť

8 Použití synonym a pohledů
Zjednodušují přístup k datům i správu Synonyma jsou dalším pojmenováním tabulek i atributů View se z pohledu koncového uživatele chová jako běžná tabulka Lze ho využít i pro odfiltrování nepotřebných, provozních atributů Umožňuje i předpočítávání hodnot Lze jím denormalizovat schéma vločky pro koncové uživatele Není vhodné pro přímý přístup k zdroj. datům

9 Primární klíče Je vhodné definovat politiku tvorby PK
Poměrně snadné je to u dim. tabulek: Oracle – SEQUENCE, MSSQL – IDENTITY Datový typ použít vhodný pro joinování, záleží na DB, někdy se hodí i malý CHAR U faktových tabulek je složený z FK, může být i sekvence, záleží to na situaci:

10 Primární klíče Interní pravidla organizace umožňují více záznamů v FT se stejným ID Některé techniky updatování záznamů ve FT to vyžadují Sekvenční hodnota umožní odhalit, kde nastal problém v ETL Snadnější debugování – „podívej se na záznam 11535“ M:N vazby mezi faktovými tabulkami

11 Cizí klíče Otázkou je jestli řešit provázanost pomocí FK
Výhodou je referenční integrita Nevýhodou nižší výkon Největší nebezpečí vyplývá z vymazání záznamu v dim tabulce, což není obvyklé Pokud DB systém podporuje optimalizace založené na CONSTRAINTS, použijte je

12 Fyzický datový model Vychází z logického datového modelu
Doplňuje např. STAGE, provozní tabulky, atd. Liší se podle typu DB systému Je potřeba ověřit: jména tabulek a atributů korespondují s firemní politikou datové typy korespondují se zdrojovými daty Doplňuje provozní sloupce Použijte modelovací nástroj (konzistence, dokumentace, …)

13 Hvězda nebo vločka Logický datový model je obvykle hvězda – intuitivnější, vyšší výkon Některé BI nástroje preferují strukturu vločka, pak je vhodné dodržet logické přirozené členění Koncoví uživatelé mohou používat VIEW

14 Odhad velikosti DW Roli hrají především faktové tabulky a indexy
Odhad velikosti zahrnuje: velikosti jednoho záznamu na základě datových typů, cca. 100B započítaní i historických dat indexy odhadneme až následně započítání prostoru pro dočasné tabulky a logy Započítání velikosti analytické krychle, cca. 40 až 300% vstupních dat Celkově DW zahrnuje asi 3x větší objem než vstupní data

15 Provozní tabulky Určeny pro běh systému:
STAGE – určeny pro uchovávání denního loadu i pro jednotlivé postupné fáze ETL AUDIT – audit provedených operací ERROR – zaznamenání chyb Monitorovací tabulky – sledují přístup uživatelů Security – omezení dotazů na určité záznamy

16 Audit tabulky Vytvořeny pro každou fact tabulku jako speciální dimenze
Obsahuje metadata o okamžiku, kdy vzniká každý nový záznam Data prezentována formou reportu informujícího o průběhu plnění DW

17 Error tabulky Cílem je zachytit všechny chyby, především v ETL
Středem je fact tabulka s granularitou na chyby Dimenze tvoří čas (id pro sumarizaci všech chyb), dávka (proces spuštění) a chyba (popis chyby) Může být propojena na Error detail tabulku

18 Indexy Závisí na konkrétním DB systému Typy a použití:
b-tree – stromová struktura, sloupce s vysokou kardinalitou (order_number, customer_key, …) clustered – sloučený, jeden na tabulku, vysoká kardinalita, data jsou fyzicky seřazena bitmap indexy – nízká kardinalita, denormalizované tabulky, typicky pro flagy a yes/no hodnoty Pokud indexace zdrží ETL o více než 20% vyplatí se indexy zrušit a znovu vytvořit

19 Indexace dimenzí Primární klíč sestává z jednoho sloupce
Na něj se vytváří index Pokud jsou podporovány bitmap indexy, používají se na sloupce, podle kterých se často filtruje B-tree indexy se používají na dimenzionální atributy Indexujte sloupce pro joiny, filtry i seskupování

20 Indexace fakt tabulek Především b-tree nebo clustered index na primární klíč Klíč časové dimenze by měl být první, protože se podle něj často dotazuje Indexují se i jednotlivé FK do dimenzí Fakta se nevyplatí indexovat, jen v případě, že jsou častou součástí dotazu: „plat > “

21 Testování kvality dat Nevyplácí se podceňovat
Spočívá ve spuštění dotazu pracujícím se zdrojovými daty, který kopíruje logiku DW Získané výsledky se srovnávají s těmi v DW Srovnávají se SUM a COUNT hodnoty Neexistuje testovací nástroj

22 Další testy ETL – testování, zda ETL se spouští kdy má, probíhá předem odhadnutý čas, jednotlivé fáze jsou včas, množství souhlasí Výkonostní – hardware, OS, DB systém, ladění výkonu (indexy) Použitelnost – spolupráce s uživateli

23 Děkuji za pozornost Dotazy?