Semestrální práce 4IT450

Transkript

1 Předmět: 4IT450 Den a čas cvičení: Út Zimní semestr 2010/2011 Semestrální práce 4IT450 Podpora CASE při vytváření databází Jméno: Veronika Honová Tomáš Jedlička Martin Potančok Jan Pávek

2 1 Obsah 2 Úvod Princip tří architektur Modelová databáze CASE nástroje Oracle SQL Developer Data Modeler Úvod Požadavky na systém Konceptuální úroveň Technologická úroveň Implementační úroveň Další funkce Shrnutí PowerDesigner Úvod Požadavky na systém Konceptuální úroveň Technologická úroveň Implementační úroveň Další funkce Shrnutí Toad Data Modeler Úvod Požadavky na systém Konceptuální úroveň Technologická úroveň Implementační úroveň Další funkce Shrnutí XTG Data Modeller Úvod Požadavky na systém Konceptuální úroveň Technologická úroveň

3 5.4.5 Implementační úroveň Další funkce Shrnutí Srovnání CASE nástrojů Závěr Seznam použité literatury Seznam obrázků Seznam tabulek

4 2 Úvod CASE nástroje podporující návrh a vytváření databází považujeme za velmi důležité téma v oblasti modelování. Databáze tvoří základ podnikových informačních systémů a bez dobře postavené datové architektury nám sebelepší aplikace nepomůžou k efektivnímu využití potenciálu informačních technologií. Právě CASE nástroje nám umožňují vytvořit kvalitní datový model jako východisko pro použitelnou datovou architekturu. Proto jsme si zvolili tématem naší práce Podporu CASE při vytváření databáze. V rámci návrhu databází se budeme držet zavedeného Principu tří architektur (P3A). Ten vytvoří podklad pro testování jednotlivých nástrojů. Na základě vytváření úrovní, které jsou součástí tohoto principu, prověříme funkčnost nástrojů a porovnáváme jejich vlastnosti. Pro tyto účely jsme vybrali konkrétní modelovou databázi, jež bude sloužit k simulaci všech činností potřebný pro korektní návrh databáze v souladu s P3A. Za účelem porovnání jsme vybrali čtyři nástroje. Jedná se o produkty z rozličných cenových kategorií. Konkrétně jde o aplikace Oracle SQL Developer Data Modeler, PowerDesigner, Toad Data Modeler a XTG Data Modeller. Toto samozřejmě nepokrývá celé spektrum produktů tohoto druhu, ale pro potřeby této práci považujeme počet testovaných nástrojů za dostatečný. Hlavním cílem této práce je tedy porovnání jednotlivých CASE nástrojů z pohledu použití pro návrh a vytváření databází. Záběr některých z nich je výrazně širší, my se budeme soustředit především na datové modelování. U každého produktu uvedeme doporučení, pro které uživatelské skupiny je vhodný. Srovnávat budeme na základě modelování naší vybrané databáze a také tabulkovým porovnáním některých vlastností těchto nástrojů. Pro dosažení tohoto cíle je třeba nejdříve objasnit Princip tří architektur a představit naši modelovou databázi. Struktura práce je následující. V následující kapitole si představíme Princip tří architektur a jeho zásady. Vysvětlíme si obsah a účel jednotlivých úrovní návrhu. V další části popíšeme modelovou databázi, se kterou budeme dále pracovat. Následovat bude testování jednotlivých nástrojů. Každá kapitola bude rozdělena v souladu s úrovněmi P3A. U jednotlivých nástrojů uvedeme systémové požadavky a některé další užitečné funkce. Kapitoly budou uzavřeny shrnutím informací o nástroji. Poslední kapitolou bude Srovnání CASE nástrojů, kde uvedeme tabulku s dostupností vybraných funkcí a shrnující vlastnosti porovnávaných nástrojů. 4

5 3 Princip tří architektur Princip tří architektur (P3A) je jedním ze tří základních principů vývoje informačního systému. Vychází z dalších dvou principu modelování a principu abstrakce. Princip modelování je objektivním základem vývoje informačního systému. IS je infrastrukturou, vždy něco podporuje a nemá tak význam sám o sobě. Proto je nejdůležitější poznat, co má podporovat, tzn. business systém a business procesy a na základě jejich poznání vytvořit IS jako model business systému, který má podporovat. Princip abstrakce je přímým důsledkem principu modelování, jeho podstatou je zanedbávání detailů za účelem postižení celku. Podstatné modelujeme do detailů, zatímco od nepodstatného abstrahujeme. Důsledkem obou předchozích principů je právě princip tří architektur, který představuje návod, jak používat abstrakci, aby byl dodržen princip modelování. Princip tří architektur podle prof. Řepy definuje způsob použití abstrakce pro vývoj informačního systému po jednotlivých vrstvách. Jednotlivé vrstvy se zaměřují na 3 hlavní aspekty vyvíjeného systému: obsah, technologii a implementační/realizační specifika. Tyto hlavní aspekty vyvíjeného systému tvoří přirozenou posloupnost: ze specifikace obsahu systému vyplývají možnosti technologického řešení a konkrétní použitá technologie určuje implementační možnosti. Návrh informačního systému probíhá ve třech, po sobě následujících architekturách: konceptuální zde je vytvořen zcela obecný, čistě obsahový model systému, nezatížený ani technologickou koncepcí řešení, ani jeho implementačními specifiky. Je zde abstrahováno od technologických a implementačních specifik řešení. Konceptuální návrh určuje CO je obsahem systému. technologické zde je vytvořen model systému, zohledňující technologickou koncepci řešení, tj. ve strukturovaném pojetí koncepci organizace dat (technologie souborová, stromově, síťově, či relačně databázová atd.) a technologickou koncepci jejich zpracování (jazyk 3., či 4. generace, technologické prostředky architektury client - server atd.). Technologický model stále nesmí být zatížen implementačními specifiky řešení. Je zde tedy abstrahováno od implementačních specifik řešení, obsahové náležitosti jsou dány konceptuálním řešením a zde se neřeší. Technologický návrh určuje, JAK je obsah systému v dané technologii realizován. implementační zde je vytvořen model systému, zohledňující implementační specifika použitého vývojového prostředí (konkrétního databázového systému, programovacího jazyka a dalších prostředků, jako například vývojového prostředí GUI atd.). Není zde abstrahováno od žádných specifik řešení, obsahové náležitosti jsou dány konceptuálním řešením, technologie je dána technologickým řešením, implementační návrh se tedy týká pouze implementačně specifických rysů systému. Implementační návrh určuje ČÍM je technologické řešení realizováno. *Řepa, Princip tří architektur ilustruje Obr. 1. Místo pojmu architektura se také používá pojem úroveň. Technologická úroveň se též někdy označuje jako logická a implementační jako fyzická. My se v této práci budeme držet označení konceptuální technologická implementační úroveň. 5

6 Obr. 1 Princip tří architektur *Řepa, Principu tří architektur se využívá i v datovém modelování při návrhu struktury datové základny. Hlavní důvod je ten, že data, přesněji entity, atributy a vztahy tvořící navrhovanou databázi by měly přesně odpovídat výseku reality, který modelujeme a který se snažíme v databázi zachytit. Používá se pro to termínu konzistence. Abychom jí však mohli dosáhnout, musíme být na konceptuální úrovni zcela odstíněni od všech technologických vlivů a implementačních specifik prostředí, ve kterém bude modelovaná databáze fyzicky realizována. Tyto vlivy by nám totiž mohly dosažení úplné konzistence mezi realitou a jejím obrazem v databázi znemožnit. Výhodou tohoto přístupu zároveň je, že návrh datové základny na konceptuální úrovni je možné transformovat do libovolného logického uspořádání dat na technologické úrovni a implementovat v libovolném databázovém systému na úrovni implementační. Máme tak zajištěnu nezávislost návrhu na konceptuální úrovni na platformě. Při návrhu datové základny se ještě konceptuální úroveň rozděluje na konceptuální schéma reality a konceptuální model. Konceptuální schéma reality (viz Obr. 2) je nástrojem poznání reality, jedná se o hrubý model za účelem poznání reality. Na něj pak navazuje konceptuální model, jehož účelem již je přesná specifikace obsahu datové základny na konceptuální úrovni. Na technologické úrovni určujeme technologické aspekty návrhu, tedy jestli použijeme relační nebo objektový datový model apod. Na implementační úrovni pak vybíráme konkrétní databázový systém, ve kterém bude návrh datové základny fyzicky realizován, výstupem této úrovně jsou obvykle příkazy definující databázi ve zvoleném databázovém systému. Principu tří architektur se budeme striktně držet při popisu a testování CASE nástrojů v této práci. 6

