VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA STROJNÍHO INŽENÝRSTVÍ ÚSTAV AUTOMATIZACE A INFORMATIKY FACULTY OF MECHANICAL ENGINEERING INSTITUTE OF AUTOMATION AND COMPUTER SCIENCE

POROVNÁVACÍ STUDIE DATABÁZÍ COMPARATIVE STUDY OF DATABASES

BAKALÁŘSKÁ PRÁCE BACHELOR´S THESIS

AUTOR PRÁCE

MIROSLAV PAZDERA

AUTHOR

VEDOUCÍ PRÁCE SUPERVISOR

BRNO 2007

doc. Ing. BRANISLAV LACKO, CSc.

Strana 7

ANOTACE Předmět zadání a tedy jednotlivé cíle bakalářské práce zpracovávám pro konkrétní v praxi používaný projekt. Úlohy řeším v oblastech datového dotazovacího jazyku ( Data Query Language – DQL ), datového manipulačního jazyku ( Data Manipulation Language – DML) vycházejících ze standardů ANSI. Výsledkem této práce je porovnání relační a objektové databáze a na praktických příkladech srovnání jejich výkonů.

ANNOTATION Subject and single task of bachelor writing is making for the project, which practical use. The task solve in Data Query Language – DQL, Data Manipulation Language – DML. Result of the material is comparing relational study and object-oriented database; and the compare of their performances in the practice samples.

KLÍČOVÁ SLOVA Relační databáze, objektová databáze, SQL, ODMG, Caché, MSSQL 2005, databázový model, vrstvy datového systému

KEYWORDS Relation database, object database, SQL, ODMG, Caché, MSSQL 2005, database model, achitekture dabase system

Strana 9

Seznam použitých zkratek

ADT

Abstract Data Type

ANSI

American National Standards Institute

CODASYL

Conference On Data Systems Languages

CPU

Central Processing Unit

DAO

Data Access Object

DBMS

DataBaze Managment System

DML

Data Manipulation Language

DQL

Data Query Language

HTML

HyperText Markup Language

ISV

Independent Software Vendor

JDO

Java Data Objects

ODMG

Object Database Management Group

OODBMS

Object Oriented Database Management System

OODM

Object Oriented Database Model

OQL

Object Query Language

ORDBMS

Object Relational Database Management System

ORDM

Object Relational Database Model

PDA

Personal Digital Assistants

RDBMS

Relational Database Management System

SQL

Structured Query Language

SŘBD

Systém Řízení Báze Dat

XML

eXtensible Markup Language

Strana 11

OBSAH:

Zadání bakalářské práce ................................................... Licenční smlouva .............................................................. Abstrakt a klíčová slova .................................................... Seznam použitých zkratek ................................................ Obsah ............................................................................... Úvod ................................................................................. 1 2 Popis prostředí pro řešení cílů .......................................... 3 Cíle bakalářské práce ........................................................ 3.1 Návrh srovnávacích testů výkonu objektové a relační databáze ... 3.2 Proveďte rozbor srovnání výhod a nevýhod relační a objektově orientované databáze .................................................................... 3.3 Doporučte vhodnou objektovou databázi, nahrazující relační databázi ........................................................................................... 4 Závěr .................................................................................. Literatura ........................................................................... Seznam příloh .................................................................... Přílohy .................................................................................

3 5 7 9 11 13 21 27 27 37 41 43 45 49 51

Strana 13

1 Úvod Dnes si již nedovedeme představit žádnou rozsáhlejší aplikaci bez nezávislého a výkonného řešení úložiště dat. Návrháři informačních systémů, aplikací mají k dispozici nepřeberné množství možností jak tento úkol řešit. Rozhodujícím měřítkem je bezpochyby rychlost v podobě přístupu k určitému objemu dat. Databáze je velmi obecný pojem. Pomineme-li počítačové pojetí můžeme si pod tímto pojmem představit sešit s jednotlivými záznamy našich přátel nebo obchodních partnerů s adresami a telefonními čísly případně tabulku s těmito informacemi. V rozsáhlejší podobě pak jako kartotéku. Každý z uvedených systémů má určité výhody v některé z požadovaných služeb na informační základnu. Sešit rozdělený podle abecedy po stránkách zjednoduší vyhledávání podle jména adresáta, tabulka se všemi záznamy nabídne komplexní přehled o uložených informacích. Výhoda kartotéky je v rozšiřovací možnosti datové základny nebo v archivaci již nepoužívaných dat. Při uspořádání je možné i přehledně vyhledávat. V dnešní počítačové době jsou převážně i tyto osobní záznami uchovávány v digitální podobě, v nejrůznějších formách, na různém hardware. Pro příklad srovnání můžeme uvést mobilní telefonní asistenty, počítačové stanice nebo servery. Je patrné, že uchovávání dat u těchto různých běžně používaných zařízení se musí zákonitě lišit a úložiště je tedy přímo závislé na použitém hardware. Databáze jsou využívány uživateli v nejrůznějších oborech a nelze dnes najít obor, kde by nebylo možné nebo nutné takto postupovat. Databáze tedy představuje nástroj pro shromáždění a uspořádání vzájemně souvisejicích informací, se kterými uživatel aplikace pracuje jako s kompaktní jednotkou. Každý výrobce databázového software přistupuje individuálně k řešení jednotlivých požadavkům na služby spojené se správou databáze. O takovém softwaru pak hovoříme jako o databázovém systému (Databaze Managment System DBMS, v českém prostředí Systém řízení báze dat SŘBD).

Mezi základní služby těchto software patří: o o o o o o

přesun dat mezi fyzickou a logickou vrstvou více uživatelské přístupy, jejich práva, nakládání s daty zálohování a obnova dat, úprava velikosti fyzických souborů databáze podpora dotazovacího jazyka datová integrita, reidexace, optimalizace procesů nezávislost na aplikaci, efektivní přístup k datům

1 Úvod

Externí vrstva

Strana 14

Uživatelský pohled 1




Logická datová nezávislost Logická vrstva

Interní schéma (logické schéma)

Databázový soubor

Databázový soubor

Databázový soubor

Databázový soubor

Databázový soubor

Fyzická vrstva

Databázový soubor

Fyzická datová nezávislost

Obr. 1: Vrstvy datového systému Nejrozšířenější modely databází Otevřené soubory (flat files) jsou soubory operačního systému. Obsahem těchto souborů jsou holá data bez metadat. Doslovný překlad slova metadata je „data o datech“ jedná se tedy o doplňující údaje o jaká data se jedná, identifikaci struktury nebo jiných informací vztahujících se k vazbám mezi záznamy. Informace o struktuře dat, vzájemných vztahů mezi záznamy musí obsahovat přímo aplikace, která s těmito soubory pracuje. Soubory nejsou čitelné v operačních systémech. Na základě znalostí metadat je možné prostřednictvím databázového systému převádět data ve fyzické vrstvě nebo-li mezi datovými strukturami v logickém schématu. Hierarchický model Byl vyvinut z původních souborových systémů, kde záznamy byly hierarchicky uspořádány do struktury podobné organizačnímu diagramu. Struktura jednotlivých záznamů je definována ukazateli, které za pomocí adres uvádí, kde se svázaný záznam fyzicky nachází. Nadřazený záznam (rodič) může mít jeden nebo více podřízených záznamů (potomků), ale podřízený záznam musí mít jen jeden nadřazený záznam. V tomto modelu nelze jednoduše řešit požadavky na dva nadřazené záznamy k jednomu podřízenému. To lze řešit přidáním dalších záznamů k jinému nadřízenému záznamu, které vedlo k duplicitě a v době používání tohoto modelu k nežádoucímu nárůstu obsazení diskového prostoru nebo použít řešení na aplikační úrovni. Z důvodu tohoto problému byl model dodatečně upraven firmou IBM. Úprava umožňovala, aby podřízený záznam měl více nadřazených záznamů. Tento model byl nazván rozšířený hierarchický databázový model.

