DEDUKTIVNÍ DATABÁZE (DISTANČNÍ VÝUKOVÁ OPORA)

UČEBNÍ TEXTY OSTRAVSKÉ UNIVERZITY ______________________________________________ Přírodovědecká fakulta

DEDUKTIVNÍ DATABÁZE (DISTANČNÍ VÝUKOVÁ OPORA)

Zdeňka Telnarová

2003 ________________________________________ Ostravská univerzita

1 Úvod ........................................................................................................... 4 2 Teoretická východiska deduktivních databází........................................... 6 2.1 Datový model a jazyk v DATALOGu................................................. 7 2.2 Interpretace klauzule, model a logický důsledek................................. 9 2.3 Graf závislostí a rekurze .................................................................... 12 2.4 Bezpečná pravidla.............................................................................. 12 2.5 Vyhodnocování nerekurzívních pravidel........................................... 13 2.6 Rekurzivní pravidla ........................................................................... 16 2.7 Negace v pravidlech .......................................................................... 17 3 Deduktivně objektové systémy řízení báze dat ........................................ 19 3.1 Florid ................................................................................................. 20 3.2 Gedblog ............................................................................................. 20 3.3 Illustra ................................................................................................ 21 3.4 ODE ................................................................................................... 21 3.5 Validity .............................................................................................. 22 3.6 RockRoll............................................................................................ 22 3.7 P/FDM ............................................................................................... 22 4 Deduktivně objektový databázový systém ConceptBase a jeho základní komponenty ................................................................................................. 24 4.1 Jazyk Telos v ConceptBase ............................................................... 25 4.2 Jednoduchý model v Telos ................................................................ 28 4.3 Predikátový jazyk CBL jako součást Telos ....................................... 29 4.4 Dotazování v ConceptBase................................................................ 31 4.5 Modelování a metamodelování v ConceptBase ................................ 36 5 Využití deduktivních pravidel k zachování integrity dat.......................... 45 5.1 Pojem deduktivní integrita................................................................ 45 5.2 Princip deduktivní integrity v relačních datových modelech ............ 46 5.3 Nevýhody deduktivní integrity v relačních datových modelech ....... 47 5.4 Integritní omezení v ConceptBase..................................................... 48 6 Metodická doporučení k integraci deduktivních pravidel do návrhu informačního systému.................................................................................. 51 6.1 Úvod do metodiky ............................................................................. 52 6.2 Analýza .............................................................................................. 61

2

6.3 Návrh ..................................................................................................67 6.4 Prototyping deduktivních pravidel .....................................................81 7 Demonstrační úloha...................................................................................88 7.1 Analýza subsystému Komunikace účastníků vzdáleného vyučování.88 7.2 Návrh subsystému Komunikace vzdáleného vyučování ..................101 7.3 Prototyping deduktivních pravidel ...................................................112 8 Korespondenční úkol...............................................................................115 9 Závěr........................................................................................................116 10 Použitá literatura....................................................................................117

3

1 ÚVOD Systémy řízení báze dat jsou jednou z nejpoužívanějších technologií, které byly v oblasti informačních technologií vyvinuty. Jejich použití však zdaleka není tak snadné, jak mnohdy naznačují propagační a komerční publikace. Problémy reprezentace a zpracování dat jsou stále aktuálnější a rozhodně nelze říci, že všechny problémy uživatelů jsou řešeny a vyřešeny optimálně. Donedávna většina dat, která byla v databázové technologii zpracovávána, byla uložena ve formě jednoduchých relačních tabulek, jejichž struktura byla definována s využitím jednoduchých datových typů. Moderní databázové aplikace ovšem potřebují manipulovat s objekty, které nelze snadno transformovat do relačních tabulek. Výzkum na poli databázové technologie byl postaven před úkol, jak tento problém řešit. Jako dlouhodobě výhodná investice se jeví přechod k objektově relačním databázovým systémům. Tyto SŘBD kombinují výhody moderních objektově orientovaných programovacích jazyků s rysy relačních databází jako jsou např. vícenásobné pohledy a neprocedurální dotazovací jazyky. Objektová infrastruktura zároveň poskytuje možnost definování vlastních datových typů a funkcí. S přechodem na objektově relační databázovou technologii vznikla potřeba modifikace metodiky datového modelování. Snaha přiblížit databázové koncepty reálnému světu a potřebám složitých databázových aplikací vede k vývoji systémů řízení báze dat směrem k objektové orientaci, k aktivním databázím, deduktivním databázím, temporálním, prostorovým, textovým či multimediálním databázím. S vývojem objektově orientované databázové technologii úzce souvisí vývoj nových metodologií pro analýzu, návrh a implementaci informačních systémů s databází, které jsou založeny na objektech. Jedná se např. o metodologie OMT, Booch Method, Jacobson Methodology, Martin/Odell Methodology, Wirfs/Brock Methodology, Methodology Coada a Yourdona, Fusion, Syntropy, IDEA Methology, atd. Zjednodušeně bychom mohli konstatovat: “Moderní databázové systémy, to jsou transakce, objekty a pravidla“ [4]. Transakce jsou klíčovým rysem databázové technologie, protože garantují integritu a konzistenci databáze. Všeobecně jsou známy vlastností transakcí, označované jako ACID (atomicity, consistency, isolation, durability). Databázové objekty jsou strukturovány do perzistentních tříd, které jsou organizovány v hierarchii generalizace – specializace, které navzájem na sebe odkazují a které jsou asociovány s metodami. Velmi inovačním prvkem jsou spolu s objekty rovněž pravidla. Pravidla můžeme chápat ve dvou dimenzích. Jedná se o pravidla deduktivní a o pravidla aktivní. Deduktivní pravidla umožňují odvozovat nové informace na základě exitujících informací, uložených jako data v databázi a zároveň je možno využít deduktivních pravidel k zajištění integrity databáze.

4

Aktivní pravidla zajišťují vykonávání operací v případě, nastala-li určitá událost. Aktivní pravidla vykonávají akce (tzn. provádějí databázové operace nebo volají externí programy). Aktivní pravidla jsou často v relačních databázových systémech označována jako triggery. Ve vývoji systémů řízení bází dat se od prvopočátku jednalo o tzv. datovou nezávislost, tj. nezávislost dat na jejich fyzické implementaci a nezávislost dat na aplikačních programech. S využitím objektové orientace je možno mnoho procedur a funkcí (které byly dříve součástí aplikačních programů) převést do popisu struktury databáze, kde jsou metodami jednotlivých tříd. Chování objektu není v takovém případě záležitostí aplikačního programu, ale báze dat. Můžeme tedy hovořit o další formě nezávislosti dat na aplikacích (metody nejsou součástí aplikace, ale schémat). Deduktivní přístup k databázové problematice zavádí další typ nezávislosti. Jedná se o tzv. nezávislost znalostní (její koncept byl uveden Friesenem v roce 1994). Znalost není součástí aplikace, nýbrž součástí datového schématu. Objekty, deduktivní a aktivní pravidla hrají velkou roli v rozšíření znalostní nezávislosti dat na aplikačních programech. Hlavní výhoda znalostní nezávislosti je v tom, že objekty a pravidla se uplatňují napříč aplikacemi. Tak, jako s přechodem od relačních databází k objektovým vzešla potřeba modifikace metodiky analýzy, návrhu a implementace informačních systémů s databází, stejná potřeba vzniká s přechodem k databázím deduktivním. Jakým způsobem modifikovat, resp. rozšířit metodiku o nové koncepty založené na deduktivních pravidlech? To je základní otázka, které se budeme věnovat při studiu předkládané výukové opory.

5

2 TEORETICKÁ VÝCHODISKA DEDUKTIVNÍCH DATABÁZÍ Cíl: Po prostudování této kapitoly bude umět definovat základní pojmy, popsané v klíčových slovech, dále budete schopni: -

navrhovat bezpečná pravidla,

-

sestavit jednoduchý logický program s využitím Hornových klauzulí,

-

vytvořit graf závislostí,

-

vyhodnotit nerekurzivní pravidla,

-

vyhodnotit rekurzivní pravidla.

Klíčová slova: EDB, IDB, dedukce, deduktivní pravidlo, formule, klauzule, Hornovy klauzule, interpretace klauzule, graf závislostí, rekurze, bezpečnost pravidel, vyhodnocování pravidel. Deduktivní databáze jsou založeny na podpoře teorie dokazování a jsou schopné dedukce dodatečných faktů z faktů, které jsou uloženy v extenzionální databázi. Mají zabudovány speciální deduktivní axiomy a pravidla dedukce. Deduktivní pravidla společně s integritními omezeními odvozují fakta, která jsou obvykle označovány jako intenzionální databáze. Deduktivní databáze se tedy skládá ze dvou složek, extenzionální databáze (EDB) a intenzionální databáze (IDB). Deduktivní datový model využívá dvou typů konceptů. Základní koncepty jsou uloženy v databázi (EDB) a odpovídají relacím v relačním datovém modelu nebo objektům v objektovém datovém modelu. Odvozené koncepty nemusí být uloženy v databázi, jsou obvykle dočasné a uchovávají mezivýsledky operací. Tyto koncepty jsou označovány jako intenzionální koncepty. Základním stavebním kamenem deduktivních databází jsou deduktivní pravidla, vyvinuta a demonstrována na paradigmatech logického programování v programovacím jazyku Prolog (Colmerauer a Kowalski, 1979). Hlavním smyslem deduktivních pravidel je reprezentace obecných deklarativních znalostí. Uplatnění deduktivních pravidel je možné jak v relační, tak objektové databázové technologii. Jazyk SQL a podobné jazyky pro manipulaci s daty, založené na relační algebře a relačním kalkulu, nemají dostatečnou vyjadřovací sílu a nejsou schopny vyjádřit uzávěr tranzitivních závislostí a všeobecné agregace v relačním datovém modelu. Tranzitivní uzávěr (podle [17]) databáze nebo deduktivní databáze (X,R), kde X je extenzionální databáze a R je množina pravidel, je databáze Y, která zahrnuje X a veškerá fakta, odvozená použitím pravidel z R. Logická pravidla využívající funkčních symbolů

6

mohou vyjádřit jakýkoliv výpočet tak, že ten může být zapsán v konvenčním programovacím jazyku. Dokonce logická pravidla bez funkčních symbolů (např. jazyk DATALOG) mají sílu vyjádřit výpočet větší než konvenční DQL (Data Query Language).

Příklad 2-1: Mějme predikát manažér(Z,M) a předpokládejme, že má hodnotu true tehdy, když zaměstnanec Z odpovídá přímo manažéru M. Můžeme definovat další predikát vedoucí(Z,V), který nabývá hodnoty true, když V je manažérem zaměstnance Z nebo jeho manažéra , ….. Predikát vedoucí(Z,V) je tranzitivním uzávěrem manažéra(Z,M). Predikát vedoucí(Z,M) můžeme vyjádřit: a) vedoucí(Z,M) ← manažér(Z,M) b) vedoucí(Z,M) ← vedoucí(Z,A) & manažér(A,M) Příklad ilustruje rekurzivitu deduktivních pravidel. Pravidla definují pravdivé instance predikátů.

2.1 Datový model a jazyk v DATALOGu V datalogovské interpretaci se na databázi nahlíží jako na množinu faktů, kdy faktem je instance v odpovídající relaci. Fakt je tedy logický predikát, obsahující jako své argumenty pouze konstanty. Základní predikáty odpovídají databázovým relacím a jsou definovány na úrovni definice schématu databáze, zatímco odvozené predikáty jsou definovány pravidly. Pojem schéma databáze je rozuměn ve smyslu [15], kde je schéma databáze dáno množinou schémat relací, z nichž každé lze vyjádřit zadáním jména relace a množiny atributů včetně domén a množinou integritních omezení. Datový model v DATALOGu je model založený na klauzulární logice, která je speciálním typem predikátové logiky vhodným pro logické programování, s některými omezeními. Predikátovému symbolu v DATALOGu odpovídá stejně jako v predikátové i klauzulární logice jeho interpretující relace. Na rozdíl od relační algebry, relace nemají pojmenované atributy. Komponenty relací mají fixní pozice a odkazy na sloupce jsou možné prostřednictvím této pozice. Je-li např. p predikátový symbol, pak můžeme provést odkaz p(X,Y,Z), kde X označuje první komponentu nějaké n-tice v relaci P, která odpovídá predikátu p. DATALOG na rozdíl od predikátové či klauzulární logiky nepovoluje funkční symboly v argumentech predikátů, argumenty mohou být pouze proměnné a konstanty.

Průvodce studiem: Obecně mohou pravidla obsahovat i funkční symboly. Máte-li zájem se s touto problematikou seznámit blíže, problémem definice pravidel

7

s použitím funkčních symbolů a především metodami vyhodnocování takových pravidel se podrobně zabývá publikace [16].

2.1.1 Atomická formule Základním stavebním kamenem DATALOGu jsou atomické formule. Atomická formule je ve tvaru p(A1, A2, …An). Argumentem může být proměnná nebo konstanta. Predikátový symbol je asociován s určitým počtem argumentů a můžeme použít p(K) k označení predikátu stupně K. Atomické formule lze konstruovat rovněž s aritmetickými porovnávacími predikáty =, <, >, …V tom případě se jedná o atomickou formuli s vestavěnými predikáty a formule se zapisuje ve tvaru např. X < Y nebo <(X,Y). První způsob zápisu je označován jako infixová notace, druhý prefixová notace. Vestavěné predikáty nemusí reprezentovat konečné relace.

2.1.2 Klauzule a Hornovy klauzule Literálem se rozumí buď atomické formule nebo negované atomické formule. Negovaná atomická formule se označuje ¬p(A1,…,An). Negovaná atomická formule se nazývá negativní literál. Nenegovaný literál je pozitivní literál. Klauzule je součet (logické OR) literálů. Hornova klauzule je klauzule s nejvýše jedním pozitivním literálem, tj. klauzule, která má obecně (zde s vynecháním atributů) tvar ¬p1 ∨ ¬p2 ∨...∨ ¬pn ∨ q. Klauzule tohoto typu lze, jak je známo, přepsat do tvaru implikace (p1 & p2 &...& pn ) → q , který je vhodný pro formulování logických pravidel. To je totiž tvar formule umožňující vyjádřit, že q je logickým důsledkem současné platnosti předpokladů p1 , p2 ,..., pn . Z toho důvodu jsou formule v Hornově klauzulárním tvaru základem pro formulování problémů v klauzulární logice, logickém programování i deduktivních databázích. Hornova klauzule je buď: • Jeden pozitivní literál, např. p(X,Y), který se označuje jako fakt. • Jeden nebo více negativních literálů, čímž je chápáno integritní omezení. • Pozitivní literál a jeden nebo více negativních literálů, což vyjadřuje deduktivní pravidlo ¬p1 ∨ … ∨ ¬pn ∨ q. Logickým ekvivalentem tohoto zápisu je zápis p1 ∧ p2 … ∧ pn → q. V DATALOGu se vyjádří Hornova klauzule ve tvaru: q ← p1 & …&pn,

8

kde: q je hlava pravidla (consequent), p1& …&pn je tělo pravidla (antecedent). Kolekce Hornových klauzulí tvoří logický program. Proměnné, které se vyskytují pouze v těle, mohou být existenčně kvantifikovány, zatímco ostatní proměnné jsou univerzálně kvantifikovány v celém pravidle.

Příklad 2-2: 1) 2) 3) 4) 5) 6)

sourozenec(X,Y) ← rodič(X,Z) & rodič(Y,Z) & X <>Y bratranec(X,Y) ← rodič(X,Xp) & rodič(Y,Yp) & sourozenec(Xp,Yp) bratranec(X,Y) ← rodič(X,Xp) & rodič(Y,Yp) & bratranec(Xp,Yp) příbuzný(X,Y) ← sourozenec(X,Y) příbuzný(X,Y) ← sourozenec(X,Y) & rodič(Y,Z) příbuzný(X,Y) ← příbuzný(Z,Y) & rodič(X,Z)

Například pravidlo 1) říká, že pro všechny X a Y je X sourozencem Y tehdy, jestliže existuje Z takové, že Z je rodičem obou X i Y a přitom X a Y není tentýž jedinec.

2.2 Interpretace klauzule, model a logický důsledek 2.2.1 Interpretace atomů Stejně jako v predikátové logice souvisí pojem atomu s pojmem predikátu a ten zase s pojmem relace i v klauzulární logice. Schéma syntaxe n-árního predikátu (, ,..,) odpovídá schématu jeho interpretující relace stejné arity <jméno relace>(, ,..,). Atributy uvedené v závorkách schématu relace i schématu odpovídajícího predikátu, se stejně jako v predikátové logice i v relační teorii nazývají deskriptory, neboť slouží k popisu toho, co jednotlivé výrazy v závorce za predikátovým symbolem znamenají.

Příklad schémtua predikátu : matka(<matka>, )

9

zamezí nejasnostem, ke kterému ze dvou termů predikátu se vztahuje event. ohodnocení pomocí objektů z podmnožiny matek universa diskursu a ke kterému se vztahuje ohodnocení prvky podmnožiny dětí. Predikát může mít jakoukoliv aritu, ale pokud nějakou má, je jí pro účel interpretace přiřazena odpovídající interpretující relace stejné arity. Interpretace atomu musí postupovat na základě pravdivostní hodnoty predikátu. Je-li atomem n-ární predikátový symbol p(t1, t2,...,tn), kde t1, t2,...,tn jsou konstanty nebo proměnné, které se po svém ohodnocení staly rovněž konstantami, nabývá atom pravdivostní hodnoty true, právě když (t1, t2,...,tn) je prvkem relace R interpretující predikátový symbol p. Protože klauzule v Datalogu má tvar q ← p1 & …&pn, je interpretována jako false v jediném případě, a to v tom, kdy jsou všechny atomy p1 , …, pn jejího těla interpretovány jako true a atom q hlavy je interpretován jako false.

2.2.2 Dedukce modelem množiny pravidel Definice 2-1 podle [15] Model množiny pravidel je množina faktů (predikátů s konstantami jako argumenty), které po dosazení do všech pravidel ohodnocují všechna pravidla hodnotou true. Je tedy nutné současné splnění všech pravidel.

Příklad2-3: Jsou předpokládána pravidla: 1) p(X) ← q(X) 2) q(X) ← r(X) Tato pravidla říkají, že je-li r true, pak q je taky true a je-li q true, je taky p true. Jeden možný model je model M1 = {r(1), q(1), p(1), q(2), p(2), p(3)}. Pravidla mají hodnotu true pro argumenty uvedené v modelu. Pro všechny ostatní argumenty mají hodnotu false. Důkaz: X=1 Po dosazení do pravidla (1): true ← true Po dosazení do pravidla (2): true ← true X=2 Po dosazení do pravidla (1): true ← true Po dosazení do pravidla (2): true ← false

10

X=3 Po dosazení do pravidla (1): true ← false Po dosazení do pravidla (2): false ← false Ať je provedena jakákoli substituce, pravidla vždy nabývají hodnoty true. Z toho vyplývá, že M1 je modelem množiny pravidel {(1), (2)}. Při použití pravidel k definování operací nad databází se předpokládá, že instance databáze dává hodnotu true tehdy, když odpovídající relace obsahuje tento fakt jako svou n-tici. Nechť r je databázový predikát a p, q jsou predikáty, definované využitím r. Lze předpokládat, že r(1) je true, zatímco r(X) je false pro X <> 1. Existuje další model M2 = {r(1), q(1), p(1)}. Existuje konečný počet modelů s databází, která má pouze r(1) true. M2 je minimální model, tzn. že nelze zaměnit žádný fakt z true na false, aniž by byl porušen model dokazující databázi {r(1)}. M1 nemá tuto vlastnost minimality. Model M1 se získá použitím definice logických důsledků.

2.2.3 Formální odvozování logického důsledku Stejně jako v predikátové (klauzulární) logice i v Datalogu existují dva přístupy k prověřování, resp. generování logických důsledků databáze. První z nich je již zmíněný sémantický přístup vycházející z modelů množiny předpokladů, druhým je přístup čistě formální, pro nějž není nutné zabývat se pravdivostními hodnotami atomů klauzulí. Tato interpretace vychází z axiomů použitých v důkazu. Z faktů v databázi může být získán další fakt použitím pravidel jako jejich logický důsledek. Logickým důsledkem množiny pravidel je každý fakt, který byl z databáze formálně odvozen použitím pravidel. Všechna fakta lze odvodit použitím pravidel s axiomem if…then. To znamená, že substitucí dokázaných faktů do daných faktů jsou vytvořena další fakta. V tomto smyslu lze definovat význam kolekce pravidel v existenci množiny faktů odvoditelných z daných faktů. Tvar pravidla je následující: hlava ←tělo resp. consequent ← antecedent

2.2.4 Výpočtová definice Vychází z vytvoření algoritmu pro stanovení, zda potencionální fakt (predikát s konstantami jako argumenty) je pravdivý nebo nepravdivý. Například se může jednat o algoritmus nalezení minimálního modelu pro množinu pravidel. Pravidla lze např. převést na soustavu rovnic relační

11

algebry. Takto získané rovnice lze řešit iterativně, obdobně jako soustavu algebraických rovnic. Výsledek řešení soustavy rovnic relační algebry se nazývá pevný bod.

2.3 Graf závislostí a rekurze Graf závislostí obsahuje predikáty jako uzly grafu a orientované hrany grafu vyjadřují tu skutečnost, že predikát p je odvoditelný z predikátu q. To znamená, že existuje pravidlo se subcílem označeným predikátem p a s hlavou označenou predikátem q. p

q

Logický program je rekurzivní, jestliže jeho graf závislostí má jeden nebo více cyklů. Predikáty, které jsou součástí jednoho nebo více cyklů, se nazývají rekurzivní predikáty. V příkladu 2-2 se předpokládá, že predikát rodič je koncept obsažený v EDB a predikáty sourozenec, bratranec a příbuzný jsou součástí IDB, rodič(R,D) znamená, že R je rodičem D. Graf závislostí:

příbuzný

bratranec

sourozenec

rodič

Obr. 2-1

2.4 Bezpečná pravidla Podmínkou při definování pravidel je (mají-li mít operace nad databází smysl), aby byly operace prováděny nad konečnými relacemi. Existují dva zdroje, které vedou k nekonečným relacím: • Proměnná se vyskytuje pouze ve vestavěném predikátu. • Proměnná se vyskytuje pouze v hlavě pravidla. Pravidla by měla mít tu vlastnost, že nebudou vytvářet z konečných relací relace nekonečné. Existují v podstatě dva způsoby, jak zabezpečit výše

12

uvedenou vlastnost. Jednou možností je limitovat každou proměnnou, která se objeví v pravidle a druhou možností je povolit pouze ordinární (ne vestavěné) predikáty, které korespondují s konečnými relacemi.

2.4.1 Formální limitování proměnných podle [15] 1) Každá proměnná, která se objeví jako argument v ordinárním predikátu v těle pravidla je limitována. 2) Každá proměnná X, která se objeví ve výrazu typu X = a nebo a = X (kde a je konstanta) je limitována. 3) Proměnná X je limitována, pokud se objeví ve výrazu typu X = Y, kde Y je limitována proměnná. Pravidlo je definováno jako bezpečné, jestliže všechny jeho proměnné jsou limitovány. Příklad pravidel, která nejsou bezpečná: p(X,Y) ← X = Y limitovány p(X,Y) ← q(Y)

proměnné

X,Y

nejsou

proměnná Y je limitována výrazem q(Y), ale proměnná X není limitována

Příklad bezpečného pravidla: P(X,Y) ← q(X,Z) & T = b & Y = T proměnné X, Z sou limitovány výrazem q(X,Z), proměnná T je limitována výrazem T = b, proměnná Y je limitována výrazem Y = T.

2.5 Vyhodnocování nerekurzívních pravidel V dalším textu budou předpokládána pouze bezpečná pravidla, která neobsahují negace. Taková pravidla jsou označována jako pravidla “datalogovská”. V atalogovské třídě pravidel existuje způsob převedení nerekurzivních pravidel do výrazů relační algebry a lze vždy nalézt takové uspořádání ve vyhodnocovaných pravidlech, že relace v ěle zrovna vyhodnocovaného pravidla jsou k ispozici [14]. Nechť existuje pravidlo r obsahující predikáty p1, …pn. Je-li toto pravidlo nerekurzivní, pak lze vytvořit graf závislostí p1, …, pn tak, že existuje-li hrana pi → pj, pak i < j. Jednotlivé relace lze vypočíst v ořadí p1, …, pn, přičemž při výpočtu relace pi se objeví pouze dříve vypočtené predikáty. Výpočet relace pro každý predikát pi lze podle [15] rozdělit do dvou kroků: 1) Pro každé pravidlo r, které má pi v lavě, se stanoví relace odpovídající tělu pravidla jako přirozené spojení dílčích relací, jejichž predikáty se vyskytují v ěle pravidla r. V ěle pravidla se vyskytují predikáty relací z BD, resp. IDB. Protože se jedná o

13

nerekurzivní pravidlo, lze předpokládat, že všechny relace z DB s redikáty pk, kde k < i jsou již vypočteny. 2) Vypočte se projekce relace získané v odě 1) dle proměnných vyskytujících se v ěle pravidla. Pokud existuje více pravidel rm, která mají pi v lavě pravidla, pak se bod 1) provede pro každé pravidlo rm a následně se provede sjednocení všech dílčích relací.

