ICT

Multidimenzionální modelování v rámci analýzy a návrhu IS/ICT Vladimíra Zádová Katedra informatiky, TU Liberec, e-mail: [email protected] Abstrakt: Strukturovaný a objektový přístup jsou klasické přístupy používané pro modelování informačních systémů. Diagramy přístupů jsou navrženy pro konceptuální a technologickou úroveň modelování v rámci P3A. Oba přístupy byly navrženy pro analýzu a návrh transakčních systémů. Pro modelování BI aplikací, zejména modelování datového skladu, je užíván termín multidimenzionální modelování, výstupem jsou multidimenzionální modely. Příspěvek se zabývá vztahem multidimenzionálního modelování, resp. multidimenzionálních modelů k jednotlivým úrovním P3A uplatňovaném při vývoji aplikací. Klíčová slova: analýza, návrh, model, objektový přístup, strukturovaný přístup, multidimenzionální modelování, konceptuální úroveň, technologická úroveň, P3A, datový sklad, BI Abstract: Structured and object-oriented approaches are classical approaches used for modeling of information systems. Diagrams of these approaches are proposed for conceptual and technological levels of modeling within P3A. Both kinds of approaches have been proposed for analysis and design of transaction processing systems. For modeling of BI applications, namely data warehouse modeling, the term multidimensional modeling is used, multidimensional models being products of it. This contribution is about relationship between multidimensional modeling and multidimensional models to conceptual and technological levels within P3A applied in the analysis and design of applications. Key Words: Analysis, design, model, structured approach, object-oriented approach, multidimensional modeling, conceptual level, technological level, Principle of Different Architectures (P3A), data warehouse, BI

1. Úvod Význam informací a znalostí pro rozhodování posiluje v organizacích postavení jejich informačních systémů (IS). Nové informační a komunikační technologie (ICT) umožňují změnu kvality a postupné rozšiřování IS založeného na ICT (IS/ICT) včetně podpory vazeb vně organizace a podpory rozhodování. Aplikace (subsystémy) IS/ICT organizací jsou tvořeny aplikacemi pro podporu činností (transakčními aplikacemi) a aplikacemi pro podporu rozhodování. U aplikací pro podporu rozhodování se vžil název business intelligence (BI). V rámci BI hrají zásadní roli datové sklady. Obtížnost návrhu datových skladů je dána jejich postavením v rámci IS/ICT. I když datové sklady patří do BI, jejich podoba odpovídá nejen požadavkům managementu na procesy pro podporu rozhodování, ale také dosažitelnosti a kvalitě zdrojů dat. Úspěšnost realizace datového skladu je dána i schopnostmi návrhářů a přístupy k návrhu. Pro proces modelování datového skladu, na jehož konci je navržený model datového skladu, se vžil název multidimenzionální modelování, pro navržené modely pak název multidimenzionální modely. 66

SYSTÉMOVÁ INTEGRACE 4/2009

Multidimenzionální modelování v rámci analýzy a návrhu IS/ICT

Předkládaný příspěvek je zaměřen na multidimenzionální modelování a multidimenzionální modely pro návrh datového skladu. Hlavním cílem příspěvku je určit vztah multidimenzionálního modelování a jeho produktů multidimenzionálních modelů ke konceptuální a technologické úrovni v rámci principu tří architektur (P3A) používaného v klasických přístupech. Pro potřeby hlavního cíle jsou uvedeny multidimenzionální modely používané pro návrh datového skladu (3. kapitola) a krátce zmíněny vztahy mezi dvěma základními typy aplikací z hlediska dat a procesů (2. kapitola). Příspěvek navazuje na články [ZA1] a [ZA3] zveřejněné v tomto časopise, které jsou věnovány přístupům k analýze a návrhu IS/ICT.

