WebML - datovΘ modelovßnφ
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).
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":
<ATTRIBUTE id="kod" type="String"/>
<ATTRIBUTE id="nazev" type="String"/>
<ATTRIBUTE id="popis" type="Text"/>
<ATTRIBUTE id="cena" type="Float"/>
<ATTRIBUTE id="zaruka" type="Integer"/>
<ATTRIBUTE id="novnika" type="Boolean"/>
</ENTITY>
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.
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).
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∞:
<ATTRIBUTE id="kod" type="String"/>
<ATTRIBUTE id="nazev" type="String"/>
<ATTRIBUTE id="popis" type="Text"/>
<ATTRIBUTE id="cena" type="Float"/>
<ATTRIBUTE id="zaruka" type="Integer"/>
<ATTRIBUTE id="novnika" type="Boolean"/>
<RELATIONSHIP id="zbozi_na_kategorii" to="kategorie" inverse="kategorie_na_zbozi" minCard="1" maxCard="1"/>
</ENTITY>
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:
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∞:
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∙.