UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

UNICORN COLLEGE
Katedra informačních technologií
BAKALÁŘSKÁ PRÁCE
Srovnání moţností relačních a objektových databází
Autor BP: Hana Vaňásková
Vedoucí BP: Ing. Miroslav Žďárský
2012 Praha
ČESTNÉ PROHLÁŠENÍ
Prohlašuji, ţe svou bakalářskou práci na téma Srovnání moţností relačních a objektových databází
jsem vypracovala samostatně pod vedením vedoucího bakalářské práce a s pouţitím odborné
literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou téţ uvedeny v seznamu
literatury a pouţitých zdrojů.
Jako autor uvedené bakalářské práce dále prohlašuji, ţe v souvislosti s vytvořením této bakalářské
práce jsem neporušila autorská práva třetích osob, zejména jsem nezasáhla nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědoma následků porušení ustanovení
§ 11 a následujících autorského zákona č. 121/2000 Sb.
.....…….……………….
V ........................... dne ..................
Hana Vaňásková
-4-
PODĚKOVÁNÍ
Děkuji vedoucímu bakalářské práce Ing. Miroslavu Ţďárskému za podporu, účinnou metodickou,
pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
-5-
SROVNÁNÍ MOŢNOSTÍ RELAČNÍCH
A OBJEKTOVÝCH DATABÁZÍ
COMPARISON OF RELATIONAL
AND OBJECT ORIENTED DATABASES
-6-
ABSTRAKT
Tato bakalářská práce si klade za cíl porovnat moţnosti, které nabízejí v dnešní době nejrozšířenější relační databáze s moţnostmi nabízenými nepříliš prosazenými objektovými databázemi.
Za tímto účelem je v první části práce provedena rešerše těchto dvou datových modelů, včetně
jejich standardů (SQL, OQL, ODL, ...), hlavních rozdílů, výhod a nevýhod. Tato část zahrnuje
ukázky kódu a příkazů tak, jak jsou teoreticky definovány samotnými standardy. Představeny jsou
také vybrané RDBMS a ODBMS nabízené na trhu.
Ve druhé části práce je pak na příkladu fiktivní společnosti Bluedy+ Holding, a. s. navrţena a implementována datová vrstva pro evidenci zaměstnanců, zaměstnaneckých benefitů, klientů a projektů v relační databázi PostgreSQL a objektové databázi db4o.
Klíčová slova: relační databáze, objektové databáze, SQL, OQL, ODL, db4o, PostgreSQL
-7-
ABSTRACT
This bachelor thesis aims to compare the possibilities offered by nowadays most widespread relational database with the possibilities offered by not too used object-databases.
For this purpose in the first part of the work there is carried out searches of these two data models
including their standards (SQL, OQL, ODL, ...), the main differences, advantages and disadvantages. This part includes sample of source code and commands as they are theoretically defined
by standards themselves. Selected RDBMS and ODBMS offered on the market are presented.
In the second part there is on the example of a fictitious company Bluedy + Holding, a. s. designed
and implemented a data layer for records of employees, employee benefits, clients and projects in
the PostgreSQL relational database and object database db4o.
Keywords: relational databases, object databases, SQL, OQL, ODL, db4o, PostgreSQL
-8-
OBSAH
1.
Úvod .......................................................................................................................................... 10
2.
Databáze ................................................................................................................................... 11
3.
4.
5.
2.1
Databáze a databázové systémy ....................................................................................... 11
2.2
Datový model ..................................................................................................................... 11
2.3
Databázové modely............................................................................................................ 12
Relační databáze ....................................................................................................................... 15
3.1
SQL .................................................................................................................................... 17
3.2
Produkty na trhu ................................................................................................................. 25
Objektové databáze ................................................................................................................... 29
4.1
Objektový datový model ..................................................................................................... 30
4.2
Objektový model podle ODMG........................................................................................... 32
4.3
Object Definition Language (ODL) ..................................................................................... 33
4.4
Objektový dotazovací jazyk (OQL) ..................................................................................... 36
4.5
Produkty na trhu ................................................................................................................. 39
Praktická ukázka RDBMS a ODBMS ........................................................................................ 41
5.1
Řešený problém ................................................................................................................. 41
5.2
Výběr databází ................................................................................................................... 43
5.3
Návrh datové vrstvy ............................................................................................................ 43
5.4
Implementace ..................................................................................................................... 49
6. Závěr ........................................................................................................................................... 58
7. Conclusion .................................................................................................................................. 60
8. Zdroje .......................................................................................................................................... 62
9. Seznam pouţitých pojmů a zkratek ............................................................................................ 64
10.
Seznam obrázků ....................................................................................................................... 65
11.
Seznam tabulek ........................................................................................................................ 67
Příloha 1 – Datové typy v PostgreSQL ............................................................................................. 68
-9-
1.
ÚVOD
V dnešní době při návrhu informačního systému převládá paradigma objektově orientovaného programování. Objektově orientované programovací jazyky umoţňují prezentovat ve zdrojovém kódu
objekty jako odraz skutečných věcí a tvorů v reálném ţivotě, umoţňují dědičnost objektů, vytváření
atributů a metod jako odraz vlastností a schopností, zapouzdření, polymorfismus. Přesto,
kdyţ chceme do databáze uloţit takový objekt, v naprosté většině případů ho mapujeme (měníme)
na řádek v tabulce relační databáze, kde se atributy stanou sloupci tabulky. Jen velmi málo aplikací
v dnešní době objekty uchovává v databázi v „původním formátu―, ačkoliv by to v určitých situacích
znamenalo jednodušší práci s uloţenými daty.
V následujících kapitolách se proto pokusím přiblíţit relační i objektově orientované databáze
a srovnat oba přístupy z více pohledů. Nejprve vymezím důleţité pojmy týkající se problematiky
databází a krátce představím historický vývoj databázových modelů. Následně detailněji rozeberu
teorii nejznámějšího databázového modelu – relačního modelu a teorii často opomíjeného objektového modelu. Teorie se však od praxe často liší, a právě objektově orientované databáze jsou toho
důkazem, a proto bude část práce věnována implementaci totoţného příkladu v relační databázi
PostgreSQL a v objektově orientované databázi db4o.
Na závěr doplním vlastní subjektivní srovnání práce s relační a objektovou databází na základě
provedené rešerše a implementace. Cílem však není porovnat databáze výkonnostně, to by vyţadovala mnohem rozsáhlejší studii, optimalizace a především několik odlišných problémů k implementaci, které by ukázaly, kde je daný databázový model výhodnější. Mým cílem je porovnat tyto
na první pohled protichůdné modely z hlediska moţností vyuţití, rozdílů při návrhu, intuitivní práce
s daty a podobně.
- 10 -
DATABÁZE
2.
Neţ se pustíme do výkladu relačních a objektových databází, podívejme se na několik pojmů,
které se v následujícím textu budou často objevovat a pro pochopení celého kontextu je
jejich znalost nezbytná.
2.1 Databáze a databázové systémy
Pojem databáze by se dal definovat jako prostor paměťového média, ve kterém jsou uloţena data
(Procházka, Oracle. Průvodce správou, využitím a programováním mad databázovým systémem. 2009).
Součástí databází jsou také softwarové prostředky, které umoţňují v tomto prostoru data vyhledávat podle nejrůznějších parametrů, číst je, mazat, přidávat či upravovat. Tyto softwarové prostředky
jsou nazývány database management system (DBMS), v české literatuře se můţete setkat také
s označením systém řízení báze dat (SŘBD).
Kromě vlastních dat jsou v databázi uloţeny také metadata. Metadata si lze představit jako popisky
vlastních dat a databáze. Jsou někdy označovány také jako data o datech, právě kvůli jejich popisnému charakteru.
Spojením databáze (DB) a database management system (DBMS) vzniká databázový systém
(DBS), který zajišťuje komplexní správu velkého mnoţství dat.
Současné databázové systémy kromě jiţ zmiňovaných funkcí obvykle zajišťují také

podporu pro datové modely,

práci s transakcemi,

moţnost manipulace s daty pomocí vyšších programovacích jazyků (SQL, OQL, ...),

bezpečnost (autentifikace, autorizace) a

zotavení z chyb bez ztráty dat.
Mezi v současnosti nejpouţívanější databázové systémy patří například Oracle Database, Microsoft SQL Server nebo IBM DB2. Své příznivce však získávají také méně rozšířené DBS jako Gemstone, db4o, Jasmine, OpenIngres, Caché a další.
2.2 Datový model
Pro návrh databázových systémů se obvykle pouţívá datový model, coţ je v podstatě abstraktní
koncept databázového systému. Jednotlivé typy datových modelů zachycují v různých úrovních
abstrakce řešení datové vrstvy konkrétního informačního systému a jsou prostředkem
pro komunikaci mezi členy vývojového týmu, popřípadě dalšími zainteresovanými osobami.
- 11 -
Zjednodušeně lze říci, ţe datový model je mapa databáze, která zobrazuje pouţité datové struktury
(atributy, pohledy apod.) a jejich vzájemné vazby. (Procházka 2009)
Typicky při návrhu databáze vzniká více modelů a to postupně od nejvyšší úrovně abstrakce
po nejniţší. Typy pouţitých modelů jsou závislé na zvoleném databázovém modelu (hierarchický,
síťový, relační, objektově relační, objektově orientovaný).
Například při návrhu relační databáze se pouţívají tzv. tři kroky modelování databáze. Jedná se o

konceptuální datový model,

logický datový model a

fyzický datový model. (Oracle Corporation nedatováno)
2.3 Databázové modely
„Databázový model definuje především používanou abstrakci pro přístup k datům, z té ale často již
přímo vyplývají požadavky na způsob uložení dat a jejich vzájemného provázání.“ (Oracle
Corporation nedatováno) Určuje tak architekturu samotné databáze.
Jak je jiţ zmíněno v kapitole 2.2 Datový model, rozlišujeme několik databázových modelů, neboli
několik typů databází. Většina odborných publikací se shoduje na rozlišení pěti základních typů:

hierarchický model,

síťový model,

relační model,

objektově relační model a

objektový model.
Někteří autoři povaţují za databázové modely také modely fulltextové, hypertextové a modely zaloţené na sémantických sítích. (Merunka 2008)
Následují krátké popisy hierarchického a síťového modelu. Ostatní modely budou podrobně
popsány v samostatných kapitolách.
2.3.1 Hierarchický model
Data v tomto modelu jsou organizována do stromové struktury s jedním kořenovým záznamem.
Vztah mezi záznamy je typu rodič/potomek a platí, ţe kaţdý záznam má libovolné mnoţství potomků, ale pouze jednoho rodiče (aţ na kořenový záznam, který rodiče nemá). Záznam, který nemá potomka, se nazývá list. (Hronek 2007)
Kaţdý záznam je v databázi implementován jako kolekce určitého typu datové struktury, často se
pouţívají zřetězené seznamy. Navigace mezi kolekcemi probíhá pomocí vzájemných odkazů.
(Kocan 2008)
- 12 -
Obrázek 1: Schéma hierarchické databáze
Kořen
A
B
C
D
List
A.B
E
A.C
F
A.B.E
A.B.F
A.D
Navigační
odkaz
G
A.C.G
Zdroj: Autorem vytvořeno v aplikaci MS Visio 2010
„Použití hierarchického modelu je vhodné tam, kde i zájmová realita má hierarchickou strukturu.“
(Farana 1995) Tím se myslí data, která mají jednoduché vazby typu rodič/potomek jako například
přehled zaměstnanců společnosti nebo seznam jejích poboček a oddělení.
Nalezení dat v hierarchické databázi vyţaduje navigaci přes záznamy směrem dolů (potomek),
nahoru (rodič) a do strany (další potomek), začíná se však vţdy u kořene. Mezi nevýhody hierarchického modelu patří:

absence standardů,

v některých případech nepřirozená organizace dat (zejména obtíţné znázornění vztahu
M:N, který se řeší např. pomocí virtuálních záznamů),

sloţité operace vkládání a rušení záznamů. (Farana 1995)
Pravděpodobně
nejznámější
implementací
tohoto
modelu
byl
systém
IMS
vyvinutý
v šedesátých letech společnostmi IBM a NAA, a to pro realizaci skladového hospodářství v rámci
projektu Apollo. (Kocan 2008)
2.3.2 Síťový model
Síťový model je často označován za rozšíření hierarchického modelu. Stejně jako hierarchický
model je zaloţen na stromové struktuře typů záznamů, pouze mění terminologii pro popis vztahů
mezi záznamy, které označuje vlastník (neboli rodič v hierarchickém modelu) a člen (neboli poto-
- 13 -
mek v hierarchickém modelu) a samotný vztah 1:N označuje jako set. V síťovém modelu neplatí
omezení na jednoho vlastníka a je tak moţné modelovat i vazby typu M:N. (Hronek 2007)
Schéma konkrétní situace můţe vypadat například takto:
Obrázek 2: Schéma síťové databáze
Manaţer A
zaměstnává
zaměstnává
zaměstnává
Set
Konkrétní
výskyt
záznamu
Pracovník 1
pracuje na
Projekt 1
Pracovník 2
pracuje na
Pracovník 3
pracuje na
Projekt 2
Projekt 3
Mezi další výhody síťového modelu patří moţnost přistupovat k datům odkudkoliv. Pokud se například v ukázce na obrázku 2: Schéma síťové databáze snaţíme zjistit, kdo je manaţerem projektu
Projekt 3, jednoduše začneme databázi procházet od projektu aţ k manaţerovi.
Síťový model byl roku 1972 standardizován výborem Database Task Group (DBTG) a svého,
ač krátkého, času byl hojně vyuţívaný, v polovině 80. let ho však rychle nahradily velmi úspěšné
a do dnes převládající relační databáze. Mezi známé implementace síťového modelu se zařadili
například IDMS, ADABAS nebo DMS 1100. (Hronek 2007)
Nevýhodou síťového modelu je stejně jako u hierarchického modelu obtíţná změna struktury databáze, kdy je většinou potřeba měnit celou aplikaci. (Farana 1995)
- 14 -
RELAČNÍ DATABÁZE
3.
Relační model je v současnosti nejpouţívanějším databázovým modelem. Roku 1970 byl navrţen
britským vědcem Edgarem Frankem Coddem v práci „A relational model of data for large shared
data banks― a během několika málo let nahradil v té době pouţívaný síťový model.
Relační model je zaloţen na matematickém konceptu relace, která je fyzicky reprezentována dvourozměrnou tabulkou. Řádky tabulky odpovídají jednotlivým datovým n-ticím a sloupce tabulky odpovídají atributům. Na rozdíl od hierarchického modelu nedefinuje relační model vztahy mezi záznamy ani způsob přechodu mezi nimi. Vztahy mezi záznamy vznikají aţ při vyhodnocování operací. Následuje výčet nejdůleţitějších vlastností relačních tabulek.