2. Data a procesy v IS/ICT Jak je uvedeno v předchozí části, aplikace IS/ICT lze rozdělit na dva základní typy aplikace pro podporu činností a aplikace pro podporu rozhodování (BI). Mezi těmito dvěma typy aplikací existují vztahy, které lze z hlediska dat a procesů manipulujících s daty zjednodušeně zobrazit tak, jak je uvedeno na obr. 1.

BI aplikace OLTP

Operativní data

ETL

Datové sklady

OLAP, DM

Ostatní zdroje Obr.1 Vztahy a návaznosti mezi daty a procesy v IS/ICT Zdroj: vlastní Za ostatní zdroje jsou považovány externí zdroje a další vnitřní zdroje organizace mimo OLTP (On-line Transaction Processing, transakční systémy). Na obrázku jsou dále uvedeny dva základní zdroje dat – operativní data a datové sklady, ve způsobech zpracování jsou rozlišeny procesy OLTP, OLAP (On-line Analytical Processing), ETL procesy (Extraction Transformation Loading; Extrakce, transformace, uložení) a dolování dat (Data Mining). OLTP a operativní data tvoří jednotný celek, který je dán historicky a je z hlediska vývoje prakticky uzavřen. V případě datových skladů je třeba vidět dva základní procesy - procesy, kterými jsou získávány informace a znalosti z dat (OLAP, dolování dat) a procesy spojené s aktualizací datového skladu (ETL). Určujícím pro strukturu datových skladů je zejména OLAP, kde se jedná o analýzu ukazatelů na různé úrovni podrobnosti pro různé dimenze (operace roll-up a drill down, eventuálně drill across). Pro všechny procesy rozhodování je důležité stanovit zaměření, podrobnost a rozsah sledování (tedy jednotlivé atributy, které vyhovují požadavkům). V případě dolování dat se jedná spíše o stanovení atributů jedné úrovně hierarchie, pro OLAP jsou v dimenzích určeny atributy vytvářející více úrovní jedné hierarchie, popřípadě může dimenze obsahovat více hierarchií. K atributům na jednotlivých úrovních


67

Vladimíra Zádová

(agregační úrovně, dimenzionální atributy) mohou být stanoveny popisné atributy (vlastností atributů, nedimenzionální atributy).

3. Datové modely pro návrh datových skladů Pro návrh struktury datových skladů jsou zásadní jak modely dat datových skladů, tak modely pro ukládání operativních dat. Z modelů pro návrh datové struktury operativních dat se jedná zejména o ERA model a model tříd pro konceptuální úroveň, relační a objektově relační model pro úroveň technologickou. Tyto modely jsou třeba pro zjišťování existence zdrojů dat i kvality dat pro plnění datových skladů a návrh ETL. Multidimenzionální modely pro návrh datových skladů v současné době nejčastěji vycházejí z relačního modelu dat, nebo jsou založeny na multidimenzionální kostce. Vývojová prostředí nabízená pro řešení datových skladů, resp. aplikací BI (např. Oracle, Microsoft, Progress) jsou založena na těchto modelech. V odborných kruzích jsou uváděny objektové modely pro řešení datových skladů, objevují se XML řešení návrhu datového skladu, prozatím bez praktických aplikací. Některými autory jsou pro řešení navrhovány modely datového skladu, které zobrazují hierarchické vztahy mezi atributy sledovaných dimenzí, eventuálně i možné agregační funkce k daným faktům. Existují i úpravy modelů používaných pro konceptuální úroveň návrhu OLTP systémů ( např. uvedeno v [KOU]). Relační model dat pro návrh datového skladu Multidimenzionální model dat vycházející z relačního modelu odlišuje dva základní typy relací, které se nazývají tabulky dimenzí a tabulky faktů. Oba typy tabulek jsou databázové relace s určitými specifiky, které zohledňují cíl, pro který jsou určeny. Mohou vytvářet hvězdicové struktury (star schema), různé formy sněhových vloček (snowflake schema) a souhvězdí (constellation schema). Na následujících dvou obrázcích jsou graficky znázorněna dvě základní schémata. Obecně jsou zobrazeny jen tabulky dimenzí a tabulky faktů, nejsou uvedeny atributy, které tabulky obsahují. D2

