Hlavní práce3615_xjanm89.pdf, 582.4 kB Stáhnout

(1)

Vysoká škola ekonomická v Praze

Fakulta informatiky a statistiky

Katedra informačních technologií

Student : Martin Janů

Vedoucí bakalářské práce : Ing. Dušan Chlapek Recenzent bakalářské práce :

TÉMA BAKALÁŘSKÉ PRÁCE

Porovnání objektových databázových systém ů

ROK : 2006

(2)

Prohlášení

Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.

V Praze dne 21.08.2006 ... ...

podpis

(3)

Děkuji Ing. Dušanu Chlapkovi, vedoucímu bakalářské práce, za odborné vedení práce, cenné rady, připomínky a podněty.

(4)

Abstrakt - č esky

Hlavním cílem práce je najít požadavky kladené na funkcionalitu objektového databázového systému, podle kterých porovnám některé komerční systémy dostupné na trhu.

Analýza nabízených vlastností může sloužit jako podklad pro výběr, jestliže jsme se rozhodli použít objektovou technologii. Podpůrnými cíli je srovnání objektového a relačního datového modelu a vymezení oblastí, do kterých je nasazení objektových DBS vhodné.

Při stanovování kritérií budu vycházet z podpůrných cílů. Objektový datový model je značně odlišný od relačního a proto objektové DBS systémy musí zajistit některou požadovanou funkcionalitu jiným způsobem než relační konkurenti. Oblasti nasazení ovlivňují charakter aplikací, pro které jsou databáze určeny.

Výsledkem práce je vytvoření přehledu o objektových DBS, jejich porovnání a identifikace přínosů a bariér rozšíření.

První část porovnává přístupy k elektronickému ukládání dat a vytváří koncept pro pochopení postavení objektových databázových systémů na trhu. Součástí je porovnání relačního a objektového datového modelu, podrobněji jsou zde vysvětleny principy objektového modelu. Aby bylo možné stanovit si kritéria, je třeba shrnout požadavky, které jsou kladeny na funkcionalitu objektového DBS. Existují dva druhy zdrojů. První tvoří teoretická práce manifest ODBMS, druhý charakter prostředí, ve kterém se objektové DBS nasazují. Protože důležitým faktorem úspěchu je podpora standardů, popíšu standard ODMG.

Druhá část stanovuje kritéria hodnocení a porovnává produkty. Vychází ze tří hlavních metrik, které jsou v této oblasti důležité – výkon, škálovatelnost a podpora vývoje aplikací. V porovnání je zařazeno několik komerčních produktů a pro zajímavost i jedno open-source řešení. Produkty jsou stručně představeny. Podrobněji se zaměřím na architekturu systému, perzistenci objektů a způsob implementace transakčního zpracování. Cílem je najít vlastnosti, podle kterých se nejvíce odlišují, protože nejvíce ovlivní rozhodování při výběru. V kapitole porovnání uvedu výsledné hodnoty do tabulky a zhodnotím výsledky práce.

Práce podává informace o oblasti objektových DBS, jejich výhodách a omezeních. Může sloužit jako podklad pro firmu, jestliže vybírá vhodný objektový databázový systém. Informace mohou použít IT-manažeři, systémoví integrátoři, některé části i programátoři.

(5)

Abstrakt - anglicky

The main aim of this work is to find out requests on object oriented database system functionality and compare several commercial ODBMS’s according to these requests. Feature analysis can be used as a background when we evaluate an ODBMS. The first support aim is to compare relational and object data model, the second support aim is to define areas that are suitable for object databases implementation.

The selected criteria are based on support aims. Object data model is far different from relational data model. Therefore object DBS must ensure needed functionality in a different manner in comparison to the relational competitors. Suitable areas for ODBMS implementation determinate character of applications, for that are ODBMS made.

As a result, there is an overview about ODBMS‘s. There is a comparison of several products and key findings about benefits and barriers of use.

First part of the work compares the approaches of electronic data saving and gives a background for understanding ODBMS‘s position in the current market. Comparison of relational and object model is included. First chapter also explain object model principles. On order to set up the criteria, it is necessary to summarize requests on ODBMS functionality.

There are two kinds of resources. First is a theoretical work Object Oriented Database System Manifesto, second is the implementation environment. There is the ODMG standard described, because support of standards is important success factor.

Second part sets criteria and compares products. It comes from three main metrics, that are important – performance, scalability and application development support. Comparison includes several commercial products and one open-source solution. Whole products are describes briefly. I focus more on architecture, object persistence and concurrency control. The aim is to find out the differeces, because these features are most important when we evaluate an ODBMS. Chapter Comparison figures a table with all chosen features. I describe the results.

This work gives information about object oriented database systems, their benefits and constraints. It can be used as a background when we evaluate an ODBMS. Information can be used by IT - managers, system integrators and some parts by programmers.

(6)

Osnova

ABSTRAKT - ČESKY ... 4

ABSTRAKT - ANGLICKY... 5

OSNOVA... 6

ÚVOD... 9

1 VZNIK DBS A JEJICH SROVNÁNÍ PODLE DATOVÝCH MODELŮ... 11

1.1 Přístupy k elektronickému zpracování dat ... 11

1.1.1 Klasické zpracování dat ... 11

1.1.2 Databázové zpracování dat ... 11

1.2 Typy datových modelů... 12

1.2.1 Síťový datový model ... 12

1.2.2 Hierarchický datový model... 13

1.2.3 Relační datový model ... 14

1.2.4 Objektový datový model... 15

1.2.4.1 Základní objektové principy... 15

1.2.4.2 Objektově – relační datový model... 17

1.2.4.3 Čistě objektový datový model ... 17

1.2.5 Ostatní datové modely ... 18

1.2.6 Porovnání RDBMS, ORDBMS, OODBMS ... 18

1.2.7 Výhody a nevýhody RDBMS, ORDBMS a OODBMS... 19

1.3 Shrnutí ... 21

2 POŽADAVKY NA OODBMS ... 22

2.1 Manifest objektově orientovaných databázových systémů... 22

2.2 Požadavky dané implementačním prostředím... 23

2.2.1 Způsoby použití OODBMS v IS... 24

2.2.2 Příklady nasazení ... 24

2.3 Shrnutí ... 25

3 POUŽÍVANÉ STANDARDY... 27

3.1 Standard ODMG 2.0 ... 27

3.1.1 Objektový datový model... 28

3.1.2 Definice objektů – ODL, OIF ... 29

3.1.3 Dotazovací jazyk OQL ... 29

3.1.4 Napojení na programovací jazyky ... 30

3.1.4.1 OGMG a Java... 30

3.1.5 Shrnutí ... 31

(7)

4 KRITÉRIA HODNOCENÍ ... 32

4.1 Architektura... 33

4.2 Perzistence objektů... 36

4.3 Transakce a konkurenční přístup ... 37

4.3.1 Konkurenční přístup k datům ... 37

4.3.1.1 Two Phase Locking protocol (2PL) ... 38

4.3.1.2 Multi version concurrency control (MVCC) ... 39

4.3.1.3 Porovnání přístupů 2PL protocol a MVCC ... 39

4.3.2 Zotavení databáze po neúspěšném proběhnutí transakce... 39

4.3.3 Shrnutí ... 39

4.4 Podporované standardy ... 40

4.5 Podpora ze strany dodavatele... 40

4.6 Ostatní ... 40

5 JEDNOTLIVÉ DATABÁZOVÉ PRODUKTY... 41

5.1 Komerční systémy ... 41

5.1.1 Gemstone Object Server/S... 41

5.1.1.1 Architektura... 41

