UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY. Datové sklady KIT/INDSK

Transkript

1 UNIVERZITA PARDUBICE FAKULTA ELEKTROTECHNIKY A INFORMATIKY Datové sklady KIT/INDSK Jakub Mejznar 2011/2012 1

2 Obsah Seznam Obrázků... 4 Tabulka Faktů... 5 Požadavky na tabulku faktů... 5 Tabulka Dimenzí... 6 Hierarchie... 7 Kostka... 8 Partitioned Tables... 9 Vytvoření partitioned tables Materialized Views Materializované pohledy a přehled potřeb Přehled řízeného použití materializovaných pohledů Hlavní typy materializovaných pohledů Příklady vytvoření materializovaných pohledů Dimensions Vytváření dimenzí Mazání a vytváření sloupců Mnohonásobné hierarchie Využití normalizovaných dimenzionálních tabulek Prohlížení dimenzí Using the DESCRIBE_DIMENSION Procedure Využití dimenzí s omezeními Validace dimenzí Pozměnění dimenzí Mazání dimenzí Popis realizace ve schématu SH Partitioned table Columns Indexy DDL Materialized View Refresh Option:

3 Indexy: SQL Query DDL Dimension Hierarchie Úrovně Script Output DDL

4 Seznam Obrázků Obrázek 1 - Tabulka faktů... 5 Obrázek 2 - Tabulka dimenze... 6 Obrázek 3 - Hierarchie... 7 Obrázek 4 - Datová kostka... 8 Obrázek 5 - Partitioned table... 9 Obrázek 6 - Transparentní přepisování dotazů Obrázek 7 - Hvězdicové schéma Obrázek 8 - Informační hierarchie Obrázek 9 - Mnohonásobná hierarchie

5 Tabulka Faktů typicky obsahuje dva typy sloupců: ty které obsahují číselná fakta (obvykle nazývaná měření) a ty, ve kterých jsou cizí klíče k tabulkám dimenzí obsahují buď informace na detailní úrovni, nebo fakta, která již byla seskupena (tyto tabulky faktů obvykle nazýváme shrnutím) obvykle obsahují fakta se stejnou úrovní seskupení (agregace) většina faktů je aditivních, ale mohou být i polo-aditivní a neaditivní. o Aditivní fakta mohou být seskupena jednoduchým aritmetickým doplňkem, typickým příkladem je prodej o Polo aditivní fakta jsou seskupena podél některé konkrétní dimenze, příkladem mohou být skladové zásoby, kde není možné určit úroveň pouze pohledem o Neaditivní fakta nemohou být přidána, příkladem jsou průměry Požadavky na tabulku faktů tabulka faktů musí být definována pro každé hvězdicové schéma primárním klíčem je obvykle složený klíč, vytvořený ze všech cizích klíčů Obrázek 1 - Tabulka faktů 5

6 Tabulka Dimenzí dimenze je struktura, skládající se z jedné, nebo více hierarchií, která kategorizují data atributy dimensí napomáhají k popisu dimensionální hodnoty, bývají popsány textovými hodnotami několik odlišných dimensí, kombinované s fakty, vám umožní odpovědět na obchodní otázky běžně používanými dimenzemi jsou zákazníci, produkty a čas dimenzionální data jsou typicky shromažďována na nejnižší úrovni detailu a dále slučována do vyšších úrovní, které jsou více užitečné k analýze, toto slučování nazýváme hierarchiemi Obrázek 2 - Tabulka dimenze 6

7 Hierarchie logická struktura, které používají seřazených úrovní, k organizaci dat mohou být použity ke sloučení (agregaci) dat například v časové dimensi, hierarchie může seskupit data z úrovně měsíc do úrovně čtvrtletí v úrovni rok mohou být také využity k definování směru cesty a také k definici rodinné struktury uvnitř hierarchie je každá úroveň logicky propojena s vyšší i nižší úrovní datové hodnoty z nižších úrovní se slučují do datových hodnot vyšších úrovní dimense může být složena s více než jedné hierarchie například v dimensi produktů mohou být dvě hierarchie jedna pro kategorii produktu a druhá pro dodavatele produktu Obrázek 3 - Hierarchie 7

8 Kostka Kostky obsahuji míry a spojení na jednu nebo více dimensí. Osy kostky obsahuji dimensionální členy a tělo kostky obsahuje hodnoty míry. Například data prodeje mohou být organizována do kostky, jejíž hrany obsahují hodnoty dimensí času, produktu a povýšení a jejíž tělo obsahuje hodnoty z měření hodnocení prodej a dolarového prodej. Kostka je propojena do tabulek dimensi pres cizí klíče. Omezení zajišťují referenční integritu během denních operaci s daty ve skladě. Aplikace analýzy dat typicky soustřeďují data přes mnoho dimensí. To umožňuje vyhledání anomálií nebo neobvyklých zákonitostí v datech. Používáním kostek je nejúčinnější cesta k vykonávání operací toho typu. V relační implementaci, při návrhu dimensí se skladovými klíči, délka řádku kostky je obvykle redukována. To protože skladové klíče jsou kratší než jejich přirozené protějšky. Ve výsledku je potřeba menší úložný prostor pro data kostky. Pro klíče se využívá datový typ VARCHAR2. Obrázek 4 - Datová kostka 8

