Výučbové nástroje pre relačné a objektové databázy

Transcription

1 Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: Informatika Gabriel Tekeľ Výučbové nástroje pre relačné a objektové databázy Bakalársky projekt Vedúci bakalárskeho projektu: Ing. Miroslav Galbavý Máj, 2011

2 ČESTNÉ PREHLÁSENIE AUTORA Čestne prehlasujem, že som túto prácu vypracoval samostatne, na základe získaných vedomostí a s využitím uvedenej literatúry. V Bratislave dňa... podpis autora

3 POĎAKOVANIE Týmto by som rád vyjadril svoje poďakovanie vedúcemu tejto bakalárskej práce Ing. Miroslavovi Galbavému za svoj čas, ochotu a akúkoľvek nápomocnú radu či myšlienku pri jej vypracovávaní.

4 Anotácia Slovenská technická univerzita v Bratislave FAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ Študijný program: Informatika Autor: Gabriel Tekeľ Bakalársky projekt: Výučbové nástroje pre relačné a objektové databázy Vedúci projektu: Ing. Miroslav Galbavý Máj, 2011 Databázový systém je program, ktorý vykonáva operácie nad veľkým množstvom perzistentných údajov. Označuje sa ako SRBD systém riadenia bázy dát. Popis štruktúry dát a typu dát, ktoré sú v databáze, sa nazýva dátový model. V súčasnosti najviac používané dátové modely sú relačný a objektový dátový model. Úlohou tohto bakalárskeho projektu je oboznámenie sa s predstaviteľmi relačných a objektových databáz a ich technológiami na spravovanie dát. Vybraným relačným databázovým systémom je databáza PostgreSQL a objektovým predstaviteľom tohto projektu je databáza Caché. V projekte je obsiahnutý návrh transformačného procesu medzi objektovou a relačnou databázou, ktorý je podľa špecifikácie zadania aj implementovaný. Výsledná aplikácia reálne transformuje dátové štruktúry Caché databázy na dátové štruktúry relačnej databázy.

5 Annotation Slovak University of Technology in Bratislava FACULTY OF INFORMATICS AND INFORMATION TECHNOLOGIES Degree course: Informatics Author: Gabriel Tekeľ Bachelor Theses: Learning tools for relational and object databases Supervisor: Ing. Miroslav Galbavý 2011, May The database system is a program that carries out operations over large amounts of persistent data. This is known as a DBMS - database management system. Description of data structure and type, which are in the database, are called the data model. Currently the most widely used data models are relational and object data model. The aim of this bachelor project is to identify the representatives of relational and object databases and their technology to manage data. Selected relational database system is PostgreSQL database and chosen object database of this project is Caché system. Project contains design of transformation process between object and relative database which is implemented according to assignment. The resulting application transforms data structures form Cache database into relational database.

6 Obsah 1 Úvod Účel dokumentu Zoznam použitých skratiek Analýza Databáza Relačný model dát Atribút Primárny kľúč Objektový model dát Základy objektovej orientácie Prečo zvoliť objekty pre dátový model? Databázový systém PostgreSQL Základné charakteristiky databázového systému PostgreSQL Databázová technológia Caché Základná charakteristika Caché Objektový model Caché Analýza existujúceho stavu Hibernate Active Record Pattern Záver analýzy Výber implementačného prostredia Zhrnutie a ďalšia práca Opis riešenia Špecifikácia hlavných požiadaviek Nesúlad medzi objektovým a relačným modelom Opis transformačného procesu Mapovanie objektového modelu na relačnú schému Mapovanie generalizácie (dedičnosti) Mapovanie asociačných a kompozičných vzťahov Mapovanie asociačného vzťahu many to many Mapovanie kolekcie (pole) Mapovanie vnorených (embedded) objektov Mapovanie identity objektu Spätný proces transformácia relačnej databázy na objektovú Návrh aplikácie Konektory Parser XML súborov SQL Generátor Prenášač dát Implementácia návrhu aplikácie Vytvorenie spojenia s databázami Export definícii tried z objektovej databázy Pomocné dátové štruktúry XML Parser analýza exportovaných tried Implementácia modulu zabezpečujúceho aplikáciu dedičnosti...34

7 3.7.6 Generovanie DDL kódu Vloženie DDL kódu do relačnej databázy a prenos dát Overenie správnosti riešenia Výučbový potenciál výsledného produktu Technická dokumentácia Zoznam použitých technológii Požiadavky na použitie aplikácie Používateľská príručka Zhodnotenie Zoznam použitej literatúry Prílohy...48 Príloha A Použitá notácia diagram tried a dátový diagram...48 Príloha B Akceptačné testy...50 Príloha C Implementácia objektového modelu v Caché a generovaný DDL kód...52 Príloha D Zoznam obrázkov...55 Príloha E Zoznam tabuliek...55 Príloha F Zoznam elektronického média...55

8 1 Úvod 1.1 Účel dokumentu Ľudia mali už odpradávna potrebu zhromažďovať informácie. Predchodcami súčasných databáz boli kartotéky z papiera a všetky operácie musel zabezpečovať človek manuálne. V širšom slova zmysle si môžeme databázu predstaviť ako súbor dát, ktorý slúži pre popísanie nejakej skutočnosti. Asi by sme dneska márne hľadali moderný informačný systém, ktorý nepoužíva žiadnu databázu. Najviac používané databázy v súčasnosti sú relačné databázy, kde sa dáta uložené v tabuľkách avšak s nástupom objektovo-orientovaných programovacích jazykov čí zložitých multimedíálnych alebo geografických systémov prišla požiadavka aj na priame uloženie objektov do databázy, na základe čoho uzreli svetlo sveta objektové databázy. Účelom dokumentu v časti Analýza je zhrnúť základné vedomosti o dvoch dneska v praxi najpoužívanejších dátových modeloch a to síce o relačnom a objektovom dátovom modeli ako aj charakterizovať konkrétnych predstaviteľov týchto modelov a to relačný databázový systém PostgreSQL a objektovú databázovú technológiu Caché a taktiež aj preskúmať existujúce objektovo-relačné mapovacie nástroje, ktoré nám môžu do určitej miery slúžiť ako inšpirácia pri našom riešení problému. V časti dokumentu Opis riešenia sa pokúsime navrhnúť proces transformácie nesúladných dátových štruktúr objektovej a relačnej databázy a opísať postup implementácie. Záver dokumentu bude patriť zhodnoteniu dosiahnutých výsledkov, čo sa nám podarilo splniť a naopak, čo ostalo za hranicami našich možnosti. V časti Technická dokumentácia si opíšeme použité technológie, spôsob zaobchádzania s aplikáciou, či požiadavky na jej fungovanie. 1

9 1.2 Zoznam použitých skratiek API - Application Programming Interface CRUD Create, Read, Update, Delete DOM Document Object Model JDBC Java Database Connectivity JRE Java Runtime Enviroment LGPL - Lesser General Public License OID Object Identifier OODBMS Object Oriented Database Managment System POJO Plain Old Java Object RDMBS Relational Database Managment System SRBD Systém Riadenia Bázy Dát XML extensible Markup Language 2

10 2 Analýza 2.1 Databáza Počítačová databáza je množina štruktúrovaných dát alebo informácií uložených v počítačovom systéme.[1] 2.2 Relačný model dát Relačné databázové systémy sú postavené na základe definície relačného modelu a spolu s relačným systémom riadenia bázy dát (SRBD) sa stali najpoužívanejšími databázovými systémami. Relačný dátový model je : založený na teórii relácii, množinovom pojme relácií a relačnej algebre všetky vzťahy reprezentuje vo forme tabuliek, pretože dvojrozmerné tabuľky stačia na modelovanie reálnych vzťahov kľúčovým pojmom používaným pri relačnom modelovaní je relácia [2] Relačný dátový model podľa pôvodnej definície vychádzal z nasledovných požiadaviek : Zabezpečiť vysoký stupeň dátovej nezávislosti. Zabezpečiť minimálnu redundanciu dát spolu s konzistenciou dát s podporou sémantiky jazyka. Sprístupniť databázu pomocou množinovo orientovaného neprocedurálneho jazyka. Umožniť jednoduchým spôsobom reštrukturalizáciu a rast dátového modelu. [2] 3

11 Základné pojmy, ktoré si musíme jasne definovať, ak chceme pracovať s relačným modelom, sú : relácia n-tica atribút primárny kľúč doména V tabuľke č. 1 si môžeme všimnúť akou formou sú reprezentované jednotlivé relačné pojmy a v akom vzťahu sú voči súborovej analógii. Relačný pojem Reprezentácia Súborová analógia relácia tabuľka súbor n-tica riadok záznam atribút stĺpec položka Tab. 1: Analógia pojmov Atribút Atribút relácie je stĺpec relácie označený unikátnym názvom a doménou.[1] Relácia je určená svojou množinou atribútov, ktoré zabezpečia adresovací mechanizmus prístupu k hodnotám reprezentovaným v samotnej relácii. Samotný atribút bližšie popisuje hodnoty ukladané v relácii, pretože atribút relácie je určený aj príslušným dátovým typom, prípadne ďalšími integritnými obmedzeniami týkajúcich sa hodnôt, ktoré môže nadobúdať.[3] V rôznych reláciách je možné používať rovnaké mená atribútov, ale v rámci jednej relácie musia byť mená atribútov rôzne.[2] Primárny kľúč jednoznačne identifikuje záznam tabuľky môže byť tvorený jedným alebo niekoľkými atribútmi, podľa toho rozlišujeme jednoduchý alebo zložený primárny kľúč 4