5.1.1.2 Perzistence objektů... 42

5.1.1.3 Transakce a konkurenční přístup... 43

5.1.1.4 Dotazovací jazyk ... 43

5.1.1.5 Shrnutí ... 44

5.1.2 Versant... 44

5.1.2.2 Persistence objektů... 44

5.1.2.5 Srhnutí ... 45

5.1.3 Progress Software – ObjectStore 6.3 ... 45

5.1.3.5 Shrnutí ... 49

5.1.4 Caché 5.2 ... 49

5.1.4.3 Transakce ... 51

5.1.4.5 Shrnutí ... 51

5.2 Open-source ODBMS... 51

5.2.1 Db4object 5.0... 51

5.3 Tabulka porovnání ... 52

6 POROVNÁNÍ OBJEKTOVÝCH DATABÁZOVÝCH SYSTÉMŮ... 54

6.1 Architektura... 55

6.2 Perzistence objektů... 56

(8)

6.3 Transakce ... 56

6.4 Standardy ... 57

6.5 Podpora ze strany dodavatele... 57

6.6 Ostatní ... 58

6.7 Shrnutí výsledků porovnání ... 58

6.7.1 Meziskupinové porovnání... 58

6.7.2 Další výhody/nevýhody ODBMS ... 59

6.8 Shrnutí ... 59

ZÁVĚR ... 60

POUŽITÁ LITERATURA... 62

Teorie ... 62

Informace o produktech ... 64

TERMINOLOGICKÝ SLOVNÍK A SEZNAM ZKRATEK... 66

(9)

Úvod

Objektové databázové systémy představují zajímavou alternativu k ostatním databázovým technologiím. Příčiny jejich vzniku můžeme spatřovat ve dvou zásadních faktorech.

Za prvé je to změna implementačního prostředí. S charakterem měnící se ekonomiky na informační společnost a rozvojem informačních technologií roste i množství ukládaných dat v podnikové sféře a mění se jejich charakter. Ačkoliv tato domněnka není nijak prokazatelná a mnozí o ní budou tvrdit, že se jedná o spekulaci, je výsledkem několika vývojových faktorů. Rozvoj počítačově založených informačních systémů především do středních a menších podniků, velké podniky si mohou dovolit zavádět business inteligence aplikace. Logistické firmy, dopravní společnosti nebo energetika zvyšují návratnost vložených prostředků zaváděním on-line sledování distribuční sítě. Prudký rozvoj zaznamenalo elektronické obchodování (e-business). Výsledkem je větší množství ukládaných dat a změna charakteru aplikací.

Druhý faktor souvisí se způsobem vývoje aplikací a je odrazem změn v ekonomice.

Strukturovaný vývoj nebyl vhodný na rozsáhlejší aplikace a v devadesátých letech se začalo prosazovat objektově orientované paradigma. Nejprve se objektově orientovaný přístup prosadil do programovacích jazyků, později i do fáze analýzy a návrhu.

Avšak v oblasti databázových systémů stále výrazně převažuje relační technologie.

Výrobci databázových systémů reagují na potřebu objektového rozšíření dvojím způsobem.

Stávající výrobci relačních systémů přidávají do svých produktů podporu objektově orientovaných principů a vznikají objektově-relační databáze. Druhým způsobem je tvorba čistě objektových systémů, jejichž budovaní začíná úplně od začátku. Je třeba zdůraznit, že jejich vývoj těchto systémů začal v osmdesátých letech, a v současnosti jsou na vysoké úrovni.

Ve své bakalářské práci se zabývám čistě objektovými DBS. Představují velmi vyspělou technologii, která se ale uplatňuje jen velmi pomalu. Budu hledat přínosy a bariéry rozšíření.

Hlavním cílem práce je najít požadavky kladené na funkcionalitu objektového DBS, podle kterých porovnám systémy dostupné na trhu. Výsledky mohou sloužit jako podklad pro výběr, jestliže jsme se rozhodli použít objektovou technologii. Podpůrnými cíli je srovnání objektového a relačního datového modelu a vymezení oblastí, do kterých je nasazení objektových DBS vhodné.

Při stanovování kritérií budu vycházet z podpůrných cílů. Objektový datový model je značně odlišný od relačního a proto objektové DBS systémy musí zajistit některou požadovanou funkcionalitu jiným způsobem než relační konkurenti. Oblasti nasazení ovlivňují charakter aplikací, pro které jsou databáze určeny. Výsledkem práce je vytvoření přehledu o objektových DBS, jejich porovnání a identifikace přínosů a bariér rozšíření.

První část porovnává přístupy k elektronickému ukládání dat a vytváří koncept pro pochopení postavení objektových databázových systémů na trhu. Součástí je porovnání relačního a objektového datového modelu, podrobněji jsou zde vysvětleny principy objektového modelu. Aby bylo možné stanovit si kritéria, je třeba shrnout požadavky, které jsou kladeny na funkcionalitu objektového DBS. Existují dva druhy zdrojů. První tvoří teoretická práce manifest ODBMS, druhý charakter prostředí, ve kterém se objektové DBS nasazují. Protože důležitým faktorem úspěchu je podpora standardů, popíšu standard ODMG.

Druhá část stanovuje kritéria hodnocení a porovnává produkty. Vychází ze tří hlavních metrik, které jsou v této oblasti důležité – výkon, škálovatelnost a podpora vývoje aplikací. V porovnání je zařazeno několik komerčních produktů a pro zajímavost i jedno open-source řešení. Produkty jsou stručně představeny. Podrobněji se zaměřím na architekturu systému, perzistenci objektů a způsob implementace transakčního zpracování. Cílem je najít vlastnosti, podle kterých se nejvíce odlišují, protože nejvíce ovlivní rozhodování při výběru. V kapitole porovnání uvedu výsledné hodnoty do tabulky a zhodnotím výsledky práce.

Předpokládám základní znalost relačních DBS, protože s nimi objektové databáze často srovnávám.

(10)

Práce podává informace o oblasti objektových DBS, jejich výhodách a omezeních. Může sloužit jako podklad pro firmu, jestliže vybírá vhodný objektový databázový systém. Informace mohou použít IT-manažeři, systémoví integrátoři, některé části i programátoři.

(11)

1 Vznik DBS a jejich srovnání podle datových model ů

Nejprve stručně uvedu možnosti elektronického zpracování dat, porovnám objektové databázové systémy s jinými používanými technologiemi a vytvořím tak koncept pro pochopení postavení objektových databázových systémů na trhu. Objektové DBS představují zajímavou alternativu, která si v posledních letech hledá uplatnění na databázovém trhu a naráží na dlouho používané a zakořeněné relační databáze. Cílem kapitoly je osvětlit výhody objektových databází, s kterými by se mohly uplatnit v určitých tržních segmentech.

1.1 P ř ístupy k elektronickému zpracování dat

Data jsou cenným zdrojem každého informačního systému. Existují dva základní přístupy zpracování hromadných dat – klasické a databázové [ŠED], které se liší podle stupně nezávislosti dat a aplikací a mírou vzájemné integrovanosti dat.

1.1.1 Klasické zpracování dat

U klasického zpracování dat se je program zcela svázaný se strukturou souboru. Při tvorbě aplikace je třeba definovat, s jakými daty bude pracovat, naimplementovat ji přesně na vstupní soubory a vytvořit výstupní soubory s pevně danou strukturou.

Z tohoto modelu vyplývá řada problémů[ŠED]:

• Svázanost programů a dat – Pokud je třeba změnit strukturu dat, je třeba změnit i všechny programy, které s ní pracují.

