Hvězda - multidimenziální datová struktura v praxi. Jiří Horák

Transkript

1 Hvězda - multidimenziální datová struktura v praxi Jiří Horák

2 Relační datový model Nahlíží na data v databázových relacích Řádky tabulky odpovídají jednotlivým výskytům entit Sloupce reprezentují atributy entit Každý atribut odpovídá 1 vlastnosti Požadavek normalizace dat Vybírají se atomické popisné hodnoty z 1 domény

3 OLTP systémy On-line transaction processing Běžné transakce - typicky údržba aktuálního stavu jisté evidence: Ekonomická situace (zákazníci aktuální kontaktní údaje, objednávky doručené, vyřizované, výrobky aktuální) Informační systém o území (aktualizace geometrie a vlastností silniční sítě, aktuální názvy ulic, poslední evidence obyvatel, aktuální užití a pokryv krajiny, zemědělská a lesnická produkce) Dopravní systém (aktuální stav komunikační sítě, řídících prvků, aktivních agentů) Vodohospodářský systém (kolik a kde prší, předpověď, aktuální průtok, stav regulačních prvků)

4 Požadavky na zpracování? Dominují: aktualizační transakce (UPDATE, INSERT) zpravidla 1.řádek jednoduché dotazy (jak se jmenuje toto místo, vyber silnice 1.třídy) = selektivní dotazy Paralelní přístup více uživatelů (s editačními právy) Velký počet požadavků

5 Co s historickými daty? Neplatná data se odstraňují ze systému a archivují Žijeme současností, k historii se málo vracíme Jednoduché datové struktury pro současnou situaci (je jasné co je parcela, co je trvalý pobyt občana, co znamená míra nezaměstnanosti) => pro většinu praktických úloh není potřeba příliš data popsat (popis sémantiky dat) Jakmile však chceme studovat historii a nechat ji, aby nás poučila, narážíme na řadu problémů

6 Překážky analýzy dat v běžné db Normalizace dat (mnoho malých tabulek s elementárními údaji) Slabá podpora SQL pro požadované operace např. třídění se provádí až po provedené relační operaci, slabé agregační funkce např. nelze jednoduše srovnat danou hodnotu s agregovanou, slabé statistické funkce, chybí podpora zpracování časových řad, měření blízkosti apod. Přetížení systému velkým počtem běžných požadavků (+ zamykání) Nedostatečné techniky indexace dat

7 Překážky plnohodnotného uložení cenných dat Nelze zapsat metadata ke každému údaji Víte, jak se měřilo? Jak uložit hodnoty pod detekční limit (<2 ppm, st. )? Jak zapsat neurčitost spojenou s těmito údaji?

8 A nepořádek Chyby, opomenutí, nedůslednosti jsou uloženy v db a petrifikovány Co nevadilo při běžné práci se může projevit při analýze Víte, jaká je cena dat? Jak chcete provádět hlubší analýzu těchto dat? Cítíte-li tyto problémy, založte si

9 DATOVÝ SKLAD aneb data warehousing

10 Co je datový sklad? značně frekventovaný pojem někdy intuitivně pro označení rozsáhlého úložiště dat varianty chápání datového skladu: 1. datový sklad ve smyslu organizovaného, jednotného a integrovaného úložiště dat 2. datový sklad typu warehouse, analytický datový sklad, integrace dat z transakčních databází, jejich agregace a uložení v multidimenzionálních strukturách, optimalizace z hlediska dotazování a analýzy dat. 3. datový sklad používaný pro ukládání originálních dat v primární podobě ve formě multidimenzionální struktury především s cílem vytvoření centrálního úložiště spřesným popisem originálních dat. Jde tedy o transakční systém s multidimenzionální strukturou

11 Dimenze zde není spojena s prostorem Pojem dimenzionalita, resp. multidimenzionální struktury není chápán jako prostorový jako dimenze se nepoužívají prostorové souřadnicové osy, ale popis faktorů, které data ovlivňují a zajímají nás z hlediska analýzy