12 musí spĺňať dve nasledovné požiadavky : (a) jedinečnosť - to znamená, že tabuľka nemôže obsahovať dve alebo viac rovnakých hodnôt kľúča [2] (b) minimalizácia v prípade, že sa kľúč skladá z viacerých atribútov, žiaden z týchto atribútov nemôže byť vynechaný, inakšie by došlo k porušeniu zásady o jedinečnosti kľúča [2] 2.3 Objektový model dát Relačný dátový model je najbežnejší model používaný v dnešných databázových systémoch obmedzuje však štruktúru a vzťahy uchovávaných dát na množinu tabuliek nad preddefinovanou množinou základných dátových typov. Nespornou výhodou tohto modelu je jednoduchosť a v dôsledku toho aj jednoduchá štandardizácia a prenositeľnosť. Nevýhodou však je rozdielnosť reálnych dát od vnútorného tabuľkového modelu databázy. Vzťahy medzi dátami je možne reprezentovať iba tabuľkami, čo u aplikácií s komplikovanejším dátovým modelom vedie k množstvu tabuliek vzájomne previazaných pomocou kľúčov. Dochádza tým k strate prehľadnosti, databáza sa stáva horšie spravovateľnou a budúce zmeny v dátovom modeli aplikácie nútia programátorov k citeľným zásahom do jeho tabuľkovej reprezentácie. Rada aplikácií, napríklad z oblasti dizajnu, multimédií, geografických systémov apod., však potrebuje taký dátový model, ktorý umožní lepšiu korešpondenciu medzi zložitými reálnymi dátami a ich reprezentáciou v databázovom systéme. Týmto modelom je objektový model dát. Objektový model dát v databázových systémoch vychádza zo známych princípov objektovo orientovaného modelovania a programovania. Je však ďalej obohatený o techniky reprezentácie vzťahov, dotazovania, transakčného prístupu a podobne. [5] Základy objektovej orientácie Objekty Objektovo-orientovaný model je založený na dekompozícií informácií z reálneho sveta na tzv. objekty. Pod pojmom objekt sa rozumie každá (aj štruktúrovaná) entita, ktorá je 5

13 jednoznačne a nezávisle identifikovaná v rámci určitého kontextu okolitého sveta. Objekt tak má jednoznačnú identitu, každé dva objekty sú vzájomne odlíšiteľné. Identita objektu je určená identifikátorom OID 1, ktorý je generovaný systémom, je unikátny, nemenný počas celej doby existencie objektu a skrytý pre programátora i koncového užívateľa.[4] Triedy Objekty sú charakterizované pomocou tried. Trieda je abstraktný popis objektu, určuje dátové zložky objektu a operácie (nazývané metódy), ktoré sa dajú nad objektom realizovať. Každý objekt je inštanciou nejakej triedy, od jednej triedy je možné inštanciovať všeobecne neobmedzený počet štrukturálne zhodných objektov Literály Literál je dátová entita určitého dátového typu, ktorá však na rozdiel od objektov nemá vlastnú identitu. Literály sa obvykle vyskytujú ako dátové atribúty objektov. Množina operácii nad dátovým typom literálov je pevne stanovená, nie je možné ju meniť.[4] Zapúzdrenie Okolie objektov ma prístup iba k rozhraniu operácií, vlastná implementácia operácií je vždy pred okolím skrytá. Ide o typickú vlastnosť objektovo orientovaného prístupu, ktorá zvyšuje mieru abstrakcie a nezávislosti objektov.[7] Okrem skrývania implementácie je možné skrývať aj časti rozhraní. Atribúty a operácie sa dajú označiť za verejné (public) alebo súkromné (private). Niektoré systémy zavádzajú ešte jednu úroveň, obvykle nazývanú protected. Takto označené atribúty a operácie sú prístupné v objektoch danej triedy a v objektoch tried odvodených od tejto triedy.[4] Dedičnosť Dedičnosť je ďalšou typickou vlastnosťou objektového modelu. Vychádza z myšlienky, že niektoré triedy môžu byť špecializovanou verziou inej triedy, resp. určitá trieda je zovšeobecnením jednej alebo viacerých špeciálnejších tried. Ak je trieda odvodená od 1 Object identifier 6

14 inej triedy, dedí všetky jej atribúty a operácie. Ďalej môže doplniť nové atribúty a operácie, prípadne predefinovať zdedené operácie.[4] Polymorfizmus Polymorfnými operáciami sa označujú operácie, ktoré sa dajú realizovať nad objektmi rôznych tried. Pritom činnosť operácie sa môže líšiť podľa triedy objektu, nad ktorým je realizovaná. V objektovo orientovaných programovacích jazykoch sa polymorfizmus metód obvykle obmedzuje na triedy, ktoré sú vo vzťahu generalizácia / špecializácia Prečo zvoliť objekty pre dátový model? U nových databázových aplikácií dáva väčšina vývojárov prednosť objektovej technológii, pretože vývoj zložitých aplikácií je omnoho rýchlejší a neskoršie úpravy sú jednoduchšie. Objektová technológia poskytuje rad výhod, akými sú napríklad: Objekty podporujú bohatšie dátové štruktúry, ktoré omnoho prirodzenejšie popisujú skutočné dáta. Programovanie je jednoduchšie. Je ľahšie sledovať, čo práve robíte a s čím práve pracujete. Pojatie objektu ako čiernej skrinky so zapúzdrenými prostriedkami umožňuje programátorom zdokonaľovať vnútorné operácie v objekte, bez toho, aby sa ovplyvňovali ostatné časti aplikácie. Vďaka objektom je možné jednoduchým spôsobom prepojovať rôzne technológie a aplikácie. Objektová technológia je použitá v mnohých nových nástrojoch. Objekty zaisťujú oddelenie užívateľského rozhrania od zvyšku aplikácie. Pokiaľ treba prijať novú technológiu užívateľského rozhrania (možno nejakú doposiaľ neznámu technológiu budúcnosti), bude možné použiť väčšinu kódu znovu. 2.4 Databázový systém PostgreSQL V tejto kapitole si priblížime základné vlastnosti zástupcu relačných databáz, databázového systému PostgreSQL. Nejedná sa však o vyčerpávajúci opis jeho 7

15 funkcionality, ale skôr o snahu predstaviť tento systém čitateľovi s tým, že niektorých ďalších funkčných vlastností sa dotkneme v ďalších častiach tejto práce.[5] Základné charakteristiky databázového systému PostgreSQL Základné charakteristiky databázového systému sa pokúsim priblížiť v niekoľkých bodoch : PostgreSQL je najvyspelejší databázový systém spadajúci do skupiny Open Source software. Predchodca systému PostgreSQL bol systém Ingres, vyvinutý na kalifornskej univerzite v Berkeley, kde taktiež prebiehal vývoj objektovorelačného databázového serveru s názvom Postgres. Systém Postgres bol následne doplnený o podporu jazyka SQL. Výsledný projekt bol označený ako Postgres95, ktorý bol v roku 1996 premenovaný na PostgreSQL. SRBD je postavený na architektúre klient/server. V tomto modeli SRBD beží na serveri a čaká na požiadavky prichádzajúce od jednotlivých klientov. Výsledok spracovania je odoslaný klientovi. V súčasných databázových systémoch sa komunikácia medzi klientom a serverom uskutočňuje pomocou jazyka SQL. Architektúra klinet/server odľahčuje SRBD od prevádzky aplikačných programov a funkcií prezentačného softwaru, ktoré bežia na klientskom počítači. Pre komunikáciu so systémom sú k dispozícií nasledovné jazyky a frameworky : o C o C++ o Java o Perl o ODBC o Python o TCL o C Easy API o Vnorené HTML (PHP) o.net o Macromedia 8

16 o Rails Databázový systém je podporovaný nasledovnými operačnými systémami : o Windows o Linux (novšie distribúcie) o FreeBSD, NetBSD, OpenBSD o AIX, IRIX, HP/UX o Solaris o Mac OS o Unix systémy [8] PostgreSQL je medzinárodne považovaný za najdokonalejší a najflexibilnejší voľne šíriteľný relačný databázový systém. Medzi jeho hlavné priority patrí dodržiavanie noriem a implementácia jazyka SQL, ktorú používa, vyhovuje štandardu ANSI- SQL:2008. Je používaný známymi spoločnosťami ako napríklad Skype, MySpace, Cisco či Yahoo. Projekt tiež podporujú mnohé známe softwarové korporácie ako sú Sun Microsystems, HP, Red Hat. Priamy prístup k vývojárom, komunite užívateľov, manuálom a zdrojovému kódu často poskytuje kvalitnejšiu podporu než ponúkajú iné databázové systémy. PostgreSQL je bezplatné pre ľubovoľné použitie, či už komerčné alebo nekomerčné.[5] O databázovom systéme PostgreSQL by sme mohli napísať celú trilógiu a tento predchádzajúci prehľad nie je postačujúci na jeho dokonalú charakteristiku. Cieľom tejto kapitoly bolo všeobecnejšie zhrnutie dôležitých prvkov tohto databázového systému a zdôrazniť fakt, že vývoj tohto projektu nie je iba jedným z tisícov obyčajných projektov, z ktorých mnohé, ako sa rýchlo objavia, tak aj rýchlo zmiznú, ale jedná sa o významný projekt, za ktorým stojí početná komunita ľudí a ktorý podporujú významné svetové spoločnosti.[5] Z predchádzajúcich uvedených informácií o databázovom systéme PostgreSQL sú kľúčové pre potreby nášho zadania hlavne dve vlastnosti : 9

