4IT450 Podpora CASE při vytváření databází

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky 4IT450 Podpora CASE při vytváření databází Závěrečná práce týmu CASE jaro 2011 Tým Jana Svitalská (vedoucí týmu) Timur Nigmatullin Radim Klepetko Julie Koroleva Petr Varadinov Roman Lelek Artur Kashapov Datum odevzdání

2 Obsah 1 ÚVOD 4 2 VYBRANÁ FUNKČNOST DATABÁZOVÝCH NÁSTROJŮ CASE FORWARD ENGINEERING TRANSFORMACE MODELŮ GENEROVÁNÍ DDL SKRIPTU PARAMETRY TÝKAJÍCÍ SE VELIKOSTI DATABÁZE REVERSE ENGINEERING ZPŮSOBY GENEROVÁNÍ MODELU PROSTŘEDNICTVÍM RE MOŽNOSTI RE OMEZENÍ RE EXPORT DOKUMENTACE RTF DOKUMENTACE HTML DOKUMENTACE VALIDACE MODELU MOŽNOSTI VALIDACE PRAVIDLA DATOVÉHO MODELOVÁNÍ OBCHODNÍ PRAVIDLA PODPORA TÝMOVÉ PRÁCE REPOSITORY KOLABORACE VERZOVÁNÍ BEZPEČNOST PODPORA TVORBY DIMENZIONÁLNÍCH DATABÁZÍ PODSTATA MULTIDIMENZIONÁLNÍCH DATABÁZÍ NÁVRH FAKTOVÝCH A DIMENZIONÁLNÍCH TABULEK NÁVRH OLAP KOSTEK METADATA DIMENZIONÁLNÍHO MODELU 27 3 VYBRANÉ DATABÁZOVÉ NÁSTROJE CASE ERWIN DATA MODELER (COMPUTER ASSOCIATES) ENTERPRISE ARCHITECT (SPARX SYSTEMS) INFOSPHERE DATA ARCHITECT (IBM) POWERDESIGNER (SYBASE) SQL DEVELOPER DATA MODELER (ORACLE) 35

3 3.6 ER/STUDIO DATA ARCHITECT 36 4 ZÁVĚR 37 5 POUŽITÁ LITERATURA 37 3

4 1 Úvod Návrh databáze je složitý iterační proces, který je však možno automatizovat pomocí moderních nástrojů CASE. Pod zkratkou CASE se skrývá sousloví Computer Aided Software Engineering, jedná se tedy o počítačem podporované softwarové inženýrství. Tato semestrální práce se zaměřuje na nástroje CASE pro návrh databází, které jsou v textu někdy také označovány jako databázové nástroje CASE. Touto problematikou se zabývaly již dvě semestrální práce vytvořené v rámci kurzu 4IT450. První z nich (Filippi et al., 2009) popisuje tři významné nástroje CASE v této oblasti (Oracle Designer, Toad Data Modeler a Sybase PowerDesigner). Druhá z nich (Potančok et al., 2010) zkoumá čtyři vybrané nástroje CASE z hlediska úrovní návrhu v rámci tzv. principu tří architektur. Zaměřuje se zejména na funkčnost těchto nástrojů, která se týká datového modelování. Tato práce má za cíl přinést jiný pohled na tuto oblast nástrojů CASE. Cílem práce je popsat významnou funkčnost 1 těchto nástrojů a srovnat vybrané nástroje z hlediska této funkčnosti. Předmětem a tedy ani cílem této práce není poskytnout vyčerpávající přehled 2 funkcí a nástrojů CASE pro tvorbu databází, spíše je cílem poskytnout pohled na tyto nástroje z hlediska možných a nejpoužívanějších funkcí, které podporují životní cyklus vývoje databází, na konkrétních příkladech nástrojů CASE. V práci je nejdříve analyzována funkčnost databázových nástrojů CASE. Funkce byly vybrané na základě předchozí analýzy databázových nástrojů CASE a to zejména dle jejich přítomnosti ve více nástrojích a dle relevantnosti a užitečnosti pro tvorbu databází. Vybraná funkčnost se tedy objevovala ve více nástrojích CASE, na základě čehož je možno usuzovat, že je její používání časté, nebo je výjimečná pro určitý nástroj, ale zdá se být natolik sofistikovaná a užitečná, že je zmíněna. Druhou část pak tvoří popis vybraných nástrojů CASE, ze kterých vychází první část. Výběr těchto nástrojů spočívá zejména na dodržení dvou základních charakteristik nástrojů CASE kvalitní grafické rozhraní umožňující tvorbu diagramů, modelů a grafů a přítomnost repositáře (úložiště) pro efektivní řízení 1 Funkčností je v práci rozuměn soubor funkcí a možností, které jsou nějakým způsobem praktické či vhodné pro vývoj databázových aplikací 2 Např. datové modelování zde je jen probíráno z hlediska multidimenzionálního modelování, na tomto místě odkazujeme na předchozí práci (Potančok et al., 2010), která tuto funkčnost popisuje dostatečně.