• Redundance dat – Každý program používá svoje soubory a proto mohou být stejné údaje uloženy vícekrát.

• Nekonzistence dat – Může vzniknout tehdy, když se změna promítne jen do některých souborů.

• Izolovanost a roztroušenost dat – V rozsáhlejších informačních systémech jsou data uložena na více místech bez jasných vazeb a v různých formátech. To komplikuje vytváření nových aplikací nad těmito daty.

• Obtížné reporty – Zjištění stavu dat lze provést pouze přes aplikaci, protože zde neexistují dotazovací jazyky jako v databázových systémech.

Klasické zpracování není vhodné pro budování rozsáhlejších informačních systémů. V současnosti lze použít maximálně pro vytváření drobných aplikací s potřebou nízké integrace dat s ostatními. Jedná se o výjimečné případy, ve kterých by bylo vytváření databáze složitější než použít ukládání do datového souboru.

1.1.2 Databázové zpracování dat

Nevýhody souborového uložení dat vedly v 60. letech ke vzniku a prosazení databázového zpracování, které se kromě odstranění nevýhod klasického zpracování snaží ulehčit tvorbu programů tím, že funkcionalitu, jako je řízení přístupu více uživatelů, podpora transakcí, ověření přístupových práv uživatele, definice integritních omezení, vyhodnocování dotazů, atd., zajišťuje databázový systém. Důsledkem je jednodušší vývoj aplikace a vyšší bezpečnost, protože s přenesením této funkcionality na úroveň databáze odpadá nutnost její implementace v aplikaci.

Databázové systémy mají následující vlastnosti [ŠED]:

• Struktury datových souborů jsou odděleny od aplikačních.

• Přístup k datům je možný jen prostřednictvím programů databázového systému.

• Data je možné vyhodnotit jakýmkoliv způsobem, můžeme snadno modifikovat dotazy.

• Je umožněn přístup více uživatelů současně a vyřešena ochrana dat před zneužitím.

(12)

DB, DBMS, DBS

Pojmy vysvětluji na základě skript Databázové systémy [ŠED].

Princip databázového zpracování spočívá ve vytvoření jednoho úložiště dat – databáze (database, DB) s předem navrženou strukturou záznamů. Správný návrh zamezuje, aby se vytvářela redundantní data. Pojem databáze tedy znamená souhrn všech uložených dat. Veškeré programové vybavení zajištující chod databáze tvoří systém řízení báze dat (database management system, DBMS). Ten spolu s databází tvoří databázový systém (database system, DBS).

DB+DBMS=DBS

Aplikace může do databáze přistupovat pouze přes systém řízení báze dat (DBMS).

DBMS zajišťuje definici struktury dat, manipulaci s daty, bezpečnost a integritu dat, zotavení po chybách, transakční zpracování a optimalizaci výkonu DBS.

Zahrnuje prostředky pro práci s daty. Jazyk DDL (data definition language) slouží pro definici struktury dat a jazyk DML (data manipulation language) pro manipulaci s nimi, tj. pro aktualizaci, vložení, výběr dat podle dotazu a mazání dat. V relačních DBS představuje DDL a DML jazyk SQL. V objektových DBS je DDL i DML shodný s programovacím jazykem.

V praxi se někdy používá slovo databáze nesprávně ve dvojím významu. Má představovat obsah databázového systému, ale může znamenat i celý databázový systém.

1.2 Typy datových model ů

Vytvoření struktury databáze je nedílnou součástí vývoje informačního systému. Data reprezentovaná v IS můžeme chápat jako model reality, který odráží, jakým způsobem objekty reálného světa vnímáme. Datový model je souhrn nástrojů pro popis objektů reality, jejich reprezentujících dat, vztahů mezi nimi, sémantiky a integritních omezení. Datové modely, které popisují logickou organizaci dat v databázi, lze rozdělit do třech kategorií – předrelační (síťové, stromové), relační a postrelační (objektově-relační, objektové).

1.2.1 Sí ť ový datový model

Síťový datový model patří historicky mezi nejstarší. Prošel standardizací v roce 1972 na konferenci CODASYL a je popsán ve skriptech Databázové systémy [MER1].

Základem síťového datového modelu jsou vzájemně propojené množiny záznamů. Záznamy jednoho typu jsou obvykle uloženy v jednom souboru. Celá databáze je složena ze dvou hlavních množin. První z nich je množina záznamů (obvykle rozložená do více souborů), druhou z nich je množina spojek, přičemž spojka je zvláštní typ záznamu o dvou položkách, které obsahují fyzické adresy záznamů, které spojují.

Síťový datový model je formální model pro reprezentaci vztahů atributů množiny entit a asociací mezi množinami entit. Tento model je základem běžně používaných databázových systémů na velkých počítačích a představuje souhrn navzájem propojených segmentů tak, že jednotlivé datové struktury vytvářejí síť. Každý segment představuje vstup do této struktury a vlastní propojení je realizováno přes uložené adresy, tzv. spojky. Tento model se tedy sestává z typů záznamů a spojek.

Typ záznamu je souhrn datových položek, přičemž datová položka je nejmenší logickou jednotkou dat. Typy záznamů pak reprezentují množinu výskytů záznamů sestávajících z hodnot datových položek. Množina datových položek, která jednoznačně určuje výskyt záznamu, se nazývá klíč.

[MER]

(13)

Obr. 1. 1. - Síťový datový model, Bachmanův diagram¹, [MER1]

Univerzálnost síťové struktury spočívá v možnosti teoreticky libovolného propojení množiny jejich prvků bez ohledu na jejich úroveň a výskyty. Hlavním cílem programových produktů se síťovou strukturou bylo oddělení množin prvků struktury od množiny jejich vzájemných vazeb (spojek). To umožňuje měnit záznamy o vazbách mezi prvky bez nutnosti jejich změny a naopak.

Síťové databáze jsou dodnes nejrychlejší používané databázové systémy a lze je i v současnosti implementovat do úloh, které zpracovávají velké objemy dat. Většina programovacích jazyků obsahuje knihovny funkcí pro práci s daty organizovaných v síťovém modelu.

Mezi nevýhody patří omezení, že k datům lze přistupovat pouze sekvenčním přístupem (data se zpracovávají postupně po jednotlivých záznamech). Sekvenční přístup sice podporuje zpracování dat v programovacích jazycích, avšak neumožňuje efektivně vyhodnocovat dotazy.

Další nevýhodou je obtížná změna struktury databáze. Síťový model je optimální pro navržení struktury, která se nemění a do které se záznamy jen zapisují. Operace mazání záznamů a změna struktury jsou náročné.

Přestože se síťový datový model hojně implementoval a používal v šedesátých letech 20.stol., nestal se dominantním ze dvou hlavních důvodů. Za prvé, IBM si zvolilo používat hierarchický model do jejich produktů jako např. IMS a DL/I. Druhým důvodem byl nástup relačního modelu, který nemá výše uvedené nedostatky. Největší výhoda síťových a hierarchických databází, velká rychlost, byla s nárůstem výkonu HW smazávána.

1.2.2 Hierarchický datový model

Hierarchický datový model je zvláštním případem síťového datového modelu s jedním podstatným rozdílem, že každý segment je odkazován pouze nejvýše jedním rodičovským.

Výsledkem databáze je strom, ve kterém jsou data uspořádána podle hierarchických stromů (země, stát, hlavní město, město,.. ). V hierarchickém stromu existuje jeden speciální význačný typ záznamu, tzv. kořen. Ostatní typy záznamů se nazývají závislé typy záznamů a jsou ve struktuře hierarchického stromu na nižší úrovni. [MER1]