17 Databázový systém predstavuje open source projekt, z čoho vyplýva, že pri práci s ním máme neobmedzené možnosti. Poskytuje API podporu pre programovací jazyk Java, pomocou ktorého bude implementované naše riešenie 2.5 Databázová technológia Caché Cieľom tejto kapitoly je, podobne ako v predchádzajúcej o PostgreSQL, charakterizovať objektový databázový systém Caché Intersystems Základná charakteristika Caché Základné vlastnosti databázovej technológie Caché v niekoľkých bodoch : Systém Caché je mimoriadne výkonná databázová aplikácia novej generácie. Kombinuje objektovú databázu, vysokovýkonný jazyk SQL a rýchly prístup k viacrozmerným poliam, pričom všetkými týmito spôsobmi sa dá pristupovať k dátam súčasne. Dáta sú popísané iba raz v jedinom integrovanom slovníku dát a sú okamžite dostupné prostredníctvom všetkých prístupových metód. Systém Caché poskytuje takú úroveň výkonu, rozšíriteľnosti, rýchleho programovania a jednoduchého použitia, ktorá je u relačnej technológie nedosiahnuteľná. Zahrňuje aplikačný server s progresívnymi možnosťami objektového programovania, schopnosť jednoduchej integrácie so širokou paletou technológií a mimoriadne výkonný databázový stroj. Systém Caché ma niekoľko vstavaných skriptovacích jazykov : Caché ObjectScript výkonný a ľahko zvládnuteľný programovací jazyk, Caché Basic nadstavba bežne používaného programovacieho jazyka Basic, ktorý obsahuje rozšírenie pre efektívny prístup k dátam a objektovú technológiu, a Caché MVBasic variant jazyka Basic používaná v MultiValue aplikáciách. Ďalšie programovacie jazyky ako Java, C# a C++ sú podporované pomocou priameho volania a iných rozhraní, ktoré zahrňujú ODBC, JDBC,.NET. 10

18 Zahŕňa bohaté prostredie pre vývoj prepracovaných webových aplikácií využívajúcich ako klienta prehliadač. Technológia CSP (Caché Server Pages) umožňuje rýchle vyvíjanie a spúšťanie dynamicky generovaných webových stránok. Tisíce užívateľov webu môžu súčasne pristupovať do databázových aplikácií. U aplikácií, ktoré nevyžadujú ako klienta prehliadač, je užívateľské rozhranie väčšinou naprogramované s využitím niektorej z obľúbených technológií pre vývoj užívateľských rozhraní, napr. Java,.NET, Delphi, C# alebo C++. Najlepšie výsledky (rýchlejšie programovanie, väčší výkon a najnižšia cena za údržbu) sa dosahujú, ak je všetko ostatné programované v jazykoch systému Caché. Technológia Caché takisto poskytuje mimoriadne vysokú úroveň možnosti spolupráce s ostatnými technológiami a podporuje všetky bežné používané nástroje. K dispozícií je široká paleta vývojových metodológií. [6] Objektový model Caché Objektový model Caché je založený na štandarde ODMG (Object Database Management Group) a definuje správanie a vlastnosti objektov. Tento model podporuje nasledujúce prvky : Komplexnosť - Objekty môžu byť uložené v Caché databáze alebo na inom externom disku. Objektový model je dostatočne bohatý nato, aby mohol kompletne definovať informácie požadovane pre komplexné databázové aplikácie (napr. indexy, štruktúra uloženia, integritné ohraničenia, atď.). Vlastnosti Objekty môžu obsahovať jednoduché vlastnosti (literály) ako aj ďalšie objekty alebo odkazy na ďalšie objekty, rôzne druhy vzťahov medzi objektmi, kolekcie a stream-ové vlastnosti. Vlastné dátové typy Objekty môžu používať aplikáciou špecifikované dátové typy, ktoré sú definované ako triedy. Polymorfizmus Aplikácie sa môžu jednoducho prispôsobiť novým okolnostiam poskytnutím operácií, ktoré majú špecializovanú implementáciu. Počas behu 11

19 programu systém automaticky zavolá správnu implementáciu založenú na type objektu. Dedičnosť Aplikácie môžu znova použiť kód odvodením nových komponentov z existujúcich tried. [6] Referencia na objekty OREF a OID OREF - Odkaz na objekt. Hodnota, ktorá odkazuje na špecifickú inštanciu objektu v pamäti. Vždy, keď je objekt volaný z pamäti, môže nadobudnúť odlišnú OREF hodnotu.[6] OID - Identifikátor objektu, ktorý pozostáva z názvu triedy a ID hodnoty. Unikátna hodnota, ktorá špecifikuje inštanciu perzistentného objektu uloženého v databáze. Táto hodnota objektu nemôže byť nikdy zmenená.[6] ID Hodnota, ktorá jednoznačne identifikuje objekt patriaci do špecifického segmentu. 2.6 Analýza existujúceho stavu Nakoľko podstatnú časť nášho projektu bude tvoriť návrh transformačného procesu medzi objektovými a relačnými dátovými štruktúrami a jeho implementácia, analyzovali som niektoré existujúce riešenia, ktoré sa v praxi používajú ako transformačné prostriedky medzi objektovým a relačným svetom : Oracle Toplink Hibernate Java Persistence API (EJB 3.0) NHibernate LinQ for SQL Active Record Pattern 12

20 2.6.1 Hibernate je voľne šíriteľný nástroj pod LGPL licenciou, ktorý umožňuje mapovať triedy v jazyku Java na tabuľky relačnej databázy popis transformácie objektov do tabuliek relačnej databázy určujú XML konfiguračné súbory alebo anotácie (obr. 1) k samotným dátam, teda k objektom v databáze sa pristupuje priamo pomocou jazyka HQL 2, čo sa vo veľkej miere prejaví na časovej úspore pri vývoji databázovej aplikácie disponuje transparentnou perzistenciou dát, čo znamená, že u aplikácii je možné meniť databázu obsahuje kompletnú podporu pre vývojové prostredie Eclipse, čo sa ukázalo ako veľká výhoda pri testovaní tohto frameworku využíva automatické generovanie primárnych kľúčov aplikuje niekoľko stratégii objektovo-relačného mapovania, polymorfické asociácie, indexované kolekcie a iné objektovo-orientované črty. Hibernate komunikuje s databázou priamo prostredníctvom ovládača JDBC [11,12] 2 Hibernate Query Language dotazovací jazyk pre technológiu Hibernate 13

21 Obr. 1: Hibernate využíva databázu a konfiguračné súbory na to, aby pre aplikáciu zabezpečil perzistenciu servisov a perzistentné objekty. Súbor hibernate.properties obsahuje konfiguráciu Hibernate a XML súbory udávajú ako sa budú mapovať POJO objekty na tabuľky relačnej databázy Architektúra Hibernate je zložená z troch základných modulov : Connection Managment zabezpečuje spoľahlivé riadenie spojení s databázou, čo je veľmi dôležitá časť pri práci s databázou. Transaction Managment umožňuje používateľovi súčasne vykonávať viac dopytov. Object Relation Maping samotná realizácia objektovo-relačného mapovania, kedy sú dáta z objektovej formy transformované do relačných tabuliek. [12] Medzi najväčšie výhody Hibernate nesporne patrí automatické mapovanie objektov na databázové schémy, dotazovací mechanizmus s jednoduchým objektovo-orientovaným HQL jazykom, automatické doťahovanie referencii a kolekcii ku ktorým používateľ pristupuje (lazy initialization). Použitie Hibernate je rozhodne jednoduchšie ako využívať statický JDBC prístup. Do určitej miery by nám táto javovská knižnica mohla slúžiť ako inšpirácia pre tvorbu našej aplikácie s tým rozdielom že, mnou navrhnutá aplikácia nebude transformovať Java triedy, ale priamo triedy definované objektovou databázou Caché na tabuľky relačnej databázy. 14

22 2.6.2 Active Record Pattern [13] architektonický návrhový vzor pre prácu s dátovými zdrojmi implementáciou tohto vzoru je zvyčajne objekt, ktorý je charakteristický svojím chovaním a dátami, pričom väčšina z týchto dát je perzistentných a potrebujú byť uložené v databáze trieda implementuje potrebné rozhranie pre perzistenciu objektu typicky CRUD. relačné dáta sú potom reprezentované ako objektovo-orientovaný kód, kde databázové tabuľky odpovedajú triedam, riadky tabuliek objektom a nakoniec jednotlivé polia riadkov atribútom objektov Príklad databázovej tabuľky Cars so stĺpcami VIN (Vehicle identification number), Year a Color a triedy Car, ktorá implementuje Active Record Pattern : car = new Car(); car.vin = 'BA 123 AL'; car.year = '1999'; car.color = 'blue'; car.save(); Tento pseudokód, prevedením na príkaz jazyka SQL, vloží do tabuľky nový záznam: INSERT INTO Cars (VIN, Year, Color) VALUES (' BA 123 AL', 1999, 'blue'); Trieda Car môže taktiež slúžiť k dotazovaniu databázy : mycar = car.search('ba 123 AL'); Active Record sa používa v prípadoch, kedy doménová logika (doménový model) nie je príliš zložitá. Silnou stránkou tohto nástroja je jeho jednoduchosť a pochopiteľnosť - kód je do istej miery samovysvetľujúci. Nevýhodou tohto produktu je, že pracuje spoľahlivo 15