7 4 Modelová databáze Pro přehlednost a srozumitelnější srovnání je při testování všech nástrojů použit jednotný školní příklad, jehož cílem bylo vytvoření databáze pro Český tenisový svaz, sloužící k evidenci registrovaných hráčů věkové kategorie dospělých, jednotlivých turnajů, které jsou v probíhající sezóně pořádány a kterých se tito hráči účastní, mateřských klubů těchto hráčů a soutěží družstev, kterých se tyto kluby v probíhající sezoně účastní. Turnaje, výsledky hráčů na těchto turnajích a soutěže družstev jsou evidovány pouze pro právě probíhající sezonu. Modelovány jsou entity Hráč (každý hráč je jednoznačně identifikován atributem rodné číslo), Klub (číslo klubu), Turnaj (kód turnaje), Soutěž družstev (zkratka soutěže). Konceptuální schéma modelové databáze včetně všech atributů a vztahů mezi entitami v notaci používané v daném předmětu je znázorněno na následujícím obrázku. Obr. 2 Konceptuální schéma modelové databáze 7

8 5 CASE nástroje 5.1 Oracle SQL Developer Data Modeler 2.0 Společnost Oracle nabízí hned několik CASE nástrojů podporujících vytváření databází. Všechny tyto nástroje jsou zdarma s licencí umožňující používat jejich plné verze k vyvíjení vlastních aplikací nebo samovzdělávacím účelům a je možné je stáhnout z webových stránek společnosti Oracle 1. Ke stažení je třeba pouze bezplatná registrace. Největším z nich co se týče nabízených funkcí a typů modelů je bezesporu komplexní a integrované vývojové prostředí Oracle Developer Suite, jehož nejnovější verze je 10g ( ). Jedná se o balík produktů, který obsahuje několik komponent. Oracle Developer Suite tedy nepodporuje zdaleka pouze vytváření databází. Z těchto komponent nás nejvíce zajímá Oracle Designer, který zahrnuje podporu pro modelování podnikových procesů, systémovou analýzu, softwarový design a vývoj informačních systémů. Tento nástroj je možné stáhnout a používat i samostatně. Nevýhodou obou těchto aplikací je to, že potřebují přímo spolupracovat s databází Oracle, kam si ukládají všechny informace, a proto je nutné mít tuto databází též nainstalovanou, což jejich testování poměrně ztěžuje. Proto bude dále představen další z nástrojů společnosti Oracle Oracle SQL Developer Data Modeler, který spolupráci s databází Oracle nevyžaduje, navíc jej není nutné ani instalovat Úvod Oracle SQL Developer Data Modeler nabízí široké spektrum funkcí a nástrojů k datovému modelování a modelování databází, zahrnující ERD diagramy, relační databázový design, datové typy, multidimenzionální modely, Data Flow diagramy i generování DDL kódu. Testována je jeho verze 2.0, kterou je také možné zdarma stáhnout z webových stránek společnosti Oracle. Jak již bylo zmíněno, není nutné jej instalovat. Stahován je *.zip archiv, který obsahuje i Java Runtime Environment nutný pro práci programu, tento archiv stačí rozbalit do libovolné složky a spustit. Základní obrazovka programu je znázorněna na Obr

9 5.1.2 Požadavky na systém Obr. 3 Uživatelské prostředí Oracle SQL Developer Data Modeler Minimální požadavky Procesor - Místo na pevném disku 125 MB Operační paměť min. 512 MB, doporučeno 1 GB Operační systém Microsoft Windows (XP, Vista, 7 včetně x64) Linux Mac OS X Další JavaTM 1.6 nebo vyšší Standard Edition Runtime Environment Tab. 1 Oracle SQL Developer Data Modeler požadavky na systém [Oracle, 2009] Konceptuální úroveň Konceptuální model databáze je v programu Oracle SQL Developer Data Modeler označován jako Logical. Všechny prvky konceptuálního modelu je možné vytvořit pomocí ikon v horní vodorovné nástrojové liště. Nová entita se vytváří pomocí funkce New Entity. Na kartě entity Entity Properties zadáme její název, k určení atributů entity pak slouží záložka Attributes. Při definici atributu můžeme využít přednastavených standardních datových typů, které zahrnují jak základní znakové (CHAR, VARCHAR, TEXT), číselné (INTEGER, DECIMAL, FLOAT) a časové typy (DATE, TIME), tak mnohé jiné, např. AUDIO, IMAGE, XMLTYPE a další. Celkem je jich v nabídce přes 60. Jestliže si chceme vytvořit svoje domény, slouží k tomu volba Tools Domains Administration. Vlastní domény jsou uloženy do souboru defaultdomains.xml, pokud si tento soubor přejmenujeme, můžeme takto definované domény importovat v budoucnu do dalších modelů. Pokud je atribut jednoznačným identifikátorem dané entity, zaškrtneme volbu Primary UID, v případě, že je uvedení atributu povinné, použijeme volbu Mandatory (při volbě Primary UID je samozřejmě zaškrnuta automaticky). K definici vztahů mezi entitami slouží funkce New M:N Relation, New 1:N Relation a New 1:1 Relation. Na kartě vztahu Relation Properties můžeme zadat název vztahu, kardinalitu vztahu je pak možné 9

10 změnit na záložce Cardinality. Program předpokládá všechny nové vztahy defaultně jako nepovinné, pokud je některá nebo obě strany vztahu povinné, odškrtneme příslušné políčko Source/Target Optional. Rovněž lze pojmenovat role obou stran v daném vztahu. Program však neumožňuje v konceptuálním modelu zachytit vztah s atributem, takový atribut se musí přidat do příslušné tabulky až v dalším modelu na technologické úrovni. Nový pohled se vytváří pomocí funkce New View. Pro zajímavost je dobré uvést i funkci Fit Screen, která přizpůsobí velikost prvků modelu velikosti okna. Jejím opakem je funkce Default Size, která naopak nastaví prvkům modelu zpět defaultní velikost. Konceptuální model modelové databáze je znázorněn na Obr. 4. Obr. 4 Oracle SQL Developer Data Modeler model na konceptuální úrovni Z Obr. 4 je zřejmé, že jednoznačný identifikátor entity je v modelu označen modrým křížkem (Primary UID), povinný atribut červenou hvězdičkou (Mandatory) a nepovinný atribut červeným kolečkem (v našem příkladě jsou atributy všech entit povinné). Program používá jako výchozí tzv. Barkerovu notaci, u které je dobré upozornit na ten fakt, že kardinalita a parcialita vztahu jsou znázorněny na opačných stranách spojovací čáry znázorňující daný vztah, což může působit na první pohled poněkud zmatečně. Ilustrujme si to na příkladu vztahu mezi entitami Klub a Hráč. Platí, že za jeden klub může hrát více hráčů, ale klub také nemusí mít žádného hráče, to znamená, že vztah Klub-Hráč má kardinalitu 0:n. Skutečnost, že za klub může hrát více hráčů, tedy kardinalita je vyjádřena pomocí vidličky u entity Hráč, zatímco nepovinnost, tedy parcialita tohoto vztahu nám ukazuje přerušovaná čára blíže k entitě Klub. U vztahu Hráč-Klub je to obdobné (povinnost vztahu je znázorněna čárou 10

11 plnou). Barkerova notace je tedy odlišná od notace konceptuálního schématu (viz Obr. 2). Nevýhodou je, že v modelu nejsou viditelné definované datové typy jednotlivých atributů ani názvy vztahů mezi entitami. Řešením je použití Bachmanovy notace, kterou program také nabízí, notaci lze změnit pomocí funkce Tools-Generals Options na záložce Diagram-Logical Model volbou Notation Type. Seznam všech vytvořených entit, atributů, vztahů, identifikátorů či pohledů je uveden v levé části okna, kde je též možnost upravovat jejich vlastnosti Technologická úroveň Technologický model databáze je v programu Oracle SQL Developer Data Modeler označován jako Relational. Již z tohoto pojmenování vyplývá, že program umožňuje použití pouze relačního datového modelu. Vytvořit technologický model je obecně možné dvěma způsoby. Zaprvé si ho můžeme pomocí programu nechat vygenerovat z konceptuálního modelu. Tento postup je mnohem jednodušší a častější, odpovídá podstatě toho, proč CASE nástroj používáme. Slouží k tomu funkce Engineer to Relational Model, u každého prvku konceptuálního modelu lze ještě pomocí volby Engineer To nastavit, zda se má v technologickém modelu objevit či nikoliv. Vlastnosti všech vygenerovaných prvků je možné dále měnit a upravovat, jedná se především o přidání atributů do tabulek vzniklých ze vztahů kardinality M:N z důvodu toho, že program neumožňuje na konceptuální úrovni modelovat vztah s atributem, a změnu typu referenční integrity jednotlivých cizích klíčů. Program defaultně nastavuje typ referenční integrity RESTRICT, pokud z konceptuálního modelu nevyplývá něco jiného, typ je možné změnit na kartě ForeignKey Properties volbou Delete Rule. Na výběr jsou všechny čtyři základní typy NO ACTION, CASCADE, SET NULL a RESTRICT. Druhou možností je, obdobně jako na konceptuální úrovni, vytvořit všechny prvky ručně opět pomocí ikon v horní vodorovné nástrojové liště funkce New Table, New FK Relation apod. Nutno podotknout že tento postup je nejen náročnější a zdlouhavější, ale především mnohem náchylnější k chybám a vzniku nekonzistencí mezi oběma modely a zároveň popírá samotnou podstatu používání CASE nástrojů a nerespektuje princip tří architektur (viz kapitola 3), proto zde nebyl použit. V souvislosti s tím však program nabízí zajímavou funkci Engineer to Logical Model, která z technologického modelu zpětně vygeneruje nebo modifikuje konceptuální model. Tato funkce se může hodit v případě, že modely dodatečně upravujeme nebo přizpůsobujeme. Technologický model modelové databáze je znázorněn na Obr

