WebML – datové modelování

8. ledna 2004

•

Datové modelování představuje jednu ze základních součástí analýzy každého softwarového projektu, tedy i projektu, jehož cílem je vytvořit internetovou aplikaci. Správný návrh datové struktury může do značné míry ovlivnit bezporuchovost, udržovatelnost a rozšiřitelnost výsledné aplikace. Jak se s touto problematikou vypořádala metodologie WebML, se dozvíte v následujícím článku.

Úvod do datového modelování

Cílem datového modelování je navrhnout kvalitní datovou strukturu pro konkrétní aplikaci a databázový systém, který bude tato aplikace využívat k uložení dat.

Při datovém modelování obvykle vytváříme nejprve konceptuální datový model. Konceptuální datový model představuje určité zobecnění oproti konkrétní implementaci datové struktury v relační, objektové, případně nativní XML databázi. Zobecněním získáme nezávislost modelu na konkrétním databázovém systému, ale zároveň jsme schopni tento model kdykoliv převést do konkrétního implementačního prostředí.

Pokud bychom od začátku analýzy „šili“ datovou strukturu na míru například databázovému systému MySQL a později zjistili, že zákazník hodlá přejít na Oracle nebo dokonce na nějakou XML databázi, museli bychom pravděpodobně celý návrh opakovat. Vhodnější je tedy vytvořit nejprve obecnější konceptuální datový model a teprve na jeho základě ve fázi implementace navrhnout datovou strukturu pro konkrétní databázový systém. Pokud používáme nějaký CASE nástroj, máme téměř vždy možnost nechat si z příslušného modelu databázovou strukturu automaticky vygenerovat (například ve formě SQL skriptů).

Pokrýt problematiku datového modelování v jednom článku představuje vzhledem k rozsahu a obtížnosti tématiky zcela nemožný úkol. Proto je cílem tohoto článku pouze ukázat, jak k datovému modelování přistupuje metodologie WebML.

Datový model WebML

Datový model WebML slouží pro návrh datové struktury, která reprezentuje informace zpracovávané a prezentované v internetové aplikaci. Jedná se o konceptuální model, který je velice podobný klasickým ER diagramům používaným pro návrh struktury relačních databází nebo UML Class diagramům používaných v objektové analýze a návrhu.

Model je tvořen sadou entit, které jsou mezi sebou provázány pomocí vazeb s příslušnou kardinalitou (násobností).

Entity

Entita reprezentuje určitou skupinu objektů reálného světa, které se označují jako instance entity. Všechny instance dané entity se nazývají populací a vyznačují se stejnou vnitřní datovou strukturou, která se vyjadřuje množinou atributů. Pouhá shoda atributů ale samozřejmě nestačí, všechny instance dané entity musí mít i logickou souvislost. Typickou entitou může být například entita „zákazník“ a instancemi této entity mohou být například „Jan Novák“, „Petra Čechová“ a další. Entitou samozřejmě nemusí být jen nějaké reálné fyzické objekty (zboží, zákazník), ale může se jednat i o objekty abstraktní (kategorie zboží, objednávka a podobně).

Každá entita je popsána svým názvem a sadou atributů. Například entita zboží bude mít pravděpodobně atributy (kód, název, popis, cena, záruka a další). Každý z těchto atributů má samozřejmě přiřazen i datový typ. WebML definuje následující obecné datové typy:

Integer
Float
String
Text
Date
Time
Boolean
Blob

Tyto datové typy jsou navrženy tak, aby nebyly přímo závislé na konkrétním databázovém systému. Jde o základní datové typy, se kterými se pravděpodobně setkáme ve většině databázových systémů. Při generování konkrétní databázové struktury z navrženého modelu jsou tyto datové typy nahrazeny příslušnými ekvivalenty konkrétního databázového systému. Například „string“ může být implementován jako „char(n)“ nebo „varchar(n)“. WebML navíc nabízí možnost jednoduše definovat vlastní datové typy.

Pokud používáme CASE nástroj WebRatio, bude ke každé entitě automaticky generován atribut s názvem OID (object identification). Jedná se o přirozené číslo, které jednoznačně identifikuje všechny instance dané entity. Při generování konkrétní databázové struktury bude OID nahrazeno způsobem, který odpovídá danému typu databáze. V relačních databázích to bude primární klíč.