23 iba v prípade, keď triedy priamo korešpondujú s databázovými tabuľkami. Ťažko sa mapujú do objektov Active Record také vlastnosti ako je napríklad dedičnosť. Nástroj Active Record nám môže slúžiť ako inšpirácia pri tvorbe návrhu transformácie dátových štruktúr, tentoraz však smerom od relačnej databázy k objektovej. 2.7 Záver analýzy Výber implementačného prostredia Implementáciu databázového rozhrania resp. platformu pre spracovanie dát relačných a objektových databáz by sme chceli realizovať v jazyku Java (SDK) práve preto, že : Java je považovaná za vlajkovú loď medzi objektovými programovacími jazykmi a práve objektové prvky tohto jazyka majú mnohé ekvivalenty u technológie Caché. PostgreSQL poskytuje pre Javu ovládač JDBC, ktorý umožňuje spojenie s touto databázou použitím štandardného, od databázy nezávislého Java kódu. Caché poskytuje pre Javu hneď niekoľko spôsobov, pomocou ktorých môže programátor realizovať pripojenie na túto databázu. Java je multiplatformová, takže prakticky by táto naša aplikácia mohla fungovať na všetkých operačných systémoch, pre ktoré poskytujú Caché a PostgreSQL podporu Zhrnutie a ďalšia práca Táto kapitola nám mala poskytnúť teoretický náhľad na databázové systémy. Jej hlavným cieľom bolo oboznámenie sa s typickými vlastnosťami dneska dvoch najpoužívanejších dátových modelov v databázových systémoch, a to s relačným a objektovým dátovým modelom. Predstavili sme si taktiež konkrétnych predstaviteľov týchto modelov, databázové systémy PostgreSQL a Caché. Záver práce patril charakteristike existujúcich aplikačných riešení, ktoré sú určené pre transformáciu dát objektového a relačného sveta. Nadobudnuté teoretické poznatky z tejto práce predstavujú dobrú východiskovú pozíciu 16

24 pre ďalšiu praktickú prácu, ktorej cieľom bude predovšetkým: návrh transformačného procesu dátových štruktúr medzi databázami oboch typov implementácia korektného databázového rozhrania pre spracovanie dát relačných a objektových databáz navrhnúť transformačný proces a implementovať ho takým spôsobom, aby mohol do určitej miery spĺňať funkciu nástroja pre účel výučby. 17

25 3 Opis riešenia V tejto kapitole je podrobne opísané naše riešenie problému automatizovanej transformácie dátových štruktúr medzi objektovou a relačnou databázou, špecifikácia hlavných požiadaviek na aplikáciu ako aj samotná implementácia v programovacom jazyku Java. V kapitole sú taktiež opísané entity, ktoré slúžia na dočasné uchovanie údajov ako aj jednotlivé moduly aplikácie, z ktorých každý slúži na vykonanie špecifickej úlohy. Priblížime si taktiež hlavné problémy pri preklápaní údajových štruktúr medzi odlišnými typmy databáz, ktoré sú vo všeobecnosti definované ako nesúlad medzi objektovým a relačným svetom (impedance mismatch). Celé riešenie bude demonštrované na adekvátnom objektovom modeli a jeho relačnom ekvivalente, kde bude znázornené ako sa jednotlivé objekty a ich špecifické prvky transformujú na tabuľky relačnej databázy. Načrtneme si taktiež návrh opačného procesu transformácia relačnej databázy na objektovú. V závere kapitoly si uvedieme, ako by bolo možné ďalej aplikáciu rozšíriť respektíve modifikovať, aby priniesla ešte bohatšiu funkcionalitu a väčší úžitok pri jej používaní a tiež zhodnotíme, ktoré aspekty tejto problematiky aplikácia nerieši resp. uvedieme hlavné nedostatky a chybové stavy, ktoré môžu vzniknúť pri preklápaní dátových štruktúr medzi databázami. 3.1 Špecifikácia hlavných požiadaviek Aby aplikácia dokázala zabezpečovať požadovanú funkcionalitu, bolo potrebné identifikovať nasledujúce hlavné požiadavky, ktoré bude treba implementovať : Vytvoriť pripojenie na relačnú databázu PostgreSQL Vytvoriť pripojenie na objektovú databázu Caché Export definícii tried do XML dokumentu Identifikácia elementov a atribútov v XML dokumente Prenos (migrácia) samotných dát medzi databázami Definícia transformačných pravidiel 18

26 Evidencia dočasných (pracovných) údajov Generovanie SQL (DDL) kódu Možnosť zásahu používateľa pri automatickom preklápaní dátových štruktúr Prehľadný výpis o tom, ako a čo sa transformovalo medzi databázami Správa konfiguračných súborov aplikácie Okrem hlavných požiadaviek tzv. funkcionálnych, sme identifikovali ešte menej dôležité požiadavky nefunkcionálne, ktoré nie sú z hľadiska riešenej problematiky kľúčové, avšak pri implementácii taktiež zohrávajú svoju rolu. Medzi takéto požiadavky možno zaradiť : Intuitívne grafické rozhranie Dostatočná spoľahlivosť a efektívnosť Primeraná spätná väzba aplikácie Nenáročné technické požiadavky kladené na operačný systém Optimálna bezpečnosť z hľadiska prístupu k databázam 3.2 Nesúlad medzi objektovým a relačným modelom Aby bolo možné navrhnúť proces preklápania dátových štruktúr objektových a relačných databáz, je potrebná identifikácia tých konštrukčných prvkov, ktoré nemajú jednoznačný ekvivalent u opačnej paradigmy alebo sa nedajú zastúpiť vôbec. Zatiaľ čo objektovo-orientovaná technológia je výsledkom práce softvérových inžinierov, relačne orientovaná technológia je postavená na overenom matematickom základe. Súbor nezhodných prvkov medzi týmito dvoma prístupmi sa označuje ako nesúlad objektového a relačného modelu 3. Objekty spájajú dáta so správaním, tabuľky relačných databáz obsahujú iba dáta. Pretože sa tieto dve paradigmy v mnohých prvkoch odlišujú, ich vzájomná spolupráca nebude bezproblémová [14]. Medzi hlavné objektovo-orientované koncepty, ktoré je dôležite spomenúť v súvislosti s objektovo-relačný mapovaním, patrí : 3 Object-relational impedance mismatch 19

27 Zapúzdrenie - objektovo-orientované programy obsahujú premenné a metódy, ktorých vnútorná reprezentácia je skrytá pred vonkajším svetom - miesto priameho obmedzenia cez rozhranie objektu je možné v relačnej databáze do určitej miery použiť rolu ako mechanizmus pre reguláciu prístupu - RDBMS automaticky priraďuje dátam sadu prípustných operácii, prístupové obmedzenie je možne taktiež dosiahnuť postupným odstraňovaním týchto dát [14] Rozhranie, Trieda, Dedičnosť, Polymorfizmus - prístup k objektu je možný prostredníctvom rozhrania, je to vlastne jediný spôsob ako sa dostať k vnútornej štruktúre objektu - v relačnom modeli sa využívajú pohľady (wievs), ktoré zároveň zabezpečujú rôzne obmedzenia, aby zaistili integritu [15] - podobne, triedy objektov, dedičnosť a polymorfizmus nie sú v relačnom databázovom systéme podporované [16] Rozdielnosť dátových typov - relačný model vôbec nepoužíva referenčné atribúty alebo pointre, naproti tomu v objektovo-orientovanej paradigme sa bežne používajú atribúty, ktorých hodnota je referencia na iný objekt - tabuľky relačných databáz obsahujú reťazcové typy, ktoré sú limitované svojou dĺžkou napr. VARCHAR[50], kým vlastnosti typu reťazec (String) v objektoch sú obmedzované iba pamäťou [14] Štrukturálna a integritná rozdielnosť - v objektovo-orientovaných jazykoch môžu objekty pozostávať z viacerých objektov alebo môžu mať svoju špecializáciu(generalizáciu), a tak mapovanie do tabuliek relačnej databázy je v tomto smere menej priamočiare - objekty nedefinujú obmedzenia (constraints), deklarujú výnimky (exceptions raising) [15] 20

28 Nesúlad medzi objektovým a relačným modelom sa v praxi rieši pomocou objektovorelačného mapovania. Nástroje pre mapovanie vytvárajú obojsmerné spojenie medzi dátami v relačnej databáze a objektmi v aplikácii.[16] Treba podotknúť, že univerzálne riešenie objektovo-relačného mapovania neexistuje, ale všeobecnosti sa používajú najčastejšie tieto dva nasledujúce prístupy : Kompenzácia - použitie medzivrstvy (frameworku), ktorá mapuje napríklad entity dátového modelu na objektový model, takáto medzivrstva sa zvykne označovať ako O/R Mapper. Minimalizácia - rozšírenie objektovo-orientovaného jazyka o prvky, ktorými možno pokryť relačný model [15] Naše riešenie bude realizované na princípe kompenzácie, kedy budeme implementovať medzivrstvu, ktorá bude z definícii Caché tried generovať zodpovedajúci DDL kód. 3.3 Opis transformačného procesu Celý transformačný proces dátových štruktúr pozostáva z niekoľkých základných krokov. Nasledujúci opis jednotlivých krokov transformačného procesu (obr. 2) je uvedený iba stručne, aby sme si dokázali urobiť celkový náhľad na stratégiu riešenia. Detailnejší opis bude uvedený v častiach Mapovanie objektových princípov na relačnú schému a Implementácia. Na úvod transformačného procesu potrebujeme získať inštancie pripojenia nad objektovou a relačnou databázou. Tieto inštancie pripojenia sa v aplikácii využívajú pri komunikácii aplikačnej logiky s riadiacim systémom bázy dát. Ako už bolo skôr spomenuté, spojenie sa realizuje prostredníctvom ovládača JDBC. Po skončení práce s databázami je dôležité ukončiť spojenie (deštrukcia inštancii pripojenia). 21

