Semestrální práce 4IT450

Předmět: 4IT450 Den a čas cvičení: Út 9.15 – 10.45 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

1 Obsah 2

Úvod ................................................................................................................................................ 4

3

Princip tří architektur ...................................................................................................................... 5

4

Modelová databáze ......................................................................................................................... 7

5

CASE nástroje .................................................................................................................................. 8 5.1

Oracle SQL Developer Data Modeler 2.0 ................................................................................ 8

5.1.1

Úvod ................................................................................................................................ 8

5.1.2

Požadavky na systém ....................................................................................................... 9

5.1.3

Konceptuální úroveň ....................................................................................................... 9

5.1.4

Technologická úroveň ................................................................................................... 11

5.1.5

Implementační úroveň .................................................................................................. 12

5.1.6

Další funkce ................................................................................................................... 15

5.1.7

Shrnutí ........................................................................................................................... 15

5.2

PowerDesigner 15.2 .............................................................................................................. 16

5.2.1

Úvod .............................................................................................................................. 16

5.2.2

Požadavky na systém ..................................................................................................... 17

5.2.3

Konceptuální úroveň ..................................................................................................... 17

5.2.4

Technologická úroveň ................................................................................................... 19

5.2.5

Implementační úroveň .................................................................................................. 20

5.2.6

Další funkce ................................................................................................................... 24

5.2.7

Shrnutí ........................................................................................................................... 24

5.3

Toad Data Modeler 3.6.......................................................................................................... 25

5.3.1

Úvod .............................................................................................................................. 25

5.3.2

Požadavky na systém ..................................................................................................... 26

5.3.3

Konceptuální úroveň ..................................................................................................... 26

5.3.4

Technologická úroveň ................................................................................................... 28

5.3.5

Implementační úroveň .................................................................................................. 30

5.3.6

Další funkce ................................................................................................................... 33

5.3.7

Shrnutí ........................................................................................................................... 36

5.4

XTG Data Modeller 2.3.4 ....................................................................................................... 37

5.4.1

Úvod .............................................................................................................................. 37

5.4.2

Požadavky na systém ..................................................................................................... 38

5.4.3

Konceptuální úroveň ..................................................................................................... 38

5.4.4

Technologická úroveň ................................................................................................... 40 2

5.4.5

Implementační úroveň .................................................................................................. 41

5.4.6

Další funkce ................................................................................................................... 44

5.4.7

Shrnutí ........................................................................................................................... 44

6

Srovnání CASE nástrojů ................................................................................................................. 45

7

Závěr .............................................................................................................................................. 51

8

Seznam použité literatury ............................................................................................................. 52

9

Seznam obrázků ............................................................................................................................ 53

10

Seznam tabulek ......................................................................................................................... 53

3

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

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, 2000+ 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

Obr. 1 – Princip tří architektur *Řepa, 2000+

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

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

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 Oracle1. 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 (10.1.2.0.2). 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. 5.1.1 Ú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. 3.

1

http://www.oracle.com/technetwork/indexes/downloads/index.html

8

Obr. 3 – Uživatelské prostředí Oracle SQL Developer Data Modeler

5.1.2

Požadavky na systém Minimální požadavky Procesor Místo na pevném disku Operační paměť Operační systém

Další

125 MB min. 512 MB, doporučeno 1 GB Microsoft Windows (XP, Vista, 7 včetně x64) Linux Mac OS X JavaTM 1.6 nebo vyšší Standard Edition Runtime Environment

Tab. 1 – Oracle SQL Developer Data Modeler – požadavky na systém [Oracle, 2009]

5.1.3 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

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

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. 5.1.4 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. 5.

11

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. 5.1.5 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 7.1

12

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: 2.0.0 Build: 584 at: 2010-10-01 16: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" "název klubu" ulice město PSČ "počet dvorců" zkratka

CHAR (5) NOT NULL , VARCHAR2 (40) NOT NULL , VARCHAR2 (30) NOT NULL , VARCHAR2 (30) NOT NULL , CHAR (5) NOT NULL , INTEGER NOT NULL , CHAR (4) );

ALTER TABLE Klub ADD CONSTRAINT Klub_PK PRIMARY KEY ( "číslo klubu" ) ; CREATE TABLE "Soutěž družstev" ( zkratka CHAR (4) "název soutěže" VARCHAR2 (25) oblast VARCHAR2 (20) míče VARCHAR2 (30)

NOT NULL , NOT NULL , NOT NULL , NOT NULL );

ALTER TABLE "Soutěž družstev" ADD CONSTRAINT "Soutěž družstev_PK" PRIMARY KEY ( zkratka ) ; CREATE TABLE Turnaj ( "kód turnaje" CHAR (6) "název turnaje" VARCHAR2 (50) "termín od" DATE "termín do" DATE "plánovaný počet účastníků" INTEGER startovné NUMBER "číslo klubu" CHAR (5)

NOT NULL , NOT NULL , NOT NULL , NOT NULL , NOT NULL , NOT NULL , NOT NULL);