9 Partitioned Tables Datové sklady obsahují velice rozměrné tabulky, a proto potřebují techniky, které by sloužili k řízení těchto objemných tabulek a také by zajistili dobrý dotazovací výkon. Důležitým nástrojem k dosažení tohoto cíle, společně se zvýšením přístupu k datům, je partitioning. Partitioning nabízí podporu pro veliké tabulky a indexy tím, že je rozloží do menších a lépe spravitelných částí, které nazýváme partitiony. Tato podpora je důležitá především v aplikacích s přístupem k tabulkám a indexům s miliony záznamy a mnoha gigabajty dat. Partitioned tabulky a index usnadňují administrativní operace tak, že jim povolují pracovat nad podmnožinou dat. Například je možné vložit nový partition, organizovat existující partition, nebo smazat martition s téměř nulovým přerušením read-only aplikace. Partitioning také může pomoci vyladit SQL příkazy tak, aby se předešlo k prohledávání zbytečných tabulek a indexů. Dále je možné vylepšit ýkon masivních spojovacích operací s velkým množstvím dat. Posledním vlastností je skvělé vylepšení ovladatelnosti velmi velkých databází a dramatické zredukování času pro jejich administrativu, jako například záloha, popř. obnova dat. Při vkládání, nebo vytváření partitiony, máte možnost odložení vzniku segmentu, dokud data nebudou poprvé vložena. Obrázek 5 - Partitioned table Granularita v partition schématu může být jednoduše změněna rozdělením, nebo spojením, partition. Pokud jsou data tabulky v jedné partitione více než v ostatních, ta která obsahuje více dat, může být rozdělena pro dosažení rovnoměrnějšího rozdělení. Partitioning také 9

10 umožňuje výměnu partitiony s tabulkou. Tím, že je možné snadno přidat, odstranit, nebo vyměnit velké množství dat ve velmi krátkém čase, swapping může být využit k udržení velkého množství dat, která jsou načtena, nedostupných, dokud není nahrávání ukončeno, nebo může být použito jako cesta k ukládání dat mezi rozdílnými fázemi využití. Pro příklad to jsou denní transakce, nebo online archivy. Dobrým výchozím bodem pro zvážení strategie partitioningu je použití poradenství v rámci SQL Access Advisor, část o Tuning Pack. SQL Access Advisor nabízí jak grafické rozhraní, tak rozhraní příkazového řádku. Kompletní přístup, který se běžně využívá společně s partitioningem je paralelní provádění, které urychluje dlouho trvající dotazy, ETL a některé další operace. Vytvoření partitioned tables CREATE TABLE sales_range_hash( s_productid NUMBER, s_saledate DATE, s_custid NUMBER, s_totalprice NUMBER) PARTITION BY RANGE (s_saledate) SUBPARTITION BY HASH (s_productid) SUBPARTITIONS 8 (PARTITION sal99q1 VALUES LESS THAN (TO_DATE('01-APR-1999', 'DD-MON-YYYY')), PARTITION sal99q2 VALUES LESS THAN (TO_DATE('01-JUL-1999', 'DD-MON-YYYY')), PARTITION sal99q3 VALUES LESS THAN (TO_DATE('01-OCT-1999', 'DD-MON-YYYY')), PARTITION sal99q4 VALUES LESS THAN (TO_DATE('01-JAN-2000', 'DD-MON-YYYY'))); SELECT * FROM sales_range_hash WHERE s_saledate BETWEEN (TO_DATE('01-JUL-1999', 'DD-MON-YYYY')) AND (TO_DATE('01-OCT-1999', 'DD-MON-YYYY')) AND s_productid = 1200; 10

11 Materialized Views Další z technik v datových skladech pro zvýšení výkonu je vytváření přehledů. Přehledy jsou speciálními typy agregovaných pohledů, které zlepšují časy spouštěných dotazů. Dotazy se hodnotí podle výpočetních kritérií a výsledky agregačních operací se před výkonem ukládají do tabulky v databázi. Například můžete vytvořit souhrnnou tabulku obsahující součty prodejů dle krajů a produktů. Přehledy nebo agregace jsou zapouzdřeny ve speciální datové struktuře, které se nazývají materializovaný pohled. Materializované pohledy mohou provádět celou řadu akcí, jako je například zlepšení výkonu dotazu nebo poskytování replikovaných dat. Materializované pohledy jsou pohledy, které poskytují pohled na určitá souhrnná data. Takových pohledů je vytvořeno více a jsou využívány uživateli, kteří dostávají požadovaná data. Mechanismus Oracle serveru upravuje SQL dotaz, tak aby bylo možné použít více ekvivalentních materializovaných pohledů. Materializované pohledy jsou dostupné pomocí dotazů od uživatele a v rámci datového skladu jsou transparentní pro koncového uživatele nebo databázové aplikace. V DS můžeme používat materializované pohledy k předpočítání výpočtů a ukládání agregovaných dat jako například součet tržeb. Materializované pohledy v těchto prostředích jsou často označovány jako souhrny, protože ukládají souhrnné údaje. Mohou být také použity k předzpracování spojení výsledků dotazů s agregací anebo bez agregace. Materializovaný pohled eliminuje režii spojenou s nákladnými spojeními a agregací pro velké nebo důležité třídy dotazů. Aby data byla aktuální, je potřeba také nastavit určitý proces, kterým se zajistí jejich obnova. Materializované pohledy našli také své využití v distribuovaných výpočtech a při získávání dat mobilními klienty. Materializované pohledy a přehled potřeb V datových skladech se materializované pohledy využívají ke zrychlení dotazů nad velkou databází, kde dochází často ke spouštění dotazů obsahujících agregační funkce. Operace agregace jsou náročné z hlediska času a výpočetního výkonu. Oracle optimalizátor automaticky rozpozná, kdy je vhodné využít některý z materializovaných pohledů pro odpověď na dotaz zadaný uživatelem. Tuto skutečnost popisuje následující schéma. 11