Hlavním omezení vyplývající z tohoto modelu je možnost znázornit pouze jednoduché vztahy. Rodič může mít více potomků, lze zaznamenat vztah 1:N (rodič-potomek), ovšem nelze vytvořit vztah segmentů N:1 a M:N.

1 Obdélník (segment) reprezentuje záznamy jednoho typu v množině záznamů a čáry se šipkou mezi obdélníky představují spojky jako orientovanou vazbu mezi záznamy.

(14)

Hierarchické databázové systémy nemají schopnost zaznamenat jakoukoliv strukturu objektů z reality, avšak jednoduše zachytí některé její výseky v podobě stromů. Platí pro ně stejné výhody a nevýhody jako pro síťové databáze.

1.2.3 Rela č ní datový model

Vojtěch Merunka [MER1] popisuje relační model ve svých skriptech následovně:

Relační datový model má počátky v roce 1969. Autorem prvních prací byl E. F. Codd, matematik z laboratoře IBM v San José, a prvním prakticky používaným relačním databázovým systémem byl produkt DB2 firmy IBM. Relační datový model se od svých předchůdců (síťového a hierarchického modelu) liší tím, že je důsledně budován na teoretickém základě. Je definována struktura dat a povolené operace nad nimi.

Základní pravidla RDM publikoval Dr. E. F. Codd v článku"A relational model of data for large shared databanks"[COD] následovně:

• RDB důsledně odděluje data, která jsou chápána jako relace, od jejich implementace.

• Přístup k datům je symetrický, tj. při manipulaci s daty se nezajímáme o přístupové mechanismy k datům.

• Pro manipulaci s daty jsou k dispozici dva silné prostředky - relační kalkul a relační algebra

• Pro omezení redundance dat v relační databázi jsou navrženy pojmy umožňující normalizovat relace.

Relační datový model je postaven na matematické definici relace². Doménou rozumíme množinu hodnot stejného datového typu, relace je množina vztahů mezi prvky několika domén.

Relace se uživateli reprezentuje jako dvourozměrná tabulka, ve které záhlaví tvoří názvy vybraných domén, nad kterými je relace definovaná. Každý řádek tabulky odpovídá jedné entitě a každý sloupec obsahuje prvky jedné domény. Atribut pojmenovává doménu použitou v relaci.

Řádky v relaci jsou nezávislé na pořadí, proto je v každé tabulce atribut, který jednoznačně identifikuje každý řádek. Nazývá se primární klíč. Vazbu mezi tabulkami vytvoříme přidáním dalšího atributu, cizího klíče, který odkazuje na primární klíč druhé tabulky. Relační model umožňuje vyjádřit vztahy 1:1 a 1:N. Vztah M:N se vytvoří pomocí vazební tabulky, která obsahuje dva atributy představující hodnoty cizích klíčů. Výhoda relačního modelu spočívá v tom, že i vazby, které při prvním návrhu nepředpokládáme, můžeme do struktury databáze přidat zavedením další vazební tabulky.

Při vytváření logického relačního datového modelu se aplikuje proces databázové normalizace, která spočívá v nahrazování jedné relace více relacemi s jednodušší a regulérnější strukturou. Jejím cílem se odstranit redundantní ukládání dat. V literatuře se uvádí šest pravidel, označených jako normální formy, které by měly být aplikovány, aby byla databáze správně navržena.

Vedle řady komerčních produktů existují i open-source DBS, např. Firebird nebo jednodušší MySQL. Databázové systémy používající relační datový model patří v současnosti stále k nejrozšířenějším. Hlavní výhody relačních DBS souvisí s jejich dlouhodobým nasazením, při kterém prošly silnou standardizací. Staví na pevném teoretickém základě, existují pravidla definující podmínky relačního modelu, pracují s dotazovacím jazykem SQL, který je standardizován, existuje middleware usnadňující vývoj aplikace a existují prostředky pro efektivní návrh datové struktury. Omezením relačních DBS je nižší výkon než u objektových DBS a především obtížnější vývoj aplikace v objektově orientovaném jazyce, protože je třeba mapovat objektové schéma na relační. Tím se prodlužuje celý vývoj systému a zvyšuje se riziko zavedení chyby. Tyto nedostatky se snaží odstranit objektové databázové systémy.

2 Nechť je dán systém Di, 1≤ i ≤ n neprázdných množin, tzv domén. Pak podmnožina kartézského součinu R ⊆ D1 × D2 × … × Dn se nazývá relace stupně n (n-ární relace) nad doménami D1, D2, … ,Dn. Prvky relace R jsou uspořádané n-tice (d1, d2, … ,dn), kde di∈ Di, 1 ≤ i ≤ n.

(15)

RDBS jsou vhodné především pro jednoduše strukturovaná data.

1.2.4 Objektový datový model

Objektový datový model vznikl jako reakce na nedostatky RDBS. S rostoucím výkonem informačních technologií se začaly objevovat nové typy aplikací, které potřebují ukládat data jiného charakteru. Některé aplikace pracují s komplexními (bohatě provázanými) daty, jiné kromě běžného textu potřebují ukládat celé dokumenty, zvukové nebo i obrazové záznamy.

Nové typy aplikací, pro které jsou objektové DBS vhodné[ZSI]:

• Původně byly určené pro CAD (Computer Aided Design) aplikace, ve kterých tvořily úložiště průmyslových návrhů včetně komponent, z nichž byl návrh vytvořen.

• CASE (Computer Aided Systems Engineering) systémy na podporu vývoje SW aplikací.

• Multimediální databáze, v nichž se pracuje s obrázky, zvukovými nebo video daty.

Vznikly z potřeby uchovávat geografická data (geografický informační systém) nebo data z hlasové pošty.

• Kancelářské systémy (OIS – Office Information Systems), ve kterých se pracuje s dokumenty.

• Hypertextové databáze. Hypertext je text, který obsahuje odkazy na jiné místo v dokumentu nebo na jiné dokumenty.

Objektový datový model přináší jiný pohled na data. Data nejsou dána pouze hodnotami seskupených do datových struktur (relací), ale jsou vztažena k objektům, které přímo odpovídají objektům z reality [ZSI].

1.2.4.1 Základní objektové principy

Zakladní objektové principy vycházejí z objektově orientovaného programování.

Objektem reality rozumíme každou entitu, která je jednoznačně identifikovatelná. Každý objekt se vyznačuje vlastní identitou (OID – object identifier), dva objekty se stejnými vlastnostmi jsou navzájem odlišitelné. Příkladem může být objednávka, faktura nebo osoba Jan Novák.

Každý objekt reality má určité vlastnosti, popisující jeho stav, a operace, které s ním můžeme provádět. Pro zachycení vlastností v modelu se používá pojem literál [ATK]. Literál je entita určitého datového typu, která nemá vlastní identitu, odkazujeme se na ni hodnotou. Pro každý datový typ literálu existuje pevně daná množina operací. Při vytváření datového modelu používáme princip abstrakce. Zaznamenáváme pouze vlastnosti a činnosti, které jsou pro funkcionalitu IS důležité.

• Třídy

Objekty seskupujeme do abstraktních popisů zvaných tříd. Třídu můžeme z hlediska OOP chápat jako šablonu pro vytváření objektů. Určuje vlastnosti (v modelu atributy) a operace (metody), které se budou o objektu zaznamenávat. Při uložení objektu vytvoříme instanci příslušné třídy tím, že přiřadíme konkrétní hodnoty vlastnostem třídy. Výsledný objekt představuje kromě takto vložených dat i metody, které přejímá z definice třídy. Ke každé třídě lze vytvořit libovolný počet instancí.

