![]() |
![]() |
E-R model
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.
<seznam dílů seriálu> <COMPUTERWORLD> |