12 Obrázek 6 - Transparentní přepisování dotazů Motivací k používání materializovaných pohledů je zvýšení výkonu. Přesto se může stát, že materializované pohledy výkon serveru nezvyšují, protože mohou být špatně nastaveny nebo nejsou využívány v pravém okamžiku. Při přepisování dotazů, se vytvoří materializované pohledy, které splňují největší počet dotazů. Například pokud identifikujeme 20 dotazů, které jsou běžně aplikovány na detaily nebo skutečnosti tabulek, pak bychom měli být schopni uspokojit je s pěti nebo šesti dobře napsanými materializovanými pohledy. Definice materializovaného pohledu může obsahovat libovolný počet agregací (SUM, COUNT(x), COUNT(*), COUNT(DISTINCT x), AVG, VARIANCE, STDDEV, MIN a MAX). Také může obsahovat libovolný počet spojení. Přehled řízeného použití materializovaných pohledů Motivace pro použití materializovaných pohledů je zlepšení výkonu. Režie spojené s řízením materializovaného pohledu se může stát významným problémem systémového řízení. Při kontrole nebo vyhodnocování některých nezbytných činností řízení materializovaného pohledu, se musí zvážit některé z následujících akcí: Identifikování toho, co materializovaný pohledy potřebují na začátku k vytvoření Indexace materializovaných pohledů Zajistit, aby všechny materializované pohledy a indexy materializovaných pohledů byli aktualizovány správně pokaždé, když je databáze aktualizovaná Kontrola, které materializované pohledy byly použity Určování toho, jak efektivní každý materializovaný pohled byl na pracovní zátěži výkonu 12

13 Určení, které nové materializované pohledy by měly být vytvořeny Určení, které existující materializované pohledy by měli být zrušeny Archivace staršího detailu a materializovaného pohledu dat, která již nejsou užitečná Hromadné načtení dat do skladu Hlavní typy materializovaných pohledů Materializované pohledy s agregací Materializované pohledy obsahující pouze spojení vnořené materializované pohledy Příklady vytvoření materializovaných pohledů CREATE MATERIALIZED VIEW cust_sales_mv PCTFREE 0 TABLESPACE demo STORAGE (INITIAL 8M) PARALLEL BUILD IMMEDIATE REFRESH COMPLETE ENABLE QUERY REWRITE AS SELECT c.cust_last_name, SUM(amount_sold) AS sum_amount_sold FROM customers c, sales s WHERE s.cust_id = c.cust_id GROUP BY c.cust_last_name; Příklad vytvoření materializovaného pohledu s agregací CREATE MATERIALIZED VIEW LOG ON products WITH SEQUENCE, ROWID (prod_id, prod_name, prod_desc, prod_subcategory, prod_subcategory_desc, prod_category, prod_category_desc, prod_weight_class, prod_unit_of_measure, prod_pack_size, supplier_id, prod_status, prod_list_price, prod_min_price) INCLUDING NEW VALUES; Na dalším příkladu je ukázka vytvoření materializovaného pohledu s agregací: CREATE MATERIALIZED VIEW LOG ON sales WITH SEQUENCE, ROWID (prod_id, cust_id, time_id, channel_id, promo_id, quantity_sold, amount_sold) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW product_sales_mv PCTFREE 0 TABLESPACE demo STORAGE (INITIAL 8M) BUILD IMMEDIATE REFRESH FAST ENABLE QUERY REWRITE AS SELECT p.prod_name, SUM(s.amount_sold) AS dollar_sales, COUNT(*) AS cnt, COUNT(s.amount_sold) AS cnt_amt FROM sales s, products p WHERE s.prod_id = p.prod_id GROUP BY p.prod_name; Příklad vytvoření materializovaného pohledu pouze se spojením CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID; CREATE MATERIALIZED VIEW LOG ON times WITH ROWID; CREATE MATERIALIZED VIEW LOG ON customers WITH ROWID; CREATE MATERIALIZED VIEW detail_sales_mv 13

14 PARALLEL BUILD IMMEDIATE REFRESH FAST AS SELECT s.rowid "sales_rid", t.rowid "times_rid", c.rowid "customers_rid", c.cust_id, c.cust_last_name, s.amount_sold, s.quantity_sold, s.time_id FROM sales s, times t, customers c WHERE s.cust_id = c.cust_id(+) AND s.time_id = t.time_id(+); Příklad vytvoření vnořeného materializovaného pohledu CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID; CREATE MATERIALIZED VIEW LOG ON customers WITH ROWID; CREATE MATERIALIZED VIEW LOG ON times WITH ROWID; Následující příklad vytvoří materializovaný pohled join_sales_cust_time, tak aby se obnovoval po commitu: CREATE MATERIALIZED VIEW join_sales_cust_time REFRESH FAST ON COMMIT AS SELECT c.cust_id, c.cust_last_name, s.amount_sold, t.time_id, t.day_number_in_week, s.rowid srid, t.rowid trid, c.rowid crid FROM sales s, customers c, times t WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id; Další příklad vytvoří materializovaný pohled na tabulku join_sales_cust_time. Je zapotřebí vytvořit materializovaný view log na tabulku. Protože se jedná o agregaci jedné tabulky, musíme zaznamenávat všechny potřebné sloupce a využít klauzuli INCLUDING NEW VALUE: CREATE MATERIALIZED VIEW LOG ON join_sales_cust_time WITH ROWID (cust_last_name, day_number_in_week, amount_sold), INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW sum_sales_cust_time REFRESH FAST ON COMMIT AS SELECT COUNT(*) cnt_all, SUM(amount_sold) sum_sales, COUNT(amount_sold) cnt_sales, cust_last_name, day_number_in_week FROM join_sales_cust_time GROUP BY cust_last_name, day_number_in_week; 14