29 Ďalší krok zahŕňa výber schémy v objektovej databáze a následný export definícii tried tejto schémy Aplikácia ďalej načíta všetky triedy, ktoré sú definované v XML formáte do dátovej štruktúry DOM 4 a postupne ich analyzuje pomocou technológie XPath 5. Z jednotlivých objektovo-orientovaných prvkov sa ďalej generuje DDL kód, podľa definície konverzie dátových typov v súbore mapping.xml Pred tým, ako sa tento kód aplikuje na relačnú databázu, môže ho ešte používateľ podľa potreby modifikovať Po vytvorení dátovej štruktúry je už možné realizovať migráciu resp. kopírovanie samotných dát. Pre túto požiadavku sme využil existujúcu utilitu Caché databázy Caché SQL Gateway, ktorá zaisťuje prístup k objektom v databáze pomocou štandardného jazyka SQL. Obr. 2: Návrh nášho transformačného procesu dátových štruktúr medzi objektovou a relačnou databázou. 4 Document object model dátová štruktúra, ktorá reprezentuje XML dokument ako strom. 5 XPath dotazovací jazyk, ktorý slúži pre výber uzlov a ich atribútov v XML. 22

30 Na základe návrhu transformačného procesu sme si ujasnili a vymedzili rozsah funkčného potenciálu našej aplikácie, ktorý bude zabezpečovať : mapovanie atribútov na stĺpce v relačnej databáze mapovanie tried na tabuľky relačnej databázy implementáciu dedičnosti v relačnej databáze mapovanie asociačných, agregačných a kompozičných vzťahov mapovanie kolekcii typu array a list mapovanie vnorených (embedded) objektov mapovanie indexov 3.4 Mapovanie objektového modelu na relačnú schému Aby sme si ukázali ako naša aplikácia rieši transformáciu jednotlivých objektovoorientovaných prvkov, navrhneme si objektový model s príslušnými objektovými prvkami, za pomoci ktorého demonštrujeme postupné preklápanie dátových štruktúr objektov na tabuľky relačnej databázy. Navrhnutý objektový model (obr. 3) zastrešuje oblasť, ktorá sa týka obchodnej firmy(company) so zamestnancami (employees), ktorá ponúka svoje produkty(productes) uložené na sklade (warehouse) zákazníkom (customers). Zákazníci si kupujú produkty tejto firmy prostredníctvom objednávok(orders),. Jednotlivé entity sú v objektovom modeli reprezentované pomocou tried. 23

31 Obr. 3: Ukážka objektového modelu jednotlivé triedy a rôzne typy vzťahov medzi nimi. 24

32 3.4.1 Mapovanie generalizácie (dedičnosti) Je zrejmé, že relačné databázy v prirodzenom smere nepodporujú princíp dedičnosti. Existujú však stratégie, ktorých implementáciou je možné do určitej miery napodobiť dedičnosť v relačnej databáze : Celá hierarchia tried sa premietne do jedinej tabuľky v relačnej databáze Výhoda implementácie takejto stratégie je predovšetkým jednoduchý prístup k tabuľke a jednoduchosť pridávania nových tried, ktorých atribúty sa potom iba pridajú do tejto jedinej tabuľky. Medzi hlavné nevýhody takéhoto mapovania možno zaradiť zviazanosť tried v hierarchii do jedinej tabuľky - zmena v jednej triede môže mať vplyv na tabuľku, ktorá potom môže mať vplyv na iné triedy v hierarchii. Ďalším veľkým problémom je, že dochádza k plytvaniu miesta v databáze redundancia dát. Taktiež pri väčšej hierarchii tried môže tabuľka rýchlo narastať, čo môže mať pri ďalších operáciách nežiaduce vplyvy. Každá trieda v hierarchii sa premietne do samostatnej tabuľky v relačnej databáze. Medzi výhody takejto stratégie patrí to, že je ľahko, čo môže byť účelné práve pri našej aplikácií z pedagogického hľadiska. Ďalej je možné veľmi jednoducho zmeniť nadtriedy a pridávať nové podtriedy, nakoľko nám stačí vždy modifikovať resp. pridať len jednu tabuľku. Ako nevýhoda by sa mohol javiť fakt, že pri načítaní objektu je nutné sprístupniť viacej tabuliek. Po dlhšom zvažovaní sme dospeli k tomu, že pri transformačnom procese využijeme prvý spôsob aplikovania dedičnosti v relačnej databáze, hoci tento spôsob je viacej náchylnejší k tomu, aby porušoval normalizačné pravidlá v relačnej databáze i keď na druhej strane predpokladáme, že hierarchia generalizácie nebude nejako obzvlášť veľká. Predsa len, aplikácia ma slúžiť ako nástroj, za pomoci ktorého demonštrujeme ekvivalenciu dátových štruktúr objektovej a relačnej databázy a nie ako nástroj, ktorý môže byť skutočne nasadený do reálneho prevádzky. 25

33 3.4.2 Mapovanie asociačných a kompozičných vzťahov. Projekcia vzťahov tried do relačnej databázy závisí na hodnote kardinality. Strana ONE alebo PARENT sa v tabuľke premietne ako stĺpec, ktorý obsahuje referenčné hodnoty definované pomocou cudzích kľúčov na tabuľku, ktorá je projekciou triedy, ktorej hodnota kardinality vzťahu je MANY alebo CHILDREN. Strana s hodnotou kardinality MANY alebo CHIDLREN nie je do relačnej tabuľky mapovaná vôbec, lebo to jednoducho nie je potrebné. Kompozičný vzťah sme zabezpečili v relačnej databáze takým spôsobom, že cudzí kľúč obsahuje klauzulu ON DELETE CASCADE. V našom ukážkovom objektovom modeli( obr. 3) si to môžeme demonštrovať na vzťahu customer a order, kedy pri zániku objektu typu customer automaticky zanikajú aj objekty typu order, ktoré sa na tento objekt odkazovali Mapovanie asociačného vzťahu many to many Objektová databáza Caché nedokáže priamo implementovať vzťah many to many. Miesto toho je potrebné ešte zabezpečiť implementovanie medzitriedy, ktorá sa do relačnej databázy premietne ako väzobná tabuľka. Je to identický postup s tým, kedy sa v relačnej databáze vzťah many to many rozbije na dva asociačné vzťahy one many za pomoci vytvorenia väzobnej tabuľky. Takže táto medzitrieda sa premietne do relačnej databázy ako väzobná tabuľka obsahujúca dva stĺpce, ktoré tvoria cudzie kľúče odkazujúce sa na tieto dve triedy, medzi ktorými bola pôvodne väzba many to many Mapovanie kolekcie (pole) Jedným zo spôsobov ako implementovať v relačnej databáze kolekciu typu pole je vytvorenie ďalšej tabuľky, ktorá bude uchovávať jednotlivé položky poľa. Názov tejto novej tabuľky je zložený z názvu triedy, v ktorej sa pole nachádza a zo samotného názvu poľa. Nová tabuľka je zložená z troch stĺpcov. Prvý obsahuje ID každej inštancie rodičovskej triedy. Tu treba pripomenúť, že dané ID nie je pre túto tabuľu jedinečné, ale jedinečné je v rodičovskej tabuľke. Druhý stĺpec obsahuje identifikátor pre každý prvok 26

34 poľa a tretí stĺpec je pre samotný prvok poľa. A samozrejme, môžeme ešte pridať ďalší stĺpec typu OID 6, ktorý bude reprezentovať primárny kľúč každého záznamu Mapovanie vnorených (embedded) objektov Vlastnosť, ktorá je typu vnorený object (serializable), sa premietne do relačnej tabuľky takým spôsobom, že všetky vlastnosti, ktoré obsahuje serializovateľný objekt, sa pridajú ako ďalšie stĺpce do pôvodnej tabuľky. Názov vlastnosti serializovateľného objektu sa premietne do rodičovskej tabuľky ako názovserializovateľnéhoobjektu_názovvlastnosti. Treba pripomenúť dôležitý fakt, že pokiaľ trieda obsahuje viacej vnorených objektov, pri projekcii do relačnej databázy môže dôjsť k rýchlemu narastaniu tabuľky a tým pádom aj k redundancii dát, čo môže byť z hľadiska uloženia dát dosť neefektívne Mapovanie identity objektu Každý objekt je jednoznačne identifikovaný pomocou identifikátora objektu OID, ktorý je zložený z ID objektu a názvu triedy a nie je možné, aby mali dva objekty rovnakú identitu. Z toho dôvodu pre každú vytvorenú tabuľku vytvárame v relačnej databáze primárny kľúč typu OID, ktorý jednoznačne identifikuje každý záznam v tabuľke. Postupným preklápaním jednotlivých prvkov objektového modelu podľa vyššie opísaných transformačných pravidiel nám aplikácia zabezpečí vygenerovanie DDL kódu definujúceho výslednú dátovú štruktúru v relačnej databáze (obr. 4). Za povšimnutie stojí, že nám vznikli niektoré nové tabuľky, ktoré neboli v diagrame tried definované žiadnou triedou ako je v našom prípade napr. tabuľka Person_ s. Táto novovzniknutá tabuľka odzrkadľuje fakt, že typ pole v objektovom modeli nám podmienil vznik novej tabuľky v relačnej databáze, ktorá bude obsahovať jednotlivé položky poľa. Naopak, trieda IdCompany sa nepremietla do žiadnej tabuľky v relačnom modeli, pretože inštancie tejto triedy sú vnorené objekty a tie mapujeme takým spôsobom, že atribúty serializovateľnej triedy sú pridané ako nové stĺpce v pôvodnej tabuľke. 6 Object identifier 27

35 Obr. 4: Implementácia transformovaného objektového modelu v relačnej databáze 28