ALTER TABLE Turnaj ADD CONSTRAINT Turnaj_PK PRIMARY KEY ( "kód turnaje" ) ; 13

CREATE TABLE "Účast na turnaji" ( "Hráč_rodné číslo" CHAR (10) "Turnaj_kód turnaje" CHAR (6) výsledek VARCHAR2 (15) body INTEGER

NOT NULL , NOT NULL , NOT NULL , 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

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ů. 5.1.7 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í. 5.1.7.1      

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

5.1.7.2 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

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] 5.2.1 Ú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 2 799 USD za verzi DataArchitekt až po 5 495 USD za jednu licenci PowerDesigner Studio. [SoftwareMedia.com, 2010] K testování jsme použili trial verzi dostupnou na stránkách společnosti Sybase2. 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 15.2. 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.

2

http://www.sybase.cz/index.php?option=com_content&view=article&id=3&mid=24

16

Obr. 6 – Uživatelské rozhraní Sybase PowerDesigner

5.2.2

Požadavky na systém Procesor Místo na pevném disku Operační paměť Operační systém

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]

5.2.3 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

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. 7.

18

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 , 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. 5.2.4 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

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 a cizí klíč jako . Model se ukládá do souboru s koncovkou *.pdm. 5.2.5 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

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

/*==============================================================*/ /* 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

/*==============================================================*/ /* 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

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. 5.2.7 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. 5.2.7.1 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í

5.2.7.2 Nevýhody   

obtížnější orientace v menu vyšší cena chybí česká lokalizace

24

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 2.25. 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. 5.3.1 Ú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 3.6.7.1. 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 5.3.3 – 5.3.4.

3

http://www.casestudio.com/enu/

25

Obr. 9 – Ukázka základního uživatelského rozhraní nástroje Toad Data Modeler

5.3.2

Požadavky na systém Procesor Místo na pevném disku Operační paměť Operační systém

Minimální požadavky Doporučené požadavky Pentium IV Pentium dual core 100 MB 200 MB 256 MB 1 GB 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]

5.3.3 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

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

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. 11.

28

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

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: 4.10.2010 Modified: 4.10.2010 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

/ -- 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

-- 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

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

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

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

Obr. 15 – Reverse Engineering – obrazovka Connection

35

Obr. 16 – Reverse Engineering – obrazovka Object Palette a vygenerovaný, neupravený model

5.3.7 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í. 5.3.7.1     

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

5.3.7.2    

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

5.4 XTG Data Modeller 2.3.4 Společnost XTG Systems, s.r.o. patří mezi české IT společnosti, na trhu ji nalezneme od roku 2000. 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. 5.4.1 Úvod XTG Data Modeller 2.3.4 (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 2.3.4. 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čnosti5. 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 4 000 Kč XTG Data Modeller 2.3.x - SINGLE LITE* 1 500 Kč XTG Data Modeller 2.3.x - SITE MULTI 12 000 Kč XTG Data Modeller 2.3.x - UNLIMITED MULTI 29 000 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 2.3.4 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.

4 5

http://www.xtg.cz/download/xtgdm_demo_cz.zip http://www.xtg.cz/objednavka.php3

37

Obr. 17 – Uživatelské prostředí XTG Data Modeller

5.4.2

Požadavky na systém Minimální požadavky Procesor Místo na pevném disku Operační paměť Operační systém

2 MB Microsoft Windows 95, 98, ME, NT, 2000, XP, Vista, 7

Tab. 5 – XTG Data Modeller – požadavky na systém [XTG, 2010]

5.4.3 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

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

Obr. 19 – XTG Data Modeller – model na konceptuální úrovni

Vytvořený model nám ukazuje, jak se v programu zobrazí jednotlivé parametry entit a vazeb. Nejprve se zaměříme na entity. Primární klíče jsou označovány symbolem klíče, cizí klíče označuje XTGDM modrým písmem a parametry, které nesmějí být nulové, mají u sebe identifikátor NN. Program ovšem nezobrazuje definované datové typy. Zobrazení vazeb je téměř standardní podle notace konceptuálního schématu (viz Obr. 2). PK vazby jsou zobrazeny žlutým čtverečkem a FK vazby čtverečkem šedým. Oba dva druhy samozřejmě zobrazují jméno vazby. Program bohužel nabízí pouze jednu notaci a nelze jej ani doplnit o další. Výhodou je tzv. razítko, které obsahuje všechny důležité informace o projektu a na obrázku jej vidíme v levém horním rohu. Program ukládá veškeré informace o projektu (konceptuální, technologický model a další) do jednoho souboru. Jedná se o soubor *.xer. 5.4.4 Technologická úroveň Do technologické úrovně se v programu dostaneme přepnutím pohledu na Physical view (pohled vybereme v menu pod položkou view). Bohužel program neobsahuje žádné generování technologického modelu. Z většiny CASE nástrojů jsme zvyklí, že právě na tomto místě použijeme funkci generující další úroveň. V právě popisovaném XTG Data Modelleru nic takového nenalezneme. Zahrnuje pouze funkci, která přepne pohled a zobrazí uvedená jména, která jsme zadali pro entity, atributy a vazby do příslušné položky. V programu není žádná kontrola datových typů, vazeb atd. Vše musí hlídat autor modelu. Současné řešení považujeme za obrovskou nevýhodu programu. Můžeme říci, že omezuje jeho širší rozšíření a použití. V případě, že společnost XTG Systems, s.r.o. chce dále nabízet, rozvíjet a rozšiřovat produkt měla by funkcionalitu co nejdříve zapracovat. Technologický model databáze je znázorněn na Obr. 20. 40

Obr. 20 – XTG Data Modeller – model na technologické úrovni

Model nám ukazuje technologickou úroveň v programu XTG Data Modeller. Jedná se vlastně o model na konceptuální úrovni (detailně popsaný v předchozí kapitole) doplněný o datové typy u jednotlivých atributů. V technologickém modelu se samozřejmě zobrazují názvy uvedené pro technologickou úroveň. Jak již bylo řečeno v předcházející (konceptuální) úrovni, všechny úrovně jsou ukládány do jednoho *.xer souboru. 5.4.5 Implementační úroveň Pro generování SQL kódu, který zabezpečuje vytvoření databáze, její aktualizaci a průběžnou práci, obsahuje XTG Data Modeller funkci SQL Script (DDL). Nástroj umožňuje vybrat typ databáze z následujícího seznamu:  InterBase/Firebird  MySQL  Centura SQLBase  Microsoft SQL Server  Microsoft Acces  Oracle  Sybase  PostgreSQL  DB2  Informix  Mimer 41

Typ databáze je nutné ale vybrat předem pomocí nástroje Choose DB server type, který není přístupný z nástroje SQL Script (DDL). Bohužel ani v poslední verzi programu (2.3.4.) není dostupná automatická konverze datových typů pro různé typy databázových serverů. Datový typy je nutné tedy stále ručně hlídat. Toto je jedna z obrovských nevýhod programu. Dalším problémem je pouze obecná podpora typů databázových serverů. Jak je vidět z výše uvedeného seznamu, není zde podpora jednotlivých verzí. Standardně se skript generuje do souboru ve formátu *.sql, v případě potřeby je možné zadat i formát *.ddl. Při generování lze do skriptu vložit další části definované uživatelem. Tato možnost je dostupná přímo z programu a poté tedy není potřeba vstupovat do skriptu. Níže naleznete ukázku vygenerovaného skriptu pro náš ukázkový příklad a prostředí Oracle. CREATE TABLE Hráč ( rodné_číslo příjmení jméno bodová_hodnota platnost_registrace_do číslo_klubu

CHAR (10) VARCHAR (25) VARCHAR (15) INTEGER DATE CHAR (5)

NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL);

ALTER TABLE Hráč ADD (CONSTRAINT PK_Hráč PRIMARY KEY (rodné_číslo)); CREATE TABLE Klub ( číslo_klubu název_klubu ulice město PSČ počet_dvorců zkratka_soutěže

CHAR (5) VARCHAR (40) VARCHAR (30) VARCHAR (30) CHAR (5) INTEGER CHAR (4)

NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NULL);

ALTER TABLE Klub ADD (CONSTRAINT PK_Klub PRIMARY KEY (číslo_klubu)); CREATE TABLE Soutěž_družstev ( zkratka_soutěže název_soutěže oblast míče ALTER TABLE Soutěž_družstev (zkratka_soutěže));

CHAR (4) VARCHAR (25) VARCHAR (20) VARCHAR (30) ADD

NOT NULL, NOT NULL, NOT NULL, NOT NULL);

(CONSTRAINT

42

PK_Soutěž_družstev

PRIMARY

KEY

CREATE TABLE Turnaj ( kód_turnaje název_turnaje termín_od termín_do plánovaný_počet_účastníků startovné číslo_klubu

CHAR (6) VARCHAR (50) DATE DATE INTEGER NUMERIC (8,2) CHAR (5)

NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL);

ALTER TABLE Turnaj ADD (CONSTRAINT PK_Turnaj PRIMARY KEY (kód_turnaje)); CREATE TABLE Účast_na_turnaji ( kód_turnaje rodné_číslo výsledek body

CHAR (6) CHAR (10) VARCHAR2 (15) INTEGER

ALTER TABLE Účast_na_turnaji (kód_turnaje,rodné_číslo));

ADD

NOT NULL, NOT NULL, NOT NULL, NOT NULL);

(CONSTRAINT

PK_Účast_na_turnaji

PRIMARY

KEY

ALTER TABLE Účast_na_turnaji ADD (CONSTRAINT účast_na_turnaji_1 FOREIGN KEY (rodné_číslo) REFERENCES Hráč); ALTER TABLE Účast_na_turnaji ADD (CONSTRAINT účast_na_turnaji_2 FOREIGN KEY (kód_turnaje) REFERENCES Turnaj); ALTER TABLE Turnaj ADD (CONSTRAINT pořádá FOREIGN KEY (číslo_klubu) REFERENCES Klub); ALTER TABLE Klub ADD (CONSTRAINT účast_v_soutěži družstev FOREIGN KEY (zkratka_soutěže) REFERENCES Soutěž_družstev ON DELETE SET NULL); ALTER TABLE Hráč ADD (CONSTRAINT členství FOREIGN KEY (číslo_klubu) REFERENCES Klub);

43

5.4.6 Další funkce Mezi další funkce, které bychom rádi zmínili, patří prohlížení databází a reversní engineering a to jak přes ODBC tak SQL skript. Tuto funkcionalitu využijeme především při práci s již existující databází nebo při jejích úpravách. Naše práce se zaměřuje na podporu CASE při vytváření nových databází, z tohoto důvodu zde nebudeme zmíněné funkce detailně popisovat. 5.4.7 Shrnutí XTG Data Modeller 2.3.4 je jednoduchým, nutno říci že až příliš jednoduchým, CASE nástrojem pro modelování databází. Zcela souhlasíme s následující charakteristikou od pana Rydvala: „Program bych přirovnal k malému dítěti, které již umí trošku žvatlat a snaží se lézt, ale pořádný krok kupředu ho teprve čeká“. [Rydval, 2005] Na programu je vidět, že je teprve ve svém začátku, přesto ale má v sobě určitý potenciál. Bohužel vývoj na trhu CASE nástrojů je velmi rychlý a společnost XTG Systems, s.r.o. již dlouhou dobu nevydala žádnou novou verzi a tak čím dál tím víc ztrácí konkurenceschopnost. Program obsahuje některé zajímavé funkce, bohužel ale v něm nalezneme spíše více nevýhod. Vše jsme přehledně shrnuli do následujících dvou podkapitol 5.4.7.1 a 5.4.7.2. Přichází poslední otázka, pro koho je program vhodný? V současné podobě je použitelný ve velmi malých organizacích, které nepotřebují komplexní nástroje. Dále by bylo možné ho použít při výuce, zde ale vidíme problém špatného rozdělení konceptuální a technologické úrovně. 5.4.7.1 Výhody  nízká cena  reversní engineering 5.4.7.2 Nevýhody  pouze obecná podpora jednotlivých typů databázových serverů, program nepodporuje jejich jednotlivé verze  neexistence automatické konverze datových typů pro různé typy databázových serverů  uživatelské prostředí je částečně v angličtině a částečně v češtině  ovládání není intuitivní  přílišná jednoduchost  nejistý budoucí vývoj

44

6 Srovnání CASE nástrojů Po analýze všech představených nástrojů jsme nejdůležitější kritéria pro hodnocení nástrojů rozdělili do čtyř skupin – obecné, technologické, funkční a ostatní. Mezi obecná kritéria jsme zařadili aktuální verzi nástroje, výrobce a jeho webové stránky, licenci a cenu, která jsou důležitá pro získání základních informací o jednotlivých nástrojích, především možností jejich získání a používání. Technologická kritéria zahrnují operační systém, HW nároky a podporované databázové systémy. Podporovaná notace, generování technologické úrovně z konceptuální, generování konceptuální úrovně z technologické, generování SQL skriptu a reverzní inženýrství tvoří skupinu funkčních kritérií. Tuto funkcionalitu posuzujeme především z toho důvodu, že je velmi důležitá při navrhování databází, což je hlavní podstatou zde popisovaných nástrojů. Skupina ostatních kritérií zahrnuje další funkce jako generování dokumentace, verzování, podpora týmové spolupráce a přístup do SŘBD. Mezi ostatní kritéria je řadíme proto, že se jedná o funkce podpůrné, tedy ne nezbytně nutné pro komplexní návrh databáze. Následuje charakteristika jednotlivých kritérií. 

Obecné  Aktuální verze nástroje Zachycuje verzi testovaného nástroje. Zároveň jde o poslední dostupnou verzi k začátku testování aplikace.  Výrobce Uvádí výrobce (autora) produktu.  Webové stránky Odkazuje na webové stránky výrobce, kde lze nalézt dodatečné informace o produktu.  Licence Specifikuje druh licence. Je zde uvedeno, zda se jedná o freeware (případně omezení při jeho používání), nebo placený software.  Cena Uvádí oficiální cenu za licenci produktu. Pokud existuje více verzí, jsou zde zachyceny hodnoty pro jednotlivé verze případně cenové rozmezí. Pokud není známa oficiální cena v CZK, jsou zde použity cizí měny (EUR, USD).

45



Technologické  Operační systém Vymezuje podporované operační systémy (včetně verzí) pro daný nástroj. Tyto informace jsou čerpané přímo od výrobce.  HW nároky Specifikují minimální nároky na systém pro uspokojivý běh aplikace. Zpravidla jde o požadavky na procesor, minimální velikost operační paměti a doporučené volné místo na pevném disku. Údaje pocházejí z informací od výrobce.  Podporované databázové systémy Uvádí databázové systémy, které testovaný nástroj podporuje. To znamená, že dokáže vygenerovat kompatibilní databázi z vytvořených modelů a že dále umožňuje pokročilé funkce při práci s těmito databázovými systémy (reverzní inženýrství, přístup do systému, řízení

báze dat apod.), pokud jimi disponuje. Jestliže jsou podporovány pouze některé verze DB systému, jsou zde konkrétně uvedeny. 

Funkční  Podporovaná notace Zachycuje seznam podporovaných notací, které jsou k dispozici při vytváření datových modelů. Uživatel si je může libovolně měnit v průběhu návrhu (pokud nástroj disponuje více notacemi). Jsou zde vyjmenovány konkrétní notace (např. Barkerova notace), jestliže se nejedná o standardizovanou notaci, je uvedena notace „vlastní“.  Generování technologické úrovně z konceptuální Jde o jeden ze základních kroků při modelování databáze podle Principu tří architektur. Definuje, zda je nástroj schopen vytvořit technologický datový model na základě konceptuálního modelu. Pokud ano, je uvedeno, jak lze tento krok učinit v prostředí nástroje.  Generování konceptuální úrovně z technologické Jedná se o opačný postup oproti předchozímu bodu. Z technologického modelu se vytváří konceptuální. Při běžném návrhu databáze není tento krok běžný. Ve specifických případech se jedná o užitečnou funkci. V případě podpory uvádíme, kde tuto funkci najdeme.  Generování SQL skriptu Vystihuje podporu procesu, kdy na základě datového modelu (zpravidla technologického) nástroj generuje SQL kód. Pomocí tohoto kódu lze vytvořit modelovanou databázi v prostředí vybraného podporovaného databázového systému. Je zde také uveden odkaz na konkrétní funkci v testovaném nástroji.  Reverzní inženýrství Uvádí, zda daný nástroj podporuje funkci reverzního inženýrství. Jedná se o proces, kdy na základě existující databáze nástroj vygeneruje zpětně její model. 46



Ostatní  Generování dokumentace Vyjadřuje podporu vytváření dokumentace v průběhu návrhu databáze. Pokud ji nástroj podporuje, jsou specifikovány formáty, pomocí nichž lze popsat jednotlivé modely, například HTML, RTF.  Verzování Uvádí podporu evidence vývojových verzí návrhu databáze. Mělo by umožňovat zachytit změny v průběhu vývoje a vrátit se k některé z předchozích verzí v případě potřeby.  Podpora týmové práce Specifikuje, zda testovaný nástroj umožňuje efektivní práci více uživatelů na projektu. Základním prvkem této funkce je úložiště. Jedná se o společný pracovní prostor, kde jsou uloženy jednotlivé verze projektu. Úložiště disponuje řízeným přístupem více uživatelů spolupracujících na projektu.  Přístup do SŘBD Vystihuje, zda nástroj umožňuje přímý přístup do systému řízení báze dat, tedy jestli umožňuje přímo měnit strukturu databáze a její další správu. V některých případech je uvedeno, že je přístup možný pouze skrze aplikační rozhraní, jako například ODBC.

Při hodnocení jednotlivých nástrojů zohledňujeme z obecných kritérií zejména aktuálnost poslední dostupné verze, cenu v závislosti na poskytované funkcionalitě a možnost získání informací o nástroji z webových stránek výrobce. Za technologická kritéria s nejvyšší vahou považujeme z pohledu možnosti navrhování databází kritérium podporované databázové systémy. Ve skupině funkčních a ostatních kritérií posuzujeme především fakt, jestli nástroj uvedenou funkcionalitu obsahuje či nikoli a pokud ano, snažíme se uvádět konkrétní název funkce v nástroji. Pro lepší přehlednost uvádíme srovnání všech představených nástrojů v následující tabulce. Tabulka je zároveň i určitým návodem, na co se zaměřit při výběhu a hodnocení různých CASE nástrojů pro návrh databází. Zde uvedené je možno považovat za kritéria, podle kterých lze hodnotit i jiné, v této práci nepopsané nástroje. Váhu, kterou uživatel jednotlivým kritériím přisuzuje, a tedy které považuje za nejdůležitější pro výběr konkrétního nástroje, si musí každý zvolit sám, protože se jedná o velmi subjektivní pohled. Cílem naší práce není vybrat jeden nejlepší nástroj a proto ani váhu jednotlivých kritérií nevolíme. Snažíme se pouze o shrnutí nejdůležitějších bodů.

47

Oracle SQL Developer Data Modeler

PowerDesigner

Aktuální verze Výrobce

2.0 Oracle

15.2 Sybase

Webové stránky výrobce, nástroje Licence

www.oracle.com

www.sybase.cz

 freeware

 placená

Cena

zdarma

 2 799 USD – 5 495 USD

Operační systém

 Microsoft Windows (XP, Vista, 7 včetně x64)  Linux  Mac OS X

 Microsoft Windows XP, Vista, 7  Microsoft Windows Server 2003, 2008

HW nároky (procesor, operační paměť, místo na pevném disku)

 min. 512 MB RAM, doporučeno 1 GB  125 MB HDD

 Pentium 1.5 GHz  1 GB RAM  alespoň 500 MB HDD

Podporované databázové systémy

 Oracle Database 11g, 10g a 9i  SQL Server 2005 a 2000

 IBM DB2  Informix SQL  Microsoft SQL Server 48

Toad Data Modeler

XTG Data Modeller

3.6.7.1 CHARONWARE, s.r.o. Quest Software, Inc. www.casestudio.com

2.3.4 XTG Systems, s.r.o.

   

 placená

placená omezený freeware 435 € 479 $

 Windows 2000 Professional Edition (Service Pack4)  Windows XP (32/64-bit)  Windows Vista (32/64-bit)  Windows Server 2003 (32/64-bit)  Windows Server 2008 (32/64-bit)  Windows 7 (32/64-bit)  Pentium IV, doporučeno Pentium dual core  256 MB RAM, doporučeno 1 GB  100 MB HDD, doporučeno 200 MB  DB2 UDB v. 8 (LUW), 9.0 (LUW), 9.5 (LUW), 9.7 (LUW)  DB2 z/OS v. 9

www.xtg.cz

   

SINGLE – 4 000 Kč SINGLE LITE – 1 500 Kč SITE MULTI – 1 2000 Kč UNLIMITED MULTI – 29 000 Kč  Microsoft Windows 95, 98, ME, NT, 2000, XP, Vista, 7

 2 MB RAM

 InterBase/ Firebird  MySQL  Centura SQLBase

 DB2/390 8 a 7  DB2/UDB 8.1 a 7.1

 Oracle

Podporovaná notace

 Barkerova  Bachmanova

Generování technologické úrovně z konceptuální Generování konceptuální úrovně z technologické (zpětně) Generování SQL scriptu Reverzní inženýrství

Ano, pomocí funkce Engineer to Relational Model

 Entity/Relationship  Merise  IDEF1X  Barkerova Ano, pomocí funkce Generate Physical Data Model

Generování dokumentace Verzování Podpora týmové spolupráce Přístup do SŘBD

Ano, pomocí funkce Engineer to Logical Model

Ano, pomocí funkce Generate Conceptual Data Model

Ano, pomocí funkce Generate DLL Ano

Ano, pomocí funkce Generate Database Ano

Ne Ne Ne

Export do všech běžných formátů, RTF, HTML,Excel atd. Ano (verze Enterprise) Ano (verze Enterprise)

Ne

Ano, přímý přístup

 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  IE (Information Engineering)  IDEF1X

Microsoft SQL Server Microsoft Acces Oracle Sybase PostgreSQL DB2 Informix Mimer

 Vlastní

Ano, pomocí funkce File - Sync & Convert – Simple Model Conversion Ano, pomocí funkce File - Sync & Convert – Simple Model Conversion

Ne

Ano, pomocí funkce Model – Generate DDL script Ano, pomocí funkce File – Reverse Engineering Export do formátů HTML, PDF a RTF Ano Ne

Ano, pomocí funkce SQL Script (DDL) Ano

Pouze pro reverzní inženýrství (přes ODBC, ADO…)

Ano, přes ODBC

Tab. 6 – Srovnání CASE nástrojů

49

       

Ne

Ano – HTML Ne Ne

Z výše uvedené tabulky je zřejmé, že všechny popisované nástroje poskytují základní funkcionalitu týkající se návrhu databáze a to možnost navrhovat modely jak na konceptuální a technologické úrovni, tak i implementační úroveň databáze. Velmi důležitou funkci generování mezi jednotlivými úrovněmi podporují pouze tři z představených nástrojů a to Power Designer, Toad Data Modeler a Oracle SQL Developer Data Modeler. XTG Data Modeller bohužel nemá tuto možnost integrovánu a proto je nutné navrhnout každou úroveň zvlášť, což může vést ke zbytečným chybám, vzniklým při opakovaném návrhu té samé databáze. Pokud bychom měli nástroje porovnat z pohledu cenového, je zřejmé, že nejlevnější, dokonce zdarma je nástroj Oracle SQL Developer Data Modeler, který například oproti XTG Data Modelleru, jehož cena se pohybuje od 4 000 Kč za nejjednodušší verzi do 29 000 Kč za verzi s největší funkcionalitou, má mnohem lépe navržené uživatelské rozhraní a i při nulových nákladech na pořízení obsahuje všechny základní funkce. Nástroj Toad Data Modeler asi nejvíce vystihuje anglické „value for money“, tedy fakt, že za cenu, která je za nástroj účtována, dostane zákazník takové množství funkcí, které očekává. Dalo by se říct, že cena přesně vystihuje funkcionalitu nástroje. Poslední z představovaných nástrojů Power Designer je v cenové kategorii sice na nejnižší příčce, tedy je z uvedených nástrojů nejdražší, ale vzhledem k tomu, že se jedná o nástroj s dlouholetou tradicí a prověřenou kvalitou, je tento fakt zajisté pochopitelný a proto i dnes Power Designer pořád patří mezi velmi populární CASE nástroje pro návrh databází. Z ostatních funkcionalit je dobré vyzdvihnout například možnost reverzního inženýrství, kterou obsahují všechny představené nástroje, nebo pak také možnost generovat dokumentaci do různých formátů. Tuto možnost má jak Power Designer a XTG Data Modeller, tak i Toad Data Modeler, ale ten pouze v placené verzi. Další důležitou funkcí je například přímý přístup do databáze přes ODBC, kterou disponuje pouze Power Designer a XTG Data Modeller. Z pohledu hardwarových nároků, případně požadavků na systém si musí každý uživatel uvážit, co je zrovna pro něj nejvýhodnější. To samé se dá říct i o podporovaných databázových systémech. Konkrétně jsou uvedeny v tabulce. Asi nejvíce databázových systémů podporuje Toad Data Modeler, dnes hojně využívaný Oracle podporují všechny popisované nástroje. Pokud vezmeme v úvahu všechny uvedené klady i zápory, dosahuje nejvyššího průměru hodnot kritérií Power Designer, a to i přes jeho vysokou cenu. Toad Data Modeler i XTG Data Modeller jsou sice velmi dobré nástroje, ale prvotní orientace uživatele v jejich uživatelském rozhraní může být z počátku poněkud nesnadná a to hlavně v případě, že již dříve používal právě velmi známý Power Designer. Oracle SQL Developer Data Modeler je také kvalitní nástroj, ale někdy může být jeho nulová cena citelná při potřebě složitějších funkcí. Například absence jiné než Barkerovy a Bachmanovy notace může být při výběru CASE nástroje pro někoho rozhodujícím faktem, proč si zrovna Oracle SQL Developer Data Modeler nezvolit. Další srovnání je pro účely představení nástrojů asi zbytečné, základní funkcionalita i požadavky byly uvedeny, a pokud se uživatel chce o nástrojích dozvědět více, není nic lepšího než vlastní zkušenost.

50

7 Závěr Oblast CASE nástrojů, které podporují vytváření databází, se velmi dynamicky vyvíjí. V dnešní době většina nástrojů podporuje mnohem více funkcí než pouhé modelování databází. Jak již víme, na trhu nalezneme mnoho nástrojů z rozdílných cenových kategorií, s rozdílnou funkcionalitou a rychlostí vývoje. Pokud se rozhodneme pro nákup je potřeba vybrat ten správný. Cílem naší práce bylo představení a následné porovnání čtyř CASE nástrojů podporující modelování a tvorbu databází. Náš cíl také samozřejmě zahrnoval porovnání jednotlivých nástrojů mezi sebou a vytvoření doporučení ohledně cílové skupiny uživatelů. V předcházejících kapitolách 5 a 6 jsme se detailně věnovali srovnání nástrojů z pohledu ceny, nároků na systém, funkcionality a jejich možností. Na tomto místě bychom rádi shrnuli naše poznatky získané v průběhu testování všech nástrojů. Nejrobustnějším řešením z našeho testování, je bezesporu PowerDesigner, tento nástroj je možné použít nejen k modelování databází, ale i k tvorbě mnoha dalších modelů. Jeho patnáct verzí a společnost Sybase naznačuje jistý budoucí vývoj a tedy jistotu pro zákazníky, kteří do něj investují. Je tedy vhodný pro firemní zákazníky, kteří jej využijí ke každodenní práci. Toad Data Modeler a Oracle SQL Developer Data Modeler bychom mohli zařadit přibližně na stejnou úroveň. Oba dva velmi dobře odvedou svou práci a v některých případech i něco navíc. Jejich výhodou je poměrně nízká cena (nástroj od společnosti Oracle je dokonce freeware) a opět možnost použití ve firemním prostředí. Na úplný konec bychom zařadili program od společnost XTG. Bohužel jeho kvalita a vývoj zaostávají za ostatními nástroji. Nedokážeme si představit reálné použití tohoto nástroje ve společnostech a to především z již zmíněných kvalitních nedostatků, ale také z nejistého budoucího vývoje. Doporučili bychom ho pouze pro domácí tvorbu malých modelů, popřípadě ho lze využít pro výuku s důrazným upozorněním, že téměř nerespektuje P3A. Pro budoucí uživatele máme následující doporučení. Vždy si nástroj před koupí velmi dobře vyzkoušejte, lze využít trial verzí ze stránek společností, protože v mnoha případech ilustrace poskytované výrobcem vypadají lákavě, ale skutečnost je často jiná. Do budoucna se dá předpokládat neustálý vývoj CASE nástrojů pro podporu vytváření databází, v dnešní době je velkým trendem vytvářet robustní nástroje podporující více oblastí modelování. Tento trend s největší pravděpodobností bude pokračovat a nástroje budou podporovat čím dál tím více modelů.

51

8 Seznam použité literatury [Havel, 2010]

Havel, Prokop. SAP koupí amerického výrobce softwaru Sybase E15.cz. *Online+ 13. květen 2010. *Citace: 8. říjen 2010.+ http://www.e15.cz/byznys/technologie-a-media/sap-koupiamerickeho-vyrobce-softwaru-sybase.

[Oracle, 2009]

Oracle. SQL Developer Data Modeler Release Notes. [Online] 10. prosinec 2009. *Citace: 10. říjen 2010.+ http://www.oracle.com/technetwork/developer-tools/datamodeler/re leasenotespatch1-167677.html.

[Quest-Software, 2010]

Quest-Software. ER diagrams, entity relationship diagrams and Toad™ Data Modeler software. [Online] 31. říjen 2010. [Citace: 2. listopad 2010.] http://www.casestudio.com/enu/requirements.aspx.

[Rydval, 2005]

Rydval, Slávek. Kreslítka pro krycím jménem CASE. [Online] 1. srpen 2005. [Citace: 5. říjen 2010.+ http://www.rydval.cz/phprs/view.php?cisloclanku=2005123135.

*Řepa, 2000+

Řepa, Václav. Vývojové trendy metodik vývoje informačních systémů výzva BPR. *Online+ 3. září 2000. *Citace: 11. říjen 2010.+ http://nb.vse.cz/~repa/veda/EurOpen99%20Paper.pdf.

[SoftwareMedia.com, 2010] SoftwareMedia.com. Sybase PowerDesigner Software | SoftwareMedia.com. *Online+ 5. říjen 2010. *Citace: 6. říjen 2010.+ http://www.softwaremedia.com/sybase/powerdesigner/. [Sybase, 2010]

Sybase. PowerDesigner Modeling and Metadata Management Software Tool - Data Modeling, Information - Sybase Inc. [Online] 1. listopad 2010. [Citace: 2. listopad 2010.] http://www.sybase.com/products/modelingdevelopment/powerdesig ner.

[XTG, 2010]

XTG. XTG Systems - XTG Data Modeller. [Online] 30. září 2010. [Citace: 1. říjen 2010.+ http://www.xtg.cz/xtgdm.php3.

52

9 Seznam obrázků Obr. 1 – Princip tří architektur *Řepa, 2000+ ........................................................................................... 6 Obr. 2 – Konceptuální schéma modelové databáze................................................................................ 7 Obr. 3 – Uživatelské prostředí Oracle SQL Developer Data Modeler...................................................... 9 Obr. 4 – Oracle SQL Developer Data Modeler – model na konceptuální úrovni .................................. 10 Obr. 5 – Oracle SQL Developer Data Modeler – model na technologické úrovni ................................. 12 Obr. 6 – Uživatelské rozhraní Sybase PowerDesigner ........................................................................... 17 Obr. 7 – PowerDesigner – model na konceptuální úrovni .................................................................... 19 Obr. 8 – PowerDesigner – model na technologické úrovni................................................................... 20 Obr. 9 – Ukázka základního uživatelského rozhraní nástroje Toad Data Modeler ............................... 26 Obr. 10 – Toad Data Modeler – model na konceptuální úrovni ........................................................... 27 Obr. 11 – Toad Data Modeler – model na technologické úrovni .......................................................... 29 Obr. 12 – Reverse Engineering – výběr, odkud chceme načíst požadovaná data................................. 34 Obr. 13 – Reverse Engineering – obrazovka pro uvedení cesty k souboru na pevném disku............... 34 Obr. 14 – Reverse Engineering – poslední obrazovka před spuštěním reverzního inženýrství ............ 35 Obr. 15 – Reverse Engineering – obrazovka Connection ...................................................................... 35 Obr. 16 – Reverse Engineering – obrazovka Object Palette a vygenerovaný, neupravený model ....... 36 Obr. 17 – Uživatelské prostředí XTG Data Modeller ............................................................................. 38 Obr. 18 – XTG Data Modeller – detail entity ......................................................................................... 39 Obr. 19 – XTG Data Modeller – model na konceptuální úrovni ............................................................ 40 Obr. 20 – XTG Data Modeller – model na technologické úrovni........................................................... 41

10 Seznam tabulek Tab. 1 – Oracle SQL Developer Data Modeler – požadavky na systém *Oracle, 2009+ ........................... 9 Tab. 2 – PowerDesigner – požadavky na systém *Sybase, 2010+ .......................................................... 17 Tab. 3 – Toad Data Modeler – požadavky na systém *Quest-Software, 2010] ..................................... 26 Tab. 4 – Licence XTG Data Modeller...................................................................................................... 37 Tab. 5 – XTG Data Modeller – požadavky na systém *XTG, 2010+......................................................... 38 Tab. 6 – Srovnání CASE nástrojů............................................................................................................ 49

53