15 Dimensions Dimense je struktura, která kategorizuje data tak, aby byla uživatelsky čitelná a zodpovídala tím i snadno zodpovídala business otázky. Nejčastějšími dimenzemi jsou zákazníci, produkty a čas. Například, každý prodejní kanál prodejce oděvů mohou shromažďovat a ukládat data týkající se prodeje a reklamace jejich sortimentu. Maloobchodní řetězce mohou stavět datový sklad pro analýzu prodeje svých produktů ve všech prodejnách, což napomůže odpovědět otázky typu: Jaký je efekt, pokud snížím cenu jednoho produktu, na související produkt, který nebyl zlevněn? Jaký je prodej produktu před a po slevě? Jaký má sleva efekt na rozdílné distributorské kanály? Údaje v o obchodníkově datovém skladu mají dvě důležité komponenty: dimenze a fakty. Dimenze jsou produkty, zákazníky, akce, kanály a čas. Fakty jsou prodeje (prodané jednotky) a profit. Datový sklad obsahuje fakta o každém produktu pro každý den. Typickou implementací datového skladu je hvězdicové schéma. Obrázek 7 - Hvězdicové schéma V Oracle Databázích, je dimensionální informace uložena v dimensionální tabulce. Kromě toho, databázový objekt dimenze pomáhá organizovat a seskupovat informace do dimenzionální hierarchie. Toto reprezentuje vazba 1:n mezi sloupci /skupiny sloupců (úrovně hierarchie), které nemohou být prezentovány s omezujícími podmínkami. Analýza dat obvykle začíná na vyšších levlech v dimenzionální hierarchii a postupně směřuje směrem dolů, pokud to situace potřebuje. 15

16 Dimenze nemusí být definovány. Avšak pokud vaše aplikace využívá dimenzionální model, vyplatí se strávit nějaký čas jejich vytvářením, přináší to mnoho výhod. Dimenze jsou také přínosem pro operace obnovení materializovaných pohledů s SQL Access Advisorem. Vytváření dimenzí Předtím, než budete moci vytvořit dimenzionální objekt, musí databáze obsahovat dimenzionální tabulku obsahující dimenzionální data. Například, pokud vytvoříme dimenzi zákazníků, musí existovat tabulky, které obsahují informace o městech a státech atd. Nyní lze nakreslit hierarchii dimenzí tak, jak je zobrazena na následujícím obrázku. Například město je potomkem státu (protože můžeme shrnout data z úrovně měst nahoru do úrovně státu) a země. Tato informační hierarchie bude uložena v databázovém objektu dimenze. Obrázek 8 - Informační hierarchie V případě normalizovaných, nebo částečně normalizovaných dimenzí reprezentací (dimenze, která je uložena ve více jak jedné tabulce), musíme zjistit, jak jsou tyto tabulky propojeny. Pamatujte si, že jakékoli spojení mezi dimenzionálními tabulkami může zaručit, že každá řádka potomka může být napojena pouze na jeden řádek na straně rodiče. V případě denormalizované dimenze, je zapotřebí určit zda sloupce potomka unikátně determinují sloupce na straně předka. Pokud k těmo relacím využíváme omezení, mohou být povolena klauzulemi NOVALIDATE a RELY. Dimenze se vytváří CREATE DIMENSION příkazem, nebo s využitím Dimension Wizardu v Oracle Enterprise Manageru. V CREATE DIMENSION příkazu se využívá LEVEL klauzule k identifikaci jména a úrovně dimenze. 16

17 Hierarchická integrita je nezbybtná ke správnému fungování operací pro správu materializovaných pohledů. Například, je možné deklarovat dimenzi products_dim, která obsahuje úrovně product, subcategory, a category: CREATE DIMENSION products_dim LEVEL product LEVEL subcategory IS (products.prod_id) IS (products.prod_subcategory) LEVEL category IS (products.prod_category)... Každá úroveň dimenze musí korespondovat s jedním, nebo více sloupci v tabulce v databázi. Tedy, úroveň product je identifikována sloupcem prod_id v tabulce products a úroveň subcategory je identifikovaná sloupcem s názvem prod_subcategory v té stejné tabulce. V tomto příkladu, jsou databázové tabulky denormalizovány a všechny sloupce exinstují v jedné tabulce. Avšak není to požadavek pro vytváření dimenzí. Dalším krokem je deklarace vztahů mezi úrovněmi s příkazem HIERARCHY a jejich pojmenování. Vztahy mezi hierarchiemi jsou funkčně závislé od konkrétní úrovně k úrovni v hierarchii následující. Díky pojmenovaným úrovním nadefinovaným dříve, potomek (CHILD OF) vztahu označuje, že každá úroveň potomka je spojena pouze s jednou úrovní předka. Následující příkaz deklaruje hierarchii prod_rollup a definuje vztah mezi products, subcategory a category: HIERARCHY prod_rollup (product CHILD OF subcategory CHILD OF category) Kromě hierarchického vzathu 1:n, dimenze disponují i 1:1 atributy mezi úrovněmi a jejich závislostmi, určených atributům dimenze. Například, dimenze times_dim, obsahuje sloupce fiscal_month_desc, fiscal_month_name a days_in_fiscal_month. Jejich vztahy jsou definovány níže: LEVEL fis_month IS TIMES.FISCAL_MONTH_DESC... ATTRIBUTE fis_month DETERMINES (fiscal_month_name, days_in_fiscal_month) ATTRIBUTE... DETERMINES klauzule se týká fis_month do fiscal_month_name a days_in_fiscal_month. Všimněte si, že je to jen jednosměrná determinace, která garantuje jen, že pro fiscal_month, například , bude nalezena naprosto přesná hodnota pro fiscal_month_name, například November a days_in_fiscal_month, například 28. Nelze určit konkrétní fiscal_month_desc založen na fiscal_month_name, což je November pro každý fiskální rok. Příklad: CREATE DIMENSION products_dim LEVEL product IS (products.prod_id) LEVEL subcategory IS (products.prod_subcategory) [SKIP WHEN NULL] LEVEL category IS (products.prod_category) 17