Grafická notace pro entity ve WebML nikterak nevybočuje ze zažitých způsobů. Entitu zobrazujeme pomocí obdélníku, ve kterém jsou vepsány název a pod čarou atributy (viz obrázek č. 1).

entita zbozi
Obrázek č. 1 – příklad entity „zbozi“

Jak bylo uvedeno v předchozím článku, všechny modely WebML jsou interně ukládány ve formátu XML. Následující výpis představuje XML zápis pro entitu „zbozi“:

Vazby mezi entitami, kardinalita

Vazba mezi entitami představuje logický vztah mezi entitami. V datovém modelu WebML jsou povoleny pouze vazby mezi dvěma entitami (binární vazby). Vychází se z možnosti realizovat jakoukoliv N-ární vazbu (mezi N entitami) pomocí N vazeb binárních a jedné centrální (vazební) entity.

Stejně jako entita má své instance, také binární vazba má své instance. Pokud je binární vazba definována jako logický vztah mezi dvěma entitami, potom je instance binární vazby vztah mezi dvěma instancemi dvou entit. Například vazba mezi entitou zboží a kategorie, může mít instanci „stůl od firmy xy patří do kategorie kuchyňské stoly“.

Na vazbu můžeme pohlížet jako na dvě vazby v opačných směrech. V tomto smyslu se hovoří o takzvaných rolích, které představují pohled na danou vazbu ve směru od jedné entity ke druhé. Například na vazbu mezi kategorií zboží a zbožím můžeme pohlížet tak, že se ptáme, do jaké kategorie daná položka zboží patří, nebo tak, že se ptáme, jaké zboží patří do příslušné kategorie.

Ke každé z rolí přiřazujeme takzvanou kardinalitu. Kardinalita představuje omezení v počtu instancí druhé entity, které mají vztah s jakoukoliv instancí první entity. Definuje se vždy maximální a minimální kardinalita. Minimální kardinalita může nabývat hodnot 0 nebo 1 a maximální kardinalita 1 nebo N. K osvětlení problematiky vazeb a kardinality by mohl pomoci obrázek č. 2.

binarni relace
Obrázek č. 2 – příklad binární vazby

Na obrázku č. 2 můžeme vidět vazbu pojmenovanou „zbozi_kategorie“, která vyjadřuje vztah mezi zbožím a kategorií. Vazbu charakterizují dvě role podle toho, kterým směrem ji čteme. K rolím jsou přiřazeny kardinality. Pokud vazbu čteme směrem od zboží ke kategorii (role: zbozi na kategorii), zajímá nás, v kolika kategoriích může být zboží uloženo. Kardinalita „1,1“ znamená, že zboží může být uloženo v jedné a právě jedné kategorii. Pokud vztah čteme z druhé strany (role: kategorie_na_zbozi), zajímá nás, kolik druhů zboží může být v jedné kategorii. Kardinalita „0,N“ znamená, že kategorie může být prázdná nebo obsahuje N druhů zboží (teoreticky nekonečno).

Pozn. aut.: Šipky v obrázku pouze zdůrazňují směr, ve kterém se vztah čte ve spojení s danou rolí a kardinalitou. Směr je zde zdůrazněn především z toho důvodu, že kardinalita v datovém modelu WebML je připisována k entitám v opačném směru než je obvyklé v klasických ER diagramech. Role ani názvy vazeb se do modelu nezakreslují, jsou ovšem nedílnou součástí modelu.

Při generování struktury databáze z modelu WebML do nějaké relační databáze, odpovídá každé entitě jedna relační tabulka. V datovém modelu WebML se nedefinují explicitně atributy, které v relačních databázích označujeme jako cizí klíče. Pokud bychom v relační databázi chtěli implementovat schéma z obrázku č. 2, museli bychom k tabulce zboží přidat atribut id kategorie, který by nám zajistil provázání tabulek zboží a kategorie. V modelu WebML ovšem žádné klíče nedefinujeme z důvodu nezávislosti na konkrétním databázovém systému. Cizí klíč totiž není z hlediska konceptuálního modelu logickou součástí entity zboží, ale je definován pomocí vazby, jejíž implementace se může v různých databázových systémech lišit. Pokud se ale rozhodneme, že v naší aplikaci použijeme relační databázi, budou z modelu při generování datové struktury automaticky vygenerovány i atributy cizích klíčů. Při vyskytnutí vztahu „1,N : 1,N“ (jedna instance první entity má vztah s více instancemi druhé entity a naopak ) se automaticky generuje vazební tabulka, která se bude skládat ze dvou cizích klíčů.