12 Obr. 5 Oracle SQL Developer Data Modeler model na technologické úrovni Z Obr. 5 je zřejmé, že primární klíč je v modelu označen modrým písmem a písmenem P, cizí klíč písmenem F. Na rozdíl od konceptuální úrovně jsou zde již viditelné datové typy jednotlivých atributů. Seznam všech vytvořených tabulek, sloupců, indexů nebo cizích klíčů je opět uveden v levé části okna. Program ukládá modely obou úrovní do jednoho souboru přenositelného formátu *.xml. Malou nevýhodou je, že v jednom okně programu můžeme modelovat pouze jeden konceptuální a jeden jenom odpovídající technologický model, není však problém spustit více instancí programu Implementační úroveň Ke generování kódu, tedy jednotlivých příkazů pro vytvoření databáze v konkrétním databázovém systému slouží funkce Generate DLL. Oracle SQL Developer Data Modeler nabízí výběr z těchto databázových systémů: Oracle Database 11g, 10g a 9i SQL Server 2005 a 2000 DB2/390 8 a 7 DB2/UDB 8.1 a

13 Vygenerované příkazy je možné uložit do souboru ve formátu *.sql nebo *.ddl. V našem konkrétním příkladě vygeneroval program pro databázový systém Oracle Database 11g následující skript: -- Generated by Oracle SQL Developer Data Modeler Version: Build: at: :32:34 -- site: Oracle Database 11g -- type: Oracle Database 11g CREATE TABLE Hráč ( "rodné číslo" CHAR (10) NOT NULL, Příjmení VARCHAR2 (25) NOT NULL, jméno VARCHAR2 (15) NOT NULL, "bodová hodnota" INTEGER NOT NULL, "platnost registrace do" DATE NOT NULL, "číslo klubu" CHAR (5) NOT NULL ); ALTER TABLE Hráč ADD CONSTRAINT Hráč_PK PRIMARY KEY ( "rodné číslo" ) ; CREATE TABLE Klub ( "číslo klubu" CHAR (5) NOT NULL, "název klubu" VARCHAR2 (40) NOT NULL, ulice VARCHAR2 (30) NOT NULL, město VARCHAR2 (30) NOT NULL, PSČ CHAR (5) NOT NULL, "počet dvorců" INTEGER NOT NULL, zkratka CHAR (4) ); ALTER TABLE Klub ADD CONSTRAINT Klub_PK PRIMARY KEY ( "číslo klubu" ) ; CREATE TABLE "Soutěž družstev" ( zkratka CHAR (4) NOT NULL, "název soutěže" VARCHAR2 (25) NOT NULL, oblast VARCHAR2 (20) NOT NULL, míče VARCHAR2 (30) NOT NULL ); ALTER TABLE "Soutěž družstev" ADD CONSTRAINT "Soutěž družstev_pk" PRIMARY KEY ( zkratka ) ; CREATE TABLE Turnaj ( "kód turnaje" CHAR (6) NOT NULL, "název turnaje" VARCHAR2 (50) NOT NULL, "termín od" DATE NOT NULL, "termín do" DATE NOT NULL, "plánovaný počet účastníků" INTEGER NOT NULL, startovné NUMBER NOT NULL, "číslo klubu" CHAR (5) NOT NULL); ALTER TABLE Turnaj ADD CONSTRAINT Turnaj_PK PRIMARY KEY ( "kód turnaje" ) ; 13

14 CREATE TABLE "Účast na turnaji" ( "Hráč_rodné číslo" CHAR (10) NOT NULL, "Turnaj_kód turnaje" CHAR (6) NOT NULL, výsledek VARCHAR2 (15) NOT NULL, body INTEGER NOT NULL ); ALTER TABLE "Účast na turnaji" ADD CONSTRAINT "Účast na turnaji IDX" PRIMARY KEY ( "Hráč_rodné číslo", "Turnaj_kód turnaje" ) ; ALTER TABLE "Účast na turnaji" ADD CONSTRAINT FK_ASS_10 FOREIGN KEY ( "Hráč_rodné číslo" ) REFERENCES Hráč ( "rodné číslo" ); ALTER TABLE "Účast na turnaji" ADD CONSTRAINT FK_ASS_11 FOREIGN KEY ( "Turnaj_kód turnaje" ) REFERENCES Turnaj ( "kód turnaje" ); ALTER TABLE Turnaj ADD CONSTRAINT pořádá FOREIGN KEY ( "číslo klubu" ) REFERENCES Klub ( "číslo klubu" ); ALTER TABLE Klub ADD CONSTRAINT "účast v soutěži družstev" FOREIGN KEY ( zkratka ) REFERENCES "Soutěž družstev" ( zkratka ) ON DELETE SET NULL; ALTER TABLE Hráč ADD CONSTRAINT členství FOREIGN KEY ( "číslo klubu" ) REFERENCES Klub ( "číslo klubu" ); 14

15 5.1.6 Další funkce Z dalších funkcí umožňuje Oracle SQL Developer Data Modeler vytváření multidimenzionálních modelů a modelování Data Flow diagramů Shrnutí Oracle SQL Developer Data Modeler je jednoduchým, avšak velmi účinným nástrojem podporujícím vytváření databází. Jeho používání je velmi intuitivní, k čemuž přispívá i to, že je opatřen pěkným a hlavně přehledným designem. Můžeme říci, že se jedná o CASE nástroj pro každého. Každý, kdo má alespoň nějakou, byť jen malou zkušenost s datovým modelováním ať už z jakéhokoliv nástroje, se v něm rychle a snadno zorientuje a může velmi brzy efektivně využít všech jeho funkcí Výhody zdarma ke stažení bez instalace jednoduché a intuitivní ovládání přehledný design možnost zpětného generování konceptuální modelu z technologického funkce pro přizpůsobení velikosti prvků modelu velikosti okna programu Nevýhody nemožnost modelovat vztah s atributem nezobrazování datových typů atributů a názvů vztahů na konceptuální úrovni při použití Barkerovy notace práce pouze s jedním konceptuálním a technologickým modelem 15