Příklad 2-4: Příklad vychází z pravidla 2) v příkladu 2-2: bratranec(X,Y) ← rodič(X,Xp) & rodič(Y,Yp) & sourozenec(Xp,Yp) Nechť jsou vypočteny relace R a S pro predikáty rodič a sourozenec. Pravidlo 2) lze převést na rovnici relační algebry, která má následující tvar: B(X,Xp,Y,Yp) = R(X,Xp) ∗ R(Y,Yp) ∗ S(Xp,Yp) Operátor ∗ je operátor přirozeného spojení, který je asociativní a komutativní, tzn. nezáleží na pořadí uvedených predikátů. Relace B(X,Xp,Y,Yp) se skládá ze čtveřic (a,b,c,d) takových, že: (a,b) je obsažena v R (c,d) je obsažena v R (b,d) je obsažena v S Všechny čtveřice (a,b,c,d), které po dosazení do těla pravidla ohodnocují formuli jako true, tvoří relaci B.

Příklad 2-5: Příklad demonstruje vyhodnocování nerekurzivních pravidel dle [15]. Nechť existují následující čtyři pravidla. 1) p(a,Y) ← r(X,Y) 2) p(X,Y) ← s(X,Z) & r(Z,Y) 3) q(X,X) ← p(X,b) 4) q(X,Y) ← p(X,Z) & s(Z,Y) Predikáty r a s jsou EDB predikáty, z čehož lze předpokládat existence relací R a S. Predikáty p a q jsou IDB predikáty, pro které je nutné vypočítat relace P a Q. Nejdříve je třeba vylepšit pravidla 1) a 3) odstraněním konstanty a opakované proměnné v hlavách pravidel. Pravidla lze upravit následovně: 1) p(X,Y) ← r(Z,Y) & X=a 2) p(X,Y) ← s(X,Z) & r(Z,Y)

14

3) q(X,Y) ← p(X,b) & X=Y 4) q(X,Y) ← p(X,Z) & s(Z,Y) Výpočet algebry:

relace P se provede převedením pravidel na operace relační P(X,Y) = πX,Y(R(Z,Y) ∗ {a}) ∪ πX,Y(S(X,Z) ∗ R(Z,Y))

kde: πX,Y je projekce atributů X,Y, {a} je unární konstantní relace, ∗ je operace přirozeného spojení, ∪ je operace sjednocení. Dále se vypočte relace Q: Výraz pro dílčí relaci p(X,b) je: πX (σZ=b(P(X,Z)) kde: Z je libovolně zvolená proměnná, σZ=b je podmínka selekce, πX je projekce atributu X. Výše uvedený výraz přinese do relace q(X,Y) pouze atribut X. Relace však obsahuje i atribut Y, jehož hodnoty se rovnají hodnotám atributu X. Atribut Y do relace přinese výraz πY(P(Y,W)), kde W je opět libovolně zvolená proměnná. Kartézský součin (označený operátoren x) těchto dvou projekcí za podmínky, že X = Y je vyjádřením pravidla 3). σX=Y(πX(σZ=b(P(X,Z))) x πY(P(Y,W))) Pravidlo 4) lze zapsat výrazem: πX,Y (P(X,Z) ∗ S(Z,Y)) Výsledná relace Q je: Q(X,Y) = σX=Y(πX(σZ=b(P(X,Z))) x πY(P(Y,W))) ∪ πX,Y(P(X,Z) ∗ S(Z,Y))

15

2.6 Rekurzivní pravidla Pravidlo je rekurzivní, pokud ve své hlavě obsahuje predikát shodný s predikátem v těle pravidla. Rekurzivní pravidla se vyskytují v dotazech na tranzitivní uzávěr množiny závislostí (chápaný ve smyslu [17]). Takový dotaz se skládá ze dvou pravidel. Startovacího pravidla, které je nerekurzivní a zabezpečuje bázi rekurze a rekurzivního pravidla, které zabezpečuje indukci.

2.6.1 Vyhodnocování rekurzívních pravidel Při vyhodnocování rekurzivních pravidel (tj. v grafu závislostí jednotlivých predikátů se vyskytuje cyklus) je situace složitější v tom, že výpočet dílčí relace obsahuje výraz, který ještě není vyhodnocen. Základní myšlenkou deduktivních databází je možnost odvozování faktů použitím pravidel a další využití těchto faktů k odvozování dalších faktů. Existuje-li konečná databáze EDB, na kterou se použijí datalogovská pravidla, existuje pouze konečný počet různých faktů, která mohou být odvozena. Tato fakta musí být ve tvaru p(a1, …, ak), kde p je IDB predikát a a1, …,ak jsou konstanty databáze. Pomocí pravidel lze vyjádřit graf závislostí uvedený na obr.2-1 a to s následujícím označením relací pro uvedené predikáty: R … rodič S … sourozenec B … bratranec P … příbuzný Graf závislostí pak lze podle [15] vyjádřit následujícími pravidly: 1) S(X,Y) = πX,Y(σX<>Y(P(X,Z) ∗ P(Y,Z))) 2) B(X,Y) = πX,Y(R(X,Xp) ∗ R(Y,Yp) ∗ S(Xp,Yp)) ∪ πX,Y(R(X,Xp) ∗ R(Y,Yp) ∗ B(Xp,Yp)) 3) P(X,Y) = S(X,Y) ∪ πX,Y (P(X,Z) ∗ R(Y,Z)) ∪ πX,Y(P(Z,Y) ∗ R(X,Z)) Výpočet relace B z pravidla 2) vyžaduje znalost B(Xp,Yp), ovšem tato relace ještě není vypočtena. Pravidlo 2) je třeba transformovat do soustavy rovnic relační algebry. Takto získané rovnice lze řešit iterativně, obdobně jako soustavu algebraických rovnic. Řešením soustavy rovnic relační algebry je tzv. pevný bod. Metoda pevného bodu je jedna z metod odvozování faktů z pravidel obsahujících rekurze. Vstupem do metody je kolekce datalogovských pravidel s EDB predikáty r1, …., rk a IDB predikáty p1, …, pk včetně příslušných relací R1, ….Rk. Výstupem je nejmenší pevný bod, který představuje množinu faktů odvoditelných z dané množiny pravidel. Pevný bod se získá řešením datalogovských rovnic získaných z pravidel.

16

2.7 Negace v pravidlech Situace, kdy je potřeba do těla pravidla umístit negativní literál je celkem frekventovaná. Čistě teoreticky již takové pravidlo není Hornovou klauzulí. Při přepisu takového pravidla do relační algebry by bylo nejjednodušší použít operace doplňku, který ovšem není základní operací relační algebry, a proto je vhodnější použít operaci rozdílu. Doplněk konečné množiny může být nekonečný a tato situace není přípustná z hlediska bezpečnosti deduktivních pravidel. Z uvedeného důvodu nelze nad doplňkem provádět operace selekce a spojení. Problém může nastat, pokud se v těle pravidla vyskytne proměnná pouze v negativním literálu. V takovém případě je třeba proměnnou eliminovat.

Příklad 2-6: Nechť existují predikáty muž(X), rodič(X,Y) a pomocí deduktivních pravidel je odvozen predikát není_otec(X). není_otec(X) ← muž(X) ∧ ¬rodič(X,Y) Odstranění proměnné Y: otec(X) ← muž(X) ∧ rodič(X,Y) není_otec(X) ← ¬otec(X) Přepis do relační algebry: není_otec(X) = muž(X) - πX (rodič(X,Y)) V souvislosti s výskytem negace v těle pravidla vyvstává problém stratifikace. Stratifikace může být dosaženo pouze tehdy, lze-li pravidla rozdělit do takových vrstev, že k vyhodnocení každé vyšší vrstvy jsou vyžadována pouze fakta vyhodnocena v nižší vrstvě. Stratifikace nemůže být dosaženo, pokud se v pravidle vyskytuje koncept závislý na sobě samém jak negativně, tak rekurzivně. Nechť existuje množina pravidel, ve které se vyskytují predikáty p, q. Existuje-li pravidlo ve tvaru p ← ¬ q a zároveň existuje v grafu závislostí hrana z p do q, je daná množina pravidel nestratifikovatelná. Pro zjištění, zda daná množina pravidel je či není stratifikovatelná existuje jednoduchý algoritmus, který zároveň rozdělí pravidla do vrstev, ve kterých mají být vyhodnocována. Algoritmus je např. popsán v [15].

Pojmy k zapamatování: EDB, IDB,

17

dedukce, deduktivní pravidlo, formule, klauzule, Hornovy klauzule, interpretace klauzule, graf závislostí, rekurze, bezpečnost pravidel, vyhodnocování pravidel

Úkoly k zamyšlení: 1. Navrhněte pravidlo, které nebude bezpečné. Zdůvodněte, proč je tomu tak. 2. Navrhněte soubor pravidel, která budou obsahovat rekurzi. 3. Vytvořte praktický příklad pro odvození faktu z množiny faktů a pravidel.

Kontrolní otázky: 1. Jaké mohou být argumenty predikátů v Datalogu? 2. Uveďte příklad atomické formule s vestavěným predikátem. 3. Co je logickým ekvivalentem k zápisu¬p1 ∨ … ∨ ¬pn ∨ q a jak vypadá zápis takovéto Hornovy klauzule v Datalogu? 4. Vytvořte graf závislostí k příkladu 2-1.

18

3 DEDUKTIVNĚ OBJEKTOVÉ SYSTÉMY ŘÍZENÍ BÁZE DAT Cíl: Po prostudování kapitoly 3 budete lépe rozumět důvodům k přechodu od relačních databází k databázím objektovým a deduktivním, resp. objektovědeduktivním. Dále budete umět krátce charakterizovat některé systémy řízení báze dat založené na objektově-deduktivních paradigmatech.

Klíčová slova: Deduktivní databáze, objektově-orientované systémy řízení báze dat, Florid, Gedblog, Illustra, ODE, Validity, RockRoll, P/FDM.

Průvodce studiem: Problémy spojené s klasickým návrhem informačních systémů lze rozdělit do dvou skupin. Hlavní problém přináší ta skutečnost, že reálný svět je mnohem složitější než je schopen postihnout jeho model (informační systém). Dalším problémem je korektnost informačního systému a uspokojivá transformace dotazů sestavených v přirozeném jazyce do jazyka umělého, včetně interpretace odpovědí. Snaha řešit tyto problémy posouvá výzkum a vývoj v oblasti databázových technologií směrem k technologiím objektovým a deduktivním. Deduktivní databáze reprezentují přístup, který vznikl z požadavku rozšíření vyjadřovací síly relačního jazyka a zároveň zachování jeho neprocedurality. Nezanedbatelná výhoda deduktivních databází ovšem spočívá rovněž v redukci dat, kdy je možno nahradit velké množství dat několika deduktivními pravidly. Zajímavý je příklad F.Bryho, který realizoval informační systém veřejné dopravy s využitím deduktivní databáze. „Pravidlo: Je-li svátek, platí jízdní řád jako v neděli nahradí mnoho konkrétních denních jízdních řádů“ [14]. Zajištění větší flexibility při řešení multimediálních a distribuovaných požadavků je problém, jehož řešení se spojuje se vznikem objektověorientovaných databází. Objektově-orientované systémy řízení báze dat by měly zajistit větší flexibilitu při práci s velkými objemy dat, při práci s komplikovanými transakcemi a při zakomponování databází do moderních distribuovaných architektur (např. COBRA). Současné trendy ve vývoji databázové technologie ukazují, že vedle tradičních databázových systémů 2. generace budou vyvíjeny systémy pro bohatší podporu struktur objektů a pravidel. Požadavky jsou kladeny na správu objektů a implementaci pravidel. Ve většině deduktivně objektových systémů řízení báze dat jsou pravidla zabudována do metod tříd, což vede k duplicitním kódům. Vhodnější přístup k využití deduktivních pravidel je možné spatřovat v udržování pravidel zvlášť (jako samostatné objekty) a

19

umožnit na ně konstruovat i dotazy. Vzhledem k univerzalitě a širokému využívání jazyka SQL se dá předpokládat, že zůstane zachován i ve většině budoucích databázových systémů. To ovšem nebrání implementaci objektových a deduktivních jazyků, jak jsou toho příkladem jazyky O-Telos a Chimera, jejichž charakteristice se budeme ještě v této opoře věnovat. I když spojení deduktivně objektová databáze není jediné možné a bylo vyvinuto několik deduktivně relačních systémů řízení báze dat, založených na DATALOGu (LDL, NAIL!, POSTGRES), výzkum a vývoj se v současné době zaměřuje především na spojení těchto dvou přístupů, tj. objektového a deduktivního. V této souvislosti lze jmenovat např. systémy ConceptBase, Florid, Gedblog, Illustra, ODE, Validity RockRoll, P/FDM. Systém ConceptBase je podrobně popsán v kapitole 4 a je snadno dosažitelný v plně funkční podobě na Internetu včetně nezbytné dokumentace. (http://www-i5.informatik.rwth-aachen.de/CBdoc/cbaccess.html). Následuje krátká charakteristika ostatních, výše uvedených systémů řízení báze dat. Podrobnější popis by byl nad rámec předkládané výukové opory. Pro bližší seznámení se s popisovanými systémy jsou uváděny odkazy na další materiály, vesměs na URL adresy.

3.1 Florid Florid je deduktivně objektový databázový systém, který využívá jazyka Flogic k definování datových struktur a dotazování. F-logic je navržen jako logický, deklarativní jazyk, který akceptuje objektově-orientované modelování dat, a který kombinuje deklarativní sémantiku a expresivitu deduktivních databázových jazyků s bohatými modelovacími schopnostmi objektově-orientovaných datových modelů. Systém Florid podporuje definice schémat databáze včetně vícenásobné dědičnosti. Vyhodnocování logických programů je založeno na postupu zdola-nahoru vycházejícího z DATALOGu. Florid umožňuje komunikaci s web servery a tudíž zabezpečuje přístup k web dokumentům. Florid byl vyvinut na univerzitě v Mannheimu a Freiburgu. Více informací o jazyku F-logic lze získat na URL adrese: http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?F-Logic nebo na adrese http://www.cs.sunysb.edu/~kifer/dood/.

3.2 Gedblog Gedblog je logický systém řízení báze dat (založený na logické databázové teorii), který má schopnost zpracovávat ne-grafické i grafické informace. Byl vyvinut jako rozšíření systému Edblog právě o možnost zpracování grafických informací. Gedblog využívá logické teorie založené na různých typech klauzulí:

20

• • • •

Hornovy klauzule (pravidla pro vyjádření intenzionální databáze a fakta pro extenzionální databázi). Integritní omezení jsou interpretována tak, že instance hlavy pravidla jsou dedukovány, jestliže tělo pravidla je vyhodnoceno jako true. Kontroly podmínek platnosti (check). Syntaxe podmínek platnosti je: A1&….&An → B1 &….&Bm Transakce, které představují vykonání modifikace extenzionálních dat za situace, jsou-li splněny stanovené podmínky.

Více informací o systému lze získat na adrese: http://rep1.iei.pi.cnr.it/projects/GEDB/.

3.3 Illustra Illustra je vcelku nový systém řízení báze dat (z r. 1995), který spojuje relační systém s objektovou orientací a s aktivními pravidly. Illustru bychom mohli označit jako objektově relační systém řízení báze dat, který disponuje relačním datovým modelem, jazykem SQL a který je rozšířen o objektovou orientaci (dědičnost, metody, …). Pro definování struktur databáze. Illustra disponuje vestavěnými datovými typy a jakýmikoli uživatelem definovanými datovými typy. Dědičnost se vztahuje jak na atributy, tak na funkce. Funkce v Illustře jsou části kódu, zapsaného v SQL nebo v C, které mohou být uchovávány v databázi a mohou být volány. Pravidla využívá Illustra k tomu, aby přebírala zodpovědnost za správnost manipulace s daty (jednoduché operace Insert, Delete, Update), tzn. pravidla slouží převážně k definování integritních omezení.

3.4 ODE Systém ODE je založen na databázovém programovacím jazyku O++, který je rozšířením jazyka C++ o podporu řízení dat jako jsou transakce, perzistentní objekty a aktivní pravidla. V ODE je koncept aplikační domény modelován prostřednictvím tříd, jejichž syntaxe a sémantika je inspirována jazykem C++. ODE využívá jak perzistentních, tak volativních objektů (pozn. perzistence, resp. volativnost není vlastnosti tříd, nýbrž vlastností objektů). Deduktivní pravidla systém ODE nepodporuje, pouze pravidla aktivní, která se v ODE nazývají triggery. Pokud chceme možností deduktivních pravidel využít i v systému ODE, je třeba je transformovat do triggerů. To znamená převést deklarativní výraz na O++ funkci. Transformovat lze rovněž rekurzivní pravidlo využitím rekurzivní funkce jazyka O++. Generická integritní omezení systémem ODE přímo podporována nejsou. Integritní omezení jsou přeložena do aktivních pravidel (triggerů). Při překladu je třeba replikovat všechna aktivní pravidla, která vznikla transformací deduktivních pravidel, v příslušných třídách, protože ODE nepodporuje necílené koncepty (pozn. pojem cílený resp. necílený koncept bude vysvětlen dále).

21

Pro více informací lze sáhnout na adresu: http://www.nada.kth.se/~sam/Pim/Db/userguide.html.

3.5 Validity Validity patří do skupiny deduktivně objektových databázových systémů. Často se vyskytuje termín deduktivní a objektově-orientované databáze (DOOD). Současný výzkum v oblasti deduktivních databází je zaměřen na spojení deduktivních schopností s objektově orientovanými databázemi za účelem kombinace výhod expresivity objektových datových modelů a deklarativního stylu logického programování. Validity je prvním komerčním produktem na tomto poli výzkumu a vývoje. Deduktivní jazyk implementovaný v systému Validity se nazývá DEL (Datalog Extended Language). DEL umožňuje uživatelem definované typy, jednoduchou i vícenásobnou dědičnost, metody. Deklarativní DEL je jazykem pro psaní formulí, které jsou používány jako deduktivní pravidla a integritní omezení. Příkazový DEL je databázový programovací jazyk, umožňující zapisovat aplikační transakce, těla funkcí a metody. Současná verze systému Validity neumožňuje zapisovat aktivní pravidla. Více informací o systému Validity lze získat např. z článku Oris Friesen, Alexandre Lefebvre, Laurent Vieille: VALIDITY: Applications of a DOOD System. EDBT 1996: 131-134, Springer.

3.6 RockRoll RockRoll je deduktivní a objektově-orientovaný databázový systém, který disponuje příkazovým databázovým jazykem ROCK a deduktivním dotazovacím jazykem ROLL. ROCK může být použit pro definování schématu databáze a pro manipulaci s daty, zatímco ROLL se využívá k tvorbě dotazů a k definování deklarativních metod. Více informací lze nalézt na adrese: http://www.cee.hw.ac.uk/Databases/rnr.html.

3.7 P/FDM P/FDM je systém řízení báze dat, který byl navržen pro řešení netradičních aplikací, jako jsou aplikace pro návrh databází. Jedná se o systém založený na datovém modelu v Prologu, který je rozšířen o některé rysy objektověorientovaných datových modelů. Manipulace s daty je realizována jednoduchými operacemi, implementovanými jako procedury v Prologu. Kromě Prologu je součástí P/FDM i kompilátor jazyka Daplex (jazyk pro definice dat a manipulaci s daty). Daplex je deklarativní jazyk vysoké úrovně. Výstupem z kompilátoru Daplexu je prologovský program, který obsahuje vložená volání jednoduchých databázových operací. Daplex obsahuje optimalizátor dotazů, který využívá heuristické vyhledávání. Kompilátor je schopen přeložit generická integritní omezení vyjádřená v Daplexu do fragmentů programu v Prologu, který hlídá integritu dat

22

při aktualizaci databáze. P/FDM disponuje grafickým uživatelským rozhraním, založeným na formulářích. Ve vývoji je verze systému, která bude využívat tří-rozměrnou grafiku. Systém pracuje ve vyspělém víceuživatelském režimu. Ucelenou představu o systému lze získat prostudováním web stránek na adrese http://www.csd.abdn.ac.uk/~pfdm/.

Průvodce studiem: Kromě výše zmíněných SŘBD existují a jsou více méně ověřovány i další systémy, jako např. Algres, LDL++, Quixote, Aditi, Coral, XSB a další. Některé z nich jsou volně dostupné na Internetu, v některých z nich již byly vytvořeny četné aplikace. Většinou se jedná o systémy vyvinuté na západoevropských a amerických univerzitách.

Pojmy k zapamatování: Deduktivní databáze, objektově-orientované systémy řízení báze dat, Florid, Gedblog, Illustra, ODE, Validity, RockRoll, P/FDM.

Úkoly k zamyšlení: Pokuste se najít na Internetu některé další systémy řízení báze dat, které vykazují charakteristiky deduktivních databází. Krátce je popište včetně tříd aplikací, na kterých již byly využity.

Kontrolní otázky: 1. Co je hlavní výhodou deduktivních databází? 2. Jaké jsou základní charakteristiky deduktivních systémů pro řízení báze dat (SŘBD)? 3. Jaké znáte deduktivní SŘBD?

23

4 DEDUKTIVNĚ OBJEKTOVÝ DATABÁZOVÝ SYSTÉM CONCEPTBASE A JEHO ZÁKLADNÍ KOMPONENTY Cíl: Po prostudování této kapitoly budete umět: -

vyjmenovat klíčové charakteristiky ConceptBase,

-

vyjmenovat a popsat vzory tvrzení v ConceptBase,

-

vyjmenovat a vysvětlit Telosovské axiomy,

-

sestavit jednoduchý model v Telos,

-

sestavovat literály a formule v Telos,

-

sestavovat dotazy v Telos,

-

převést E-R diagram na CB graf.

Klíčová slova: ConceptBase, Logický, rámcový a grafický formát, Telos, vzory tvrzení, třídy znalostní báze, Telosovské axiomy, CBL, dotazování, model, metamodel. Systém ConceptBase je rozšířením relačních databázových systémů ve dvou směrech. Jednou oblastí je zavedení objektově orientovaných abstrakcí do datového modelu, dalším rozšířením je zabudování deduktivních abstrakcí a v tomto ohledu je systém ekvivalentem logických a sémantických sítí. Co se týká architektury, systém ConceptBase je systémem s architekturou klient server. V ConceptBase je implementován jazyk pro reprezentaci znalostí Telos. Databáze v ConcetBase je objektovou databází s pravidly jako atributy tříd. Hlavní rozšíření je v přidání komplexních domén, sdílených objektů a procedur do databáze. Znalostní reprezentace vychází z deduktivních databází nebo ze sémantických datových modelů. Jazyk Telos umožňuje integrovat deduktivní a objektově-orientované datové modely.

Průvodce studiem: Veškeré definice, axiomy a vzorce, použité v této kapitole, jsou přebrány od autorů systému ConceptBase (Lehrstuhl Prof. Dr. Matthias Jarke, c/o ConceptBase Team). Většina literatury pro zpracovní této kapitoly byla získána prostřednictvím Internetu na zdrojové adrese http://wwwi5.informatik.rwth-aachen.de/CBdoc/.

24

Definice 4-1 podle[25] ConceptBase je deduktivní objektově orientovaný systém řízení metadatabází, zaměřený především na konceptuální modelování. Systém má implementován jazyk Telos.

Klíčové charakteristiky: • • • • • • • • • • •

Logický, rámcový a grafický pohled na uložené objekty. Neomezená možnost rozšiřování hierarchie tříd. Deduktivní pravidla a integritní omezení jako atributy tříd. Dotazy jako třídy s omezeným členstvím. Komplexní pohledy. Aktivní pravidla se schopností aktualizovat databáze a spouštět externí programy. Perzistentní objekty s možným přístupem k historii objektů. Úroveň meta pravidel a integritních omezení pro axiomatické rozšíření jazyka. Optimalizace dotazů. Grafický prohlížeč. Interface pro deklaraci dotazů a tvorbu Telosovských objektů.

Všechny třídy, meta třídy, instance, atributy, pravidla, integritní omezení a dotazy jsou reprezentovány jako objekty. Každý objekt může být aktualizován po dobu životního cyklu objektové báze. Dokonce členství ve třídě je reprezentováno jako objekt. Sémantika Telosu je založena na DATALOGu. Schopnost metamodelování dovoluje využívat heterogenní modelovací jazyky jako E-R diagram, OMT, atd. jako Telosovské metatřídy, jejichž pravidla a integritní omezení zakóduje do axiomů např. procesem generalizace. Metatřídy mohou existovat v rámci stejné objektové báze. Objekt popsaný v jednom modelovacím jazyku může být spojen s objektem popsaným v jiném modelovacím jazyku. ConceptBase sleduje klient-server architekturu. Klientský program se může spojit s ConceptBase serverem a měnit data s využitím komunikačního protokolu Internetu. Programovací interface umožňuje uživateli vytvářet vlastní klientské aplikace v Jave, C nebo Prologu. ConceptBase využívá X11 interface, který nabízí grafické, tabulkové a textové nástroje pro editování a prohlížení objektové báze.

4.1 Jazyk Telos v ConceptBase Model vytvořený v jazyce Telos zevšeobecňuje dřívější datové modely a znalostní reprezentace, jako E-R diagram nebo sémantické sítě a spojuje je s predikátovými tvrzeními a dočasnými informacemi.

25

Příklad 4-1: Následuje stručné popsání reality, na které budou demonstrovány některé příklady kapitoly 4. Společnost má zaměstnance, někteří z nich mohou být manažéry. Zaměstnanci mají jméno a plat, které se může občas měnit. Jsou přiřazeni k oddělení, které je vedeno manažérem. Vedoucí zaměstnance může být odvozen od oddělení zaměstnance a manažéra oddělení. Žádnému zaměstnanci není dovoleno vydělat více, než vydělává jeho vedoucí. Telos podporuje tři různé formáty pro zápis příkazů. Základním formátem je formát logický, který umožňuje začlenit jazyk predikátových tvrzení pro deduktivní pravidla, dotazy a integritní omezení. Dalšími formáty je formát grafický (sémantická síť) a formát rámcový (frame). Oba formáty jsou založeny na formátu logickém a jsou z něho odvozeny.

4.1.1 Logická interpretace znalostní báze Znalostní báze v Telosu je založena na konečné množině vzájemně propojených tvrzení, která jsou zde chápána jako objekty. KB = {P(oid, x, l, y, tt)| oid, x, y, tt ∈ID, l ∈ LABEL }, kde: oid je identifikátor, který je klíčem v znalostní bázi, ID je neprázdná množina identifikátorů, LABEL je neprázdná podmnožina jmen, x je zdroj, l je jméno, y je cíl, tt je doba trvání. Objek x má vztah s objektem y, kde jméno vztahu je l. Vztah se předpokládá do doby tt.

4.1.2 Vzory tvrzení V ConceptBase jsou rozeznávány čtyři vzory tvrzení a jsou jim dávána následující jména: 1) Individuals P(oid, oid, l, oid, tt) Toto tvrzení vytváří objekt oid se jménem l, jehož trvání se předpokládá do doby tt. 2) InstanceOf relationship (instantiations)