• Identita objektu

Každý objekt má přidělen objektový identifikátor OID (Object Identifier). OID je automaticky vygenerován systémem řízení báze dat při uložení objektu do databáze a je neměnný, i když se změní hodnoty objektu nebo když se obsah databáze přemístí na jiné paměťové médium. Uživatel databáze k OID nemá přístup. V distribuovaných DBS je OID unikátní v celém systému.

Vojtěch Merunka ve svých skriptech [MER1] popisuje možnosti konceptu OID takto:

Vzhledem ke konceptu OID můžeme rozlišovat mezi pojmem rovnost objektu a totožnost objektu (dva objekty se stejnými daty ještě nemusejí být totožné), což relační datový model nedovoluje, neboť identita relačních záznamů je pevně svázána s hodnotami vnitřních složek záznamů. Koncept OID způsobuje, že v objektech není třeba některé jejich datové složky

(16)

rezervovat jako primární klíče, jak je známe z relačních databází, což prakticky znamená, že objektovou databázi není třeba normalizovat způsobem, jak jej známe z relačních databází.

• Komplexní objekty

Na komplexní objekt pohlížíme jako na jeden předmět reálného světa, ale skládá se z dalších objektů. Obsažený objekt může být buď zapouzdřený v rámci komplexního objektu, být jeho částí a dostupný pouze skrze metody komplexního objektu. Druhým způsobem je existence samostatných objektů, na které má komplexní objekt referenci na OID [BRA].

Komplexním objektem může být datová struktura seznam (list), která je složená z primitivních datových typů – čísel nebo textů, anebo entita, která je složená z více objektů. Příkladem druhé možnosti je použití datové struktury kusovník. Kusovník se používá pro výrobky složené z více součástek (propiska se skládá z náplně a plastového obalu, který je tvořen dalšími částmi). Kvůli zachycení vazeb je převedení kusovníku do relační databáze složitější, než uložení v podobě objektů do objektového DBS.

• Rozšiřitelnost datových typů

Rozšiřitelnost předdefinovaných datových typů vychází z potřeby zachytit v databázi další informace související s objektem. Objekty můžeme rozšířit o další data, nebo k nim přidat metody pro práci s daty. Na úrovni aplikace se nerozlišuje mezi použitím systémem nebo uživatelem definovaného typu, pracuje se s nimi stejným způsobem. Objektu můžeme například přidat údaje o době zahájení nad nimi běžící transakce nebo při používání verzování číslo verze [ATK].

Práce s objekty je postavena na třech pilířích – zapouzdření, dědičnosti a polymorfismu.

• Zapouzdření (encapsulation)

Zapouzdření je technika softwarového návrhu, při které jsou data a funkce s nimi pracující spojeny do jedné entity. Data objektu jsou skryta před ostatními objekty a lze k nim přistupovat pouze pomocí metod objektu [ZSI].

Vlastnost zapouzdření zvyšuje míru nezávislosti objektů a zajišťuje konzistenci modelu.

Objekt může změnit implementaci metody při zachování stejného rozhraní, aniž by se musely ostatní objekty změně přizpůsobit. Komunikace přes rozhraní objektu dovoluje přidávat nové objekty s referencemi na stávající. Modularita je vhodná pro budování rozsáhlých aplikací v týmu.

• Dědičnost (inheritance)

Dědičnost dovoluje vytvářet odvozené třídy a využívat existující kód. Jestliže vytváříme odvozenou třídu, rodičovská třída určuje společné vlastnosti a metody, které potomek povinně přejímá. Potomek si může metodu předefinovat nebo vytvořit novou. Dědičnost lze použít, jestliže mezi potomkem a rodičovskou třídu existuje vtah, že „potomek je rodič“, např. běžný účet je účet.

Například běžný účet a termínovaný učet mají několik společných vlastností (majitel, částka, minimální limit, úroky) a můžeme nad nimi provádět stejné operace (vložit peníze, převést peníze, zúčtovat úroky, zrušit účet). Tyto společné vlastnosti zahrnuje rodičovská třída účet. Založením účtu vytvoříme objekt ve třídě běžný nebo termínovaný účet, který převezme vlastnosti z rodičovské třídy.

Rodičovská třída může vytvořit více potomků. Podle toho, jestli je potomek odvozen z jedné nebo více tříd, rozlišujeme dědičnost na jednonásobnou a vícenásobnou. Programovací jazyk Java podporuje jednonásobnou dědičnost. DBMS podporuje typ dědičnosti podle toho, jaký jazyk používá k definici datového modelu.

• Mnohotvárnost (polymorfismus) a pozdní vazba (late-binding)

Polymorfismus souvisí s předchozí vlastností – dědičností. Polymorfismus umožňuje vytvořit stejnojmenné metody pro objekty více tříd. Každá třída obsahuje vlastní implementaci

(17)

metody a objekty z různých tříd reagují jiným způsobem. Například metoda zúčtovat úroky je odlišná pro třídu běžný účet a termínovaný účet.

Polymorfní operace jsou realizovány tzv. pozdní vazbou. Aplikace zvolí dynamicky za chodu aplikace kód metody, který se má použít nad objektem podle toho, do jaké třídy patří.

Podpora objektově orientovaných principů v databázi vyústila ve dva proudy vývoje.

• Evoluční směr, jehož výsledkem jsou objektově-relační DBS vzniklé rozšířením relačních DBS o objektové vlastnosti. V jádře zůstávají stále relační, protože jsou založeny na relačním modelu.

• Revoluční směr, který vede k vývoji čistě objektových databázových systémů. Výsledkem jsou systémy budované úplně od začátku, které jsou postaveny na objektovém datovém modelu.

1.2.4.2 Objektov ě – rela č ní datový model

Informace čerpám z článku Object-Relational Database Systems - The Road Ahead [DEV].

Objektově-relační DBS si ponechávají rysy relačních databází a rozšiřují je o objektové vlastnosti. Data jsou uložena v tabulkách stejně jako v RDBM, ale některé atributy mohou mít rozvinutější datovou strukturu, která se nazývá abstraktní datové typy (ADT). Uživatel si může definovat vlastní datový typ složený z více atributů a příslušných metod určujících chování dat.

ADT odpovídá jednomu sloupci tabulky. Složené datové typy mohou zahrnovat datové typy z jiných tabulek a tím se zaznamená struktura objektu.

Příkladem abstraktního datového typu je typ Adresa, který se skládá z atributů Ulice, Číslo, Město a PSČ. Tento ADT může být použit v tabulce Zaměstnanec, která má atributy Příjmení, Jméno a Adresa.

ORDBMS používají dotazovací jazyk SQL rozšířený o určité objektové vlastnosti.

Poslední standard je z roku 2003, většina objektových vlastností je součástí předcházejícího standardu SQL 3 z roku 1999. SQL 3 podporuje objektové vlastnosti tímto způsobem: dotazy mohou obsahovat vnořené objekty, součástí dotazu může být metoda, dotazy mohou zahrnovat abstraktní datové typy, apod. [SQL]. Cílem rozšíření je podpora objektového modelu v relačních databázích.

Trend přidávání objektových vlastností do relačních DBS je podmíněn vlivem prostředí.

Především je to zájem výrobců relačních DBS. Během několika desetiletí vznikly robustní, trhem ověřené produkty, které si zajišťují konkurenceschopnost podporou objektových principů. V současné době většina produktů stavících na relačním datovém modelu zahrnuje objektové rozšíření. Patří mezi ně Oracle od verze 8, IBM, DB2, Informix, MS SQL Server a další.