5 vývoje a jeho kontrolu (Agarwal, 2010). Druhým výběrovým kritériem pak je možnost tvorby datových modelů a používání dalších funkcí s tvorbou databází souvisejících. 2 Vybraná funkčnost databázových nástrojů CASE Nástroje CASE umožňují zrychlit, usnadnit a automatizovat vývoj databází a pomáhají také zlepšovat kvalitu již vytvořených databází. Zaměřují se zejména na fázi analýzy a návrhu a menším dílem i na fázi testování. Pomáhají vizualizovat a zpřehledňovat návrh databází. Díky automatizovaným funkcím navíc redukují množství manuálních chyb (Teorey, 2005) Nejstěžejnější funkci těchto nástrojů představuje možnost datového modelování, kdy je možno snadno prostřednictvím uživatelsky přívětivého grafického rozhraní vytvářet tabulky, indexy, procedury, pohledy, triggery a další objekty. Kromě toho lze i modelovat různé vztahy mezi těmito objekty, vznikají tak normální formy, cizí klíče a různé typy vztahů (dědičnost, agregace, kompozice atd.). Výsledkem jsou potom modely např. ve formě ER diagramu, které je možno dále detailněji specifikovat a následně odvodit i skripty pro vytvoření databáze. Jak již bylo výše uvedeno v poznámce, funkčnost datového modelování je v této práci popisována jen z hlediska multidimenzionálního modelování a na tomto místě odkazujeme na dostatečný zdroj týkající se této problematiky (Potančok et al., 2010). Níže následuje popis vybraných funkcí a vlastností databázových nástrojů CASE, které jsou dokládány často praktickými ukázkami z prostředí některých nástrojů. 2.1 Forward Engineering Jedna z nejvíce užívaných funkcí každého dobrého modelovacího nástroje zahrnuje tzv. forward engineering (dále jen FE ). FE v obecném pojetí znamená technologický postup tvorby programového kódu nebo databáze z diagramu abstraktního modelu (Beneš, 2008). V běžné praxi se tedy jedná o převedení neformálních požadavků do formálnější specifikace v podobě různých diagramů, ze kterých se pak odvozuje programový kód nebo databáze. Z hlediska databázového nástroje CASE potom tato funkcionalita představuje možnost generovat všechny potřebné skripty pro vytvoření fyzické databáze na cílový server. Jedná se tedy o tradiční proces přechodu od vysoké úrovně abstrakce, přes logické návrhy databáze až k její fyzické implementaci (Garg, 2009). 5

6 FE je základním stavebním kamenem modelem řízené architektury (Modeldriven architecture, dále jen MDA ). Myšlenkou MDA je provedení návrhu jednotlivých částí systému do příslušných diagramů, které jsou díky své vizuální podobě a znázorněným vazbám lépe čitelné a je tak snazší i rychlejší s nimi pracovat. Tento koncept tak umožňuje standardizovat modely a dále definuje způsob transformace jednoho modelu v druhý (Šveřepa, 2004). FE přístup umožňuje platformní nezávislost návrhu systému. Nejdříve jsou vytvořeny diagramy, které reflektují aktuální požadavky, a později se rozhoduje o jejich fyzickém provedení. Systém je tak přenositelný mezi různými platformami. FE tak umožňuje přímé použití diagramů modelu při realizaci daného systému tak, že je zpracuje buď přímo do kódu zvoleného programovacího jazyka, nebo do diagramů s nižším stupněm abstrakce logicky navazujících v procesu vývoje daného systému. Tyto činnosti není tedy nutné ručně opakovat vývojářem, pouze vždy na každé úrovni zapracovat konkrétní zpřesnění modelu podle stupně abstrakce. Přínosem tohoto přístupu je rychlá tvorba výchozího modelu a automatizovaný postup až ke zdrojovému kódu. V případě generování zdrojového kódu databáze hovoříme spíše o generování kostry výsledné databáze, která odráží zejména modelované vazby a datové typy, nicméně samotný funkční kód je nutno doplnit programátorem Transformace modelů Předpokladem správného návrhu databáze přístupem shora-dolů (top-down přístup) je zachování konzistence mezi modely různé úrovně abstrakce. Většina nástrojů CASE respektuje tzv. princip tří architektur, kdy je možné postupovat od konceptuálního návrhu, který pak je doplňován technologickými specifiky a následně převeden do fyzické realizace databáze. Nástroje CASE tak umožňují vytvářet konceptuální, logické a fyzické modely. 3 Názvosloví těchto modelů se však může v jednotlivých nástrojích lišit (např. logický model je omezen u nástroje SQL Developer Data Modeler jen na technologii relačních databází a tak je i nazýván relačním) a ne vždy jsou všechny podporovány (jen PowerDesigner z námi zkoumaných nástrojů podporuje všechny tři úrovně návrhu). Při převodu modelu vyšší úrovně abstrakce do detailnějšího modelu je možno vybrat jen některé objekty, které jsou pro následný model relevantní. Nástroj CASE pak sám vytvoří potřebné cizí klíče, příp. vazby M:N převede do referenční tabulky (za předpokladu relačního návrhu). Entity v konceptuálním modelu se tak stávají tabulkami, příp. třídami (např. u programu Enterprise Architect), atributy se přemění 3 Některé nástroje CASE umožňují vytváření i tzv. multidimenzionálních modelů a OLAP kostek, o těch je ale více pojednáno v podkapitole