26

P(oid, x, *instanceof, y, tt) Toto tvrzení vytváří instanci x třídy y do doby tt. 3) IsA relationships (specializations) P(oid, x, *isa, y, tt) Toto tvrzení vytváří třídu x jako specializaci třídy y do doby tt. 4) Attribute Všechna další tvrzení.

4.1.3 Předdefinované třídy Telosovské znalostní báze Telos využívá strukturální axiomy, jejichž úplný výčet je uveden v publikaci [18]. Tyto axiomy jsou spojeny s předdefinovanými třídami, které jsou automatickou součástí každé Telosovské znalostní báze. Individual obsahuje všechny individualy jako instance InstanceOf obsahuje všechny konkretizace jako instance IsA obsahuje všechny specializace jako instance Attribute obsahuje všechny atributy jako instance Proposition obsahuje všechna tvrzení jako instance Class obsahuje všechny třídy (včetně sebe) jako instance Token obsahuje ty individualy, které již nemohou mít instance SimpleClass obsahuje individualy, které mohou mít instance, které jsou Token MetaClass obsahuje individualy, které mohou mít instance, které jsou SimpleClass Metameta Class

obsahuje individualy, které mohou mít instance, které jsou MetaClass

Navíc Telos využívá vestavěných tříd jako Integer, Real a String.

4.1.4 Některé Telosovské axiomy Uživatelé nepracují přímo s tvrzeními, ale s jejich textovou (frame) nebo grafickou (sémantická síť) podobou. Tyto formáty nejsou založeny na oid objektů, ale na jejich komponentě label. Aby bylo garantováno jednoznačné mapování, musí platit axiom pojmenování. Axiom pojmenování Jméno individualu musí být jednoznačné, jména všech atributů společného zdrojového objektu musí být rovněž jednoznačná.

27

Specializační axiom Cílový objekt specializace dědí všechny instance svého zdroje. Dle příkladu 4-1 všechny instance třídy Manažér jsou zároveň instancemi třídy Zaměstnanec. Konkretizační axiom Jestliže p je tvrzení, které je instancí tvrzení P, pak zdroj p musí být instancí zdroje P a cíl p musí být instancí cíle P.

4.2 Jednoduchý model v Telos Nechť existuje následující jednoduchý model:

O so b a

P a cien t

Lék

Jakub

P en icilín

Obr. 4-1 Pak tvrzení, korespondující s uvedenými objekty a vztahy, jsou následující: 1) Proposition(Osoba, Osoba, -, Osoba) 2) Proposition(Pacient, Pacient, -, Pacient) 3) Proposition(#1, Pacient, *isa, Osoba) 4) Proposition(Lék, Lék, -, Lék) 5) Proposition(#2, Pacient, bere, Lék) 6) Proposition(Penicilín, Penicilín, -, Penicilín) 7) Proposition(#3, Penicilin, *instanceof, Lék) 8) Proposition(Jakub, Jakub, -, Jakub) 9) Proposition(#4, Jakub, *instanceof, Pacient) 10) Proposition(#5, Jakub, lék1, Penicilín) 11) Proposition(#6, #5, *instanceof, #2)

28

Oid, výše označováno #, je generováno systémem. Objekty, korespondující s tvrzeními 1), 2) a 4), jsou individualy. Ostatní objekty se nazývají atributy a to atributy instanční, které mají třetí komponentu *instanceof a atributy specializační, které mají třetí komponentu *isa. Je-li tvrzení ve formě Proposition(oid, x, *instanceof, c), pak x je instancí c (c je třídou x). Je-li tvrzení ve formě Proposition(oid, c, *isa, d), pak c je subclass d (d je superclass c).

4.3 Predikátový jazyk CBL jako součást Telos Predikátový jazyk CBL se využívá k vyjádření integritních omezení, deduktivních pravidel a dotazů. Proměnné, použité ve formulích, musí být kvantifikovány a spojeny s typem, který limituje rozsah možných instancí z množiny instancí dané třídy. Obvykle je znalostní báze omezena do doby rollbacku, která závisí na typu formule. KBrbt = {P(oid, x, l, y, tt) in KB | rbt during tt} Integritní omezení je vyhodnocováno v aktuální KB (rbt představuje aktuální čas prováděné transakce). Rollback pro dotaz je dán dobou vyhodnocení dotazu. Význam použitých symbolů je shodný s významem odpovídajících symbolů v kapitole 4.1.1.

4.3.1 Literály, umožňující přístup k Telos objektům 1) (x in c) resp. in(x,c) infixová, resp. prefixová notace Objekt x je instancí třídy c. 2) (c isA d) resp. IsA(c,d) Objekt c je specializací třídy d. 3) (x m y) resp. A(x,m,y) Objekt x má atribut, jehož hodnoty jsou instance objektu y. Takto definovaný vztah je instancí kategorie atributů s označením m. 4) From(p, x) Objekt p má zdroj v objektu x. 5) To(p, y) Objekt p má cíl v objektu y. 6) Label(p, l) Objekt p má jméno l. Následující literály definují druhou třídu formulí: 7) x < y, x > y, x <= y, x >= y, x = y, x <> y, kde x,y musí být instance třídy Integer nebo Real. 8) x = = y

29

Objekty x a y jsou totožné.

4.3.2 Kvantifikovatelné proměnné Formule s univerzálním kvantifikátorem má tvar: Forall x | c F nebo forall x(x in c) → F Pro všechny instance x třídy c platí formule F. Formule s existenčním kvantifikátorem má tvar: Exists x | c F nebo exists x (x in c) and F Existuje instance x třídy c, pro kterou platí formule F.

4.3.3 Restrikce pro formule Každá konstanta, obsažená ve formuli F, musí být jméno existujícího objektu v Telosovské znalostní bázi nebo je to konstanta vestavěné třídy Integer, Real nebo String. Každý atribut (x m y) obsažený ve formuli musí mít unikátní jméno m ve znalostní bázi.

Definice 4-2 podle[25] Legální integritní omezení je CBL formule, která splňuje uvedené restrikce.

Příklad 4-2: Zapišme integritní omezení pro plat zaměstnance/manažéra (vycházeje z příklady 4-1), když platí, že plat zaměstnance/manažéra nesmí být větší než 10.000,- Kč Forall x | Zaměstnanec y | Integer (x plat y) → y <= 10000

30

Forall x | Manažér y | Integer (x plat y) → y <= 10000

Definice 4-3 podle[25] Legální deduktivní pravidlo je CBL formule splňující uvedené restrikce a mající formát: forall x1 | c1 … forall xn | cn R → lit(a1, …, am) kde: lit je literál typu 1) 2) nebo 3), proměnné a1, …, am odpovídají proměnným x1, …xn, které jsou tříd c1 , …ca, R je formule. V Telosu jsou pravidla a integritní omezení definována jako atributy tříd. Text formule je uzavřen do znaků “$“. Následující formule definuje šéfa zaměstnance jako deduktivní pravidlo a stanovuje integritní omezení pro plat zaměstnance, kdy plat zaměstnance nesmí být větší než plat jeho šéfa. Zaměstnanec with Rule ŠéfRule: $forall z | Zaměstnanec m | Manažér (exists o | Oddělení (z oddel o) and (o vedoucí m)) → ( z šéf m) $ constraint PlatHranice: $ forall z | Zaměstnanec b | Manažér x,y | Integer (z šéf b) and (z plat x) and (b plat y) → x < y $ End

4.4 Dotazování v ConceptBase 4.4.1 Začlenění dotazů do objektově orientované databáze Z abstraktního pohledu databáze organizují informace do množin objektů. V objektově orientovaných databázích jsou tyto množiny nazývány třídami a jejich elementy jsou omezovány ne příliš komplikovanými výrazy. Podobné výrazy pro popis tříd objektů (tzv. konceptuální popisy neboli koncepty) jsou zkoumány v umělé inteligenci, kde se vyskytují v jazycích pro reprezentaci znalostí. Tato podobnost mezi databázovým výzkumem a oblastí umělé inteligence nabízí možnost využití rozumných technik pro koncepty při popisech schémat tříd a dotazů v objektově orientované databázi. Dotazy po jejich vyhodnocení vracejí množiny objektů. Objektově-orientované databáze nabízí možnost znovu použít dotazy,

31

protože jejich schémata jsou obvykle bohatší a detailnější než schémata relačních databází. Hodnoty atributů jsou omezeny typy tříd, třídy mohou mít podtřídy s dodatečnými omezeními.

4.4.2 Schéma a dotazovací jazyk Třídy jsou seskupením konečné množiny objektů ( instancí tříd). Předpokládejme, že podmínka pro členství může být vyjádřena výrazem v logice 1. řádu. • Vztahy podtříd

•

Třídy jsou organizovány v hierarchii. Každá instance třídy je také instancí supertřídy. Deklarace atributů Objekty mohou mít atributy, které nabývají hodnot z domén. Domény jsou omezeny třídami. Podtřídy mohou mít atributy omezeny rozsahem podtřídy.

Atributy mohou být specifikovány jako funkce a mají většinou jednu hodnotu, je-li to nutné, pak mají vždy jednu hodnotu. Konceptuální jazyk je velmi podobný jazykům pro definování schémat a dotazů v OODB. Koncept je intenzionální popis množin objektů zkonstruovaných z primitivních konceptů a atributů. Komplexní koncept může být zkonstruován z existujících konceptů.

4.4.3 Třídy dotazů Dotazování v objektových databázích znamená získávání uložených objektů, které odpovídají zadaným podmínkám. V relačních databázích jsou dotazy konstruovány pomocí operací relační algebry a odpovědí jsou opět relace např. množiny n-tic. V objektově orientovaných databázích jsou množiny reprezentovány objekty a je přirozené objekty použít jak pro popis dotazu, tak pro výsledek dotazu, tedy odpověď. Otázkou je, zda odpověď může vytvářet nový objekt, či zda odpověď je nutno uložit do existujícího objektu. V ConceptBase objekty dotazů musí být společné instance všech supertříd. V dotazu lze specifikovat tzv. odvozené koncepty, které se specifikují v klauzuli derived. Forma této specifikace je: Ij: (a1:C1).(a2:C2)…(an:Cn), kde: Ij je návěští, ai jsou atributy,

32

Ci jsou třídy. Návěští odpovídají odvozeným konceptům a dále se využívají v klauzuli where pro porovnávání hodnot vytvořených konceptů. Dotazy obsahují omezení (constraints), která definují další podmínky pro objekty zahrnuté do odpovědi dotazu. Omezení jsou specifikována logickými formulemi podobně jako omezení při definování schématu tříd. Ve formuli se může objevit i návěští. Proměnná this odkazuje na odpověď dotazu.

Definice 4-4 podle[25] V ConceptBase jsou dotazy definovány jako speciální třídy, jejichž instance jsou odpověďmi na příslušné dotazy. Dotazy jsou instancemi systémové třídy QueryClass. QueryClass je definována: Individual QueryClass in Classs isA Class with attribute retrieved_attribute: Proposition; extenzionálních atributů computed_attribute: Proposition intenzionálních atributů attribute, single constraint:MSFOLquery End

pozn.

projekce

pozn.

projekce

pozn. restrikce

Je-li specifikován dotaz, musí být odpověď instancí supertřídy, tj. v rozsahu hodnot definovaných supertřídou.

Příklad 4-3: Definujme Manažéry - odboráře, jako ty manažéry, kteří jsou členovy odborů. Individual Odbory in Class End Individual ČlenOdborů in Class with attribute odbory:Odbory End QueryClass ManažérOdborář isA Manažér, ČlenOdborů end QueryClass ManažérOdborář isA Manažér, ČlenOdborů with retrieved_attribute

33

odbory:Odbory; plat: Integer End Retrieved attribute je obdobou projekce v relační algebře. Atributy musí být prezentovány v jedné ze supertříd querytřídy. V našem příkladu atribut odbory se dědí ze třídy ČlenOdborů a plat se dědí ze třídy Manažér. CBQL vyžaduje projekci atributů v dotazu. Každá odpověď musí zahrnovat projekci atributů.

Příklad 4-4: Specifikujme hodnotu atributu VysokýPlat jako plat Manažéra-odboráře, který je větší než 60.000,-Kč. QueryClass VysokýManažérOdborář isA ManažérOdborář with retrieved_attribute plat:VysokýPlat End Individual VysokýPlat in Class isA Integer with rule VysokýPlatpravidlo: $forall m/Integer (m >= 60000) → (m in VysokýPlat) $ End Třída hodnot atributů VysokýPlat je podtřídou vestavěné třídy Integer, tj. každá odpověď, která vyhovuje dotazu na atribut VysokýPlat vyhovuje i dotazu na atribut plat. ConceptBase pracuje s tzv. query constraint. Jejich definice vychází z definice deduktivního pravidla.

Definice 4-5 podle[25] Nechť Q je query třída s integritním omezením F, které obsahuje předdefinovanou proměnnou this. Pak query pravidlo je definováno jako formule forall this/Proposition F → Q(this) ConceptBase automaticky generuje řešení (this in Q) z literálu Q(this).

Příklad 4-5: Zjistěme všechny Vysoké-manažéry-odboráře, jako Manažéry-odboráře, kteří mají VysokýPlat. QueryClass VysokýManažerOdborář isA ManažérOdborář with

34

retrieved_attribute odbory:Odbory constraint vysokýmanažérpravidlo: $ exists s/VysokýPlat (this plat s) $ End V dotazu se také mohou objevovat tzv. vypočítávané atributy. Tyto vypočítávané atributy se definují pro danou třídu, nikoliv pro její supertřídu. Rozsah hodnot je definován pomocí deduktivního pravidla. Předpis pro výpočet hodnoty vypočítávaného atributu je součástí pravidla v dotazu. Literál, jako odpověď na tento dotaz Q(this, v), obsahuje instance dotazu obsažené v this a vypočítané hodnoty atributu obsažené ve v. Pak je query pravidlo definováno jako formule: Forall this/Proposition forall v/C F → Q(this, v) kde: v jsou vypočítávané atributy, C jsou příslušné třídy atributů v.

Příklad 4-6: QueryClass VysokýManažerOdborář2 isA ManažérOdborář with retrieved_attribute odbory:Odbory computed_attribute vedoucí: Oddělení constraint vysokýmanažérpravidlo: $ exists s/VysokýPlat (this plat s) and (~vedoucí vede this)$ End Pozn. V ConceptBase označení pro vypočítávaný atribut musí mít prefix ~ V dotazech je možno využít rekurze použitím rekurzivních deduktivních pravidel nebo odkazem na třídu dotazu. Dále je možno využívat dotazů s parametrem nebo parametry. Struktura dotazu s parametrem je: Individual GenericQueryClass isA QueryClass with Attribute Parameter:Proposition End

35

Parametry mohou být získané nebo vypočtené hodnoty atributů.

4.5 Modelování a metamodelování v ConceptBase Deduktivně objektový databázový systém ConceptBase lze využít při návrhu a implementaci informačních systémů s podporou metamodelování. Formální metamodel umožňuje formulaci sémantických podmínek mezi různými specifikacemi (např. vytvořenými různými týmy nebo technikami) a tím zabezpečuje koordinaci vývoje informačního systému. Metainformační systém řídí integraci schémat do IS. Schémata subsystému jsou totiž součástí jeho dat. Ve standardu ANSI IRDS (Information Resource Dictionary Standard) je na nejvyšší úrovni omezený E-R model (pouze s binárními vztahy). Jako příklad je možno uvést softwarovou databázi s relačním schématem, aplikačními programy, jejich modulární kompozicí, jejich vzájemnými závislostmi, odkazy na zdroje, atd. Aplikační data obsahují n-tice hodnot a odkazy na konkrétní programy. Nejvyšší úroveň takové softwarové databáze je založena na relačním datovém modelu. Relační model sám je uložen ve schématu ve standardu ANSI IRDS. Standard předpokládá uložení jak datového modelu, tak programů do schématu.

4.5.1 ConceptBase jako nástroj modelování ConceptBase disponuje metamodelovacím nástrojem k definování schémat každého subsystému. Na rozdíl od běžných databázových přístupů, ConceptBase není vhodný k rozlišování mezi datovou úrovní a úrovní schémat (úrovní dat a metadat). Na druhé straně vyžaduje abstrakční formalizmus podobný objektově orientovaným systémům (konstruktor, isa hierarchie, atd.). Důležitý požadavek se týká schopnosti vyjádření závislostí mezi objekty v subsystému. Datový model v ConceptBase zabezpečuje deduktivní formalizmus objektově orientovaného datového modelu. Deduktivní pravidla a integritní omezení jsou jedinými prostředky ke specifikování metod. Z tohoto pohledu je možno deduktivně objektovou databázi v ConceptBase chápat jako trojici: DOB = (OB, R, IC), kde: OB je extenzionální objektová báze, R jsou deduktivní pravidla, IC jsou integritní omezení. Databáze obsahuje předdefinovanou množinu strukturálních axiomů reprezentovanou formulemi v R a v IC. Obvykle je požadováno, aby OB a R vyhovovaly IC, což [25] zapisuje:

36

OB ∪ R╞ IC Extenzionální objektová báze je konečná podmnožina, kterou [25] zapisuje jako: OB ⊆{P(o, x, l, y)|o, x, y∈ID, l ∈ LAB}, kde: o je klíčem v znalostní bázi, ID je neprázdná množina identifikátorů s neprázdnou podmnožinou LAB všech jmen, komponenty o, x, l, y se nazývají identifikátor, zdroj, jméno vztahu a cíl, objekt x má vztah s objektem y, jméno vztahu je l. Elementy OB jsou označovány jako objekty. Extenzionální báze může být vizualizována jako strukturovaná sémantická síť. Objekty označované „individuals” představují uzly sémantické sítě. Objekty označované „instatiations“ a „specializations“ představují hrany (linky). Ostatní objekty jsou nazývány atributy. Sémantická síť může obsahovat linky mezi linkami. ConceptBase neomezuje počet úrovní, schéma může být instancí množiny metatříd, tyto mohou být instancemi metametatříd, atd. Uzávěr může být zabezpečen objektem Object a Class. ConceptBase umožňuje ekvivalentní syntaxi pro deduktivně objektové báze, tzv. frame syntaxi, která pracuje s názvy objektů, nikoli s identifikátory. ConceptBase je vybavena množinou axiomů (jejich plný výčet uvádí publikace [18]), které lze rozdělit do čtyř skupin: • Identita objektů a odkazů.

•

Tyto axiomy definují základ deduktivně objektové databáze. Zabezpečují unikátnost všech interních identifikátorů a referenční integritu všech elementů v OB. Externí pojmenování objektů.

•

Tyto axiomy garantují unikátní mapování objektů z různých forem (grafické, frame) do základní logické formy, ve které jsou objekty identifikovány pomocí unikátního identifikátoru. V praxi to znamená unikátní pojmenování objektů v grafické a frame formě. Definování abstraktních principů jako odvozených vztahů.

•

Jsou zavedeny tři predikáty In, Isa a A. Predikát In(x,y) značí, že objekt x je třídy y, Isa(c,d) značí, že objekt c je s objektem d ve vztahu ISA hierarchie. Predikát A(x,m,y) značí, že objekt x má atribut y s názvem m. Definování abstraktní sémantiky.

37

Tyto axiomy zabezpečují dědičnost ze supertřídy do subtřídy, mnohonásobnou dědičnost, generalizaci a konkretizaci.

Metamodelování v ConceptBase Při vývoji softwarových subsystémů (jako např. informačních systémů) hraje velmi důležitou úlohu proces abstrakce. Metamodely umožňují popisovat abstraktní koncepty vývoje s tím, že se tyto koncepty stávají součástí databází stejně jako modelovaná data. ANSI standard definuje čtyři úrovně abstrakce při modelování. • Úroveň reálného světa.

•

Na této úrovni dochází k identifikaci reality, upřesnění objektů, jejich konkrétních vlastností a vztahů mezi nimi. Úroveň modelu.

•

Na úrovni modelu dochází k seskupování reálných objektů do tříd objektů a tříd atributů (v relační terminologii jsme zvyklí používat pojem doména) a rozpoznávání vztahů mezi třídami. Úroveň metamodelu.

•

Úroveň metamodelu se zabývá klasifikací typů vyskytujících se v modelu a abstrakcí vztahů mezi nimi. Metameta úroveň. Představuje vyjádření obecného v metamodelovacím procesu.

konceptuálního

elementů

přístupu

Metamodely jsou důležité během všech fází vývoje subsystému, klíčovou roli však hrají ve fázi analýzy a návrhu. Ve fázi analýzy model obsahuje popisy tříd objektů systému, vztahy mezi třídami, operace, které mohou být vykonávány v systému, přípustné návaznosti těchto operací. Tyto popisy jsou zahrnuty to tří modelů nazývaných objektový model, model operací a model životního cyklu. Fáze analýzy může rovněž obsahovat model chování systému. Ve fázi návrhu je popisováno, jak se jednotlivé objekty na sebe navzájem odkazují, jak se na objekty vztahuje dědičnost, jaké mají třídy objektů atributy a metody. Odpovídající modely jsou označovány jako graf interakce objektů, graf visibility, graf dědičnosti a popisy tříd. Ve fázi implementace jsou předchozí informace převedeny do příslušného programovacího jazyka. Součástí modelování je tvorba modelu datového slovníku. Jedná se o speciální model, nezařazený do partikulární úrovně abstrakce, protože doprovází celý modelovací proces a zahrnuje jak fázi analýzy, tak fázi návrhu. ConceptBase disponuje modelovacími technikami, odvozenými z E-R modelování, doplněnými o metamodelování s rozumnou množinou

38

omezení, zajišťujících konzistenci. ConceptBase může sloužit jako zásobárna vývojových předloh a může obsahovat jak metamodel, tak aktuální softwarový projekt. Součástí systému ConceptBase je grafický interface, který umožní uživateli zobrazit vztahy mezi vybranými třídami ze znalostní báze (sémantická síť). Kompatibilita s E-R modelem je zachována, tzn., že E-R model je možno převést na příslušnou sémantickou síť, přičemž je vyžadováno, aby atributy byly definovány jako vztahy mezi třídami.

Převod E-R diagramu na CB graf E-R diagram disponuje dvěma konstrukty, je jimi entita a vztah. ConceptBase jako modelovací nástroj na úrovni logického formátu, disponuje jediným konstruktem a tím je tvrzení (Proposition), které je v modelu objektem. Různé vzory tvrzení jsou zapisovány, jak bylo popsáno výše. ConceptBase kromě logického formátu rovněž disponuje grafickým formátem, který umožňuje zakreslit tzv. sémantickou síť. K tomuto účelu je v metamodelování možno využít následujících grafických vzorů: Všechny instance tříd

Vestavěné třídy (Boole, Integer, Real, String)

jméno Vztahy pro přiřazení atributů Isa vztah Konkretizace (instanceof)

Příklad 4-7: Příklad demonstruje definice modelu Ordinace v objektově deduktivním databázovém jazyku Telos. Definice na „Class“ úrovni Třída Ordinace jako subclass třídy Class Individual Ordinace in Class

39