16 5.2 PowerDesigner 15.2 Společnost Sybase působí na softwarovém trhu již více než 25 let. Její centrála se nachází v Dublinu v Kalifornii. Za dobu své působnosti se stala jednou z vůdčích společností v oblasti správy datových skladů a distribuce dat. Mezi její další produkty můžeme zařadit databázové servery pro OLTP, portálové a aplikační servery a integrační nástroje. Úspěch dosahuje také v oblasti softwaru pro mobilní telefony. Silné postavení má společnost Sybase v rámci vývojových a CASE nástrojů, které jsou předmětem naší práce. Této oblasti dominuje produkt PowerDesigner zahrnující komplexní nástroje pro analýzu a návrh informačních systémů. Kvalitu produktů společnosti Sybase dokazuje letošní akvizice společností SAP. [Havel, 2010] Úvod PowerDesigner nabízí široké možnosti pro obchodně orientovanou procesní analýzu, datovou a objektovou analýzu. Standardem je samozřejmě podpora UML a pro naše potřeby také tříúrovňového návrhu databází. Jedná se o skutečně rozsáhlý nástroj na nejvyšší úrovni, který má pokrývat všechny aspekty rozvoje organizace. PowerDesigner existuje ve čtyřech základních verzích. Verze DataArchitekt, jak již napovídá název, je vhodná pro datové modelování a administraci databází. Varianta Developer je naopak zaměřena na objektové modelování zahrnující řízení požadavků. Umožňuje propojení s nejrozšířenějšími vývojovými nástroji a podporuje celou řadu programovacích jazyků. Tyto dvě verze spojuje varianta Studio. Ke jmenovanému obsahu přidává ještě modelování obchodních procesů. Nejnižší verze v nabídce je Viewer, která umožňuje pouze čtení modelů a jenž je také jako jediná dostupná zdarma. Ceny ostatních verzí se pohybují od USD za verzi DataArchitekt až po USD za jednu licenci PowerDesigner Studio. [SoftwareMedia.com, 2010] K testování jsme použili trial verzi dostupnou na stránkách společnosti Sybase 2. Pro její stažení je podmínkou vyplnění formuláře zahrnujícího základní kontaktní údaje uživatele a otázky týkající se plánovaného využití zkušební verze. Po jeho odeslání je nabídnuta ke stažení poslední verze PowerDesigneru Jedná se o plnohodnotnou variantu Studio Enterprise. Omezena je pouze zkušební dobou 15 dní, po které je třeba produkt zakoupit. Instalace umožňuje zvolit instalované funkce programu a nesetkali jsme se při ní s žádnými problémy. PowerDesigner neobsahuje českou lokalizaci. Na následujícím obrázku je znázorněna úvodní nabídka po spuštění programu

17 5.2.2 Požadavky na systém Procesor Místo na pevném disku Operační paměť Operační systém Obr. 6 Uživatelské rozhraní Sybase PowerDesigner Doporučené požadavky Pentium 1.5 GHz alespoň 500 MB 1 GB RAM Microsoft Windows XP, Vista, 7 nebo Microsoft Windows Server 2003, 2008 Tab. 2 PowerDesigner požadavky na systém [Sybase, 2010] Konceptuální úroveň Po otevření nabídky New Model nabídne PowerDesigner několik kategorií vytvářených modelů. Lze volit ze skupin Business, Information, Application, Technology a Requirements and Planning. Konceptuální datový model nalezneme v kategorii Information pod názvem Conceptual Data. Po jeho výběru se zobrazí obrazovka, pomocí které můžeme začít model vytvářet. V horní části se nachází klasicky uspořádané menu. Pod ním jsou ikonky zastupující nejčastěji využívané funkce. Samozřejmostí je možnost volby, které skupiny funkcí zde chceme mít zastoupené. Největší část okna 17

18 zabírá plocha pro vytváření samotného modelu. V její blízkosti je vhodné mít umístěnou paletu, kde nalezneme jednotlivé prvky konceptuálního datového modelu. Po levé straně nalezneme stromovou strukturu. Tam se ve složkách nacházejí vytvořené prvky našeho modelu. Spodní část okna je vyhrazena pro výpis informací o prováděných činnostech. Ještě musíme dodat, že strukturu obrazovky lze libovolně upravovat. Popsané uspořádání odpovídá výchozímu nastavení programu. Vytvoření entity je nejjednodušší kliknutím na paletku s prvky a následným umístěním prvku na plochu pro vytvářený model. Ikonky na paletě lze většinou dobře identifikovat, při nejistotě lze najetím kurzorem na ikonku vyvolat její název. Vytvořit novou entitou jde i z nabídky menu Model. Pro úpravu vlastností entity je možné ji rozkliknout. Zobrazí se tabulka se záložkami. První z nich (General) slouží především pro nastavení názvu, kódového označení a případného komentáře. Záložka Attributes umožňuje nastavit jednotlivé atributy dané entity. Nastavujeme zde jejich název a kódové označení, dále lze vybrat jejich datový typ z dostatečné nabídky podporovaných formátů. Pro nastavení atributu jako primárního klíče je nutné zaškrtnout položku P (Primary), pro povinnost vyplnění atributu položku M (Mandatory). V záložce Identifers se automatický objevují jednoznačné identifikátory entity. Další záložky obsahují pokročilá nastavení a v každé záložce je odkaz na příslušnou oblast nápovědy. Entity se propojují pomocí prvku Relationship, jenž je součástí paletky. Po jeho výběru se jednoduše propojí vybrané entity. Opět lze nastavit jeho vlastnosti poklepáním na jeho umístění, případně výběrem ze stromové nabídky prvků. Na první záložce nastavujeme obdobně jako u entity název vztahu. Další záložka slouží k výběru kardinality. K dispozici jsou všechny varianty 1:1 (v programu pojmenovaná One One), 1:N (One Many) a N:N (Many Many). Dále je zde možnost zvolit povinný vztah pro jednu ze stran, nebo pro obě. Není tudíž problém v konceptuálním modelu zachytit, aby hráč měl povinně členství v právě jednom klubu. PowerDesigner umí na konceptuální úrovni znázornit vztah s atributy (asociační tabulku). Prvek se nazývá Association Link. Umožňuje nastavit atributy vztahu včetně datových typů a samozřejmě kardinalitu. Hotový konceptuální datový model ilustruje Obr

19 Obr. 7 PowerDesigner model na konceptuální úrovni Výchozí notace v sobě kombinuje dva různé přístupy. Jedná se o notace Entity/Relationship a Merise. Důvodem této kombinace je podpora jednak jednoduchých vztahů bez atributů a také asociačních tabulek. Ve výsledku to může působit trochu rušivě (jinak označená kardinalita u vztahu s atributy), ale funkčnost takovéhoto řešení je plně dostačující. Dále jsou k dispozici notace IDEF1X a Barkerova notace. Jejich výběr je možný v menu Model Options. Výchozí notace nám poskytuje všechny potřebné informace. U entity je zřejmý její název a jména atributů. Primární klíč je podtržený a označený zkratkou <pi>, povinné položky zkratkou <M>. U každého atributu též nalezneme zkratku vyjadřující datový typ. Vztahy jsou označeny názvem, kardinalita je vyznačena běžným způsobem (pouze u vztahu s atributy ve formátu M:N). Konceptuální datový model se ukládá do samostatného souboru s koncovkou *.cdm Technologická úroveň Technologický model databáze je možné vygenerovat z konceptuální úrovně návrhu. V programu PowerDesigner stačí vybrat v menu položku Generate Physical Data Model. Následně se otevře nabídka, kde se upravují vlastnosti generování modelu. Nalezneme zde především možnosti, zda chceme vytvořit nový model, či aktualizovat stávající, dále můžeme vybrat, které entity se mají generovat a které nikoliv. Poté se již vytvoří technologický model, zachycují strukturu tabulek budoucí databáze. V našem případě byl vygenerován zcela korektně. Problém nebyl ani se vztahem M:N, který navíc obsahoval vlastní atributy. Model je samozřejmě možné dále upravovat. Vhodné je zkontrolovat a upravit nastavení týkající se referenční integrity. To nalezneme poklepáním na vztah mezi tabulkami (případě výběrem ze stromové nabídky prvků) v záložce Integrity. Dostupné typy referenční integrity jsou None, Restrict, Cascade, Set null, Set Default. U povinných vztahů je standardně nastaveno Restrict. V našem případě to zabraňuje například vymazání klubu, který 19

