CASE pro podporu databází

Transkript

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
5.2.5
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
5.3.3
5.3.4
5.3.5
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
5.4.3
5.4.4
2
5.4.5
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"
);
ADD CONSTRAINT FK_ASS_10 FOREIGN KEY ( "Hráč_rodné číslo" )
REFERENCES Hráč ( "rodné číslo" );
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
Procesor
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]
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 <pi>, povinné položky zkratkou <M>. U každého atributu též nalezneme zkratku
vyjadřující datový typ. Vztahy jsou označeny názvem, kardinalita je vyznačena běžným způsobem
(pouze u vztahu s atributy ve formátu M:N). Konceptuální datový model se ukládá do samostatného
souboru s koncovkou *.cdm.
Technologický 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
<pk> a cizí klíč jako <fk>. Model se ukládá do souboru s koncovkou *.pdm.
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
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
Procesor
Operační paměť
Operační systém
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]
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
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
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
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
Procesor
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]
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.
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.
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
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
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č
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

CASE pro podporu databází

Transkript

Podobné dokumenty

ER diagram (Entity Relationship Diagram)

Nový design výrobků řady JUPOL a JUB Professional Přehled

Nástroje pro vývoj aplikací v závislosti na platformě a jejich vazba na

4IT_450 Přehled CASE nástrojů na tuzemském trhu

Přehled CASE nástrojů na tuzemském trhu

Nástroje pro vývoj aplikací a jejich vazba na CASE

Příklad

XML a ORACLE

Propozice česky

Strukturované metodologie

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Datové modelování

Otevírání černých skříněk

Databázové systémy I.

Použití case pro architekturu SOA

Nástroje pro vývoj aplikací v závislosti na platformě a jejich vazba na

Úkoly 1.0 - MIKMIK.cz

nový nissan juke

Přehled nástrojů CASE na tuzemském trhu

Eye-tracking pro testování čtení workflow diagranů v geografických

Seznam přihlášených posádek 2014

CANNONDALE KAMENICKÝ MARATON propozice závodu

Vzorce a recepty nebeské mechaniky