7 na sloupce, příp. operace. U převodu do fyzického modelu je nutno zadat i cílový databázový systém a jeho verzi, neboť každý má svá implementační specifika, která se potom promítají i do modelu. Tato specifika představují zejména syntaktická pravidla a používání datových typů. Příklad těchto specifik demonstruje Obrázek 1 pomocí karty pro SQL Server, kde je možno nastavit mj. průměrnou velikost tabulky a datový typ pro fyzickou implementaci databáze. Obrázek 1 ERwin Data Modeler - nastavení specifik databázového serveru SQL 7

8 2.1.2 Generování DDL skriptu Od fyzického modelu je pak jen krůček k vygenerování DDL (Data Definition Language) skriptů nutných pro vytvoření databáze na konkrétním databázovém serveru. Nástroje CASE umožňují generovat skript, který je pak možné později spustit na serveru, nebo přímo se připojí na server a provedou příkazy pro vytvoření tabulek, indexů, pohledů, procedur atd. Nástroje CASE tak umožní vybrat jen některé prvky diagramu (tabulky, pohledy apod.) nebo konkrétní objekty, pro které je žádoucí vygenerovat skript. Pokud nástroj umožňuje i nastavení práv (permissions) uživatelů k danému databázovému objektu, generují se i skripty nastavující tato oprávnění. Lze tak produkovat i skripty pro tvorbu indexů, triggerů, aktualizačních pravidel a mnoho jiného. Ukázka dialogového okna, které umožňuje tento výběr, představuje Obrázek 2. Obrázek 2 ERwin Data Modeler dialogové okno Forward Engineer Schema Generation Parametry týkající se velikosti databáze Při fyzickém návrhu databáze se velmi často musí řešit i kapacitní otázky týkající se jednotlivých tabulek a indexů. Cílem takové analýzy je zvýšení výkonnosti a zefektivnění správy dat. Nástroje CASE mohou být i v tomto případě nápomocné, neboť některé z nich obsahují funkce pro nastavení odhadované počáteční velikosti daného objektu (tabulky, index apod.) a atributů týkajících se nárůstu velikosti 8

9 např. za měsíc. Tato velikost se nejčastěji vyjadřuje v jednotkách počtu záznamů. Jakmile je u jednotlivých tabulek a indexů určena jejich velikost, lze odhadnout požadavky na celkovou velikost databáze (Embarcadero, 2011a). Obrázek 3 ER/Studio Data Architect - dialogové okno Capacity Planning Options Na Obrázek 3 je zobrazeno dialogové okno Capacity Planning Options, které nabízí program ER/Studio Data Architect. Jak je zde vidět, je možno tato nastavení použít ke specifikaci počátečního množství řádků v tabulce, zadání parametrů týkajících se nárůstu velikosti tabulky (procentuálně nebo počtem řádků), dále slouží k analýze těchto parametrů do budoucna. Také je možno do odhadů týkající se velikosti tabulky zahrnout i indexy a primární klíče. V levém dolním rohu se následně zobrazují hrubé odhady týkající se velikosti tabulky. V případě potřeby ER/Studio Data Architect umožňuje i generovat a tisknout reporty s těmito odhady (Kalis, 2007). 2.2 Reverse engineering V předchozí kapitole jsme si představili možnosti nástrojů CASE v oblasti tzv. dopředného návrhu databází tedy postup od nejvyššího stupně abstrakce až ke 9

10 konkrétní implementaci v podobě databáze v určitém DDL. Mnohé podniky, zejména ty malé, však tento systematický přístup návrhu databáze odmítají či jej nemohou realizovat z důvodů finančních či časových (Blaha, 1999). Většinou tak vytvoří v poměrně rychlé době konkrétní implementaci databáze, která vyhovuje aktuálním požadavkům. Časem se však údržba této databáze může prodražit, neboť je nutné provést změny v její struktuře díky měnícím se požadavkům. Databáze tak není flexibilní, obsahuje duplicity, nepodporuje podnikové standardy, je nepřehledná a stává se tak neefektivní. Podnik se proto může rozhodnout pro použití metody tzv. zpětného inženýrství (reverse engineering, dále jen RE ), kdy se analyzuje již implementovaná databáze a odvozují se obecnější modely. Tento proces vyžaduje intelektuální přístup spočívající ve využití podnikových znalostí a zkušeností a v práci analytika, který ručně prochází DDL skripty databáze. Nicméně tento přístup většinou selhává, neboť původní návrháři mohli již podnik opustit a není nikdo, kdo by se v současné databázi vyznal. V těchto případech se RE neobejde bez podpory automatizovanými nástroji a přichází do popředí nástroje CASE, které disponují touto vlastností (Müller et al., 2000). Prakticky je téměř nemožné se bez těchto nástrojů obejít, pokud má být proces RE úspěšný (Hainaut, 2002). Příslušný nástroj CASE tak pomáhá velmi rychle převést DDL skript databáze do modelu. Je tak redukována manuální práce analytika spočívající ve čtení skriptů a dále se snižuje riziko chybovosti, které je s tím spojeno (Müller et al., 2000). Takové nástroje CASE musí zahrnovat tzv. DDL extraktory, které umí číst DDL skripty různých databázových jazyků. Mají v sobě dále zakomponovány různé inteligentní analyzátory, které dokáží na základě heuristických pravidel odvodit z těchto DDL skriptů databázové schéma tvořené tabulkami, vztahy mezi nimi apod. Jsou v nich také zabudovány i různá integrační schémata, která jsou schopna určit sémantické vztahy a vyloučit duplicity (Hainaut, 2002). Procesem RE je tak možné odvodit ze stávající databáze dokumentaci na vyšší úrovni abstrakce, což redukuje chybovost v případě manuálního zpracování. Dalším důvodem pro použití funkčnosti RE je potřeba přenosu existující databáze do jiného databázového prostředí (např. z DB2 do SQL Serveru) (Silpiö, 2009). Své využití tak RE nalezne v případě aktualizace staré databáze bez dokumentace na novou, kde je možné některé koncepty staré databáze využít (Hainaut, 2002) Způsoby generování modelu prostřednictvím RE Nástroje CASE umožňují v zásadě dva možné přístupy generování modelu: a) ze souboru obsahujícího skript v příslušném databázovém jazyce, který většinou obsahuje kromě struktury databáze i příkazy pro tvorbu různých procedur a definující přístupová práva; 10