1 Úvod

Strana 15

Síťový model Období vývoje síťového modelu je shodné s obdobím vzniku hierarchického modelu a jako u něj jsou relace mezi rodičovským záznamem a potomkem evidovány pomocí ukazatelů s fyzickými adresami. Informace o relaci je uvedena jen u nadřazených záznamů a jsou pojmenovány. Tím je umožněn přechod mezi záznami prostřednictvím konkrétní relace. Tato vlastnost způsobí, že jeden typ záznamů se může na straně potomků zúčastnit několika relací. Tento systém byl flexibilnější, ale na druhou stranu se vyznačoval daleko vyšší složitostí. Pojmenováním relací bylo možné řetězit ukazatele jednoho typu kruhově neboli cyklicky. Tento proces byl nazván „procházení množiny“. U tohoto modelu byla nutná specializovanovaná obsluha, která pečlivě kontrolovala aby nevznikaly nekonečné smyčky mezi relacemi. Síťový model umožňoval různorodost možností pro pořízení konkrétního záznamu z databáze, ale při špatné znalosti její struktury, mohlo dojít k tomu, že nebylo možené se k záznamu vůbec dostat. Nevýhodou tohoto modelu byla obrovská složitost a nákladná údržba databáze. To vedlo k nezájmu uživatelů a k ukončení dalšího vývoje. Z hlediska databází byl tento model významný zdůvodu uznávaného standardu DBTG CODASYL, který byl přijat roku 1971.

Obr. 2: Příklad síťového datového modelu [15] Relační model Základní myšlenka modelu je ve struktuře práce s množinou dat. Tou odstartoval svojí výzkumnou práci (1970) Dr. E.F. (Ted) Codd, který se považuje za zakladatele relačního databázového modelu. Nepracujeme tedy s jednotlivými záznamy jako u dříve uvedených modelů a také není třeba, pro získání požadovaných společně definovaných údajů, procházet celou databázi. Není nutné u relačního modelu znát všechny možné způsoby využití dat při návrhu datové struktury. Definujeme strukturu pro ukládání dat a datové množiny slučujeme podle potřeb a

1 Úvod

Strana 16

požadavků. Relační model je velmi dobře matematicky popsatelný, kde na relaci nahlížíme jako na konečnou podmnožinu kartézského součinu a popis operací mezi relacemi (množinami dat) jsou operacemi relační algebry. Pro zobrazení a konkrétnější představu o množině entit a vztahů mezi nimi velmi dobře slouží ER diagramy ( Entit – Relationship Diagram ) jejíž představitel je Peter Chen (1976).

Obr. 3: Příklad struktury relačního datového modelu Objektově orientovaný model Masivnější rozšíření tohoto modelu nastalo až počátkem devadesátých let, kde nebylo možné na relačních databázových systémech vhodně zpracovat složitější datové typy. Tento model vychází a je optimalizován pro potřebu objekového programování a jsou u něj známé vlastnosti zapouzdření, polymorfizmus, dědičnost. Vlastnost zapouzdření spojuje data a kód metod do jednoho celku objektu. Tohoto se využívá především k zabezpečení před neoprávněnými vnějšími zásahy. Polymorfizmus je vlastnost, která umožňuje, aby jediný název byl použit pro více rozdílných chování. Je tím zajištěna snadná rozšiřitelnost a modifikace s minimálním rizikem výskytu tvorby chyb. Dědičnost je proces při kterém je jeden objekt (podřízený) odvozený od jiného objektu (nadřazeného). Dědičností vzniká objekt s obecnými vlastnostmi, které se dále rozšiřují o specifické prvky pro nově vytvořený objekt.

Obr. 4: Objekt, třída objektu a instance třídy [1]

1 Úvod

Strana 17

Objektově relační model Současný vývoj je veden ve směru objektového programování a tento trend je patrný i v oblasti databazí. Objektově relační model rozšiřuje relační datový model o objektové prvky v podobě definování objektových typů dat. Záměrem je spojit výhody objektově orientovaného modelu a relačního modelu. Relační model rozšířený o prvky objektové využívají především tvůrci relačních enginů, které rozšířením o objektové prvky se snaží vyřešit potřebu a nároky vývojářů pracující v objektových programovacích jazycích a tím přizpůsobit relační databáze. Nedílným prvkem napomáhající k tomuto stavu a důvodu stálého využívání relačních databází oproti objektovým je opoždění vývoje standardu neboli normy oproti technologickému pokroku. Tento přehled není úplným přehledem dnes známých a popsaných databázových modelů. Vývoj k objektovým modelům byl značně bouřlivý a stále není u konce. Ukončení tohoto vývoje se nedá předpokládat. Je nutné stále rozšiřovat možnosti databázových úložišť pro potřebu rozvíjejících se informačních systémů a to v celé šíři informačních, komunikačních, průmyslových a jiných oblastí. V popsaných modelech se převážně setkáváme se strukturovanými daty. Vývoj databázových systémů směřuje hlavně do zpracování nestrukturovaných dat, které jsou pro lidstvo typické. Standardní aplikace se vytváří ve vícevrstvé architektuře. Základem je dvouvrstvá architektura klient / server, aplikační logika je převážně na straně klienta. To vede k hardwarové náročnosti na klientské stanici z důvodu potřeby velké výpočetní kapacity. Řešením je minimálné třívrstvá architektura, kde aplikační logika je převedena do aplikační vrstvy a tedy na výkonné servery. Dalšími výhodami je možnost využití služeb rozložení zátěže (load balancing) nebo služby při výpadku (fail over). Tato architektura přesouvá zvýšený datový přenos od klientů a datového serveru do spojení mezi aplikačním serverem a datovým serverem. Klientská vrstva

Aplikační vrstva

Datová vrstva

RDBMS

Klient Klient

Aplikační server OODBMS

Obr. 5: Architektura informačního systému

1 Úvod

Strana 18

Klientská vrstva – FRONT-END První vrstvou je tzv. klientská vrstva. Tato vrstva prezentuje data z informačního systému uživatelům a zároveň poskytuje přístup k jednotlivým službám. V informačních systémech se vyskytují dva druhy klientských aplikací. Prvním z nich jsou standardní windows aplikace(Win32). Tyto aplikace jsou vhodné pro požadavky komplexního a výkonného uživatelského rozhraní. Často se tyto aplikace označují tzv. tlustý klient, kde značná část aplikační logiky je právě na straně tohoto klienta. Druhým typem klientské aplikace je interface pro standardní HTML prohlížeč. Toto uživatelské rozhraní se využívá u aplikací na které nejsou kladeny velké nároky případně tam, kde je potřeba častých změn a úprav na tomto uživatelském rozhraní. Architektura takto koncipovaných systémů se navrhuje tak, aby umožňovala snadné přizpůsobení klientské vrstvy různým druhům klientských aplikací. Tato koncepce umožňuje podporu mobilních telefonů a jinných mobilních zařízení typu PDA. Tyto aplikace nazýváme tenkými klienty, což jsou klienti oproštěni o aplikační logiku, která je přesunuta na aplikační vrstvu tedy na aplikační servery, ke kterým tenký klient přistupuje. Aplikační vrstva - střední vrstva (middle tier, middleware) Druhou vrstvou je tzv. aplikační vrstva. Tato vrstva reprezentuje vlastní aplikační logiku celého informačního systému. Úkolem aplikační vrstvy je poskytování potřebných funkcí dle požadavků klientů z klientské vrstvy. Dalším využitím aplikační vrstvy je možnost komunikace s externími systémy za účelem výměny dat případně komunikace s ostatními uzly vlastního informačního systému. Velikost aplikační vrstvy vede k jejímu dalšímu dělení na tzv. subvrstvy. Každá z těchto subvrstev je zodpovědná za dílčí část aplikační vrstvy a tímto dělěním se zjednodušují a zpřehledňují definice aplikační vrstvy. Subvrstvy jsou definovány jako prezentační - UI/RPC (presentation), aplikační - Service (business) a datová - DAO (persistence). Vazby mezi jednotlivými subvrstvami jsou na úrovni rozhraní a umožňují snadnou změnu implementace. Oddělením vrstev získáváme výhodu v možnosti snazšího testování jednotlivých subvrstev a jejich přehlednost. Databázová vrstva - BACK-END Poslední vrstvou informačního systému je tzv. databázová vrstva. Na úrovni této vrstvy se řeší úkoly spojené s bezpečným poskytováním dat a jejich uchovávání. Součástí této vrstvy je také správa dat, udržování integrity, bezpečnost. Komunikace mezi vrstvami Vrstvy mezi sebou komunikují standardními internetovými komunikačními protokoly skupiny TCP/IP, případně vlastními protokoly a to z důvodu bezpečnosti. Komunikace probíhá jen mezi sousedními vrstvami.