12 Datový sklad I.typu Integrovaná, sjednocená, verifikovaná data v jednotném prostředí

13 Datový sklad I.typu Cílem je provádět transformaci originálních dat způvodních míst uložení (ze samostatných informačních systémů), odstínit rozdíly v datech, provést jejich sjednocení, standardizaci, uložení a zpravidla i zpřístupnění v jednotném prostředí (resp. prostředí s jednotným, standardním přístupem). Zpravidla centralizované řešení (může být ovšem i distribuované, avšak s jednotnou logickou a metodickou částí). Tento typ datového skladu neprovádí agregaci dat (ve smyslu ukládání pouze sumarizovaných či jinak agregovaných prostorových dat)

14 Datové sklady GIS veřejné správy Datový sklad Vodstvo ČR Datový sklad CENIA datový sklad Informačního systému osilniční a dálniční síti České republiky datový sklad IDC ÚHÚL datové sklady GIS měst, krajů apod.

15 Charakteristika Jsou zaměřeny na centrální skladování a poskytování dat sjednocených z původních zdrojů např. importy dat ZABAGED pro konstrukci DMT (IDC UHUL) Studie metainformačního systému MEDIS ŽP také hovoří o datovém skladu s konzolidovanými, agregovanými daty

16

17 Upravené pojetí Někdy označení pro databázová řešení, kde jsou vrelační či objektové databázi uložena i geometrická data (především jde o prostorová rozšíření relačních SŘBD). není zřejmé, zda se ukládají originální nebo upravená, integrovaná data Někdy je transformace chápána jako jednorázová a ne jako proces zachovávající originální data a systémy. Následně slouží vytvořený datový sklad přímo pro transakční operace.

18 Datový sklad II.typu Data warehouse

19 Datový sklad II.typu Datový sklad (data warehouse) představuje architekturu, obvykle založenou na relačním SŘBD, která se používá pro údržbu historických dat získaných z databází operativních dat, která byla transformována, sjednocena a zkontrolována před jejich použitím v databázi datového skladu nepoužívá přímo data získaná při běžných transakcích, provádí se jejich selekce, vyčištění a agregace podle vhodných kritérií Cíl - uložit vyčištěná a integrovaná data pro zefektivnění následující analytické a statistické práci s daty historická data, v některých případech i externí

20 Proč se používá Odvozené informace slouží pro podporu rozhodování s využitím specifických technik dolování dat (typický nástroj datových skladů) nebo v navazujících systémech typu OLAP OLAP (On Line Analytical Processing) - technologie pro zpracování dat z databáze na serveru (datovém skladu) s využitím velkého množství kladených dotazů Pravidla pro OLAP Typické OLAP operace: Drill-down Roll-up Slice-and-dice Pivot

21

22 Realizace relační databázové modely s odpovídající multidimenzionální strukturou (systémy ROLAP) speciální multidimenzionální databáze, které multidimenzionální struktury podporují nativně (místo uložení dat v relačních tabulkách aplikují zpravidla vícerozměrná pole, známá z programovacích technik) a mají k dispozici specializovaný multidimenzionální SŘBD Realizace v RMD těžkopádná normalizované tabulky. Lépe v multidimenzionální kostce, i když je řídce obsazena

23 Multidimenzionální struktura dimenze a fakta

24 Dimenze reprezentují jednotlivé aspekty, podle kterých jsou organizována fakta a podle kterých došlo k agregaci dat. Na jejich základě se provádí analýza agregovaných dat. Dimenze mají zpravidla hierarchickou strukturu. Jednotlivé prvky hierarchie se pak používají k seskupování dat (faktů). V klasických ekonomických aplikacích je vždy přítomna ekonomická dimenze a čas, další dimenze se již navrhují s ohledem na preference uživatelů. Může to být dimenze výrobků, zaměstnanců, zákazníků, ale také geografická dimenze.

25