End Třída Osoba v class Ordinace Individual Osoba in Ordinace with attribute jmeno : String; prijmeni : String; rc : String End Třída Pacient jako subclass Osoby (isA vztah) Individual Pacient isA Osoba with attribute poj : Pojistovna End pozn.(atribut poj nabývá hodnot z třídy Pojistovna) Třída Lekar jako subclass Osoby (isA vztah) Individual Lekar isA Osoba with attribute ico : Integer; smlouva : Smlouva End pozn.(atribut smlouva nabývá hodnot z třídy Smlouva) Třída Pojistovna v class Ordinace Individual Pojistovna in Ordinace with attribute kod : Integer; nazev : String End Třída Smlouva v class Ordinace Individual Smlouva in Ordinace with attribute cislo : Integer; lekar : Lekar; pojistovna : Pojistovna; dat_od : String; dat_do : String End pozn. (atribut pojistovna nabývá hodnot z třídy Pojistovna, atribut lekar nabývá hodnot z třídy Lekar)

40

Třída Navsteva v class Ordinace jako subclass objektu Lekar a Pacient Individual Navsteva in Ordinace isA Lekar,Pacient with attribute dat_nav : String; diagnoza : String; dat_kontr : String; lekar : Lekar End pozn.(atribut lekar nabývá hodnot z třídy Lekar) Definice na „Token“ úrovni Objekt Novak jako instance Osoby, Pacienta a Navstevy Individual Novak in Osoba,Pacient,Navsteva with attribute,jmeno novakovojmeno : "Jan" attribute,prijmeni novakovoprijmeni : "Novak" attribute,rc novakovorc : "5502150111" attribute,poj novakovapojistovna : VZP attribute,dat_nav dat_nav : "1.2.1999" attribute,diagnoza diagnoza : "152" attribute,dat_kontr dat_kontr1 : "15.2.1999"; dat_kontr2 : "16.2.1999" attribute,lekar lekar : Kral End Objekt Kral jako instance Osoby a Lekare Individual Kral in Osoba,Lekar with attribute,jmeno kralovojmeno : "Karel" attribute,prijmeni kralovoprijmeni : "Kral" attribute,rc kralovorc : "5501150222"

41

attribute,smlouva kralovasmlouva1 : 000199; kravolasmlouva2 : 000299 End Objekt VZP jako instance Pojistovny Individual VZP in Pojistovna with attribute,kod kodpojistovny : 111 attribute,nazev nazevpojistovny : "Vseobecna zdravotni pojistovna" End Objekt HP jako instance Pojistovny Individual HP in Pojistovna with attribute,kod kodpojistovny : 222 attribute,nazev nazevpojistovny : "Hornicka pojistovna" End Objekt 000199 jako instance Smlouvy Individual 000199 in Smlouva,Integer with attribute,cislo cislosmlouvy : 0001 attribute,dat_od plati_od : "1.1.1999" attribute,dat_do plati_do : "31.12.1999" attribute,pojistovna s_pojistovnou : VZP End Objekt 000299 jako instance Smlouvy Individual 000299 in Smlouva,Integer with attribute,cislo cislosmlouvy : 0002 attribute,dat_od plati_od : "1.1.1999" attribute,dat_do plati_do : "31.12.1999" attribute,pojistovna s_pojistovnou : HP

42

End Definice integritních omezení Následující integritní omezení popisují reálnou situaci, kdy: Lékař a pacient není tatáž osoba: Individual Navsteva in Ordinace,Class isA Pacient with attribute dat_nav : String; diagnoza : String; dat_kontr : String; lekar : Lekar attribute,constraint omezlekare : $forall p/Pacient l/Lekar x,y/String (p rc x) and (l rc y)→ x<>y $ End Lékař ošetří pouze toho pacienta, který je pojištěn u pojišťovny, s níž má daný lékař uzavřenou smlouvu: Navsteva with constraint omezpoj:$forall n/Navsteva l/Lekar s/Smlouva p/Pojistovna (n lekar l) and (n poj p) and (l smlouva s) → (p=s)$ End Graf modelu Ordinace Lekarna Osoba

Pojistojna

VZP

Smlouva

HP

Lekar

000199

000299

Navsteva

$forall n/Navsteva l/Lekar s/Smlouva … Pacient

Kral

$forall p/Pacient l/Lekar x,y/String … Novak

obr. 4-2 Jak již bylo zmíněno, ConceptBase umožňuje tvorbu a administraci metamodelu včetně jeho grafické reprezentace ve formě sémantické sítě.

43

Pojmy k zapamatování: ConceptBase, Logický, rámcový a grafický formát, Telos, vzory tvrzení, třídy znalostní báze, Telosovské axiomy, CBL, dotazování, model a metamodel.

Úkoly k zamyšlení: V příkladu 4-7 udělejte následující úpravy: 1. Do třídy Návštěva vložte atribut pacient, který bude odkazovat na třídu Pacient. 2. Na úrovni Token vložte dalšího pacienta. 3. Vytvořte integritní omezení, které bude kontrolovat, že datum návštěvy pacienta je menší než datum kontroly, na kterou je pacient na návštěvě pozván.

Kontrolní otázky: 1. Vvyjmenujte čtyři vzory tvrzení, které používá ConceptBase. 2. Je-li tvrzení ve formě Proposition(oid, x, *instanceof, c), pak x je čím vzhledem k c ? Je-li tvrzení ve formě Proposition(oid, c, *isa, d), pak c je čím vzhledem k d? 3. Jaký má v ConceptBase kvantifikátorem?

tvar

formule

s univerzálním

4. Jakých hodnot nabývá proměnná this v query pravidle? 5. Vyjmenujte čtyři úrovně abstrakce při modelování dle ANSI standardu.

44

5 VYUŽITÍ DEDUKTIVNÍCH PRAVIDEL K ZACHOVÁNÍ INTEGRITY DAT Cíl: Po púrostudování této kapitoly budete rozumět a umět vysvětliti pojmy definované v klíčových slovech a dále budete umět: -

definovat nevýhody relačních databází v souvislosti s definováním a vyhodnocováním integritních omezení,

-

charakterizovat kompilační a vyhodnocvací fázi kontroly integrity dat,

-

charakterizovat syntaktická a sémantická integritní omezení.

Klíčová slova: Deduktivní integrita, kompilační fáze, vyhodnocovací fáze, syntaktická integritní omezení, sémantická integritní omezení.

5.1 Pojem deduktivní integrita Relační model je znám jak svým solidním teoretickým základem, tak omezenými vyjadřovacími prostředky. V relačním modelu je využívána, jako základ pro vývoj deklarativních dotazovacích jazyků, matematická logika. Deklarativní dotazovací jazyk, založený na relačním kalkulu, je však ve svých vyjadřovacích možnostech omezen. Jednou z možností zvětšení expresivity dotazovacího jazyka, jak již bylo uvedeno v kapitole 2, je využití deduktivních pravidel. Snaha o zvýšení expresivity vede k využití deduktivních pravidel i pro definování integritních omezení. Definování integritních omezení pomocí deduktivních pravidel je v databázové literatuře označováno jako deduktivní integrita. Relační datový model vykazuje některé nevýhody: • Slabá možnost datového modelování, která je dána rozporem mezi složitostí reálného světa a jednoduchostí relačních konstruktů. • Slabá podpora pro vývoj aplikačních procedur a jejich znovu využití, hlavně nemožnost využití agregace a dědičnosti. • Slabá podpora vyhodnocování schématu při údržbě dat daná především slabou možností znovu využití již vyhodnocených struktur. Nejen z uvedených nevýhod vyplývá snaha o přechod od relačně deduktivní technologie k technologii objektově deduktivní. Zavedení pojmu „třída“ do integritních omezení vede k efektivnějším metodám při údržbě databáze ve smyslu zachování integrity dat. Integrita dat u relačních datových modelů je založena na velkém množství kontrol, které se provádí při jakékoli aktualizační operaci. Tyto kontroly

45

jsou součástí procedur nazývaných triggery. Agregace u objektově orientovaných databází dovoluje přidružit triggery k objektům obdobně jako atributy, což zabezpečuje mnohem větší efektivnost v optimalizaci vyhodnocování integrity a přitom triggery jsou přímo součástí databáze. Mechanizmus metatříd navíc dovoluje efektivní kontrolu integrity při aktualizační transakci využitím explicitních vztahů mezi třídami a podtřídami a tudíž triggery definované v třídách se uplatňují rovněž na všechny podtřídy.

5.2 Princip deduktivní integrity v relačních datových modelech Metody zachování integrity jsou založeny na známých principech poprvé popsaných v [12]. Předpokládá se, že databáze vyhovuje integritním omezením před zahájením transakce a možné narušení integrity může být zapříčiněno pouze touto transakcí. Kontrolu integrity dat po vykonání transakce je možno rozdělit do dvou fází: • Kompilační fáze, kdy je kompilovaná nová integrita, formulovaná v deklarativní podobě (tj. v logice 1. řádu). Tato fáze zabezpečuje transformaci formule do interní normální formy, generování zjednodušených parametrizovaných integritních omezení zodpovědných zvlášť za vkládání a rušení dat, uložení těchto omezení „blízko“ korespondujících dat a automatické spuštění vyhodnocovací fáze. • Vyhodnocovací fáze zajišťuje verifikaci transakce použitím zkompilované formule. Pro každý element, kterým má být databáze aktualizována jsou vyhledána korespondující data v relacích (kolekcích) a relevantní integritní omezení. Nedojde-li k chybě, je zabezpečena správnost transakce.

5.2.1 Kompilační fáze Integritní omezení je formule logiky 1. řádu, která musí být platná v každém stavu databáze. V podstatě může být chápána jako kontinuálně vyžadovaný booleovský dotaz, přičemž true je informace explicitně obsažená v databázi nebo odvoditelná použitím pravidel. Pro definici integritních omezení využijeme pojmu disjunktivní normální forma. Formule je (podle [11]) v disjunktivní normální formě, je-li disjunkcí několika podformulí (disjunktů), o nichž platí: • Každý disjunkt je konjunkcí konečně mnoha literálů. • V žádném disjunktu se sobě odpovídající pozitivní a negativní literály nevyskytují současně.

46

Definice 5-1

definice integritního omezení podle [19]

Nechť Λ je množina pozitivních literálů deklarativního jazyka, L1, L2, …Lm ∈ Λ. Pak integritní omezení je dobře formovaná formule v disjunktivní normální formě zapsaná v jednom z následujících tvarů: ∃ x1, x2, …, xn(L1 ∧ L2, …∧ Lm ∧ R) nebo ∀ x1, x2, …, xn(¬L1 ∨ ¬L2, …∨ ¬Lm ∨ R) kde: každá proměnná x1, x2, …, xn se nachází v nejméně jednom z literálů L1, L2, …Lm, subformule R je buď formule bez kvantifikátorů nebo opět v jednom z uvedených tvarů, jestliže se některá z x1, x2, …, xn objeví v R, pak je volná, jiné, než kvantifikované proměnné nejsou povoleny.

Definice 5-2

definice aktualizační transakce podle [19]

Transakce je množina aktualizačních operací. Každá aktualizace je vyjádřena pozitivním nebo negativním literálem nad Λ. Pozitivní literál L představuje operaci vkládání informace L do databáze, negativní literál ¬L představuje výmaz informace L z databáze. Integritní omezení je relevantní k aktualizační operaci, jestliže doplněk aktualizační operace je sjednotitelný s literálem v integritním omezení.

5.3 Nevýhody deduktivní integrity v relačních datových modelech Relační model způsobuje neefektivní vyhodnocování deduktivních integritních omezení. Tato skutečnost je ilustrována na následujícím příkladu. Mějme relace: Lék(jméno: String, cena: Real) Pacient(jméno: String, adresa: String, sex: Char, věk: Integer, bere_lek: String) Trpí(pacient: String, příznak: String) Léčí(lék: String, příznak: String) Mějme integritní omezení: Forall p,d,a,s,x,o Pacient(p,a,x,o,d) and Léčí(d,s) → Trpí(p,s)

47

Jestliže se např. změní adresa Pacienta, musí být vyhodnocováno integritní omezení, ačkoliv tato změna neovlivňuje pravdivost formule, která integritní omezení definuje. Zefektivněním vyhodnocování deduktivní integrity se jeví přechod k deduktivně objektové databázi, která nabízení flexibilnější agregační abstrakci, uniformitu („všechno je objekt“) a jednoduchost. V některých případech dekompozice objektů vede až k úrovni atributů, která zefektivňuje vyhodnocování integritních omezení při aktualizačních operacích.

5.4 Integritní omezení v ConceptBase Příkladem jazyka, který je schopen popsat definice integritních omezení a deduktivních pravidel pomocí objektové orientace je jazyk Telos (systém ConceptBase), který mapuje všechny vztahy včetně definic objektů a všech jejich atributů do jednoduché datové struktury, tzv. tvrzení. Ze syntaktického hlediska jsou pravidla v Telos speciální formou integritních omezení. Rozdíl mezi deduktivními pravidly a integritními omezeními je ten, že deduktivní pravidla mohou vytvářet nová fakta z těch fakt, která jsou obsažena v extenzionální databázi. Integritní omezení společně s deklarací objektů jsou považována za základní axiomy (deduktivní axiomy produkované pravidly), které jsou po jejich implementaci v systému děděny a které omezují existující datové objekty. Integritní omezení v Telos jsou rozdělena na integritní omezení syntaktická a sémantická.

5.4.1 Syntaktická integritní omezení Syntaktická integritní omezení zahrnují: • Referenční integritu, která požaduje, aby atribut vždy odkazoval na existující databázový objekt. V ConceptBase je tato integrita automaticky hlídána v operaci „výmaz objektu“. • Entitní integritu, kdy každý objekt v bázi objektů musí mít své unikátní jméno různé od null. Každý objekt (frame) smí existovat v databázi pouze jednou a může obsahovat různé atributy.

5.4.2 Sémantická integritní omezení Sémantická integritní omezení zahrnují: • Doménovou integritu, která se zabezpečuje omezením typu hodnot, kterých může atribut nabývat. Každý atribut má v Telos definován příslušný datový typ, založený na základních doménách jako Numeric, Character, String, Boolean, Enumerated, Date/Time,

48

•

Money. Dále je možno využívat uživatelem definované datové typy postavené na vyjmenovaných základních doménách. Omezení vztahů je sémantickým integritním omezením, které se vztahuje k následujícím oblastem: ƒ Omezení kardinalit. Model připouští kardinality 1:1, 1:N, N:1, N:M. ConceptBase využívá vestavěnou integritu single a necessary. Atribut označený „single“ se může vyskytovat 0 nebo 1 krát, atribut označený „necessary“ se může vyskytovat více než jednou. Obě označení (tedy single i necessary) očekávají právě jeden výskyt. Min-maxové integritní omezení ConceptBase nepodporuje. ƒ

Omezení účasti ve vztahu specifikuje, zda objekt má povinnou účast ve vztahu nebo zda může objekt existovat nezávisle na jiném objektu (aniž by s ním vstupoval do vztahu). Tento typ integrity není přímo v ConceptBase podporován a musí být formulován explicitně.

ƒ

Všeobecná sémantická integritní omezení. Jedná se o explicitně formulovaná tvrzení, zabezpečující sémantické restrikce nad objekty, resp. třídami, které nejsou odvoditelné z předchozích tvrzení. Pro metamodelování v ConceptBase jsou nejdůležitější a zároveň nejnáročnější. Jsou to ta omezení, která jsou v ConceptBase definována v klauzuli constraints (vyskytuje se rovněž termín „generická IO“).

Z ohledem na datové modelování v ConceptBase můžeme výše popsaná integritní omezení rozdělit do dvou tříd. „Inherent constraints“, která jsou automaticky zabezpečována ConceptBase a „Explicit Constraints“, která musí být explicitně v návrhu databáze formulována.

Pojmy k zapamatování: Deduktivní integrita, kompilační fáze, vyhodnocovací fáze, syntaktická integritní omezení, sémantická integritní omezení.

Úkoly k zamyšlení: Pokuste se zformulovat situace, kdy může dojít k narušení integrity dat. Berte v úvahu, že v databázi máte uložena data o více objektech, které vstupují do vzájemných vztahů. Pokuste se najít kategorie problémových oblastí.

49

Kontrolní otázky: 1. Jaké jsou nevýhody relačního datového modelu v souvislosti s kontrolou integrity dat? 2. V čem může objektový přístup pomoci řešit tyto problémy? 3. Co to jsou triggry? 4. Charakterizujte doménovou, entitní a referenční integritu.

50

6 METODICKÁ DOPORUČENÍ K INTEGRACI DEDUKTIVNÍCH PRAVIDEL DO NÁVRHU INFORMAČNÍHO SYSTÉMU Cíl: Po prostudování této kapitoly bude čtenář umět navrhovat objektový model podle metodologie IDEA. Bude umět integrovat do modelu odvozené koncepty (atributy, pohledy, třídy). Dále bude umět navrhnout dynamický model aplikační domény a především bude umět navrhovat deduktivní pravidla a integrovat je do modelu. Bude schopen navrhovat deduktivní pravidla pro odvozování dat a pro definování integritních omezení a to včetně pravidel rekurzívních. Bude schopen provádět prototyping deduktivních pravidel.

Klíčová slova. Objektový model, dynamický model, analýza, návrh, odvozování dat, návrh integritních omezení, prototyping deduktivních pravidel.

Průvodce studiem: V současné době stále ještě existují dva hlavní přístupy k vývoji informačních systémů, přístup strukturovaný a objektově orientovaný. Hlavním účelem strukturovaného přístupu je strukturovat postup při tvorbě informačního systému, zatímco hlavním účelem objektově orientovaného přístupu je vytvářet opakovaně využitelné komponenty. Objektový přístup vychází z přirozeného způsobu lidského myšlení, strukturovaný přístup je konstrukcí lidského intelektu. Dle názoru mnoha odborníků v této problematice budou obě metodologie, jak strukturovaná tak objektová, ještě velmi dlouho a úspěšně žít a fungovat vedle sebe. Během posledních 10-15 let bylo vyvinuto několik metodologií vývoje informačních systémů založených na objektově-orientované technologii. Patří mezi ně např. Booch metodologie, Jacobson metodologie, Martin/Odell metodologie, Wirfs/Brock metodologie nebo metodologie Coada a Yourdona. Zároveň se v poslední době stávají předmětem zájmu ve vývoji informačních systémů nové koncepty, jakými jsou deduktivní a aktivní pravidla. Příkladem metodologie, která s těmito koncepty pracuje je metodologie IDEA. IDEA je plně objektově orientovaná, jejímž hlavním předmětem zájmu a perspektivou zkoumání jsou data. Je jedním z výstupů IDEA projektu (1992-1996), jehož cílem bylo využít v praxi objektověorientované technologie a technologie založené na deduktivních a aktivních pravidlech v nových generacích databázových systémů. Hlavní přínos IDEA metodologie spočívá v uvedení některých zatím více méně teoreticky vymezených konceptů jako objekty, deduktivní a aktivní pravidla

51

do praktického využití vývoje informačních systémů. IDEA metodologie má klasickou strukturu. Je rozdělena do čtyř části: analýza, návrh, prototyping a implementace. Každá z těchto fází využívá výše zmíněných konceptů na různé úrovni abstrakce. V této kapitole se budeme zabývat metodikou integrace deduktivních pravidel do analýzy a návrhu IS. Použití této metodiky pak ukážeme na demonstrační aplikaci v následující kapitole. Výklad je zaměřen na metodologii IDEA, přičemž je dodržováno základní strukturování na analýzu, návrh, prototyping a implementaci.

6.1 Úvod do metodiky Hlavním předmětem zájmu této kapitoly, jakož i ostatně celé výukové opory je deduktivní pravidlo, a to na různých úrovních abstrakce, resp. v různých fázích vývoje informačního systému. Proto je nutné přesněji vymezit jeho úlohu a určit postavení v kontextu dalších konceptů, především v kontextu pojmu objekt. IDEA metodologie pracuje se dvěma modely a to s objektovým a dynamickým modelem. V následujícím textu je tedy věnována pozornost těmto modelům se zřetelem na možnost integrace deduktivních pravidel na úrovni analýzy, návrhu a prototypingu informačního systému.