11 b) z existující databáze, přičemž je nutné vytvořit síťové připojení k datovému zdroji. Podmínkou pro vygenerování fyzického modelu je samozřejmě definování příslušného databázového systému, na kterém bude model založen. Na Obrázek 4 je tak zobrazeno dialogové okno Reverse Engineer v programu Erwin Data Modeler, kde je vybrán jako cílový databázový systém SQL Server Obrázek 4 ERwin Data Modeler - dialogové okno Reverse Engineer s výběrem cílové databáze Možnosti RE Většinou je možné zvolit volbu, zda se má automaticky vytvářet referenční integrita u sloupců s identickými názvy a datovými typy v různých tabulkách, či zda se automaticky má vytvořit primární klíč u tabulek bez klíče, které ale mají primární unikátní klíč. ERwin Data Modeler například dokáže odvodit primární klíč v případě, že tabulka v databázi má definován primární nebo unikátní index. Vztahy mezi tabulkami pak odvozuje z indexů. Pokud tabulka obsahuje index, který zahrnuje stejná pole jako index identifikovaný jako primární klíč v jiné tabulce, definuje vztah parent-child. Odvozování se dá také provádět na základě názvů polí pokud tabulka A obsahuje index se stejným názvem jako index v jiné tabulce B, který v ní tvoří primární klíč, je index v tabulce A určen jako cizí klíč do tabulky B (Computer 11

12 Associates, 2011a). Dialogové okno, které umožňuje zvolit možnosti týkající se převodu databáze do modelu je znázorněno na Obrázek 5. Obrázek 5 CA Erwin dialogové okno Reverse Engineer s nastavením možností Dále se vybírají i prvky, které mají být do modelu vygenerovány. Např. v programu InfoSphere Data Architect je možné zvolit pro import tabulky, indexy, pohledy, rutiny, uživatelsky definované typy, role, uživatele a mnoho dalšího. Enterprise Architect umožňuje import existující databáze do modelu přes ODBC připojení. Výhodou je, že kromě filtrování prvků databáze nabízí i výběr konkrétních objektů. Ty jsou pak přeneseny do modelu jako třídy. Další funkci, kterou je možné využít v souvislosti s RE, je synchronizace změn v modelu a databázi. Pokud tak například jsou v modelu přidány nové tabulky, při využití funkce Compare and sync v programu InfoSphere Data Architect mohou být tyto změny přeneseny do databáze program umí tyto změny nalézt, vygenerovat ALTER skript a spustit patřičné příkazy v databázi. Funkce umí provést i opačnou synchronizaci, tedy přenést změny provedené v databázi do modelu. Tato funkčnost umožňuje zachovat konzistenci mezi fyzickou implementací a metadaty k databázi. Ukázku synchronizace databáze a modelu nástroje InfoSphere Data Architect je znázorněna na Obrázek 6. V dialogovém okně je možné porovnat datový model a fyzickou databázi. V prvním sloupci lze odkrývat jednotlivé objekty a vidět tak konkrétní hodnoty pro model a databázi. V tomto případě je patrné, že v tabulce 12