Objektově – relační databáze vznikají s minimálními náklady ve srovnání s vývojem objektového DBS, kdy se začíná budovat úplně od začátku.

Hlavní výhodou objektově – relačních databází je tedy nízká cena, komerční objektové databáze stojí v současnosti přibližně dvojnásobek. ORDBS ale zůstává ve svých principech stále relační (je potřeba mapovat objekty do tabulek).

1.2.4.3 Č ist ě objektový datový model

Revoluční směr vývoje vyústil v čistě objektové databáze, které nejsou postaveny na relačním schématu. Vychází ze síťového datového modelu a rozšiřuje jej o práci s objekty podobným způsobem jako v OO programování.

V objektovém datovém modelu jsou data uložena ve formě objektů, které jsou sdruženy podle podobných vlastností do jednotlivých tříd. Třída popisuje zaznamenávané vlastnosti objektu, objekty jsou konkrétní hodnoty těchto vlastností. Každý objekt má určité atributy, které představují jeho vlastnosti, a metody, které popisují dostupné operace. Tento způsob pohledu na data je nejvíce podobný realitě.

(18)

Výhodou objektového datového modelu je možnost přímého vyjádření modelované reality v databázi. Není nutné provádět mezikroky pro převod objektů do relačního schématu při ukládání objektu. Zároveň je jednodušší získávání objektů z databáze, protože není potřeba spojovat několik tabulek jako u relačních DBS.

1.2.5 Ostatní datové modely

Existují další datové modely, které jsou kombinací výše uvedených technologií.

• XML databáze

S rozvojem jazyka XML potřebují aplikace ukládat data z XML dokumentů, což většina relačních DBS podporuje. Používají algoritmy pro mapování schématu dokumentu do podoby, která je vhodná pro uložení do databáze (mapování do tabulek nebo objektově-relační mapování).

Objektově relačním mapováním XML do databáze se zabýval M. Vanický v diplomové práci a došel k následujícímu závěru. [VAN].

Objektově relační mapování XML dat do relační databáze vynechává některé údaje o fyzické struktuře (jako entity, CDATA a typ kódování) a o logické struktuře (způsob zpracování instrukcí a pořadí, ve kterém se vyskytují elementy a PCDATA). To může mít za následek, že pokud uložíme data z původního dokumentu a následně z nich sestavíme nový XML dokument, najdeme mezi nimi drobné odlišnosti. Nesoulad se projeví jen v určitých aplikacích.

Existuje i možnost uložit XML dokument do nativní XML databáze přímo ve formátu XML.

Definice XML databáze Ronalda Bourreta [VAN]:

„Nativní XML databázový systém je databázový systém, který definuje model XML dokumentu a ukládá a získává dokumenty dle tohoto modelu. Model musí obsahovat minimálně elementy, atributy,PCDATA a zachovávat dokumentové pořadí prvků. Příkladem takového modelu je datový model XPath, XML Infoset a modely odvozené z DOM a z událostí SAX 1.0.“

Nativní XML databáze umožní jednodušší přístup k datům pomocí dotazovacího jazyka XPATH, nemusíme vytvářet dotazy na data, která jsou namapovaná v relační DBS. Další výhodou může být (ale nemusí) vyšší rychlost získávání dat než u relačních DB. Závisí to podle způsobu fyzického uložení dat. XML databáze udržují celé dokumenty fyzicky pohromadě anebo místo logických ukazatelů na jiné části dokumentu používají fyzické ukazatele. To umožní, aby byl dokument načten do paměti bez používání logického spojování jeho částí nebo pouze za použití fyzických spojek, přičemž oba způsoby jsou rychlejší než logické spojování, které používají relační databáze.

Hlavním omezením je fakt, že XML databáze umí vrátit data jen ve formátu XML. Pokud aplikace potřebuje data v jiném formátu, musíme postupně procházet XML dokumentem a potřebná data si manuálně poskládat.

• Multidimenzionální databáze

V mutlidimenzionální (vícerozměrné) databázi jsou data uložena na principu vícerozměrné matice, například trojrozměrnou matici lze reprezentovat kostkou. Obsah se vytváří přesunutím dat z relační, popřípadě objektové databáze do podoby, která je vhodná na vyhodnocování složitých dotazů. Využití nalézají na podporu OLAP aplikací, které vytvářejí složité dotazy. Jednotlivé dimenze jsou sledované veličiny – např. čas, výrobky a pobočky.

1.2.6 Porovnání RDBMS, ORDBMS, OODBMS

Porovnání jsem provedl na základě článku Object Database vs. Object-Relational Databases [CLU]. Některé charakteristiky jsem přidal nebo pozměnil.

RDBMS ORDBMS OODBMS

existující standardy SQL 2 (SQL-92) SQL 3 (SQL-99) ODMG 3.0 podpora OOP špatná, složité omezená na nové dobrá

(19)

mapování objektů do DB

datové typy - ADT

jednoduchost použití samotné databáze

založené na snadno pochopitelném principu tabulek

podobné jako u RDBMS, složitější kvůli rozšíření

snadné pro programátory, složitější pro uživatele – GUI nástroje pro přístup podpora komplexních

dat

nepodporuje

abstraktní datové typy

podporuje abstraktní datové typy a komplexní vztahy

lze definovat širokou škálu datových typů a bohatě provázané vztahy

vyspělost produktů velmi dobrá

rozšíření jsou nová, podstatně mladší než komerční OODBMS

komerční produkty velmi vyspělé, open- source středně vyspělé dotazovací jazyk SQL – velmi účinný

nástroj

SQL 3 s objektově orientovanými vlastnostmi

OQL – dobrá podpora OOP

rozšíření na trhu velké velké nepříliš velké

životaschopnost výrobců

velká u dlouho fungujících výrobců

nejistá, riziko rozkládají

provozováním jiných činností

Tab. 1. Porovnání RDBMS, OODBMS a ORDBMS

1.2.7 Výhody a nevýhody RDBMS, ORDBMS a OODBMS

Většina výhod i nevýhod OODBMS pramení ze svázanosti aplikace s databází.

OODBMS nabízejí spoustu speciálních funkcí, které by měl vývojář aplikace znát, aby se uplatnily výhody objektových databází v podobě schopnosti rychle zpracovávat velké množství složitých dat. Kvalita výsledného informačního systému je závislá na způsobu použití.

Například Versant nabízí 7 typů zámků, 4 typy dotazů a mnoho nástrojů na ladění výkonu.

Jestliže programátor zná, jaký typ zámku je nejvhodnější v dané situaci použít, vzniká z objektové databáze silný nástroj.

Dotazovací jazyky

Deklarativní přístup jazyka SQL se ukázal jako velmi účinný pro tvorbu libovolných dotazů. V oblasti OODBMS existuje jazyk OQL (Object Querry Language), který je obdobou jazyka SQL. Je velmi přínosný pro programátora, protože navigační způsob získávání objektů z databáze je totožný s konvencemi programovacího jazyka. SQL prošel silnou standardizací a všechny relační DBS ho podporují. Standard OQL je nový a je součástí standardu ODMG. Ne všechny systémy ho podporují, problémovou oblastí jsou open-source. Blíže popisuji OQL v kap. 3. Standardy.

SQL OQL

možnosti použití DDL a DML část DML – pouze pro výběr dat

update dat přímo voláním metody objektu

typ deklarativní deklarativní (funkcionální)

podpora objektových principů ano, v rozšířeném SQL 3

ano (komplexní objekty, identita objektů, polymorfismus, vyvolávání

metod, pozdní vazba)

(20)