36 3.5 Spätný proces transformácia relačnej databázy na objektovú Relačné databázové systémy poskytujú spoľahlivé, štandardizované a robustné riešenie zabezpečenia perzistencie dát. Avšak pri pokusoch o použitie relačných databáz, pri pokročilejších aplikáciách softvérového inžinierstva, vedomostných, dopravných alebo multimediálnych systémov, sa rýchlo preukázali ich nedostatky. Vykonávanie zložitých operácií nad komplexnými objektmi vyvolalo potrebu objektových databázových systémov, ktoré by lepšie uspokojili ich požiadavky. Z toho dôvodu vzniká požiadavka na transformáciu existujúcej relačnej databázy na objektovú databázu. Hlavný princíp celej transformácie spočíva v nahradení všetkých prvkov relačnej databázy za im zodpovedajúce objektové elementy, analogicky ako pri našom objektovorelačnom transformačnom procese. Celý transformačný proces si môžeme rozdeliť do štyroch základných krokov (obr. 5) : V prvej fáze je potrebné získať informácie, na základe ktorých bude vytvorená nová objektová schéma. Tieto informácie získame z relačnej databázy. Ďalej je nutné získať aj sémantické informácie, ktoré však nie sú explicitne prístupné z relačnej schémy ale získavajú sa v procese sémantického rozšírenia. V nasledujúcom kroku je možné na základe získaných informácii transformovať relačnú schému na objektovú. Predchádzajúce kroky by mali umožniť automatickú migráciu dát z relačnej do objektovej databázy. Úlohou sémantického rozšírenia je získanie dodatočných informácií z relačnej databázy, ktoré nie sú explicitne dostupné. Proces je známy aj pod pojmom databázové reverzné inžinierstvo. Môžeme ho považovať za inverzný proces k procesu tvorby databázy. Databázové reverzné inžinierstvo je komplexný proces, avšak často chybový. Jeho zložitosť vyplýva z toho, že sémantické informácie pôvodne dostupné v konceptuálnej schéme sa jej transformáciou do relačnej stratili (napr. kardinalita vzťahov). A práve tu je dôležitá používateľská interakcia, aby bolo možné identifikovať správnu reprezentáciu. Používateľ by mal používať iba zadefinovanú množinu operácii transformačných 29

37 pravidiel. Po zásahu používateľa už je možné pomocou transformačného procesu vytvoriť objektovú schému. Posledným krokom procesu je migrácia samotných dát, čo by pri korektnej transformácii medzi relačným a objektovým modelom malo prebehnúť automatizovane. Obr. 5: Schéma transformačného procesu medzi relačnou a objektovou databázou Tu je dôležité uviesť, že relačno-objektové mapovanie nie je také priamočiare ako objektovo-relačné mapovanie a v súčasnosti sa využíva iba zriedkavo, hoci v budúcnosti tomu môže byť inak. Taktiež ako nevýhoda sa môže javiť to, že je nevyhnutný zásah ľudského faktora za účelom sémantického rozšírenia základných údajov, čo vlastne znemožňuje dosiahnutie úplnej automatizácie. V tejto podkapitole sme si predstavili stručný návrh procesu relačno-objektovej transformácie. Pri procese preklápania dátových štruktúr z relačnej do objektovej databázy dochádza analogicky k rovnakým transformáciám ako pri procese opačnom objektovo-relačnej transformácii. Vo všeobecnosti, napr. triedy sa premietnu v relačnej databáze na tabuľky a naopak alebo atribúty triedy na stĺpce tabuľky a naopak. Z implementačného hľadiska našej aplikácie databázového rozhrania som práve toto považoval za hlavný dôvod, prečo som sa rozhodol túto funkcionalitu reverznej transformácie dátových štruktúr ku objektovo-relačnej transformácii neimplementovať. 30

38 Následne som sa mohol tak viacej sústrediť pre dokonalejšiu implementáciu funkcionality objektovo-relačnej transformácie. 3.6 Návrh aplikácie Návrh aplikácie sme s rozdelili na niekoľko logických častí, ktoré sme si pomenovali moduly aplikácie: Konektory Konektory aplikácie budú slúžiť na ustanovenie spojenia s databázami, podľa zvolených parametrov. Trieda PostgreSQLConnector bude obsahovať metódu connect, ktorá vráti databázové pripojenie na relačnú databázu PostgreSQL a trieda CacheConnector taktiež metódu connect, ktorá vráti propojenie na objektovú databázu Caché Parser XML súborov Modul XML parser bude disponovať metódami určenými pre analýzu vybraného XML dokumentu, ktorý vznikne exportovaním definície triedy z Caché databázy ako aj XML dokumentu, ktorý bude obsahovať pravidlá definujúce to, ako sa dátové typy objektovej databázy budú mapovať do relačnej databázy. Elementy a atribúty XML dokumentu budú analyzované pomocou technológie XPath SQL Generátor Časť aplikácie, ktorú sme nazvali SQL Generátor, bude tvoriť kľúčový segment transformačného procesu dátových štruktúr medzi objektovou a relačnou databázou. Metóda generatecode bude generovať DDL kód z XML definície triedy. Bližšie si túto metódu opíšeme v kapitole Implementácia Prenášač dát Tento aplikačný modul by mal byť schopný na základe vytvorenej dátovej štruktúry v relačnej databáze preniesť dáta z databázy Caché do databázy PostgreSQL za podmienky, že vytvorená dátová štruktúra je korektná a zodpovedá tej objektovej. 31