20 zahrnuje ještě členy (protože každý hráč musí být členem nějakého klubu). Změnou referenční integrity na kaskádový typ by po vymazání klubu zmizeli i všichni jeho členové z tabulky hráčů. Různé typy referenční integrity lze nastavit zvlášť pro úpravu (update) řádku a pro jeho vymazání (delete). Technologický model je možné samostatně vytvořit zvolením položky Physical Data v menu New Model. Po jeho dokončení lze zpětně vygenerovat konceptuální model. Tento postup ovšem nedoporučujeme. Obr. 8 PowerDesigner model na technologické úrovni Na Obr. 8 vidíme vygenerovaný technologický model. Zobrazuje schéma tabulek naší databáze. V rámci každé tabulky jsou uvedeny jejich sloupce včetně datových typů. Primární klíč je označen jako <pk> a cizí klíč jako <fk>. Model se ukládá do souboru s koncovkou *.pdm Implementační úroveň Pro vygenerování SQL kódu slouží položka v menu Generate Database. Po jejím otevření se zobrazí nabídka týkající se místa uložení a názvu souboru. Formát generovaného souboru je *.sql. V záložce Preview lze prohlédnout generovaný kód a případně ho vykopírovat nebo vytisknout. Na kartě Selection jde vybrat jen určité části (tabulky) databáze. Výběr databázového systému se provádí zvlášť v menu Change Current DBMS. K dispozici je široké množství databázových systémů. Uvést můžeme IBM DB2, INFORMIX SQL, Microsoft SQL Server, ORACLE a mnoho dalších. U každého systému je zpravidla podporováno několik různých verzí. My jsme generovali kód pro ORACLE 11g a zde je ukázka kódu. Za zmínku stojí automatické generování základních indexů a také příkazy drop, které zajišťují, aby nedošlo ke konfliktům s již vytvořenými částmi databáze. 20

21 alter table HRAC drop constraint FK_HRAC_CLENSTVI_KLUB; alter table KLUB drop constraint FK_KLUB_UCAST_V_S_SOUTEZ; alter table TURNAJ drop constraint FK_TURNAJ_PORADA_KLUB; alter table UCAST drop constraint FK_UCAST_UCAST_HRAC; alter table UCAST drop constraint FK_UCAST_UCAST2_TURNAJ; drop index "clenstvi_fk"; drop table HRAC cascade constraints; drop index "ucast_v_soutezi_druzstev_fk"; drop table KLUB cascade constraints; drop table SOUTEZ cascade constraints; drop index "porada_fk"; drop table TURNAJ cascade constraints; drop index UCAST2_FK; drop index UCAST_FK; drop table UCAST cascade constraints; /*==============================================================*/ /* Table: HRAC */ /*==============================================================*/ create table HRAC ( RC CHAR(10) not null, PRIJMENI VARCHAR2(25) not null, JMENO VARCHAR2(15) not null, KLUB CHAR(5) not null, BH INTEGER not null, PLATNOST_REG DATE not null, constraint PK_HRAC primary key (RC)); /*==============================================================*/ /* Index: "clenstvi_fk" */ /*==============================================================*/ create index "clenstvi_fk" on HRAC ( KLUB ASC); 21

22 /*==============================================================*/ /* Table: KLUB */ /*==============================================================*/ create table KLUB ( CISLO CHAR(5) not null, NAZEV_KLUBU VARCHAR2(40) not null, ULICE VARCHAR2(30) not null, MĚSTO VARCHAR2(30) not null, PSC CHAR(5) not null, SOUTEZ CHAR(4), POCET_DVORCU INTEGER not null, constraint PK_KLUB primary key (CISLO)); /*==============================================================*/ /* Index: "ucast_v_soutezi_druzstev_fk" */ /*==============================================================*/ create index "ucast_v_soutezi_druzstev_fk" on KLUB ( SOUTEZ ASC); /*==============================================================*/ /* Table: SOUTEZ */ /*==============================================================*/ create table SOUTEZ ( ZKRATKA CHAR(4) not null, NAZEV_SOUTEZE VARCHAR2(25) not null, OBLAST VARCHAR2(20) not null, MICE VARCHAR2(30) not null, constraint PK_SOUTEZ primary key (ZKRATKA)); /*==============================================================*/ /* Table: TURNAJ */ /*==============================================================*/ create table TURNAJ ( KOD CHAR(6) not null, NAZEV_TURNAJE VARCHAR2(50) not null, PORADATEL CHAR(5) not null, OD DATE not null, DO DATE not null, PLAN_POCET_UC INTEGER not null, STARTOVNE NUMBER(8,2) not null, constraint PK_TURNAJ primary key (KOD)); /*==============================================================*/ /* Index: "porada_fk" */ /*==============================================================*/ create index "porada_fk" on TURNAJ ( PORADATEL ASC); 22

23 /*==============================================================*/ /* Table: UCAST */ /*==============================================================*/ create table UCAST ( HRAC CHAR(10) not null, TURNAJ CHAR(6) not null, VYSLEDEK VARCHAR2(15) not null, BODY INTEGER not null, constraint PK_UCAST primary key (HRAC, TURNAJ)); /*==============================================================*/ /* Index: UCAST_FK */ /*==============================================================*/ create index UCAST_FK on UCAST ( HRAC ASC); /*==============================================================*/ /* Index: UCAST2_FK */ /*==============================================================*/ create index UCAST2_FK on UCAST ( TURNAJ ASC); alter table HRAC add constraint FK_HRAC_CLENSTVI_KLUB foreign key (KLUB) references KLUB (CISLO); alter table KLUB add constraint FK_KLUB_UCAST_V_S_SOUTEZ foreign key (SOUTEZ) references SOUTEZ (ZKRATKA) on delete set null; alter table TURNAJ add constraint FK_TURNAJ_PORADA_KLUB foreign key (PORADATEL) references KLUB (CISLO); alter table UCAST add constraint FK_UCAST_UCAST_HRAC foreign key (HRAC) references HRAC (RC); alter table UCAST add constraint FK_UCAST_UCAST2_TURNAJ foreign key (TURNAJ) references TURNAJ (KOD); 23

24 5.2.6 Další funkce Pro práci na větších projektech je výhodou integrovaná podpora úložiště. Ta umožňuje pohodlnou práci na modelu z různých míst a je vhodná pro práci více osob najednou. V menu ji nalezneme pod položkou Repository. Tato funkce je ale dostupná pouze u verzí programu s přídomkem Enterprise Shrnutí PowerDesigner je výkonný nástroj pro modelování. Jeho možnosti jsou velmi široké. Mimo datové analýzy pokrývá i další oblasti návrhu podnikových informačních systémů. Daní za rozsah podporovaných činností je částečná nepřehlednost menu. Pokročilejší funkce je občas obtížnější nalézt. V případě nouze pomůže dobře zpracovaná nápověda. Užití programu je vhodné pro mírně pokročilé uživatele (v oblasti modelování) i pro větší projekty. Překážkou může být vyšší cena za licenci programu Výhody pokrývá široké spektrum analýz (procesní, datová, objektová) plně podporuje princip tři architektur velké množství podporovaných databázových systémů obsahuje pokročilé funkce pravidelné vydávání nových verzí Nevýhody obtížnější orientace v menu vyšší cena chybí česká lokalizace 24

25 5.3 Toad Data Modeler 3.6 Toad Data Modeler je profesionální databázový modelovací CASE nástroj, který umožňuje navrhovat ER diagramy pro rozsáhlé databáze různých druhů. Je vyvíjen českou společností CHARONWARE, s. r. o., která je součástí společnosti Quest Software, Inc., proto je tedy nástroj Toad Data Modeler někdy označován právě jako produkt této společnosti. Předchůdcem Toad Data Modeleru bylo velmi oblíbené CASE Studio, jehož vývoj byl v roce 2006 ukončen. Poslední verzí je verze Důvodem bylo sloučení společnosti CHARONWARE, s. r. o. se společností Quest Software, Inc. a vznik nového projektu, který se zabývá vývojem zde popisovaného Toad Data Modeleru Úvod Nástroj obsahuje kompletní funkcionalitu potřebnou pro návrh databáze od její počáteční fáze návrh na konceptuální úrovni, až po fázi konečnou implementační úroveň. Možnost generování modelů z jedné úrovně do druhé je velkým přínosem programu, protože jednak šetří čas a pracnost návrhu a pak také zamezuje vzniku zbytečných chyb při tvorbě opakovaného návrhu jedné databáze pro více úrovní. Při návrhu je možné zvolit jednu z dvou podporovaných notací a to buď velmi často používanou IE notaci (Information Engineering), anebo notaci IDEF1X (Integration Definition for Information Modeling). Změna vybrané notace je možná i v průběhu návrhu a je velmi jednoduchá (na liště menu po stisku tlačítka Notation vybereme požadovanou volbu). Toad Data Modeler je vydáván ve dvou verzích, plné a freeware verzi, na webových stránkách společnosti je uveden odkaz pro jejich stažení 3. Plná verze se stahuje nejprve jako verze s trial licencí na 15 dní a po zakoupení a zadání licenčního klíče, který je možné získat na stránkách, na něž je také přímo uveden odkaz ze stránek nástroje a jehož cena je buď 435 nebo 479$, se její licence prodlouží na neurčito. Pro stažení trial verze je nutné se nejprve zaregistrovat, přičemž registrace je poměrně zdlouhavá. V případě verze freeware se nejedná o pravý freeware, ale o časově i funkčně omezenou plnou verzi. Časové omezení je buď na 120 dní od chvíle prvního spuštění nástroje, nebo do 31. ledna 2011, podle toho, co nastane dříve. Funkční omezení zahrnují především ukládání návrhu modelu, náhled a tisk modelu, generování reportů a generování SQL skriptu v případě, že je v návrhu více než 25 entit. Současná a zároveň i zde testovaná verze nástroje nese označení Toad Data Modeler V případě instalace nástroje, plné i freeware verze, je nutné mít správě registrovanou knihovnu VBScript, jinak instalace končí chybou. Pokud se tato chyba vyskytne, je nutné knihovnu znovu registrovat, poté by již měla instalace proběhnout v pořádku. Základní uživatelské rozhraní je viditelné na Obr. 9. Další prvky potřebné pro modelování se objeví vždy až při otevření konkrétního pracovního prostoru. Prvky pro návrh konceptuální úrovně se zobrazí až po otevření prostoru pro návrh logického modelu apod. Více prvků a tedy komplexnější pohled na uživatelské rozhraní nástroje poskytuje Obr. 10 a Obr. 11 v kapitolách