1 Úvod

Strana 19

Z popisu třívrstvé architektury je zřejmé, že klient této architektury není ovlivněn datovým modelem úložiště. Změna v datové vrstvě ve formě Back-End aplikace se projeví v nižších subvrstvách aplikační vrstvy. Konkrétně změna datového modelu ovlivní datovou subvrstvu aplikační vrstvy. Klient a aplikační subvrstvy jsou převážně programovány za pomocí objektových jazyků (C#, C++, Java, aj.) a objektovými nástroji. Datová subvrstva při použití datového úložiště s relačním datovým modelem musí obsahovat trasformaci z relačně uložených dat a metadat do struktury objektových tříd. V případě objektového modelu je tato transformace nadbytečná. To se jeví v této architektuře jako časová a zátěžová úspora.

Strana 21

2 Popis prostředí pro řešení cílů Použitý Hardware Notebook IBM A31p CPU Paměť Disk

Intel Pentium 4 Mobile 1,8GHz 1,0 GB 1,2 GHz IDE Hitachi_HTS5412, 60GB, 5400RPM

Použitý Software Operační systém Databáze

Microsoft Windows XP Profesional SP2 Microsoft SQL server 2005 Caché 5.0.7

Popis množství dat v databázích Velikost souborů v MSSQL 2005 Datový Transakční Volné místo v souborech

1,46 GB (1 572 864 000 bytes) 1,46 GB (1 572 864 000 bytes) 183, 90 MB (6%)

Relační Databáze obsahuje záznamy v 11 tabulkách. Tabulka BR_BROADCAST BR_BROADCAST_PLAN BR_INTERVAL_PLAN BR_INTERVAL_PLAN_BR CL_CLIENT DC_DOCUMENT DC_DOCUMENT_ROWS PL_LIST PR_PRODUCT PR_TYPE_CODE SS_SUBJECT

Počet záznamů 1 789 245 3 547 996 3 402 442 4 585 158 48 791 82 533 179 799 1 372 99 133 249 10

Počet sloupců

Obsah

Index

19 12 19 11 27 62 40 13 24 8 4

185,891 MB 258,203 MB 456,070 MB 284,305 MB 6,234 MB 51,031 MB 45,406 MB 0,125 MB 12,945 MB 0,016 MB 0,008 MB

0,883 MB 1,180 MB 4,789 MB 3,797 MB 0,039 MB 0,250 MB 0,227 MB 0,016 MB 0,070 MB 0,016 MB 0,023 MB

Shodné množství dat, které je výše uvedeno, bylo převedeno do objektové databáze Caché.

2 Popis prostředí pro řešení cílů

Obr. 6: Diagram datového modelu testovaných dat

Strana 22


Strana 23

Počty výskytů shodných dat BR_BROADCAST_PLAN ni_position int c_price numeric nl_broadcast_id int nl_subject_id int nl_row_id int nd_discount numeric ni_source tinyint ni_free smallint nl_status_id int ni_order smallint nl_product_id int ts timestamp

BR_BROADCAST nd_discount ni_count nl_circuit_id nl_broadcasted_id ni_length nb_strict_order t_float_start nl_block_id nb_special nl_broadcast_id t_float_end t_broadcast nl_type_id nl_period_id ni_priority d_broadcast nl_subject_id s_name ts

numeric smallint int tinyint smallint tinyint char int tinyint int char char int int smallint int int varchar timestamp

25 16 876 336 508 10 36 557 1 2 17 2 16 21 823 4 359 372

4 19 13 3 98 2 6 9 224 2 457 828 5 668 14 89 8 2 749 9 159 1 789 245

BR_INTERVAL_PLAN_BR t_start char nl_circuit_id int nl_document_id int d_date int nl_subject_id int ni_order smallint ni_rotation_order int nl_row_id int nl_broadcast_id int t_end char ts timestamp

PR_PRODUCT ni_length ni_length_real nl_number_id s_name nl_client_id nl_statistics_id nl_subject_id s_tape s_file s_audiowault s_theme nb_completed nb_condition s_internal s_description nl_product_id nl_type_id d_copyright d_end nb_source_type ni_prefer d_start d_delivery ts

smallint smallint int varchar int int int varchar varchar varchar varchar tinyint tinyint varchar varchar int int int int tinyint smallint int int timestamp

234 12 31 629 2 626 9 17 49 36 486 348 228 286 4 585 158

110 158 4 85 124 8 705 193 10 2 563 51 451 13 698 13 843 2 2 66 226 42 22 201 73 1 697 1 3 11 1 1 862 99 133


Strana 24

Popis SQL serveru [14] SQL Server je všestranné, integrované a komplexní řešení pro data, které přispívá ke zvýšení výkonnosti uživatelů v celé organizaci poskytováním zabezpečenější, spolehlivější a produktivnější platformy pro podniková data a aplikace BI. SQL Server 2005 přináší specialistům IT i pracovníkům s informacemi výkonné známé nástroje, omezuje složitost vytváření, nasazování, správy a využívání podnikových dat a analytických aplikací na nejrůznějších platformách od mobilních zařízení po podnikové datové systémy. Prostřednictvím rozsáhlé sady funkcí, vzájemné funkční spolupráce se stávajícími systémy a automatizace rutinních úloh nabízí SQL Server 2005 organizacím všech velikostí úplné datové řešení.

Obr. 7: Rozložení datové platformy serveru SQL Server 2005

Popis Caché [13] CACHÉ® je inovativní objektová databáze, která zpracovává SQL 5x rychleji než relační databáze. Caché umožňuje rychlý rozvoj webových aplikací, mimořádnou rychlost zpracování transakcí, masivní šiřitelnost a dotazy na transakční údaje v reálném čase - s minimálními požadavky na administraci. Caché je k dispozici pro Unix, Linux, Windows, Mac OS X a OpenVMS. Caché je postrelační databázový systém spojující unikátním způsobem tři možnosti přístupu k údajům: • • •

SQL objektový přístup vícerozměrný přístup k datovým polím.


Strana 25

Všechny tři metody lze použít zároveň, i při současném přístupu k jedné položce. Žádné mapování, žádný middleware. Caché umožňuje vývoj webových aplikací, poskytuje mimořádnou rychlost transakčního zpracování, masivní rozšiřitelnost a transakční zpracování v reálném čase.

Obr. 8: Architektura Caché

Strana 27

3 Cíle bakalářské práce 3.1 Návrh srovnávacích testů výkonu relační a objektové databáze Test importu Popis testu: data vyexportovaná do textového souboru byla pomocí funkcí pro import naimportována do příslušných tabulek na každém databázovém serveru. Měření spočívalo v času potřebném pro naplnění tabulky všemi daty ze souboru. Výsledek testu je zapsán tabulkou a grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O. Výsledek sledování je vztažen na tabulku PR_PRODUKT a zobrazen grafem, který je součástí příloh.

Import Tabulka

Počet záznamů

objem dat v DB Caché

SQL 2005

BR_BROADCAST

1 789 245

185,891 MB

17min 58s

2min 47s

BR_BROADCAST_PLAN

3 547 996

258,203 MB

25min 2s

3min 16s

BR_INTERVAL_PLAN_BR

4 585 158

284,305 MB

34min 53s

3min 32s

99 133

12,945 MB

98s

12,5s

PR_PRODUCT

10000 Impo rt do SQL 20 0 5 Impo rt do Cac hé

čas importu (s)

1 000

1 00

10

1 BR_BROADCAST

BR_BROADCAST_PLAN

Obr. 9: Graf porovnání importů

BR_INTERVAL_PLAN_BR

PR_PRODUCT

3.1 Návrh srovnávacích testů výkonu relační a objektové databáze

Strana 28

Test exportu dat Popis testu: data byla pomocí funkcí pro export daného serveru vyexportována z příslušných tabulek do textového souboru. Měření spočívalo v čase potřebném pro naplnění souboru všemi daty z tabulky. Výsledek testu je zapsán tabulkou a grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O, výsledek sledování je vztažen na tabulku PR_PRODUKT a zobrazen grafem, který je součástí příloh.

Export Tabulka

Počet záznamů

objem dat v DB Caché

SQL 2005

BR_BROADCAST

1 789 245

185,891 MB

5min 57s

1min 3s

BR_BROADCAST_PLAN

3 547 996

258,203 MB

7min 34s

1min 34s

BR_INTERVAL_PLAN_BR

4 585 158

284,305 MB

23min 22s

2min 35s

99 133

12,945 MB

22,8s

7,1s

PR_PRODUCT

1 0000 Ex po rt z SQL 20 0 5 Ex po rt z Cac hé

čas exportu (s)

1 000

100

10

1 BR_BROADCAST

BR_BROADCAST_PLAN BR_INTERVAL_PLAN_BR

Obr. 10: Graf porovnání exportů

PR_PRODUCT


Strana 29

Test výkonnosti projekce Popis testu: nad jednotlivými tabulkami příslušných serverů se spouští níže uvedené příkazy SQL a je měřen čas práce serveru. Výsledek testu je zapsán tabulkou. Výsledné záznamy jsou zpracovány pro porovnání a zapsány do tabulky následně pak zobrazeny grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O. Výsledek sledování je vztažen na úkon nad tabulkou PR_PRODUKT a je zobrazen grafem, který je součástí příloh.

select * from select top <počet záznamů> * from

Výsledky měření na SQL 2005 Pořadové číslo měření 1

2

3

4

5

6

7

8

9

10

BR_BROADCAST (ms) 81 697,0

95 106,0

95 317,0

98 553,0

95 077,0

95 146,0

95 337,0

94 827,0

95 700,0

95 907,0

1 383,0

950,0

790,0

774,0

740,0

813,0

750,0

790,0

830,0

743,0

BR_BROADCAST_PLAN (ms) 145 480,0

123 177,0

133 980,0

125 353,0

115 813,0

113 977,0

123 527,0

132 560,0

135 546,0

156 024,0

1 244,0

1 093,0

790,0

830,0

810,0

823,0

800,0

794,0

860,0

820,0

BR_INTERVAL_PLAN_BR (ms) 149 123,0

143 437,0

135 787,0

136 976,0

160 190,0

160 620,0

152 007,0

140 423,0

142 003,0

143 727,0

1 263,0

1 020,0

900,0

914,0

930,0

883,0

920,0

900,0

833,0

940,0

PR_PRODUCT (ms) 4 907,0

4 866,0

4 867,0

5 037,0

4 836,0

4 807,0

5 030,0

5 027,0

4 776,0

4 867,0

1 104,0

830,0

733,0

740,0

760,0

740,0

773,0

770,0

774,0

780,0

Výsledky měření na Caché Pořadové číslo měření 1

2

3

4

5

6

7

8

9

10

7 043,77

7 197,03

7 274,87

7 164,07

7 282,74

7 179,00

7 119,19

7 785,86

7 911,47

7 925,54

7 958,18

7 832,51

7 900,48

7 866,97

BR_BROADCAST (ms) 6 924,29

7 228,17

7 133,96


7 896,33

8 033,05

BR_INTERVAL_PLAN_BR (ms) 9 556,03

9 332,68

9 036,11

9 194,83

9 242,14

9 223,45

9 148,30

9 223,01

9 123,89

9 191,56

6 160,30

6 188,42

6 194,51

6 376,21

6 573,24

6 171,00

6 194,19

6 002,00

PR_PRODUCT (ms) 6 527,21

6 416,38


Strana 30

Vyhodnocení výsledků měření Počet vrácených záznamů

Tabulka BR_BROADCAST BR_BROADCAST_PLAN BR_INTERVAL_PLAN_BR PR_PRODUCT

x (ms) SQL 2005

1 789 245

94266,7

17 499

856,3

3 547 996

130543,7

26 922

886,4

4 585 158

146429,3

29 165

950,3

99 133

4902

13 999

800,4

s (ms) Caché

SQL 2005 0,05269

7 154,7104

0,00048

7 933,9306

0,00025

9227,2016

0,00021

6280,3472

0,00807

s (m s) Cac hé

čas (ms)

0 ,1 0 0 0 0

0 ,0 1 0 0 0

0 ,0 0 1 0 0

0 ,0 0 0 1 0

Obr. 11: Graf porovnávaných výsledků

0,31638

0,04945

s (m s) SQL 20 0 5

BR_BROADCAST _P LAN

0,29470

0,03194

s (m s) SQL 20 0 5

BR_BROADCAST

0,40886

0,03679

x – aritmetický průměr z naměřených výsledků s – čas na pořízení jednoho vráceného záznamu

1 ,0 0 0 0 0

Caché

BR_INT ERVAL_P LAN_BR

P R_P RODUCT

0,44863


Strana 31

Test výkonu projekce s agregační funkcí

Popis testu: nad jednotlivými tabulkami příslušných serverů se spouští níže uvedený příkaz SQL a je měřen čas práce serveru. Výsledek testu je zapsán tabulkou. Výsledné záznamy jsou zpracovány pro možné porovnání, zapsány do tabulky a zobrazeny grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O. Výsledek sledování je vztažen na tabulku PR_PRODUKT a zobrazen grafem, který je součástí příloh. select count(*) from


2

3

4

5

6

7

8

9

10

BR_BROADCAST (ms) 583

520

530

530

530

573

550

620

580

564

940

934

940

950

943

970

1 003

1 303

1 240

1 264

1 240

1 263

1 240

1 283

1 230

40

40

30

20

30

30

30

30

BR_BROADCAST_PLAN (ms) 1 060

930

963

BR_INTERVAL_PLAN_BR (ms) 1 413

1 310

PR_PRODUCT (ms) 40

40


2

3

4

5

6

7

8

9

10

BR_BROADCAST (ms) 18 956,75 18 485,26 15 843,06 16 566,32 15 988,85 16 665,40

16 789,51 16 787,65

15 721,44 17 593,18


33 231,91 32 688,06 32 448,37 32 459,90 32 920,38 33 043,25 32 337,92 33 387,27 31 550,07

BR_INTERVAL_PLAN_BR (ms) 365 078

366 420

335 339

345 139

349 938

354 040

344 293

353 515

327 039

326 339

616,88

583,28

628,43

600,92

591,20

566,56

636,41

570,22

PR_PRODUCT (ms) 565,25

649,58

Vyhodnocení výsledků měření Tabulka

Počet vrácených záznamů

x (ms) SQL 2005

s (ms) Caché

SQL 2005

Caché

BR_BROADCAST

1 789 245

558,00

16939,74

0,000312

30,357

BR_BROADCAST_PLAN

3 547 996

963,30

32598,27

0,000272

33,840

BR_INTERVAL_PLAN_BR

4 585 158

1278,60

346714,40

0,000279

271,167

99 133

33,00

600,87

0,000333

18,208

PR_PRODUCT

x – aritmetický průměr z naměřených výsledků s – čas na pořízení jednoho vráceného záznamu


Strana 32

0 ,1 0 0 0 0 0 s (ms) SQL 20 0 5 s (ms) Cac hé

čas (ms)

0 ,0 1 0 0 0 0

0 ,0 0 1 0 0 0

0 ,0 0 0 1 0 0 BR_BROADCAST

BR_BROADCAST _P LAN BR_INT ERVAL_P LAN_BR

P R_P RODUCT


Test výkonnosti při aktualizaci údajů Popis testu: nad jednotlivými tabulkami příslušných serverů se spouští níže uvedený příkaz SQL a je měřen čas práce serveru. Výsledek testu je zapsán tabulkou. Výsledné záznamy jsou zpracovány pro možné porovnání tabulkou a zobrazeny grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O. Výsledek sledování je vztažen na tabulku PR_PRODUKT a zobrazen grafem, který je součástí příloh. update set nl_subject_id = nl_subject_id


2

3

4

5

6

7

8

9

10

21,48

13,81

15,45

13,10

13,22

22,07

21,41

352,75 373,35 249,09 BR_INTERVAL_PLAN_BR (s)

281,23

325,15

224,25

250,35

261,00

371,81

378,17

590,30 584,70 PR_PRODUCT (s)

615,20

587,50

598,36

583,95

589,81

595,73

598,83

592,48

7,62

8,41

8,11

8,24

9,33

8,76

9,91

8,75

BR_BROADCAST (s) 35,49 13,75 22,42 BR_BROADCAST_PLAN (s)

8,44

8,78


Strana 33


2

3

4

5

6

7

8

9

10

BR_BROADCAST (s) 243,00

242,00

254,00

239,00

244,00

247,00

252,00

254,00

250,00

246,00

506,00

459,00

503,00

441,00

469,00

473,00

491,00

1 103,00

1 079,00

1 042,00

1 069,00

1 058,00

1 027,00

1 093,00

1 049,00

15,00

15,00

16,00

17,00

15,00

15,00

16,00

16,00

BR_BROADCAST_PLAN (s) 516,00

438,00

483,00

BR_INTERVAL_PLAN_BR (s) 1 061,00

1 035,00

PR_PRODUCT (s) 15,00

16,00


Tabulka

x (s) SQL 2005

s (s) Caché

SQL 2005

Caché

BR_BROADCAST

1 789 245

19,22

247,100

0,000011

0,000138

BR_BROADCAST_PLAN

3 547 996

306,72

477,900

0,000086

0,000135

BR_INTERVAL_PLAN_BR

4 585 158

593,69

1061,600

0,000129

0,000232

99 133

8,64

15,600

0,000087

0,000157

PR_PRODUCT

0 ,0 0 0 25 0 s (s) SQL 20 0 5 s (s) Cac hé 0 ,0 0 0 20 0

čas (s)

0 ,0 0 0 1 5 0

0 ,0 0 0 1 0 0

0 ,0 0 0 0 5 0

0 ,0 0 0 0 0 0 BR_BROADCAST

BR_BROADCAST _P LAN BR_INT ERVAL_P LAN_BR


P R_P RODUCT


Strana 34

Test výkonnosti projekce s selekcí nad více tabulkami Popis testu: na příslušných serverech se spouští níže uvedené příkazy SQL a je měřen čas práce serveru. Pro porovnání byla vytvořena v Caché třída, srovnatelná strukturou se strukturou sloučených tabulek, kde na této třídě byl, pomocí OQL, zpracován požadavek podmínek. Výsledek testu je zapsán tabulkou. Výsledné záznamy jsou zpracovány pro možné porovnání tabulkou a zobrazeny grafem. Dále bylo sledováno, pomocí performance, využití CPU, paměti a I/O, které jsou zobrazeny grafem, který je součástí příloh. Projekce 1: select a.*, b.*, c.*, d.* from PR_PRODUCT as a inner join BR_BROADCAST_PLAN as b ON a.nl_subject_id = b.nl_subject_id and a.nl_product_id = b.nl_product_id and (CAST(a.nl_product_id AS varchar(8)) LIKE '%129') inner join BR_INTERVAL_PLAN_BR as c ON a.nl_subject_id = c.nl_subject_id and b.nl_broadcast_id = c.nl_broadcast_id and b.ni_order = c.ni_order inner join BR_BROADCAST as D ON a.nl_subject_id = d.nl_subject_id and b.nl_broadcast_id = d.nl_broadcast_id

Projekce 2: select a.*, b.*, c.* from BR_INTERVAL_PLAN_BR as a inner join BR_BROADCAST as b ON a.nl_broadcast_id = b.nl_broadcast_id and a.nl_subject_id= b.nl_subject_id and a.nl_document_id = 22706 left join BR_BROADCAST_PLAN as C ON a.nl_broadcast_id = c.nl_broadcast_id and a.nl_subject_id= c.nl_subject_id inner join PR_PRODUCT as d ON a.nl_subject_id= d.nl_subject_id and c.nl_product_id = d.nl_product_id

Výsledky měření na SQL 2005 Pořadové číslo měření 1 2 Projekce 1 (s) 128,52 136,31 Projekce 2 (s) 16,38

19,30

3

4

5

6

7

8

9

10

122,92

120,00

134,82

121,16

123,47

127,06

124,87

127,36

18,13

18,38

13,45

11,62

16,20

14,93

12,90

11,34


Strana 35


2

3

4

5

6

7

8

9

10

Projekce 1 (s) 630,11

632,50

645,63

625,44

631,65

638,43

640,14

627,24

628,62

629,64

81,15

80,21

85,05

78,21

78,81

80,01

80,98

84,31

81,66

186,128

183,96

185,97

184,43

192,50

187,86

183,28

188,24

189,63

73,82

75,38

74,98

78,13

76,93

77,93

73,98

72,34

Caché třída (s) 82,15 Projekce 2 (s) 185,50

Caché třída (s) 74,45

79,60


x (s) SQL 2005

Caché SQL

s (s) Caché Třída

SQL 2005

Caché SQL

Caché Třída

Projekce 1

2 702

126,65

632,939

81,253

0,04687

0,23425

0,03007

Projekce 2

1 032

15,26

168,137

75,754

0,01479

0,16292

0,07341

0 ,25 0 0 0 s (s) SQL 20 0 5 s (s) Cac hé SQL

čas (s)

0 ,20 0 0 0

s (s) Cac hé Třída

0 ,1 5 0 0 0

0 ,1 0 0 0 0

0 ,0 5 0 0 0

0 ,0 0 0 0 0 Projekce 1


Projekce 2

Strana 37

3.2 Proveďte rozbor srovnání výhod a nevýhod relační a objektově orientované databáze OODBMS Výhody - vhodně vystihuje složité vztahy mezi daty [7] - flexibilní manipulace s daty[7] - hiearchická struktura dat [19] - automatická jednoznačná identifikace objektu Nevýhody - prostředky pro selekci pod průměrem RDBMS[7] - složitost modelu - kvalita uživatelského rozhraní - malá praktická znalost back-end aplikací ze strany tvůrců sw [20] - chybějící uznávané standardy a jejich akceptace při tvorbě back-end aplikací [20] RDBMS - ORDBMS Výhody - vhodné pro velké množství rel.jednoduchých dat [7] - dobré prostředky pro selekci[7] - standardizovaný SQL jazyk [19] - rozšířenost , bohatá základna kvalitních BackEnd i FrontEnd aplikací [19] - matematickým model, nevhodný pro obecný popis objektů reálného světa Nevýhody - komplikovaná manipulace s daty [7] - nesoulad mezi programovacími jazyky a databází [19] - propojení více tabulek JOIN, použití klauzule ORDER By, použití negativních operátorů NOT BETWEEN, NOT IN, IS NOT NULL a LIKE zvyšuje zatížení serveru => klesající výkonost [2] - chybí přímá podpora objektových jazyků

Relační struktura databáze je výrazně odlišná od objektové struktury aplikací, proto je třeba podnikat celou řadu mezikroků podporujících spolupráci relačních databází s objektově orientovanými aplikacemi. Je jasné, že tyto mezikroky nejen dělají aplikaci složitější, ale také snižují výkonnost a zvyšují riziko výskytu chyb. Se vzrůstající složitostí aplikace se prodlužuje také délka vývoje a testování a rostou s tím spojené náklady. [18, 7]

3.2 Proveďte rozbor srovnání výhod a nevýhod databází

Strana 38

Databázové modely, relační a objektový, jsou každý navržen pro jiné datové struktury. Relační respektive objektově relační je navržen pro velké množství jednoduchých dat a objektový model je navržen pro složité vazby mezi objekty. Jednotlivé výhody i nevýhody korespondují s těmito koncepcemi. Rozdíly lze srovnávat u propracovanosti uživatelských rozhraní a nástrojů ve kterých má relační Back-End aplikace díky svému dlouhodobému používání nesporný náskok. Rozdílnost modelů je znatelná v celém procesním cyklu návrhu datového modelu aplikace. Příkladem je unikatní identifikace, v relačním modelu zabezpečená pomocí primárního klíče a u objektového modelu ji zabezpečuje objektová identita. Nezávislost objektové identity je na místě(bereme z hlediska umístění v diskovém prostoru), změně struktury i změně hodnot objektu. Takové možnosti primární klíč u relačního modelu nenabízí. Porovnáváme-li začlenění zásad pro objektové programování je podpora ze strany objektově relačního modelu omezena na ADP Abstraktní Datové Prvky. Objektové databáze plně podporují polymorfismu, dědičnosti a zapouzdření. Objektově orientovaný přístup dovoluje udělat zásadní rozhodnutí brzy na začátku projektu a odložit nepodstatná rozhodnutí (nebo ta, pro něž nemáme dostatečné informace) na poždější dobu [26]. Dále je v příspěvku uvedeno, že objektový přístup přináší zkrácení doby vývoje aplikací, smížení nákladů na jejich vývoj a zjednodušení i zrychlení údržby, ať již z hlediska oprav nebo z hlediska nutných dadatečných změn a doplňků.

Porovnání standardů DBMS [21] SQL-92 JDBC

SQLJ

SQL:1999

ODMG 3.0

JDO

Parts 0 1: relational model

SQL:1999 object model

Java, C++, and Smalltalk object models enhanced for transparent persistence

Java object model enhanced for transparent persistence

Model relational model

relational model

Part 2: SQL:1999 object model

The model with the transparent persistence enhancements is a superset of the OMG Common Object Model

Data Definition Language SQL

SQL

SQL

SQL

Object Definition Language (ODL) which is a superset of the OMG Interface Definition Language (IDL)

Java & XML


Strana 39

Query Language Embedded SQL, Dynamic SQL, and Call-level interface

Call-level interface for SQL

Embedded SQL

Embedded SQL, Dynamic SQL, and Call-level interface

Object Query JDO Query Language (OQL) Language which is based on (JDOQL) SQL-92

Embedded SQL and Java

Embedded SQL, Dynamic SQL, and Call-level interface

Java, C++, or Smalltalk

Data Manipulation Language Embedded SQL, Dynamic SQL, and Call-level interface

Call-level interface for SQL and Java

Java

Srovnání databázových systémů [16] Kritérium

RDBMS

ORDBMS

ODBMS

Definovaný standard

SQL2 (ANSI X3H2)

SQL3/4 (in process)

ODMG-V2.0

Podpora pro objektově orientované programování

Špatná; programátoři stráví 25% času kódování mapováním objektového programu do databáze

Omezená hlavně na nové datové typy

Přímá a rozsáhlá

Jednoduchost používání

Strukturám tabulky je jednoduché Totéž co RDBMS porozumět; mnoho s rozšířením ADP dostupných nástrojů pro koncové uživatele

OK pro programátory; SQL přístup

Jednoduchost vývoje

Poskytuje Poskytuje nezávislost dat z nezávislost dat z aplikace, dobrá aplikace, dobrá pro pro jednoduché jednoduché vztahy vztahy

Objekty jsou přirozenou cestou k modelu; může vyhovět širokým rozsahem typů a vztahů

Rozšiřitelnost a obsah

Žádná

Omezená hlavně na nové datové typy

Může pracovat s libovolnou složitostí; uživatelé mohou psát metody a jakékoliv struktury


Strana 40

Může pracovat s libovolnou složitostí; Složité datové vztahy Pro model obtížné Pro model obtížné uživatelé mohou psát metody a jakékoliv struktury Úroveň bezpečnosti se mění s dodavatelem, je Výkon versus spolupracovatelnost třeba vzájemně porovnat; dosáhnutí vyžaduje rozsáhlé testování

Úroveň bezpečnosti se mění s dodavatelem, je třeba vzájemně porovnat; dosáhnutí vyžaduje rozsáhlé testování

Úroveň bezpečnosti se mění s dodavatelem; vetšina ODBMSs dovoluje programátorům rozšířit funkčnost DBMS definováním nových tříd

Distribuce, replikace Rozsáhlá a spojené databáze

Rozsáhlá

Podle dodavatele; pár jich poskytuje rozsáhlou podporu

Vyspělost produktu

Velmi vyspělé

Nezralé; rozšíření jsou nová, stále se definují a jsou Relativně vyspělé relativně neprozkoušená

Podpora pro lidi a univerzálnost SQL

Široká podpora nástrojů a trénovaných vývojářů

Vybaveno SQL, ale Může využívat určeno pro objektově výhod nástrojů orientované RDBMS a vývojářů programování.

Softwarové ekosystémy

Poskytováno hlavními RDBMS společnostmi

Poskytováno hlavními RDBMS společnostmi

ODBMS výrobci začínají emulovat RDBMS výrobce, ale žádný nenabízí velký obchod jiným ISV

Životaschopnost výrobce

Očekávaná pro hlavní zaběhnuté RDBMS výrobce

Očekávaná pro hlavní RDBMS výrobce; UniSQL bojuje

Menší než se čekalo; stále se očekává snižování

Zdroj: International Data Corporation, 1997

Strana 41

3.3 Doporučte vhodnou objektovou databázi, nahrazující relační databázi Jak tomu bývá u rychle se rozvíjejících oborů, ke kterým informační technologie a vývoj software zajisté patří, je nabídka velmi rozsáhlá. Každý tvůrce datového úložiště a to díky prvotní nestandardizaci, používá jiná řešení, nástrojů, metod. Z nabídky, která je obsáhlá, se nabízejí tyto subjekty a produkty[11]: db4objects, Inc. (db4o - database for objects - open source) GemStone Systems, Inc. (GemStone/S and GemStone Facets) GLinkNET Technology (Link.NET) InterSystems Corporation (Caché) Jade Software Corporation (JADE) JDOInstruments Project (JDOInstruments - open source) JYD Software Engineering Pty Ltd. (JYD Object Database) Logic Arts, Ltd. (VOSS) Matisse Software, Inc. (Matisse) Micro Data Base Systems, Inc. (TITANIUM) Moscow State University (GOODS - open source) ObjectDB Software (ObjectDB for Java/JDO) Objectivity, Inc. (Objectivity/DB) Orient Technologies (Orient Enterprise Edition and Orient Just Edition) The Ozone Database Project (ozone - open source) Prevayler Project (Prevayler - open source) Progress Software Corporation (ObjectStore Enterprise and PSE Pro) run Software-Werkstatt GmbH (ODABA) Sysra (EyeDB) Versant Corporation (Versant Developer Suite and FastObjects) Pro vypracování tohoto cíle je nutné podrobně znát na teoretické a praktické úrovni doporučovaný Object Oriented Databaze Menagment Systems OODBMS, dále pak se předpokládá znalost aplikace, která má být na tento OODBMS převáděna, seznámit se s metodami transformace a nedílnou podmínkou je znalost jednotlivých standardů. Při rozhodovacím procesu o výběru Back-End aplikace navrhuji zaměřit se u jednotlivých nabídek na následující kritéria: podporované platformy a podporované programovací jazyky, licenční politiku, podporu standardů, cenové srovnání, přehled vývoje a jeho aktuální stav, zázemí firmy, působení na místním trhu včetně podpůrných činností – školení, certifikace, propagace. Domnívám se, že podle vlastních zkušeností i podle rozšiřujícího se uplatnění v praxi, jak ze strany stěžejních informačních firem například IBM[22], tak i u subjektů z jiných odvětvích, lze datové úložiště Caché doporučit jako vhodný nástroj pro realizaci objektového databázového systému pro podporu informačního systému.

Strana 43

4 Závěr Při řešení návrhu srovnávacích testů výkonu vybrané relační a objektové databáze byla data relačního modelu MSSQL serveru 2005 převedena ve stejné struktuře do prostředí objektového datového modelu v Caché. Pro převod relačních dat do objektového prostředí nebylo možné využít nástrojů Caché Data migration pro nedostatečnou kompatibilitu převáděných dat. Převod jsem provedl vyexportováním dat z SQL serveru do textového souboru. V Caché Studiu jsem vytvořil odpovídající třídy a pomocí Caché SQL Import wizard jsem vytvořil příslušné instance třídy a to importem dat z textového souboru. Následně byly spouštěny příkazy dotazovacích jazyků uváděné v bodu 3.1 této práce, které byly vyhodnoceny a vzájemně porovnány. Měření bylo prováděno na shodném hardware na každém datovém úložišti samostatně tak, aby výkon jednoho úložiště neovlivňoval výkon druhého úložiště. Pro účely posledního testu „Test výkonnosti projekce se selekcí nad více tabulkami “ byla vytvořena samostatná třída za pomocí dědičnosti ze tříd obsahující instance jednotlivých tabulek z relačního modelu. V zápisu výsledků měření uvedeno pod názvem „Caché třída“. Pro vyhodnocení výsledků testů jsem použil výpočet hodnoty „x“ – aritmetický průměr z naměřených výsledků a „s“ – čas na pořízení jednoho vráceného záznamu. Pro názornější porovnání byl čas na pořízení jednoho vráceného záznamu jednotlivých datových úložišť zobrazen v grafu hodnot. Pro náhled na zátěž hardware byly sledovány průběhy využití procesoru, paměti a I/O stránky pro každý příkaz nad daným datovým úložištěm. Příklady jsou součástí přílohy. Jednotlivé testy ukázaly převahu výkonu v uvedených příkladech u MSSQL serveru 2005, poslední test tak jednoznačný není. Ukazuje poměr výkonu přístupem k objektům databáze prostřednictvím OQL a za pomocí třídy. Zde jednoznačně byl výkonově výhodnější přístup za pomocí třídy. U tohoto příkladu bylo použito složitějších vazeb mezi daty, které u MSSQL 2005 a obecně u relačních databází se vystihuje spojováním tabulek a to přináší určité výkonnostní problémy. Cahé nebo objektově orientovaná datová úložiště jsou v těchto případech výhodnější, pracují-li s jednou pro tento účel vytvořenou třídou. Pracujeme-li s třídami shodně jako s tabulkami v relačním modelu je výkon výrazně horší. Pro získání výsledků práce byly použity nástroje dodávané výrobci. U MSSQL serveru 2005 je to SQL server manager studio, u Caché SQL manager. Klienti jsou omezeni pro zobrazování záznamů, byli nastaveni tak, aby bylo možné získat co největší počet záznamů z úložiště. V rozdílnosti klientů spatřuji určitý nesoulad mezi výsledky. Přístup k datům v Caché bylo prostřednictvím jazyka OQL. Pro detailnější srovnání by bylo vhodné použít funkční aplikaci vytvořenou pro relační úložiště a tuto transformovat do objektového prostředí. Aplikace v reálné praxi nemusí přistupovat k datům a využívat jazyka OQL, vhodnější přístup z hlediska rychlosti k poskytovaným datům je přístup přímo k objektům – datovým třídám a ty používat pro potřeby klientské aplikace. Tímto postupem by se dosáhlo přesného srovnání vhodnosti úložiště s relačním nebo objektovým datovým modelem pro danou datovou strukturu a datové vazby z ní vycházející.

4 Závěr

Strana 44

Zpracováním druhého cíle „proveďte rozbor srovnání výhod a nevýhod relační a objektově orientované databáze“ byly představeny výhody a nevýhody databázových systémů, standardů a srovnání datových modelů. Oba datové modely OODM i ORDM jsou rozdílné a u protikladných vlastností dochází k tomu, že výhoda jednoho modelu je nevýhodou modelu druhého a naopak. V celé šíři srovnávání jsou v „různých pádech skloňovány“ požadavky na ten který datový model. Relační datový model byl navržen pro zpracování velkého množství relativně jednoduchých dat. Objektový model byl vyvíjen pro data složité struktury. Pro vypracování třetího cíle této práce jsou uvedeny oblasti, které se zdají být rozhodující při výběru dodavatele datového úložiště. V dnešní době hlavně díky Internetu nejsou definovány hranice nebo jiná omezení při výběru software. Je nutné zohlednit podružné náklady a potřeby spojené s provozem a vývojem aplikací pro pořízené datové úložiště. Prací bylo provedeno orientační srovnání dvou vybraných databází. Pro podrobnější a průkaznější srovnání by bylo potřeba testovat více databází a provést větší počet složitějších testů. Větší počet databází by bylo potřeba zejména v oblasti objektově orientovaných databází, ve kterých se objevují dosti velké rozdíly. V oblasti relačních databází jsou funkce a programová řešení srovnatelná.

Strana 45

Literatura:

[1]

Wolfgang Kirsten, Michal Ihringer, Mathias Kühn, Bernhard Rőhrig, Caché databáze postrelačního typu a tvorba aplikací, CP Books, Brno 2005

[2] Microsoft Coporation, Microsoft SQL Server 7, Training Kit, Database Implementation, Computer Press, Praha 1999 [3] Oppel Andrew, Databáze bez předchozích znalostí, Computer Press, Brno 2006 [4] Kocan Marek, článek Databáze dneška, Reseller Magazine IT, číslo 12, ročník IV, vyšlo 29.listopadu 2006 [5]

Edlich Comparing the Object and the Relational Data Model. June 2006. [cit. 16. březena 2007]. Dostupné z: http://www.odbms.org/download/ 002.02%20Edlich%20Comparing%20the%20Object%20and%20the %20Relational%20Data%20Model%20June%202006.PDF

[6]

Pieter van Zyl, Derrick G. Kourie, Andrew Boake. Comparing the Performance of Object Databases and ORM Tools. September 2006. [cit. 16. března 2007]. Dostupné z: http://www.odbms.org/download/027.01%20Zyl%20Comparing %20the%20Performance%20of%20Object%20Databases%20and%20ORM% 20Tools%20September%202006.PDF

[7]

Matula P. OODBMS systém POET, struktura, možnosti a způsob využití. CIT Ostravká Univerzita. [cit. 10. dubena 2007]. Dostupné z: http://honor.fi.muni.cz/tsw/1999/147.pdf

[8]

Fromek Daniel, Novotný Miroslav. Object query linguage. MFF UK 2005. [cit. 10. dubna 2007]. Dostupné z: http://www.ksi.mff.cuni.cz/~pokorny/dj/prezentace/2_52.pdf

[9]

Návrat Lumír. Klientská část objektově orientovaného databázového systému. 63 stran. Ostrava. 2002. Diplomová práce na Katedře informatiky fakulty elektrotechniky a informatiky VŠB - Technické univerzity v Ostravě. Vedoucí diplomové práce doc. Ing. Miroslav Beneš, Ph.D. [cit. 16. března 2007]. Dostupné z: www.cs.vsb.cz/navrat/files/textDipl.pdf

Literatura

Strana 46

[10]

Merunka Vojtěch. Normalizace v objektových databázích. Katedra informačního inženýrství. PEF. ČZU Praha 2004. [cit. 15. dubna 2007]. Dostupné z: http://kii.pef.czu.cz/~merunka/documents/publications/Objekty_2004_Pra ha.pdf

[11]

Barry & Associates, Inc. Object-oriented database product vendors. [cit. 1. května 2007]. Dostupné z: http://www.servicearchitecture.com/products/object-oriented_databases.html

[13]

Co je Caché? [cit. 21. dubna 2007]. Dostupné z: http://www.intersystems.cz/cache/index.html

[14]

Přehled produktu SQL Server 2005. Publikováno 7.11.2005. [cit. 21. dubna 2007]. Dostupné z: http://www.microsoft.com/cze/windowsserversystem/sql/prodinfo/overview /default.mspx

[15]

Lenka Novotná & Lada Oberreiterová. Síťový a hiearchycký databázový model [cit. 6. května 2007]. Dostupné z: www.ksi.mff.cuni.cz/~pokorny/dj/prezentace/2_44.ppt

[16]

Batko Michal. Relační vs. relačně objektové vs. objektové databáze. [cit. 6. února 2007]. Dostupné z: http://www.fi.muni.cz/~xbatko/oracle/compare.html

[17]

Pichlík. Třívrstvá architektura v kostce. Publikováno 11. listopadu .2004. [cit. 11. dubna 2007]. Dostupné z: http://www.sweb.cz/pichlik/archive/2004_11_07_archive.html#1100128179 26264151

[18]

Procházka Jaroslav. Objektově orientované databáze. Publikováno 3. března 2004. [cit. 10. března 2007]. Dostupné z: http://www.dbsvet.cz/view.php?cisloclanku=2004030301

[19]

Holub Vít. Transformace relačního datového modelu na objektový. [cit. 15. dubna 2007]. Dostupné z: http://www.agris.cz/etc/textforwarder.php?iType=2&iId=137542& PHPSESSID=71

Literatura

Strana 47

[20] Merunka Vojtěch. Objektový přístup k databázové technologii. Katedra informačního inženýrství. PEF. ČZU Praha 2004. [cit. 15. dubna 2007]. Dostupné z: http://kii.pef.czu.cz/~merunka/documents/publications /TSW_2004_Ostrava.pdf

[21]

Barry & Associates, Inc. Summary comparison of DBMS standards [cit. 15. dubna 2007]. Dostupné z: www.servicearchitecture.com/database/articles/comparison_of_dbms_standards.html

[22]

Howard Philip. Competitive case studies. Director of Research - Technology, Bloor Research. Publikováno: 16. ledna 2007. [cit.15. března 2007]. Dostupné z: www.it-director.com/technology/applications/ content.php?cid=9088

[23]

Straka M. Vývoj databázových aplikací. Grada 1992 Praha

[24]

Michael J.- Hernandez J. N8vrh databází. Grada Publishing 2005 Praha

[25]

Smejkal T. SQL Server 2005. Grada Publishing 2006 Praha

[26]

Doc.Ing.Branislav Lacko CSc. Komparativní analýza strukturovaného a objektově orientovaného přístupu. Sborník konference Objekty ´96. Praha 30.-31. října 1996. Česká zemědělská univerzita Praha a ITC PragoData

Strana 49

Seznam příloh Grafy zátěže při testu importu Grafy zátěže při testu exportu dat Grafy zátěže při test výkonnosti projekce Grafy zátěže při test výkonu projekce s agregační funkcí Grafy zátěže při test výkonnosti při aktualizaci údajů Grafy zátěže při test výkonnosti projekce s selekcí nad více tabulkami

Strana 51

Přílohy Grafy zátěže při testu importu

Import PR_PRODUCT do Caché, maxima CPU 96%, 1,8 MB Memory, I/O 0,9/0 KB

Import PR_PRODUCT do SQL 2005, maxima CPU 73%, 120 MB Memory, I/O 2,9/1,5MB

Přílohy Grafy zátěže při testu exportu dat

Export tabulky PR_PRODUCT z Caché, maxima CPU 98%, 1,8MB Memory, I/O 7,7MB; 250KB

Export tabulky PR_PRODUCT z SQL 2005, maxima CPU 86%, 98MB Memory, I/O write 7,4MB; 5,9MB

Strana 52

Přílohy Grafy zátěže při testu výkonnosti projekce

Monitoring průběhu projekce nad tabulkou PR_Produkt z Caché, maxima CPU 14%, 1,7MB Memory, I/O 305,2/2,1KB

Monitoring průběhu projekce nad tabulkou PR_Produkt z SQL 2005, maxima CPU 81%, 64MB Memory, I/O 21,4/1,3MB

Strana 53

Přílohy

Strana 54

Grafy zátěže při testu výkonu projekce s agregační funkcí

Monitoring při průběhu projekce s agregací nad tabulkou PR_Produkt v Caché, maxima CPU 32%, 1,7MB Memory, I/O 6,2MB / 330 B

Monitoring průběhu projekce s agregací nad tabulkou PR_Produkt v SQL 2005, maxima CPU 21,2%, 62,2MB Memory, I/O 0 B

Přílohy

Strana 55

Grafy zátěže při testu výkonnosti při aktualizaci údajů

Monitoring při průběhu projekce s agregací nad tabulkou PR_Produkt v Caché, maxima CPU 98%, 1,7MB Memory , I/O 709 / 408 B

Monitoring při průběhu projekce s agregací nad tabulkou PR_Produkt v SQL 2005, maxima CPU 22%, 63,7MB Memory , I/O 1,3MB / 808 KB

Přílohy

Strana 56

Grafy zátěže při testu výkonnosti projekce s selekcí nad více tabulkami

Monitoring při průběhu projekce1 v Caché, maxima CPU 59,5%, 1,9 MB Memory , I/O 12,6MB / 39KB

Monitoring při průběhu projekce1 v SQL 2005, maxima CPU 97%, 95MB Memory , I/O 22,8MB / 228 KB

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

Recommend Documents