výpočetní úplnost ano ne Tab. 2. Porovnání SQL a OQL

Výhody RDBMS

• Jednoduchost - Systém tabulek je snadno pochopitelný.

• Rozšířenost a velké povědomí – Vývojáři jsou zvyklí používat relační technologii, stávající aplikace běží na této technologii a není důvod ji měnit.

• Podpora standardů a teoretického základu – DBS jsou postaveny na Coddově pevném matematickém základě.

• Velmi účinný a jednoduchý jazyk SQL používá deklarativní přístup, který zdůrazňuje, jaká data najít, místo navigačního, který vychází z postupu, jak data najít. Uživatel SQL pouze zadá podmínky dotazu, aniž by musel psát programový kód.

Nevýhody RDBMS

• Nevhodná reprezentace entit reálného světa [BRA] – Jestliže použijeme normalizaci, jsou data jedné entity rozdělena do více částí. Jestliže je získáváme zpět, musíme je pospojovat výpočetně náročnou operací JOIN.

• Restriktivní datová struktura [BRA] – Relace přesně určuje, jaké hodnoty do ní můžeme vkládat. Řádky se musí skládat ze stejných atributů, sloupec obsahuje domény jednoho typu. Hodnoty navíc mohou být pouze atomické. Stálá struktura je příliš omezující pro objekty, které mají bohatě provázanou strukturu, a vede k nepřirozenému spojování relací.

Výhody ORDBMS

• Podpora objektové orientace – Datový model podporuje základní rozšíření datových typů, dědičnost a komplexní objekty [DEV].

• SQL – Dotazovací jazyk si ponechává výhody deklarativního jazyka a je rozšířen o objektovou podporu.

Nevýhody ORDBMS

• Data se stále ukládají do tabulek – Ve své podstatě jsou ORDBMS stále relační. Tento bod je více diskutabilní v pohledu jeho zařazení mezi výhody a nevýhody. Relační model má pevné zázemí a jediným jeho problémem, avšak zásadním, je odlišnost od objektově orientovaného pohledu na data, která je patrná i při aplikaci objektových principů do tabulek.

Výhody OODBMS

• Konzistence modelů – Jestliže vyvíjíme aplikaci v objektově orientovaném jazyce, kterou budeme provozovat na relační databázi, používáme během vývoje dva rozdílné modely. V úvodní fázi vývoje, v analýze, zachycujeme objekty z reálného světa v konceptuálním datovém modelu nezávisle na použité technologii. Ve fází hrubého návrhu se pohybujeme stále na úrovni objektového datového modelu, který potřebujeme převést v detailním návrhu na tabulky databáze. V následujících fázích (implementace a testování) pracujeme s dvěma odlišnými modely a úpravy v aplikaci jsou složitější, protože se promítají dvakrát. Nástroje na objektově-relační mapování zjednodušují proces objektově-relačního mapování. Nabízejí jednodušší API do relační databáze než bychom použili při manuálním převádění objektů na tabulky, avšak objektové databázové systémy nabízejí větší komfort. DDL i DML je přímo programovací jazyk a při komunikaci s databází nemusíme používat žádný další nástroj.

• Rychlejší vývoj aplikace – Důsledkem konzistence modelů je rychlejší uvedení aplikace na trh.

• Databázové schéma lze měnit za běhu aplikace – Můžeme měnit strukturu databáze, aniž bychom ji museli zastavit znovu spustit. Tím se zvyšuje dostupnost databáze.

• Výkon – Nárůst výkonu je patrný u rozsáhlejších aplikací s komplexními objekty.

(21)

• Škálovatelnost – Architektura objektových DBS je stavěná, abychom mohli rozšiřovat systém s minimálním negativním dopadem na výkon.

Nevýhody OODBMS

• Přenositelnost aplikací je mírně omezená – Kvůli odlišnému způsobu implementace některých vlastností se aplikace stává závislou na určité databázi. Přenositelnost je možná s drobným zásahem do kódu aplikace.

• Vysoká cena

• Složitější z hlediska administrace – Komerční systémy představují robustní řešení, jejichž správa bývá náročnější než u relačních DBS. Jednou z příčin je nízká znalost objektových DBMS.

• Neochota ze strany vývojářů [DBS] – Vývojáři hledají vhodné open-source řešení, které lze využívat pro komerční účely.

OODBMS bývá vytýkána nízká podpora standardů, avšak současné komerční verze podporují standardy ODMG 3.0 nebo JDO, problémovou oblastí zůstávají některé open-source systémy. Blíže se k problému dostanu v kap. 5 – Porovnání.

1.3 Shrnutí

V praxi převažují relační databáze, které se rozšiřují o objektově orientované vlastnosti.

Relační technologie se úspěšně používá již několik desítek let. Produkty se dostaly na velmi vysokou úroveň a vývojáři si zvykli pro ně vytvářet aplikace. Netvrdím, že by se měly stávající relační DBS nahrazovat objektovými DBS. Spíše při tvorbě nové aplikace bychom měli zvážit, jestli není lepší použít objektovou databázi. Velmi vyspělé komerční systémy jsou vhodné na práci s bohatě provázanými daty a připraveny na vysokou zátěž, v úvahu proto připadají ve větších projektech. V oblasti open – source je nabízená funkcionalita nižší. Jsou vhodné na práci s bohatě provázanými daty v menších aplikacích.

Kombinací relačního datového modelu a OOP vznikly objektově-relační DBS. Jejich výhodou je nižší cena než u objektových systémů, avšak ve své podstatě jsou stále relační, protože převádíme objekty do tabulek.

(22)

2 Požadavky na OODBMS

Kapitola shrnuje požadavky, které se očekávají od ODBMS. V první části se zaměřím na Manifest objektově orientovaných databázových systémů, který může být považován za soupis vlastností, které by měl každý OODBMS splňovat. V druhé části provedu analýzu prostředí, do kterého se objektové DBS nasazují. Vysvětlím způsoby implementace v rámci IS a uvedu příklady nasazení.

2.1 Manifest objektov ě orientovaných databázových systém ů

Základní technologické požadavky, které musí databázový systém splnit, aby byl označen jako objektově orientovaný, jsou uvedeny v díle Manifest objektově orientovaných databázových systémů, 1995 [Atk].

Zatímco relační databázové systémy jsou postaveny na pevném teoretickém základě [Cod], neexistuje podobná všeobecně uznávaná specifikace pro objektově orientované DBS. Existuje několik návrhů popisu objektově orientovaného modelu, avšak žádný se nestal všeobecně uznávaným.

Vznik objektových databázových systémů je založen na experimentální aktivitě. Vznikala prototypová řešení i komerční produkty (např. G-Base, 1988). Zájem o objektově orientované databáze byl podnícen potřebou vývoje systémů na podporu designu (CAD). Tyto aplikace vyžadují pracovat s velmi komplexními daty a přitom poskytovat vysoký výkon pro interaktivní zpracování.

Cílem manifestu není standardizace jazyků objektových databází podobně jako u ODMG, ale vytvoření obecných požadavků, které dávají odpověď na otázku „Co je to objektově orientovaný databázový systém“.

OODBMS vznikly rozšířením databázového způsobu zpracování dat o principy z objektově orientovaného programování. Z každé oblasti si přinášejí určité principy.

Manifest rozděluje charakteristiky objektově orientovaných databázových systémů do tří kategorií: povinné (systém je musí splnit, aby byl takto označen), volitelné (pouze vylepšují funkcionalitu) a volné (vývojář si může vybrat z více alternativ).

Povinné vlastnosti:

1) Musí to být databázový systém, proto je nutná podpora těchto rysů:

• perzistence

• správa sekundární paměti

• paralelní přístup více uživatelů

• zotavení po chybě (recovery)

• prostředky pro kladení libovolných dotazů

2) Musí být objektově orientovaný, tzn. že musí podporovat tyto rysy:

• identita objektu

• typy a třídy

• komplexní objekty

• zapouzdření

• dědičnost

• přetížení metod s pozdní vazbou

• rozšiřitelnost typů

• výpočtová úplnost.

Volitelné rysy obsahují:

• Podpora vícenásobné dědičnosti

• Typová kontrola

(23)

• Tvorba distribuovaných systémů

• Transakce

• Verzování Volné rysy:

• Programovací paradigma - uživatel by měl mít možnost zvolit si libovolné programovací paradigma

• Rozšíření základních datových typů - základní datové typy a konstrukce mají být rozšířitelné různými způsoby pro podporu objektové orientace

• Typový systém – Existuje typový systém hodnot.

• Uniformita – Systémy by měly používat jednotné pojmy (typ, objekt, metoda)

Vlastnosti, které zde nepopisuji, jsou vysvětleny v jiné části práce. Povinné vlastnosti databázového charakteru a volitelné vlastnosti jsou vysvětleny a upřesněny v kontextu současných objektových DBS v kap. 4. Kritéria. Povinné objektové vlastnosti jsem zmínil v kap. 1.2.4.1. Základní objektové principy. Podrobněji se nyní pozastavím u perzistence.

Perzistence

Perzistence je základní vlastnost každého databázového systému a spočívá v uložení dat nejen po dobu běhu programu, ale natrvalo.

Běžné programovací jazyky mají dobrou podporu práce s dočasnými daty, ale trvalá data mohou uchovávat pouze na principu souborové základny, která je pro efektivní provoz nevyhovující. Naproti tomu jsou databázové systémy navrženy na správu trvalých dat. Aplikace potřebuje pracovat současně s trvalými i dočasnými objekty, proto by měl DBMS vyhovět požadavkům aplikace i databázové formy zpracování.

ODBMS jsou založeny na transparentním principu persistence objektů.

K objektům v databázi se přistupuje přímo prostřednictvím programovacího jazyka a aplikace pracuje s trvalými objekty v databázi stejným způsobem jako s dočasnými objekty v operační paměti. Nemusíme používat jiné jazyky jako vnořený SQL nebo rozhraní JDBC či ODBC [ODA2]

Databázové systémy většinou nabízí podporu více programovacích jazyků, např. Java, C#, C++, neomezují se pouze na jeden z nich.

Pojem transparentní persistence objektů v rámci distribuovaného databázového systému znamená, že aplikace nemusí znát fyzické umístění objektu v síti distribuovaných databází, získává je přes OID. OID proto musí být unikátní v rámci celé sítě databází. Objekty mohou měnit fyzické umístění (data migration), aniž by o tom aplikace věděla.

Výpočtová úplnost

Výpočtová úplnost spočívá ve vyjádření libovolné výpočetní funkce pomocí jazyka databázového systému DML (data manipulation language).[ATK]

Shrnutí

Objektové databázové systémy nejsou postaveny na žádném teoretickém základu. Vývoj probíhal opačným způsobem. Nejprve vznikla prototypová řešení různého charakteru až později se objevovaly snahy o ucelený popis, co je to vlastně objektový databázový systém. Objektově orientovaný manifest je snaží shrnout vlastnosti, které by měl objektový DBMS splnit, aby obstál požadavkům. Je z roku 1995 a v současnosti nelze na základě tohoto díla stavět systém kritérií, protože tyto požadavky splňují všechny komerční systémy. Aplikace by měla smysl v oblasti open-source.

2.2 Požadavky dané implementa č ním prost ř edím

Změny v implementačním prostředí a jiný charakter aplikací se odrážejí na požadavcích, které by měly DBS splnit. Kapitola podává v první části přehled o způsobech zařazení

(24)

objektových DBMS do architektury IS. V druhé části uvádí oblasti, do kterých jsou objektové DBS nasazovány.

2.2.1 Zp ů soby použití OODBMS v IS

Objektové DBS můžeme rozdělit do několika skupin podle způsobu zařazení do architektury IS.

Vnořené ODBMS

IDC definuje vnořené DBMS následovně[IDC]:

Vnořené DBMS jsou DBMS, které jsou prodávány nezávislému softwarovému výrobci (ISV), aby se staly součástí jeho softwarového produktu..Vůči koncovému uživateli nemají viditelnou stránku, řídící funkce se vykonávají buď automaticky nebo přes API, takže nezávislý softwarový výrobce ji může ovládat prostřednictvím implementujícího produktu. Jsou navrženy a uzpůsobeny pro výkon a malý rozsah spíše než flexibilitu nebo jednoduchost používání (protože nemají viditelné uživatelské rozhraní). Podle IDC průzkumu tento trh vykazoval v roce 2003 obrat 208,3 bilionů USD, zatímco trh kompletních ODBMS 27,6 bilionů USD. IDC tvrdí, že od vnořených DBMS očekává růst.

Do této skupiny patří db4object nebo upravené verze kompletních komerčních systémů. Kompletní ODBMS

Kompletní ODBMS představují robustní databázové systémy, které běží nezávisle na aplikaci. Součástí jsou nástroje na administraci, prohlížení a tvorby databáze. Prodávají se přímo koncovému uživateli (firmě). Podle způsobu použití je lze rozdělit následovně:

Napojení na externí relační zdroje

Objektový DBS můžeme použít jako mezivrstvu k propojení aplikace a dalších zdrojů, kterými může být relační databáze. Systémy mají rozhraní, pomocí kterého mohou mapovat tabulky na objekty a naopak. Fungují jako datová integrační platforma.

Rozsáhlá síť databázových systémů

Databáze je součástí klient-server architektury, většinou třívrstvé nebo vícevrstvé.

Třívrstvá architektura zapojuje aplikační server a dovoluje použít tenkého klienta. Jestliže vytvoříme architekturu propojením více aplikačních serverů, získáme vícevrstvou architekturu.

Komerční DBS se zaměřují na tento způsob použití.

Shrnutí

ODBMS jsou určené především pro nasazení do vícevrstvých architektur. Podpora distribuovaných systémů a možnost ukládat velké množství dat jsou proto nutností. Požadavky bychom měli přizpůsobit faktu, jestli potřebujeme vnořený nebo kompletní systém. Protože vnořená databáze se stane součástí jedné aplikace, nemusí zahrnovat nástroje na správu a složité typy zámků (zamykání se použije jen ve víceuživatelských aplikacích). Její hlavní výhodou je rychlost a snadnost implementace.

2.2.2 P ř íklady nasazení

Podkapitola shrnuje aplikační oblasti, ve kterých se objektové DBMS používají. Použité informační zdroje jsou buď ze stránek výrobců nebo z článků, které jsem získat rešerší v databázi Proquest.

• Elektronický obchod a internetové aplikace

Hlavním přínosem objektového DBS v této oblasti je rychlejší uvedení aplikace do provozu.

Systém můžeme nasadit již ve fázi vývoje a postupně dotvářet. DBS dovoluje měnit datové schéma za běhu, a tím zvyšuje dostupnost aplikace.

Příklady: Rezervační systém letenek firmy Fractal je největším nasazením Gemstone v ČR (www.fractal.cz) [BER]. Dalším příkladem je letecká společnost All Nippon Airways Co., která používá rezervační systém letenek (ObjectStore). Oficiální stránky Tour De France používají ObjectStore.