Každý, kdo vyrábí nebo používá libovolné počítačové programy, obvykle narazí na tentýž problém: jak je nějaký objekt, např. pracovník Novák, chorobopis, mapa apod. v programu reprezentován. Řeknete si, že jako data. To je zřejmě pravda, je však třeba mít po ruce návod, jak jsou ta data strukturovaná a jak je máme přesně interpretovat.

Skutečnost může být ještě složitější. Data se nějak tváří pro uživatele programu a nějak jinak pro vlastní program, který s nimi pracuje. Uživateli se mohou jevit jako dvourozměrná tabulka A, ale někde uvnitř informačního systému jsou třeba uložena pomocí dvou tabulek B a C spolu s návodem, jak vytvořit tabulku A. Např. řádek v tabulce A obsahuje data o pracovníkovi jménem Novák, včetně úkolu, který řeší, jakou v něm má funkci, kdo úkol vede apod. Ve skutečnosti však může jít o dva řádky, přičemž jeden je z B (popisuje Nováka) a druhý z C (popisuje úkol, který Novák řeší)

Takto lze jít v různých reprezentacích až někam na magnetický disk, kde bychom zjistili, že řádky tabulek A a B jsou uspořádány jako záznamy v sektorech na disku a že k nim ještě existují nějaká další, pomocná data, která urychlují přístup do A i B.

Podobně lze jít i od tabulek směrem k objektům, které reprezentují. Mezi skutečného Nováka a řádek tabulky, který ho reprezentuje můžeme vložit abstrakci - typ entity PRACOVNÍK a entitu Novák. Ta se bude od skutečného Nováka lišit tím, že je charakterizována jenom několika vlastnostmi skutečného Nováka, např. jménem, rodným číslem, datem narození apod. Hodnoty těchto vlastností se reprezentují pomocí dat.

Všechny fáze uvedené úvahy měly něco společného. Vždy se vytvářel jistý model. Těch modelů bylo hned několik, podle toho na jaké úrovni abstrakce se člověk na skutečný objekt (řekněme Novák) díval.

V tuto chvíli si řeknete - aha, zmíněný řádek tabulky je databázový model Nováka, stejně jako je třeba papírový Betlém papírovým modelem skutečného Betléma nebo Petřínská věž ocelovým modelem skutečné Eiffelovky. Bohužel, tak tomu není. Terminologie databází je zrovna v této oblasti na hony vzdálená našemu chápání modelu. Databázový model totiž není model (v běžném slova smyslu). Je to nástroj určený modelování. Např. relační databázový model je aparát umožňující popisovat a konstruovat relace. Výsledkem modelování, tj. použití daného aparátu, ovšem zase nevznikne žádný model, nýbrž schéma relační databáze. Tedy PRACOVNÍK(JMÉNO, RODNÉ_ČÍSLO,DATUM_N) může být schématem jedné relace z nějakého rozsáhlejšího schématu relační databáze.

Vlastní relace obsahující (kromě dalších) čtveřici údajů o Novákovi tvoří část relační databáze. Vztah jedné konkrétní relace k jejímu schématu je asi takový, jako vztah proměnné a hodnoty, kterou obsahuje. Tedy schéma relace PRACOVNÍK je jakási relační proměnná daného typu.

Nedávno se v jednom časopise zmiňovali, kdo má tuto terminologii na svědomí. Uvedené pojetí databázového modelu prý prvně použil slavný databázista C.J. Date v jedné ze svých prvních knih.

Jaké jsou databázové modely? Do nedávna byly tři: síťový, hierarchický a relační. Ty první dva u nás už moc neznáme. Stručně řečeno, pracovalo se záznamy, které se spojovaly do grafových struktur, lidově řečeno - sítí. Např. jsou-li ODDĚLENÍ, resp. PRACOVNÍK jména typů záznamů o odděleních, resp. pracovnících, pak dvojice < ODDĚLENÍ, PRACOVNÍK> může tvořit hranu (grafu) ve schématu síťové databáze. Záznam o oddělení Technické spolu se seznamem záznamů pracovníků, kteří v něm pracují může tvořit část síťové databáze.

Jaký je rozdíl mezi databázovým a datovým modelem? V používané terminologii se mezi těmito pojmy příliš nerozlišuje. Můžete se setkat i s relačním datovým modelem, přičemž jde stále o totéž. Pojem “datový” je však obecnější než databázový. Jde-li o speciální případ datových struktur, kterými databáze bezesporu jsou. Je však vhodnější hovořit o databázových modelech.

Od počátku 90. let se hovoří o objektových modelech. Jejich hlavním nástrojem je pojem objektu. Nepoužívá se tu ani “databázový” ani “datový”. Snad proto, aby se data odlišila od objektů, které mají svou identitu, přičemž nemusí nést žádná data. Hezkým paradoxem je, že o kousek níže, na úrovni implementace, jsou i objekty vyjádřeny pomocí dat.

Objektové modely jsou charakteristické ještě jednou zvláštností. Není totiž pouze jeden objektový model. Těch je asi tolik, kolik existuje výrobců systémů řízení objektových databází. A to nemluvím o teoreticích, kteří si navrhli své vlastní objektové modely.

V tradičním světě databází jsou naopak zmíněné tři databázové modely jedinečné. Ten síťový byl navržen skupinou odborníků a konstituován ve zprávě CODASYL z r. 1972, hierarchický vznikl vývojem v druhé polovině 60. let. Relační je výmyslem Dr. Codda, který jej publikoval v časopise CACM v r. 1971. Namítnete, že v relačních databázích se používá pojem tabulka a ne relace. Ano, to je pravda, jde však o rozdíly, které potřebují trochu hlubší vysvětlení. Takže o tom někdy příště.

Pojetí databázového modelu jako nástroje lze použít i v dalších oblastech informačních technologií. Zmínili jsme se o typu entity a entitě. Jde zase o jisté nástroje modelování, známé jako konceptuální modely. Tím nejznámějším je E-R model, na který také dojde v našem seriálu. Výsledkem modelování na této úrovni je konceptuální schéma. Abstraktní objekty (jako např. entita Novák) tvoří informační bázi.

Jak databázové, tak konceptuální modely jsou vlastně jisté jazyky. Použijeme-li programovací jazyk, vznikne program, použijeme-li jazyk - databázový model, vznikne schéma databáze. Vedle formálních prostředků, jak schéma zapisovat (syntaxe), jsou vybaveny i sémantikou, která do jisté míry vyjadřuje, co dané schéma vlastně znamená.

Přiznejme, že jde o prostředky jednoduché a z hlediska sémantiky dosti chudé. O čem přesně nějaká databáze pojednává, to vše se nevyčte pouze z jejího schématu, ale z další dokumentace aplikačního systému. Takže pozor. Abyste mohli klást požadavky na databázi, je nutné minimálně znát odpovídající databázové schéma. Další informace poskytne příslušné konceptuální schéma. Závisí ovšem na složitosti aplikace. U některých databází (pojišťovna, medicína, účetnictví apod.) musím ještě dokonale znát oblast aplikace a všechna schémata mi pomohou jen částečně.

Na závěr už jen stručně. Nejde jen o databáze. Celá informatika je samé modelování. Nejtěžší je zařídit, aby si uživatel rozdíl mezi modelem a skutečností skoro neuvědomoval, což se už někdy docela daří. Možná, že to však není ani nutné, ani žádoucí.