Tabulky jsou odlišené jedinečným názvem.

Kaţdá buňka tabulky obsahuje právě jednu hodnotu. Nedefinujeme-li hodnotu buňky, její
hodnota je automaticky nastavena na null.

Kaţdý sloupec tabulky má jedinečný název a pořadí sloupců lze měnit.

Všechny hodnoty v jednom sloupci jsou ze stejné domény (mnoţiny přípustných hodnot).

Kaţdý řádek tabulky, záznam, je jedinečný a pořadí záznamů lze měnit. (Conolly, Begg a
Holowczak 2009)
V tabulkách musí vţdy existovat sloupce nebo kombinace sloupců, které zajišťují jedinečnost záznamů. Takové sloupce nebo kombinace označujeme jako klíče relace, těch v jedné tabulce můţe
být i více. Ten klíč, který vybereme, aby jedinečně určoval záznamy v tabulce, nazýváme primární
klíč – takový atribut nesmí nabývat hodnoty null, protoţe kaţdý záznam musí být jednoznačně
určený primárním klíčem. Pokud přesto při vytváření tabulky nemáme sloupce vhodné pro primární
klíč, vytváří se uměle sloupcem ID, kde obvykle sám systém přiřazuje inkrementálně hodnoty
(Conolly, Begg a Holowczak 2009).
Kromě primárního klíče můţeme označit v tabulkách cizí klíče, coţ jsou sloupce tabulky odpovídající primárnímu klíči jiné nebo téţe tabulky. Rovnost cizího a primárního klíče slouţí k propojení
tabulek a tvoření vztahů typů 1:1, 1:N a M:N, viz obrázek 3: Ukázka relační databáze. (Conolly,
Begg a Holowczak 2009)
Kromě klíčů relace můţeme u jednotlivých sloupců definovat také integritní omezení, coţ, jak název napovídá, jsou nějaká omezení a pravidla, která definují některé vlastnosti dat. Jsou značnou
přidanou hodnotou databází, kontrolují (validací na datové vrstvě), zda uţivatel zadává do databáze smysluplná data. Například atribut primární klíč musí splňovat integritní omezení na jedinečnost
a nenullovou hodnotu. Obě omezení jsou vysvětlena výše.
Podívejme se na ukázku dvou relací z korporátního prostředí na obrázku 3: Ukázka relační databáze. Relace na obrázku jsou pro ukázku značně zjednodušené, v praxi obsahují relace typicky
mnohonásobně více záznamů.
- 15 -
Obrázek 3: Ukázka relační databáze
Relace (Zaměstnanci)
Primární klíč
Atributy
ID_ZAM
Příjmení
Jméno
Pozice
Kancelář
1
Novák
Petr
Finanční ředitel
S.1
2
Dvořáková
Dana
Sekretářka
S.1a
3
Čech
Mojmír
Obchodní ředitel
M.1
4
Zelená
Nikola
HR manaţer
M.23
Cizí klíč
Relace (Majetek společnosti)
ID_MAJ
ID_ZAM
Název
ID_SMLOUVA
8420-12
1
MacBook Air 13'‘
NB10201103
3412-20
4
Nokia Oro Light
MT09201101
0010A8
null
MacBook Air 11'‘
null
R54J12
1
iPhone 4S 64GB černý
MT11201105
Cizí klíč
První relace, Zaměstnanci, obsahuje údaje o identifikačním čísle zaměstnance (ID_ZAM), jménu,
příjmení, pozici a umístění v kanceláři. Jediný sloupec vhodný pro primární klíč je zde ID zaměstnance, které ze své povahy musí být pro kaţdý záznam jedinečné.
Druhá relace, Majetek společnosti, obsahuje informace o identifikačním čísle majetku (ID_MAJ), ID
zaměstnance, který má nějaký majetek zapůjčený, název majetku a ID smlouvy o zapůjčení. Zde
jiţ ID zaměstnance jako primární klíč nemůţeme pouţít, protoţe jeden zaměstnanec si můţe zapůjčit více poloţek, v tabulce tedy bude zaznamenán vícekrát se stejným ID zaměstnance a to tím
pádem ztrácí svou jedinečnost. Kandidátními klíči jsou tedy ID majetku a ID smlouvy. Na jednu
smlouvu si však zaměstnanec můţe vypůjčit více poloţek a nastává tak stejný problém jako u ID
zaměstnance. Navíc je v obrázku naznačeno, ţe ID smlouvy je pouţito jako cizí klíč pro další tabulku, která však v obrázku jiţ není zobrazena. Primárním klíčem tedy bude ID majetku, které splňuje integritní omezení na jedinečnost i nenullovou hodnotu.
Relace Zaměstnanci a Majetek společnosti jsou ve vztahu 1:N, propojené klíčem ID_ZAM (ID zaměstnance), coţ znamená, ţe kaţdý zaměstnanec můţe mít v zapůjčení několik poloţek,
ale kaţdá poloţka můţe být půjčena maximálně jednomu zaměstnanci (nemusí však být půjčena
nikomu, jako je tomu u poloţky 0010A8).
Relační model má silné teoretické základy a podporu standardizovaného dotazovacího jazyka
SQL. Další silnou stránkou tohoto modelu je jeho jednoduchost a vhodnost pro vyuţití v OLTP
databázích (Online Transaction Processing). Ale má i své nevýhody. Mezi často zmiňované slabiny
aţ nedostatky patří například:
- 16 -

nedostatečná reprezentace objektů „reálného světa―,

nedostatečná podpora integritních omezení,

obtíţné zpracování rekurzivních dotazů,