26 Fakta představují agregované hodnoty, které jsou zajímavé pro rozhodování. obvykle jsou numerická a měřitelná. získávají se opakovaně Granularita - určuje úroveň podrobnosti faktů. Závisí na úrovni podrobnosti dimenzí. Vysoká granularita znamená uložení dat v nízkém stupni agregace (např. údaje za sčítací obvody), tedy s velkým detailem dat. Aditivita faktů = vlastnost určující, zda je možné fakta sumarizovat podle dimenzí (aditivní podle všech d., semiaditivní, neaditivní atributy)

27 Základní varianty MDDS Hvězdy a souhvězdí Sněhové vločky Hyperkostky, krychle Rozlišování explicitní a implicitní hierarchie u dimenzionálních tabulek

28 Hvězda, hvězdicové schéma Datum

29 Hvězda a souhvězdí Hvězda = 1 tabulka faktů obklopená dimenzionálními tabulkami, mezi kterými nejsou funkční závislosti Vtabulcefaktů jsou uložena fakta spolu s klíčem tvořeným kombinací identifikátorů všech dimenzí (tedy z cizích klíčů). Na ní jsou napojeny tabulky dimenzí, které popisují vlastnosti vždy 1 dimenze. Souhvězdí (galaxie) = schéma s více hvězdami, které sdílejí některé dimenzionální tabulky

30

31 Souhvězdí

32 Implicitní a explicitní hierarchie Implicitní hierarchie přímo v tabulce dimenze (není normalizovaná) Explicitní hierarchie hierarchický řetěz tabulek v dimenzi (obec okres kraj NUTS2 stát) Oboje má své výhody Vícenásobné hierarchie např. více paralelních větví v hierarchii. Např. obec okres/obec s rozšířenou působností kraj (ORP není skladebná do okresu)

33 Explicitní hierarchie

34 Další strukturování dat pro zlepšení zpracování Rozdělení tabulky faktů dle úrovně agregace v souladu s hierarchií dimenze - souhvězdí tab.faktů Vedle rozdělení tab. Faktů se provede rozdělení i jednotlivých dimenzionálních tabulek podle hierarchie sněžení, tvorba sněhových vloček

35 Explicitní hierarchie v souhvězdí tab.faktů

36 Sněžení

37 Hyperkostka

38

39 Návrh datového skladu II. typu GIS statistiky: úřady práce a SSZ MPSV ČR

40 Implementace nástrojů prostorové analýzy trhu práce v činnosti úřadů práce export z OKpráce (v3.3) GIS statistiky nové šablony - ŠablonaGIS0-GIS3.xls, obce, mikroregiony Soustava ukazatelů vhodných pro popis situace na trhu práce 34 primárních údajů a agregovaných za obce nebo městské části (resp. obvody) a 34 ukazatelů dnes nové šablony, 142 primárních údajů, podobný počet ukazatelů ukazatelé - zpravidla podíly vybrané skupiny uchazečů na celkovém počtu uchazečů, případně žen

41 List OKpráce

42 List Ukazatelé

43 Hvězda s částečnou externí hierarchií

44 Tab. faktů

45 Způsob definice ekonomické osy

46 Realizace v SPSS

47 Vhodnost této struktury pro SPSS Způsob práce v SPSS přímo zvýhodňuje uložení sledovaných fakt do 1 sloupce: počínaje tvorbou výběrů, až po generování statistik hromadně dle dalších atributů Pivoting výsledné statistiky (změna dimenzí) OLAP kostky

48 Výhody takové organizace dat 10 Nová Plán 8 6 Nové H Žaben Slezské Rudoltice Býkov-Láryšov Velká Štáhle Staríc Detrichov nad BystricíNová Plán Karlova Studánka Bílá Nošovice Paskov Nová Plán Nová Plán Slezské Pavlovice Nová Plán Komorní Lhotka Trinec Herma Zmn Zpc0024_u Zpce12_u Zpcvabc_u Zpc5099_u ZPPMEA ZPPSS ZRPML ZMPSS ZVYJEA