18 HIERARCHY prod_rollup ( product CHILD OF subcategory CHILD OF category) ATTRIBUTE product DETERMINES (products.prod_name, products.prod_desc, prod_weight_class, prod_unit_of_measure, prod_pack_size, prod_status, prod_list_price, prod_min_price) ATTRIBUTE subcategory DETERMINES (prod_subcategory, prod_subcategory_desc) ATTRIBUTE category DETERMINES (prod_category, prod_category_desc); Alternativně mohla být použita klauzule extended_attribute_clause namísto attribute_clause, jak je ukázáno v následujícím příkladu: CREATE DIMENSION products_dim LEVEL product IS (products.prod_id) LEVEL subcategory IS (products.prod_subcategory) LEVEL category IS (products.prod_category) HIERARCHY prod_rollup ( product CHILD OF subcategory CHILD OF category ) ATTRIBUTE product_info LEVEL product DETERMINES (products.prod_name, products.prod_desc, prod_weight_class, prod_unit_of_measure, prod_pack_size, prod_status, prod_list_price, prod_min_price) ATTRIBUTE subcategory DETERMINES (prod_subcategory, prod_subcategory_desc) ATTRIBUTE category DETERMINES (prod_category, prod_category_desc); Design, vytvoření a údržba dimenzí je součástí designu, tvorby a údržby vašeho schématu datového skladu. Pokud vytvoříte novou dimenzi, ověřte si, zda splňuje následující požadavky: Mezi předkem a potomkem musí být vazba 1:n. Předek může mít jednoho, nebo více potomků, ale potomek jen jednoho předka Mezi úrovněmi hierarchie a jejich závislými atributy musí být vztah 1:1 Pokud sloupce úrovně předka a úrovně potomka jsou v rozdílných vazbách, poté spojení mezi nimi musí být 1:n. Každý řádek potomka musí být propojen jen s jedním řádkem předka, vyjímka je při využití klauzule SKIP WHEN NULL Musíte se ujistit, že sloupce hierarchií nejsou prázdné, výjimka vzniká při použití klauzule SKIP WHEN NULL Hierarchie dimenzí mohou být překryty, nebo od sebe odpojeny. Avšak sloupce hierarchií nemohou být přidruženy k více jak jedné dimenzi Mazání a vytváření sloupců Příkaz CREATE DIMESION může být využit pro specifikaci jednoho, nebo více sloupců, které jsou unikátně určeny podle úrovně hierarchie. 18

19 Pokud využíváte extended_attribute_clause k vytvoření více sloupců rozdělených podle úrovně hierarchie, můžete smazat jakýkoli atribut bez potřeby smazání všech ostatních. Alternativně je možno specifikovat jméno atributu pro každý příkaz CREATE, nebo ALTER DIMENSION tak, že jméno atributu je specifikováno pro každý atribut, kde je možnost spedifikování vazby mezi více úrovněmi. Následující příkaz ilustruje smazání jednotlivého sloupce, bez potřeby smazání sloupců ostatních: CREATE DIMENSION products_dim LEVEL product IS (products.prod_id) LEVEL subcategory IS (products.prod_subcategory) LEVEL category IS (products.prod_category) HIERARCHY prod_rollup ( product CHILD OF subcategory CHILD OF category) ATTRIBUTE product DETERMINES (products.prod_name, products.prod_desc, prod_weight_class, prod_unit_of_measure, prod_pack_size,prod_status, prod_list_price, prod_min_price) ATTRIBUTE subcategory_att DETERMINES (prod_subcategory, prod_subcategory_desc) ATTRIBUTE category DETERMINES (prod_category, prod_category_desc); ALTER DIMENSION products_dim DROP ATTRIBUTE subcategory_att LEVEL subcategory COLUMN prod_subcategory; Mnohonásobné hierarchie Definice jediné dimenze může obsahovat více hierarchií. Předpokládejme, že náš maloobchodník chce sledovat prodej určité věci v čase. Prvním krokem je definování časové dimenze, díky které budeme prodej sledovat. Následující obrázek ilustruje dimenzi times_dim s dvěmi hierarchiemi. Obrázek 9 - Mnohonásobná hierarchie 19