sémantické přetíţení (neexistuje mechanismus pro rozlišení mezi entitami a relacemi nebo
pro rozlišení různých druhů relací).
Zmíněné problémy se netýkají výhradně relačního modelu. Ve skutečnosti v relačním modelu není
ţádný hlubší problém, coţ také dokazuje jeho úspěšnost. Úspěch relačního datového modelu
je však limitován určitými typy aplikací. Při současném rozšiřování a vývoji nových, podstatně sloţitějších, aplikací, se pak uţivatelé setkávají s tzv. „relační zdí―, neboť RDBMS jiţ nenabízí potřebný
výkon a funkčnosti. (Wade 2005) V těchto situacích, kde pouţití relačního modelu není vhodné,
se upřednostňují jiné modely, ať jiţ zmiňovaný síťový model pro reprezentaci hierarchické struktury, nebo v současnosti se rozšiřující objektový model, o kterém pojednává kapitola 4. Objektové
databáze.
3.1 SQL
Se vznikem Coddova schématu relačních databází začala firma IBM pracovat na vývoji jazyka
pro ovládání těchto databází. Cílem bylo vymyslet jazyk, který by byl syntakticky co nejvíce podobný anglickému jazyku a byl by tak přístupný také uţivatelům bez hlubšího technického vzdělání.
Výsledkem byl jazyk Structured English Query Language (SEQUEL), který byl později při zachování výslovnosti přejmenován na SQL. K vývoji jazyka se přidali i další firmy. V roce 1979 uvedla
na trh firma Relational Software, Inc. (dnešní Oracle Corporation) svojí relační databázovou platformu Oracle Database a s ní zveřejnila první komerční verzi SQL. IBM uvedla v roce 1981 nový
systém SQL/DS a v roce 1983 systém DB2. Dalšími systémy byly např. Progres, Informix a SyBase. Ve všech těchto systémech se pouţívala varianta jazyka SQL. (Procházka 2009).
Ačkoli tedy byla společnost IBM u zrodu relačních databází a jazyka SQL, přišla se svým databázovým systémem o celé dva roky později neţ konkurence.
Po tomto rozšíření se jazyk SQL, tehdy ještě nazýván SEQUEL2, stal v roce 1986 de facto standardem (SQL-86) (Oracle Corporation nedatováno) a to i přes snahu amerického institutu ANSI (American National Standards Institute) prosadit jako standard zcela nový jazyk RDL. SQL jako standard
byl přijat i organizací ISO/IEC (International Organization for Standardization s přidruţenou International Electrotechnical Commission). Aktuálním standardem je SQL:2008, většina databází však
vychází ze starších standardů SQL-92 a SQL-99 a z novějších implementují do svých systémů
pouze vybrané části, které se podle jejich usouzení na trhu ujmou a na druhou stranu doplňují
vlastní části, které ve standardech obsaţeny nejsou. Výsledkem je tak sloţitější přenositelnost
aplikací a větší rozdílnost jednotlivých verzí SQL podle výrobce databáze.
Ukázky příkazů v této práci jsou psány v databázi PostgreSQL 9.1.3, převáţná většina z nich vychází ze standardu SQL-92 a měla by proto být přenosná i na ostatní platformy.
- 17 -
Jazyk SQL se skládá ze čtyř hlavních, odlišně zaměřených, skupin příkazů:
1. Data Definition Language (DDL),
2. Data Manipulation Language (DML),
3. Data Control Language (DCL) a
4. transakční příkazy. (Oracle Corporation nedatováno)
Obrázek 4: Základní příkazy jazyka SQL
Kromě těchto hlavních příkazů zahrnuje SQL také další příkazy pro práci s indexy, pohledy (views),
triggery apod. Ty v této práci nepopisuji, neboť cílem není popsat všechny moţnosti databází do
hloubky, ale porovnat přístup odlišných databázových modelů a práci s nimi.
3.1.1 Data Definition Language (DDL)
Pomocí DDL definujeme relační schéma databáze. Velmi hezkou definici uvádí ve své publikaci
David Procházka (Procházka 2009): „Jazyk DDL slouží k definici struktury dat ukládaných do databáze. Pomocí této sekce SQL lze přesně nadefinovat, jaký typ dat budeme do databáze ukládat.“
Jinými slovy pomocí DDL navrhujeme jednotlivé tabulky, jejich atributy, klíče, vazby, omezení, způsob indexování a další oblasti určující charakter ukládaných dat.
Pro ukázku příkazů jazyka DDL vyuţiji schéma relací zobrazené na obrázku 3: Ukázka relační
databáze (viz strana 16). Jedná se o dvě relace, Zaměstnanci a Majetek společnosti, ve vztahu
1:N.
Pro vytvoření nové tabulky pouţijeme příkaz CREATE TABLE s následující syntaxí (vyhrazené
výrazy DDL jsou zvýrazněny modrou barvou a nepovinné údaje jsou ohraničeny ‗[‗ a ‗]‘):
- 18 -
Obrázek 5: Syntaxe příkazu CREATE TABLE
Zdroj: Vlastní zpracování
Základní syntaxe příkazu CREATE TABLE (a také ALTER TABLE) můţe být rozšířena o takzvaná
omezení (constraints). Jejich výčet a stručný popis je uveden v tabulce 1: SQL – Integritní omezení.
Tabulka 1: SQL - Integritní omezení
Omezení
Popis
NOT NULL
Doménové omezení. Daný sloupec nesmí obsahovat hodnotu null.
UNIQUE
Doménové omezení. Daný sloupec nesmí obsahovat duplicitní hodnoty.
CHECK
Doménové omezení. Hodnoty daného sloupce musí splňovat danému
booleovskému výrazu.
Primary Key
Entitní omezení. Hodnoty musí splňovat omezení NOT NULL a zároveň
UNIQUE.
Právě jeden primární klíč (PK) musí být definován v kaţdé tabulce. Typicky
se vytváří umělý PK datového typu celé číslo, které je optimálnější při porovnávání (například při operaci JOIN) neţ text.
Foreign Key
Referenční omezení. Hodnoty sloupce mohou být pouze NULL nebo shodné s jedním primárním klíčem nadřazené tabulky.
Toto omezení zajišťuje referenční integritu databáze a definuje akce, které
mají nastat při změně odkazovaného záznamu.
Zdroj: Dokumentace PostgreSQL (The PostgreSQL Global Development Group nedatováno)
Vytvoření relací Zaměstnanci a Majetek společnosti je znázorněno na obrázku 6: Vytváření tabulek
v jazyce DDL. U relace Majetek společnosti je záměrně vynechán atribut id_smlouva. Na původním
schématu byl zobrazen za účelem znázornění moţnosti evidence více cizích klíčů v jedné tabulce.
Pro jeho zahrnutí do tabulky Majetek_Spolecnosti by bylo potřeba doplnit tabulku Smlouvy.
- 19 -
Obrázek 6: Vytváření tabulek v jazyce DDL
Po spuštění těchto příkazů se v databázi vytvoří prázdné tabulky. V kapitole 3.1.2 Data Manipulation Language si ukáţeme, jak tabulky naplnit daty, jak si zobrazit obsah těchto tabulek, včetně projekce, sjednocení, selekce a podobně.
Popis pouţitých a dalších často vyuţívaných datových typů je přiloţen v příloze 1: Datové typy
v PostgreSQL.
Mezi další příkazy jazyka DDL patří příkaz DROP, který smaţe vybranou tabulku a příkaz ALTER,
který slouţí pro úpravy tabulek, například přidání/ubrání sloupce nebo změny omezení. Příkaz
pro přidání atributu popis do existující tabulky Majetek společnosti a zároveň přidání omezení NOT
NULL na atribut název by vypadal takto:
Obrázek 7: Úpravy tabulek v jazyce DDL
Pomocí příkazu ALTER je moţné nejen měnit sloupce a omezení, ale také měnit názvy sloupců,
názvy tabulek nebo datové typy jednotlivých sloupců.
3.1.2 Data Manipulation Language (DML)
Teď, kdyţ máme vytvořené a provázané tabulky, můţeme je naplnit daty. K tomu nepouţijeme
jazyk DDL, ale jazyk DML, který slouţí k manipulaci s uloţenými daty, jejich ukládání (příkaz
INSERT), mazání (příkaz DELETE), editaci (příkaz UPDATE) a především vyhledání (příkaz
SELECT).
- 20 -
Syntaxe příkazů INSERT, DELETE a UPDATE není nijak komplikovaná, a proto ji představím rovnou na praktické ukázce v naší relaci Zaměstnanci.
Obrázek 8: DML příkazy v jazyce SQL
Stejným způsobem naplníme i relaci Majetek společnosti, u které je navíc potřeba při vkládání dat
dávat pozor na atribut cizí klíč, kde hodnota musí být shodná z odpovídajícím primárním klíčem
v relaci Zaměstnanci nebo musí být null. Ke zjištění hodnoty ID_ZAM některého ze zaměstnanců
pouţijeme poslední zmiňovaný příkaz – SELECT.
Základní syntaxe příkazu SELECT je velmi jednoduchá. Na následujícím obrázku je jiţ doplněná
i o nepovinnou klauzuli WHERE, tedy dodatečnou podmínku.
Obrázek 9: Syntaxe příkazu SELECT
Pokud chceme vypsat všechny atributy relace, můţeme místo výčtu atributů pouţít znak hvězdičky
(viz obrázek 10: Příkaz SELECT v jazyce SQL (konzole psql)). Obvykle ale nepotřebujeme data
všech atributů a v takovém případě do výčtu atributů zadáme pouze vybrané z nich. Tím provedeme takzvanou projekci. K problematice pouţívání projekce se velmi výstiţně vyjádřil Jaromír Kukal
(Kukal 1998) v článku Projekce v databázových systémech: „Projekce zajímá především cílevědomé inteligentní jedince, kteří vědí, že důležité je vždy jen něco, zatímco všechno zahlcuje málo
inteligentního alibistu. Při projekci máme v příkazu SELECT možnost vyjádřit se o tom, které
sloupce relace vlastně chceme vidět.“
Nepovinná klauzule WHERE pak slouţí k takzvané selekci (někdy označované jako restrikce),
neboli výběru pouze těch záznamů relace, které odpovídají dané podmínce. Jedná se tedy o filtrování řádků tabulky (zatímco projekce filtrovala sloupce tabulky).
Podívejme se na několik jednoduchých příkladů projekce a selekce psaných v psql konzoli:
- 21 -
Obrázek 10: Příkaz SELECT v jazyce SQL (konzole psql)
Zdroj: Vlastní zpracování v konzoli psql
V posledním příkladu na obrázku výše je pouţitá funkce LIKE, která pracuje s regulárními výrazy.
Selekci lze doplnit o mnoho dalších funkcí a klauzulí. Některé z nich jsou popsány níţe u příkladů
spojování tabulek.
Častěji se setkáme s výběrem dat z více tabulek najednou. K tomu je potřeba nejprve související
tabulky propojit pomocí primárních a cizích klíčů a následně provést selekci a projekci. Existuje
několik způsobů, jak tabulky propojit.
- 22 -
Obrázek 11: Typy JOIN příkazů
Zdroj: http://www.codeproject.com/KB/database/Visual_SQL_Joins/Visual_SQL_JOINS_orig.jpg
Obrázek níţe znázorňuje pouţití INNER JOIN příkazu pro získání informací o tom, kteří zaměstnanci mají zapůjčený majetek společnosti.
Obrázek 12: Příkaz INNER JOIN v jazyce SQL (psql)
Záznamy byly navíc seřazeny abecedně podle atributu pozice pomocí příkazu ORDER BY. Pomocí
agregační funkce COUNT pak můţeme příkaz dále upravit tak, ţe se nám ke kaţdému zaměstnanci vypíše počet vypůjčených předmětů.
- 23 -
Obrázek 13: Příkaz LEFT JOIN v jazyce SQL (psql)
Zdroj: Vlastní zpraování v konzoli psql
Na příkladech byly ukázány pouze základní příkazy. Mezi další často pouţívané funkce patří SUM,
ABS, AVG, MAX, MIN, SUBSTRING, TRIM a spousta jiných.
3.1.3 Data Control Language (DCL)
K databázi plné soukromých dat je potřeba doplnit přístupová práva jednotlivým uţivatelům. Jazyk
DCL slouţí právě k této správě uţivatelů a práv. Umoţňuje vytvářet, mazat a měnit jak uţivatele,
tak jejich práva na vytváření a úpravy tabulek, pohledů i samotných vnitřních dat.
Od verze Postgre 8.1 jiţ není moţné vytvářet skupiny uţivatelů a spravovat tak práva více rolím
zároveň. Určitým způsobem je obdoba skupin stále moţná (pomocí příkazu IN ROLE), to však
nese značná omezení. Skupiny rolí nejsou součástí SQL standardu a tak je nyní moţné vytvářet
pouze role/uţivatele. Na jednu stranu je to krok zpět ve správě práv, na druhou stranu tím usnadňuje přenositelnost databáze na jiné platformy. Nově pak do správ uţivatelů přibyl uţitečný příkaz
inherit, který slouţí k dědění vlastností mezi rolemi a tak částečně nahrazuje zrušené skupiny.
Pro ukázku dalších zajímavých příkazů si vytvořme nyní jednoho uţivatele s přístupem a jednoho
administrátora bez přístupu do databáze.
Obrázek 14: Vytvoření uţivatele v jazyce DCL
Zbývá přidat uţivateli databáze práva. K tomu slouţí příkaz GRANT, naopak zrušit práva umoţňuje
příkaz REVOKE. Povaţujme našeho uţivatele za správce majetku společnosti a nastavme práva
takto:
Obrázek 15: Nastavení práv v jazyce DCL
- 24 -
Nyní platí:
1. Uţivatel bude mít veškerá práva na relaci Majetek společnosti.
2. Uţivatel bude mít navíc právo pro přidávání nových zaměstnanců do relace Zaměstnanci.
3. Uţivateli odebereme práva na mazání záznamů z relace Majetek společnosti.
4. Všem uţivatelům nastavíme práva na příkaz SELECT v celé databázi.
3.1.4 Transakční příkazy (TCC)
Transakce jsou nedílnou součástí relačních i objektových databází. Představují ucelenou logickou
jednotku, sloţenou z několika SQL příkazů, která se provádí samostatně. Tím zabezpečují integritu
dat při provádění změn, a proto jsou nezbytné především u rozsáhlejších příkazů.
Pokud bychom například chtěli globálně zvýšit mzdy o 10% a z jakéhokoliv důvodu by se změna
nepodařila provést u všech zaměstnanců a aplikace by se po chybě pokusila provést příkaz opakovaně, nastala by situace, kdy zčásti mzdy zvednou o 21% a zčásti jen o 10%. A to pouze
v případě, ţe by se příkaz na druhý pokus provedl úspěšně. Z tohoto důvodu je nutné mít moţnost
odvolat všechny provedené změny, pokud se kdykoliv vyskytne chyba, tedy pouţít transakce.
Kaţdý SQL příkaz ve své podstatě začíná novou transakci. Příkazy DDL a DCL obsahují tzv. „auto
commit―, který potvrdí změny v databázi automaticky po vykonání příkazu. Příkazy DML je nutné
potvrdit příkazem COMMIT, aby změny v databázi byly trvalé. Podívejme se na příklad transakce
sloţené z více DML příkazů.
Obrázek 16: Transakce v jazyce SQL (psql)
Transakce na obrázku výše zvyšuje plat zaměstnancům podle osobního hodnocení o 10% nebo
8%, případně 4%. Jedná se o velmi zjednodušený příklad, který slouţí pouze pro demonstraci syntaxe transakcí. V praxi bývají transakce mnohonásobně delší a sloţitější.
3.2 Produkty na trhu
Jako nejpouţívanější databázový model mají relační databáze na trhu několik desítek úspěšných
systémů pro řízení databází (DBMS). Není moţné jednoznačně určit „tu nejlepší― databázi, vţdy
záleţí na úhlu pohledu, na vyuţití, na potřebách konkrétního informačního systému. V této kapitole
jsou představeny nejznámější a nejpouţívanější z nich. Kaţdá databáze můţe být vhodná pro něco jiného, vyuţívaná více v určitém odvětví – proto zde neuvádím ani ţebříček oblíbenosti
ani srovnání databází z hlediska vyuţívání a podobné statistiky.
- 25 -
3.2.1 Oracle
Aktuální verzí je Oracle Database 11g, multiplatformní databázový systém dostupný pro všechny
platformy také s podporou 64 bitové architektury (kromě neplacené verze Express Edition). Vyuţívá standardizovaný dotazovací jazyk SQL-92, který rozšiřuje o vlastní funkčnosti především
pro správu dat (Partitioning Advisor, Automatic Partitioning, Oracle Advanced Compression, materializované pohledy OLAP a další), imperativní programovací jazyk PL/SQL a další moţnosti
pro snazší správu a řízení databáze. (Procházka 2009) (Oracle Corporation nedatováno)
Oracle databáze je nabízena ve čtyřech verzích:

Express Edition je bezplatná základní verze, ale je omezená na 1 jádro CPU, 1GB RAM
a 4GB dat a zahrnuje pouze některá moţná Oracle rozšíření pro správu databází. Na serveru je pak moţné současně provozovat pouze jednu instanci databáze. Tato verze je určena pro menší začínající projekty, s jejichţ rozšiřováním je moţné koupit licenci na vyšší
verzi Oracle databáze.

Standard Edition One omezuje pouze maximální počet procesorových jader, které mohou
být aţ dvě. Jedná se jiţ o licencovanou verzi, jejíţ cena se odvíjí především od pouţitých
procesorů. Na rozdíl od Express Edition zahrnuje více rozšiřujících Oracle funkčností.

Standard Edition se od předchozí verze liší podporou aţ čtyř procesorových jader a zahrnuje více funkčností pro podporu škálovatelnosti.