6.1.1 Objektový model Objektový model (podle IDEA [ http://www.txt.it/idea/]) je množina konceptů a označení, která je využívána k vyjádření klíčových abstrakcí aplikační domény a jednotlivých vztahů mezi nimi. Hlavní roli hraje pojem objekt a třída. Objekty mají vnitřní strukturu a chování a shlukují se do tříd objektů. Objektový model vychází z rozpoznání nejdůležitějších objektů aplikace, jejich struktury, chování a vzájemných vztahů.

6.1.1.1 Objekty Objekt reprezentuje individuální koncept aplikace. Každý objekt je spojen s objektovým identifikátorem, který je generován systémem. Každý objekt v databázi, i v reálném světě, má svou identitu. Objekt kromě identifikátoru je spojen s kolekcí hodnot, tyto hodnoty jsou nazývány „statický stav objektu“. Statický stav objektu je aktualizován operacemi pro manipulaci s daty. Objekt je rovněž asociován s operacemi, které mohou být nad objektem prováděny.

6.1.1.2 Třídy Objekty se shlukují do množin objektů se stejnou strukturou a taková množina se nazývá třída. Objekt je pak členem (instancí) třídy. Objektový

52

model (v grafické reprezentaci IDEA) je zobrazován obdélníky se jmény tříd a pojmenovanými atributy s asociovanými datovými typy. Datové typy jsou atomické (integer, real, string, boolean, ..) a uživatelem definované, které jsou označovány jako tzv. domény. Null je polymorfní hodnota jakéhokoli datového typu, která reprezentuje neznámou hodnotu. Operace jsou označovány pomocí jména a kolekce parametrů. Každé jméno operace musí být jednoznačné v rámci třídy a různé od jmen atributů. Parametry mohou být vstupní a výstupní. Operací mohou být buď funkce (s jedním výstupním parametrem) nebo procedury (s více výstupními parametry).

6.1.1.3 Vestavěná integritní omezení Integritní omezení v databázové technologii hrají nezastupitelnou úlohu. Jejich existence patří k základním paradigmatům databázové technologie, jako je nezávislost dat na programech (aplikacích). Pro definování vestavěných integritních omezení mají již relační databázové systémy silné nástroje. Jsou jimi např.: • Notnull atributy, což jsou takové atributy, jejichž hodnoty musí být známy, tzn. nesmí být null. • Primary key je kolekce atributů, které jako celek jednoznačně identifikují každou instanci relace. • Unikátní atribut je atribut nebo kolekce atributů, jehož hodnota je unikátní pro každou instanci relace.

6.1.1.4 Generalizace - specializace a dědičnost Objektový model podporuje generalizaci - specializaci mezi třídami. Každá generalizace je vytvořena mezi jednou supertřídou a jednou nebo více subtřídami. Každá subtřída zahrnuje podmnožinu objektů supertřídy, které sdílejí stejné vlastnosti. Specializace pak představuje reverzní proces a v tomto smyslu je možno generalizaci chápat jako proces zevšeobecňování, zatímco specializace je proces hledání zvláštního. Hlavní výhodou zavádění generalizace je dědičnost. Díky dědičnosti jsou vlastnosti supertříd automaticky použitelné pro subtřídy. Znaky dědičnosti mohou být lokálně předefinovány.

6.1.1.5 Vztahy Vztahy jsou asociace mezi objekty, obvykle představují asociaci dvou objektů (binární vztahy), ovšem mohou existovat i asociace více objektů (nární vztahy). Tak jako jsou objekty spojovány do tříd, vztahy jsou rovněž tvořeny na úrovni tříd. Vztahy, stejně jako objekty (třídy) mohou mít atributy. Vztahy mohou zahrnovat objekty téže třídy, v tomto případě je nazýváme „kruhy“. Např. Kurz je předpokladem pro jiný Kurz, resp. Kurz musí splňovat předpoklady jiného Kurzu.

53

6.1.1.6 Kardinality Kardinalita je integritní omezení, které určuje počet objektů, které mohou vstupovat do vztahu. Kardinalita může být vyjádřena: • min, max - Minimální, resp. maximální počet objektů vstupujících do vztahu. • * - Nula nebo více objektů vstupuje do vztahu (v relační databázové technologii jsme zvyklí tento typ kardinality označovat jako tzv. nepovinné členství ve vztahu.) • + - Jeden nebo více objektů vstupuje do vztahu (v relační databázové technologii jsme zvyklí tento typ kardinality označovat jako tzv. povinné členství ve vztahu).

6.1.1.7 Referenční integrita Referenční integrita je omezení binárního vztahu v tom smyslu, že jedna třída je označena jako tzv. „odkazující“ a druhá jako tzv. „odkazovaná“. Pro odkazovanou třídu to znamená, že nemůže v rámci této třídy existovat objekt, který by nevstupoval do vztahu s objektem třídy odkazující. Standardní způsoby zachování referenční integrity jsou „Restrict“ a „Cascade“ (u některých SŘBD rovněž "Set null").

6.1.1.8 Generické integritní omezení Konvenční databázové systémy podporují vestavěná integritní omezení, která jsou rovněž nazývána integritní omezení ve fixním formátu. Existují i další integritní omezení, v tzn. generickém formátu, která závisejí na specifikované aplikační doméně. Tato omezení mohou být podporována v jejich plné obecnosti pouze novými generacemi databázových systémů. Pro generická integritní omezení je využití deduktivních pravidel zvláště výhodné. Zavedení deduktivních pravidel pak bude představovat zcela nový pohled na to, jakým způsobem je možno definovat integritní omezení a jakým způsobem je možno udržovat konzistenci databáze. K vlastní integraci je rozumné provést rozčlenění IO do několika skupin: • Statická a dynamická omezení Statická omezení mohou být vyhodnocena v jednoduchém stavu databáze, tzv. v kontextu objektů a vztahů. Tato omezení lze dále rozdělit na omezení bezprostřední a omezení s odloženým vyhodnocením. Odložená vyhodnocení jsou prováděna před schválením transakce (commit), bezprostřední jsou prováděna v průběhu transakce. Dynamická omezení srovnávají dva stavy databáze, nazývané inicializační a koncový stav a jsou navrhována pro monitorování změn stavů. Např. stav objektů třídy Zkouška před započetím a na

54

•

konci zkouškového období. Rovněž dynamické omezení může být buď vyhodnocováno bezprostředně (v průběhu transakce) nebo po ukončení transakce. Rozsah omezení Omezení definovaná v kontextu specifikovaných tříd jsou nazývána cílená omezení. V případě realizace integritního omezení formou deduktivního pravidla se bude jednat o predikát, který bude dohlížet na stav individuálních cílových objektů a bude poskytovat pro každý cílový objekt specifickou pravdivostní hodnotu. Predikát může taky odkazovat na ostatní objekty, které jsou spojeny vztahem s cílovým objektem. Na příklad Student se nezapíše do následujícího ročníku, pokud nemá splněn stanovený počet kreditů nebo přerušil studium. Všechna ostatní omezení jsou nazývána necílená omezení. Na příklad Student musí udělat Zkoušky Kurzů, které navštěvuje.

Generická integritní omezení doporučuji odhalovat již ve fázi analýzy a ve fázi návrhu jejich neformalizovanou podobu, získanou ve fázi analýzy, transformovat do deduktivních pravidel (formální zápis generického integritního omezení).

6.1.1.9 Odvozené koncepty Odvozenými koncepty se rozumí takové koncepty, které se explicitně v databázi nevyskytují (nejsou součástí extenzionální databáze), ale které je možno na základě deduktivních pravidel odvodit. Odvozené koncepty jsou součástí intenzionální databáze. Objektový model může obsahovat třídy, atributy tříd a vztahy, jejichž instance nebo hodnoty jsou odvoditelné z ostatních instancí a jsou tedy dosažitelné z dat uložených v databázi. Odvozené instance lze reprezentovat jako dodatečné informace. Pravidla pro odvozování dodatečných informací jsou vytvářena ve fázi návrhu informačního systému. Odvozeným konceptem může být atribut, třída a pohled.

6.1.2 Dynamický model Dynamický model je (podle IDEA [ http://www.txt.it/idea/] ) založen na použití stavových diagramů, jako známého vizuálního formalizmu pro popsání vývoje dynamického systému. Stavový diagram vyjadřuje jak objekty reagují na události změnou svého stavu. Ve stavovém diagramu jsou postihnuty jak stavy související s jednou třídou objektů, identifikovanou v Objektovém modelu (targeted statecharts), tak stavy související s kolekcí tříd (untargeted statecharts).

55

6.1.2.1 Stavy tříd objektů Dynamický stav reprezentují výstupy všech významných událostí, které ovlivnily objekt v době jeho vzniku. Když je použit pojem „stav“ v dynamickém modelu, odkazuje se tím na abstraktní reprezentaci historie objektu nezávislé na jeho interní struktuře.

Příklad: Stav objektu Student může být splňuje požadavky ke zkoušce nebo nesplňuje požadavky ke zkoušce. Události, které mohou ovlivnit splnění požadavků studenta jsou: napsat test aspoň na minimální počet bodů nebo napsat test na méně než minimální počet bodů. Stavový diagram by pak mohl vypadat následovně: uspět u testu Student se splněnými požadavky

Student s neplněnými požadavky nespět u testu

Obr. 6-1

6.1.2.2 Přechody Jsou šipky spojující zdrojové a cílové stavy. Přechody jsou pojmenované trojice E [ C ] / A, kde E je událost, která spouští přechod, C je podmínka, za které k přechodu má dojít a A je akce, která má být provedena. Standardní sémantika přechodů je taková, že jestliže se objeví událost, objekt změní stav a akce, je-li uvedena, se vykoná. Jestliže je událost vynechána, přechod je proveden automaticky po zadání stavu. Je-li uvedena podmínka, musí být splněna, aby došlo ke změně stavu. Události, spouštějící změnu stavu, mohou být tří typů: manipulace s objekty, volání operací nebo symbolické události. Události manipulace s objektem zahrnují operace create, modify, specialize, generalize. Události volání operace jsou označovány specifikovaným jménem operace následovaným seznamem parametrů. Jedná se o volání externí procedury nebo funkce. Symbolické události jsou označovány prostřednictvím uživatelem definovaných jmen a popsány generickým výskytem, který může ovlivňovat historii objektu, ale není nezbytně spojen s operacemi, popsanými v objektovém modelu. Na příklad symbolickou událostí může být událost Uspět u testu, resp. Neuspět u testu.

56

Každá akce může být vykonání symbolické události, volání operace, vykonání manipulace nad daty nebo jakákoliv jiná akce závislá na aplikaci jako např. start externí aktivity. Stav objektu může být taky dán vstupními a ukončujícími akcemi. Vstupní akce jsou provedeny, jakmile objekt do tohoto stavu vstupuje, ukončující akce jsou provedeny, jakmile objekt stav opouští.

6.1. 2.3 Dekompozice stavů: OR- substavy Stavy mohou být dekomponovány cestou upřesňování shora-dolů. ORsuperstav je síť OR-substavů. Sémantika OR-dekompozice je taková, že platí: Je-li objekt v superstavu, pak musí být v jednom ze substavů. Proces upřesňování shora-dolů může být použit na substavy rekurzivně a povoluje víceúrovňovou reprezentaci dynamiky komplexního systému. Výhodou je, že přechody stavů mohou spojovat stavy z různých úrovní abstrakce. Každý přechod z/do superstavu může představovat vícenásobné přechody, všechny se stejným jménem, vycházející z (vstupující do) jednoho z jeho substavů. Každý přechod stavu na dané úrovni abstrakce musí odpovídat aspoň jednomu přechodu stavu na nižší úrovni abstrakce.

6.1.2.4 Stavy kolekce tříd objektů Jedná se o stavy reprezentující dynamiku několika integrovaných tříd. Ve stavovém diagramu se tyto stavy znázorní tak, aby bylo zřejmé, že se jedná o stav skupiny objektů. Každá ze tříd obsažených v kolekci může být popsána svým stavovým diagramem (targeted statechart).

6.1.2.5 Dekompozice stavů: AND- substavy AND-dekompozice je mechanizmus k rozdělení (zjemnění) stavu do několika AND-substavů. Na rozdíl od OR-dekompozice, výskyt stavu v AND-superstavu implikuje existenci tohoto stavu v každém substavu. AND-dekompozice umožňuje popsat dynamiku celého systému komplexně (ačkoliv tento se může skládat z několika nezávislých částí). Přičemž znalost stavu celého systému vyžaduje znalost stavu všech jeho komponent. AND-substavy, rovněž nazývané ortogonální stavy, popisují dynamiku rozsáhlých nezávislých komponent. Mezi jednotlivými ortogonálními komponentami mohou být následující vazby: • Změna stavu v jedné komponentě může být podmíněna stavem jiné komponenty. • Změna stavu jedné komponenty může spouštět události produkované jinou komponentou. • Události produkované akcemi, spojenými se změnou stavu jedné komponenty, jsou vysílány na všechny ostatní komponenty.

57

AND-dekompozice jsou používány k zachycení dynamiky kolekce objektů.

6.1.3 Pravidla a operace Konvenční databázové systémy s pojmy pravidla a operace nepracují a jejich částečnou funkci plní dotazy. V deduktivně objektových systémech jsou pojmy operace a pravidla základními koncepty využívanými k získávání informací z databáze. Z formálního hlediska se jedná o deklarativní výrazy, jejichž vyhodnocením (vhodnou interpretací) lze získat dodatečné informace z databáze. S pojmem deduktivní pravidlo pracují deduktivní databáze ať již v relační databázové technologii, tak v technologii objektové. Důležité je najít pro deduktivní pravidlo správné místo ve smyslu jeho integrace do analýzy a návrhu informačního systému.

6.1.3.1 Deduktivní pravidla Jak již bylo uvedeno v kapitole 2, deduktivní pravidlo je výraz ve tvaru: hlava ← tělo , kde hlava je atomická formule a tělo je libovolná formule. Každá proměnná v hlavě pravidla se musí vyskytovat rovněž v těle pravidla. K definování téhož konceptu je možno použít několika pravidel.

Příklad: Příklad definuje plat zaměstnance použítím deduktivních pravidel. X.plat=10000 ← inženýr(X), X.věk < 35 X.plat=15000 ← inženýr(X), X.věk > =35 X.plat=25000 ← manažér(X), skupina(Y), Y in X.vedoucí X.plat=35000 ← manažér(X), oddělení(Y), Y in X.ředitel

6.1.3.2 Stratifikace Deduktivní pravidla mohou na sobě navzájem záviset různým způsobem, buď hierarchicky nebo rekurzivně. Tato závislost může být vyjádřena tvrzením, že koncepty, odvoditelné na vyšší úrovni, mohou být vyhodnoceny pouze, pokud koncepty na nižší úrovni, na nichž jsou tyto koncepty vyšší úrovně závislé, již byly dříve vyhodnoceny. Každá úroveň je označována „strata“ a celkové vytváření úrovní se nazývá stratifikace množiny pravidel. Tento proces musí být pečlivě kontrolován, pokud se v pravidlech objeví negace. Negativní literály v deklarativních výrazech nemohou produkovat žádná nová tvrzení, ale mohou pouze potvrdit nebo vyvrátit tvrzení vytvořená v průběhu vyhodnocení jejich pozitivních výskytů se stejnými proměnnými.

58

Před vyhodnocením negace je třeba znát všechna pozitivní fakta, ze kterých může být vyjádřen závěr ve formě negace. Existují-li např. tvrzení, kdo je koho potomkem, pak pouze jejich plný výčet umožňuje potvrdit či vyvrátit tvrzení, kdo koho potomkem není. Stratifikace nemůže být dosaženo, pokud existuje odvozený koncept, který závisí jak rekurzivně, tak negativně na sobě samém. Množina pravidel obsahující takovýto rekurzivní cyklus, který zahrnuje negace, se nazývá nestratifikovatelná.

Příklad: Příkladem nestratifikovatelné množiny pravidel mohou být např. následující dvě pravidla: Student(X) ← not Zaměstnanec(X) Zaměstnanec(X) ← not Student(X) Obě pravidla je třeba umístit na stejnou úroveň, protože jsou rekurzivně závislá. Zároveň by však měla být umístěna do různých úrovní, protože jeden na druhém negativně závisí. Taková situace je označována jako logický paradox a musí jí být zabráněno (při návrhu se nesmí vyskytnout). Další paradoxní situace může nastat, pokud k odvození konceptu je třeba vypočítat agregační funkci, jejímž argumentem je odvozovaný koncept. Tuto situaci je možno uvést na příkladu: X in Y.stejnýPříjem ← Zaměstnanec(X), Zaměstnanec(Y), X.plat = avg(Y.stejnýPříjem.plat) Zaměstnanec X má stejný příjem jako Zaměstnanec Y, jestliže X má plat rovný aritmetickému průměru platů zaměstnanců se stejným příjmem jako Y. Takovéto rekurzivní cykly zahrnující agregační funkce musí být rovněž vyloučeny. Stratifikovaná množina pravidel je pak množina pravidel, která vylučuje negační a agregační paradox. Kromě stratifikace, musí být pravidla rovněž bezpečná. Bezpečnost pravidel již byla popsána v kapitole 2, proto na tomto místě jí nebude věnována pozornost.

6.1.3.3 Deduktivní pravidla pro odvozování dat Deduktivní pravidla mohou být mocným nástrojem pro odvozování dat na základě extenzionálních dat uložených v databázi a odvozená data tvoří tzv. intenzionální databázi. Z hlediska potřeb vývoje informačního systému je výhodné uvažovat o využití deduktivních pravidel k odvozování tříd, atributů a pohledů. Využitím deduktivních pravidel lze odvodit další třídy, jejichž populace závisí na hodnotě nějakého atributu definované supertřídy. Populace mohou být odvozeny pouze pro subtřídy pomocí pravidel, která jsou definována v supertřídách. Pohledy jsou chápány jako virtuální objekty,

59

které vzniknou vyhodnocením dotazu nebo deduktivního pravidla a tím usnadňují tvorbu aplikace. K pohledům lze nastavit individuální přístup pro aplikace, což umožňuje vytvářet mechanizmus ochran. Data jsou vybírána z více tříd a k těmto datům je nastaven selektivní přístup. Jednou z důležitých aplikací deduktivních pravidel je výpočet odvozených atributů, tj. takových atributů, jejichž hodnota může být odvozena z hodnot jiných atributů. Tvůrce informačního systému by měl zvažovat, které atributy musí být součástí extenzionální databáze a které je možno odvodit. Speciální pozornost je třeba věnovat rekurzívním atributům. Nejjednodušší a nejpoužívanější forma rekurze je tranzitivní uzávěr binárního vztahu. Vztah je modelován tak, že typ atributu objektu odkazuje zpět na tento objekt. Tento typ vztahu bývá nazýván kruhovým vztahem, jak již bylo zmíněno v kap. 6.1.1.5.

6.1.3.4 Deduktivní pravidla pro definování integritních omezení Integritní omezení lze vyjádřit pomocí deduktivních pravidel, přičemž databázi vyhovuje dané integritní omezení, je-li hodnota pravidla „false“. Databáze není konzistentní, je-li hodnota deduktivního pravidla „true“. Integritní omezení, jak již bylo uvedeno u objektového modelu, je možno rozdělit na omezení bezprostřední a omezení s odloženým vyhodnocením. Kontrola omezení s odloženým vyhodnocením je prováděna po schválení transakce (commit), tzn. nejdříve je provedena celá transakce (např. aktualizace dat) a pak je kontrolována integrita dat. U bezprostřední kontroly je kontrola provedena po každé specifické operaci (nazývané řádek transakce). V obou případech je sémantika kontroly omezení následující. Jestliže po výpočtu příslušného deduktivního pravidla dojde k produkci hodnot do hlavy pravidla, tyto hodnoty jsou chápány jako nepovolená data a transakce je zrušena. Operace prováděné transakcí jsou zrušeny a databáze je uvedena do stavu před započetím transakce.

6.1.3.5 Operace Operace (v objektové terminologii nazývané metody) představují uživatelem definovaný mechanismus pro vyhledávání objektů a manipulaci s jejich obsahem. Operace mají dvě komponenty: podmínku operace a tělo operace. Podmínka je pravidlo, které garantuje deklarativní kontrolu během vykonávání operace. Vyhovují-li interpretace proměnných ve formuli specifikované podmínce, podmínka pro vykonání operace je splněna a operace může být vykonána. Tělo operace je procedura, která obsahuje zobrazovací, event. aktualizační databázové příkazy.

60

6.2 Analýza Během analýzy se dle metodologie IDEA vytvářejí dva modely. Objektový model a Dynamický model. Objektový model je rozšířeným E-R modelem, který představuje statický popis objektů v klasickém databázovém smyslu. Entity odpovídají třídám a vztahy odkazům mezi objekty. Třídy jsou popsány společně s jejich atributy a metodami. Model zahrnuje rovněž hierarchii tříd a integritní omezení. Dynamický model je založen na známém vizuálním formalizmu stavových diagramů. Je jich použito k vyjádření dynamiky objektů, ve smyslu událostí a podmínek, které způsobí změny a konsekvence změn stavů. Analýza je tedy proces sběru a specifikování požadavků ve formě Objektového a Dynamického modelu. Tato fáze je zaměřena na modelování reality s cílem vytvořit model spojený s příslušnou grafickou reprezentací, který bude obsahovat jednoduše popsané statické a dynamické rysy budoucí aplikace. Již ve fázi analýzy je třeba postupovat tak, aby navržená databáze splňovala požadavky pro znalostní nezávislost. O znalostní nezávislost se jedná tehdy, když znalost je součástí databáze, nikoli databázové aplikace. Analýza je proces transformace neformálních popisů na popisy semiformální. Analýza se zaměřuje na strukturu a vlastnosti klíčových domén abstrakce. Proces analýzy problému je možno rozdělit (podle IDEA) do těchto základních fází: hrubá analýzy, detailní analýzy a integrace s verifikací.

6.2.1 Hrubá analýza Je úvodní pohled na uživatelské požadavky s cílem stanovit hranice problému. V této fázi musí být zodpovězeny otázky: • Co jsou důležité abstrakce, které tvoří slovník problémové domény. • Co jsou hlavní funkce, které musí být zabezpečeny, aby byly splněny požadavky uživatele. Odpovědí na tyto dvě základní otázky tvoří dva hlavní výstupy hrubé analýzy a to je popis zdrojů a aplikací. Identifikace zdrojů je aktivita, u které je definován seznam konceptů aplikační domény tak, aby byla získána množina tříd zahrnutých do budoucího systému. Těmito třídami zdrojů mohou být hmotné předměty, koncepty, zaznamenané události, osoby, role, místa, atd. Identifikace aplikací směřuje k pochopení podstaty aplikací, které jsou uživatelem požadovány v dané aplikační doméně. Základní otázkou identifikace aplikací je, které funkce musí být vyvinuty ve vztahu ke sdíleným perzistentním konceptům aplikační domény. Výsledkem této fáze je seznam aplikací, popisující hlavní funkce vyvíjeného softwarového systému.

61

Před vyvíjením detailní analýzy je nutné stanovit rozlišovací úroveň řešení. Otázkou je, které zdroje, identifikované jako důležité elementy problémové domény, jsou důležité abstrakty, které mají být zahrnuty do řešení problému. Výsledkem této fáze bude kvalifikovaný seznam zdrojů.

6.2.2 Detailní analýza Je proces definování informačního obsahu, statických a dynamických vlastností, vzájemných vztahů zdrojů a aplikací definovaných v hrubé analýze. Výstupem této fáze je Objektový, Aplikační a Dynamický model a opravený seznam zdrojů a aplikací vytvořený ve fázi hrubé analýzy. Následující schéma zachycuje vstupy a výstupy detailní analýzy, jak s nimi pracuje IDEA metodologie.

Seznam zdrojů

Požadavky

Detailní analýza

Seznam aplikací

Objektový model

Dynamický model

Aplikační model Opravený seznam zdrojů a aplikací Obr. 6-2

Detailní analýza, v případě využití deduktivních přístupů, bude rozlišovat dvě hlavní oblasti. Oblast struktury, kterou lze označit jako analýzu schématu a oblast znalostí, označovanou analýza znalosti. Analýza schématu zahrnuje třídy z hrubé analýzy včetně jejich atributů, vztahy mezi třídami, dědičnosti a operace jednotlivých tříd. Analýza znalostí se zaměřuje na odhalení sémantických vlastností elementů, které nejsou přímo uvedeny v Objektovém modelu. Analýza znalostí pak bude zahrnovat jak statické sémantické vlastnosti (všeobecná integritní omezení popsaná podmínkami validace dat), tak vlastnosti dynamické (odkazující na chování tříd v souvislosti s událostmi popsanými v Dynamickém modelu).

62

6.2.3 Analýza schématu Analýza schématu definuje strukturu perzistentních, sdílených informací aplikační domény. Pro každou třídu hrubé analýzy definuje atributy, operace a vztahy tak, aby byla zabezpečena očekávaná sémantika tříd. Výstupem této aktivity je kompletní Objektový model, zobrazující atributy tříd, jejich vztahy a dědičnost.

6.2.3.1 Identifikace atributů a vztahů V této fázi je třeba zodpovědět následující otázky: • Co jsou elementy charakterizující vnitřní strukturu objektů daných tříd? • Jaké jsou sémantické závislosti tříd? Při definování atributů je třeba zadat typ těchto atributů. Typem může být vestavěný typ nebo typ konstruktor. Analytik může rovněž definovat uživatelem definovaný typ s příslušnou sémantikou. Atributy a vztahy mohou být odvozeny, tj. mohou obsahovat odvozenou informaci z jiných položek Objektového modelu. Relevantní odvozovací pravidlo bude formalizováno ve fázi návrhu.

6.2.3.2 Identifikace hierarchií Dalším typem sémantických závislostí mezi třídami je existence vztahů dědičnosti. Pro definování dědičnosti je třeba zodpovědět následující otázky: • Je koncept vyjádřený danou třídou specializací konceptu vyjádřeného jinou třídou? • Jsou objekty jedné třídy podmnožinami objektů jiné třídy? Jsou-li obě odpovědi ano, pak mezi třídami existuje dědičnost.

6.2.3.3 Identifikace operací Každá třída je zavedena do schématu, aby plnila určitý úkol, resp. zodpovídala za provedení specifikovaných úkolů. Definice operací je aktivita, která identifikuje prováděné služby každým zdrojem pro zajištění těchto zodpovědností. Při identifikaci operací se objevují následující otázky: • Které operace zabezpečují interface definovaných tříd? • Jsou identifikované operace nutné a postačující k plnění zodpovědnosti tříd? Operace mohou být klasifikovány jako operace všeobecného použití, dynamické operace a operace aplikačních závislostí.

63

Operace všeobecného použití jsou služby, které spravují objekt od jeho vzniku až k zániku a obsahují: • Konstruktor, který vytvoří objekt podle pravidel nebo parametrů. • Destruktor, který zruší objekt a možnost asociovat informace, které závisí na jeho existenci. • Akcesor, který zpřístupní informace o objektu nebo množině objektů. • Transformer, který mění objekt. Všechny operace nemusí být vždy explicitně definovány. Konstruktor a destruktor může být implicitní. Akcesor může být rovněž implicitní podle toho, zda je k dispozici potřebný dotazovací jazyk. Dynamické operace jsou operace, které mění stav objektu v závislosti na události, která nastala a podmínkách, které byly splněny. Reakce na událost může být specifikována jako operace, jejíž vyvolání koresponduje s tím, že byla objektu ohlášena relevantní událost. Operace aplikačních závislostí ovlivňují jak Dynamický, tak Objektový model. Mohou být požadovány z více aplikací a jsou nezbytné proto, aby zabezpečovaly očekávané funkcionality tříd.

6.2.4 Analýza znalostí Analýza znalostí je nalézání a specifikování relevantních vlastností, které byly identifikovány během hrubé analýzy a vymezeny v analýze schématu. Otázky pro analýzu znalostí jsou: • Jaké podmínky musí třídy a vztahy splňovat, aby mohly být spolehlivou reprezentací reality? • Jaké podmínky musí splňovat operace tříd? • Jaké je chování identifikovaných tříd jako odezva na významné událost? Výstupem znalostní analýzy je množina integritních omezení kladených na Objektový model a popis stavů těch tříd, které projevují dynamické chování. Integritní omezení řeší omezení tříd (primární klíč, unikátní hodnoty atributů, notnull, atd.), kardinality (1:N, nepovinné:povinné, atd.) a referenční integritu Zvláštní pozornost si zasluhují generická integritní omezení, jak byla definována v kapitole 6.1.1.8. V rámci analýzy jsou generická integritní omezení definována v přirozeném jazyce, tedy neformalizovaně, je však již v této fázi rozhodnuto, o jaká generická integritní omezení půjde. V podstatě IDEA metodologie rozlišuje čtyři typy generických integritních omezení: statické bezprostřední, statické odložené, dynamické bezprostřední, dynamické odložené. Každé z nich může být zaměřeno na objekty jedné třídy (cílené) nebo na objekty více tříd (necílené).

64

6.2.4.1 Cílené/necílené integritní omezení Jestliže se integritní omezení vztahuje pouze na objekty jedné třídy, jedná se o cílené IO. O cílené IO se jedná rovněž tehdy, je-li aktualizační operace zaměřena na aktualizaci objektů jedné třídy, ale podmínky aktualizace jsou kladeny na více tříd. Cíleným objektem se zde rozumí objekt aktualizace a nikoli objekty tříd, které se vyskytují v podmínce, za které může k aktualizaci dojít. Jestliže integritní omezení zahrnuje objekty více tříd a není zřejmý jakýsi „centrální“ objekt, tj. objekt jedné třídy, jehož hodnoty budou aktualizovány, pak se jedná o necílené IO.

6.2.4.2 Statické/dynamické integritní omezení Pokud se integritní omezení vztahuje k jednomu stavu databáze (např. student získá určitý počet kreditů, pokud splní požadavky ke zkoušce a vykoná zkoušku), je takové IO definováno jako statické. Na druhé straně dynamické IO posuzuje dva stavy databáze, tzn. např. srovnává stav objektu student v předchozím a současném stavu databáze tedy před a po zápisu.

6.2.4.3 Bezprostřední/odložené integritní omezení Jestliže v rámci jedné transakce se vyskytuje operace, která může integritní omezení porušit a následuje operace, která databázi opět uvede do souladu s tímto integritním omezením, je zřejmé, že kontrola integritního omezení je prováděna až po ukončení této transakce. IO pak má statut s odloženou realizací. Na druhé straně, pokud v rámci transakce je IO narušeno a již nemá šanci být napraveno, je rozumné toto IO definovat jako bezprostřední a tudíž rovněž vykonat kontrolu IO ihned po ukončení operace.

6.2.4.4 Analýza funkčních závislostí Prvním krokem analýzy schématu je identifikace tříd a jejich atributů. Identifikace tříd je velmi náročný proces, který předpokládá dobrou znalost aplikační domény stejně jako zkušenost analytika. U jednotlivých tříd je třeba zvažovat oprávněnost jejich existence, respektive možnost či nutnost rozdělení třídy do více tříd. Zjištění, zda je třída adeptem na rozdělení není možné ponechat pouze na intuici a je vedeno především záměrem odstranit redundance v budoucí databázi. V relační databázové technologii existuje nástroj k odstranění redundancí založený na vyhledávání funkčních závislostí atributů a následné dekompozici relačních schémat.

6.2.5 Definice dynamiky Definice dynamiky (Dynamický model), jak ji vnímá IDEA je zaměřena na následující otázky:

65

• •

Existuje nějaký objekt, který je ovlivňován minulostí? Které události jsou relevantní k minulosti objektu? Existuje nějaký objekt, jehož minulost ovlivňuje chování jiných objektů?

Tato fáze analýzy představuje pohled na identifikované zdroje ve snaze nalézt relevantní události, stavy a změny stavů. Události mohou přicházet z různých zdrojů: z externího prostředí, z volání operace, z aktualizace objektu nebo mohou existovat události definované v aplikaci. Precizní zmapování událostí se provádí ve fázi návrhu.

6.2.6 Aplikační analýza Tato fáze je zaměřena na detailnější specifikace aplikačního seznamu, vytvořeného v hrubé analýze. V rámci aplikační analýzy jsou kladeny následující otázky: • Které výpočty aplikace provádí? • Které objekty aplikace čte resp. zapisuje? • Vyžaduje aplikace splnění nějakých podmínek (preconditions, postconditions)? • Produkuje aplikace události? Odpovědi na tyto otázky jsou shrnuty do popisu aplikace. Popis aplikace může být tvořen z následujících informací. Aplikace: Jméno Popis: Text Vstupy: Zdroje (entity, vztahy) Změny: Zdroje (entity, vztahy) Zprávy: Události Předpoklady : Podmínky Výsledky: Popis

6.2.7 Integrace a verifikace Tato fáze analýzy má dva základní významy. Integrovat různé pohledy na aplikační doménu v průběhu analýzy schématu a znalostní analýzy a ověřit, zda výsledný produkt analýzy odpovídá požadavkům uživatele.

6.2.7.1 Integrace Objektového a Dynamického modelu •

66

Všechny třídy, které se vyskytují ve zdrojovém nebo nezdrojovém stavovém diagramu musí být definovány jako zdroje v Objektovém modelu.

• • • •

Všechny události ve zdrojovém stavovém diagramu, korespondující s voláním operace, musí odpovídat lokálním nebo zděděným operacím v popisu třídy, na kterou se popis odvolává. Všechny akce ve zdrojovém nebo nezdrojovém stavovém diagramu musí odpovídat volaných operacím popsaným v příslušných třídách nebo nadtřídách. Všechny proměnné, vyskytující se v podmínkách, musí být definovány jako odpovídající třídy. V nezdrojových stavových diagramech odkazy z jednoho objektu na druhý musí být podporovány příslušným vztahem v Objektovém modelu mezi třídami.

6.2.7.2 Integrace Aplikačního, Objektového a Dynamického modelu • •

Všechny třídy a atributy tříd čtené a zapisované aplikací nebo zmiňované v pre a post podmínkách musí být definovány v Objektovém modelu. Všechny události, která aplikace provádí, se musí objevit aspoň v jednom stavovém diagramu.

6.3 Návrh Návrh je proces převodu Objektového a Dynamického modelu do konceptuálního schématu, který zabezpečuje jednoznačnou specifikaci aplikační domény. Návrh je převedení semi-formálního tvaru analýzy do plně formálního tvaru. V rámci návrhu se provádí návrh schématu databáze, který představuje strukturální znalost. Po návrhu schématu databáze se provede návrh deduktivních pravidel, která byla neformálně popsána v analýze schématu, analýze znalostí a analýze funkčních závislostí.

67

6.3.1 Návrh schématu

Návrh schématu (struktura a chování)

Analýza

Návrh pasivních pravidel (deklarativní znalost)

Prototyping

Návrh aktivních pravidel

Obr. 6-3 Návrh schématu je sekvence transformací charakteristik z Objektového modelu, které jsou vyjádřeny pomocí vhodného formálního jazyka. Hlavním úkolem je transformace grafických popisů na textové. Vztahy z Objektového modelu se transformují do atributů objektových hodnot, které slouží jako odkazy mezi objekty. Separátně se berou v úvahu typy, třídy, generalizace a vztahy. Vztahy se modelují pomocí atributů, nakonec se navrhnou operace, které reprezentují chování jednotlivých komponent Objektového modelu. Návrh schématu představuje návrh typů, tříd, generalizací, vztahů a operací.

6.3.2 Návrh datových typů Je první aktivitou návrhu schématu, při které je třeba se zaměřit na využití vestavěných datových typů a na návrh uživatelem definovaných datových typů. Z důvodu komplexních atributů objektu se zavádí uživatelem definované datové typy. Uživatelem definované typy jsou zvláště výhodné tehdy, jsou-li využity u definování atributů více tříd nebo jako parametry více operací. Při návrhu atributů je třeba dbát na to, aby hodnoty atributů nevykazovaly individuální identitu a dynamiku. Nastane-li taková situace, pak je vhodné takový atribut navrhnout jako objekt. Podstatnou otázkou

68

v této fázi je: „Reprezentuje hodnota třídu nebo datový typ?“. Základním vodítkem může být tvrzení, že typy popisují hodnoty, zatímco třídy popisují objekty.

6.3.3 Návrh tříd Návrh tříd se hlouběji zabývá každou třídou Objektového modelu. Pro každý atribut a parametr operace se nastaví inicializační typy. Pro atributy a parametry operací se přesně určí datový typ. Pro jednotlivé třídy se zkoumá, zda objekty této třídy mohou existovat samostatně nebo pouze ve vztahu s objekty jiné třídy. Dalším krokem návrhu je zvážení, zda některé třídy není vhodné rozdělit. Kandidátem pro rozdělení jsou třídy s příliš velkým počtem atributů a operací.

6.3.4 Návrh generalizací Při návrhu generalizací musí být dodrženo minimálně jedno ze dvou kritérií, které musí splňovat navržená subtřída: • Musí existovat takový stav navržené subtřídy, který smysluplně rozšiřuje stav přímé nadřazené supertřídy a tím uchovává další informace. • Musí mít nějakou operaci nebo omezení, kterým disponují její objekty a přitom nejsou tyto operace resp. omezení podporovány přímou supertřídou. V souvislosti s generalizací je rozumné diskutovat, zda každá třída smí či nesmí míti více supertříd, resp. zda každý objekt supertřídy náleží nějaké subtřídě. V konceptuálním E-R modelu platí pravidlo, že schéma je korektní, má-li pouze jeden zdroj IsA hierarchie (analogie dědičnosti subtřídy ze supertřídy). Co se týká vztahu objektu supertřídy s objekt subtříd je možno uvažovat oba případy. Je-li vztah mezi super a subtřídou takový, že každému objektu supertřídy náleží aspoň jedna subtřída, jedná se o totální generalizaci, v opačném případě se jedná a parciální generalizaci. Jeli vztah mezi super a subtřídou takový, že každému objektu supertřídy náleží nejvýše jedna supertřída, jde o exkluzivní generalizaci. Z hlediska návrhu generalizací jsou preferovány exkluzivní totální generalizace. Pro zabezpečení konzistence generalizace by měla být dodržena následující pravidla: • Hierarchie generalizace je acyklická. • Pokud třída dědí z více tříd, musí mít tyto třídy společného předka. • Je-li v subtřídě předefinován nějaký atribut, musí být typ tohoto atributu subtypem atributu v supertřídě. • Je-li v subtřídě předefinován vstupní parametr operace, musí být typ předefinovaného parametru subtypem parametru definovaného v supertřídě.

69

•

Je-li v subtřídě předefinován výstupní parametr operace, musí být typ předefinovaného parametru subtypem parametru definovaného v supertřídě.

6.3.5 Návrh vztahů Návrh vztahů, které byly vytvořeny mezi třídami Objektového modelu ve fázi analýzy, představuje obdobu klasické transformace známé např. z E-R diagramu na relační datové schéma. Zde mohou být vztahy mapovány buď formou přidaných atributů do relací nebo nových relací. V objektových modelech jsou vztahy reprezentovány objektovými atributy, kdy hodnota atributu jedné třídy objektu ukazuje na objekt jiné třídy. Např. vztah mezi třídou Student a třídou Skupina je modelován atributem třídy Student se jménem je_zařazen, přičemž tento atribut nabývá hodnot třídy Skupina. Vztahy, stejně jako třídy a atributy mohou být buď extenzionální nebo je možno tyto vztahy odvodit, což je situace pro efektivní využití deduktivního pravidla. Transformací vztahů navržených v Objektovém modelu dojde k odstranění vztahu z Objektového modelu a přidání atributu do příslušné třídy.

Příklad: se_skládá_z Student

Skupina je_zařazen Obr. 6-4

Vztah je_zařazen je transformován tak, že do třídy Student se zařadí atribut je_zařazen. Typ tohoto atributu je buď Skupina, jedná-li se o kardinalitu 1:1 nebo set-of(Skupina), jedná-li se o kardinalitu 1:N. V některých případech je třeba modelovat vztahy v obou směrech. Student je zařazen do Skupiny a Skupina se skládá ze Studentů. Nechť vztah Skupina se_skládá_z Student má kardinalitu 1:N a vztah Student je_zařazen Skupina je v kardinalitě 1:1. Pak typ atributu se_skládá_z je set-of(Student) a typ atributu je_zařazen je Skupina.

6.3.6 Návrh deduktivních pravidel Co se týká návrhu deduktivních pravidel, budeme se zabývat deduktivními pravidly pro odvozování dat a deduktivní pravidly pro definici integritních omezení. Pravidla pro odvozování dat pak budeme členit na pravidla, která

70

odvozují atributy, pohledy a třídy. Integritní omezení jsou chápána jako implicitní (fixní formát) nebo jako uživatelem definovaná (generic formát). Návrh deduktivních pravidel je iniciován a vychází z neformálních popisů získaných v průběhu analýzy. Během návrhu může být objeveno mnoho dalších požadavků. Návrhář může definovat všechna odvozená data, která obohatí znalosti podporované systémem a odhalí všechny zdroje kontrol konzistence, které mohou být formulovány jako integritní omezení. Na druhé straně přínosem je, pokud návrhář odhalí i možné závislosti mezi již navrženými konstrukty a vhodným nadefinováním deduktivních pravidel je redukuje resp. úplně odstraní. Zmenšení objemu dat pak přináší snazší kontrolu integrity databáze spojenou s aktualizačními operacemi. Velkou výhodou deduktivních pravidel je jejich deklarativnost. Umožňují popis znalostí, které nevyžadují žádné procedurální detaily a tudíž popis pravidel je naprosto nezávislý od jejich implementace. Na druhé straně z toho vyplývají i omezení v nemožnosti vyjádřit procedurální rysy, které jsou někdy zapotřebí. Jsou-li deduktivní pravidla pro odvozování dat transformována do aktivních pravidel, dochází k tzv. materializaci dat. V takovém případě jsou odvozená data extenzionálně uložena v databázi. Jazyky pro definování pravidel (Prolog nebo Datalog) jsou používány v kontextu relačních databází. V případě použití objektově orientovaných databází, objektová reprezentace vede k různým stylům pravidel. Proměnné odkazují na objekty spíše než na hodnoty a přístup k jednotlivých hodnotám atributů se realizuje prostřednictvím tečkové notace.

Příklad 6-1: Definujme entity Osoba, Rodič a Partner v relačním a objektové pojetí: Relační pojetí Osoba(jméno, adresa, pohlaví) Rodič(rodič, dítě) Partner(manžel, manželka) Objektové pojetí Object Osoba s atributy jméno: string adresa: string sex: string dítě: set-of Osoba partner: Osoba Deduktivními pravidly lze odvozovat pohledy. Pohledy jsou podobné relacím, ale jejich n-tice nejsou uloženy v databázi. Mohou se vypočítat pomocí dotazovacího jazyka nebo deduktivních pravidel. V objektovém pohledu deduktivní pravidla mohou odvozovat pohledy nebo atributy.

71

Pohledy pro relační přístup Matka(matka, dítě) Sestra(jméno, jméno) Předek(jméno, jméno) Odvozené atributy pro objektový přístup Rodič: set-of(Osoba) Matka: Osoba Sestra: set-of(Osoba) Předek: set-of(Osoba) Všechny tyto předpoklady můžeme vyjádřit pomocí pravidel.

V relačním pojetí: Matka(X,Y) ← Rodič(X,Y), Osoba(X,-,žena) matka je rodič, žena Sestra(X,Y) ← Rodič(Z,X), Rodič(Z,Y),Osoba(X,-,žena) sestra je žena, která má stejné rodiče jako osoba Y Předek(X,Y) ← Rodič(X,Y) předek je rodič Předek(X,Y) ← Rodič(X,Y), Předek(X,Y) předek je rodič předka V objektovém pojetí: X in Y.rodič ← Osoba(X), Osoba(Y), Y in X.dítě X je rodičem Y, jestliže X aY jsou osoby a zároveň Y je dítětem X X in Y.matka ← Osoba(x), Osoba(Y), X in Y.rodič, X.sex=“žena“ X je matkou Y, jestliže X a Y jsou osoby, X je rodičem Y a zároveň X je žena X in Y.sestra ← Osoba(X), Osoba(Y), Osoba(Z), Z in Y.rodič, Z in X.rodič, X.sex=“žena“ X je sestrou Z, jestliže existuje osoba Z, která je rodičem X i Y a zároveň X je žena X in Y.předek ← Osoba(X), Osoba(Y), X in Y.rodič

72

X in Y.předek ← Osoba(X), Osoba(Y), X in Y.rodič.předek Tímto způsobem je vyjádřena rekurze. X je předkem Y, je-li jeho rodičem. X je předkem Y, je-li rodičem předka. Příklad 6-1 ukazuje, jak může být deduktivních pravidel použito k vyjádření inverzních vztahů (rodič, dítě). Nejfrekventovanější použití rekurzívních pravidel je pro vyjádření tranzitivního uzávěru binárních vztahů. V uvedeném případě pohled Předek je definován jako tranzitivní uzávěr relace Rodič. Tranzitivní uzávěr vyžaduje dvě pravidla, startovací pravidlo (nerekurzivní), které zabezpečuje bázi rekurze a rekurzivní pravidlo, které zabezpečuje indukci. Objektový přístup se vyhne zavádění existenčně kvantifikované proměnné Z (v relačním pojetí) vyjádřením cesty, která kombinuje atributy rodič a předek (Y.rodič.předek).

6.3.7 Všeobecné principy dobře formovaných deduktivních pravidel Pravidla, aby mohla být vyhodnocena, musí splňovat několik syntaktických a sémantických požadavků (vyplývají z teoretických předpokladů, které byly popsány v kapitole 2). Tyto požadavky lze shrnout do následujících bodů: • Pravidla musí být v omezeném rozsahu, tzn. všechny jejich proměnné musí být omezeny vhodnými formulemi. • Pravidla musí být bezpečná, tzn. všechny proměnné v hlavě pravidla se musí objevit minimálně v jedné pozitivní formuli v těle pravidla. • Pravidla s negativními formulemi musí být stratifikována, tzn. nesmí být rekurzivně použita v těle jiných pravidel tak, aby vytvářela cyklus rekurzivních pravidel, která vyvolávají negativní formuli. • Pravidla s termy musí být stratifikována, tzn. že nesmí být rekurzivně použita v těle ostatních pravidel tak, aby tvořila cyklus rekurzivních pravidel, které volají množinu termů.

6.3.8 Pravidla pro odvozování dat Následující kapitoly jsou věnovány integraci deduktivních pravidel do návrhu informačního systému dle členění, uvedeného v kapitole 6.3.6.

6.3.8.1 Návrh odvozování atributů Jednou z důležitých aplikací deduktivních pravidel je výpočet odvozených atributů, tj. takových atributů, jejichž hodnota může být odvozena z hodnot jiných atributů. Návrhář by měl odpovědět na následující otázku: Existují nějaké atributy, jejichž hodnoty mohou být odvozeny?

73

Příklad: Příklad odvozeného atributu by mohl být následující: Mějme atribut datum narození u třídy Osoba. Z atributu datum narození odvoďte atribut věk. Define object class Osoba with Attribute datum_narození: date, věk: integer derived End Define external formula castToVěk(in D:date, out A:integer) End Define implementation for Osoba with Attribute Self.věk = I ← integer(I), castToVěk(Self.datum_narození, I) End Proměnná Self postupně nabývá všech instancí třídy Osoba.

6.3.8.2 Návrh odvozování rekurzivních atributů Speciální pozornost je třeba věnovat rekurzívním atributům. Nejjednodušší a nejpoužívanější forma rekurze je tranzitivní uzávěr binárního vztahu [17]. Vztah je modelován tak, že typ atributu objektu odkazuje zpět na tento objekt. Tento typ vztahu bývá nazýván kruhovým vztahem.

Příklad: Mějme následující fragment schématu databáze : Define object class Osoba with Attribute děti: set-of(Osoba), rodiče: set-of(Osoba), derived, sourozenci: set-of(Osoba), derived, předci: set-of(Osoba), derived End Využitím deduktivních pravidel můžeme navrhnout odvozené atributy rodiče a sourozenci a odvozený rekurzivní atribut předci např. následujícím způsobem: Define implementation for Osoba with Attribute X in Self.rodiče ← Osoba(X), Self in X.děti; X in Self.sourozenci ← Osoba(X), X.rodiče in Self.rodiče, X != Self;

74

X in Self.předci ← Osoba(X), X in Self.rodiče; X in Self.předci ← Osoba(X), X in Self.rodiče.předci End kde: „!“ je operátor řezu, který zabraňuje vyhodnocování zbytku výpočtového stromu. Použije se tehdy, když víme, že zbytek výpočtového stromu již nic nepřinese do celkového výpočtu. Dá se tím výpočet urychlit. V uvedeném příkladu stačí pro definici sourozence, že tito mají aspoň jednoho společného rodiče (tedy za sourozence považujeme i sourozence nevlastní).

6.3.8.3 Návrh odvozování pohledů Pohledy jsou chápány v databázové terminologii jako virtuální objekty (relace), které vzniknou vyhodnocením dotazu a usnadňují tvorbu aplikace. K pohledům lze nastavit individuální přístup pro aplikace, což umožňuje vytvářet mechanizmus ochran. Data jsou vybírána z více tříd a k těmto datům je nastaven selektivní přístup.

Příklad: Define view Manželství (Manžel:Osoba, Manželka:Osoba) Manželství([Manžel:X, Manželka:Y]) ← X.sex=”Muž” End

X.partner=Y,

6.3.8.4 Návrh odvozování tříd Využitím deduktivních pravidel lze odvodit další třídy, jejichž populace závisí na hodnotě specifikovaného atributu definované supertřídy.

Příklad: Mějme třídu Osoba, jejímž atributem bude profese. Na základě hodnoty atributu profese = učitel lze odvodit třídu Učitel. Define implementation for class Učitel Population Učitel(X) ← Osoba(X), X.profese = „učitel“ End Jestliže Osoba změní profesi, musí být automaticky vyňata z třídy Učitel.

6.3.9 Pravidla pro definování integritních omezení Zcela odlišný pohled na integritu databáze a především na údržbu konzistence přináší zavedení deduktivních pravidel do její definice. Deduktivní pravidla mohou sloužit k definování integritních omezení a to

75

jak ve fixním formátu, tak tzv. generických integritních omezení. Fixní formát se obvykle týká omezení typu notnull, primary key, unique attribut, inverse attribut a referenční integrita. Výše uvedená integritní omezení jsou podporována konvenčními databázovými systémy a tudíž uživatel se může plně spolehnout na zajištění integrity, jsou-li tato omezení nadefinována a tedy jsou součástí schématu databáze. Existují i další integritní omezení v tzn. generickém formátu, která závisí na specifikované aplikační doméně. Tato omezení mohou být podporována v jejich plné obecnosti pouze novými generacemi databázových systémů. u kterých se projeví výhody využití deduktivních pravidel, která jako součást databáze zajišťují integritu dat v souvislosti s požadavky aplikace .

6.3.9.1 Návrh integritních omezení ve fixním formátu •

notnull atribut Toto omezení zabraňuje, aby hodnota daného atributu zůstala prázdná nebo byla null. S využitím deduktivního pravidla lze zajistit toto integritní omezení tak, že pokud hodnota daného atributu je null, pravidlo produkuje do hlavy pravidla hodnotu. Jak bylo uvedeno výše, produkce hodnoty do hlavy pravidla je prováděna tehdy, je-li formule v těle pravidla ohodnocena jako true a je-li hodnota deduktivního pravidla true, databáze není konzistentní.

Příklad 6-2: Define object class Zaměstnanec Attributes jméno: string, notnull ……. Add constraint null_jméno for Zaměstnanec As null_jméno(Self) ← Self.jméno = null •

Primární klíč a unikátní atribut Hodnoty primárního klíče jednoznačně identifikují jednotlivé objekty dané třídy, tzn. všechny hodnoty tohoto atributu musí být jedinečné. Primární klíč smí být složený z více atributů, pak se identifikační vlastnost týká složeného klíče jako celku a nikoliv jeho částí. Navíc primární klíč nesmí nabývat hodnoty null a jde-li o složený primární klíč, žádná jeho složka nesmí nabývat hodnoty null. Tato vlastnost je automaticky hlídána, pokud je daný atribut definován jako primární klíč. Každá třída smí mít pouze jeden primární klíč, ale smí mít více unikátních atributů (tzv. kandidáti primárního klíče). Tito kandidáti splňují identifikační vlastnost, ovšem nemusí splňovat požadavek notnull ani pro složený atribut, ani pro jeho složky.

76

Příklad 6-3: Define object class Zaměstnanec Attributes číslo_zaměstnance: string, jméno: string, notnull, datum_narození: string notnull, národnost: string constraint key(číslo_zaměstnance), unique(jméno, datum_narození, národnost) add constrait key for Zaměstnanec as key(Self) ← Zaměstnanec(X), X!=Self, X.číslo_zaměstnance=Self.číslo_zaměstnance End Add constraint unique for Zaměstnanec As unique(Self) ← Zaměstnanec(X), X!=Self, X.jméno=Self.jméno, X.datum_narození=Self.datum_narození, X.národnost=Self.národnost •

Inverzní atributy Inverzními atributy se rozumí dva atributy různých tříd, které slouží k modelování vztahu mezi těmito třídami, přičemž oba atributy vyjadřují tutéž skutečnost. Z hlediska nákladů na údržbu konzistence databáze je výhodnější jeden z těchto atributů definovat jako odvozený a využít deduktivního pravidla, které skutečnost existence inverzích atributů efektivně modeluje.

Příklad 6-4: Define object class Zaměstnanec Attributes pracuje_na: Oddělení …. Define object class Oddělení Attributes zahrnuje: set-of(Zaměstnanec) …. Atributy pracuje_na a zahrnuje jsou inverzními atributy a tato skutečnost může být modelována definováním jednoto z těchto atributů jako odvozeného. Např. definujme atribut zahrnuje jako odvozený: Define object class Oddělení Attribute zahrnuje: set-of(zaměstnanec), derived Define implementation for Oddělení

77

Attributes X in Self.zahrnuje ← Zaměstnanec(X), X.pracuje_na=Self End Druhým možným řešením je definovat oba atributy a pomocí integritních omezení kontrolovat konzistenci databáze, tzn. odhalovat nedostatky, které by mohly nastat při zadání hodnoty jak do atributu zahrnuje, tak do atributu pracuje_na. Tento způsob je náročnější na údržbu. •

Referenční integrita Referenční integrita je hlídána mezi dvěma třídami, z nichž jedna je označována jako odkazující (nezávislá, nadřazená) a druhá jako odkazovaná (závislá, podřazená). Pro podřazený objekt platí, že nemůže existovat, aniž by vstoupil do vztahu s nadřazeným objektem. Tento způsob integrity je možno opět modelovat s využitím deduktivních pravidel.

Vyjděme z předchozího příkladu a předpokládejme, že třída Zaměstnanec je závislá na třídě Oddělení, tzn., že neexistuje žádný Zaměstnanec, který by nepatřil do některého z existujících Oddělení. Tuto skutečnost lze s využitím deduktivních pravidel modelovat následujícím způsobem: Define object class Zaměstnanec Attributes pracuje_na: Oddělení, notnull End Add constraint umístění for Zaměstnanec Umístění(Self) ← Self.pracuje_na = null End

6.3.9.2 Návrh generických integritních omezení Během analýzy jsou získávána generická integritní omezení jako požadavky uživatelů na danou aplikaci a jsou obvykle zaznamenávána neformalizovaně. Ve fázi návrhu se tato neformalizovaná integritní omezení transformují do odpovídající formální podoby. Již ve fázi analýzy se rozhoduje o tom, zda se jedná o generická integritní omezení cílená na konkrétní třídy objektů nebo necílená. Dalším možným kritériem rozdělení generických integritních omezení je kriterium dynamiky. Podle tohoto kriteria je účelné rozdělit generická IO statická a dynamická.

6.3.9.3 Cílená IO Omezení definovaná v kontextu specifikovaných tříd jsou omezení cílená. Formální zápis takového integritního omezení pak představuje predikát, který dohlíží na stav individuálních cílových objektů a poskytuje pro každý cílový objekt pravdivostní hodnotu. Predikát může taky odkazovat na

78

ostatní objekty, které jsou spojeny vztahem s cílovým objektem. Cílená IO jsou funkce, které vracejí objekty z jedné (cílené) třídy.

Příklad 6-5: Zaměstnanec jde do důchodu, pokud má věk větší než 60 let nebo má odpracováno více než 35 let. Následující příklad demonstruje definici pohledu Adept_na_důchod: Define view Adept_na_důchod(Důchodce:Zaměstnanec) Adept_na_důchod([X]) ← Zaměstnanec(X), X.věk > 60; Adept_na_důchod([X]) ← Zaměstnanec(X), X.odpracováno > 35 End Add constraint Chybný_adept for Důchodce As není_adept(Self) ← not Adept_na_důchod([Self]) End

6.3.9.4 Necílení IO Tato IO se nevztahují k jedné třídě, nýbrž k více třídám, které jsou ve vzájemných vztazích, obvykle ve vztahu odkazující a odkazované třídy. Necílená IO na rozdíl od cílených jsou funkce, které vrací více vzájemně provázaných objektů z různých tříd.

Příklad: Předpokládejme třídy Kurz, Zkouška a Student a jejich následující definice: Define object class Zkouška Attributes udělaná: Student, předmět: Kurz …. End Define object class Student Attributes studijní_plán: set-of(Kurz) … End Následuje IO, které bude vyjadřovat tu skutečnost, že Student smí složit pouze Zkoušku z takového Kurzu, který je součástí jeho Studijního plánu. Add constraint špatná_zkouška((S:Student, K:Kurz, Z:Zkouška) As špatná_zkouška([S, K, Z]) ← Z.udělaná=S, Z.předmět=K, not K in S.studijní_plán

79

End

6.3.9.5 Dynamická IO Dynamická IO se zabývají dvěma různými stavy stejného objektu. Má-li být např. vyjádřena ta skutečnost, že hodnota jistého atributu definované třídy je u každého nového (mladšího) objektu větší než hodnota téhož atributu staršího objektu téže třídy, lze využít deduktivního pravidla pro definici dynamického IO. Příklad uvádí IO, které hlídá, aby nové číslo verze bylo vždy větší než staré.

Příklad: Add constraint číslo for Cyklus As číslo(Self) ← Self.číslo_verze <= old(Self.číslo_verze) End

6.3.9.6 Pravidla pro funkční závislosti Všechny funkční závislosti, které jsou považovány jako předpoklady (nalezeny v analýze funkčních závislostí), je možno přepsat do deduktivních pravidel.

Příklad 6-6: Mějme množinu atributů A,B,C,D ∈ U, kde r(U) je schéma relace/třídy, s následujícími instancemi: A

B

C

D

a

b1

c1

d1

a

b2

c2

d2

Jestliže navíc platí, že b1=b2, pak platí A → B, tzn. atribut B je funkčně závislý na atributu A (ke každé hodnotě atribut A existuje právě jedna hodnota atributu B). Tuto skutečnost je možno přepsat do deduktivních pravidel. r(a, b1, c2, d2) ← r(a, b1, c1, d1) & r(a, b2, c2, d2) nebo b1 = b2 ← r(a, b1, c1, d1) & r(a, b2, c2, d2) Do deduktivních pravidel lze přepsat rovněž Armstrongovy axiomy (zde bez důkazu). Výsledkem přepisu je množina deduktivních pravidel, jejichž vyhodnocením lze získat všechny důsledky (uzávěr množiny funkčních závislostí), které vyplývají z předpokládaných funkčních závislostí.

80

6.4 Prototyping deduktivních pravidel Během fáze návrhu deduktivních pravidel je navrženo jisté množství pravidel a integritních omezení více méně nezávisle, podle toho, jak to vyžaduje aplikace. Je zřejmé, že takto navržená pravidla a integritní omezení mohou sice jednotlivě splňovat syntaktické a sémantické požadavky (viz. kap. 6.3.7.), ale množina těchto pravidel jako celek není navržena správně. Ve fázi návrhu je totiž kladen důraz na správnost jednotlivých pravidel, resp. integritních omezení. Fáze prototypingu v souvislosti s navrženou integrací deduktivních pravidel do analýzy a návrhu informačního systému se zaměřuje na vzájemné závislosti a souvislosti mezi definovanými pravidly resp. mezi integritními omezeními. Předmětem zájmu prototypingu je stratifikace a uspokojivost. • Stratifikace (jak byla v obecných rysech popsána v kapitole 2.3) stanovuje pořadí vykonávání jednotlivých pravidel v rámci množiny navržených pravidel. Jak již bylo uvedeno, množina pravidel nemusí být vždy stratifikovatelná, vyskytují-li se v ní negativní literály, rekurze, resp. agregační funkce. • Množina pravidel, která se skládá z pravidel pro odvozování dat a integritních omezení, je uspokojivá, jestliže je možno vytvořit přinejmenším jeden stav databáze konzistentní se schématem, který je správný, tzn. vyhovuje všem integritním omezením. Prototyping se zaměřuje prostřednictvím statické a dynamické analýzy na zjištění, zda vzájemné vztahy mezi pravidly splňují podmínky stratifikace a uspokojivosti. Prototyping pomáhá odhalovat nedostatky v pravidlech zkonstruovaných ve fázi návrhu nikoliv co se týká jejich jednotlivých definic, ale vzájemných vztahů a návazností (event. jejich redundance).

6.4.1 Statická analýza Statická analýza je založena na určení logických závislostí mezi uloženými (extenzionálními) a odvozenými (intenzionálními) koncepty a jejich vizualizace ve formě grafů závislostí. Uzly grafu závislostí představují třídy, atributy, integritní omezení a pohledy. Hrana z uzlu X do uzlu Y modeluje tu skutečnost, že koncept X se vyskytuje v těle deduktivního pravidla, které odvozuje koncept Y, obsažený v hlavě pravidla.

Příklad 6-7: Mějme následující množinu deduktivních pravidel X in Y.rodiče ← Osoba(X), Osoba(Y), Y in X.dítě X=Y.matka ← Matka(X), Osoba(Y), X in Y.rodič X in Y.sestry ← Osoba(X), Osoba(Y), X in Y.rodič.dítě, X.sex = „žena“, X! =Y Rodič(X) ← Osoba(X), X.dítě ! = {}

81

Matka(X) ← Rodič(X), X.sex = „žena“ Extenzionální koncepty jsou: Třída Osoba Atributy dítě a sex Intenzionální koncepty jsou: Třídy Rodič, Matka Atributy sestry, rodiče a matka

6.4.1.1 Graf závislostí V grafu závislostí lze zavést následující značení:

Extenzionální třída

Intenzionální třída

Extenzionílní atribut

Intenzionální atribut

Následuje graf závislostí, který modeluje vztahy mezi jednotlivými pravidly z příkladu 6-7.

82

Osoba.matka

Osoba.rodiče

Osoba.sestry

Matka

Osoba.sex

Rodič

Osoba

Osoba.dítě

Obr. 6-5 Dalším krokem je zjištění, zda je či není sestavený graf závislostí acyklický (tzn. neobsahuje cyklus). Pokud je graf acyklický, je rovněž navržená množina pravidel stratifikovatelná a tudíž existuje hierarchický postup deduktivních pravidel, který zabezpečí odvození veškerých konceptů. Z výše uvedeného příkladu vyplývá např. následující postup vyhodnocování pravidel: 1) odvození atributu rodiče 2) odvození třídy Rodič 3) odvození třídy Matka 4) odvození atributu matka 5) odvození atributu sestry Dalším důležitým požadavkem je, aby cesty v grafu, které odvozují koncepty, byly dobře formované, tzn. aby každý odvozovaný koncept v grafu byl dosažitelný prostřednictvím přímé cesty z nejméně jednoho extenzionálního konceptu.