26 5.3.2 Požadavky na systém Obr. 9 Ukázka základního uživatelského rozhraní nástroje Toad Data Modeler Minimální požadavky Doporučené požadavky Procesor Pentium IV Pentium dual core Místo na pevném disku 100 MB 200 MB Operační paměť 256 MB 1 GB Operační systém Windows 2000 Professional Edition (Service Pack4) Windows XP (32-bit nebo 64-bit) Windows Vista (32-bit nebo 64-bit) Windows Server 2003 (32-bit nebo 64-bit) Windows Server 2008 (32-bit nebo 64-bit) Windows 7 (32-bit nebo 64-bit) Tab. 3 Toad Data Modeler požadavky na systém [Quest-Software, 2010] Konceptuální úroveň Nástroj umožňuje navrhovat modely databáze jak na konceptuální, tak i na technologické úrovni, přičemž je možné jednotlivé modely vzájemně přegenerovávat, tedy z modelu konceptuální úrovně vygenerovat model technologické úrovně a obráceně. Nejdříve se zaměříme na úroveň konceptuální. Konceptuální model, pro nějž je velmi často používáno i označení logický model, můžeme pomocí Toad Data Modeleru navrhnout poměrně snadno. Nejdříve je nutné vytvořit si pracovní prostředí pro tvorbu logického modelu a to poměrně standardním způsobem, výběrem možnosti File z lišty menu a dále zvolením možnosti New Model. Objeví se okno, kde je na výběr z dvou záložek Physical Data Model a Logical Data Model. Pokud chceme modelovat na konceptuální úrovni, přepneme na záložku Logical Data Model a vybereme Logical Model. V tuto chvíli máme vše připravené a můžeme začít se samotným modelováním. Jednotlivé prvky můžeme vybírat buď z nabídky Objects z lišty menu, nebo přímo z vodorovné nástrojové lišty, která je přístupná při tvorbě logického modelu. Další možností, je použít klávesové zkratky. Pro vkládání entit a jim podobných prvků je nutné kliknout na příslušnou ikonu v nástrojové liště (v případě entit na tlačítko entity) a poté znovu kliknout do pracovního prostoru. Podobně funguje princip i u vztahových prvků, jen s tím rozdílem, že při vkládání prvku do modelu musíme kliknout dvakrát a to na obě koncové entity. Při vložení nového prvku je vždy nutné znovu kliknout na příslušnou ikonu v nástrojové liště, což může být v případě vkládání velkého množství prvků značně zdržující. 26

27 Vlastnosti jednotlivých prvků můžeme upravovat přímo po dvojkliku na příslušný prvek v nově otevřeném okně vlastností. U entit můžeme takto upravovat například název, přidávat atributy, určovat jednoznačný identifikátor a další. U vztahů je možné kromě jiného také změnit název, určit kardinalitu a zároveň si otevřít a upravit vlastnosti dvou koncových entit vztahu. Na Obr. 10 je vidět uživatelské rozhraní, které přísluší návrhu na konceptuální úrovni. Obr. 10 Toad Data Modeler model na konceptuální úrovni Ukázkový model je navržen v IE notaci, jednoznačné identifikátory, neboli primární klíče jsou označeny hned třemi způsoby a to červenou barvou, symbolem klíče a zkratkou PUI (Private Unique Identifier). Název entity je již tradičně v její horní části, písmenem M je znázorněno, zda jsou jednotlivé atributy povinné a název vztahu se nachází vždy téměř uprostřed vztahu. Dá se říct, že co se týče zpracování návrhu je Toad Data Modeler velmi podobný mnohým dalším nástrojům pro návrh databází a jeho používání by po bližším seznámení nemělo dělat problémy a zároveň vzniklý model by měl být dobře čitelný. Ve chvíli, kdy je logický model navržen, je většinou nutné přejít na technologickou úroveň. I tento přechod má Toad Data Modeler poměrně elegantně vyřešen. 27

28 5.3.4 Technologická úroveň Model na technologické úrovni se v Toad Data Modeleru nazývá Fyzický model a je vždy navržen už pro konkrétní databázový systém. Pokud máme zpracován logický model databáze, je tvorba fyzického modelu velmi rychlá a jednoduchá. Stačí v nabídce tlačítka File v liště menu nalézt možnost Sync & Convert a dále zvolit Simple Model Conversion. V tabulce vybereme databázový systém, pro který chceme generovat (v našem případě Oracle 11g Release 2) a stiskneme Convert. Po vygenerování by se nám měl zobrazit kompletní fyzický model včetně všech vztahů a měly by být označeny primární i cizí klíče. Může se stát, že se cizí klíče nezobrazí, je to pouze z důvodu velikosti rámečku entity, proto je dobré entity buď manuálně upravit nebo na každé entitě (případně po označení všech entit) v kontextovém menu zatrhnout možnost Recalculate size. Podobně lze z fyzického modelu vygenerovat zpětně model logický. Toad Data Modeler velmi šetří čas a práci při přechodu z jedné úrovně na druhou a to v jakémkoli pořadí. Pokud chceme navrhovat fyzický model, aniž bychom jej vygenerovali, postupujeme podobně, jako při návrhu logického modelu v předchozí kapitole. V liště menu zvolíme File New Model a na záložce Physical Data Model vybereme, pro který databázový systém je model určen. Tento výběr je velmi důležitý, protože podle něj se bude následně generovat i SQL kód, o kterém je více popsáno v následující kapitole. Pokud bychom chtěli model převést na jiný databázový systém, musíme jej opět přegenerovat pomocí příkazu Sync & Convert. Vkládání jednotlivých prvků a úprava jejich vlastností je stejná, jako u modelování konceptuální úrovně a proto se jí v této kapitole nebudeme už více zabývat. Na technologické úrovni je možné velmi jednoduše definovat například pohledy (VIEW) a vztahy M:N (M:N Relationship), protože pro ně na nástrojové liště existují samostatné ikony a tedy pro přidání například vztahu M:N stačí pouhá dvě kliknutí. Uživatelské rozhraní, určené pro návrh technologické úrovně, je zobrazeno na Obr

29 Obr. 11 Toad Data Modeler model na technologické úrovni Jednoznačné identifikátory jsou opět barevně odlišeny, primární klíč červenou barvou, znakem červeného klíče a označením PK (Primary Key), cizí klíč zelenou barvou, znakem zeleného klíče a označením FK (Foreign Key) a primární cizí klíč modrou barvou, znakem modrého klíče a označením PFK (Primary Foreign Key). Zda jsou atributy povinné, určuje zkratka NN (NOT NULL). Pokud máme vytvořen fyzický model databáze, můžeme přistoupit k implementační úrovni, tedy k tvorbě samotného kódu tvořícího databázi, který Toad Data Modeler opět umí vygenerovat přímo z vytvořeného fyzického modelu. Více se implementační úrovní zabývá následující kapitola. 29