39 3.7 Implementácia návrhu aplikácie V tejto časti práce si podrobne opíšeme implementáciu jednotlivých modulov aplikácie, predovšetkým tých, ktoré z hľadiska problematiky transformácie dátových štruktúr medzi databázami hrajú kľúčovú rolu. Celková vnútorná štruktúra jednotlivých častí implementácie je zobrazená na obrázku č Vytvorenie spojenia s databázami Spojenie s relačnou databázou PostgreSQL vytvárame prostredníctvom volania nasledujúceho príkazu : DriverManager.getConnection(jdbc:postgresql://localhost:5432/databaseNa me",username, password); kde databasename je názov konkrétnej databázy a paremetre username a password sú prístupové údaje do databázy. K objektovej databáze Caché sa pripájame obdobne prostredníctvom príkazu : CacheDatabase.getDatabase("jdbc:Cache://localhost:1972/USER",username, password); kde User definuje menný priestor, nad ktorým sa bude operovať Export definícii tried z objektovej databázy Prvý významný krok pri procese transformácie dátových štruktúr medzi databázami je export definície tried určitej schémy z databázy Caché do XML formátu, čo realizujeme nasledovným spôsobom : DatabaseUtilities.exportClass(className, path, "c", false); Vyššie uvedený príkaz sa vykoná práve toľkokrát, koľko tried obsahuje vybraná schéma pre každú triedu sa vytvorí samostatný XML dokument, ktorý opisuje definíciu triedy v XML jazyku. 32

40 3.7.3 Pomocné dátové štruktúry Bolo potrebné uvažovať, akou formou budú v programe reprezentované jednotlivé elementy Caché triedy. Nakoniec sme sa rozhodli reprezentovať každý takýto element v samostatnej dátovej štruktúre (obr. 6) práve pre flexibilnosť a nezávislosť elementu na konkrétnej triede, čo bude veľkou výhodou práve pri takých operáciách akou je napr. v našom programe aplikovanie dedičnosti potrebujeme kopírovať vlastnosti nadtriedy do podtriedy. Obr. 6: Java triedy, ktorých inštancie uchovávajú informácie o elementoch Caché tried Pre názornosť trieda Company obsahuje atribút Employees, ktorá je vlastne referenciou na inú triedu. Tento atribút je v XML súbore 7 reprezentovaný nasledovne : <Property name="employees"> <Type>Companies.Employee</Type> <Cardinality>many</Cardinality> <Inverse>Company</Inverse> <Relationship>1</Relationship> </Property> Práve preto sme si vytvorili triedy typu Property, Index alebo ClassInfo, ktoré sú vlastne akýmisi dočasnými dátovými štruktúrami, pretože uchovávajú definície jednotlivých 7 Tento XML súbor je vyexportovaná definícia Caché triedy. Caché triedy sa definujú v Caché Studiu v tzv. CLS jazyku Caché Definition Language. 33

41 elementov Caché tried. Vyššie uvedená časť XML dokumentu je v programe reprezentovaná nasledovne : Property newproperty = new Property(); newproperty.classname ="Company"; newproperty.name="employees"; newproperty.type="companies.employee"; newproperty.cardinality="many"; newproperty.inverse="company"; newproperty.relationship="1"; XML Parser analýza exportovaných tried Trieda XmlParser.java definuje metódu getzoznamelementov(string path), ktorej jediný parameter path určuje cestu k XML súboru, v ktorom je definícia danej triedy. Metóda vracia zoznam (List) všetkých elementov Caché triedy ako sú Property, Index alebo ClassInfo. Ďalšou metódou, ktorú implementuje trieda XmlParser.java, je metóda getzoznammapovacichpravidiel(string path), ktorá podobne ako predchádzajúca metóda, obsahuje jeden parameter path určujúci cestu k XML súboru a vracia zoznam inštancii triedy MappingRule. Trieda MappingRule, podobne ako trieda Property je dátovou štruktúrou, v ktorej si uchovávame informáciu o tom ako sa konkrétny dátový typ objektovej databázy Caché premietne do relačnej databázy. Napríklad : <Type> <CacheType>%String</CacheType> <SqlType>VARCHAR</SqlType> </Type> Dátový typ objektovej databázy String sa premietne do relačnej databázy ako dátový typ VARCHAR. Výhoda takejto reprezentácie pomocou XML súboru je, že si môžeme túto konfiguráciu konverzie dátových typov podľa potreby ľubovoľne modifikovať Implementácia modulu zabezpečujúceho aplikáciu dedičnosti Dedičnosť je v definícii triedy v Caché databáze vyjadrená pomocou kľúčového slova Extends: Class Companies.Customer Extends Companies.Person 34

42 Preto naša aplikácia musí byť schopná identifikovať takéto prípady, kedy podtrieda dedí všetky atribúty nadtriedy. V časti sme si ukázali, akými dvoma spôsobmi budeme zabezpečovať prípad dedičnosti v relačnej databáze pôvodná tabuľka podtriedy sa rozšíri o všetky atribúty tých tried, ktoré sú uvedené za kľúčovým slovom Extends. Metóda applyinheritance triedy ObjectFeatures.java vracia nový zoznam elementov triedy vrátane pridaných atribútov a samozrejme aj príslušných indexov týchto atribútov a to realizuje takým spôsobom, že prechádza cez elementy atribúty a indexy všetkých tried danej schémy a vyberie tie, ktorých parameter property.classname resp. index.classname sa zhoduje s tými, ktoré sú uvedené pri danej triede ako nadtriedy. Tu treba pripomenúť, že funkčnosť neobmedzujeme iba na jednu nadtriedu, ale na ľubovoľný počet tried, ktoré sú uvedené za kľúčovým slovom Extends, avšak vysporiadanie sa s kolíziami, ktoré sa týkajú názvov zdedených vlastností je už mimo rozsahu schopností našej aplikácie a tak sa pri testovaní bude predpokladať, že zdedené vlastnosti viacerých tried nebudú rovnomenné. Je dôležité, aby sa nadtrieda nachádzala v rovnakom balíku ako podtrieda, pretože tak sme to implementačne zabezpečili. Rovnakým spôsobom sme sa rozhodli v relačnej databáze riešiť implementáciu vnorených objektov, takže metóda applyserialize funguje podobným štýlom ako predchádzajúca metóda, okrem toho však ešte musí zisťovať, či je vlastne typ atribútu vnorený objekt. Napríklad pri definícii atribútu Property EmployeeAddress As Companies.Address; zisťuje, či je trieda HierarchyPack.Address rozšírením systémovej triedy %SerialObject. Ak áno, potom metóda vráti nový zoznam elementov triedy, vrátane tých, ktoré obsahuje serializovateľná trieda HierarchyPack.Address. Je dôležité uviesť, že serializovateľná trieda nie je vyjadrená v relačnej databáze vlastnou tabuľkou, pretože nemá vlastnú identitu a teda nemôže vystupovať ako samostatný objekt. 35

43 3.7.6 Generovanie DDL kódu Modul aplikácie, ktorý rieši generovanie DDL kódu je z pohľadu transformácie dátových štruktúr databáz najdôležitejší. Implementácia tohto modulu obsahuje priamo pravidlá, podľa ktorých sa jednotlivé prvky objektovo-orientovanej schému budú transformovať na nim prislúchajúce relačné ekvivalenty. Trieda SQLGenerator.java implementuje metódu generatesqlcode, ktorá je definovaná jedným vstupným parametrom typu List, ktorý obsahuje zoznam všetkých elementov danej triedy. Metóda postupne vyhodnocuje jednotlivé elementy tejto triedy a generuje príslušný DDL kód definujúci jednotlivé stĺpce v relačnej databáze, primárne a cudzie kľúče a indexy. Návratový typ metódy je String, ktorý obsahuje celkovú DDL definíciu jednej tabuľky. Pre demonštráciu si uveďme príklad : Zadajme na vstup metódy zoznam, ktorý obsahuje nasledujúce elementy objektovoorientovanej triedy : classinfo.classname = "Companies.Customer" classinfo.superclasses ="Companies.Person" property_1.classname = "Companies.Customer" property_1.name=" " property_1.type="%string" property_2.classname = "Companies.Customer" property_2.name="company" property_2.type="companies.company" property_2.cardinality="one" property_2.relationship="1" Logika metódy postupne prechádza cez celý tento zoznam elementov a postupne vytvára výsledný DDL reťazec : CREATE TABLE companies.customer ( " " character varying, "Company" oid, "ID" oid NOT NULL, CONSTRAINT "Companies.Customer_pkey" PRIMARY KEY ("ID"), CONSTRAINT "Companies.Company_fkey" FOREIGN KEY ("Company") ); 36

44 Stojí tu za povšimnutie, ako sa nám dátový typ %String z objektovej databázy konvertoval na dátový typ character varying. Takúto projekciu typov sme dosiahli volaním metódy tej istej triedy maptype(string cachetyp), ktorá nám vráti dátový typ relačného ekvivalentu ku dátovému typu Caché. Všetky kroky transformačného procesu objektovo-relačného mapovania, ktoré sme si doposiaľ uviedli, boli v podstate úplne automatizované a tak nemožno vylúčiť, že pri zložitejších objektových modeloch došlo k neočakávanej transformačnej udalosti, nehovoriac o tých objektových prvkoch, ktorých transformáciu do relačnej databázy aplikácia vôbec nezabezpečuje. Z toho dôvodu môže používateľ ešte pred aplikovaním DDL kód na relačnú databázu tento kód ľubovoľne modifikovať, prípadne pridať nové definície tabuliek, atribútov, indexov, integritných obmedzení atď Vloženie DDL kódu do relačnej databázy a prenos dát V našom prípade DDL definícia každej tabuľky je obsiahnutá v jednej premennej typu String. Tieto premenné sú uložené do fronty, odkiaľ sú postupne vyberané a pomocou API funkcie createstatement.execute() aplikované na relačnú databázu, nie však v ľubovoľnom poradí. Nie je predsa možné vytvoriť skôr tabuľku Employee ako tabuľku Company, pretože tabuľka Employee obsahuje cudzí kľúč, ktorý sa odkazuje práve na atribút primárneho kľúča tabuľky Company. Posledný krok celkového transformačného procesu je migrácia samotných dát z objektovej do relačnej databázy. Pre túto činnosť sme využili utilitu objektovej databázy Caché Caché SQL Gateway, ktorá umožňuje pristupovať k jednotlivým inštanciám tried k objektom pomocou SQL jazyka. Z vytvorenej dátovej štruktúry z predchádzajúcich krokov transformačného procesu si dokážeme vyextrahovať jednotlivé názvy tabuliek a ich atribútov a tak nie je problém pomocou klasických SQL dopytov získať samotné dáta objektov. 37

45 Obr. 7: Diagram Java tried znázorňujúci štruktúru aplikácie z implementačného hľadiska 3.8 Overenie správnosti riešenia Po implementovaní jednotlivých častí návrhu transformačného procesu je potrebné vykonať dostatočné množstvo testov, aby sme sa uistili, že aplikácia skutočne interpretuje navrhovaný transformačný proces a jeho predpokladané výstupné hodnoty. Pred tým než začneme s preklápaním dátových štruktúr objektovej databázy do relačnej, je potrebné aby sme v objektovej databáze vytvorili schému s definíciou jednotlivých tried. K tomuto nám poslúži náš objektový model (obr. 3), ktorého definíciu implementujeme v objektovej databáze Caché. V prílohe C je zobrazená kompletná definícia tohto objektového modelu a zároveň aj výstup - aplikáciou generovaný príslušný DDL kód. V prílohe B taktiež 38

46 uvádzame akceptačné testy, ktoré sa týkajú najfrekventovanejších operácii vykonávaných nad našou aplikáciou. Celkovo možno povedať, že pri štandardnej a nie príliš komplikovanej definícii jednotlivých Caché tried, aplikácia generuje korektný DDL kód a správne realizuje prenos dát medzi objektovou a relačnou databázou. Treba priznať, že určitá chybovosť sa začína prejavovať pri zložitejších definíciách tried, avšak také nie sú predmetom zadania riešenej problematiky pre nás je dôležité ukázať, ako možno medzi sebou transformovať dátové štruktúry objektovej a relačnej databázy a komplikované definície v objektovom modeli budú takémuto účelu slúžiť asi ťažko. Ukážky typických definícii Caché tried, ktoré aplikácia dokáže spracovať so stopercentnou spoľahlivosťou, sú v spomínanej prílohe C. 3.9 Výučbový potenciál výsledného produktu Našou úlohou v tomto projekte bolo okrem realizovanej transformácie dátových štruktúr aj prispôsobiť riešenie úlohy tak, aby tento návrh transformačného procesu a jeho implementácia v podobe aplikácie mohli slúžiť ako nástroj, za pomoci ktorého je možné dostatočne demonštrovať spoločné a odlišné prvky objektovej a relačnej databázy. Túto úlohu sme splnili, ale iba do určitej miery. Používateľ tu môže jasne vidieť napr. akým spôsobom sa triedy objektového modelu ukladajú do relačnej databázy po kliknutí na názov triedy sa mu zobrazí definícia triedy a následne ju potom môže porovnávať so zodpovedajúcim DDL kódom pre relačnú databázu. Pre väčšiu efektivitu v pedagogickom smere, by sa žiadalo doimplementovať viacej grafických znázornení v aplikácii, čo možno brať ako dobrú motiváciu pri pokračovaní riešenia do budúcnosti. 39

47 4 Technická dokumentácia V tejto kapitole si urobíme náhľad na vývoj a používanie aplikácie po technickej stránke. 4.1 Zoznam použitých technológii Program je implementovaný v jazyku Java (Enterprise Edition 5 SDK) funkčná logika pomocou najpopulárnejšieho vývojového prostredia pre Javu Eclipse Europa a grafické používateľské rozhranie v Eclipse plugine - Jigloo hlavne pre jednoduchosť vytvárania a prideľovania funkcionality grafickým prvkom aplikácie. Aplikácia pristupuje k objektovej databáze Caché prostredníctvom ovládača JDBC, ktorý je definovaný v triede com.intersys.objects.database a k relačnej databáze PostgreSQL 9.0 taktiež pomocou JDBC ovládača, ktorý je súčasťou java balíka postgresql jdbc4.jar. Export definície tried z objektovej databázy a aplikačná konfigurácia je zabezpečovaná pomocou jazyka XML. Objektový model (obr. 3), dátový model (obr. 4) a diagram Java tried(obr. 5) boli vypracované v programe Rational Software Architect Vývoj a testovanie aplikácie prebiehal pod operačným systémom Microsoft Windows XP Professional, Verzia 2002, SP Požiadavky na použitie aplikácie Na spustenie a používanie aplikácie je potrebné splniť niekoľko nevyhnutných požiadaviek : Platforma (operačný systém) musí obsahovať inštaláciu Javy minimálne Java JRE 8. Aby aplikácia mohla realizovať transformáciu odlišných dátových štruktúr databáz, musí operačný systém disponovať inštaláciou OODBMS Caché Intersystems a taktiež aj RDBMS PostgreSQL. Používateľ musí mať povolenie na prístup k menovaným databázam 8 Java Runtime Enviroment 40

48 Objektová databáza Caché musí obsahovať nejakú schému spolu s definíciami jednotlivých tried, aby aplikácia mala čo transformovať. V priečinku so spustiteľným súborom bin.jar sa musí nachádzať priečinok config/, v ktorej je obsiahnutý XML súbor s názvom mapping.xml, ktorý obsahuje pravidlá konverzie dátových typov Caché na dátové typy relačnej databázy. Okrem priečinku config/ sa neskôr pri exportovaní tried z databázy Caché vytvorí ďalší priečinok /exported_classes, ktorý bude obsahovať definícu tried v XML súboroch. 4.3 Používateľská príručka Jednou z výhod aplikácie je, že nie je potrebná jej inštalácia, spúšťa sa pomocou jedného vykonateľného súboru bin.jar. Hlavné okno aplikácie (obr. 10) je pomerne jednoduché a intuitívne ale s určitosťou postačujúce pre potreby nášho zadania. Je rozdelené na niekoľko logicky súvisiacich častí. Pri práci s aplikáciou je ako prvé potrebné sa prihlásiť na server tak ako objektovej tak aj relačnej databázy. Na obrázku č. 8 je znázornený vstupný dialóg obsahujúci vstupné polia pre prihlasovacie údaje na databázy a URL adresu databázového servera. Po úspešnom prihlásení sa nám v pravej časti tohto dialógu zobrazia všetky schémy, ktoré obsahuje databáza, na ktorú sme sa prihlásili. Obr. 8: Vstupný dialóg pre vytvorenie spojenia s databázou 41

49 Po výbere schémy, ktorú budeme chcieť transformovať sa nám v ďalšej časti okna zobrazia jednotlivé triedy danej schémy (obr. 9). Tu si môže používateľ kliknúť na určitú triedu a následne sa zobrazí jej definícia v XML súbore, ktorú je možné podľa potreby modifikovať. Obr. 9: Zoznam tried, ktoré obsahuje vybraná schéma Nasleduje najpodstatnejšia funkčná časť aplikácie generovanie DDL kódu, čo používateľ realizuje pomocou tlačidla Generate SQL Code. V strednej časti hlavného okna Generated SQL Code sa následne zobrazí vygenerovaný DDL kód. Tento si môže ďalej používateľ podľa potreby midofikovať. Tlačidlom Insert DDL Code to PostgreSQL sa spúšťa operácia, ktorá uloží generovaný kód do relačnej databázy PostgreSQL a posledná časť transformačného procesu kopírovanie dát sa realizuje tlačidlom Copy Data From Caché to PostgreSQL. Dolná časť hlavného okna obsahuje sekciu s názvom Info About Operations, ktorá nám podáva informácie o úspešných a neúspešných operáciách nad databázmi. Pravá časť okna obsahuje ešte tačidlo Mapping Rule, ktoré otvorí XML súbor s konverziou typov, ktorú si môže používateľ ešte dodatočne takýmto spôsobom upravovať. 42

50 Obr. 10: Celkový náhľad na grafické používateľke rozhranie aplikácie. 43

51 5 Zhodnotenie Cieľom zadania bakalárskej práce počas zimného semestra bolo oboznámenie sa s predstaviteľmi relačných a objektových databáz a ich technológiami na správu dát a taktiež vyšpecifikovanie typických vlastností relačných a objektových databáz. Ako predstaviteľa relačnej databázy sme si vybrali databázu PostgreSQL a na druhej strane databázu Caché ako zástupcu objektových databáz. Teoretické poznatky, ktoré sme nadobudli počas riešenia bakalárskeho projektu I, nám priniesli dobrú východiskovú pozíciu pre ďalšiu časť zadania, ktorou bol návrh transformačného procesu dátových štruktúr medzi odlišnými typmi databáz. Hlavné ťažisko práce na bakalárskom projekte II spočívalo už v spomínanom návrhu transformačného procesu a v jeho implementačnom zabezpečení pričom sme prihliadali na fakt, že návrh tohto procesu by mal dostatočne odrážať to, ktoré typické prvky majú objektový a relačný model spoločné a naopak, ktoré charakteristické vlastnosti databázy sa pri transformácii jej dátovej štruktúry na iný typ strácajú resp. menia. Práve tento aspekt by mal pokrývať požadovaný výučbový zámer. Môžeme skonštatovať, že sa nám podarilo takýto proces úspešne navrhnúť hoci podrobnejšie sme špecifikovali a implementačne zabezpečili v tejto práci iba smer transformácie z objektovej do relačnej databázy avšak pri hrubšom návrhu opačného smeru transformácie sme dospeli k záveru, že sa pri jeho realizácii predpokladá analogický postup. Funkčný potenciál aplikácie sme demonštrovali na množine testov, pri ktorých sme dosiahli prevažne očakávané výstupné hodnoty a taktiež sme sa snažili v čo najväčšej miere ošetriť chybové stavy aplikácie. Je zrejmé, že nie v silách jedného študenta, aby v obmedzenom čase vytvoril nástroj, ktorý by dokázal konkurovať súčasným komerčným riešeniam alebo by dokázal ošetriť transformáciu každého charakteristického prvku pre danú schému v podstate to nebolo od nás ani vyžadované. Napriek tomu si myslím, že sa nám podarilo vyriešiť transformáciu kľúčových záležitostí, ktoré tvoria základ objektových a relačných databáz a hlavne sme dokázali znázorniť, čo sa akým spôsobom mapuje do typovo odlišnej 44

52 databázy, hoci pre väčšiu názornosť by bolo treba ešte v aplikácii doimplementovať viacej grafických znázorňovacích prvkov. Do budúcnosti by stálo za uváženie aj implementačne zabezpečiť akúsi medzivrstvu, ktorá by dokázala zovšeobecňovať schémy rozličných objektových databáz na jednotný typ objektovej schémy, aby sa použitie aplikácie nemuselo obmedzovať iba na jednu konkrétnu databázu v tomto prípade databázu Caché. Na poste relačnej databázy je možne bez problémov urobiť zmenu, nakoľko generovaný DDL kód je štandard používaný vo väčšine súčasných relačných databázach. 45

53 6 Zoznam použitej literatúry [1] MATIAŠKO, Karol et al.: Databázové systémy Základy databázových systémov. Vydavateľstvo: EDIS, ISBN [2] Relational Database Systems An Introduction [3] Relačná databáza [4] COOPER, R.: Object Databases: An ODMG Approach, Intl. Thomson Computer Press, [5] MOMJIAN, Bruce : PostgreSQL Praktický pruvodce. Vydavateľstvo: Computer Press, ISBN [6] Průvodce technologií InterSystems Caché. CZ.pdf [7] Using Caché object : The Caché Object Model. [8] PostgreSQL : About. [9] Using Java with Caché: The Caché Java Binding 46

54 [10] KIRSTEN, W. IHRINGER, KUHN, M. et al.: Object-Oriented Application Development Using the Caché Postrelational Database, Springer-Verlag 2003, ISBN [11] Hibernate [12] Hladík, I. : Hibernate, Wesley. ISBN [14] Ambler, S ( ). Object relational impedance mismatch. [15] Tropashko, V. Object relational impedance mismatch [16] (2008) The object relational impedance mismatch [13] Fowler, Martin (2003). Patterns of enterprise application architecture. Addison _The_Object_Relational_amp_ldquo_Impedance_Mismatch_amp_rdquo.aspx 47

55 7 Prílohy Príloha A Použitá notácia diagram tried a dátový diagram V tejto práci bola použitá notácia UML. Použili sme doleuvedené typy diagramov a im prislúchajúce techniky opisu problémovej oblasti, ktorých stručné vysvetlenie uvádzame nižšie. Obr. 11: Trieda a jej atribúty Obr. 12: Asociačný vzťah medzi triedami rovnoprávny vzťah medzi triedami Obr. 13: Agregačný vzťah medzi triedami jedna trieda je súčasťou druhej Obr. 14: Kompozičný vzťah medzi triedami podriadený objekt nemôže existovať bez nadradeného 48

56 Obr. 15: Generalizácia špecializácia triedy Obr. 16: Dátová tabuľka v tomto prípade obsahuje jeden primárny kľúč a dva atribúty Obr. 17: Vzťah s kardinalitou 1 ku 0 až n Obr. 18: Vzťah s kardinalitou 1 ku 1 Obr. 19: Vzťah s kardinalitou 1 ku 1 až n Obr. 20: Slovná poznámka týkajúca sa pripojeného objektu tejto poznámke 49