Enterprise Edition jako jediná není omezena ani počtem procesorů ani podporou rozšiřujících Oracle funkčností, z nichţ některé jsou jiţ vestavěné a některé je moţné volitelně dokoupit. (Oracle Corporation nedatováno)
Oracle je beze sporu jeden z největších hráčů na trhu databázových řešení. Popis všech funkčností, které Oracle nabízí, by rozsahem vydal na celou publikaci, to však není cílem této práce. Zájemcům doporučuji oficiální stránky společnosti Oracle (http://www.oracle.com).
3.2.2 Microsoft SQL Server
Aktuální verzí je Microsoft SQL Server 2012, výkonný relační systém, který je povaţován za bezpečný a snadno škálovatelný. (Microsoft Corporation nedatováno) Je nabízený ve třech hlavních edicích:

Standard Edition nabízí základní databázové funkčnosti včetně reportování a analytických
nástrojů. Tato edice je omezena na 16 procesorových jader.

Business Intelligence je zaměřena na rychlé vyhledávání dat (funkce Power View umoţňuje vizuální procházení dat).

Enterprise Edition doplňuje k funkčnostem předchozích verzí nové nástroje pro řízení bezpečnosti a vysoké dostupnosti (např. funkce ColumnStore). (Microsoft Corporation 2012)
- 26 -
Dále jsou k dispozici edice známé z předchozích verzí – Developer (verze Enterprise určená pouze
pro účely vývoje a testování), Web (levnější edice určená pro webové aplikace) a Express (verze
zdarma pro malé projekty s omezením na jeden procesor, 1GB RAM a 10GB dat). (Microsoft
Corporation 2012)
Pro někoho můţe být značnou nevýhodou závislost na Microsoftu, tuto databázi lze spustit pouze
v operačním systému Windows.
3.2.3 MySQL
Aktuální verzí je MySQL 5.5, coţ je multiplatformní open source databázový systém dostupný
jak pod bezplatnou licencí GPL, tak pod komerční placenou licencí. Aktuálně ji vyvíjí společnost
Oracle Corporation, která ji získala odkoupením společnosti Sun Microsystems roku 2010. (Oracle
Corporation nedatováno) Spekulovalo se nad budoucností této databáze pod vedením Oracle Corporation, ale společnost se rozhodla ji dále vyvíjet a podporovat. Získává tak silné postavení na trhu
velkých projektů s komerční databází Oracle i na trhu menších, především webových, aplikací
s databází MySQL.
MySQL je povaţována za velmi rychlou databázi, která však kvůli zaměření na rychlost postrádá
mnoţství funkcí nabízených konkurenčními produkty (především PostgreSQL a Firebird). (Zajíc
2005) Je však moţné, ţe tyto nedostatky se odstraní s novým plánem vývoje, který představil Oracle Corporation, tedy s novou verzí přidat méně funkčností, které však budou kvalitněji propracované. Aţ nová verze ale ukáţe, jakým směrem se bude MySQL pod vedením Oracle Corporation
ubírat.
3.2.4 PostgreSQL
Nejnovější verzí je PostgreSQL 9.1, multiplatformní open source databázový systém vydávaný
pod bezplatnou licencí BSD. Vychází především ze standardu SQL-92 a SQL-99, který, stejně
jako ostatní databázové systémy, rozšiřuje o vlastní funkčnosti a procedurální jazyk PL/pgSQL.
PostgreSQL je označován za volně dostupný Oracle, především kvůli rozsahu nabízených rozšiřujících funkčností a stabilitě, díky které je vhodný také pro komerční pouţití i u větších aplikací.
(Kocan, Databáze dneška podevatenácté 2009)
Zahrnuje také většinu datových typů definovaných standardem SQL-2008 a podporuje práci
s multimediálními soubory. (The PostgreSQL Global Development Group nedatováno)
„Komunita okolo této platformy patří mezi největší na světě a za velmi kvalitní lze považovat také
dokumentaci. Na druhou stranu bývají nové vlastnosti zapracovávané až v okamžiku jejich faktické
potřeby, což není vždy zcela ideální stav. O kvalitách PostgreSQL svědčí nejen nabízená funkčnost, ale také jednotlivá nasazení – v rámci České republiky jmenujme například doménový registr
CZ.NIC nebo rezervační systém společnosti StudentAgency, ze zahraničních pak systémové aplikace společnosti Skype.“ (Kocan, Databáze dneška podevatenácté 2009)
- 27 -
3.2.5 Firebird
Aktuální verzí je Firebird 2.5, open source relační databázový systém od společnosti Borland. Podporuje moderní bezpečnostní mechanismy, 64bitovou architekturu, je multiplatformní a nabízí vysoký výkon při relativně nízkých systémových nárocích. (Firebird Foundation Incorporated nedatováno)
Nejčastěji vyhledávanou edicí je Embeded, která je sloţena z několika málo souborů, jeţ obsahují
veškerou funkcionalitu. Není tedy potřeba cokoliv instalovat, coţ je pro koncového zákazníka výhodné. Dalšími variantami pak jsou edice SuperServer, která sdílí svoji cache paměť mezi jednotlivými spojeními a pouţívá vlákna pro obsluhu kaţdého spojení, a edice Classic, která spouští nezávislý proces pro kaţdé spojení. (Cantu nedatováno)
Velkou nevýhodou Firebirdu je nedostatečná dokumentace. Lze sice za poplatek získat ucelenější
dokumentaci, ale všeobecně dokumentace k Firebirdu vzniká i s několikaletým zpoţděním. Moţností pak je pouţít dokumentaci databáze InterBase, ze které se Firebird roku 2000 odštěpil.
(Cantu nedatováno)
3.2.6 DB2
Aktuální verzí je DB2 9.7, multiplatformní databázový systém nabízený v několika placených i neplacených edicích společností IBM.

Zdarma je nabízena edice Express-C, která můţe být pouţita na libovolném serveru, ale
vyuţije maximálně dvě procesorová jádra a 2GB RAM. Za poplatek je moţné získat technickou podporu k této edici.

Pro malé a střední podniky je určena jiţ placená edice Express, která podporuje aţ čtyři
procesorová jádra, 4GB RAM a kromě v dnešní době běţných databázových funkčností
také cloud computing a virtualizaci.

Edice Workgroup Server na rozdíl od Express edice není omezena počtem procesorových
jader ani velikostí operační paměti.

Pro velké společnosti je určena edice Enterprise Server zaměřená na škálovatelnost.

Edice Advanced Enterprise Server obsahuje pokročilé funkce pro řízení a konfiguraci databází, je zaměřena na jednoduchou správu a vývoj databází, ladění výkonu, zabezpečení
dat (pomocí Label Based Access Control), komprese a podobně. (IBM Corp. nedatováno)
Platforma DB2 je synonymem pro vysoký výkon a vysokou dostupnost a je povaţována za ideální
platformu pro budování a provoz rozsáhlých datových skladů. Bezpečnostní funkce umoţňují šifrování dat i určení přístupových práv aţ na úroveň jednotlivých záznamů i atributů tabulky. (Kocan,
Databáze dneška potřinácté 2009)
- 28 -
OBJEKTOVÉ DATABÁZE
4.
Relační databáze jsou a zřejmě i nadále zůstanou hlavním prostředkem pro správu dat komerčních
aplikací, které jsou charakteristické velkým objemem údajů s jednoduchou strukturou. Řada aplikací, například z oblasti designu, multimédií, geograﬁckých systémů apod., však potřebuje takový
datový model, který umoţní lepší korespondenci mezi sloţitými reálnými daty a jejich reprezentací
v databázovém systému (Švec 2003) a proto v 80. letech vznikl tlak na vývoj nových databázových
systémů, které by lépe dokázaly pracovat s objekty. Objekty jsou jako stavební jednotky modelující
reálný svět lépe neţ relace.
Odpovědí jsou objektové databáze, které vznikly na počátku 90. let jako reakce na problémy
s ukládáním a zpracováním objektů v relačních databázích.
Objektové databáze se začaly objevovat nejprve v oblasti strojírenství, následně ve finančnictví
a v oblasti telekomunikací. Aktuálně se objektové databáze uplatňují také na trhu interaktivních
a dynamických webových stránek, multimediálních systémech a geografických informačních systémech. (Conolly, Begg a Holowczak 2009)
Často se ve svém okolí setkávám s názorem, ţe hlavní slabinou objektových databází je absence
standardů, formálního modelu dat, dotazovacího jazyka apod. Tyto výtky však není přesná, neboť
několik významných dodavatelů (např. Sun Microsystems, Objectivity Inc., Versant Corporation
a další) zaloţilo roku 1991 společenství Object Data Management Group (ODMG), které spojovalo
na tři sta komerčních firem, a které jiţ definovalo několik standardů, mezi kterými najdeme např.:

Object Model (určuje standardní model sémantiky databázových objektů),

Object Query Language (objektový dotazovací jazyk jako nadmnoţina SQL),

Object Definition Language (jazyk pro definici objektů),

Object-to-Database Mapping (přímé ukládání objektů a mapování objektů na databázi).
Problémem však zůstává nerespektování těchto standardů ze strany výrobců. Dalším problémem
je jazyk UML, který nepodporuje všechny potřebné konstrukce k modelování objektových databází.
Lze je však do UML doplnit.
Pod obecným označením „objektové databáze― se skrývají dva vzájemně odlišné datové modely:
a) Objektově relační datový model, který představuje evoluční trend vývoje. Jde o doplnění
relačního datového modelu o moţnost práce s některými datovými strukturami, které známe z oblasti objektově orientovaných programovacích jazyků. Většina výrobců velkých relačních databázových systémů (např. Oracle) zvolila tuto variantu a ve skutečnosti tedy
dodávají objektově relační databáze (ORDBMS). Objektově relační datový model
ale ve svých principech zůstává původním relačním datovým modelem.
b) Objektově orientovaný datový model (ODM), který představuje revoluční trend vývoje. Jde
o nový datový model, který není postaven jako rozšíření relačního datového modelu.
- 29 -
Do jisté míry zde jde o renesanci původního síťového datového modelu, který je doplněn
o moţnost práce s objekty tak, jak je známe z objektového programování. Na základě
ODM vznikly objektově orientované databáze (OODBMS). (Loomis 1994)
V praxi se však označením objektové databáze (ODBMS), není-li uvedeno jinak, myslí pouze druhý
zmiňovaný datový model, objektově orientované databáze zaloţené na objektově orientovaném
datovém modelu.
Mezi hlavní výhody ODM patří rozšířené modelovací moţnosti, moţnost přidávání nových datových typů, odstranění impedančního nesouladu (neboli odlišností mezi objektovým a relačním přístupem), podpora pokročilých databázových aplikací, výrazně bohatší dotazovací jazyk a často se
také uvádí zlepšení výkonnosti, na které poukazuje řada výkonnostních testů. „Například v letech
1989 a 1990 bylo provedeno testování výkonnosti ODBMS GemStone, Ontos, ObjectStore, Objectivity/DB a Versant proti RDBMS INGRES a Sybase. Výsledky ukázaly v průměru třicetinásobné
zvýšení výkonnosti u ODBMS ve srovnání s RDBMS.“ (Conolly, Begg a Holowczak 2009)
Určité často zmiňované nevýhody spojené se standardizací jiţ byly zmíněné výše. Mezi další nevýhody ODM pak můţeme zařadit nedostatek zkušeností ze strany výrobců, sloţitost a také slabší
podporu zabezpečení.
Výhodou pouţití objektově relačních databází (např. Oracle 8.x, DB/S Extenders) je zachování
stávajícího relačního modelu, se kterým jiţ mají uţivatelé zkušenosti. Většina firem tak nemusí
investovat nemalé finanční prostředky do nových technologií a do vzdělávání a přesto mohou
k datům přistupovat jako k objektům a vyuţívat nástroje objektového přístupu.
Zjevnou nevýhodou ORDBMS je pak sloţitost a s tím spojené vyšší náklady. Dalším problém nastává v jisté rivalitě mezi přívrţenci RDSMB a zastánci OODBMS, kteří nepovaţují propojení obou
řešení za výhodné, ale spíše naopak, coţ pravděpodobně zapříčinila také změna terminologie,
která se liší jak od terminologie objektové tak relační.
Vyuţití, výhody a nevýhody OODBMS (dále jen ODBMS) podrobněji rozebírají další kapitoly, které
se zaměřují na jednotlivé standardy skupiny ODMG (Object Model, Object Definition Language
a Object Query Language).
4.1 Objektový datový model
Základní charakteristiky objektového datového modelu lze shrnout do následujících šesti bodů:
1) Podpora více typů kolekcí objektů (relační model podporuje pro uloţení dat pouze jeden
typ a to relační tabulku) tak, jak je známe z vyšších programovacích jazyků: pole, spojový
seznam, slovník, zásobník a další. Kolekce reprezentuje úloţiště pro objekty, viz tabulku 2:
Kolekce definované ODMG ODL v kapitole 4.3 Object Definition Language (ODL).
2) Objekty se skládají z vnitřních datových sloţek (coţ mohou být opět objekty) a z metod,
obojí je typem atributu, který známe z relačních databází.
- 30 -
3) Pokud mají objekty společné atributy, jsou polymorfní, i kdyţ jejich třídy mezi sebou nedědí.
4) Kaţdý objekt má systémem přidělený vlastní jednoznačný identifikátor, obvykle označovaný jako OID (Object IDentifier). OID plní úlohu ukazatele do virtuální paměti a pro objekt
je neměnný. Díky OID lze rozlišovat mezi rovností a totoţností objektů a navíc odpadá
nutnost tvorby primárních klíčů, kterou známe z relačních databází (primární klíče však neslouţí jako ukazatelé do paměti).
5) V databázi lze pracovat i se soustavou objektů, která je sama o sobě aplikací. Objektová
databáze pak neslouţí pouze jako úloţiště dat pro externí program, ale část (popřípadě
i celek) výpočetního programu můţe být spouštěn v rámci objektového databázového serveru.
6) Jednotliví uţivatelé vidí pouze ty atributy, ke kterým mají přístupová práva. (Merunka 2008)
Můţeme si tedy všimnout jistých odlišností oproti objektově orientovaným programovacím jazykům,
jako je jiný přístup k polymorfismu a migraci mezi třídami. Pro přehlednost uvádím tabulku porovnávající terminologii relačního a objektového datového modelu.
- 31 -
Tabulka 2: Porovnání relační a objektové terminologie
Relační datový model
Objektový datový model
Záznam
Objekt
Tabulka
1) Třída
2) Kolekce
Atribut
1) Datová sloţka objektu
2) Metoda objektu
Primární klíč
OID
Propojení záznamů
Skládání objektů
Zdroj: (Merunka 2008), upraveno
4.2 Objektový model podle ODMG
Tato specifikace objektového modelu vydaná skupinou Object Data Management Group definuje
především objekty a literály, atributy, vztahy, objektové typy a předdefinované typy. Tyto základní
modelovací primitivy si v této kapitole trochu přiblíţíme.
4.2.1 Objekty a literály
Základními modelovacími prvky jsou objekt a literál. Jak jiţ bylo popsáno v předchozí kapitole,
kaţdý objekt má svůj jedinečný identifikátor (OID), který je nejen neměnný, ale ani po smazání
objektu jiţ není moţné OID tohoto objektu opětovně pouţít. Identifikátor objektu je automaticky
generovaný systémem a pro programátora i koncového uţivatele je obvykle skrytý. Krom OID je
objekt označen také jedním nebo více jmény, která by měla být srozumitelná pro uţivatele a slouţit
jako vstupní body do databáze. (Cattel a Barry 2000)
Druhý modelovací prvek, literál, je definován jako datová entita určitého datového typu. Obvykle
se s nimi setkáváme jako s atributy objektů. Je to hodnota atributu, která se během běhu programu nemění a je read-only. Na rozdíl od objektu nemá literál ţádný identifikátor.
Hlavní rozdíl mezi objekty a literály je v proměnlivosti neboli schopnosti měnit data bez změny
identity. Objekty jsou proměnlivé, takţe kdyţ změníme hodnoty jejich datových sloţek, nezměníme
jejich identitu. Literály ale proměnlivé nejsou. (Švec 2003)
Další vlastností objektů je doba platnosti, která se stanovuje při vytvoření objektu. Objekt můţe být
buď perzistentní anebo transientní. Perzistentní objekty jsou ty, které ukládáme do databáze, protoţe je potřebujeme uchovat i v době, kdy samotný program neběţí. Uloţení perzistentních objektů
spravuje ODBMS. Transientní objekty jsou naopak ty dočasné, které program vyuţívá pouze během svého běhu a při vypnutí programu se jejich hodnota ztrácí. Tyto objekty se neukládají
do databáze, paměť pro transientní objekty alokuje a uvolňuje sám běhový systém programovacího jazyka. (Merunka 2008) Příkladem můţe být funkce Add To Memory (M+) na kalkulačce, která
- 32 -
označí záznam za perzistentní a uloţí ho do paměti, kde je uchován i po vypnutí kalkulačky, zatímco ostatní záznamy se s vypnutím ztrácejí.
4.2.2 Atributy a vztahy
Atribut si lze představit jako vlastnost objektu. Pokud například máme objekt reprezentující jednoho
konkrétního člověka (objekt bude instancí třídy Člověk), pravděpodobně bude mít definované atributy jméno, příjmení, datum_narození, rodinný_stav apod.
Na rozdíl od atributu, který je vlastností jednoho objektu, je vztah charakteristikou vazby mezi dvěma objekty. Příkladem vztahu mezi dvěma objekty, instancemi třídy Člověk, můţe být například
vazba, která určuje příbuzenství konkrétních lidí. Vazby, také označované jako relace, nemají jména, ale tzv. traversal path.
Dle standardu ODMG lze pouţít pouze binární vztahy (tedy vztahy právě dvou objektů)
s kardinalitou 1:1, 1:N nebo M:N.
4.2.3 Objektové typy
Objektové typy jsou definované třídami a rozhraními, které známe z objektového programování.
Rozhraní definuje pouze abstraktní chování (abstraktní operace) objektového typu a není moţné
vytvořit jeho instanci (vytvořit podle něj objekt). Rozhraní se typicky pouţívá pro definici abstraktních operací, které budou definovány ve zděděných třídách. Třída pak definuje atributy a chování
objektového typu neboli instance dané třídy.
ODMG rozšiřuje třídu z OOP o tzv. extent., coţ je automaticky spravovaná kolekce všech objektů
dané třídy. Pokud navíc vyuţíváme dědičnosti tříd, bude extent zděděné třídy podmnoţinou extentu rodičovské třídy. Na rozdíl od relačního přístupu, kde se extent vytváří pro kaţdou definovanou
relaci, u objektového přístupu je definice extentu nepovinná. (Cattel a Barry 2000)
4.3 Object Definition Language (ODL)
Objektové databáze jsou zaloţeny na schématu definovaném pomocí Object Definition Language,
coţ je jazyk vytvořený pro definici specifikací objektových typů. ODL je tedy jakýmsi ekvivalentem
jazyka DDL, který se pouţívá v RDBMS. ODL se pouţívá obvykle v první fázi návrhu objektové
databáze, protoţe je nezávislý na programovacím jazyce.
Problémem ovšem zůstává nedodrţování standardů ODMG ze strany výrobců databází
a tak se často stává, ţe objektové databáze jazyk ODL (spíše výjimečně také jazyk OQL, viz níţe)
nepodporují a jsou doplněny jinými způsoby a metodami pro definici databázových objektů. Často
však rozšiřují pouţívané objektové programovací jazyky a práce s databází se pak můţe stát jednodušší a přirozenější, ale ztrácí hlavní přidanou hodnotu jazyka ODL – platformovou nezávislost.
- 33 -
Na obrázku 17: Definice třídy podle ODMG ODL můţeme vidět, jak ODL definuje třídu
v objektových databázích (vyhrazené výrazy ODL jsou zvýrazněny modrou barvou a nepovinné
údaje jsou ohraničeny ‗[‗ a ‗]‘):
Obrázek 17: Definice třídy v ODMG ODL
Tímto způsobem jazyk ODL specifikuje také rozhraní, datové struktury a v podstatě veškerou moţnou práci s objektovými databázemi.
Pokud se vrátíme k příkladu jednoduché třídy Člověk, mohla by definice této třídy v ODL vypadat
následovně:
Obrázek 18: Definice třídy Person v ODMG ODL
Třídě Person jsme přiřadili extent people, kde najdeme všechny vytvořené instance této třídy. Vyhrazené slovo persistent značí, ţe instance této třídy budou perzistentní, ukládané do databáze.
Třída má dále atributy name a surname datového typu string neboli textový řetězec, atribut
dateOfBirth datového typu Date a také atribut MaritalStatus, coţ je výčet všech moţných rodinných
stavů (bude tedy moţné k jedné instanci třídy Person zvolit nejvýše jednu ze zadaných
- 34 -
moţností – Single, Married, Divorced nebo Widowed). Atributy name a surname mají omezení
notnull, je tedy nutné při ukládání nového objektu do databáze tyto atributy vţdy vyplnit.
Třída Person má definovanou vazbu sama se sebou, kdy instance můţe být s několika dalšími
instancemi této třídy ve vztahu children/parents. Označení set a list v definici vazby značí mnoţinu
objektů, jedná se proto o vazbu typu M:N.
Kromě datových typů string, enum a Date, ODL definuje také následující datové typy (atomické
literály):