Rovněž vazby mezi entitami jsou ukládány ve formátu XML. Zápis pro entitu zboží by po rozšíření našeho příkladu o vazbu na kategorii zboží vypadal následovně:

Generalizace mezi entitami

Datový model WebML umožňuje sestavovat hierarchie entit, takzvané I–SA hierarchie. Znamená to, že nadřazená entita (super-entity) může mít své podřazené entity (sub-entities). Podřazená entita představuje speciální případ nadřazené entity, dědí od ní všechny atributy a může k nim přidat své specifické atributy. Hierarchie může mít více úrovní. Každá podřízená entita nesmí mít víc jak jednu nadřízenou entitu. Jednoduchý příklad generalizace viz obrázek č. 3:

Obrázek č. 3 – jednoduchý příklad generalizace

Strukturované atributy

Při čtení tohoto článku jistě již někoho napadlo, jak se datový model WebML vypořádá se strukturovanými datovými typy a s kolekcemi strukturovaných datových typů. V praxi to znamená případ, kdy má entita atribut nebo kolekci atributů, které nejsou tvořeny jen atomickou hodnotou, ale mají také svou vnitřní strukturu. Kdo zná diagram tříd (Class diagram) z UML, jistě ví, že v tomto případě se použije operace skládání případně kompozice, kdy se jeden objekt nebo celá kolekce objektů stává součástí (vlastností) jiného objektu.

WebML se s touto problematikou vypořádal pomocí takzvaných slabých entit (weak entities). Princip spočívá v tom, že se k hlavní entitě vytvoří entita, která nemůže existovat, aniž by existovala hlavní entita. Tato entita se propojí s hlavní entitou pomocí vazby s potřebnou kardinalitou.

Klasickým příkladem může být situace, kdy k jedné osobě sledujeme více kontaktních adres. Pokud bychom použili UML, pravděpodobně bychom vytvořili třídu adresa a třídu osoba. Třída osoba by pak jako jeden ze svých atributů měla kolekci příslušných adres (použili bychom skládání). Ve WebML vytvoříme následující strukturu:

strukturované atributy
Obrázek č. 4 – realizace strukturovaného datového typu

Příklad návrhu datového modelu WebML

Jako shrnutí předešlého textu zde bude uveden příklad návrhu datové struktury elektronického obchodu. Tento příklad bude velice jednoduchý a neúplný a měl by sloužit především k objasnění toho, jak se vytváří datový model ve WebML a ne jako obecný návod pro tvorbu datové struktury elektronického obchodu.

Jaké entity se budou vyskytovat v našem systému, musíme zjistit ve fázi specifikace a sběru funkčních požadavků na aplikaci. Tato fáze je nedílnou a velice důležitou součástí všech metodologií analýzy a návrhu SW. Rovněž WebML ji definuje jako úvodní fázi celého procesu vývoje internetové aplikace. Na základě rozhovorů, konzultací se zákazníkem a vlastních zkušeností sestavíme seznam všech možných entit, které v aplikaci předpokládáme, a postupem času tento seznam upravujeme (některé entity přidáváme, některé rušíme). K jednotlivým entitám postupně přidáváme identifikované atributy a vazby, až vznikne výsledný datový model.

Budeme předpokládat, že prodáváme zboží, které je organizováno do kategorií. Kategorie jsou uspořádány v hierarchii. Zboží si objednává jen ten zákazník, který se zaregistroval. Ke každému typu zboží se může diskutovat v jednoduchém diskusním fóru. U zboží sledujeme kód, název, cenu, sazbu DPH, popis a libovolné množství obrázků. Konceptuální datový model by mohl vypadat následovně:

datový model elektronického obchodu
Obrázek č. 5 – výsek datové struktury elektronického obchodu