D1

F1

D4

D3

Obr.2 Hvězdicové schéma Zdroj: vlastní

68



D2

D1

F1

D4

D3

F2

D6

D5 Obr.3 Schéma souhvězdí Zdroj: vlastní

Další možnosti návrhu schémat vycházejí z těchto dvou základních a jsou dány rozdělením tabulky faktů v souladu s hierarchií dimenzí, nebo vybudováním hierarchií jako řetězců tabulek či normalizací tabulek dimenzí daného schématu (jedné nebo více). V prvním případě vzniká souhvězdí tabulek faktů, které je speciálním případem schématu souhvězdí. Další možnost, vybudování hierarchií jako řetězců tabulek, znamená nejen rozdělení tabulek faktů, ale i rozdělení tabulek dimenzí podle hierarchií (obdobným způsobem). Tento způsob rozkladu se nazývá sněžení, tedy vytváření sněhových vloček (např. [PO1]). Normalizaci tabulek dimenzí, uvedenou jako poslední možnost, lze provádět jak ve hvězdicových schématech, tak i ve schématech souhvězdí. Hvězdicové schéma s explicitními hierarchiemi v dimenzích je v řadě publikací označeno jako schéma sněhové vločky. Multidimenzionální datový model založený na kostce Reprezentace dat datového skladu může být založena na datové kostce. Každá hrana kostky odpovídá jedné dimenzi, každý prvek v dimenzi se nazývá pozice a odpovídá hodnotě atributu v relační databázi. Prvek kostky – buňka pak vyjadřuje konkrétní hodnotu faktů vzhledem ke konkrétním hodnotám atributů dimenzí. Rozšíření sledování ukazatele o další dimenzi vede k přidání další hrany ke kostce. Obrázek 4 zobrazuje konkrétní příklad třídimenzionální kostky, která sleduje čtyři ukazatele.


69

Vladimíra Zádová

Obr.4 Multidimenzionální databáze založená na kostce Zdroj: [SAR], str.53 V multidimenzionální kostce jsou data zobrazena pomocí vícerozměrných polí, kdy každá dimenze v poli odpovídá jedné dimenzi n-rozměrné množiny dat. Obdobně jako u multidimenzionálních modelů založených na relačním modelu dat i zde existuje více typů modelů, odlišují se hyperkostky a multikostky. Modely pro podrobnější specifikaci datového skladu Postupně jsou uvedeny tři modely pro popsání vztahů mezi atributy dimenzí i požadované agregace ukazatelů. Na obrázku 5 je zobrazena tabulka faktů a tabulky dimenzí, na tuto základní strukturu navazuje další zobrazení - jednotlivých agregačních cest (spojení plnou čarou), volitelné agregační cesty (zdvojené čáry u hran). Dimenze jsou zobrazeny včetně názvu (obdélník s výplní), jsou odlišeny atributy agregačních úrovní (obdélník bez výplně) a vlastnosti atributů, vztahy mezi oběma typy atributů (spojením plnou čarou). Vlastnosti atributů jsou uvedeny vedle hrany, která je spojuje s atributem agregační úrovně, ke kterému náleží; povinnost vlastností atributu je uvedena graficky (kosočtvercem s výplní na spojovací hraně). Na obrázku k atributu agregační úrovně custId je povinně sledován atribut vlastností custName, nepovinně atribut custAge. Sledované fakty jsou spojeny s tabulkou faktů plnou čarou, jména faktů jsou uvedena vedle. Graficky není sledována agregovatelnost faktů k jednotlivým dimenzím. Agregovatelnost faktů je uváděna zvlášť – přiřazením jednotlivých úrovní omezení k těmto dimenzím.

70