číselné datové typy: long, long long, short, unsigned long, unsigned short, octet, float,
double,

logický datový typ: boolean,

znakový datový typ: char.
Speciálním datovým typem je typ any, který značí objekt libovolného datového typu. (Cattel a Barry
2000)
ODL definuje také kolekce, coţ jsou mnoţiny literálů nebo objektů. Konkrétně ODL podporuje set,
bag, list, array a dictionary (Cattel a Barry 2000). V následující tabulce (Tabulka 3: Kolekce definované ODMG ODL) najdete definice těchto kolekcí.
Tabulka 3: Kolekce definované ODMG ODL
Kolekce
Popis
Set
Neuspořádaná mnoţina prvků stejného typu. Neobsahuje duplikáty.
Bag
Neuspořádaná mnoţina prvků stejného typu, která můţe obsahovat duplikáty.
List
Uspořádaná mnoţina indexovaných prvků stejného typu.
Array
Uspořádaná mnoţina prvků stejného typu, jejichţ pozice je indexována. Na
rozdíl od listu má pevnou délku.
Dictionary
Neuspořádaná mnoţina dvojic hodnota-klíč, která můţe obsahovat duplikáty.
Zdroj: (Hoffer, J.A., 2008, kap. 15 s. 3), upraveno
Kromě atomických literálů a kolekcí ODL definuje také strukturované literály, zkráceně struktury.
Struktury mají fixní počet elementů, element můţe být jak objekt, tak i literál. ODMG Object Model
definuje struktury date, interval, time, timestamp. ODMG Object Model je ale rozšiřitelný, a proto
si vývojář můţe definovat vlastní struktury, které potřebuje. Pro tento případ Object Model obsahuje generátor struct. (Cattel a Barry 2000) Pouţití je velmi podobné jako při definici třídy, rozdíl je
v tom, ţe struktura můţe obsahovat pouze objekty a literály, nikoliv operace, vazby apod. Definice
struktury adresa by mohla vypadat například takto:
- 35 -
Obrázek 19: Definice struktury
Podle této definice struktury nyní můţeme vytvářet atributy stejným způsobem jako podle jiných
datových typů.
Podle definice třídy lze v ODL vytvořit instanci jednoduše příkazem:
<object_name> <class_name>(<attribute_name>:<value>);
Konkrétně u naší třídy Person bychom tedy mohli vytvořit například Petra Nováka a jeho syna Jana
Nováka příkazy:
NovakPetr84 Person(name „Petr“, surname „Novak“, dateOfBirth 4/5/84);
NovakJan09 Person(name „Jan“, surname „Novak“);
NovakPetr84 Person(children NovakJan09);
Při vytváření instance nemusí být všechny atributy povinné, záleţí však na návrhu databáze.
My máme v definici třídy povinné pouze atributy name a surname.
Jak jiţ bylo napsáno v úvodu, v praxi se ODL příliš nepouţívá, neboť k tvorbě databázových objektů lze vyuţít přímo moţnosti vyšších programovacích jazyků. Například ODBMS db4o lze jako knihovnu připojit k projektu psanému v jazyce .NET nebo Java a k databázi pak přistupovat metodami
psanými pro daný jazyk, coţ je obvyklejší postup, vzhledem k jednoduchosti pouţití.
4.4 Objektový dotazovací jazyk (OQL)
Nepostradatelnou součástí kaţdého databázového systému je kvalitní dotazovací jazyk. Dalším
standardem vydaným skupinou ODMG je proto objektový dotazovací jazyk OQL – Object Query
Language. Editoři standardu OQL, kteří se podíleli také na jeho vývoji, popsali OQL slovy: „It is
complete and simple. “ (Cattel a Barry 2000).
Avšak objektové databáze mají velmi sloţitou datovou strukturu s mnoha objekty provázanými
velkým mnoţstvím vazeb. Důsledkem jsou sloţité dotazovací algoritmy a také jejich niţší efektivita
v porovnání s relačními databázemi. Další komplikací při zpřístupňování dat vyhledávacím algoritmům je pak typická vlastnost OOP – zapouzdření. Vzhledem k těmto vlastnostem ODBMS
je dotazovací jazyk OQL pouţíván pouze pro vyhledávání a výběr objektů, neslouţí k manipulaci
s daty jako SQL u relačních databází. (Švec 2003) K manipulaci s daty slouţí ODL.
Dále je jazyk OQL zaloţen na těchto principech:

OQL je přímo závislý na ODMG Object Model.
- 36 -

OQL je záměrně velmi podobný SQL-92, který rozšiřuje o objektově-orientovanou notaci.

OQL je snadno pouţitelný a přenositelný.

OQL poskytuje prostředky pro práci s objekty, mnoţinami, strukturami apod.

Výsledek jakéhokoliv dotazu musí odpovídat typu definovanému v datovém modelu.

