Hned ·vodem je t°eba °φci, ₧e nejde o jeden konceptußlnφ model, ale spφÜe o rodinu model∙. V roce 1976, kdy pan P.P.P.Chen publikoval sv∙j Φlßnek o E-R modelu v Φasopise Information Systems, z°ejm∞ Ülo opravdu o jeden nßstroj. Od tΘ doby se vÜak tohoto prost°edku chopilo mnoho lidφ, kte°φ ho jednak zdokonalovali, tj. p°idßvali k n∞mu dalÜφ konstrukty, jednak ho zjednoduÜovali a dokonce i m∞nili jeho grafickou podobu. Tak₧e - dnes u₧ mßlokdo vφ, jak vlastn∞ p∙vodnφ E-R model vypadal, a to se dnes pokusφme trochu napravit.

E-R model je vÜudyp°φtomn². S rozÜφ°enφm nßstroj∙ pro poΦφtaΦovou podporu anal²zy a nßvrhu informaΦnφch systΘm∙ CASE se E-R model rozÜφ°il tak, ₧e se v tΘto oblasti stal de facto standardem. Dokonce jsou na n∞m zalo₧eny i objektov∞-orientovanΘ metodologie (nap°. OMT).

ZaΦn∞me vÜak od zaΦßtku. Chen nenadepsal sv∙j Φlßnek ôThe Entity-Relationship Model - Toward Unified View of Dataö nßhodou. Opravdu Ülo o unifikujφcφ pohled na r∙znΘ datovΘ struktury bez ohledu na to, jak jsou implementovßny. Vφme, ₧e modelovßnφm vznikne schΘma. Zde jde o konceptußlnφ schΘma, tj. popis na ·rovni koncept∙, nikoliv dat. E-R model je tedy konceptußlnφ model. Jeho role v souvislosti s informaΦnφmi systΘmy je dvojφ. Jednak s nφm popφÜeme reßln² sv∞t, jednak se z konceptußlnφho schΘmatu odvφjφ popis systΘmu na ni₧Üφ, nap°. databßzovΘ ·rovni.

Obr. 1 Role konceptußlnφho modelovßnφ

V obvyklΘ situaci je dßno relaΦnφ cφlovΘ prost°edφ, tj. z konceptußlnφho schΘmatu v E-R modelu se odvozuje schΘma relaΦnφ databßze (obr. 1). Transformace 2 se dnes d∞lß v∞tÜinou automaticky. Lze tedy napsat algoritmus, kter² ke konceptußlnφmu schΘmatu vytvo°φ schΘmata relacφ, nap°. ve form∞ CREATE TABLE p°φkaz∙ v SQL.

Dnes nßs bude spφÜe zajφmat transformace 1, kdy vlastn∞ jist²m mentßlnφm pochodem zobrazujeme jistΘ znalosti o reßlnΘm sv∞te, kterΘ jsou d∙le₧itΘ pro aplikaci, do konstrukt∙ E-R modelu.

Ji₧ z nßzvu E-R modelu je patrnΘ, ₧e repertoßr jeho konstrukt∙ bude zalo₧en na pojmech entita a vztah. N∞kdo °φkß mφsto vztah relace. Vystavuje se tak problΘm∙m zßm∞ny s relacφ v relaΦnφm databßzovΘm modelu. NedoporuΦuji to. Navφc relationship opravdu znamenß spφÜe vztah, ne₧ matematick² pojem relace.

Zapome≥me r∙znΘ filosofickΘ definice entity. Entita v databßzovΘ komunit∞ je popsateln² (odliÜiteln² od okolφ) a jednoznaΦn∞ identifikovateln² objekt. Dr. Ullman, slavnß postava informatiky, mß pro to hezk² p°φklad. Mravenec, aΦ docela dob°e popsateln², nenφ entita (rozum∞j databßzovß). Nemß nic, co by se podobalo rodnΘmu Φφslu Φi n∞jakΘmu jinΘmu identifikßtoru. T∞₧ko rozliÜφme v mraveniÜti dva mravence, nato₧ v databßzi.

Entity jsou pouhΘ abstrakce skuteΦn²ch objekt∙. Popisujφ se pomocφ atribut∙. Atribut (Φi charakteristika nebo vlastnost) danΘho typu p°i°azuje ka₧dΘ entit∞ hodnotu, o kterΘ se p°edpoklßdß, ₧e je ji₧ p°φmo reprezentovatelnß pomocφ dat. Nap°. KINO (obr. 2) bude oznaΦovat typ entit - kin, kterß jsou charakterizovatelnß atributy JM╔NO, ADRESA, JM╔NO_V (vedoucφ). Jejich hodnoty mohou b²t typu STRING. VÜimn∞te si, ₧e jde o velmi nep°esn² popis. I rozhledna Pet°φnskß v∞₧ by byla popsatelnß dan²mi atributy. V₧dy musφ existovat n∞kdo, kdo rozhodne, zdali n∞jakß entita je danΘho typu nebo ne.

Obr. 2 Atributy entity