13 PRODUCT přibyl v databázi sloupec GROSS_MARGIN, který v modelu není. Vpravo dole se pak nachází tlačítko umožňující zahrnout tuto změnu do modelu. Obrázek 6 InfoSphere Data Architect - ukázka synchronizace modelu a databáze Z výše uvedeného by mohlo vyplývat, že RE v nástrojích CASE znamená převod fyzické implementace databáze či skriptu do některé úrovně datového modelu. Tato dedukce je pravdivá pouze částečně RE umožňuje obecně totiž převod z nižší úrovně abstrakce do vyšší úrovně abstrakce. SQL Developer Data Modeler od společnosti Oracle tak také kromě převodu databáze do fyzického modelu nabízí i transformaci fyzického modelu (nižší úrovně abstrakce) do relačního modelu Omezení RE Silpiö (2009) uvádí i některá omezení této funkčnosti nástrojů CASE. Zejména se jedná o neaktuálnost podporovaných verzí databázových systémů. Dalším omezením může být různý stupeň podpory daného databázového systému v rámci jednoho nástroje CASE. Stává se také někdy, že parser převádějící databázi do modelu ohlásí chybu, na kterou je možno pak reagovat několika akcemi (přeskočení chyby, zastavení zpracování apod.). Důvodem je většinou nesoulad mezi syntaxí ve skriptu nebo databázi a cílovým serverem, který byl vybrán pro fyzický model (Computer Associates, 2011a). 2.3 Export dokumentace Samozřejmostí by v dnešní době měla být schopnost nástroje CASE generovat dokumentaci k databázovému systému podle určitých zadaných pravidel. Kvalitní nástroje CASE musí mít i možnost parametrické specifikace obsahu dokumentace tak, aby bylo možné vytvářet různé verze dokumentace např. pro manažery, analytiky nebo programátory, ale ze stejného modelu. Dokumentace či reporty vytvořené z modelů mohou sloužit i jako kontrakt mezi dodavatelem a zadavatelem řešení a dále zejména usnadňují komunikaci mezi 13

14 analytikem a vývojářem, byznys uživatelem a řešitelem a mnoha různými stakeholdery. Enterprise Architect umožňuje generovat následující typy dokumentace (Sparx Systems, 2011a): a) textovou ve formátu RTF (Rich Text Format), která obsahuje formátovaný text a tabulky; b) interaktivní ve formátu HTML (HyperText Markup Language), která vygeneruje pro každou entitu v modelu HTML stránku a všechny propojí pomocí odkazů. SQL Developer Data Modeler umožňuje uložit dokumentaci na lokální disk ve formátu XML, která se dá pak snadno zobrazit v kterémkoliv textovém programu. Druhou možností pak je export reportu do tzv. reportovacího repozitáře, který umožňuje snadné verzování a systematický přístup v rámci celé organizace. Do něj se ukládají všechny návrhy, diagramy, modely, databázová schémata a další metadata týkající se řešení informačního systému celé organizace. Kromě exportu dokumentace týkající se konkrétního návrhu databáze může uživatel tohoto nástroje CASE generovat i přehledné reporty obsahující pravidla návrhu (různá obecná pravidla modelování, byznys pravidla a další omezení, která musí model splňovat), dále reporty s informacemi o bezpečnostních aspektech databáze (uživatelé a jejich práva, šifrované sloupce, politiky apod.) a další uživatelsky definované reporty (Murray, 2011). Do reportu nemusí být zahrnut jen jeden datový model. PowerDesigner dovoluje přidat i více modelů. Pomáhá tak přehledně mapovat např. to, jak koresponduje nějaká tabulka ve fyzickém datovém modelu s entitou/entitami v modelu logickém (Sybase, 2008) RTF dokumentace Textová dokumentace je kompatibilní s aplikacemi, jako je MS Word a je vhodná zejména pro tisk. Některé nástroje CASE poskytují tvorbu vlastních šablon nebo použití předdefinovaných a např. PowerDesigner nabízí i výběr jazykové mutace pro dokumentaci (angličtina, němčina, francouzština, čínština apod.). Většinou je možno i vybrat objekty, které se mají, nebo naopak nemají zahrnout do dokumentace (např. jaké entity, vztahy apod.), možnosti třídění objektů, úroveň podrobnosti nebo změnu kódovací stránky výsledného textu. Existuje zde také možnost vyexportovat pouze diagramy. RTF reporty obsahují titulní stránku, obsah a samotnou dokumentaci, která je většinou členěna podle typu objektů a zahrnuje souhrnné tabulky pro větší přehlednost. V PowerDesigneru jsou široké možnosti kastomizace reportu vlastním 14

15 potřebám (nastavení vlastností písma, nadpisů, hlavičky, patičky apod.). Většinou je možné zobrazovat v reportu i diagramy ve formě obrázku HTML dokumentace Velkou výhodu HTML dokumentace představuje její interaktivnost jednotlivé entity jsou propojeny hypertextovými odkazy, kde lze nalézt podrobnější informace a odkazy na další entity. Je vhodná pro sdílení na internetu nebo firemním intranetu. Tento typ dokumentace vyžaduje prohlížeč a umožňuje zahrnout snadno i JPG, GIF nebo BMP obrázky částí modelů (Embarcadero, 2011a). Nevýhoda by mohla spočívat v tom, že ji nelze jednoduše - na rozdíl od textové dokumentace již upravovat, je tak vhodná spíše pro uživatele, kteří nemají kompetence model či dokumentaci upravovat, ale potřebují jej nastudovat, případně okomentovat, např. byznys uživatelé (Embarcadero, 2011a). 2.4 Validace modelu Některé nástroje CASE umožňují validaci modelů po syntaktické a logické stránce. Díky tomu lze průběžně ověřovat správnost modelu, snížit tak jejich chybovost a urychlit ladící a testovací část celého projektu tvorby databáze. Tím se stává vývoj databází standardizovaným a kontrolovaným. Validace modelu tedy slouží k ověření jeho správnosti dle předdefinovaných pravidel a omezení. Validace modelu upozorňuje na různé chyby, které neodpovídají principům datového modelování nebo byznys pravidlům, a zajišťuje tak konformitu s těmito pravidly. Kromě chyb však může validace zobrazovat různá upozornění, což mohou být jen drobnější nedostatky, které však nejsou natolik závažné, aby musely být ihned opraveny. Validace by se měla provádět po každé změně modelu a jeho předání do repositáře, případné chyby by měly být opraveny. Většinou nástroj CASE obsahuje i přídavné informace o chybě (popis chyby) a návrhy na jejich opravu (Sybase, 2008). Důležitou komponentou nástrojů CASE z hlediska validace modelu je tzv. slovník, v němž je obsažena definice datových struktur a vztahů mezi datovými prvky. Obsahuje tedy logické souvislosti modelu a tak se používá k jeho kontrole. Díky slovníku tak mohou být odhaleny např. izolované a nedefinované jednotky dat, nekonzistence související s uložením dat jako externího zdroje a dále porušení syntaktických pravidel (Kozelková, 2006). Obrázek 7 prezentuje konkrétní výsledek validace datového modelu v programu ERwin Data Modeler. Jak je vidět, v osmi objektech je dohromady devět 15