49 Box - ploty průměrné mzdy

50 Porovnání mzdy a míry nezaměstnanosti v roce 2001 Minimum Maximum Mean Std. Deviation w01 iu , , ,71 8, ,980 3,95418

51

52 Definice OLAP kostky

53 Výběr statistik uložených v buňce (resp. další dimenze)

54 Vytvoření OLAP kostky

55 Využití pivotingu

56 Výsledky Agregace pro rok x měsíc Výběr obcí, ukazatelů

57 Diskuse k realizaci geografické osy Je potřebné registrovat změny průběhu hranic a další drobné geometrické úpravy? Jak je napojit na stavovou topologii geografické databáze? drobné geometrické změny hranic zřejmě neovlivní socioekonomickou situaci => Popisovat změny pouze na základě příslušnosti malých územních jednotek do sledovaných celků (popsat územní změnu změnou příslušnosti katastrálního území, sčítacího obvodu, základní sídelní jednotky do daného celku např. zde obce) S tím spojená otázka volby vhodné granularity uložených údajů Pokud není možné ukládat data pro menší územní jednotky, zajistit alespoň externě jejich přepočty na standardizované jednotky např. OkrBruntál96 (tj. území okresu Bruntál po ) Vzniká jednodušší a robustnější systém, kdy k prostorové lokalizaci budeme používat pouze geokódy

58 Doporučení k realizaci geografické osy Používat implicitní definici hierarchie, tj. v nenormalizované podobě. Zde vyjádřit aktuální příslušnost sledované územní jednotky do vyšších územních celků a označit číslo verze Součástí klíče se stává číslo verze (do tabulky faktů se pak musí také zapsat) Lze provádět samostatné agregace dle jednotlivých úrovní hierarchie (vhodné kontrolovat počet členů agregace) s ohledem na verzi (období platnosti). Pro agregaci na elementární úrovni potřebujeme externí přepočty, jestliže si verze dané jednotky neodpovídají. Kod Obec Okres Kraj verze platnost Huzová Bruntál MSK Moravský Beroun Bruntál MSK Norberčany Bruntál MSK Huzová Olomouc OLK Moravský Beroun Olomouc OLK Norberčany Olomouc OLK

59 Datový sklad III.typu Multidimenzionální, ale pro transakce (operativní data)

60 Motivace Hlavní motivací pro vytváření multidimenzionálních datových struktur pro ukládáních originálních, transakčních dat je schopnost dobře vystihnout faktory evidence a významu ukládaných dat Vhodné vysvětlení podává jedna z definic multidimenzionálního modelování (Kimball 2003): Dimensional modeling begins by dividing the world into measurements and context. Measurements are usually numeric and taken repeatedly. Facts are always surrounded by mostly textual context that's true at the moment the fact is recorded.

61 Side efect V případě řídkých matic (slabě obsazené tabulky) jde o efektivní formu uložení dat Neukládají se prázdné hodnoty v atributech, ale jen atributy s neprázdnou hodnotou Sada děravých (parciálních) atributů se převede do 2 sloupců hodnota + identifikátor atributu - a ukládá se jako samostatné řádky

62 Řešení sémantických problémů na tyto problémy poukazuje řada teoretických prací a zabývá se jím i několik evropských projektů (např. HarmonIT). nepokoušíme se unifikovat data při jejich sběru, ale snažíme se, aby při pořizování dat byla tato zapsána vprimární, co nejméně změněné podobě současně se zapisuje řada metadat, která umožňují následné správné využití dat Data jsou uložena v datovém skladu s multidimenzionální strukturou - umožňuje zapisovat měřená data s plnými metadaty, popisujícími kdy, kde, co a jak bylo měřeno