20 Nyní můžeme vytvořit hierarchii denormalizované time_dim dimenze pomocí příkazu CREATE DIMENSION. CREATE DIMENSION times_dim LEVEL day IS times.time_id LEVEL month IS times.calendar_month_desc LEVEL quarter IS times.calendar_quarter_desc LEVEL year IS times.calendar_year LEVEL fis_week IS times.week_ending_day LEVEL fis_month IS times.fiscal_month_desc LEVEL fis_quarter IS times.fiscal_quarter_desc LEVEL fis_year IS times.fiscal_year HIERARCHY cal_rollup ( day CHILD OF month CHILD OF quarter CHILD OF year ) HIERARCHY fis_rollup ( day CHILD OF fis_week CHILD OF fis_month CHILD OF fis_quarter CHILD OF fis_year ) <attribute determination clauses>; Využití normalizovaných dimenzionálních tabulek Tabulky využívané k definování dimenzí mohou být normalizované, nebo denormalizované, stejně jako každá individuální hierarchie. Pokud úrovně hierarchie pocházejí z jedné tabulky, nazýváme je plně denormalizovaná hierarchie. Například cal_rollup v times_dim dimenzi je demoralizovanou hierarchií. Pokud úrovně hierarchie pocházejí z různých tabulek, hierarchie je plně, nebo jen částečně normalizovanou hierarchií. Tato sekce poukazuje, jak definujeme normalizovanou hierarchii. Předpokládejme, že sledujeme zákazníky podle města, státu a země. Tato data jsou uložena v tabulkách customer a countries. Customer dimenze customer_dim je částečně normalizovanou, protože datové entity cust_id a country_id jsou brány z dalších tabulek. Klauzuje JOIN KEY v dimenzi specifikuje jak propojit dohromady úrovně hierarchie. Příkaz pro dimenzi je částečně ukázán an následujícím příkladu. CREATE DIMENSION customers_dim LEVEL customer IS (customers.cust_id) LEVEL city IS (customers.cust_city) LEVEL state IS (customers.cust_state_province) LEVEL country IS (countries.country_id) LEVEL subregion IS (countries.country_subregion) LEVEL region IS (countries.country_region) HIERARCHY geog_rollup ( customer CHILD OF city CHILD OF state CHILD OF country CHILD OF subregion CHILD OF region JOIN KEY (customers.country_id) REFERENCES country); 20

21 Pokud použijete klauzuli SKIP WHEN NULL, můžete také využít JOIN KEY klauzuli na propojení úrovní, které postrádají úrovně v hierarchii. Například následující příkaz povoluje úrovni státu, která byla zadeklarovaná jakko SKIP WHEN NULL připojit město a zemi: JOIN KEY (city.country_id) REFERENCES country; Toto zajistí, že řádky zákazníků a měst stále zůstanou asociovány s řádky zemí, subregionů a regionů. Prohlížení dimenzí Využití Oracle Enterprise Managera Všechny dimenze, které existují v datovém skladu, mohou být prohlíženy s využitím Oracle Enterprise Managera. Using the DESCRIBE_DIMENSION Procedure K prohlížení definice dimenze slouží procedure DESCRIBE_DIMENSION v DBMS_DIMENSION balíčku. Například pokud je dimenze vytvořena v schématu sh následujícími příkazy: CREATE DIMENSION channels_dim LEVEL channel IS (channels.channel_id) LEVEL channel_class IS (channels.channel_class) HIERARCHY channel_rollup ( channel CHILD OF channel_class) ATTRIBUTE channel DETERMINES (channel_desc) ATTRIBUTE channel_class DETERMINES (channel_class); Lze spustit DESCRIBE_DIMENSION proceduru následujícím způsobem: SET SERVEROUTPUT ON FORMAT WRAPPED; --to improve the display of info EXECUTE DBMS_DIMENSION.DESCRIBE_DIMENSION('SH.CHANNELS_DIM'); Bude následovat tento výstup: EXECUTE DBMS_DIMENSION.DESCRIBE_DIMENSION('SH.CHANNELS_DIM'); DIMENSION SH.CHANNELS_DIM LEVEL CHANNEL IS SH.CHANNELS.CHANNEL_ID LEVEL CHANNEL_CLASS IS SH.CHANNELS.CHANNEL_CLASS HIERARCHY CHANNEL_ROLLUP ( CHANNEL CHILD OF CHANNEL_CLASS) ATTRIBUTE CHANNEL LEVEL CHANNEL DETERMINES SH.CHANNELS.CHANNEL_DESC ATTRIBUTE CHANNEL_CLASS LEVEL CHANNEL_CLASS DETERMINES SH.CHANNELS.CHANNEL_CLASS Využití dimenzí s omezeními Omezení hrají v dimenzích důležitou roli. Plná referenční integrita bývá v datových skladech povolena, ale není tomu tak vždy. Je to způsobeno tím, že operační databáze má normálně plnou referenční integritu a může tak zajistit, že datový sklad nikdy nevyvolá výjimku, která porušuje pravidla integrity. 21

22 Je doporučeno, aby omezení byla zapnuta, ale pokud je validační čas problémem, se může využít NOVALIDATE klauzule: ENABLE NOVALIDATE CONSTRAINT pk_time; Primární a cizí klíče by měli být implementovány. Omezení referenční integrity a NOT NULL omezení v tabulce faktů poskytuje informace, které mohou být užitečné pro materializované pohledy. Navíc by se měla využívat klauzule RELY pro informace query rewriteru, že se může spolehnot na omezení, a to takto: ALTER TABLE time MODIFY CONSTRAINT pk_time RELY; Validace dimenzí Informace o objektu dimenze je pouze deklarativní a není vyžadována databází. Pokud jsou vztahy mezi dimenzemi nekorektní, lze očekávat špatné výsledky. Proto je dobré pravidelně využívat k verifikaci vazeb proceduru DBMS_DIMENSION.VALIDATE_DIMENSION. Tato procedura se jednoduše využívá a má jen čtyři parametry: dimension: vlastník a jméno incremental: pokuj je TRUE kontroluje pouze nově vložené řádky check_nulls: pokuj je TRUE kontroluje, zda všechny sloupce, které nejsou v úrovních se SKIP WHEN NULL klauzulí, nejsou nullové statement_id: unikátní identifikátor sloužící k identifikaci výsledku každého běhu procedury Následující příklad validuje dimenzi TIME_FN ve schématu EXECUTE DBMS_DIMENSION.VALIDATE_DIMENSION ('SH.TIME_FN', FALSE, TRUE, 'my first example'); Předtím, než spustíme VALIDATE_DIMENSION proceduru, potřebujeme vytvořit lokální tabulku, DIMENSION_EXCEPTIONS, spuštěním skriptu utldim.sql. Pokud validační procedura narazí na nějakou chybu, tak je uložena právě do této tabulky. Dotazem na tabulku zjistíme výjimky, které byly nalezeny. Následuje příklad: SELECT * FROM dimension_exceptions WHERE statement_id = 'my first example'; STATEMENT_ID OWNER TABLE_NAME DIMENSION_NAME RELATIONSHIP BAD_ROWID my first example SH MONTH TIME_FN FOREIGN KEY AAAAuwAAJAAAARwAAA Pozměnění dimenzí Dimense mohou být modifikováný použitím ALTER DIMENSION příkazu. Může být přidán, nebo smazán level, hierarchie, nebo atribut z dimenze použitím těchto příkazu: ALTER DIMENSION times_dim DROP ATTRIBUTE fis_year; 22