OQL je moţné, podobně jako SQL, pouţít jako samostatný jazyk nebo ve formě vnořeného
zápisu do jiných jazyků, pro které je definována vazba na ODMG. (Cattel a Barry 2000)
Podporovanými jazyky ze strany OQL jsou Smalltalk, C++ a Java. (Conolly, Begg a Holowczak
2009). V poslední době se však OQL rozšiřuje i mezi jiné technologie a můţeme se tak setkat například s variantou OQL.NET určenou pro jazyk .NET, variantou HQL (Hibernate Query Language)
určenou pro propojení objektů v jazyce Java s různými databázemi a dalšími implementacemi
OQL. I přes toto rozšiřování však standard OQL není plně přijat všemi výrobci a můţeme se
tak setkat s objektovými databázemi, které tento dotazovací jazyk nepodporují a obsahují jiné prostředky pro dotazování.
4.4.1
Syntaxe dotazu
Základní operátory pouţívané pro dotazování lze rozdělit do několika skupin:
1. Logické operátory: not, and a or.
2. Aritmetické operátory: +, -, *, /, mod (modulo).
3. Relační operátory: <, >, <=, >=, =, !=.
4. Operátory pro práci s řetězci: || (konkatenance), in (testuje přítomnost znaku v řetězci), like
(testuje, zda řetězec odpovídá vzoru), s[i] (vrací i-tý znak řetězce), s[l:h] (vrací podřetězec
od l-tého znaku po h-tý znak).
Dále OQL definuje operace nad kolekcemi exist(element) a unique(element), které vracejí hodnotu
true, pokud kolekce obsahuje hledaný prvek aspoň jednou respektive právě jednou. V opačném
případě vracejí hodnotu false. (Cattel a Barry 2000) (Švec 2003)
Lze pouţít také většinu operací a agregačních funkcí, pouţívaných v SQL jako min(), max(), sum(),
union a další. Také samotná syntaxe je jazyku SQL velmi podobná, jak je uvedeno v principech
OQL, vychází z jazyka SQL-92.
Základní konstrukce dotazu select-from-where vypadá následovně:
Obrázek 20: Syntaxe jednoduchého Select dotazu
- 37 -
Po vyhrazeném slovu select je nepovinný výraz distinct, který filtruje výsledky a odstraňuje duplicitní záznamy. Lze jej vyuţít například pro změnu mnoţiny výsledků typu bag, kterou funkce distinct
změní v mnoţinu typu set.
U třídy Person definované v kapitole 4.3 Object Definition Language (ODL) je moţné příkaz select
pouţít například pro vyhledání všech lidí s příjmením „Novák―:
Obrázek 21: Vyhledání podle atributu
Dalším moţným příkazem je vyhledávání přes vazby. Je například moţné vypsat všechny děti
Petra Nováka (viz 4.3 Object Definition Language). Nelze zde pouţít jednoduchý příkaz pro výpis
atributu p.children.name, protoţe se jedná o mnoţinu odkazů, proto vyuţijeme opět příkaz select,
který vrátí mnoţinu hledaných výsledků:
Obrázek 22: Vyhledávání přes vazby
Podobně jako v SQL lze i v OQL příkazy skládat a zanořovat do sebe. Následující obrázek zobrazuje strukturu dotazu, který vyhledává adresy dětí všech lidí z ulice „Main Street―, kteří mají
alespoň dvě děti, a nakonec ještě výsledné adresy filtruje a zobrazí jen adresy dětí, které nebydlí
ve stejné ulici jako rodiče:
Obrázek 23: Agregační funkce a sloţená podmínka
Jazyk OQL obsahuje také konstrukce pro vytváření nových objektů a literálů, avšak pouze tranzientních. Ty slouţí pro získání objektů jako výsledků dotazu. Výsledkem dotazu je vţdy objekt, často nějaká kolekce objektů.
Na příkladech výše jsou ukázány pouze základní typy konstrukcí, kompletní výčet konstrukcí
a ukázky pouţití lze najít například v (Cattel a Barry 2000).
- 38 -
4.5 Produkty na trhu
Ačkoliv objektové databáze nemají takové zastoupení v komerčních produktech jako databáze
relační, ukáţeme si v této kapitole, ţe nabídka ze strany objektových databází je také rozmanitá.
Všechny zde zmiňované databáze podporují standardní funkčnosti jako transakce (včetně ACID
principů), škálování, přístupy více uţivatelů apod.
4.5.1
Db4o
Tato multiplatformní open source objektová databáze od společnosti Versant Corporation je určená
pro technologie Java a .NET. Aktuální verzí je db4o 8.0. Pro nekomerční produkty a produkty pod
licencí GPL je nabízena zdarma, pro komerční produkty je nabízena placená verze s plnou podporou. Součástí obou verzí je plně integrovaná podpora LINQ pro .NET a Native Queries, dále podporují Query By Example a SODA Query API. (Versant Corporation nedatováno)
Databáze je vhodná i pro středně velké projekty a v embedded verzi ji ocení především začátečníci, pro které je dostupný také podrobný tutoriál. Nabízí IDE plug-in pro vývojové prostředí Eclipse
a Microsoft VisualStudio. Nevýhodou však je niţší rychlost při dotazování typu Native Queries
a nedostatečná podpora pro práci se soubory (především textovými). (Db4o nedatováno)
Tuto databázi vyuţívají pro své projekty například firmy Seagate Technologies, Boeing, IBM, Intel
a další. (Versant Corporation nedatováno)
4.5.2
Caché
Caché je úspěšná multiplatformní databáze od společnosti InterSystems určená především
pro webové aplikace a aplikace typu klient-server. Propagována je především její rychlost při zpracovávání SQL, kdy prý dosahuje aţ 5x lepších výsledků neţ relační databáze. Společnost navíc
garantuje vrácení peněz za licence v případě nespokojenosti s jejich produktech (platí rok po zakoupení licencí). Nejnovější verzí je Caché 2012.1. (InterSystems Corporation nedatováno)
Tato platforma zaloţená na standardu ODMG umoţňuje vyvíjet jak aplikace zaloţené na objektovém přístupu, tak pouţívat zaţité postupy ze světa relačních databází. Při tom všem navíc nabízí
stabilitu, rozšiřitelnost a bezpečnost v podobě přístupových práv, rolí a šifrování dat. (Kocan,
Databáze dneška popatnácté nedatováno)
Mezi společnosti, které vyuţívají databázi Caché, patří například IKEM, IBM a Chess Logistics
Technology. (InterSystems Corporation nedatováno)
4.5.3
Versant Object Database
Multiplatformní objektovou databázi Versant vyvíjí společnost Versant Corporation. Aktuální verze
je Versant 8.0.2. Jedná se o komerční produkt, nikoliv o open source databázi jako db4o (také
vyvíjenou společností Versant Corporation). Primárně podporuje jazyky C++, Java a .NET a lze
ji pořídit jako embedded databázi.
- 39 -
Základní funkčnosti rozšiřuje mimo jiné o řízení ţivotního cyklu objektu, vlastní dotazovací jazyk
VQL podpobný SQL-92, multithreading a podporu JDO. (Versant Corporation nedatováno)
4.5.4
Objectivity/DB
Aktuální verzí je Objectivity/DB 10.2, komerční multiplatformní ODBMS od společnosti Objectivity
Inc. Zdarma je poskytována pouze zkušební verze trial na 60 dní, je tedy vhodná spíše pro komerční vyuţití. Nabízena je jak ve verzi 32bit tak 64bit pro všechny platformy. Má široký výběr API
- pro C++, Javu, Python, Smalltalk a obecný ODBC. Pro .NET technologie nabízí integrovanou
podporu LINQ. (Objectivity, Inc. nedatováno)
Objectivity/DB pouţívají společnosti Siemens, Ericsson a další. (Objectivity, Inc. nedatováno)
4.5.5
GemStone/S
GemStone/S je multiplatformní objektová databáze vyvíjená od poloviny 80. let (původně jako rozšíření jazyka Smalltalk) společností GemStone Systems. Obsahuje rozhraní pro jazyky Smalltalk,
Java, C a C++. (Merunka 2008) Pro svou speciální verzi dotazovacího jazyka Smalltalk DB tuto
databázi ocení především příznivci tohoto čistě objektového jazyka.
Aktuální verze GemStone/S 6.6 nabízí pesimistické i optimistické řízení transakcí, připojitelnost
na externí zdroj dat přes rozhraní pro relační databáze podle standardu SQL, správu přístupových
práv a další. Stejně jako jiné databázové systémy nabízí Gemstone/S bezplatnou verzi, avšak pouze pro operační systémy Linux a s omezením na jeden procesor, 4GB dat a 1GB RAM. (Merunka
2008)
Tuto databázi vyuţívají pro své projekty například společnosti Orient Overseas Container Line
(OOCL) a Navigant International/Northwest. (GemStone Systems nedatováno)
4.5.6
VelocityDB
Tento nově vznikající (od roku 2011) objektově orientovaný databázový systém je určen pro jazyk
C# .NET. Lze ho tedy spustit v OS Windows 7, případně ve frameworku Mono. Aktuální verze 1.2.1
je zdarma nabízena pouze jako trial verze, která ale není hardwarově limitována. Kromě distribuované verze je k dispozici také embedded verze. (VelocityDB nedatováno)
Zatím nelze mluvit o přínosné dokumentaci, natoţ pak tutoriálech a podpůrné komunitě. Na druhou
stranu je však potřeba zdůraznit, ţe za pouhý rok vývoje tato databáze splňuje poţadavky pro nasazení nejen u malých projektů. Kromě základních funkčností nabízí komprese, šifrování, funkci
automatického zotavení, integraci s Windows Authentication, podporu jazyka LINQ a další doplňky.
(VelocityDB nedatováno)
- 40 -
5. PRAKTICKÁ UKÁZKA RDBMS A ODBMS
V této kapitole si na příkladu fiktivní společnosti Bluedy+ Holding, a. s. ukáţeme práci s relačním
i objektovým přístupem v praxi. Nejprve si stručně představíme řešenou úlohu a vybereme databázové systémy, se kterými budeme pracovat. Následně navrhneme perzistentní (datovou) vrstvu,
kterou se pokusíme implementovat ve vybraných databázích.
5.1 Řešený problém
Cílem je navrhnout jednoduchý databázový model pro fiktivní firmu Bluedy+ Holding, a. s., která se
profiluje v oblasti stavebnictví převáţně na zateplování panelových a rodinných domů a výstavbu
pasivních a nízkoenergetických budov.
Firma Bluedy+ Holding, a. s. má sídlo v Praze, kde zaměstnává cca 100 lidí na různých pozicích
(management, obchod, apod.). Dále má tři dceřinné společnosti:
1. BluedyStav – společnost zajišťující všechny stavitelské práce. Tato společnost dodává
všechny potřebné lidské zdroje. Zaměstnává přibliţně 200 lidí a sídlí v Ústí nad Labem.
2. BluedyMat – společnost zajišťující potřebné materiály. Tato společnost dodává všechny
potřebné materiální zdroje a to primárně společnosti BluedyStav. Zaměstnává přibliţně 50
lidí a sídlí v Mostě.
3. BluedyFin – společnost zajišťující účetnictví a další podpůrné sluţby celé firmě Bluedy+
Holding, a. s. Zaměstnává přibliţně 30 lidí a sídlí v Teplicích.
Firma momentálně plánuje otevření nových poboček na Moravě a v Německu. Při návrhu databáze
je proto potřeba počítat s moţností rozšíření aţ o 100% v následujících dvou letech.
Kaţdý zaměstnanec holdingu získává sluţební výhody, které se řídí jistými pravidly. Získání těchto
výhod závisí na individuálním posouzení, dále se přihlíţí na společnost, ve které zaměstnanec
pracuje, na uzavřené smlouvě a také na době, po jakou zaměstnanec ve firmě pracuje. Základní
prehled nabízených benefitů zobrazuje následující tabulka.
- 41 -
Tabulka 4: Zaměstnanecké výhody Bludy+ Holdingu, a. s. a dceřinných společností
Bluedy+ Holding, a. s.
BluedyStav
BluedyMat, BluedyFin
< 2 měsíce
Notebook, Mobil, Stravenky
Stravenky
Stravenky
2 – 6 měsíců
Automobil
Mobil
Mobil
6 – 12 měsíců
Penzijní připojištění
> 12 měsíců
iPad2, Ţivotní pojištění
Ţivotní pojištění
iPad2
Tento prehled není striktní, zaměstnavatelé se ho nemusí drţet. Je ale třeba na aplikační vrstvě
vyřešit notifikace pro případ, ţe zaměstnavatel udělí výhodu mimo jeho rozsah.
Řízení projektů znázorňuje obrázek 24: Business model společnosti Bluedy+ Holding, a. s. Všichni
zaměstnanci jsou obsazováni do projektů a za kaţdý projekt je kompetentní jedna osoba z Bluedy+
Holdingu, a. s. Manaţerem/obchodníkem se zaměstnanec stává pouze na dobu řešení projektu,
poté je přeřazen opět do zaměstnanců Bluedy+ Holdingu, a. s., odkud můţe být najmut jako manaţer nového projektu. Jeden zaměstnanec můţe současně pracovat na více projektech najednou.
Kaţdý projekt patří právě jednomu zákazníkovi. O zákaznících se uchovávají základní kontaktní
údaje, navíc aţ dvě kontaktní osoby. U kaţdého zákazníka se dají dohledat všechny námi aktuálně
i v minulosti zpravované zakázky.
Obrázek 24: Business model společnosti Bluedy+ Holding, a. s.
Zdroj: Vlastní zpracování v Microsoft Visio 2010
- 42 -
5.2 Výběr databází
Pro účely porovnání objektového a relačního přístupu vyuţijeme databáze, které jsou dostupné
zdarma, ideálně pak bez hardwarových a jiných limitů.
Z relačních databází tak přichází v úvahu open source databáze z tzv. velké trojky – Firebird,
MySQL, PostgreSQL. Pro výbornou dokumentaci a podpůrnou komunitou volím relační databázi
PostgreSQL.
Pro svou ebmedded verzi pro jazyk C# a propracovanou dokumentaci včetně tutoriálů je pro naši
aplikaci vhodná objektová databáze db4o.
5.3 Návrh datové vrstvy
V této kapitole provedeme analýzu poţadavků na perzistentní vrstvu aplikace a navrhneme řešení
této vrstvy. Ukáţeme si také rozdílné metody a přístupy při návrhu datové vrstvy pro relační databáze a pro objektové databáze.
Pro modelování diagramů existuje několik různých notací. Ve všech příkladech níţe je pouţita
notace podle standardu UML, která se pouţívá nejen pro návrh datové vrstvy, ale také při objektové analýze a návrhu celého IS.
5.3.1 Relační návrh
Typicky se při návrhu RDBMS postupuje takzvaným stylem „shora dolů―, kdy postupnou transformací, začínající u business zadání, vznikají tři modely lišící se abstrakcí pohledu na datovou vrstvu. Z business zadání nejprve vzniká konceptuální model, jeho zpřesněním logický model a nakonec platformně specifický fyzický model.
Konceptuální model znázorňuje základní objekty (entity) a vztahy mezi nimi včetně multiplicit. Popisuje data statická, nezabývá se operacemi, které budou s daty probíhat. Můţe nabývat více podob, v příkladech je pouţit E-R model s UML notací.
- 43 -
Obrázek 25: Konceptuální model relační databáze
Zdroj: Vlastní zpracování v Enterprise Architect 8.0
Konceptuální model na výše lze popsat následujícími body:
1. Společnost tedy nabízí 0 aţ N zaměstnaneckých výhod, zaměstnává jednoho aţ N zaměstnanců a získává zákazníky.
2. Speciálním typem zaměstnance je manaţer/obchodník (vztah generalizace), který řídí
vţdy jeden tým. Nemá-li manaţer projektový tým, který by řídil, stává se z něj zaměstnanec Bluedy+ Holdingu, a. s.. Kaţdý zaměstnanec můţe vyuţívat 0 aţ N zaměstnaneckých
výhod.
3. Tým pracuje vţdy na jedné zakázce, tedy pro kaţdou zakázku se sestavuje nový tým s novým označením týmu a novým manaţerem.
4. Zakázka je zadávána zákazníkem, přičemţ kaţdý zákazník můţe zadat více zakázek.
Transformací konceptuálního modelu na model logický získáme konkrétní tabulky, které budou
v relační databázi implementované, zatím se však jedná o platformně nezávislý model. Transformace má několik kroků. Nejprve je potřeba doplnit entitám konceptuálního modelu atributy. Vícenásobné atributy (například telefonní číslo) je potřeba nahradit pevným počtem opakování nebo je
extrahovat do nové tabulky s vazbou 1:N. Nakonec je potřeba rozvrhnout tabulky propojené vazbou generalizace/specializace, tedy spojit je do jedné tabulky, nebo rozdělit atributy a přidat vhodnou vazbu, a nebo tabulky zcela oddělit. (Conolly, Begg a Holowczak 2009)
Logický model tedy znázorňuje základní implementované atributy relačních tabulek a jejich integritní omezení. Vše je stále platformově nespecifické.
Na obrázku níţe je ukázáno, jak by logický model pro Bluedy+ Holding, a. s. mohl vypadat. U kaţdé tabulky byly doplněny atributy, přičemţ podtrţený atribut značí omezení na jedinečnost (unique)
- 44 -
a znak hvězdičky omezení na povinnou hodnotu (not null). PK je označení primárního klíče, FK
značí cizí klíč. Datové typy jsou zatím platformně nezávislé a rozlišují pouze text, dlouhý text (poznámka) a číslo.
Vazba generalizace/specializace z konceptuálního modelu byla nahrazena vazbou tak, ţe kaţdý
manaţer/obchodník musí odkazovat na právě jednoho zaměstnance, jemuţ je rozšířením a kaţdý
zaměstnanec můţe odkazovat aţ na jednoho manaţera/obchodníka jako vedoucího týmu.
Obrázek 26: Logický model relační databáze
Posledním krokem v návrhu RDBMS je rozšíření logického modelu na fyzický model, který je jiţ
platformně specifický. K tomu je v případě návrhu pro Bluedy+ Holding, a. s. potřeba provést dvě
hlavní změny.
1. Nahradit datové typy tak, aby odpovídaly databázi PostgreSQL.
2. Upravit vazby M:N pomocí vazební tabulky na vazby 1:N.
- 45 -
Výsledný fyzický model pro databázi PostgreSQL je zobrazen na následujícím obrázku.
Obrázek 27: Fyzický model relační databáze
Fyzický model je „doslovnou předlohou― pro výslednou implementaci relační databáze, proto je
obvykle dodáván jiţ v anglickém jazyce. Fyzický model databáze Bluedy+ Holding, a. s. je značně
zjednodušený a nevystihuje všechny moţnosti PostgreSQL ani moţnosti relačních databází obecně. Pro účel srovnání s objektovým modelem (více v následující kapitole) je však dostačující.
5.3.2
Objektový návrh
Pro návrh objektové databáze existuje několik metodik a doporučení, zatím však ţádné řešení není
všeobecně přijato. Obvykle se při návrhu objektové databáze vychází z třídního diagramu samotné
aplikace a návrh je podřízen zkušenostem s objektově orientovanými programovacími jazyky. „Je
možné převzít relační techniky, ale potom dostaneme jen relační databázi v objektovém prostředí
a nevyužijeme všechny vlastnosti, které ODM má. Jinou možností je převzít schéma objektů a tříd
tak, jak jsou navrženy v aplikaci, která má s databází pracovat. To už je lepší, protože právě proto
byl objektový datový model vyvinut. Jenomže struktura objektů výhodná pro aplikaci může komplikovat jejich efektivní databázové zpracování.‖ (Merunka 2008)
- 46 -
Návrh objektové databáze společnosti Bluedy+ Holding, a. s. popsaný v této kapitole vychází částečně z metodiky BORM (Business Object Relation Modeling). Jedná se o původně českou metodiku orientovanou na podporu vývoje systémů zaloţených na čistě objektově orientovaných programovacích jazycích a nerelačních objektových databázích. (Merunka 2008)
U objektové analýzy budeme postupovat podle metodiky BORM, která pro business analýzu
a návrh aplikace vyuţívá tři různé objektové modely – business model, konceptuální model a softwarový model. Během transformace modelů se mění také význam pojmu objekt. Zpočátku se jedná o objekty reálného světa tak, jak je chápe zadavatel. V konceptuálním modelu jiţ obsahují základní pojmy objektově orientovaného paradigmatu, jako například polymorfismus, zapouzdření
a podobně. V závěrečné fázi modelování se pracuje s platformně závislými objekty, které obsahují
pojmy přímo odpovídající konstrukcím z objektově orientovaných programovacích jazyků. (Merunka
2008)
Business model společnosti Bluedy+ Holding, a. s. by mohl vypadat takto:
Obrázek 28: Business model objektové databáze
Zdroj: Vlastní zpracování v Microsoft Visio 2010
Podle metodiky BORM se při transformaci na konceptuální model vyberou z business modelu ty
objekty a vazby, které mají smysl pro datovou vrstvu aplikace. Navíc je doplněn o atributy a metody
objektů, které jsou zatím platformně nezávislé. Výsledný konceptuální model s multiplicitami je
zobrazen na obrázku níţe.
- 47 -
Obrázek 29: Konceptuální model objektové databáze
Zdroj: Vlastní zpracování v Architect Enterprise 8.0
V ideálním případě se od sebe konceptuální a softwarový model liší pouze datovými typy, které
jsou u softwarového modelu platformně specifické. Takové případy jsou ale spíše výjimečné, neboť
téměř vţdy zákazník pouţívá nějakou databázi nebo nástroj pro uchování elektronických dat
a návrh databáze se musí přizpůsobit formátu těchto jiţ existujících záznamů, případně databázi,
se kterou bude nová databáze propojena.
V takovém „ideálním― případě bude softwarový model databáze Bluedy+ Holding, a. s. oproti konceptuálnímu modelu zobrazovat navíc pouze datové typy atributů, přičemţ se jedná o platformně
specifický model přizpůsobený objektově orientovanému programovacímu jazyku C#.
Obrázek 30: Softwarový model objektové databáze
- 48 -
Softwarový model je, stejně jako fyzický model u RDBMS, přímou předlohou pro implementaci
databáze, proto je návrh modelován v anglickém jazyce. Oproti relačnímu návrhu není potřeba
nahrazovat vazbu generalizace/specializace ani vazby typu M:N.
Dalším rozdílem, kromě samotného přístupu k návrhu databáze, pak je absence definic primárních
a cizích klíčů u objektového návrhu (princip vazeb u objektových databází je popsán v kapitole
4. Objektové databáze) a propojení se samotným programovacím jazykem aplikace – datové typy
odpovídají objektově orientovanému programovacímu jazyku C# a není nutné znát jako v případě
RDBMS jiné datové typy.
5.4 Implementace
5.4.1
Implementace v PostgreSQL
Veškerý DDL kód pro vytvoření tabulek databáze, včetně atributů, omezení, vazeb a základních
indexů, byl vygenerován CASE nástrojem Enterprise Architect 8.0, ve kterém byl vytvořen fyzický
model (viz obrázek 27). Kompletní kód je k nahlédnutí na přiloţeném CD (platí pro všechny kódy
vytvořené v rámci praktické části této práce), pro ukázku uvádím kód pro vytvoření relace Client.
Obrázek 31: Create table Client
Zdroj: Generováno z CASE nástroje Enterprise Architect 8.0
Pro relaci Client byla vytvořena sekvence Client_id_client_seq, která umoţňuje částečně automatizovanou správu primárního klíče id_client. Ten je moţné při vkládání nového záznamu do relace
nedefinovat a pak je doplněn automaticky sekvencí, která je chová stejně jako autoinkrementační
datový typ serial.
Pro vytvoření testovacích dat byl pouţit nástroj pro generování textů dostupný na internetové adrese www.lipsum.com a jednoduchý generátor vlastního zpracování (není předmětem této práce
a proto není součástí přiloţených materiálů).
- 49 -
Princip vkládání dat do relační databáze byl představen jiţ v kapitole 3.1.2 Data Manipulation Language (DML). Pro ukázku proto přikládám pouze část kódu pro naplnění relace Client.
Obrázek 32: Insert into table Client
Pro přiblíţení práce s daty uloţenými v relační databázi bylo vytvořeno několik příkazů na získávání, úpravu a mazání dat. Stejné příkazy byly pro moţnost porovnání práce s daty implementovány
také v objektové databázi (viz kapitola 5.4.2 Implementace v db4o).
První dotaz s projekcí atributu surname zobrazí abecedně seřazené všechny zaměstnance, jejichţ
příjmení začíná písmenem „A―.
Obrázek 33: Vyhledávání zaměstnanců podle příjmení (psqů)
Druhý dotaz zobrazí ke kaţdé společnosti počet zaměstnanců (sloupec count) a celkovou sumu
jejich platů (sloupec sum). Pro správné pouţití agregačních funkcní count() a sum() je nutné doplnit
klauzuli GROUP BY, která vymezí záznamy, ze kterých se bude součet/suma počítat.
- 50 -
Obrázek 34: Získání informací o společnostech (psql)
Třetí dotaz vyhledá všechny zaměstnance, kteří nejsou součástí ţádného týmu, a z těch vypíše
deset zaměstnanců s nejniţším platem.
Obrázek 35: Vyhledání volných pracovních sil (psql)
Následující ukázka znázorňuje transakční zpracování zvýšení mezd o 10 % těm zaměstnancům,
kteří pracují alespoň v jednom týmu nebo jsou manaţery alespoň jednoho týmu, a kteří mají plat
niţší neţ 310.
Obrázek 36: Transakce pro zvýšení mezd (psql)
- 51 -
Poslední ukázka zobrazuje jednu z moţností, jak mazat záznamy ze vzájemně propojených tabulek. Další moţností pak v PostgreSQL je nastavení omezení DELETE CASCADE na cizí klíče tabulek. Pak se smazáním záznamu s odkazovaným primárním klíčem smaţou také záznamy, které
na tento klíč odkazovaly.
Obrázek 37: Smazání benefitu (psql)
Všechny výše uvedené příkazy by měly být s minimálními úpravami přenositelné i na jiné RDBMS,
které podporují SQL. To je výhoda, kterou ODBMS nenabízejí a v dohledné době podle mého názoru ani nabízet nebudou. Výhody ODBMS představuje následující kapitola.
5.4.2
Implementace v db4o
Na rozdíl od relačních databází, kde se v databázi vytváří struktura relací, se v objektových databázích vyuţívá těsného propojení databáze s programovacím jazykem a jeho vývojovým prostředím. Implementace je tak postavená na definici tříd a jejích atributů. Stejně tak je to u databáze
db4o, která navíc podporuje tvorbu takzvaných Native Queries (NQ) (db4o Tutorial nedatováno),
neboli tvorbu dotazů v „nativním― programovacím jazyce (zde C#). Pro implementaci objektové
databáze, včetně metod pro práci s objekty uloţenými v databázi, byl vyuţit program Microsoft
Visual Studio 2010.
Co zůstává stejné pro relační i objektové databáze je moţnost generování hrubého zdrojového
kódu z CASE nástrojů (zde pouţit Enterprise Architect 8.0). Stejně jako byl pro relační databázi
vygenerován DDL kód, byl vygenerován i kód v jazyce C# pro vytvoření struktury tříd odpovídající
softwarovému modelu objektové databáze.
Pro ukázku uvádím kód třídy Team, jiţ doplněný o konstruktor třídy.
- 52 -
Obrázek 38: Třída Team
Zdroj: Generováno z CASE nástroje Enterprise Architect 8.0, upraveno v MS Visual Studio 2010
Pro připojení databáze k projektu psaném v prostředí Microsoft Visual Studio 2010 stačí připojit
knihovnu Db4object.Db4o.dll do referencí projektu. Pro samotnou práci s databází byla v projektu
vytvořena nová třída ObjectDatabase, jejíţ metody zajišťují vytvoření objektů na základě dat
z přiloţených textových souborů a následné uloţení objektů do databáze pomocí metody Store(object) volané nad databází. Jedna z metod této třídy je znázorněna na obrázku níţe. Vytváří
instance třídy Company, která reprezentuje klienta společnosti. Informace o klientech (neboli atributy instance) jsou načítány ze zdrojového souboru, ve kterém je kaţdý klient uloţen na jednom
řádku ve stejném formátu, který je zobrazen na obrázku 32: Insert into table Client.
- 53 -
Obrázek 39: Metoda ObjectDatabase.InsertCompany()
Zdroj: Vlastní zpracování v MS Visual Studio 2010
Následuje ukázka několika metod pro získávání uloţených dat z databáze, jejich úpravy a mazání.
Jak bylo předesláno jiţ v úvodu kapitoly, pro dotazování se vyuţívá především NQ (kromě NQ lze
vyuţít dotazy typu Query by Example a SODA Query API (db4o Tutorial nedatováno)) a metody pro
vyhledávání objektů jsou tak postavené na programovacím jazyce C#.
Všechny příklady níţe odpovídají příkladům z kapitoly 5.4.1 Implementace v PostgreSQL,
aby lépe demonstrovaly rozdíly v přístupu k datům u relační a objektové databáze. U vybraných
metod byl navíc přidán výpis počtu nalezených záznamů, který konzole psql zobrazuje automaticky
po kaţdém dotazu.
První metoda vypíše do konzole abecedně seřazená příjmení všech zaměstnanců, jejichţ příjmení
začíná řetězcem example (v příkladu platí: example = „A―).
- 54 -
Obrázek 40: Vyhledání zaměstnanců podle příjmení (db4o)
Metoda Companies_Info na obrázku níţe vypíše do konzole postupně název společnosti, počet
jejích zaměstananců a celkové náklady na platy zaměstnanců.
Obrázek 41: Získání informací o společnostech (db4o)
Třetí metoda najde všechny zaměstnance, kteří nepracují v ţádném týmu, seřadí je dle platu
a vypíše deset nejlevnějších volných pracovních sil.
- 55 -
Obrázek 42: Vyhledání volných pracovních sil (db4o)
Následující metoda na příkladu zvyšování platů zobrazuje pouţití transakcí v db4o. Transakce
v této databáze vzniká při kaţdém přístupu do databáze a jejím zavřením se implicitně potvrzuje.
V metodě RaiseSalary je potvrzení vynuceno po zvýšení platů všech zaměstnanců, kteří pracují
alespoň v jednom týmu nebo alespoň jeden tým vedou a kteří mají plat niţší neţ 310.
Obrázek 43: Transakce pro zvýšení mezd (db4o)
- 56 -
Smazáním objektu jsou v databázi smazány i všechny související odkazy, stejně jako bychom
v PostgreSQL pouţili kaskádové mazání. Následující metoda smaţe benefit vyhledaný podle názvu benefitu předaného parametrem.
Obrázek 44: Smazání benefitu (db4o)
Všechny metody zpracované ve vývojovém prostředí MS Visual Studio 2010 jsou k dispozici
na přiloţeném CD.
- 57 -
6 ZÁVĚR
Z několika různých pohledů byly představeny dva odlišné přístupy ke správě perzistentních dat.
Nejprve byla popsána teorie relačních databází a teorie objektových databází, znázorňující velké
rozdíly v samotném nahlíţení na problematiku jako takovou. V praktické ukázce pak byl vyzdvihnut
rozdíl v přístupu k analýze a návrhu databáze, doplněn o ukázku implementace stejného příkladu
v obou databázových modelech.
Uţ v teorii bylo znatelné, ţe relační databáze mají oproti objektovým databázím ohromný náskok
ve standardech. Drtivá většina RDBMS podporuje kompletní standard SQL-92, který rozšiřuje
o vlastní metody a prostředky. Pokud tedy člověk zvládne SQL ve vybraném RDBMS, ovládá
na základní úrovni většinu relačních databází. U objektových databází je situace zcela odlišná.
Standardy jsou brány jako ukazatelé směru, ale kaţdá databáze uţ „jede― sama za sebe. Kaţdá
databáze definuje vlastní metody, obvykle závislé na programovacím jazyce, pro který původně
daná databáze vznikala. Některé objektové databáze (například GemStone) dokonce nabízí vlastní
jazyk pro objektovou databázi, o snadném přechodu k jiné objektové databázi se tak nedá mluvit.
Co však objektové databáze ztrácejí na standardech, snadno dorovnají na podpoře vlastností objektově orientovaného programování jako je dědičnost, zapouzdření, polymorfismus, kolekce,
vlastní datové typy a další. Nehledě na výzkumy, podle kterých jsou objektové databáze v určitých
případech (především při velkém počtu opakovaných volání stejných dat) mnohonásobně výkonnější neţ relační.
Praktická část byla rozdělena na dvě oblasti a to návrh a implementaci. U návrhu datového modelu
se v obou přístupech vychází z business zadání a postupnou transformací vzniká konečný platformně specifický model. Samotná analýza se můţe u obou přístupů jevit velmi podobně, jde však
o nahlíţení na řešenou problematiku. U relačních databází se navrhují tabulky tak, aby bylo snadné a rychlé vyhledávání nejdůleţitějších dat. U objektových databází se navrhuje aplikační logika,
která odhalí potřebné třídy. Samotné kroky transformace modelů jsou tedy podobné, ale účel transformace je rozdílný.
Samotná implementace je uţ natolik rozdílná, ţe ji ani nelze srovnávat. U relačních databází jde
o znalosti SQL a znalosti mnoţinových operací. Objektové databáze jsou postavené na spolupráci
s objektově orientovanými programovacími jazyky a i práce s db4o byla aţ na výjimky pouze
o znalosti základního programování v jazyce C#. Díky tomu pro mě byla práce s db4o mnohem
intuitivnější neţ práce s PostgreSQL, vyhledávání pak dokonce jednodušší. Pro relační databáze
bylo na druhou stranu mnohem jednodušší dohledat informace o jednotlivých příkazech a jejich
parametrech.
Na příkladu společnosti Bluedy+ Holding, a. s. nenastal ţádný problém, který by v objektové nebo
relační databázi nebylo moţné vyřešit. Od generování hrubého kódu pro strukturu dat z CASE
nástroje přes ukládání a vyhledávání dat aţ po transakce byly potřebné nástroje podporovány
- 58 -
u obou databázových modelů. Jednalo se o malý projekt, ale věřím, ţe podobných výsledků bychom se dočkali i u robustnějších databází.
Hlavní problém pro rozšíření objektových databází tak vidím v nákladech na případnou změnu.
V naprosté většině informačních systémů jsou vyuţívány relační databáze a přechod na objektové
databáze by znamenal nemalé investice na úpravy celého systému a také vyškolení zaměstnanců.
Ačkoliv tedy ODBMS přinášejí intuitivnější práci s daty a výkonnější řešení například v oblasti multimediálních systémů nebo dynamických webových stránek, jsou a pravděpodobně i nadále ještě
zůstanou pouze alternativním řešením datové vrstvy.
- 59 -
7 CONCLUSION
From several different views two different approaches were presented to manage persistent data.
First the theory of relational databases and the theory of object databases were described, showing
large differences directly in viewing the issue. In a practical sample, the difference in approach to
the analysis and design of database was emphasized, supplemented by a sample of implementation of the same example in both database models.
It was apparent in the theory that the relational databases are ahead of object databases in standards. An overwhelming majority of RDBMS supports the complete SQL-92 standard, which extends at the expence their own methods and tools. So if a person can handle SQL in a selected
RDBMS he controls on a basic level most of relational databases. In object-oriented databases, the
situation is completely different. Standards are taken as indicators of direction, but each database
―goes‖ for itself. Each database defines its own methods that usually depend on the programming
language for which given database was created. Some object databases (such as GemStone)
even offer its own language for object database, so we can not talk about easy transition to other
object-oriented database.
What object databases lose in the standards, they catch up on support of features of object oriented programming like inheritance, encapsulation, polymorphism, collections, custom data types and
more. Moreover, according to the research, object databases in certain cases (especially in a large
number of repeated calls of the same data), are much more powerful than relational.
The practical part was divided into two areas - design and implementation. In designing of a data
model, both approaches proceed from business assignment and there is a gradual transformation
to the final platform-specific model. The analysis in both approaches can appear very similar, but it
is about attitude to problem. The relational database tables are designed to be easy and quick
search of the most important data. In object-oriented databases application logic is designed to
identify the necessary classes. So the actual steps of transformation models are similar, but the
purpose of transformation is different.
The implementation itself is already so different that it can not be compared. For relational databases knowledge of SQL and set operations is important. Object databases are based on cooperation with object-oriented programming languages, and even work with db4o was more or less
just about basic knowledge of programming in C#. This allows me to work with db4o much more
intuitively than working with PostgreSQL, and searching was even easier. On the other hand, finding information about individual commands and their parameters was much easier for relational
databases.
In the example of Bluedy+ Holding, a. s. there was no problem that the object or relational database could not resolve. From generating the code for data structure from CASE tool over the saving
and searching data to the transactions the necessary tools by both database models were suppor-
- 60 -
ted. It was a small project, but I believe that similar results would be seen even in more robust database.
I see the main problem for the extension of object databases in the cost of a possible change. In
most information systems relational databases are used and the transition to object-oriented database would be a considerable investment to modify the system and train employees. So although
ODBMS provide more intuitive interaction with data and powerful solutions in areas such as multimedia systems and dynamic web sites, it is and will probably be the only alternative data layer.
- 61 -
8 ZDROJE
1.
Merunka, Vojtěch. Objektové modelování. Praha: Alfa Nakladatelství, 2008.
2.
Kocan, Marek. Databáze dneška popáté. 2008.
http://www.dbsvet.cz/rservice.php?akce=tisk&cisloclanku=2008041402 (accessed 10. 30,
2011).
3.
Conolly, Thomas, Carolyn Begg, and Richard Holowczak. Mistrovství - databáze.
Profesionální průvodce tvorbou efektivních databází. Brno: Computer Press, a.s., 2009.
4.
Švec, Martin. "Objektové databáze." Brno, 2003.
5.
Hronek, Jiří. Databázové systémy. Olomouc: Katedra informatiky, Přírodovědecká fakulta,
Univerzita Palackého, 2007.
6.
Kukal, Jaromír. "Projekce v databázových systémech." Chip, 1998: 175.
7.
Zajíc, Petr. MySQL (1) - pestrý svět databází. 3 1, 2005.
http://www.linuxsoft.cz/article.php?id_article=731 (accessed 3 23, 2012).
8.
Kocan, Marek. Databáze dneška podevatenácté. 10 15, 2009.
http://www.dbsvet.cz/view.php?cisloclanku=2009101501 (accessed 3 23, 2012).
9.
—. Databáze dneška potřinácté. 2 16, 2009.
http://www.dbsvet.cz/view.php?cisloclanku=2009021601 (accessed 3 23, 2003).
10. —. Databáze dneška popatnácté. http://www.dbsvet.cz/view.php?cisloclanku=2009050402
(accessed 4 2, 2012).
11. Procházka, David. Oracle. Průvodce správou, využitím a programováním nad databázovým
systémem. Praha: Grada Publishing, 2009.
12. —. Oracle. Průvodce správou, využitím a programováním mad databázovým systémem.
Praha: Grada Publishing, 2009.
13. Cantu, Carlos H. Poznejte Firebird za 2 minuty.
http://www.firebirdnews.org/docs/fb2min_cz.html (accessed 3 23, 2012).
14. Cattel, R.G.G., and D.K. (eds) Barry. The Object Data Standard: ODMG 3.0. San Francisco:
Morgan Kaufmann Publishers, 2000.
15. Databáze. 2 16, 2012. http://cs.wikipedia.org/wiki/Datab%C3%A1ze (accessed 03 1, 2012).
16. Db4o. http://en.wikipedia.org/wiki/Db4o (accessed 4 2, 2012).
17. db4o Tutorial. Versant. http://community.versant.com/documentation/reference/db4o8.0/net35/tutorial/ (accessed leden 8, 2012).
18. Farana, Radim. Databázové systémy. Microsoft Access 2.0. Ostrava: VŠB-TU, 1995.
- 62 -
19. Firebird Foundation Incorporated. About Firebird. http://www.firebirdsql.org/en/about-firebird/
(accessed 3 23, 2012).
20. GemStone Systems. GemStone/S. http://www.gemstone.com/products/gemstone (accessed
4 3, 2012).
21. Hoffer, J. A, Prescott M. B., and Topi H. Modern Database Management. Prentice Hall,
2008.
22. IBM Corp. DB2 for Linux, UNIX and Windows. http://www01.ibm.com/software/data/db2/linux-unix-windows/ (accessed 3 23, 2012).
23. InterSystems Corporation. Caché. http://intersystems.cz/cache/index.html (accessed 4 2,
2012).
24. Loomis, Mary E.S. "ODBMS - Hitting the Relational Wall." Journal of Object-Oriented
Programming, 1994.
25. Microsoft Corporation. Introducing Microsoft SQL Server 2012. Edited by Anne Hamilton.
Redmond, Washington: Microsoft Press, 2012.
26. —. Microsoft SQL Server. http://www.microsoft.com/sqlserver/cs/cz/default.aspx (accessed 3
23, 2012).
27. Objectivity, Inc. Objectivity/DB. http://www.objectivity.com/pages/objectivity/default.asp
(accessed 4 2, 2012).
28. Oracle Corporation. Hardware and Software. Engineered to Work Together.
http://www.oracle.com/us/sun/index.htm (accessed 3 23, 2012).
29. —. Oracle Database 11g. http://www.oracle.com/us/products/database/product-editions066501.html (accessed 3 23, 2012).
30. The PostgreSQL Global Development Group. PostgreSQL 9.1.3 Documentation.
http://www.postgresql.org/docs/9.1/static/index.html (accessed 03 10, 2012).
31. Wade, Andrew E. "Hitting The Relational Wall: Object Oriented Databases vs Relational
Databases." Objectivity, Inc. White Paper. 2005.
http://www.objectivity.com/Hitting_the_relational_wall.html (accessed 11. 9, 2011).
32. VelocityDB. Features. http://www.velocitydb.com/Features.aspx (accessed 4 3, 2012).
33. Versant Corporation. Open Source Object Database (OODB) :: Product Information.
http://www.db4o.com/about/productinformation/ (accessed 4 2, 2012).
34. —. Versant Object Database.
http://www.versant.com/products/Versant_Database_Engine.aspx (accessed 4 3, 2012).
- 63 -
9 SEZNAM POUŢITÝCH POJMŮ A ZKRATEK
Pojem/Zkratka
Význam
DBMS
Database Management System. Kompletní systém určený k řízení a správě dat.
ODBMS
Object Database Management System. Kompletní systém určený k řízení
a správě dat na objektovém principu. Zahrnuje objektově orientované i
relační databáze.
OODBMS
Object Oriented Database Management System. Kompletní systém určený k řízení a správě objektových dat.
RDBMS
Relational Database Management System. Kompletní systém určený
k řízení a správě relačních dat.
ODMG
Object Database Management Group. Konsorcium firem, které vydává
standardy pro objektové databáze.
SQL
Structured Query Language. Standardizovaný dotazovací jazyk pro relační databáze.
OQL
Object Query Language. Standardizovaný dotazovací jazyk pro objektové
databáze.
JDO
Java Data Objects. Rozhraní pro perzistenci objektů v Javě.
B2C
Business-to-Customer. Označení pro obchodní vztah mezi společností a
fyzickou osobou jako koncovým zákazníkem.
Open source
Systém s dostupným zdrojovým kódem s moţností úprav.
Embedded systém
Jednoúčelový systém obvykle optimalizovaný pro konkrétní aplikaci.
Multithreading
Způsob zpracovávání úlohy ve více vláknech zároveň.
Multiplicita
Definuje moţný počet instancí vstupujících do vztahu. Někdy označována
jako násobnost.
- 64 -
10 SEZNAM OBRÁZKŮ
Obrázek 1: Schéma hierarchické databáze ..................................................................................... 13
Obrázek 2: Schéma síťové databáze ............................................................................................... 14
Obrázek 3: Ukázka relační databáze ............................................................................................... 16
Obrázek 4: Základní příkazy jazyka SQL ......................................................................................... 18
Obrázek 5: Syntaxe příkazu CREATE TABLE ................................................................................. 19
Obrázek 6: Vytváření tabulek v jazyce DDL .................................................................................... 20
Obrázek 7: Úpravy tabulek v jazyce DDL ........................................................................................ 20
Obrázek 8: DML příkazy v jazyce SQL ............................................................................................ 21
Obrázek 9: Syntaxe příkazu SELECT .............................................................................................. 21
Obrázek 10: Příkaz SELECT v jazyce SQL (konzole psql).............................................................. 22
Obrázek 11: Typy JOIN příkazů ....................................................................................................... 23
Obrázek 12: Příkaz INNER JOIN v jazyce SQL (psql) Zdroj: Vlastní zpracování v konzoli psql ..... 23
Obrázek 13: Příkaz LEFT JOIN v jazyce SQL (psql)Zdroj: Vlastní zpraování v konzoli psql .......... 24
Obrázek 14: Vytvoření uţivatele v jazyce DCL ................................................................................ 24
Obrázek 15: Nastavení práv v jazyce DCL ...................................................................................... 24
Obrázek 16: Transakce v jazyce SQL (psql) Zdroj: Vlastní zpracování ......................................... 25
Obrázek 17: Definice třídy v ODMG ODL ........................................................................................ 34
Obrázek 18: Definice třídy Person v ODMG ODL ............................................................................ 34
Obrázek 19: Definice struktury ......................................................................................................... 35
Obrázek 20: Syntaxe jednoduchého Select dotazu ......................................................................... 37
Obrázek 21: Vyhledání podle atributu .............................................................................................. 38
Obrázek 22: Vyhledávání přes vazby .............................................................................................. 38
Obrázek 23: Agregační funkce a sloţená podmínka ....................................................................... 38
Obrázek 24: Business model společnosti Bluedy+ Holding, a. s. .................................................... 42
Obrázek 25: Konceptuální model relační databáze ......................................................................... 44
Obrázek 26: Logický model relační databáze .................................................................................. 45
Obrázek 27: Fyzický model relační databáze .................................................................................. 46
Obrázek 28: Business model objektové databáze ........................................................................... 47
Obrázek 29: Konceptuální model objektové databáze .................................................................... 48
Obrázek 30: Softwarový model objektové databáze ........................................................................ 48
Obrázek 31: Create table Client ....................................................................................................... 49
Obrázek 32: Insert into table Client .................................................................................................. 50
Obrázek 33: Vyhledávání zaměstnanců podle příjmení (psqů) ....................................................... 50
Obrázek 34: Získání informací o společnostech (psql) .................................................................... 51
Obrázek 35: Vyhledání volných pracovních sil (psql) ...................................................................... 51
Obrázek 36: Transakce pro zvýšení mezd (psql) ............................................................................ 51
Obrázek 37: Smazání benefitu (psql)............................................................................................... 52
Obrázek 38: Třída Team .................................................................................................................. 53
- 65 -
Obrázek 39: Metoda ObjectDatabase.InsertCompany() .................................................................. 54
Obrázek 40: Vyhledání zaměstnanců podle příjmení (db4o) ........................................................... 55
Obrázek 41: Získání informací o společnostech (db4o) .................................................................. 55
Obrázek 42: Vyhledání volných pracovních sil (db4o) ..................................................................... 56
Obrázek 43: Transakce pro zvýšení mezd (db4o) ........................................................................... 56
Obrázek 44: Smazání benefitu (db4o) ............................................................................................. 57
- 66 -
11 SEZNAM TABULEK
Tabulka 1: SQL - Integritní omezení ................................................................................................ 19
Tabulka 2: Porovnání relační a objektové terminologie ................................................................... 32
Tabulka 3: Kolekce definované ODMG ODL ................................................................................... 35
Tabulka 4: Zaměstnanecké výhody Bludy+ Holdingu, a. s. a dceřinných společností .................... 42
- 67 -
PŘÍLOHA 1 – DATOVÉ TYPY V POSTGRESQL
Údaje převzaty z PostgreSQL 8.3.18 Dokumentace:
http://www.postgresql.org/docs/8.3/static/datatype.html
Celočíselné datové typy
Datový typ
Popis
Rozsah
smallint
2 byty
-32768 .. +32767
integer
4 byty
-2147483648 .. +2147483647
bigint
8 bytů
-9223372036854775808 .. 9223372036854775807
serial
4 byty,
autoinkrementační identifikátor
-2147483648 .. +2147483647
bigserial
8 bytů,
autoinkrementační identifikátor
-9223372036854775808 .. 9223372036854775807
Reálné datové typy
Datový typ
Popis
Rozsah
decimal
proměnlivá
aţ tisíc cifer
numeric
proměnlivá
aţ tisíc cifer
real
4 byty
přesnost na 6 desetinných míst
double precision
8 bytů
přesnost na 15 desetinných míst
money
4 byty
-21 474 836,48 .. +21 474 836,47
- 68 -
Řetězcové typy
Datový typ
Popis
char(n)
řetězec s pevnou délkou
varchar(n)
řetězec s proměnnou délkou, aţ n znaků
text
řetězec s proměnnou neomezenou délkou
name
řetězec s pevnou délkou 64 znaků
bytea
binární řetězec s neomezenou délkou
blob
binární data
binary large object
binární data
Ostatní datové typy
Datový typ
Popis
boolean
logický datový typ (1, „t―, 0, „f―, ...)
bit(n)
n-bitový řetězec
bit varying(n)
bitový řetězec, aţ n bitů
timestamp
datum i čas, moţno přidat časovou zónu
interval
interval mezi dvěma časy
date
datum
time
čas, moţno přidat časovou zónu
- 69 -

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

Podobné dokumenty

zde

Systém pro podporu odborných konferencí

Nové vlastnosti IDS 11.50

Progresscycle 2008 - Sella Bike

Teoretická východiska deduktivních databází

Akutni stavy statnicove otazky_II

dp - StarHill

celý časopis

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE Datové modelování

Nero Burning ROM

PostgreSQL ve verzi 9.2, 9.3 a 9.4 SQL

Projekt CZ.2.17/3.1.00/30233 Knihy zakoupené v rámci projektu

zpráva z analýzy metodologických postupů a návrh

databázové technologie (db) – příprava na szz

Staré mapy v pražských antikvariátech

Entitní typ