Teoretická východiska deduktivních databází

Transkript

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
<n-ární predikátový symbol>(<atribut>, <atribut>,..,<atribut>)
odpovídá schématu jeho interpretující relace stejné arity
<jméno relace>(<atribut>, <atribut>,..,<atribut>).
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>, <dítě>)
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
X=2
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.
Deduktivní databáze,
objektově-orientované systémy řízení báze dat,
Florid,
Gedblog,
Illustra,
ODE,
Validity,
RockRoll,
P/FDM.
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
jsou SimpleClass
Metameta Class
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.
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
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.
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.
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
ConceptBase,
Logický, rámcový a grafický formát,
Telos,
vzory tvrzení,
třídy znalostní báze,
Telosovské axiomy,
CBL,
dotazování,
model a metamodel.
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.
Deduktivní integrita,
kompilační fáze,
vyhodnocovací fáze,
syntaktická integritní omezení,
sémantická integritní omezení.
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:
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:
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:
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í.
Objektový model,
dynamický model,
analýza, návrh,
odvozování dat,
návrh integritních omezení,
prototyping deduktivních pravidel.
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
• 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
• studijní obor
• ročník
• kontakt
• studijní výsledky
Skupina:
• číslo skupiny
Učitel:
• osobní číslo
• 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
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
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;
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:
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
.
.
.
.
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
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
15. M. Jarke (ed.): ConceptBase V3.1 user manual. Technical report
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