Jak je v informatice obvyklΘ, rozliÜujeme mezi typem a jeho instancφ. KINO je typ, kino Mφr ve StraÜnicφch m∙₧e b²t instancφ - entitou typu KINO. Namφtnete, ₧e jste se setkali s pojetφm, ₧e entita je KINO a instancφm se °φkß v²skyty entity. Je to mo₧nΘ, ale ... . Rad∞ji ne.

Typ entity je takov² kontejner, kter² vlastn∞ obsahuje n∞co, co bylo, je a bude. Jist∞ se v °ad∞ p°φpad∙ vystaΦφ s p°φtomnostφ. KINO obsahuje souΦasnß kina nap°. v dosahu informaΦnφho systΘmu. Entity filmy typu FILM vÜak ji₧ p°ib²vajφ, tak jak vznikajφ novΘ filmy.

Vztahy mezi entitami lze takΘ kategorizovat do typ∙. Nap°. mezi typy entit KINO, KOPIE_F, P┘J╚OVNA lze definovat typ vztahu K_K_P (nebo Objednßvka) oznaΦujφcφ fakt, ₧e kino si objednßvß kopii filmu u danΘ p∙jΦovny. JednotlivΘ vztahy jsou pak trojice entit. Vztahy mohou mφt takΘ atributy. V naÜem p°φkladu to m∙₧e b²t nap°. DATUM_N, tj. datum, do kdy mß b²t kopie vrßcena.

Situaci, tj. konceptußlnφ schΘma, lze znßzornit tzv. E-R diagramy, jako vidφte na obr. 3.

Obr. 3 Chenovo E-R schΘma (bez atribut∙)

Jde o p∙vodnφ Chenovo znaΦenφ. Zb²vß vysv∞tlit dvojit² rßmeΦek oznaΦujφcφ tzv. slab² entitnφ typ, co₧ znamenß, ₧e jde o existenΦnφ zßvislost jeho entit na jin²ch entitßch. Opravdu, k existenci n∞jakΘ kopie je nutn² film. Zßvislost je zde dokonce i identifikaΦnφ. ╚φslujeme-li kopie 1, 2, ..., je nutnΘ p°idat i jmΘno filmu. ZnaΦenφ M, N, P znamenajφ kardinality vztah∙. Pro typ vztahu je_z se kardinality oznaΦujφ 1:N, tj. k jednomu filmu existuje vφce kopiφ, k jednΘ kopii je jeden film. SlabΘ typy entit modelujφ povinnΘ Φlenstvφ ve vztahu. Implicitn∞ tedy kardinality znamenajφ nepovinnΘ Φlenstvφ. Nap°. jsou p∙jΦovny, kterΘ nic nep∙jΦujφ, kina, kterß zrovna nic nehrajφ apod.

V souΦasn²ch CASE nßstrojφch jsou Φasto k dispozici jinß grafickß znßzorn∞nφ. Nap°. v CASE ORACLE m∙₧ete vid∞t znaΦenφ jako na obr. 4.

Obr. 3 E-R schΘma v CASE ORACLE (bez atribut∙)

P°eruÜovanß Φßra s jednoduch²m koncem oznaΦuje 1 a nepovinnΘ Φlenstvφ, nep°eruÜovanß Φßra konΦφcφ ôvranφ nohouö znamenß ôvφceö (N) a povinnΘ Φlenstvφ. Sprßvn∞ usoudφte, ₧e ka₧dß kopie se musφ n∞kde hrßt. Je to divnΘ, ale schΘma to tvrdφ. LΘpe °eÜeno, jde o poselstvφ projektanta, kter² tuto situaci zjistil a poctiv∞ zaznamenal (nebo se spletl). ╪ada Φtenß°∙ konceptußlnφch schΘmat chybuje v tom, ₧e je neumφ Φφst. Stßle toti₧ konfrontujφ p°eΦtenß fakta s vlastnφ zkuÜenostφ. A to se n∞kdy nemusφ vyplatit. AΦ jednoduch², p°esto je E-R model dost p°esn² (formßlnφ) jazyk.

Kdy₧ u₧ jsme u CASE ORACLE, jeho E-R model p°ipouÜtφ pouze binßrnφ (zmizely kosoΦtverce) a dokonce pouze 1:N typy vztah∙. Nßzev typu vztahu je rozd∞len ve dva navzßjem ôinverznφö nßzvy. Dobrß, ale nenφ to p°φliÜ omezenΘ? Je a nenφ. Na jednΘ stran∞ to trochu omezuje v p°irozenΘm chßpßnφ reality, na druhΘ stran∞ se binßrnφ typy vztah∙ hezky Φtou - viz ôKINO hraje FILMyö apod. Navφc platφ, ₧e co jde vyjßd°it v obecnΘm E-R, lze v binßrnφm (i kdy₧ trochu jinak) takΘ. N∞kdy °φkßm, ₧e se oba jazyky k sob∞ majφ jako Assembler a vyÜÜφ programovacφ jazyk.

Stihli jsme pouze zjednoduÜenφ E-R. Existujφ i rozÜφ°enφ, jako jsou hierarchie typ∙ entit, vytvß°enφ agregovan²ch (slo₧en²ch) typ∙ entit, zavßdφ se vφcehodnotovΘ atributy atd. O tom vÜak n∞kdy jindy.