16 chyb či varování. Například je zobrazena chyba v indexu, který nemá definován žádný sloupec. Obrázek 7 ERwin Data Modeler - Model Validation Report Možnosti validace Nástroje CASE umožňují automatizovat kontrolu modelu a objektů v něm obsažených. Lze tak vybrat všechny nebo jen některé kontroly a zahrnout do validace všechny nebo jen některé objekty. Ukázka parametrů ověřování modelu je znázorněna na Obrázek 8. Na záložce Options se vybírají pravidla, která mají být ověřena (např. lze ověřit jen unikátnost názvů entit). Je zobrazena i závažnost dané kontroly, přičemž žluté trojúhelníky s vykřičníkem symbolizují pouhá varování, zatímco červená kolečka s křížkem znamenají závažnou chybu. Na záložce Selection je pak možno zvolit jen určité objekty ke kontrole (tabulky, vztahy apod.), to je zejména užitečné v případě, když některé objekty ještě nejsou ve finální podobě a validace by našla proto mnoho chyb. 16

17 Obrázek 8 PowerDesigner - dialogové okno Check Model Parameters Pravidla datového modelování Většina nástrojů CASE má v sobě implementovány základní kontroly principů datového modelování (zejména UML a relačního, i když se objevují i validace dimenzionálního modelování) a dále je možno dodefinovat specifická vlastní pravidla (viz následující podkapitola). Organizace tak mohou vytvářet vlastní metodiky a definovat vlastní pravidla pro modely, které vyhovují jejím potřebám. Obecnými pravidly tak většinou bývá unikátnost názvu objektů v modelu, povinnost alespoň jednoho atributu v entitě a jednoho sloupce v indexu. ERwin Data Modeler například generuje jako chybu případ, kdy jsou některé tabulky bez sloupců, indexů nebo primárního klíče. Dalším závažným problémem datového modelu je sloupec, který nemá nadefinovaný datový typ či se tento typ liší od pole v jiné tabulce, na které se odkazuje. Lze nastavit i ověřování použití neplatných znaků (např. otazník nebo diakritika v názvech tabulek), omezení délky názvů tabulky a sloupců, povinnost vyplnění komentáře u sloupce apod. 17

18 2.4.3 Obchodní pravidla Omezení v modelu, která nevyplývají z obecných pravidel datového modelování, ale spíše z pravidel obchodních, lze dodefinovat v modelu přirozeným jazykem. Obchodními pravidly (business rules) mohou být například různé zákonem stanovená omezení, požadavek zákazníka nebo interní směrnice (Sybase, 2008). PowerDesigner rozlišuje mezi různými typy obchodních pravidel: a) definice textový popis objektu (např. definice pojmu zákazník); b) skutečnost/fakt obecné konstatování (např. klient provádí jednu nebo více objednávek); c) vzorec výpočet používaný v rámci systému (např. výpočet marže); d) požadavek slovní popis nějakého požadavku (např. student se může zapsat jen na jeden termín zkoušky pro daný předmět); e) validační omezení omezení týkající se hodnoty nějakého objektu v systému (např. datum zahájení projektu je menší než datum jeho ukončení); f) OCL (Object Contraint Language) omezení dodatečné omezení hodnoty (např. datum zaplacení by nemělo přesáhnout jeden měsíc od data splatnosti). Dva poslední typy obchodních pravidel se přímo generují do DDL skriptu v podobě constraint příkazu, jak je vidět na Obrázek 9, kde je omezení týkající se data zaplacení, které nesmí překročit 30 dnů od data splatnosti. Výhodou přirozeného jazyka je, že je snadno srozumitelný, oproti zápisu v nějakém formalizovaném jazyce (např. OCL). Nevýhodu však pak představuje nemožnost automatizovat kontrolu těchto pravidel nástroji CASE. Nicméně identifikace těchto pravidel by se neměla v modelu opomíjet a měla by být uvedena u patřičného objektu, aby veškerá omezení model reflektoval. 18