Obr. 5 Grafické znázornění konceptuálního multidimenzionálního schématu Zdroj: [HLV] Na následujícím obrázku nejsou uvedeny implicitní agregační hierarchie, jednotlivé dimenze začínají od nejvyšší úrovně granularity, volitelnost cesty je označena přeškrtnutím hrany (viz vztah product-diet). Řeší přiřazení vlastnosti atributů (např. address) k jednotlivým agregačním úrovním, povinnost vlastností atributů není zaznamenána. Agregovatelnost faktů k jednotlivým dimenzím je zde vyjádřena spojením v případě neaditivity (čárkovaně), ostatní agregační funkce jsou uvedeny explicitně. Na obrázku jsou první dva fakty aditivní ke všem dimenzím, mimo součtů nebude prováděna žádná jiná agregace, poslední fakt není aditivní k dimenzi produkt, nebude prováděna ani žádná jiná agregace k této dimenzi, k ostatním dimenzím bude prováděn pouze součet.

Obr. 6 Grafické znázornění schéma faktů Zdroj: [GMR2] SYSTÉMOVÁ INTEGRACE 4/2009

71

Vladimíra Zádová

Další možný způsob zobrazení multidimenzionálního modelu, známý jako MDS (multidimenzionální doménová struktura, Multidimensional Domain Structure), je na následujícím obrázku (autor E. Thomsen). Dimenze a ukazatele sledované v rámci schématu jsou od sebe odděleny. U dimenzí jsou zobrazeny agregační cesty, u každé agregační úrovně je uveden název a počty jednotlivých instancí. Vedle jednotlivých agregačních cest dimenzí je označeno sledování ukazatelů na jednotlivých agregačních úrovních, způsob značení jednotlivých ukazatelů je uveden u jejich specifikace. Nejsou zobrazeny vlastnosti atributů.

Obr. 7 Multidimenzionální doménová struktura Zdroj: [NPS], str. 111

4. Multidimenzionální modely v rámci P3A Modelování IS probíhá ve třech etapách, které souvisí s P3A. Etapa analýzy odpovídá konceptuální úrovni, konstrukce (design) technologické úrovni, implementace fyzické úrovni. Výstupem z jednotlivých etap jsou postupně konceptuální, technologický a implementační model. Přístupy k analýze a návrhu byly navrženy, vzhledem k době svého vzniku, pro transakční systémy. Charakter datového skladu je odlišný, proto je základní otázkou, zda jsou úrovně i modely, které jsou používány pro vývoj OLTP systémů, postačující pro vývoj datových skladů. Teoreticky mohou nastat tyto základní situace: převzetí modelů a úrovní daného přístupu beze změn provedení změn do stávajících modelů vzhledem ke specifickým požadavkům návrhu datových skladů použití jiných modelů, které lépe vystihnou dimenze, fakty, budou intuitivní pro uživatele dojde k rozšíření stávajících přístupů o nové modely, eventuálně úrovně. I zde je třeba rozdělit řešení datového skladu na tři části – procesy na podporu rozhodování, datový sklad, zabezpečení datových skladů daty. Pro zachycení procesů pro kontrolu konzistence zdrojů dat a jejich transformaci do datového 72