6.4.1.2 Rekurze Rekurze mohou být zdrojem potencionálních problémů při vyhodnocování deduktivních pravidel. Graf závislostí obsahující rekurze musí proto

83

splňovat následující podmínku. Každý rekurzivně odvoditelný koncept musí být dobře formován, tj. musí být odvoditelný z minimálně jednoho extenzionálního konceptu. Cyklus, který se objeví v grafu závislostí z důvodu rekurze nečiní při vyhodnocení potíže, pokud každý odvoditelný koncept je odvoditelný z konceptu extenzionálního a každý cyklus v grafu představuje rekurzi tohoto odvoditelného konceptu.

Příklad: Příklad grafu pro rekurzivní pravidla:

Osoba.předek

Osoba.rodiče

Osoba

Osoba.dítě

Obr. 6-6

6.4.1.3 Dědičnost Objektový datový model přináší do databázové technologie četné výhody. Jednou z těchto výhod je možnost využití dědičnosti. Deduktivní pravidla definovaná na úrovni supertříd jsou děděna všemi podřízenými subtřídami a tudíž nemusí být znovu definována v příslušných subtřídách. Tato skutečnost ovšem v některých případech může činit potíže. Jedná se o situaci, kdy některé deduktivní pravidlo není vhodné dědit. V takovém případě musí dojít k předefinování pravidla.