19 Obrázek 9 PowerDesigner - obchodní pravidlo generované ve skriptu 2.5 Podpora týmové práce Projektů vývoje databází podporovaných nástroji CASE se zpravidla účastní více než jeden pracovník, což automaticky vede k nutnosti předávání informací a rozpracovaných částí projektu. Stejně tak je nutné zajistit možnost sdílení jednotlivých vytvářených komponent mezi několika vývojáři, kteří potřebují pracovat současně. Obvykle je zároveň nutné na jedna a tatáž data pohlížet z různých úhlů pohledu, tedy podle rolí jednotlivých participantů: jinou představu si potřebuje utvořit návrhář databáze, jinou tester a jinak chceme i navrženou databázi prezentovat například vedení společnosti nebo významnému klientovi Repository Klíčem pro podporu týmové spolupráce je repository, česky také repositář nebo skladiště. Jedná se o prostor, který slouží k ukládání veškeré práce na projektu. Repositář může mimo jiné výrazným způsobem zvyšovat efektivitu projektů díky tomu, že umožňuje snadno znovu využít veškerých zpracovaných materiálů. 19

20 Do repository tak ukládají zejména vývojáři a analytici modely systému, detailní popisy, specifikace a jiné výstupy plynoucí z vývoje systému. Jelikož je většinou repository uložena na serveru, je možno sdílet tato metadata napříč organizací a tak další participující na projektu je mohou prohlížet (Agarwal, 2010). Repository by měla být reprezentací všech relevantních informací o systému, který je vyvíjen a to v konzistentní, úplné formě. Repository tak představuje centrální místo pro integraci, ukládání a údržbu všech dat o systému a jeho souvisejících procesech (metadata systému). Dále repository slouží pro řízení těchto metadat, umožňuje tak generování reportů, správu uživatelů metadat, provádění dotazů do těchto metadat, používání diagnostických nástrojů atd. Zejména však přináší usnadnění komunikace mezi nástroji a napříč skupinami uživatelů (Welke, 1988). Repository musí být dostatečně robustní ke zvládnutí velkých projektů a mnoha uživatelů najednou. Důležitá též může být přenositelnost repository na jiné platformy. Některé nástroje CASE mají repository založenou na textových souborech, většina využívá některý databázový systém. Mezi klíčové vlastnosti patří: robustnost: je připraven zvládnout (za odpovídající infrastrukturní podpory) velké zatížení stranou počtu uživatelů a množství ukládaných, vyzvedávaných a upravovaných dat; inteligentní verzování: možnost ukládat jeden konkrétní dokument (v tomto případě například diagram) v mnoha různých verzích a také možnost snadným způsobem zobrazit snapshop (obraz) daných dat v libovolném okamžiku v minulosti; ukládání dokumentů všech typů: a tedy neomezení na jeden (či několik) proprietárních formátů, například datových modelů užívaných jednou konkrétní aplikací; nastavení přístupových práv: obvykle je třeba, aby k repositáři mohlo přistupovat více uživatelů, přičemž někteří z nich potřebují data pouze číst, jiní měnit, dalším můžeme dát například práva pro založení celé nové vývojové větve; inteligentní sdílení: s předchozím bodem úzce souvisí i nutnost souběžného přístupu více uživatelů k repositáři a přiléhající problematika (nekonzistentní verze, zamykání vývojových větví). 20

21 I repository by měla mít svůj model,, který obsahuje informace o struktuře a možnostech repositáře: co může být jeho obsahem a jakým způsobem je možné k tomuto obsahu přistupovat a manipulovat s ním. Model repository nachází využití převážně v situacích, kdy je potřeba v jediném repositáři pracovat s různými nástroji od různých výrobců. Díky dostupným metainformacím tak mohou i původně nekompatibilní nástroje spolupracovat. Následující obrázek názorně demonstruje okno pro řešení konfliktů v repositáři nástroje ER/Studio. Obrázek 10 Řešení konfliktů v repositáři programu ER/Studio Data Architect Repositář je základem týmové spolupráce v nástrojích CASE. Z jeho vlastností vycházejí klíčové funkce, které podporu spolupráce zajišťují. Pro přehlednost jsou níže uvedeny výčtem a rozděleny do tří kategorií Kolaborace Možnost souběžné práce více uživatelů na jednom projektu (včetně upozornění, kdo další na projektu / s daným dokumentem právě pracuje). Vytváření jednotlivých (pod)projektů v rámci repositáře pro snazší organizaci práce. 21

22 Inteligentní řešení konfliktů mezi dokumenty, což zahrnuje kombinování nebo sloučení změn do většího projektu. Možnost udržovat strukturu projektu / kategorizovat jednotlivé dokumenty Verzování Zachycování a ukládání všech změn, které na dokumentech proběhly, s neomezenou historií. Možnost kdykoliv přejít k libovolné verzi kterékoliv dokumentu nebo celého projektu v libovolném čase. Funkce pro srovnávání jednotlivých verzí dokumentů a sledování konkrétních změn/rozdílů v nich. Možnost okomentovat každou změnu odeslanou do repositáře. Možnost správy několika souběžných větví téhož projektu (například produkční a vývojová verze) Bezpečnost Dostatečně robustní systém umožňující přidělovat nejrůznější typy práv uživatelům i skupinám (možné rozdělení rolí a zodpovědností při práci s repositářem názorně ukazuje Obrázek 11). Dostatečné zabezpečení dat před neoprávněným přístupem. Ochrana dokumentů před přístupem dalšího uživatele, zamkl-li ho primární uživatel z důvodu aktuálně prováděných úprav (prevence konfliktu). 22