skladu je možné použít funkční větve strukturovaného přístupu i objektový přístup. Obdobně nečiní problémy ani sledování požadavků na procesy na podporu rozhodování. Problematické je použití modelů pro vyjádření podoby datového skladu. Proto jsou výše uvedené situace analyzovány z hlediska návrhu modelu datového skladu. První možnost – převzetí modelů a úrovní přístupů beze změn - není vhodná, hlavním argumentem je to, že rozdílné cíle v IS vedou i k rozdílným požadavkům na datové modely. Podíváme-li se na specifikované požadavky pro modelování datového skladu, ke zobrazení dimenzí a faktů, hierarchií dimenzí není možné použít na konceptuální úrovni modely strukturovaného ani objektového přístupu. Uvažujeme-li datovou větev strukturovaného přístupu, která je dnes brána jako určující pro návrh datového skladu, pak pro konceptuální modelování je nejrozšířenější ERA model. Pro konceptuální modelování transakčních systémů jsou v ERA modelu dostačující prostředky pro zobrazení relevantních typů entit (objektů), typů vztahů mezi nimi a určení atributů vyjadřujících podstatné vlastnosti entit a vztahů. V konceptuálním modelu datových skladů je ale potřebné uvést jakou roli budou mít určené typy entit - mohou být dimenzemi, fakty, agregační úrovní, agregační hierarchií atp. To v základní notaci konceptuálního modelu chybí stejně jako možnost zaznamenat vztahy mezi atributy dimenzí - tedy notace pro příslušnost atributů ke stejné agregační úrovni, ke stejné agregační hierarchii, notace pro zachycení více agregačních hierarchií včetně označení implicitní hierarchie (není zřejmé jak jednoduše agregovat data). Dalším argumentem proti použití tohoto modelu je skutečnost, že byl navržen tak, aby mohl být transformován na technologické úrovni do normalizované databáze vhodné pro aktualizaci nikoli pro dotazování, pro koncového uživatele není dosti srozumitelný pro orientaci v něm [KIM]. V objektovém přístupu je situace obdobná. I když pro návrh datového skladu je možné model modifikovat - např. pro ERA model existuje notace ME-R (multidimenzionální rozšíření E-R diagramů, [KOU], str. 339), domnívám se, že není vhodné použít tyto modely pro návrh modelu datového skladu i v případě provedených změn (rozšíření o další konstrukty, eventuálně omezení pro stávající konstrukty). Důvodem je odlišný charakter procesů, pro které jsou modely entit (objektů) určeny a z toho plynoucí odlišné požadavky na jejich použití, zejména pro konceptuální úroveň. Další uvažovanou možností je použít jiný model. Multidimenzionální modely jsou vhodnými modely pro návrh datového skladu. Kladem modelů je přehlednost pro dotazování koncového uživatele, snadná orientace v modelu při analýze dalších požadavků uživatelů a snadná rozšiřitelnost modelu. V případě nutnosti lze jednoduše přidat dimenze či fakty při zakomponování dalších požadavků (samozřejmě s ohledem na granularitu). V souvislosti s použitím multidimenzionálních modelů je třeba zodpovědět, zda je vůbec nutné uvažovat o zařazení multidimenzionálního modelování do stávajících přístupů k analýze a návrhu. I když by se zdálo být vhodné použít multidimenzionální modely a řešit odděleně aplikace pro podporu rozhodování a aplikace pro podporu činností, domnívám se, že je třeba zařadit modely datového skladu do stávajících přístupů k návrhu. Za hlavní důvody považuji, že datový sklad i aplikace pro podporu rozhodování jsou integrovány do IS/ICT, možná řešení mají vazbu na zdroje dat. Dalším důvodem je i to, že modely klasických přístupů mohou být použity i pro vývoj datových skladů (např. DFD, strukturní diagram pro vyjádření konzistence zdrojů dat, jejich transformaci). SYSTÉMOVÁ INTEGRACE 4/2009

73

Vladimíra Zádová