Příklad 6-8: Mějme třídu Zaměstnanec a definujme pro tuto třídu deduktivní pravidlo, které odvodí atribut daň ze znalosti atributu hrubá_mzda. Předpokládejme, že daň činí 30 % hrubé mzdy. Define implementation for Zaměstnanec Attributes Self.daň = Y ← real(Y), Y=0.3 * Self.hrubá_mzda End Mějme třídu Inženýr, která je podtřídou třídy Zaměstnanec. Třída Inženýr automaticky dědí definované deduktivní pravidlo pro odvození daně.

84

Budeme-li chtít vyjádřit tu skutečnost, že daň inženýra není 30%, ale 40%, musíme deduktivní pravidlo předefinovat. Redefine implementation for Inženýr Attributes Self.daň = Y ← real(Y), Y= 0.4 * Self.hrubá_mzda End

6.4.1.4 Negace a stratifikace Vyskytuje-li se v množině deduktivních pravidel negace, může vyhodnocení pravidel vést k různým výsledkům, jestliže pořadí vyhodnocovaných pravidel je různé. Jednoduchá interpretace negace v databázi spočívá v tvrzení, že fakt není v databázi pravdivý, pokud není v databázi uložen. Tato jednoduchá implementace negace se v databázové literatuře označuje negace jako selhání, tedy došlo k selhání při hledání daného faktu v databázi. Výsledkem pak je, že fakt má hodnotu false.

Příklad 6-9: Inženýr(X) ← Zaměstnanec(X), X.vzdělání = „Ing“ Technik(X) ← Zaměstnanec(X), not Inženýr(X) Druhé pravidlo obsahuje negaci. K tomu, abychom mohli v databázi říci, kdo je technikem, musíme nejdříve znát všechny inženýry. Tzn., chceme-li přistoupit k odvození konceptu Technik, musíme nejdříve odvodit všechny koncepty Inženýr. Negativní tvrzení se zaznačí v grafu závislostí tak, že se hrana spojující nadřízený a podřízený koncept označí negací.

Inženýr

Zaměstnanec. vzdělání

¬

Technik

Zaměstnanec

Obr. 6-7

85

Příkladem nestratifikovatelných deduktivních pravidel by mohla být tato dvojice pravidel: Inženýr(X) ← Zaměstnanec(X), not technik(X) Technik(X) ← Zaměstnanec(X), not Inženýr(X) Jak Inženýr, tak Technik na sobě závisí rekurzivně a navíc negativně. Toto není správně definovaná sémantika.

6.4.2 Dynamická analýza Dynamickou analýzou se rozumí proces testování pravidel a integritních omezení na vzorku dat. Vzorek dat je třeba vytvořit tak, aby korespondoval s reálnými daty a tento vzorek dat je podroben testování. Nejdůležitějším požadavkem je požadavek na systematický přístup a to jak při tvorbě vzorku dat, tak při samotném testování. Dynamická analýza je někdy označována jako „analýza příkladem“. Výsledkem dynamické analýzy je zjištění, zda navržená množina pravidel a integritních omezení je uspokojivá. To znamená, že v konečném čase je možno sestavit aspoň jeden stav databáze, který splňuje všechna navržená pravidla a integritní omezení.

Pojmy k zapamatování: Objektový model, dynamický model, analýza, návrh, odvozování dat, návrh integritních omezení, prototyping deduktivních pravidel.

Úkoly k zamyšlení: 1. Pokuste se navrhnout odvozené atributy pro třídu Student a Skupina z příkladu v kap. 6.3.5. napište příslušná deduktivní pravidla pro odvození navržených konceptů. 2. Rozšiřte příklad 6-1 o návrh dalšího rekurzivního atributu. Zapište deduktivní pravidlo v relačním i objektovém přístupu.

Kontrolní otázky: 1. Charakterizujte základní typy vestavěných integritních omezení. 2. Co je to generické integritní omezení?

86

3. Popište jednotlivé kroky při návrhu schématu deduktivní databáze. 4. K čemu slouží prototyping deduktivních pravidel?

87

7 DEMONSTRAČNÍ ÚLOHA Cíl: Cílem této kapitoly je na jednom praktickém příkladu (komunikace mezi účastníky distančního vzdělávání) ukázat analýzu a částečně i návrh databázové aplikace v prostředí objektově deduktivního systému řízení báze dat. Po jejím prostudování by měl mít čtenář rámcovou představu o jednotlivých krocích a měl by být schopen sám analyzovat problémovou doménu a navrhnout schéma databáze v prostředí objektově deduktivního systému řízení báze dat.

Průvodce studiem: Vážené čtenářky, vážení čtenáři, Dostáváte se k závěru výukové opory, která Vás měla seznámit se základními pojmy a charakteristikami deduktivních databází. Podstatnou součástí této opory je metodika analýzy a návrhu deduktivní databáze, která vychází z metodiky IDEA. Závěrečná kapitola, ke které jste se dopracovali, obsahuje demonstrační úlohu, na které byste si měly popsané postupy znovu připomenout a ověřit si, zda jste probranou látku správně pochopili. Po jejím prostudování byste měli být schopni vypracovat korespondenční úkol, uvedený v kapitole 8.

7.1 Analýza subsystému Komunikace účastníků vzdáleného vyučování Vývoj IS je velmi složitá a komplexní činnost. Tato případová studie se pokouší pouze demonstrovat možné přístupy a tudíž v praktických ukázkách bude velmi zjednodušovat realitu a abstrahovat od mnoha skutečností.

7.1.1 Hrubá analýza Aktivními objekty, tj. objekty, které vyvíjejí aktivitu v procesu vzdáleného vyučování a o nichž se předpokládá že existují, jsou Student, Tutor, Autor kurzu, Examinátor a Organizátor. Některé role mohou být sloučeny, ovšem toto slučování rolí není příliš vhodné a může velmi negativně ovlivnit funkčnost celého systému. V zjednodušeném modelu budou spojeny role Tutora, Autora kurzu a Examinátora. Pro jednoduchost činnost tutora, autora kurzu a examinátora je označována jako aktivita Tutora a toto označení by nemělo asociovat představu, že veškeré aktivity provádí Tutor. Velmi důležitá je role Organizátora vzdáleného vyučování, kterou v uváděném modelu částečně vykonává Pedagogický poradce.

88

Model aktivních objektů vzdáleného vyučování:

Student

Tutor

Autor

Examinátor Organizátor

Obr. 7-1

Model s kumulací funkcí, který bude pro jednoduchost použit

Student

Tutor

Pedagogický poradce

Obr. 7-2

7.1.1.1 Identifikace zdrojů • •

Student je aktivním objektem, jehož hlavní aktivitou je organizace samostudia, samostudium a další aktivity s tím spojené. Tutor je průvodcem studenta v samostudiu, poskytuje mu materiály, testy, konzultace, je tvůrce kurzu, zkouší studenta.

89

• • • •

• • •

Pedagogický poradce organizuje vzdálené vyučování, radí studentovi v technických a organizačních záležitostech v průběhu studia, organizuje a vede tutoriály. Skupina je tvořena jednotlivými studenty a její existence jako samostatného objektu je dána operacemi, které jsou s ní spojeny. Kurz je studován studentem a veden tutorem. Výukový materiál je obvykle určen ke konkrétnímu kurzu, ovšem může existovat materiál určený pro více kurzů a je v různé podobě distribuován studentovi. Výukový materiál poskytuje tutor studentovi ve vhodné době a podobě tak, aby student z tohoto materiálu získal maximum informací a zároveň byl schopen danou problematiku z materiálu pochopit, procvičit a ověřit si její zvládnutí. Komunikace jsou veškeré formy vzájemných vztahů mezi objekty vzdáleného vyučování za účelem výměny informací. Test je průběžné zjišťování úrovně znalostí. Zkouška je závěrečné zjištění znalostí, obvykle zkouškou je zakončen kurz. Ve většině distančních kurzů je zkouška prováděna prezenčním způsobem.

7.1.1.2 Identifikace aplikací Na tomto místě bude uvedeno jen několik aplikací, které je třeba v modelu vzdáleného vyučování navrhnout. Jedná se demonstrační příklad za účelem použití popsané metodiky, nikoli o výčet aplikací. • Tvorba a aktualizace kurzu je zásadní činnost v procesu vzdáleného vyučování a tudíž i aplikace s ní spojená musí být detailně propracována. Dá se předpokládat, že tato aplikace bude dekomponována na více aplikací. • Tvorba a aktualizace studentů a skupin jsou operace spojené se studijně organizační činností (prováděné organizátorem), které v kumulovaném modelu provádí pedagogický poradce. • Vedení kurzu představuje činnosti spojené s průběhem studia daného kurzu. Tyto činnosti garantuje tutor a jejich kvalita bezprostředně odráží celkovou kvalitu vzdáleného vyučování. • Vyhodnocení kurzu, skupin a studentů zahrnuje veškeré evaluační činnosti spojené s kurzem, resp. systémem vzdáleného vyučování.

90

7.1.2 Analýza schématu 7.1.2.1 Identifikace atributů V této fázi analýzy není věnována pozornost struktuře jednotlivých atributů, tzn. zda se jedná o atributy atomické nebo strukturované (např. atribut typu třída). Atributy typu třída budou zřejmé až v následující části, při identifikací vztahů. Ovšem opačný postup by byl rovněž možný. V tom případě by bylo třeba nejdříve hledat vlastnosti tříd nezávisle na tom, zda se jedná o atributy jednoduché nebo strukturované a až pak se věnovat definování vztahů. Student: • identifikační číslo • jméno a příjmení • studijní obor • ročník • kontakt • studijní výsledky Skupina: • číslo skupiny Učitel: • osobní číslo • jméno a příjmení • katedra • kontakt Tutor: Pedagogický poradce: Kurz: • číslo kurzu • název kurzu • ukončen Komunikace: • kod • datum • místo konání • typ • forma • téma • vyhodnocení Konzultace: Konference:

91

Tutoriál: Výukový materiál: • číslo materiálu • název materiálu • typ materiálu • forma • způsob distribuce Test: • • • • • • • • • •

číslo testu otázka odpověď 1 odpověď 2 odpověď 3 odpověď 4 správná odpověď body odpověď získané body

Výsledky: • semestr • zapsaný kurz • požadované kredity • získané kredity Atd.

7.1.2.2 Identifikace vztahů a hierarchií Jednosměrné vztahy, kdy atribut X objektu A nabývá hodnoty objektu B jsou zobrazeny:

Oboustranné vztahy, kdy hodnota atributu X objektu A je objekt B a zároveň hodnota atributu Y objektu B je objekt A (např. Ucitel vede Kurz, Kurz je_veden Ucitelem) jsou zobrazeny:

92

IsA hierarchie ve smyslu supertříd a subtříd je zobrazena:

Následující model je modelem vztahů a hierarchií, přičemž vztahy jsou modelovány strukturovanými atributy (atribut typu třída) a isA hierarchií.

Obr. 7-3

93

7.1.2.3 Identifikace operací Ve fázi identifikace operací je třeba určit pro jednotlivé třídy (zdroje), za které operace budou tyto třídy odpovídat. Následující popis (s některými možnými operacemi) demonstruje proces identifikace operací. Operace všeobecného použití: Učitel posílá zprávy, hodnotí tutoriál, aktivuje komunikaci, …. Tutor tvoří kurz (ve zjednodušeném modelu), poskytuje materiály, vyhodnocuje testy, opravuje úkoly… Pedagog_poradce tvoří skupinu, vede tutoriály,… Student žádá o konzultaci, vypracovává test, stahuje výukový materiál, vykonává zkoušku,…. Dynamické operace: Dynamické operace odrážejí tu skutečnost, že je podstatné rozlišovat mezi různými stavy týchž objektů. Operace zápisu studenta do dalšího ročníku je možná po získání příslušného počtu kreditů z předchozích ročníků (tzv. kumulované kredity). Tato operace pracuje se různými stavy objektu Student. Posílá_zprávy() ↓ Hodnotí_tutoriál()↓ Aktivuje_kom() ↓

Tvoří_kurz()↑

Tvoří_skupinu()↑

Žádá_konzultaci()↑ Vypracovává_test()↑ Stahuje_materiály()↑

Obr. 7-4 94

7.1.3 Analýza znalostí Znalostní analýza je zaměřená na specifikaci integritních omezení ve fixním a generickém formátu. Not null atributy: Student: • identifikační číslo • jméno a příjmení • studijní obor • ročník • kontakt • studijní výsledky Skupina: • číslo skupiny Učitel: • osobní číslo • jméno a příjmení • katedra • kontakt Tutor: Pedagogický poradce: Kurz: • číslo kurzu • název kurzu • ukončen Komunikace: • kod • datum • místo konání • typ • forma • téma • vyhodnocení Konzultace: Konference: Tutoriál: Výukový materiál: • číslo materiálu • název materiálu

notnull notnull notnull

notnull notnull

notnull

notnull

notnull

95

• • •

typ materiálu forma způsob distribuce

Test: • • • • • • • • • •

číslo testu otázka odpověď 1 odpověď 2 odpověď 3 odpověď 4 správná odpověď body odpověď získané body

Výsledky: • semestr • zapsaný kurz • požadované kredity • získané kredity

notnull notnull

notnull

notnull notnull notnull

Atd. Kardinalita: Pro všechny vztahy (kromě isA vztahu) se určují kardinality. Notace i význam kardinalit odpovídá notaci konceptuálních modelů (E-R diagram). Nastavení kardinalit je ukázáno na následujícím schématu:

96

1:N

1:N

1:N

M:N

1:N M:N

1:N

1:N

Obr. 7-5

97

Povinná/nepovinná účast ve vztahu Pro všechny vztahy (kromě isA vztahu) se určuje, zda má objekt povinné či nepovinné členství v tomto vztahu. Povinná účast ve vztahu je ve schématu označena „+“, nepovinná účast „*“. +

1:N

*

* +

*

1:N

1:N

*

M:N

*

+

*

+ *

1:N

+

M:N

* *

+

1:N

1:N *

Obr. 7-6

98

Identifikaci generických integritních omezení Ve fázi analýzy jsou generická IO popsána pouze neformálně a zahrnuta do schématu. Již v této fázi je vhodné rozhodnout, zda se jedná o IO bezprostřední (kontrolované po ukončení operace) nebo o IO odložené (kontrolované po ukončení transakce). Následující schéma demonstruje identifikaci některých generických IO v prostředí vzdáleného vyučování.

ODLOŽENÉ Tutoriál musí být veden jedním učitelem

BEZPROSTŔEDNÍ Kurz je ukončen zápočtem nebo zkouškou

BEZPROSTŘEDNÍ Ročník studia je v int. <1,5> resp. <1,7> dle oboru

ODLOŽENÉ

BEZPROSTŘEDNÍ

Konference se účastní aspoň jedna skupina

Forma distribuce je dána výčtem možností: D1, D2, D3, …

ODLOŽENĚ Student má splněn kurz pokud vykoná předepsané testy a zkoušku

Obr. 7-7

99

7.1.4 Analýza aplikací Ve fázi hrubé analýzy bylo nalezeno pět základních aplikací. Nyní je třeba vytvořit seznam všech jejich komponent. Seznam uvádí pouze některé komponenty, zdaleka není kompletní. Aplikace Tvorba kurzu je složena z následujících operací: struktura kurzu, tvorba výukových materiálů, tvorba harmonogramu kurzu, tvorba testů, …. Aplikace Tvorba skupin je složena z následujících operací: tvorba profilů studentů, spojení studentů do skupin, aktivity skupin, … Aplikace Komunikacezahrnuje operace konzultace, konference, tutoriál, … Aplikace Testy se skládá z operací vypracování testů, zaslání výsledků, vyhodnocení, statistika, … Aplikace Hodnocení představuje hodnocení tutoriálů, kurzů, studentů, skupin, …. Po nalezení jednotlivých komponent aplikací je třeba všechny tyto komponenty popsat. Popis aplikací je možno provést následujícím způsobem.

7.1.4.1 Popis aplikace Tvorba harmonogramu kurzu Aplikace: Popis:

Vstupy: Změny:

Zpráva: Předpoklady:

Výsledek:

Harmonogram Aplikace zapíše do kalendáře pro daný semestr, v němž bude kurz realizován, všechny úkoly, které bude Student plnit. Prázdný kalendář pro daný semestr, Kurz, Test Aktualizovaný kalendář ve formě např.: Datum: úkol (Datum1,Datum2): úkol Aktualizovaný kalendář je poslán všem Studentům, zapsaným na daný Kurz. Existuje Kurz, který bude zapisován do kalendáře, existují Testy, které budou zapisovány do kalendáře, existuje aspoň jeden Student, který má zapsán daný Kurz. Aktualizovaný kalendář pro daný kurz dle aktuálního kalendáře semestru a příslušných testů.

7.1.5 Analýza funkčních závislostí Identifikace všech atributů v rámci jednotlivých tříd byla provedena tak, že kromě všech závislostí neklíčových atributů na primárním klíči se vyskytují i závislosti neklíčových atributů navzájem. Ve třídě Učitel se vyskytují následující závislosti:

100

osobní_cislo → jmeno osobní_cislo → katedra osobní_cislo → kontakt Výše uvedené závislosti jsou závislosti neklíčových atributů na primárním klíči osobní_cislo. Závislost osobní_cislo → komunikace lze chápat jako multizávislost, protože atribut komunikace je typu třída. Ve třídě Učitel se však vyskytuje i takový neklíčový atribut, který je závislý na jiném neklíčovém atributu. Touto závislostí je: katedra → jmeno Nalezené závislosti budou transformovány do deduktivních pravidel ve fázi návrhu deduktivních pravidel.

7.2 Návrh subsystému Komunikace vzdáleného vyučování 7.2.1 Návrh schématu Návrh schématu databáze představuje návrh tříd, vztahů a operací, které vycházejí z analýzy schématu a zajišťují kompletaci jejich definic. Důraz je kladen na kontrolu hierarchických vazeb, dále na to, které atributy tříd musí být uloženy v extenzionální databázi a které je možno odvodit pomocí deduktivních pravidel. Ve fázi návrhu se rovněž zavádí množina atributů, které budou podporovat dynamiku systému. Součástí návrhu je rovněž definice datových typů. Následuje několik konkrétních návrhů v modelu vzdáleného vyučování, které představují možnosti odvozování atributů včetně rekurzivních, využití dědičnosti, možnosti definování vztahů mezi třídami, vyjádření inverzního atributu. 1) Student Definice třídy Student bude mimo jiné vyžadovat definici atributu kredity_za_semestr, podle kterého budeme moci zjistit počet získaných kreditů daného studenta za jednotlivé semestry. Tento atribut nemá charakter extenzionálního atributu, protože jeho hodnota je odvoditelná z atributu studijní_výsledky. Atribut studijní_výsledky je strukturovaný (objekt), jehož definici v rámci návrhu je možno provést např.: Studijní_výsledky: • semestr • zapsaný kurz • požadované kredity • získané kredity

101

•

známka

Z uvedeného vyplývá, že ve fázi návrhu je možno nacházet další objekty, jejichž existence a hlavně struktura ve fázi analýzy ještě nebyla předpokládána. 2) Učitel Učitel je třída, která je zdrojem IsA hierarchie pro třídy Tutor a Pedagogický_poradce. 3) Kurz Součástí definice třídy Kurz je atribut požadavek, který nabývá hodnot z domény Kurz. Požadavky Kurzu jsou tedy Kurzy, které musí být bezprostředně splněny, aby si Student mohl daný Kurz zapsat. Protože atribut požadavek odkazuje na třídu Kurz (tedy na sebe samu), je s použitím deduktivních pravidel možno vytvořit tzv. binární uzávěr množiny vztahů, což představuje množinu všech podmiňujících Kurzů k zapsání daného Kurzu. Např. Kurz Relační databáze s číslem 100 požaduje splnění Kurzu Úvod do databází s číslem 95 a tento požaduje splnění Kurzu Úvod do OS s číslem 86. Jednotlivé instance třídy Kurz pak lze zapsat: Kurz: RELDA Kurz: UVDAT číslo_kurzu: 100 číslo_kurzu: 95 . . . . . . požadavek: UVDAT požadavek:Úvod do OS Ke zjištění všech (tj. nejen bezprostředních) požadavků k danému Kurzu lze vytvořit atribut předpoklady (tento bude součástí intenzionální databáze), jehož hodnoty budou generovány na základě rekurzivního deduktivního pravidla. Kromě definic tříd, hierarchií a atributů (ať již extenzionálních či intenzionálních) je třeba definovat vazby, respektive převést vazby odhalené ve fázi analýzy a zakreslené v příslušném modelu do formalizované podoby. Jedná se o definice atributů s objektovou hodnotou, která tento vztah zabezpečuje. Zde je na místě analogie s transformací konceptuálních schémat do relačních datových schémat, kdy zprostředkovatelem vazby je tzv. cizí klíč. Definici takového atributu doplňuje zároveň definice integritních omezení s využitím deduktivních pravidel. Součástí schématu databáze založeném na objektové orientaci je rovněž návrh operací, které jsou implementovány jako metody příslušných tříd. V rámci deduktivně objektové technologie jsou operace navrženy jako deduktivní nebo aktivní pravidla.

102

Jedná se o operace Tvoř_předky() třídy Kurz nebo operace Vypočti_kredity() a Zjisti_počet_studentů() třídy Student jsou součástí definic tříd Kurz resp. Student. Definice konkrétních deduktivních pravidel bude uvedena v kapitole 7.2.2. Návrh schématu mapovaný do prostředí ConceptBase: Individual Student in Class with attribute id_cislo : String; jmeno : String; obor : String; rocnik : Integer; kontakt : String; studijni_vysledky : Vysledky End pozn. atribut studijni_vysledky je objekt Individual Skupina in Class with attribute cislo_skupiny : Integer; studenti : Student; studuje : Kurz; komunikace : Komunikace End pozn. atributy studenti, studuje a komunikace jsou objekty Individual Ucitel in Class with attribute osobni_cislo : Integer; jmeno : String; katedra : String; kontakt : String; komunikace : Komunikace End pozn. atribut komunikace je objekt Individual Tutor isA Ucitel with attribute vede:Kurz End pozn. atribut vede je objekt Individual Pedagog_poradce isA Ucitel with attribute

103

ridi: Skupina End pozn. atribut ridi je objekt Individual Kurz in Class with attribute cislo_kurzu : Integer; nazev : String; vyuk_material : Vyukovy_material; test : Test; ukoncen : String; je_veden : Tutor; studuje : Skupina; pozadavek : Kurz End pozn. atributy vyuk_material, test, je_veden, studuje, pozadavek jsou objekty. Atribut pozadavek odkazuje rekurzivně na třídu Kurz. Individual Komunikace in Class with attribute kod : Integer; datum : String; misto : String; typ : String; forma : String; tema : String; vyhodnoceni : String; ucitel : Ucitel End pozn. atribut ucitel je objekt Individual Konzultace isA Komunikace with attribute student : Student End Individual Konference isA Komunikace with attribute skupina : Skupina; kurz : Kurz End Individual Tutorial isA Komunikace with attribute

104

skupina : Skupina; tema : String End Individual Vyukovy_material in Class with attribute cislo : Integer; nazev : String; forma : String; zpusob_distribuce : String End Individual Test in Class with attribute otazka : Otazka; odpoved1 : String; odpoved2 : String; odpoved3 : String; odpoved4 : String; spravna_odpoved : String; body : String; cislo_testu : Integer; odpoved : String; ziskane_body : String End Individual Vysledky in Class with attribute semestr : Integer; zapsany_kurz : String; pozadovane_kredity : Integer; ziskane_kredity : Integer End

7.2.2 Návrh deduktivních pravidel Již z návrhu schématu databáze vyplývají požadavky na definování konkrétních deduktivních pravidel jak pro odvozování dat, tak pro integritní omezení. Vycházeje ze vzorové demonstrační aplikace je třeba navrhnout deduktivní pravidla a to již ve formální podobě.

7.2.2.1 Pravidla pro odvození atributů •

kredity_za_semestr

105

•

Odvozený atribut kredity_za_semestr je atribut třídy Student a lze jej vyjádřit na základě znalosti atributů semestr a získané kredity, což jsou atributy třídy Výsledky. Propojení těchto dvou tříd je zajištěno atributem studijní výsledky. Deduktivní pravidlo je uvedeno níže (v části, označené příklad 7-1). počet_studentů_ve_skupině

•

Pro vyjádření odvozeného atributu počet_studentu_ve_skupine lze nadefinovat deduktivní pravidlo, které využije agregační funkci count. Pravidlo je uvedeno níže (v části, označené příklad 7-1). předpoklady Pro odvození atributu předpoklady se využije rekurzivní deduktivní pravidlo na tranzitivní uzávěr vztahu. Atributem předpoklady se rozumí množina všech požadavků (tj. kurzů, které musí mít student splněny, aby si mohl daný kurz zapsat). Pravidlo je uvedeno níže (v části, označené příklad 7-1).

7.2.2.2 Pravidla pro odvození tříd Na základě konkrétních hodnot daných atributů je možno definovat třídy. Definice takových tříd je součástí intenzionální databáze. Odvozenou třídou, která může být pro tvorbu aplikací prospěšná, je třída Učitel_katedry_informatiky, která představuje všechny Učitelé, u nichž hodnota atributu katedra = Informatika nebo třída Tutor_kurzu_databáze, jejíž populace vzniknou na základě hodnoty atributu vede = Databáze ve třídě Tutor. Konkrétní definice deduktivních pravidel, která generují populace uvedených odvozených tříd, jsou uvedeny níže (v části, označené příklad 7-1). Definice intenzionálního atributu kredity_za_semestr: Individual Student with attribute kredity_za_semestr : Integer derived End Pro výpočet počtu kreditů za jednotlivé semestry požijeme extérní formuli CastToPocet_kreditu, jejímž vstupním parametrem bude semestr a výstupním parametrem bude počet získaných kreditů. Define external formula CastToPocet_kreditu (in semestr: integer, out I integer) End Této formule využijeme při definování deduktivního pravidla pro odvození atributu kredity_za_semestr: Define implementation for Student with

106

attribute Self.kredity_za_semestr = I ← intereg(I), CastToPocet_kreditu (Self.studijni_vysledky.semestr, I) End Definice intenzionálního atributu pocet_studentu_ve_skupine: Individual Skupina in Class with attribute cislo_skupiny : Integer; studenti : Student; studuje : Kurz; pocet_studentu_ve_skupine : Integer derived End Define implementation for Skupina attribute Self.pocet_studentu_ve_skupine = X ← Integer(X). X = count(Self.studenti) End Definice intenzionálního atributu predpoklady: (Definice využívá rekurzivního pravidla, které se skládá z báze a rekurze) Individual Kurz in Class with attribute cislo_kurzu : Integer; nazev : String; vyuk_material : Vyukovy_material; test : Test; ukoncen : String; je_veden : Tutor; studuje : Skupina; pozadavek : Kurz; predpoklady : set-of(Kurz), derived End Define implementation for Kurz attribute X in Self.predpoklady ← Kurz(X), X in Self.pozadavek; X in Self.predpoklady ← Kurz(X), X in Self.pozadavek.predpoklady End

107

Definice intenzionální třídy Ucitel_katedry_informatiky: Define implementation for class Ucitel population Ucitel_katedry_informatiky(X) ← Ucitel(X), X.katedry Informatika End

=

Definice intenzionální třídy Tutor_kurzu_databaze: Define implementation for class Tutor population Tutor_kurzu_databaze(X) ← Tutor(X), X.vede = Databaze End

7.2.2.3 Pravidla pro definování integritních omezení ve fixním formátu Je-li tělo pravidla vyhodnoceno jako true (tj. je produkována hodnota do těla pravidla), zadaná data neodpovídají integritnímu omezení. Na základě tohoto předpokladu lze sestavit příslušné deduktivní pravidlo. Následují některá IO ve fixním formátu, jak vyplývají z aplikační domény: 1) notnull Atribut id-cislo třídy Student nesmí nabývat hodnoty null 2) primární klíč K definici primárního klíče se využije vlastnost PK, že žádné dvě hodnoty tohoto atributu se v rámci jedné třídy nesmí rovnat. Např. atribut id_cislo třídy Student bude primárním klíčem. 3) inverzní atribut Inverzními atributy mohou být např. atribut komunikace třídy Ucitel a atribut ucitel třídy Komunikace. Tyto atributy musí splňovat požadavek inverzních atributů. 4) referenční integrita Odkazuje-li např. atribut studenti třídy Skupina na třídu Student a jeli tento atribut definován jako notnull, pak je třeba příslušným deduktivním pravidlem zajistit referenční integritní omezení.

7.2.2.4 Generická integritní omezení Na základě obecné definice pro generické integritní omezení je možno definovat IO s ohledem na danou aplikační doménu. Dále jsou uvedena jak IO s bezprostředním, tak i odloženým vyhodnocením.

108

• •

• • • •

ročník Studenta je celé číslo v rozsahu 1-5 katedra Učitele je jedna z hodnot { Matematika, Informatika, Chemie, Fyzika, Biologie, Geologie} cislo_skupiny je kladné cislo_kurzu je kladné cislo_testu je v rozsahu 1-500 pozadovane_kredity >= ziskane_kredity

Veškerá pravidla pro definování IO ve fixním formátu i generických IO: Pravidla pro definování IO ve fixním formátu: id_cislo not null Add immediate constraint null_id_cislo for Student as null_id_cislo(Self) ← Self.id_cislo = null End id_cislo primary key Add immediate constraint primary_key for Student as primary_key(Self) ← Student(X), X! X.id_cislo = Self.id_cislo End Inverzní atribut Individual Ucitel in Class with attribute . . komunikace : Komunikace . . End Individual Komunikace in Class with attribute . . ucitel : Ucitel . . End Define implementation for Komunikace

109

attribute X in Self.ucitel ← Ucitel(X), X.komunikuje = Self End Referenční integrita Individual Skupina in Class with attribute . . studenti : Student, notnull . . End Add defered constraint je_slozen for Skupina as je_slozen(Self) ← Self.studenti = null End Pravidla pro generická IO: ročník Studenta je celé číslo v rozsahu 1-5 Add immediate constraint vadny_rocnik for Student as vadny_rocnik(Self) ← Self.rocnik < 1; vadny_rocnik(Self) ← Self.rocnik >5 End katedra Učitele je jedna z hodnot { Matematika, Informatika, Chemie, Fyzika, Biologie, Geologie} Add immediate constraint vadna_katedra for Ucitel as vadna_katedra(Self) ← not Self.katedra Informatika, Chemie, Fyzika, Biologie, Geologie} End

in

{

Matematika,

cislo_skupiny je kladné Add immediate constraint vadne_cislo_skupiny for Skupina as vadne_cislo_skupiny(Self) ← Self.cislo_skupiny <= 0 End cislo_kurzu je kladné Add immediate constraint vadne_cislo_kurzu for Kurz as vadne_cislo_kurzu(Self) ← Self.cislo_kurzu <= 0

110

End cislo_testu je v rozsahu 1-500 Add immediate constraint vadne_cislo_testu for Test as vadne_cislo_testu(Self) ← Self.cislo_testu < 1; vadne_cislo_testu(Self) ← Self.cislo_testu > 500 End pozadovane_kredity >= ziskane_kredity Add defered constraint vadne_kredity for Vysledky as vadne_kredity(Self) ← Self.ziskane_kredity Self.pozadovane_kredity End

>=

Pravidlo pro inverzní vztah: Define implementation for Kurz attributes X in Self.studuje ← Skupina(X), X.studuje = Self End

7.2.2.5 Deduktivní pravidla pro inverzní atributy Z Obr. 7-3 je patrné, že mezi třídami Kurz a Skupina existuje inverzní vztah. Atribut studuje třídy Skupina a atribut studuje třídy Kurz jsou tedy inverzními atributy. Z hlediska údržby integrity databáze je vhodnější jeden z těchto atributů definovat jako odvozený s využitím deduktivního pravidla.

7.2.2.6 Deduktivní pravidla pro funkční závislosti Nalezené závislosti v analýze je třeba převést do příslušných deduktivních pravidel. osobní_cislo → jmeno osobní_cislo → katedra osobní_cislo → kontakt Závislost neklíčových atributů na klíči je možno přepsat do pravidla, které vyjadřuje tu skutečnost, že jestliže se ve třídě Učitel naleznou dva objekty, které mají totéž osobní_cislo, jedná se o identické objekty. X=Self ← Ucitel(X), X.osobní_cislo=Self.osobní_cislo katedra → jmeno

111

Deduktivní pravidlo, které definuje výše uvedenou funkční závislost, vyjadřuje tu skutečnost, že jestliže se najdou ve třídě Učitel dva objekty se stejným jménem, pak mají též stejnou katedru. X.katedra = Self.katedra ← Ucitel(X), X.jmeno=Self.jmeno

7.3 Prototyping deduktivních pravidel Pro zjištění logických závislostí mezi extenzionálními a intenzionálními koncepty je vhodné sestavit graf závislostí. Extenzionální koncepty jsou všechny individuály jako třídy, které nevznikly použitím deduktivních pravidel a veškeré atributy, které nejsou definovány jako „derived“. K sestavení grafu závislostí se postačí zabývat v rámci schématu pouze těmi koncepty, které se vyskytují v těle aspoň jednoho deduktivního pravidla. V popisované aplikaci se jedná o tyto extenzionální koncepty. Individuály jako třídy: Student, Skupina, Kurz, Ucitel, Tutor, Studijni_vysledky Atributy: semestr, studenti, pozadavek, vede, katedry Na základě deduktivních pravidel byly odvozeny tyto intenzionální koncepty. Třídy: Ucitel_katedry_informatiky, Tutor_kurzu_databaze Atributy: kredity_za_semestr, počet_studentu_ve_skupine, predpoklady

112

Graf závislostí pro popsané koncepty:

Student.Studijni_ vysledky.semestr

Skupina

Tutor

Ucitel

Kurz.pozadavek

Student.kredity_za _semestr

Skupina.pocet_stu dentu_ve_skupine

Tutor_kurzu_ databaze

Ucitel_katedry_ informatiky

Kurz.predpoklady

Student

Skupina.studenti

Tutor.vede

Ucitel.katedry

Kurz

Studijni_vysledky

Z grafu závislostí je zřejmé, že se jedná o acyklický graf a tudíž navržená množina pravidel je stratifikovatelná. Dále z grafu vyplývá, že každý rekurzivně odvoditelný koncept (Kurz.predpoklady) je dobře formován, tj.

113

je odvoditelný z minimálně jednoho extenzionálního konceptu (Kurz, Kurz.pozadavek). Aplikace zároveň nevyžaduje redefinici atributů podtříd v souvislostí s dědičností. Problém negace se v aplikaci nevyskytl (žádné deduktivní pravidlo neobsahovalo negativní literál). Z hlediska statické analýzy je navržená množina deduktivních pravidel korektní.

114

8 KORESPONDENČNÍ ÚKOL Definujte jednoduchou aplikační doménu pro návrh schématu deduktivní databáze. Dle kroků, popsaných v předchozích kapitolách a použitých v demonstrační aplikaci analyzujte vybraný výsek reality (analýzu doplňte příslušnými diagramy) a navrhněte schéma objektově deduktivní databáze. Zaměřte se na návrh deduktivních pravidel pro odvození tříd, atributů (včetně rekurzivních) a integritních omezení. Zabývejte se rovněž prototypingem deduktivních pravidel.

115

9 ZÁVĚR Analýza, návrh a implementace informačních systémů je složitý proces, realizovaný formou týmové práce. Informační systém je vysoce kreativní produkt, při jehož tvorbě, jako u všech tvůrčích procesů, hraje velkou roli lidská invence. Je v podstatě nemožné vytvořit informační systém, který by splňoval veškeré požadavky a neměl žádná úskalí a chyby. Uvedená skutečnost je důvodem toho, že již řadu let existuje snaha o vytvoření systematických metod a technik, které by činnosti spojené s tvorbou IS usnadnily a byly návodem pro jejich tvůrce (týmy tvůrců). V devadesátých letech vznikly metodologie (jak bylo uvedeno v kap.1), které vycházejí z objektové orientace, a které charakterizuje společný přístup zaměřený na tzv. objektový a dynamický model. V posledních letech jsme svědky propojování objektových přístupů s přístupy deduktivními, které již prošly svým vývojem v souvislosti s možnými rozšířeními relačních databázových technologií. Základní ideou deduktivních databází je rozšíření expresivity databázových jazyků se současným zachováním jejich deklarativnosti. Zajímavý problém v této souvislosti je, jaké vzory chování lze dedukovat z celkem jednoduchých informací uložených v databázi. Zavedení deduktivních pravidel přináší dvě základní výhody. Jsou jimi nové prostředky pro zachování integrity dat a možnost odvozování nových dat (hlavně využitím rekurzivních pravidel). Spojení objektových a deduktivních přístupů v procesu tvorby informačního systému se jeví v mnoha ohledech přínosné, což je dokumentováno v jednotlivých kapitolách této výukové opory. Výuková opora si kladla za cíl seznámit čtenáře s možnostmi objektových a deduktivních přístupů k analýze a návrhu informačních systémů. Cílem nebylo uvést vyčerpávající seznam systémů řízení báze dat, proto bylo zmíněno pouze několik systémů, hlavně takových, které je možno získat volně na Internetu. Hlavní prostor byl věnován systému řízení báze dat ConceptBase. Systém byl vybrán jak z důvodu poměrně velké univerzality především v reprezentaci znalostí, tak z důvodů jeho snadného získání (včetně dokumentace) a rovněž z důvodu poměrně široké škály aplikací, které byly v prostředí ConceptBase vyvinuty. Při popisu systému ConceptBase byl kladen důraz hlavně na jeho univerzálnost, jeho možnosti interpretace znalostí, modelovací a metamodelovací nástroje, prostředky pro odvozování dat a zachování integrity dat. Důkladné seznámení se aspoň s jedním deduktivně objektovým systémem řízení báze dat je nezbytné k získání představy o možnostech, rozšířeních a nových pohledech na vývoj informačních systémů. Výuková opora je doplněna řadou příkladů v jazyku Chimera, který byl vyvinut v rámci v rámci IDEA Esprit projektu. Snahou bylo ukázat možnosti využití a přitom se neomezovat na konkrétní databázové prostředí.

116

10 POUŽITÁ LITERATURA 1. Asirelli, P., Gnesi, S., Rossi, M.C.: Deductive Database Support to the Specification of Concurrent Systems. Sborník celostátního semináře SOFSEM96, Springer, 1996 2. Ceri, S., Gottlog, G., Tanca, L.: What you Always Wanted to Know About Datalog. IEEE Trans. On Knowledge and Data Eng. 1989 3. Ceri, S., Gottlog, G., Tanca, L.: Logis Programming and Databases. Springer-Verlag, 1990 4. Ceri, S., Fraternali, P.: Designing Database Applications with Objects and Rules, Addison-Wesley, 1997 5. Korth, H.F., Silberschatz, A.: Database systém concepts, McGraw-Hill international editions, 1991 6. Lukasová, A.:Logické základy umělé inteligence – výroková a predikátová logika, Ostravská univerzita, 1995 7. Pokorný, J.: Dotazovací jazyky, Science, 1994 8. Ullman, D.J.: Principles of database and knowledge-base systems, Volume I, Computer Sc. Press, 1988 9. Ullman, D.J.: Pronciples of database and knowledge-base systems, Volume II, Computer Sc. Press, 1989 10. Wagner, G.: Fundations of Knowledge Systems with Applications to Databases and Agents, Kluwer Academic Publishers, London, 1998 11. M.A. Jeusfeld: Update control in deductive object bases, Infix-Verlag, St. Augustin, Germany 12. M.A. Jeusfeld, E. Krüger: Deductive integrity maintenance in an objectoriented setting. Technical report MIP-9013, Universität Passau. 13. M.A. Jeusfeld, M. Jarke: From relational to object-oriented integrity simplification. Proc. 2nd Intl. Conf. Deductive and Object-Oriented Databases (DOOD'91), LNCS 566, Springer-Verlag; technical report Aachener Informatik-Berichte 91-19 14. M.A. Jeusfeld, M. Staudt: Query optimization in deductive object bases. In Freytag, Vossen, Maier (eds.): Query Processing for Advanced Database Systems, Morgan-Kaufmann Publ., 1994; technical report Aachener Informatik-Berichte 91-26 15. M. Jarke (ed.): ConceptBase V3.1 user manual. Technical report Aachener Informatik-Berichte 92-17 16. M. Jarke, M. Staudt: An application perspective to deductive object bases. Proc. ACM-SIGMOD Workshop on Combining Declarative and Object-Oriented Databases, Washington D.C., May 1993, 17-30

117

17. M. Jarke, M.A. Jeusfeld, C. Quix (eds.): ConceptBase V5.0 User Manual. RWTH Aachen, Germany, 1998, ONLINE: http://wwwi5.informatik.rwth-aachen.de/CBdoc/userManual-V50/. 18. Stefano Ceri, Rainer Manthey: Consolidated Specification of Chimera (CM and CL), IDEA deliverable IDEA.DE.2P.006.01, November 1993, 86 pages. 19. Stefano Ceri, Rainer Manthey: Chimera: A Model and Language for Active DOOD Systems, Workshops in Computing Series, pp. 3-16, Springer 1995.

118