63 Problém sémantiky na příkladu Definice atributu se mění s : Časem Územím Národní specifika Souhrnně: rozdílná metodika pro daný atribut Např. míra nezaměstnanosti rozdíly ve způsobu započítávání jak nezaměstnaných tak především ekonomicky aktivních. Odhaduje se, že skutečná míra nezaměstnanosti proti registrované je cca o 1% vyšší (VŠPS x ÚP). Započítávání skupin jako ženy na mateřské dovolené, nemocní, vojáci, studenti v souběhu s praxí, atd. Rozdílný způsob výpočtu MN pro okresy (vyhlazení předchozími hodnotami). Jak moc to vadí? Záleží na účelu a zájmu analytika.

64 Jiný příklad Množství atmosférických srážek [mm]: Čas historie (změřeno) x budoucnost (předpovídáno) Metody pro měřené srážkoměrné stanice (a jaký typ), radarové odhady, adjustované radarové odhady. Metody pro predikované ALADIN, GFS V 1 vrstvě a časovém řezu je můžeme kombinovat s cílem získání více lokalizovaných hodnot v území pro lepší interpolaci (je ovšem vhodné interpolaci provádět s ohledem na jinou neurčitost těchto dat) Dokonce tam můžeme použít i data odvozená např. z časové řady při výpadku daného měření na stanici (vhodnější pro více kontinuální jevy jako je spíše průtok)

65 Multidimenzionální sklad pro TRANSCAT DSS (databáze Cassiopeia) sestava dimenzí zahrnuje: Objekt (kde se měří) atribut (co se měří) metoda (např. identifikace analytické metody) (jak se měří) jednotka měření kvalifikátor (=, >,<, stopy apod.) čas (datum a čas) hodnocení neurčitosti datová sada (potřebné kvůli vazbě na plná metadata, copyright) klasifikační schéma (v případě ukládání kódů hornin, typů vrstev, půdy, vegetace, apod.) zdroj Jazyk Výhody a nevýhody: + data zachována v podobě, která by neměla omezovat budoucí využití + přístup aplikace k datům -relativně málo srozumitelná - málokdo je ochoten to všechno vyplnit

66

67 Realizace

68 Čím se liší tento typ skladu? Nejsou to integrovaná a sjednocená data Nejsou to agregovaná data Neslouží přímo pro analýzy, ale pro uložení dat Nejsou to jen číselná data - ukládá se text Výhody textu: originální zápis čísel (ale těžkopádná realizace integritních omezení) - např. zápis 2,00 určuje přesnost na 2 desetinná místa, nebo zápis jako výsledek stanovení Ukládání jazykových variant textů (včetně kódování)

69 Ukázka multijazyčnosti

70 Uplatnění multijazyčnosti v klientovi

71 Další krok Multidimenzionální databáze operativních dat je velmi těžkopádná pro analýzy a dotazy Vhodné generovat sekundární tabulky či odvozené informace a provádět přitom integraci a standardizaci dat (použití stejných jednotek, stejné metodiky u atributů (přepočty), interpolace apod.)

72 Závěrem

73 LITERATURA (dat.sklady II.typu) Pokorný J.: Konstrukce databázových systémů. ČVUT 2004 Groff, Weinberg: SQL. Kompletní průvodce. Computer Press Berka P.: Dobývání znalostí z databází. Academia Mark Humphries a kol.: Data warehousing návrh a implementace. Computer Press, 2002, ISBN

74 Literatura k dat. skladům I.typu Ing. Marek Mlčoušek, Ing. Josef Fryml, Ing. František Šach, CSc. : Datový sklad IDC ÚHÚL Brandýs nad Labem - poskytování dat o lese prostřednictvím internetových a mobilních technologií. GIS Ostrava 2004 Vladimír Maršík: Využití standardů OpenGIS při návrhu architektury GIS Krajského úřadu. GIS Ostrava Bukáček: GIS Brno CORBLEY Kevin: V Evropě nejrozsáhlejší GIS pro užití v evidenci nemovitostí: Německá dráha vede prostorová a atribuční data v jediném systému. VÚGTK,