Je-li vyřešena otázka zda zařadit multidimenzionální modely do existujících přístupů pro návrh IS/ICT, pak je třeba zařadit multidimenzionální modely v rámci P3A. V počátečním období řešení datových skladů je považována autory za nejvhodnější možnost rozšířit dosavadní přístup o další úroveň návrhu, která je zařazena mezi konceptuální a technologickou úroveň. Tím je porušen P3A, výsledná čtyřúrovňová architektura je pak následující: - konceptuální úroveň (konceptuální model) - multidimenzionální úroveň (multidimenzionální model) - technologická úroveň (technologický model) - fyzická úroveň (implementační model). V současné době se od tohoto řešení ustoupilo. Domnívám se, že v rané fázi nebyl vzat v úvahu charakter úrovní v rámci P3A. Klasické úrovně je třeba ponechat, poněvadž i v analýze a návrhu datových skladů se řeší obsah, technologie a implementace, které odpovídají konceptuální, technologické a fyzické úrovni, jen odlišnost charakteru procesů vede k jiným požadavkům na zachycení řešení. Není-li multidimenzionální modelování další úrovní, pak je třeba zařadit multidimenzionální modely v rámci řešení P3A. Konceptuální úroveň a multidimenzionální modelování Pro modely na konceptuální úrovni je vhodné vycházet z multidimenzionálních modelů založených na relačním modelu dat. Tyto modely jsou přehledné i pro uživatele (což je pro návrh datových skladů zásadní), jejich přehlednost není výrazně omezena počtem sledovaných dimenzí. Základními modely jsou v této úrovni hvězdicové schéma a schéma souhvězdí. Pro řešení datového skladu je možné zachytit model datového skladu jako schéma souhvězdí, kde jsou zobrazeny jen fakty ke sledování a uvedeny dimenze, na jemnější rozlišovací úrovni pak uvést v rámci modelu pro každou dimenzi atributy dimenzí (bez zachycení vztahů mezi jejími atributy). Tato úroveň podrobnosti je poslední úrovní, na které je možné zobrazit model sledující vztahy mezi fakty a dimenzemi celého datového skladu. V další úrovni detailu, zobrazení hierarchií v rámci dimenzí a agregovatelnosti faktů, je třeba provádět řešení po jednotlivých částech (většinou odpovídajících hvězdicovému schématu) pomocí modelu např. uvedených na obr. 5, 6, 7. Pro konceptuálně čistý návrh by bylo vhodné vycházet i z konceptuálního modelu zdrojů dat – tedy ERA modelu či diagramu tříd, eventuálně z DFD, diagramu užití aj. (dle situace). Přístup k návrhu datových tržišť pro datový sklad vycházející z ERA modelu zdrojových dat je uveden v [GMR1], [BCF1]). Tento způsob řešení nemusí být proveditelný – konceptuální modely (ať již strukturované či objektově orientované) na této úrovni nemusí být k dispozici vůbec, nebo nemusí být aktualizovány při změnách aplikací. Technologická úroveň a multidimenzionální modelování Multidimenzionální modely založené na relačním modelu dat, popřípadě další multidimenzionální modely (např. založené na XML, objektové modely) je možné použít pro technologickou úroveň návrhu. Tato úroveň se již musí zabývat vhodným způsobem uložení z hlediska požadavků procesů pro podporu rozhodování, rychlosti odezvy - tedy modely použité na této úrovni mohou být i normalizovány (v případě schémat založených na databázové relaci), popřípadě bude upřednostněn návrh hyperkostky či multikostky. Transformace modelů 74



z konceptuální úrovně do technologické úrovně závisí i na analýzách požadavků vyjádřených pomocí agregačních vzorů. Použití modelů na této úrovni záleží i na vývojovém prostředí, které je dostupné pro řešení. Při návrhu datového skladu není porušen P3A, multidimenzionální modely jsou součástí jednotlivých úrovní architektury. Transakční systémy, které jsou zdroji dat pro datové sklady, mohou být řešeny pomocí modelů strukturovaných přístupů i objektových přístupů. To je hlavní důvod proč je třeba integrovat modely obou přístupů pro analýzu a návrh IS/ICT do jednoho celku spolu s multidimenzionálními modely pro návrh BI aplikací. Řešení není obtížné – i v těchto přístupech je respektován P3A. V případě návrhu datového skladu se zcela jasně objevuje vhodnost použít Business Rules přístup (blíže [ZA3]) – pomocí pravidel lze formulovat dimenze, fakty, atributy, modelovat vztahy. Tento přístup zajistí jeden ze základních požadavků na datový sklad - jednu verzi pravdy. Použití prostředků pro analýzu a sledování pravidel je tedy vhodné nejen k řešení aplikací pro sledování procesů, ale pro řešení všech aplikací.