23 ALTER DIMENSION times_dim DROP HIERARCHY fis_rollup; ALTER DIMENSION times_dim DROP LEVEL fis_year; ALTER DIMENSION times_dim ADD LEVEL f_year IS times.fiscal_year; Pokud je při vytváření dimenzí použita klauzule extended_attribute_clause, je možné smazat jeden atribut bez toho aniž, by bylo zapotřebí smazat ostatní atributy. Vše je úkázáno na následujícím příkladu: CREATE DIMENSION products_dim LEVEL product IS (products.prod_id) LEVEL subcategory IS (products.prod_subcategory) LEVEL category IS (products.prod_category) HIERARCHY prod_rollup ( product CHILD OF subcategory CHILD OF category) ATTRIBUTE product DETERMINES (products.prod_name, products.prod_desc, prod_weight_class, prod_unit_of_measure, prod_pack_size,prod_status, prod_list_price, prod_min_price) ATTRIBUTE subcategory_att DETERMINES (prod_subcategory, prod_subcategory_desc) ATTRIBUTE category DETERMINES (prod_category, prod_category_desc); ALTER DIMENSION products_dim DROP ATTRIBUTE subcategory_att LEVEL subcategory COLUMN prod_subcategory; Pokud se pokusíte smazat cokoli s dalšími závislostmi uvnitř dimenze, Oracle Databáze tuto změnu zamítne. Dimenze se stává neplatnou, pokud se změní jakékoli objekt schématu, na který dimenze odkazuje. Například, pokud tabulka, na kterou je dimenze definované je pozměněna, dimenze se stane neplatnou. Je možné modifikovat dimenzi přidáním SKIP WHEN NULL klauzule, jako na následujícím příkladu: ALTER DIMENSION times_dim ADD LEVEL f_year IS times.fiscal_year SKIP WHEN NULL; Úrovně obsahující SKIP WHEN NULL klauzuli nemohou být modifikovány. Namísto toho je třeba level smazat a vytvořit znovu. Pro obnovení platnosti dimenze je zapotřebí využít volbu COMPILE, stejně jako na následujícím příkladu: ALTER DIMENSION times_dim COMPILE; Dimenze mohou být také modifikovány, nebo smazány pomocí Oracle Enterprise Managera. Mazání dimenzí Dimenze je odstranena použitím DROP DIMENSION příkazu. Například následujícím příkazem: DROP DIMENSION times_dim; 23

