UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

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: (:); 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

Recommend Documents