23 Obrázek 11 Možné rozdělení rolí a zodpovědností při práci s repositářem 2.6 Podpora tvorby dimenzionálních databází Specializovanou funkcionalitou menšího počtu nástrojů CASE pro návrh databází je podpora tvorby multidimenzionálních databází, které jsou zejména aplikované v oblasti Business Intelligence (dále jen BI ). Zatímco návrh relačních databázových struktur je standardně podporován většinou nástrojů CASE, návrh multidimenzionálních databází je spíše specializovanou funkcí menšího počtu CASE nástrojů (Wu, 2001). Důvodem může být skutečnost, že BI je poměrně mladou disciplínou, která však v posledních několika letech dosahuje velkého rozvoje a investic ze strany podniků. Do relačních databází jsou data ukládána do dvourozměrných databázových tabulek (sloupec/řádek), mezi kterými jsou definovány relační vztahy vyplývající z aplikační logiky. Probíhá v nich mnoho transakcí v reálném čase a tak bývají tyto databáze nazývány OLTP (On-Line Transaction Processing). Oproti tomu multidimenzionální databáze jsou optimalizovány pro provádění analytických operací nad velkým objemem dat (např. sumarizace a agregace 23

24 informací). To je umožněno denormalizovaným modelem, který většinou obsahuje redundance Podstata multidimenzionálních databází Na začátku je na místě stručně objasnit pojmy související s problematikou dimenzionálního modelování. V rámci řešení datových tržišť a dalších BI komponent se pro návrh databází používají tabulky faktů a dimenzí. Faktové tabulky zachycují sledované ekonomické ukazatele (např. objem tržeb, náklady, výši pohledávek apod.) a jejich primární klíč je většinou tvořen cizími klíči do tabulek dimenzí. Ty obsahují různé pohledy na faktové tabulky (např. z hlediska času, produktů, zákazníků). Dalším důležitým pojmem v oblasti multidimenzionálního modelování jsou star a snowflake schémata. Schéma hvězdy se od schématu sněhové vločky odlišuje v tom, že neobsahuje další dělení dimenzionální tabulky. Dimenze většinou obsahují statická (neměnná) data, ale některé se mohou měnit (např. adresy zákazníků, produkty apod.), takové dimenze se nazývají Slowly Changing Dimension (Computer Associates, 2011a). Podrobnější popis principů multidimenzionálního modelování není předmětem této práce, byly uvedeny pouze základní pojmy, které jsou dále v textu používány Návrh faktových a dimenzionálních tabulek Dimenzionální model může být odvozen z logického či fyzického datového modelu, případně i z SQL dotazu. U některých nástrojů CASE se pouze zvolí dimenzionální notace u logického či fyzického modelu a automaticky dojde ke změnám v zobrazení tabulek a možných vlastností. Primární klíč dimenzionálních tabulek je převeden jako cizí klíč ve faktové tabulce. Důležité je správné nastavení typu tabulky v dimenzionálním modelu. Většina nástrojů podporující tuto funkci dokáže odvodit typ tabulky na základě obecných pravidel. Např. ERwin Data Modeler nastavuje při vložení tabulky standardní hodnotu dimension pro typ tabulky, ale na základě těchto pravidel se tato hodnota automaticky mění: Pokud tabulka nemá žádné rodičovské vztahy (není nadřízenou tabulkou), stává se faktovou. Pokud tabulka je nadřízená (rodičem) faktové tabulky nebo pokud je rodičovskou a zároveň podřízenou tabulkou, stává se dimenzionální tabulkou (v případě star schématu). Pokud tabulka je nadřazená dimenzionální tabulce, stává se tzv. outrigger tabulkou (v případě snowflake schématu) a vzniká hierarchie dimenzí. Typ tabulky lze samozřejmě i ručně nastavit, program ale zahlásí v případě nesprávného přiřazení typu chybu, jako je vidět na Obrázek 12, kdy byl zvolen 24

25 chybně typ tabulky na faktovou, přičemž se jedná o dimenzionální tabulku (je rodičem faktové tabulky). Obrázek 12 Erwin Data Modeler nesprávně nastavený typ tabulky v dimenzionálním modelu Na Obrázek 13 jsou zobrazeny typy tabulky, které umožňuje nastavit dimenzionální model v programu ERwin Data Modeler. Je tedy možno zvolit typ dimenzionální, faktové tabulky, nebo v případě rozdělené dimenze typ outtriger (u snowflake schématu). Obrázek 13 ERwin Data Modeler výběr typu tabulky v dimenzionálním modelu Příklad diagramu dimenzionálního modelu je na Obrázek 14, který obsahuje faktovou tabulkou s objemem prodeje, na který lze pohlížet z pohledu podle poboček či produktů a jejich kategorií. 25