30 5.3.5 Implementační úroveň Toad Data Modeler umí generovat SQL kód pro různé databázové systémy. Podporuje tyto: DB2 UDB v. 8 (LUW), 9.0 (LUW), 9.5 (LUW), 9.7 (LUW) DB2 z/os v. 9 MS Access 2000/2002/2003 MS SQL Azure MS SQL Server 2000, 2005, 2008 MySQL 5.0, 5.1 Oracle 9i, 10g, 11g R1, 11g R2 PostgreSQL 8.1, 8.2, 8.3, 8.4 Sybase ASE 12.5, 15 Sybase SQL Anywhere 11 Funkce generování SQL je přístupná třemi různými způsoby, ale vždy jen v případě, že je otevřen fyzický model, podle kterého bude kód generován. Databázový systém, pro který chceme SQL generovat, se vybere ještě před tím, než vůbec začneme fyzický model databáze tvořit. Znamená to tedy, že pokud máme například model určený pro databázový systém Oracle 11g, bude i SQL script příslušet tomuto databázovému systému. Jednou z možností, jak se dostat k nastavení generování, je přes nástrojovou lištu, stiskem tlačítka se zelenou šipkou. Dále pak nabídku otevřeme i přes tlačítko Model v liště menu, zvolením možnosti Generate DDL Script. Poslední možnost je asi nejsnazší, stačí stisknout tlačítko F9. Všemi těmito třemi možnostmi se dostaneme do nabídky, kde vybereme umístění, kam se má SQL kód vygenerovat, zvolíme, jestli chceme, aby byl výsledný soubor přímo jako script s příponou.sql, či pouze jako textový soubor.txt a můžeme nastavit i další různé detaily. Pro náš konkrétní příklad jsme generovali SQL kód pro databázový systém ORACLE 11g. Výsledek je následující: /* Created: Modified: Model: RE Oracle 11g Release 2 Database: Oracle 11g Release 2 */ -- Create tables section Table Hráč CREATE TABLE "Hráč"( "rodné číslo" Char(10 ) NOT NULL, "příjmení" Varchar2(25 ) NOT NULL, "jméno" Varchar2(15 ) NOT NULL, "bodová hodnota" Integer NOT NULL, "platnost registrace do" Date NOT NULL, "číslo klubu" Char(5 ) NOT NULL) 30

31 / -- Add keys for table Hráč ALTER TABLE "Hráč" ADD CONSTRAINT "Hráč_PK" PRIMARY KEY ("rodné číslo") / -- Table Klub CREATE TABLE "Klub"( "číslo klubu" Char(5 ) NOT NULL, "název klubu" Varchar2(40 ) NOT NULL, "ulice" Varchar2(30 ) NOT NULL, "město" Varchar2(30 ) NOT NULL, "psč" Char(5 ) NOT NULL, "počet dvorců" Integer NOT NULL, "zkratka" Char(4 )) / -- Add keys for table Klub ALTER TABLE "Klub" ADD CONSTRAINT "Klub_PK" PRIMARY KEY ("číslo klubu") / -- Table Soutěž družstev CREATE TABLE "Soutěž družstev"( "zkratka" Char(4 ) NOT NULL, "název soutěže" Varchar2(25 ) NOT NULL, "oblast" Varchar2(20 ) NOT NULL, "míče" Varchar2(30 ) NOT NULL) / -- Add keys for table Soutěž družstev ALTER TABLE "Soutěž družstev" ADD CONSTRAINT "Soutěž družstev_pk" PRIMARY KEY ("zkratka") / -- Table Turnaj CREATE TABLE "Turnaj"( "kód turnaje" Char(6 ) NOT NULL, "název turnaje" Varchar2(50 ) NOT NULL, "termín od" Date NOT NULL, "termín do" Date NOT NULL, "plánovaný počet účastníků" Integer NOT NULL, "startovné" Number NOT NULL, "číslo klubu" Char(5 ) NOT NULL) / -- Add keys for table Turnaj ALTER TABLE "Turnaj" ADD CONSTRAINT "Turnaj_PK" PRIMARY KEY ("kód turnaje") / 31

32 -- Table Účast na turnaji CREATE TABLE "Účast na turnaji"( "výsledek" Varchar2(15 ) NOT NULL, "body" Integer NOT NULL, "rodné číslo" Char(10 ) NOT NULL, "kód turnaje" Char(6 ) NOT NULL) / -- Add keys for table Účast na turnaji ALTER TABLE "Účast na turnaji" ADD CONSTRAINT "Účast na turnaji IDX" PRIMARY KEY ("rodné číslo","kód turnaje") / -- Create relationships section ALTER TABLE "Účast na turnaji" ADD CONSTRAINT "FK_UCAST_UCAST_HRAC" FOREIGN KEY ("rodné číslo") REFERENCES "Hráč" ("rodné číslo") / ALTER TABLE "Účast na turnaji" ADD CONSTRAINT "FK_UCAST_UCAST2_TURNAJ" FOREIGN KEY ("kód turnaje") REFERENCES "Turnaj" ("kód turnaje") / ALTER TABLE "Turnaj" ADD CONSTRAINT "POŘÁDÁ" FOREIGN KEY ("číslo klubu") REFERENCES "Klub" ("číslo klubu") / ALTER TABLE "Klub" ADD CONSTRAINT "ÚČAST V SOUTĚŽI DRUŽSTEV" FOREIGN KEY ("zkratka") REFERENCES "Soutěž družstev" ("zkratka") / ALTER TABLE "Hráč" ADD CONSTRAINT "ČLENSTVÍ" FOREIGN KEY ("číslo klubu") REFERENCES "Klub" ("číslo klubu") / 32

33 5.3.6 Další funkce Toad Data Modeler obsahuje ještě mnohé další funkce. Na webových stránkách produktu je uveden výčet klíčových vlastností a funkcí nástroje, které jsou následující: logický i fyzický model konverze z logického modelu do fyzického verifikace modelu generování SQL generování alter scriptů pro Oracle 10g, 9 a MS SQL Server 2008 a 2005 správce verzí (s možností přidat do projektu soubory nevytvořené v TDM) porovnávání modelů, Model Update a Model Merge HTML a RTF reporty podpora XML, XSL, generování XSD nemodální dialogy, dokovatelné panely, lupa, navigátor a další GUI vylepšení podpora pro Unicode UNDO a REDO editovatelné formuláře Mezi tyto a mnohé další patří zajisté i tzv. funkce Reverse Engineering, někdy v českém překladu označována jako reverzní inženýrství. V případě Toad Data Modeleru se jedná o možnost zpětně vytvořit fyzický model databáze z SQL scriptu. Pokud tedy máme k dispozici pouze SQL kód, můžeme k němu bez problému získat jak fyzický, tak logický model databáze. Postup není nijak složitý. Přes možnost File v liště menu vybereme položku Reverse Engineering. Otevře se průvodce reverzním inženýrstvím, kde musíme nastavit potřebné údaje. Nejdříve zvolíme, zda se chceme připojit přímo na databázový server, kde je databáze provozována, a potřebná data stáhnout odtud, či zda je SQL script umístěn lokálně v souboru na pevném disku. V našem případě jsme zkoušeli druhou variantu a budeme ji i dále popisovat. Nyní označíme, pro který databázový systém je script určen (např. Oracle 11g Release 2) a pokračujeme tlačítkem Next. Zadáme cestu k souboru SQL scriptu na pevném disku. Ostatní obrazovky už jen potvrdíme stiskem tlačítka Next. Je zde možné měnit další detaily, ale pro správné zpracování reverzního inženýrství to není nezbytné. Posledním krokem je potvrzení tlačítka Execute. Nyní by se měla objevit hláška o dokončení reverzního inženýrství, obrazovku Reverse Engineering můžeme tedy zavřít. Pokračujeme opět tlačítkem File a výběrem Connections. Zde na kartě Connections vybereme výsledek námi provedeného reverzního inženýrství (pokud je jich zde více, je nejlepší řídit se podle uvedeného data a času), stiskneme tlačítko Connect a poté Live RE. Zobrazí se obrazovky Object Palette s vypsanými entitami požadovaného modelu. Vybereme všechny entity a poté jednoduchým způsobem drag and drop, tedy chytit a přetáhnout, přesuneme entity do pracovního prostoru pro návrh fyzického modelu, který by měl být automaticky otevřen. Pokud není, je nutné jej otevřít. Teď už máme model vytvořen, stačí pouze upravit rozmístění ikon a můžeme s ním dále pracovat. Z tohoto modelu můžeme dříve popsaným způsobem vygenerovat logický model databáze. Pro přiblížení celého postupu slouží několik následujících obrázků s nejdůležitějšími obrazovkami. 33