Zákazník může vytvořit 0 až N objednávek. Každá objednávka se skládá z jedné až N položek, které jsou provázány s určitým druhem zboží a udávají, kolik kusů daného zboží se objednává a za jakou cenu (ceny se v čase mění). Speciální typ zákazníka představuje právnická osoba, u které navíc sledujeme IČO a DIČ. Zboží patří vždy do jedné kategorie. Kategorie může a nemusí mít podkategorie. Byla zde použita vazba entity na sebe samu. (Tímto způsobem se obvykle modeluje hierarchie.) Ke každému zboží dále ukládáme diskusní příspěvky, které jsou opět organizovány hierarchicky. V databázi budeme mít k dispozici také číselník DPH. Ke každému zboží můžeme ukládat libovolné množství fotografií. (Zodpovědět otázku, zda je vhodné ukládat fotografie jako Blob položku, není cílem tohoto článku.) Datová struktura není úplná a použity byly pouze základní atributy. V reálu bychom datovou strukturu upřesnili podle požadavků zákazníka.

Z modelu můžeme pomocí CASE nástroje vygenerovat datovou strukturu podle potřeby pro konkrétní databázový systém. Pro libovolnou relační databázi by byla ke každé entitě automaticky vygenerována relační tabulka s příslušnými atributy. Tabulky by byly dále doplněny o primární a cizí klíče podle stanovené jmenné konvence.

Derivation model: WebML – OQL

Jako doplnění datového modelu WebML se vytváří takzvaný Derivation model (vhodný český název se mi nepodařilo nalézt). Hlavním cílem tohoto modelu je:

rozšířit entity o tzv. dopočitatelné atributy, které nejsou explicitně ukládány v databázi
odvodit nové entity a vztahy od již existujících entit a vztahů

K tomuto účelu slouží poměrně jednoduchý dotazovací jazyk WebML – OQL. Kdo zná alternativu k SQL v objektových databázích – OQL, nebude tímto jazykem vůbec zaskočen. Výhodu OQL představuje jednoduchá transformace například právě do jazyka SQL. Při odvozování vytváříme takzvané odvozovací dotazy. Pokud použijeme CASE nástroj WebRatio, máme k dispozici pomocníka, takže OQL nemusíme umět.

Princip derivation modelu se velice podobá vytváření pohledů (views) v relačních databázích. Vytváříme různé pohledy na datovou strukturu odvozením od struktury, která je explicitně uložena v databázovém systému. V podstatě datovou strukturu rozšiřujeme bezpečným způsobem o redundantní data. Jednotlivé dotazy OQL jsou přímo převoditelné jako pohled například do databázového systému Oracle.

Odvozování probíhá ve třech oblastech:

Odvozování atributů – typickým příkladem může být doplnění entity objednávka o atribut „celková cena objednávky“, který se vypočte jako suma součinů počtu a ceny zboží ze všech položek objednávky.
Odvozování entit – jedná se o pohledy na entitu, kdy vybíráme pouze ty instance dané entity, které vyhovují určité podmínce. Příkladem může být pohled na entitu „zákazník“, kdy nás zajímají pouze zákazníci, kteří mají sumu objednávek větší než určitou částku. Jiný příklad odvozené entity může být také nejprodávanější zboží v e-shopu.
Odvozování vazeb – při odvozování vazeb se může spojit více existujících vazeb do vazby jedné, nebo můžeme vazby nějakým způsobem omezit. Příkladem spojení vazeb může být vazba mezi položkou objednávky a kategorií zboží, která se odvodí z vazby mezi položkou objednávky a zbožím a z vazby mezi zbožím a kategorií zboží. Omezením vazby může vzniknout například vazba mezi kategorií zboží a nejprodávanějšími výrobky v kategorii.

Závěr

Datové modelování v metodologii WebML se velice podobá konceptuálnímu modelování pomocí ER diagramů nebo Class diagramů. Přesto se zde nacházejí určité rozdíly, které by mohly někomu vadit (mně osobně nejvíce vadí opačné zapisování kardinalit k entitám oproti ERD nebo Class diagramům). Kromě derivačního modelu a jazyka WebML-OQL nepřináší WebML v podstatě nic nového. Datový model WebML ovšem představuje základ pro tvorbu hypertextového modelu, který již v klasických metodologiích obdobu nemá. S hypertextovým modelem a se způsobem, jak je propojen s datovým modelem, se seznámíme v některém z dalších článků.