5. Závěr Z předchozí části článku vyplývá, že na multidimenzionální modelování se je třeba dívat jako na proces pro návrh datového skladu, jehož výstupy, jednotlivé modely, nepatří do jedné úrovně v rámci P3A, ale souvisí s konceptuální a technologickou úrovní. To podporují i návrhy konceptuálních modelů publikované na konferencích či uvedené v odborných časopisech. Z porovnání zde uvedených konceptuálních modelů na větší úrovni podrobnosti je patrné, že ačkoliv zobrazují vztahy mezi jednotlivými atributy dimenzí, atributy dimenzí a fakty i agregační funkce, liší se v konstruktech pro zobrazení, liší se i v tom co zobrazují. Na porovnání těchto modelů z hlediska potřebných konstruktů pro vyjádření jednotlivých vztahů a jejich úplnosti bych ráda zaměřila další článek.

Literatura [BCF1] Bonifati, A., Cattaneo, F., Ceri, S., Fuggetta, A., Paraboschi, S.: Designing Data Marts for Data Warehouse; ACM Transactions on Software Engineering and Methodology, Vol.10, No.4, October 2001 [GMR1] Golfarelli, M., Maio, D. Rizzi, S.: Conceptual Design of data warehouses from E/R schemes, Proc. 32 th HICSS 1998 Proceedings 31st Hawaii. International Conference on System Sciences (HICSS-31), vol. VII, Kona, Hawaii, pp. 334-343, 1998. [GMR2] M. Golfarelli, D. Maio, S. Rizzi. The Dimensional Fact Model: a Conceptual Model for Data Warehouses. International Journal of Cooperative Information Systems, vol. 7, n. 2&3, pp. 215-247, 1998 [HLV] Hüsemann, B., Lechtenbörger, J., Vossen, G.: Conceptual Data Warehouse Design,In Proceedings of the International Workshop on Design and Management of Data Warehouses, DMDW, Stockholm, 2000, čl.6 [KIM] Kimball, R. a kol.: The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses, John Wiley & Sons, 1998;ISBN 0-471-25547-5 SYSTÉMOVÁ INTEGRACE 4/2009

75

Vladimíra Zádová

[KOU] ařík, V. a kol:. Umělá inteligence (4), Academia 2003, kap. 10 Datové sklady a získávání znalosti (Kouba, Z.) str. 313-354 [NPS] Novotný, O., Pour, J., Slánský, D.: Business Intelligence. Jak využít bohatství v datech, Grada, Praha, 2005, ISBN 80-247-1094-3 [PO1] Pokorný, J., Sokolowsky, P: A Conceptual Modelling Perspective for Data Warehouses, Electronic Business Engineering, 1999, str. 666-684 [PO2] Pokorny, J.: XML Data Warehouse Possibilities and Solutions, In: Constructing the Infrastructure for the Knowledge Economy: Methods & Tools, Theory & Practice. H. Linger et al (Eds), Kluwer Academic Publishers, Dordrecht, The Netherlands, 2004, pp. 531-542 [REP] Řepa, V.: Analýza a návrh informačních systémů, Ekopress, Praha, 1999, 1. vydání ISBN 80-86119-13-0 [SAR] Šarmanová, J.: Datové sklady a dolování znalostí z nich, VŠB – Technická univerzita Ostrava, Regionální centrum celoživotního vzdělávání, 2003, ISBN 80- 248- 0302-X [ZA1] Zádová, V.: Strukturovaný versus objektový přístup v oblasti analýzy a návrhu. Časopis Systémová integrace č. 3/2002, str. 117 - 137, ISSN 1210-9479 [ZA2] Zádová, V.: Specifika postavení a návrhu datových skladů v rámci IS/ICT,[disertační práce] Liberec 2006 [ZA3] Zádová, V.: Business Rules přístup v návrhu informačních systémů. Časopis Systémová integrace. č.2/2008, s. 20 – 30. ISSN 1210-9479

76


ICT

Recommend Documents