34 Obr. 12 Reverse Engineering výběr, odkud chceme načíst požadovaná data Obr. 13 Reverse Engineering obrazovka pro uvedení cesty k souboru na pevném disku 34

35 Obr. 14 Reverse Engineering poslední obrazovka před spuštěním reverzního inženýrství Obr. 15 Reverse Engineering obrazovka Connection 35

36 Obr. 16 Reverse Engineering obrazovka Object Palette a vygenerovaný, neupravený model Shrnutí Toad Data Modeler je velmi propracovaný CASE nástroj pro návrh databáze, který se může rovnat s ostatními nástroji podobného rozsahu. Po bližším seznámení s uživatelským rozhraním je navrhování vždy velmi rychlé a efektivní, výsledný návrh je graficky velmi dobře zpracován a zobrazuje všechny potřebné údaje. Nástroj obsahuje velké množství funkcí, které zde není možné všechny dopodrobna představit, proto zájemcům jednoznačně doporučujeme jeho vyzkoušení Výhody mnoho užitečných funkcí reverzní inženýrství po bližším seznámení poměrně jednoduché ovládání dobrá úroveň grafického zpracování modelů ve srovnání s ostatními CASE nástroji pro návrh databází podobného rozsahu nízká cena Nevýhody omezená funkcionalita freeware verze časové omezení freeware verze složitá orientace v uživatelském rozhraní pro začátečníka nutnost kliknout na příslušné tlačítko prvku pro každé vložení do modelu 36

37 5.4 XTG Data Modeller Společnost XTG Systems, s.r.o. patří mezi české IT společnosti, na trhu ji nalezneme od roku Zaměřuje se především na zakázkový vývoj systémů, v poslední době vyvíjí ale také nástroje typu CASE a databázové nástroje. V této práci se zaměříme především na CASE. V nabídce společnosti nalezneme dva nástroje tohoto typu: XTG Data Modeller, kterým se bude dále detailně zabývat, a XTG UniModeller, který představuje univerzální nástroj pro modelování procesů, vývojových diagramů atd. Při popisu nabídky společnosti XTG Systems, s.r.o. nesmíme zapomenout na závodní (podnikový) stravovací systém Obelix Úvod XTG Data Modeller (XTGDM 2.3.4) představuje CASE nástroj pro datové modelování. Jedná se o produkt nižší třídy, samozřejmě kategorii odpovídá jeho cena, ale i prostředí a samotné funkce programu. Nejaktuálnější verze je Produkt je dostupný ve zkušební verzi na internetových stránkách společnosti XTG Systems, s.r.o. 4 Ve zkušební verzi není časové omezení, ale omezení týkající se funkčností programu. Plnohodnotnou funkcionalitu lze zkoušet pouze u modelů obsahujících maximálně 4 entity, v opačném případě nelze model ukládat, ani generovat SQL skript a HTML dokumentaci. Pokud se uživatel rozhodne pro nákup, je možné jej uskutečnit opět přímo na stránkách společnosti 5. V současné době jsou dostupné následující licence. V případě zájmu o větší počet licencí lze se společností dojednat individuální cenu. Licence Cena XTG Data Modeller 2.3.x - SINGLE Kč XTG Data Modeller 2.3.x - SINGLE LITE* Kč XTG Data Modeller 2.3.x - SITE MULTI Kč XTG Data Modeller 2.3.x - UNLIMITED MULTI Kč * Omezení maximálního počtu entit (50). Neobsahuje databázovou konektivitu a reengineering Tab. 4 Licence XTG Data Modeller Hlavní oblastí použití XTGDM je především datové modelování. Program ale obsahuje i další funkce, jako například podporu tvorby multidimenzionálních modelů, porovnávání modelů, reversní engineering a prohlížení databází. Uživatelské prostředí je poměrně strohé, ale dostačující pro základní práci. Ukázku ilustruje Obr. 17. Tento obrázek ukazuje standardní prostředí s výchozím nastavením a vzorovým modelem od společnosti XTG Systems, s.r.o

38 5.4.2 Požadavky na systém Obr. 17 Uživatelské prostředí XTG Data Modeller Minimální požadavky Procesor - Místo na pevném disku 2 MB Operační paměť - Operační systém Microsoft Windows 95, 98, ME, NT, 2000, XP, Vista, 7 Tab. 5 XTG Data Modeller požadavky na systém [XTG, 2010] Konceptuální úroveň Program XTG Data Modeller přichází s odlišným principem práce tvorby modelů na jednotlivých úrovních. Můžeme říci, že v podstatě spojuje konceptuální a technologickou úroveň dohromady. Při tvorbě entit rovnou zadáváme jména a vlastnosti pro obě úrovně. Poté pouze přepínáme pohled mezi jednotlivými úrovněmi, neexistuje zde tedy žádné generování technologického modelu atd. Tuto vlastnost bychom měli určitě zařadit mezi nevýhody. I přestože společnost XTG Systems, s.r.o. téměř spojila konceptuální a technologickou úroveň v našem popisu produktu se pokusíme dodržet princip P3A a tyto úrovně oddělit a nahlížet na každou zvlášť, tak jak je popsáno v kapitole 3. Samozřejmě začneme konceptuální úrovní. Po založení nového projektu je potřeba nastavit pohled, který program označuje jako Logical view (pohled vybereme v menu pod položkou view). Pro vkládání všech prvků zde neexistuje žádný panel nástrojů, musíme použít kontextové menu, které vyvoláme kliknutím pravým tlačítkem myši na plochu projektu. Novou entitu vytvoříme pomocí funkce Nová TABULKA (entita). Na pracovní ploše projektu se nám objeví nová zatím prázdná entita, kterou musíme editovat. Do editačního okna se dostaneme přes funkci Detail entity, kterou vyvoláme z kontextového menu entity. Obr. 18 ukazuje editační okno entity. Zde již volíme jméno entity a to jak pro konceptuální, tak pro technologickou úroveň. Detail entity slouží také pro přidávání atributů, u kterých opět volíme názvy pro obě úrovně. Můžeme použít již definované datové typy a popřípadě definovat vlastní pomocí funkce User-defined datatype (UDD). Definovaných datových typů program obsahuje přibližně 30, nalezneme zde znakové (CHAR, VARCHAR atd.), číselné (INTEGER, DECIMAL, FLOAT atd.), časové (DATE atd.) a mnoho dalších. Uživatelem definované datové typy jsou uloženy přímo v modelu. Bohužel v současné verzi neexistuje import vlastních datových typů z jednoho 38

39 modelu do druhého. Primární klíč entity vytvoříme klasickým zaškrtnutím položky PK. Ohledně povinnosti atributů, zde nenalezneme obvyklou položku mandatory, ale je nutné použít možnost NN (Not Null), kterou aktivujeme zaškrtnutím. Obr. 18 XTG Data Modeller detail entity Vztahy mezi jednotlivými entitami tvoříme opět přes kontextové menu (vyvolané pravým tlačítek na pracovní ploše), kde použijeme funkci Nová vazba. Na výběr máme z dvou vazeb: PK vazba (definující cizí klíč jako součást primárního klíče) a FK vazba (definující pouze cizí klíč). Pro tvorbu vazby je dále nutné kliknout na zdrojovou a poté až na cílovou entitu. V případě chyby během tohoto kroku již nelze pořadí změnit, je potřeba vazbu odstranit a vytvořit novou. Program nám umožňuje vytvářet vazby typu: 1:1 a 1:N, bohužel nelze vytvořit vztah M:N. Jakmile máme vztah vytvořený, můžeme jej editovat přes funkci Detail vazby, kterou vyvoláme opět z kontextového menu vazby. Práce s touto funkcí je velmi obdobná výše popsané funkci Detail entity. Opět zde volíme jméno a to jak pro konceptuální, tak pro technologickou úroveň. Dále máme možnost upravit kardinalitu vazby a další parametry. Program nám také umožňuje definovat pohledy, k tomuto nám slouží funkce Nové VIEW, kterou je možné vyvolat z kontextového menu. Na pracovní plochu projektu se nám poté umístí nový prázdný pohled, který upravíme pomocí funkce Upravit, vyvolané z kontextového menu pohledu a zde již poté definujeme všechny potřebné parametry. Konceptuální model modelové databáze je znázorněn na následujícím obrázku. 39