24 Popis realizace ve schématu SH Partitioned table Název: Sales Tabulka faktů bez primárního klíče. Všechny řádky jsou unikátní pomocí kombinací všech cizích klíčů. Columns PROD_ID : NUMBER CUST_ID : NUMBER TIME_ID : DATE CHANNEL_ID : NUMBER PROMO_ID : NUMBER QUANTITY_SOLD : NUMBER(10,2) AMOUNT_SOLD : NUMBER(10,2) Indexy SALES_CHANNEL_BIX : CHANNEL_ID SALES_CUST_BIX : CUST_ID SALES_PROD_BIX : PROD_ID SALES_PROMO_BIX : PROMO_ID SALES_TIME_BIX : TIME_ID DDL CREATE TABLE "SH"."SALES" ( "PROD_ID" NUMBER NOT NULL ENABLE, "CUST_ID" NUMBER NOT NULL ENABLE, "TIME_ID" DATE NOT NULL ENABLE, "CHANNEL_ID" NUMBER NOT NULL ENABLE, "PROMO_ID" NUMBER NOT NULL ENABLE, "QUANTITY_SOLD" NUMBER(10,2) NOT NULL ENABLE, "AMOUNT_SOLD" NUMBER(10,2) NOT NULL ENABLE, CONSTRAINT "SALES_CHANNEL_FK" FOREIGN KEY ("CHANNEL_ID") REFERENCES "SH"."CHANNELS" ("CHANNEL_ID") ENABLE NOVALIDATE, CONSTRAINT "SALES_TIME_FK" FOREIGN KEY ("TIME_ID") REFERENCES "SH"."TIMES" ("TIME_ID") ENABLE NOVALIDATE, CONSTRAINT "SALES_PRODUCT_FK" FOREIGN KEY ("PROD_ID") REFERENCES "SH"."PRODUCTS" ("PROD_ID") ENABLE NOVALIDATE, CONSTRAINT "SALES_CUSTOMER_FK" FOREIGN KEY ("CUST_ID") REFERENCES "SH"."CUSTOMERS" ("CUST_ID") ENABLE NOVALIDATE, CONSTRAINT "SALES_PROMO_FK" FOREIGN KEY ("PROMO_ID") REFERENCES "SH"."PROMOTIONS" ("PROMO_ID") ENABLE NOVALIDATE ) PCTFREE 5 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS NOLOGGING STORAGE( BUFFER_POOL DEFAULT) TABLESPACE "EXAMPLE" PARTITION BY RANGE ("TIME_ID") (PARTITION "SALES_1995" VALUES LESS THAN (TO_DATE(' :00:00', 'SYYYY- MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) PCTFREE 0 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOLOGGING STORAGE(INITIAL NEXT MINEXTENTS 1 MAXEXTENTS PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "EXAMPLE" COMPRESS, 24

25 ... PARTITION "SALES_Q4_2003" VALUES LESS THAN (TO_DATE(' :00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) PCTFREE 5 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOLOGGING STORAGE(INITIAL NEXT MINEXTENTS 1 MAXEXTENTS PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "EXAMPLE" NOCOMPRESS ) ; 25

26 Materialized View Název: FWEEK_PSCAT_SALES_MV Refresh Option: When : DEMAND Method : FORCE Enable Query Rewrite: true Indexy: FW_PSC_S_MV_CHAN_BIX -> CHANNEL_ID SQL Query FW_PSC_S_MV_PROMO_BIX -> PROMO_ID FW_PSC_S_MV_SUBCAT_BIX -> PROD_SUBCATEGORY FW_PSC_S_MV_WD_BIX -> WEEK_ENDING_DAY SELECT t.week_ending_day, p.prod_subcategory, sum(s.amount_sold) AS dollars, s.channel_id, s.promo_id FROM sales s, times t, products p WHERE s.time_id = t.time_id AND s.prod_id = p.prod_id GROUP BY t.week_ending_day, p.prod_subcategory, s.channel_id, s.promo_id DDL CREATE MATERIALIZED VIEW FWEEK_PSCAT_SALES_MV ON PREBUILT TABLE WITH REDUCED PRECISION NOCACHE NOPARALLEL BUILD IMMEDIATE USING INDEX REFRESH ON DEMAND FORCE ENABLE QUERY REWRITE AS SELECT t.week_ending_day, p.prod_subcategory, sum(s.amount_sold) AS dollars, s.channel_id, s.promo_id FROM sales s, times t, products p WHERE s.time_id = t.time_id AND s.prod_id = p.prod_id GROUP BY t.week_ending_day, p.prod_subcategory, s.channel_id, s.promo_id; 26

27 Dimension Název: PRODUCTS_DIM Hierarchie PROD_ROLLUP Úrovně CATEGORY : SH.PRODUCTS/PROD_CATEGORY_ID PROD_TOTAL : SH.PRODUCTS/PROD_TOTAL_ID PRODUCT : SH.PRODUCTS/PROD_ID SUBCATEGORY : SH.PRODUCTS/PROD_SUBCATEGORY_ID Script Output DIMENSION SH.PRODUCTS_DIM LEVEL CATEGORY IS SH.PRODUCTS.PROD_CATEGORY_ID LEVEL PROD_TOTAL IS SH.PRODUCTS.PROD_TOTAL_ID LEVEL PRODUCT IS SH.PRODUCTS.PROD_ID LEVEL SUBCATEGORY IS SH.PRODUCTS.PROD_SUBCATEGORY_ID HIERARCHY PROD_ROLLUP ( PRODUCT CHILD OF SUBCATEGORY CHILD OF CATEGORY CHILD OF PROD_TOTAL ) ATTRIBUTE CATEGORY LEVEL CATEGORY DETERMINES SH.PRODUCTS.PROD_CATEGORY ATTRIBUTE CATEGORY LEVEL CATEGORY DETERMINES SH.PRODUCTS.PROD_CATEGORY_DESC ATTRIBUTE PROD_TOTAL LEVEL PROD_TOTAL DETERMINES SH.PRODUCTS.PROD_TOTAL ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_DESC ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_LIST_PRICE ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_MIN_PRICE ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_NAME ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_PACK_SIZE ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_STATUS ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_UNIT_OF_MEASURE ATTRIBUTE PRODUCT LEVEL PRODUCT DETERMINES SH.PRODUCTS.PROD_WEIGHT_CLASS ATTRIBUTE SUBCATEGORY LEVEL SUBCATEGORY DETERMINES SH.PRODUCTS.PROD_SUBCATEGORY ATTRIBUTE SUBCATEGORY LEVEL SUBCATEGORY DETERMINES SH.PRODUCTS.PROD_SUBCATEGORY_DESC DDL CREATE DIMENSION SH.PRODUCTS_DIM LEVEL CATEGORY IS PRODUCTS.PROD_CATEGORY_ID LEVEL PROD_TOTAL IS PRODUCTS.PROD_TOTAL_ID LEVEL PRODUCT IS PRODUCTS.PROD_ID LEVEL SUBCATEGORY IS PRODUCTS.PROD_SUBCATEGORY_ID HIERARCHY PROD_ROLLUP (PRODUCT CHILD OF SUBCATEGORY CHILD OF CATEGORY CHILD OF PROD_TOTAL) ATTRIBUTE CATEGORY DETERMINES PRODUCTS.PROD_CATEGORY_DESC ATTRIBUTE PRODUCT DETERMINES (PRODUCTS.PROD_DESC, PRODUCTS.PROD_NAME) ATTRIBUTE SUBCATEGORY DETERMINES PRODUCTS.PROD_SUBCATEGORY_DESC 27