Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií
Student
: Tomáš Petřík
Vedoucí bakalářské práce
: ing. Dušan Chlapek
Recenzent bakalářské práce
: ing. Drahomír Chocholatý, MBA
TÉMA BAKALÁŘSKÉ PRÁCE
Volba databázového systému na základě požadavků projektu IS/ICT
ROK: 2008
Prohlášení
Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze kterých jsem čerpal.
V Praze dne 24.6.2008
................................ .......................... podpis
3
Obsah 1. Úvod .......................................................................................................... 6 2. Základní pojmy ....................................................................................... 7 3. Přehled vybraných databázových systémů ........................................... 9 3.1 Oracle Database 11g ................................................................................................ 9 3.1.1 Základní popis............................................................................................................... 9 3.1.2 Systémové požadavky................................................................................................... 9 3.1.3 Další funkce .................................................................................................................. 9 3.1.4 Výhody a nevýhody .................................................................................................... 11 3.1.5 Licence ........................................................................................................................ 11
3.2 Microsoft SQL Server 2005 .................................................................................. 12 3.2.1 Základní popis............................................................................................................. 12 3.2.2 Systémové požadavky................................................................................................. 12 3.2.3 Další funkce ................................................................................................................ 12 3.2.4 Výhody a nevýhody .................................................................................................... 13 3.2.5 Licence ........................................................................................................................ 13
3.3 MySQL Server 5.0................................................................................................. 14 3.3.1 Základní popis............................................................................................................. 14 3.3.2 Systémové požadavky................................................................................................. 14 3.3.3 Další funkce ................................................................................................................ 14 3.3.4 Výhody, nevýhody ...................................................................................................... 15 3.3.5 Licence ........................................................................................................................ 16
4. Srovnání výkonnosti vybraných databázových systémů ................... 17 4.1 Způsob výběru testu výkonnosti ............................................................................ 17 4.2 Model testu TPC-C ................................................................................................ 17 4.3 Testování ............................................................................................................... 18
5. Problémy migrace mezi vybranými databázovými systémy ............. 20 5.1 Datové typy ........................................................................................................... 20 5.2 Manipulace s daty (DML - Data Manipulation Language) ................................... 21 5.3 Definice dat (DDL - Data Definition Language) .................................................. 21 5.4 Indexy .................................................................................................................... 22 5.5 Vestavěné funkce................................................................................................... 22 5.6 Uživatelsky definované funkce, procedury a triggery ........................................... 23 5.7 Transakce ............................................................................................................... 23 5.8 Nástroje pro podporu migrace databází ................................................................. 23 5.9 Shrnutí ................................................................................................................... 24
6. Návrh metodiky pro výběr databázového systému............................ 26 6.1 Úvod ...................................................................................................................... 26 6.2 Hlavní faktory ovlivňující výběr ........................................................................... 26 6.2.1 Existence stávajících dat a jejich případná migrace.................................................... 26 6.2.2 Architektura aplikace .................................................................................................. 26 6.2.3 Autentizace uživatelů .................................................................................................. 28 6.2.4 Licenční politiky výrobců databázových systémů ...................................................... 28 6.2.5 Použití transakcí .......................................................................................................... 29
6.3 Návrh řešení pro modelové situace ....................................................................... 30 6.3.1 Existence stávajících dat a jejich případná migrace.................................................... 30 6.3.2 Architektura aplikace .................................................................................................. 33 6.3.3 Autentizace uživatelů .................................................................................................. 34 4
6.3.4 Licenční politiky výrobců databázových systémů ...................................................... 37 6.3.5 Použití transakcí .......................................................................................................... 38
6.4 Shrnutí ................................................................................................................... 43
7. Závěry ..................................................................................................... 46 8. Zdroje ..................................................................................................... 47 8.1 Tištěné zdroje ........................................................................................................ 47 8.2 Elektronické zdroje ................................................................................................ 47
Abstrakt Cílem této práce je sestavit metodiku pro podporu výběru databázového systému pro daný projekt IS/ICT. Práce se nejprve zabývá popisem vybraných databázových systémů, ukazuje, jakým způsobem se dá srovnávat jejich výkonnost, dále nabízí průřez problematiky migrace a popisuje jednotlivé dílčí faktory výběru, které jsou v závěru shrnuty. Práce byla vytvořena na základě odkazované literatury a autorových zkušeností z předchozího studia i praxe. Pokusil jsem se o postup, který se mi zdál nejlepší možný v případě řešení obecného problému výběru systému. Práce je rozdělená na 7 hlavních kapitol, z nichž první 3 jsou víceméně popisné a vytvářejí základ pro zbytek práce. Abstract Aim of this work is to make a methodic to support a decision which database system is the most suitable for the IS/ICT project. At first, some database systems are being described and it’s being shown, how to compare their performance. Then there is a chapter about database migration and finally the chapter describing particular factors of making a decision which database system is the best option. Those factors are summarized at the end of a chapter. This work is based on resources literature and my experience during my studies and practice. I tried to describe a process which was, in my own opinion, the best eventuality to solve a problem to make a choice which database system is the most suitable.
5
1. Úvod Cílem této práce je pokusit se získat a zpracovat informace o třech vybraných databázových systémech (MySQL Server 5.0, Microsoft SQL Server 2005 a Oracle Database 11g) a na jejich základě vytvořit obecný postup řešení výběru databázového systému pro projekty IS/ICT. Nejprve proberu základní pojmy, se kterými se v jednotlivých částech práce setkáte. Poté se budu zabývat obecnými rysy jednotlivých systémů a jejich vlastnostmi, kterými se od ostatních nějakým způsobem odlišují. Dále je třeba zmínit problematiku výkonnosti, proto jsem se rozhodl uvést výsledky standardních testů a postup, jak k nim dojít. V další části bych chtěl poukázat na problémy spojené s migrací již existující databáze do jiného systému, také mimo jiné v závislosti na výše uvedených vybraných databázových systémech. Tato problematika je velmi široká a sama jako taková by dostačovala na samostatnou práci. Nicméně v souvislosti s vytvářením IS/ICT projektů na zelené louce v době, kdy se začínají obnovovat již vytvořené funkční systémy, je nutné problematiku migrace databáze alespoň stručně zmínit. Poslední částí této práce bude metodika pro usnadnění výběru vhodného databázového systému, která bude rozčleněna do jednotlivých částí zabývajících se různými aspekty výběru včetně doporučení, jak tyto parametry využívat. Celá metodika se pokusí o obecné zakotvení problematiky s tím, že v některých případech budou vazby na mnou vybrané předem zmíněné databázové systémy.
6
2. Základní pojmy
Databáze Databáze jsou hierarchicky uspořádaná data uložená na disku počítače, na kterém je spuštěna aplikace spravující data. Software spravující takto uložená data se nazývá Database Management System (DBMS nebo také SŘBD - Systém řízení báze dat, RDBMS - Relační DBMS). Tyto systémy uložená data poskytují navenek v určité struktuře podle definovaného modelu. Nejčastěji používaným modelem je relační model, existují ale i další, například objektový, hierarchický, síťový, atd. [WIK1] Relační databázový model Relační model je založen na matematické teorii množin a predikátové logice, definuje integritní omezení dat a jejich reprezentaci, nicméně jejich fyzická implementace není důležitá a jsou definovány možné operace nad daty. Relace je tabulka o n sloupcích a m řádcích, kde každý řádek i sloupec je nutné jednoznačně identifikovat. Každá relace by správně neměla mít nikdy žádné 2 řádky shodné. To se řeší pomocí primárního klíče definovaného jako hodnota určitého sloupce nebo skupiny sloupců, která v tabulce nemůže být vícekrát. Relační operace je množinová, logická nebo jiná definovaná operace nad tabulkou (relací, pohledem,…) a jejím výsledkem je vždy další relace. Pro usnadnění návrhu relačních databází existují 3 normální formy od 1NF do 3NF postupně snižující možnou redundanci dat v tabulkách pomocí vazeb mezi nimi. [MAN1] SQL (Structured Query Language) SQL je jazyk používaný v relačních databázích pro definici dat a jejich získávání z databáze, k definování relací uskutečňovaných nad daty. SQL je standard pro provádění dotazů vůči RDBMS, s rozšiřováním funkcionality databází byl postupně několikrát obnoven. Nicméně každý databázový systém má svůj vlastní dialekt a složitější dotazy už mohou být ne zcela kompatibilní. Každopádně základní syntaxe je u všech shodná. Příkazy tohoto jazyka se dělí do čtyř základních skupin:
DDL - Data Definition Language slouží k popsání datových struktur tabulek, indexů a pohledů, příkazy vytvářejí (CREATE), mění (ALTER) nebo ruší (DROP) struktury celé nebo jen jejich části
DML - Data Manipulation Language pomocí těchto příkazů se data čtou (SELECT), ukládají (INSERT), upravují (UPDATE) a odstraňují (DELETE)
DCL - Data Control Language tyto příkazy jsou určeny k nastavování (GRANT) a odebírání (REVOKE) přístupových oprávnění a k ovládání transakcí, kde BEGIN transakci zahájí a COMMIT ji potvrdí nebo ji ROLLBACK zruší
Ostatní příkazy do této skupiny příkazů patří zejména příkazy sloužící k popisu doplňujících 7
funkcí, určené pro popis zejména uložených procedur, funkcí a triggerů, což jsou de facto podprogramy (aplikační logika) běžící na úrovni databázového serveru. [WIK2] Aplikační logika na úrovni databázového serveru V některých případech je výhodnější data předzpracovávat před tím, než se dostanou k aplikaci. Je to hlavně z důvodu zachování integrity databáze nezávisle na aplikaci. Nicméně přílišné používání tohoto způsobu se nedoporučuje kvůli tomu, že je pak systémová zátěž nerovnoměrně rozložená mezi aplikaci a databázi a může pak snáz dojít k přetížení serveru a ke snížení dostupnosti. V případě, že je využit určitý způsob předzpracování dat, je pak také výrazně komplikovanější migrace na jiný databázový systém, je-li to potřeba. (Relační) tabulka Tabulka je relační reprezentace dat uložených v databázi. Tabulka jako taková vyhovuje definici relace. Pohled Pohled je relace, vznikající pomocí DDL z relace vytvořené zpravidla sloučením různých sloupců několika tabulek nebo jako výběr sloupců ze samostatné tabulky. DBMS používají systémové pohledy jako možnost získávání systémových informací a správy databázového systému jako takového. Transakce Transakcí rozumíme skupinu databázových příkazů, které následují po sobě. V případě, že jeden z příkazů skončí chybou, je databáze vrácena do stavu před začátkem transakce.
8
3. Přehled vybraných databázových systémů 3.1 Oracle Database 11g 3.1.1 Základní popis Společnost Oracle je lídrem na trhu v oblasti databázových řešení. Ve velké míře je jejich systém využíván ve státní správě a ve velkých firmách, kde je nutné zabezpečit co nejrobustnější řešení. Verze 11g je nejnovější verze systému, obecně však platí, že ještě určitou dobu potrvá, než se začne využívat ve velké míře. Co se týče architektury databáze Oracle, existuje zde jeden hlavní rozdíl oproti drtivé většině ostatních systémů - Oracle má vždy k jedné instanci serveru pouze jednu “databázi” jako takovou. U ostatních systémů je možné v jedné instanci souběžně obsluhovat několik databází od sebe oddělených.
3.1.2 Systémové požadavky Oracle Database je k dispozici pro 32- i 64-bitové platformy Intel s operačním systémem Windows a Linux, Solaris (SPARC), AIX (PPC64) a HP-UX (Itanium, PA-RISC). Minimální požadavky na operační paměť jsou 1GB a požadavky na místo na pevném disku jsou minimálně kolem 5GB v závislosti na typu operačního systému. [ORA1,ORA2]
3.1.3 Další funkce Oracle Database je vpodstatě standard určující další vývoj v oblasti databázových řešení, proto se v této kapitole budu zabývat otázkami koncepce tohoto systému šířeji. [ORA3] 3.1.3.1 Rozšíření funkcí databázového systému Oracle využívá rozšíření pomocí uložených procedur (stored procedures) a triggerů napsaných ve svém proprietárním jazyku PL/SQL, nebo je možné psát jejich kód v jazyce Java. 3.1.3.2 Grid computing Grid computing spočívá v možnosti zpracování dat na několika počítačích současně. Při klasickém zpracování je při potřebě vyššího výkonu nutné zajistit výkonnější hardware, což může být co se týče nákladů velmi neefektivní. V případě použití grid computingu stačí pro relativně vysoký nárůst výkonu i běžný PC server, který se zapojí do gridu. Některé operace se přesunou ke zpracování na něj, čímž se sníží celková zatíženost systému.
9
Technologie Real Application Clusters (RAC) umožňuje několika různým instancím serveru přistupovat současně ke stejným datovým souborům. Toto řešení ale není čistě softwarovým. Aby totiž systém mohl s technologií pracovat, hardware serveru vyžaduje RAID úložiště a jednotlivé instance musí mít i přímo mezi sebou vysokorychlostní síťové spojení. [ORA5] 3.1.3.3 Automatizace a podpora správy Oracle poskytuje integrované řešení správy systému v rámci rozšíření Oracle Database Management Pack. Jde o sadu nástrojů, které umožňují efektivnější optimalizaci, nabízejí administrátorům přehlednější správu a do vysoké míry eliminují pravděpodobnost lidské chyby. Oracle uvádí, že tato sada umožňuje až o 38 % vyšší produktivitu ve srovnání s IBM DB2 a Microsoft SQL Server. 3.1.3.4 Partitioning Partitioning, tedy rozdělování tabulek a indexů, umožňuje lepší manipulaci s datovými soubory, zefektivnění obsazenosti datových nosičů a přizpůsobení pro provoz systémů s vysokými nároky na dostupnost a výkon. 3.1.3.5 Složité datové typy Oracle Database umožňuje vytváření vlastních složitějších datových typů, které se pak chovají jako objekty s jednotlivými vlastnostmi a funkcemi. Vlastnosti jsou v tomto případě jednoduché datové typy, z nichž se objekt skládá, a metody a funkce jsou buď různé uživatelské funkce nebo uložené procedury k nim navázané. Každý takový objekt má i svůj konstruktor (funkci, která se provádí vždy jako inicializace nového objektu, což je analogie ke klasickému objektově orientovanému programování), jenž je implicitně prázdný. Objektová tabulka se vytváří DDL příkazy. Nejprve je potřeba vytvořit typ - CREATE TYPE název_typu AS OBJECT (definice jednotlivých složek), a poté i vlastní tabulku CREATE TABLE název_tabulky OF název_typu. Každý objekt má svůj jedinečný identifikátor OID, nicméně i objektové tabulky mohou obsahovat také klasické klíče jako tabulky normální. Objektově lze v Oracle Database vnímat i současná, pouze relační, data pomocí Objektových pohledů, kdy starší aplikace mohou nadále využívat tradiční model. [ORA4] 3.1.3.6 Zabezpečení Oracle Database umožňuje velmi efektivně řídit správu zabezpečení, šifrování, auditing a monitoring na úrovni databázového systému. Systém mimo jiné nabízí audit i na úrovni jednotlivých sloupců v tabulce.
10
3.1.4 Výhody a nevýhody 3.1.4.1 Výhody
Velmi robustní databázový systém užívaný i na nejzatíženějších systémech
Systém je de facto standardem v oblasti databázových systémů
Existuje i ve verzi Express použitelné bez nutnosti pořízení drahé licence
3.1.4.2 Nevýhody
Velmi vysoké náklady na verze systému pro náročnější aplikace
Poměrně vysoké hardwarové požadavky například oproti MySQL databázi. To ale hraje roli pouze ve velmi malém množství případů, kde se Oracle Database zpravidla nepoužívá.
3.1.5 Licence Databáze Oracle je dostupná v několika různých verzích (edicích), které se od sebe liší. Cena se pak odvíjí podle volby Edice, počtu procesorů a souběžně připojených klientů.
Enterprise Edition Nejobsáhlejší edice, která je limitována pouze výkonem hardwaru serveru, případně clusteru serverů, vhodná pro transakční zpracování, business inteligence a správu obsahu.
Standard Edition Nabízí obdobné možnosti jako Enterprise Edition s tím, že verze je limitována pro použití s maximálně čtyřmi současnými spojeními.
Standard Edition One Nabízí plnohodnotné databázové prostředí, které ale může obsloužit pouze 2 současná spojení. Licence je na uživatele s tím, že jich musí být minimálně 5 a že nelze použít clustery.
Express Edition Tato verze je zdarma i pro komerční využití, avšak licence umožňuje využívat pouze jedno jádro procesoru, 1GB operační paměti a velikost datových souborů nemůže překročit velikost 4GB. Další nevýhodou je absence Enterprise Manageru.
11
3.2 Microsoft SQL Server 2005 3.2.1 Základní popis Microsoft SQL Server je databázový systém využívaný v drtivé většině případů s technologiemi firmy Microsoft. Ve verzi 2005 je hlavní novinkou přímá vestavěná podpora .NET (SQL CLR - SQL Common Language Runtime). Microsoft tím nabízí komplexní služby pro vývojáře, které umožňují zkrácení času time to business, a tím snížení celkových nákladů na vývoj.
3.2.2 Systémové požadavky Požadavky na systémové prostředky se liší podle výběru edice [MSS1]. V praxi to ale znamená, že pro 32-bitovou architekturu je nutné mít alespoň 512 MB RAM a procesor minimálně Pentium III s taktovací frekvencí 600 MHz. Pro 64-bitové architektury pak navíc platí, že procesor musí být přinejmenším na 1 GHz s tím, že minimální doporučená velikost operační paměti je 1 GB RAM. Systém pracuje pouze s Windows 2000 SP4 a vyšší, v případě 64-bitových systémů pak minimálně s Windows XP Professional x64.
3.2.3 Další funkce 3.2.3.1 SQL Common Language Runtime V tomto ohledu je SQL Server nejzajímavější, co se týče integrace .NETu. V minulých verzích se aplikační logika na databázovém serveru psala v T-SQL, který byl pro mnoho vývojářů obtížně použitelný a tato řešení v některých případech navíc představovala jistá bezpečnostní rizika. Proto byla ve verzi 2005 zabudována možnost tyto funkce psát pomocí SQL CLR. Toto řešení nabízí také možnost využívat i jiné systémové prostředky a služby, pokud pracují jako COM komponenty nebo jako DLL podle výběru programovacího jazyka. Například je možné během zpracování uložené procedury odeslat e-mail nebo vyvolat nějakou jinou systémovou událost. [MSS2] 3.2.3.2 Složité datové typy SQL Server 2005 umí obdobně jako Oracle vytvářet složitější datové typy, avšak jejich použití se nedoporučuje zejména pro nadměrné zatížení systému, vysoký počet zamykaných záznamů pokud není databáze vyloženě optimální a v případě jeho použití není možné pracovat s dědičností a dalšími výhodami objektově orientovaného modelu. V tomto případě se nabízí použití integrace .NETu v rámci aplikace. Při použití rozhraní ObjectSpaces API je totiž možné vytvořit objektový model na straně klienta napsaného v .NETu, a to tak, že záznam v tabulce nebo i tabulkách (v podstatě určitý pohled do databáze) lze pomocí objektového modelu transformovat do třídy definované v klientské aplikaci pomocí datové definice třídy (OSD - Object Schema Definition) a relační definice (RSD - Relational Schema Definition). Z OSD a RSD vznikne mapovací schéma (MSD - Mapping Schema Definition), které se použije při inicializaci instance třídy ObjectSpace. Toto má obrovskou výhodu ve zjednodušení práce pro programátora, protože za něj ObjectSpace řeší komunikaci s databází. [MSS3]
12
3.2.3.3 Webové služby Ve verzi 2005 je novinkou, že v případě, kdy server běží na operačním systému Windows Server 2003, dokáže pracovat přímo jako webová služba a komunikovat tak přes port HTTP pomocí XML v rámci SOAP, aniž by bylo potřeba nějaké střední vrstvy. Ve verzi 2000 to bylo možné také, ale pouze s použitím ISAPI modulu webového serveru Microsoft Internet Information Services. Díky tomuto je pak SQL Server teoreticky schopen komunikovat s jakýmkoliv klientem, nicméně v tomto případě je na místě i otázka výkonu a bezpečnosti celého systému. [MSS4]
3.2.4 Výhody a nevýhody 3.2.4.1 Výhody
Integrace s Microsoft Visual Studiem (.NET) a díky němu v některých případech snížení nákladů na vývoj
Nižší cena oproti Oracle
Integrace v operačních systémech Windows
3.2.4.2 Nevýhody
Prakticky nemožná migrace na jiný operační systém.
Velké rozšíření Windows nese riziko vyšší zranitelnosti z pohledu bezpečnosti
3.2.5 Licence Microsoft svůj SQL Server 2005 vydává v několika edicích, v závislosti na edici je k dispozici určitý počet souběžných spojení a využití určitého počtu procesorů najednou. Poslední 2 uvedené edice jsou k dispozici zdarma. [MSS5]
Enterprise Edition Nejpokročilejší verze včetně všech dostupných funkcí. Je vhodná především pro aplikace transakčního zpracování a pro data warehousing.
Standard Edition Vhodné prostředí pro malé a střední organizace.
Workgroup Edition Pro malé organizace, které využijí neomezenou velikost dat a počtu uživatelů.
Developer Edition Verze určená pro vývojáře k testovacím účelům. Má shodné parametry s edicí Enterprise
Express Edition Zjednodušená verze, která je velmi limitována, například ve velikosti maximálně využitelné paměti, počtu využitých procesorů, atd.
Compact Edition Edice vhodná pro jednouživatelské aplikace na všech dostupných verzích operačního systému Windows. 13
3.3 MySQL Server 5.0 3.3.1 Základní popis MySQL Server je světově nejrozšířenější relační open source databázový systém. Je jednou z klíčových součástí tzv. LAMP (operační systém Linux, webový server Apache, MySQL, skriptovací jazyky PHP / Perl / Python), která se v současné době používá u velkého počtu webových aplikací, protože celé toto řešení je velice spolehlivé a postavení na open source základu výrazně snižuje finanční náklady na vývoj i běh aplikace. Pro tento systém existuje i sada grafických nástrojů, které jsou obdobou nástrojů proprietárních databázových systémů (MS SQL Database Management Console, Oracle Enterprise Manager,…) V současně době se za aktuální verzi považuje 5.0, ale existují i beta verze 5.1 a alpha verze 6.0. Ve verzi 5.0 se objevily nové možnosti pro zpracování aplikační logiky na straně serveru - jde o uložené procedury, pohledy a triggery (v omezené míře), které v minulých verzích nebylo možné použít. V tomto případě je vidět, že se rozdíl v možnostech proprietárních a open source databázových systémů začíná rychle snižovat.
3.3.2 Systémové požadavky MySQL Server je dostupný pro mnoho platforem v binárním formátu (Windows 2000, XP a novější, mnoho Linuxových distribucí, Mac OS X, Solaris, HP-UX, Novell a další), nicméně jsou dostupné i zdrojové kódy, takže je možné databázový server nainstalovat v podstatě na jakýkoliv operační systém, pro nějž existuje kompilátor jazyka C. Specifické systémové požadavky se odvíjejí od potřebného místa na disku. Databázový server je možné spustit prakticky na všech osobních počítačích, které jsou v současnosti dostupné. [MYS1]
3.3.3 Další funkce Funkce uváděné v této kapitole jsou podle [MYS1]. 3.3.3.1 Databáze INFORMATION_SCHEMA Tato databáze metadat o datové základně je podstatnou novinkou ve verzi 5.0. 3.3.3.2 Uložené procedury a funkce Tuto funkcionalitu poskytuje nově verze 5.0. Používá se syntaxe standardu SQL:2003, kterou používá například IBM DB2. Implementace uložených procedur a funkcí do serveru ale stále ještě probíhá. Příkazy pro zamykání a odemykání tabulek (LOCK TABLES a UNLOCK TABLES), LOAD DATA, LOAD TABLE pro uložené procedury i funkce stále nejsou implementovány. Pro uložené funkce platí stejná omezení jako pro procedury, mají ale i další omezení. Omezení, týkající se pouze funkcí, jsou pak aplikovány i na uložené procedury, které 14
jsou spouštěny v rámci funkce. V uložených funkcích nejsou povoleny:
připravené SQL příkazy (PREPARE, EXECUTE, DEALLOCATE, PREPARE),
příkazy provádějící explicitní nebo implicitní COMMIT nebo ROLLBACK,
příkazy vracející množinu výsledků s výjimkou příkazu SELECT … INTO … a s výjimkou užití ukazatelů a příkazu FETCH,
příkaz FLUSH,
uložené funkce nemohou být spouštěny rekurzivně,
uložené funkce nemohou modifikovat data v tabulce, na kterou se vztahuje SQL dotaz vyvolávající danou funkci.
3.3.3.3 Triggery Triggery jsou v MySQL serveru naimplementovány od verze 5.0.2 a jejich implementace není doposud úplná. Omezení vyplývající z tohoto faktu jsou stejná jako v případě uložených funkcí. 3.3.3.4 Pohledy Pohledy jsou v MySQL Serveru 5.0 novinkou a stejně jako uložené funkce a procedury a triggery podléhají určitým omezením:
na pohled není možné vytvořit index,
v klauzuli FROM není možné použít poddotaz.
V případě, že se provede změna v tabulce, která je použita v nějakém pohledu a má to za následek to, že pohled již není možné zobrazit, server zobrazí chybovou hlášku až v případě, že je proveden dotaz na daný pohled.
3.3.4 Výhody, nevýhody 3.3.4.1 Výhody
Systém je založen na open source licenci, jeho používání není v základní verzi nijak limitováno.
Běží na téměř každém současném počítači.
Je k dispozici pro velké množství platforem.
15
3.3.4.2 Nevýhody
Založení na open source licenci může vést k rychlejšímu proniknutí do systému.
Oproti proprietárním databázovým systémům stále chybí množství funkcí.
Nižší robustnost oproti proprietárním databázovým systémům.
3.3.5 Licence MySQL je dodáván ve dvou různých variantách – Community a Enterprise, přičemž varianta Community je zdarma. Existuje také verze MaxDB, která je určena pro použití s produkty SAP. Verze MySQL Community Server je určena pro ty, kteří si server nainstalují a spravují sami, verze jim nepřináší žádná omezení. Při koupi MySQL Enterprise jsou k dispozici navíc technická tyto služby:
Configuration Wizard umožňuje jednoduché spuštění a upgrade databáze.
MySQL Enterprise Support je standardní technická podpora pro řešení technologických problémů.
MySQL Certified DBAs non-stop konzultační služba pro administraci.
MySQL Security Advisor průběžně monitoruje systém proti bezpečnostním chybám.
MySQL Replication Advisor pro vylepšení způsobu replikace a výkonu systému.
MySQL Performance Advisor pro návrhy na možnosti zvýšení výkonu.
16
4. Srovnání výkonnosti vybraných databázových systémů 4.1 Způsob výběru testu výkonnosti Existuje mnoho způsobů testování výkonnosti databázových systémů - jde o tzv. benchmarkové testy. Je jich celá řada, nicméně existuje jeden test, který se stal de facto standardem pro měření výkonnosti relačních databázových systémů, a to test TPC-C od sdružení TPC (Transaction Processing Performance Council). Benchmarkové testy se snaží co nejdokonaleji popsat a napodobit reálnou situaci a na rozdíl od mnoha jiných mají i možnost srovnání a kvantifikace jednotlivých možností při výběru nového databázového řešení - díky způsobu jejich provádění. Při výběru tohoto testu jsem ale zjistil absenci MySQL Serveru 5 mezi testovanými platformami, což by mohlo vyvolat otázku, zda je v tomto případě srovnání na základě testu TPC-C možné. MySQL není v současné době ve velkých podnikových řešeních obvyklou platformou, používá se většinou pro méně zatížené systémy. I proto se výrobci hardware nehrnou do testování databáze řešené prostřednictvím MySQL. Z faktu, že MySQL se i podle dokumentace dá nainstalovat na prakticky jakýkoliv počítač, je zřejmé, že je a v nejbližší budoucnosti stále bude spíše řešením pro méně nákladné projekty, kde cena bude mít vyšší prioritu než výkon ve srovnání s konkurencí. Dále je třeba zmínit, že co se týče transakčního zpracování a dalších záležitostí týkajících se uložených procedur a dalších aplikačních prvků na straně databáze stále MySQL nedosahuje úrovní implementace svých protivníků. Ovšem z hlediska databází, v nichž neprobíhá transakční zpracování, mají výkon velmi významný - uvádí se, že dosahuje vyšší rychlosti zpracování i v řádech desítek procent. Toto se dá brát v úvahu pro jednodušší aplikace s relativně nízkým rozpočtem, kde se absence transakcí dá relativně jednoduše zajistit přímo v rámci aplikace. V tomto případě ale nelze opomenout nové tzv. Express verze zbylých dvou mnou uvedených databázových systémů, které se dají použít bezplatně, i když s jistými omezeními, jak je uvedeno v kapitole 3.
4.2 Model testu TPC-C Tento benchmarkový test má jednu zásadní výhodu - je nezávislý na platformě, na níž má běžet. Právě díky tomu je možné srovnávat i systémy, které pracují na jiných operačních systémech, s jinými databázovými systémy, na strojích od jiných výrobců, apod. Z testu totiž vycházejí 2 hodnoty, a to počet určitých transakcí provedených za minutu (tpm-C) a finanční náklady na jednu transakci za minutu. Tyto náklady se odvíjejí od ceny celého řešení, všech nákladů na pořízení funkčního systému, proto je pak možné srovnávat prakticky kterékoliv systémy podle těchto dvou hodnot a nedopustit se chyby. Test nespecifikuje povinnost použití či nepoužití různých vlastností databázových systémů jako je partitioning, replikace nebo clustery, protože vyšší náklady na hardware a software ovlivňují i výsledný poměr cena/výkon - tudíž není nutné technické zpracování nijak omezovat.
17
Test pracuje tak, že simuluje prostředí klasického systému vyřizujícího objednávky zákazníků, jejich platby, kontrolu stavu objednávek, skladování a doručování zboží těchto 5 typů transakcí pracuje souběžně, aby byly schopné simulovat reálné prostředí s tím, že hlavní business cíl je v tomto případě založení objednávky Test tedy počítá počet úspěšně vytvořených objednávek za minutu (tpm-C). Test dále počítá s tím, že v systému je nutné udržovat proměnlivý počet skladů, kde každý sklad obsluhuje 10 geografických celků, přičemž v každém se nachází 10 000 zákazníků. Jakákoliv z výše uvedených transakcí může být provedena v jakýkoliv okamžik, který je ale prováděn na základě obvyklých modelových situací. Každý sklad obsahuje v průměru 10 000 položek a nejčastější operací je vytvoření objednávky obsahující v průměru 10 položek skladu. V praxi se obvykle stává, že alespoň jedna položka v objednávce není v daném skladu, tudíž je nutné ji vzít ze skladu jiného. Model uvádí, že to je až 5 % všech objednaných položek. To, jestli je systém možné plně využít v reálném provozu ale závisí i na možnostech obnovy databáze po havárii, nutně musí splňovat vlastnosti ACID (Atomicity, Consistency, Isolation, Durability). Hodnota celkových nákladů musí obsahovat i náklady spojené s 5-tiletou údržbou hardwaru a softwaru a kapacitu datových úložišť pro generování dat pro následujících 180 pracovních dní. Data obsahují 8 různých druhů záznamů, aby byla zaručena různorodost dat, s nimiž všech 5 souběžně probíhajících transakcí pracuje, a dále je také nutné nasimulovat i lidské chyby, jako například chybné zadání kódu objednávky, apod. Mimo jiné je také nutné počítat s tím, že data posílaná na výstup musejí být formátována do určitého tvaru, což také do jisté míry ovlivňuje výkon. [TPC1]
4.3 Testování Testy na různých druzích hardware jsou k dispozici online na http://www.tpc.org/tpcc/results/tpcc_results.asp. Pro tento případ jsem vybral testy Oracle 11g Standard Edition One a MS SQL Server 2005 Enterprise Edition x64, které jsou funkcionalitou obdobné, oba běží na stejném typu serveru s podobnou konfigurací (viz tab 4.1). K databázi jsou připojeni 2 klienti totožné konfigurace ( Intel P915 na taktovací frekvenci 2.8 Ghz).
18
Oracle 11g
MS SQL Server 2005
Server
HP ProLiant ML350 G5
HP ProLiant ML350 G5
Procesor
Intel X5355 2.66 GHz
Intel E5320 1.86 GHz
Operační systém
Microsoft Windows Standard x64 Etd. SP1 R2
Microsoft Windows 2003 x64 Server Std. Ed.
Transakční monitor
Microsoft COM+
Microsoft COM+
Celkové náklady na systém
74,556 USD
68,814 USD
Výkon TPC-C
102,454
82,774
Cena / Výkon
0.73 USD
0.84 USD
Tabulka 4.1: Srovnání TPC-C testů
V tomto případě je možné vidět, že v poměru cena/výkon i v počtu transakcí za minutu dopadla lépe dražší varianta. Je otázkou, zda je rozdíl téměř 6 000 USD akceptovatelný ze strany sponzora projektu. Dále je možná zajímavé zmínit, že náklady na software v případě řešení s MS SQL Serverem byly téměř dvojnásobné. Z tohoto testu je podle předpokladů testu TPC-C zřejmé, že v daném případě vyšel ve srovnání vítězně Oracle. [TPC2, TPC3]
19
5. Problémy migrace mezi vybranými databázovými systémy Každý databázový systém, ačkoliv používá standardizovaný jazyk SQL, má i vlastní dialekt, což může v některých případech dělat problémy. Mohou se s nimi setkat programátoři, kteří vytvářejí aplikace v několika různých prostředích, kde v každém systému některé funkce pracují jinak. Ještě horší situace nastane, když potřebujete použít jiný databázový systém než v minulosti na stejná data s použitím stejné aplikace nebo aplikace pozměněné. Pak je nutné databázi přemigrovat. Nejhorší případ je, když potřebujete data přesunout na server s vývojově nižší verzí nebo typem, než na jakém aplikace běží v současnosti. V některých případech se může také stát, že některé funkce mohou mít shodné označení a jinou funkcionalitu nebo se mohou v každém systému jmenovat jinak, ale chovat se stejně. Problémy migrace se v této kapitole budeme zabývat z několika důležitých pohledů a na závěr se podíváme na stručný přehled několika nástrojů určených pro zjednodušení migrace databáze.
5.1 Datové typy Mezi jednotlivými databázovými systémy samozřejmě existují rozdíly jak v názvech, tak i v kapacitách jednotlivých datových polí (typů sloupců). Problémy se dají nalézt i v případě ukládání dat do připravených struktur - například pokud jde o datum, Microsoft SQL Server používá jiný formát zápisu dat. Při použití pole ukládajícího text se může lišit použití určitého typu i v rámci změny kódování textu - v tomto případě se může stát, že data, která do databáze uložíme, mají v databázi “větší délku” použijemeli vícebajtové kódování (např. UTF-8) a nepoužijeme k tomu speciálně určený datový typ. Například MySQL problém znakových sad řeší čistě v rámci nastavené znakové sady, ostatní databázové systémy vyžadují použití speciálního typu. Pokud jde o přechod z MySQL na jiný systém, je zde evidentní značný rozdíl v počtu jednotlivých číselných datových typů, které je potřeba přemapovat do patřičných ekvivalentů (ty je možné nalézt v dokumentaci všech mnou zmiňovaných databázových systémů). Tyto záležitosti ale v současné době dokáže poměrně spolehlivě řešit celá řada nástrojů usnadňujících migraci mezi jednotlivými systémy. Další problémy s datovými typy mohou nastat, používáme-li uživatelsky definované složitější datové typy – zde již úprava většinou není tak jednoduchá. Například MySQL vůbec uživatelské datové typy nepodporuje, kdežto ostatní mnou vybrané systémy ano. V Oracle Database se dají definovat jako objekt několika jednoduchých typů. Pro Microsoft SQL Server se dají složité uživatelské datové typy definovat pomocí .NET Frameworku. Dále se systémy chovají rozdílně při definování uživatelských proměnných. Zatímco inicializace proměnných v MySQL Serveru probíhá v rámci prvního nastavení, 20
v případě MS SQL Serveru je nutné proměnné deklarovat klíčovým slovem DECLARE a proměnné v MySQL existují jen po dobu spojení, což v případě MS SQL Serveru neplatí. V případě Oracle je možné definovat proměnné na úrovni PL/SQL kódu nebo proměnné pro spojení v rámci klienta.
5.2 Manipulace s daty (DML - Data Manipulation Language) Každý databázový systém má svůj dialekt SQL, ačkoliv poukazuje na obsažení nějakého standardu. Většina standardních příkazů funguje ve všech databázových systémech. Existují ale i takové případy, kde je nutné obejít některá zjednodušení, což samozřejmě neplatí pouze pro tuto podkapitolu. Jako příklad mohu uvést použití klauzule LIMIT [start, ] počet_řádků v MySQL Serveru pro výběr pouze určitého rozsahu vrácených řádků dotazem, kde při uvedení pouze jednoho parametru je vráceno prvních počet_řádků, nebo lze výpis započít až od řádku start. Toto řeší i ostatní dva mnou vybrané systémy po svém. Zatímco Oracle v rámci každého SELECTu obsahuje pseudořádek ROWNUM, takže se klauzule LIMIT dá obejít v rámci bloku WHERE ROWNUM >= start AND ROWNUM <= (start + počet_řádků), v případě MS SQL Serveru existují 2 možnosti - buď SELECT TOP počet_řádků * FROM tabulka pro prvních počet_řádků řádků, nebo v rámci poddotazu, v němž figuruje funkce row_number() v seznamu sloupců a jeho následné omezení v rámci bloku WHERE. Další problémy se týkají hlavně příkazů DELETE a UPDATE v případě rozsahu na více než jednu tabulku, což podporuje pouze MySQL. V těchto případech je nutné příkazy rozdělit do několika různých příkazů. Dále s tím souvisí i možnost MySQL pomocí příkazu INSERT vložit i více řádků najednou. Kromě toho mohou nastat problémy i při použití GROUP BY a HAVING.
5.3 Definice dat (DDL - Data Definition Language) MySQL podporuje klauzuli IF (NOT) EXISTS, která zabraňuje chybovému hlášení v případě pokusu o vytvoření nebo zrušení nějaké datové struktury (tabulka, pohled,...). Tu ale Oracle ani MS SQL Server nepodporují a je třeba pro ně napsat funkci v PL/SQL nebo T-SQL v případě SQL Serveru, která sama tento problém ošetří. Další obtíže mohou vzniknout při používání dočasných (TEMPORARY) tabulek. Zatímco v případě dočasných tabulek u MySQL vždy platí to, že tabulka existuje až do konce spojení, v případě Oracle Database je možné zvolit, zda je dočasná tabulka určená pro celé spojení nebo pro danou transakci. U MS SQL Serveru platí dočasná tabulka buď pro transakci nebo proceduru, tzn. že po ukončení procedury je dočasná tabulka automaticky odstraněna. Každá databáze jako taková má svoje specifika, a to platí i v případě jejich DDL. Je-li potřeba struktury migrovat, je jediná možnost vždy všechny náležitosti konzultovat 21
s dokumentací nebo použít speciální nástroj pro migraci databází.
5.4 Indexy Problémy mohou působit i možnosti automatického generování primárního identifikátoru - unikátního čísla automaticky zvětšovaného při přidání dalšího řádku do tabulky. Zatímco MySQL umožňuje u číselného primárního klíče uvést klíčové slovo AUTO_INCREMENT a u MS SQL Serveru se dá použít T-SQL definice IDENTITY(), Oracle Database si s tím tak jednoduše neporadí, je nutné vytvořit sekvenci, do níž se ukládá poslední použité číslo a trigger pro nově vkládané řádky dosazuje hodnotu primárního klíče. V případě definice klíčů existují také drobné rozdíly v klíčových slovech v případě MS SQL Serveru a MySQL dovoluje referenci cizích klíčů i do jiných databází. SQL Server se od svých protivníků dále liší i v jednom poměrně zásadním směru - ve sloupci s unikátním (UNIQUE) indexem bere i hodnotu NULL za hodnotu, a tudíž v jedné tabulce nemohou být dva řádky obsahující tuto “žádnou” hodnotu, to v případě MySQL ani Oracle neplatí. Podíváme-li se na plnotextové (FULLTEXT) indexy, tak zjistíme, že Oracle používá vlastní sadu indexů pro fulltextové vyhledávání, které jsou v dokumentaci velmi podrobně popsány. MySQL a MS SQL Server používají klasický fulltext index, nicméně na rozdíl od MySQL má produkt od Microsoftu zásadní omezení týkající se tohoto typu indexů, a to, že není možné přidat index k tabulce, v níž již fulltextový index existuje a tabulka musí obsahovat alespoň jeden index typu UNIQUE. Oracle typ indexu FULLTEXT nezná, nicméně obsahuje celou sadu indexů pro použití při plnotextovém vyhledávání. Jak je vidět, problematika indexů v rámci migrace je také velmi důležité téma. Většina nástrojů na podporu migrace si s tím ale dokáže poradit a vzhledem k dostupnosti těchto informací v dokumentaci je zde není třeba více rozebírat.
5.5 Vestavěné funkce Každý databázový systém má svá specifika. Například MySQL ještě donedávna neumožňoval pracovat s uživatelsky vytvářenými funkcemi, uloženými procedurami a triggery, což kompenzoval velkým množstvím vestavěných funkcí přímo do databázového systému, aby se tak ulehčila práce s ním. Pokud již daná aplikace využívá různé dotazy, obsahující ne úplně standardní funkce, je nutné je přepsat. Při přechodu z MySQL je tedy třeba dát výrazně pozor, zda nedochází k problémům s aplikací některé funkce se liší pouhým identifikátorem, jiné je nutné ošetřit přímo v aplikaci. Při kontrole je velmi vhodné zaměřit se na různé operace s datem a časem a další operace s texty. Je důležité i takto specializované dotazy konfrontovat s dokumentací nově zaváděného databázového systému.
22
5.6 Uživatelsky definované funkce, procedury a triggery Při migraci databáze, která obsahuje nějaké uživatelsky definované funkce (UDF - User Defined Function), procedury nebo triggery, se prakticky nikdy nevyhnete nutnosti jejich přepsání. V mnou sledovaných případech se všechny vytvářejí jiným způsobem, MS SQL Server umožňuje uživatelské kódy psát pomocí T-SQL nebo jako knihovny psané v jazyce podporovaném .NETem, Oracle je umožňuje psát buď pomocí PL/SQL nebo v Javě. V případě MySQL je pro použití UDF nutné zkompilovat a zavést modul v jazyce C. Používáme-li uložené procedury nebo triggery, slouží pro jejich popis syntaxe SQL:2003, kterou používá mimo jiné IBM DB2. Navíc existují pravidla pro používaná rozhraní tříd, pokud jsou vytvářeny jako UDF, a to může přepis kódů těchto funkcí a procedur velmi zkomplikovat situaci. Jednotlivé funkce a procedury mají pro každý systém i svá určitá specifika, která je občas nutné obejít (například platnost dočasných tabulek), vždy je však potřeba nahlédnout do dokumentace pro daný případ řešení. Problémy mohou nastat v případě, že je potřeba databázi migrovat na MySQL, když procedury obsahují vlastnosti, které MySQL dosud nepodporuje, viz kapitola 3.
5.7 Transakce V rámci migrace je také důležité zmínit rozdíly v implementacích transakčního zpracování různými databázovými systémy. Je například nemožné migrovat databázi pracující s geoprostorovými daty na MySQL, pokud je nutné v databázi i v tabulkách obsahující takováto data používat transakce, protože MySQL podporuje ukládání prostorových (spatial) dat pouze v typech tabulek MyISAM, který nepodporuje transakce. Více se této problematice budu věnovat v kapitole 7.
5.8 Nástroje pro podporu migrace databází Existuje mnoho nástrojů podporujících převod dat a struktur z jednoho databázového systému do druhého, některé slouží pro převod z databáze A do databáze B, jiné umožňují migraci na více systémů. Důležité také je, jakým způsobem se dostávají k datům, některé pracují pouze s dumpem databáze (textový soubor obsahující výpis DDL a DML instrukcí), některé se k datům připojí přes ODBC (Open Database Connectivity) a jiné používají přímý ovladač a ne všechny nástroje dokáží přemigrovat I aplikační logiku dané databáze. I když existuje mnoho nástrojů pro ulehčení a zautomatizování migrace, prakticky nikdy se neobejde bez zásahu administrátora databáze. Všechny mnou vybrané databázové systémy obsahují vlastní nástroj pro migraci dat i struktur včetně uložených procedur i mezi sebou (viz tab. 5.1) s výjimkou migrace z MySQL na MS SQL Server, kde pro MySQL byl vydán pouze dokument popisující rozdíly mezi dotčenými databázemi. Proto bych preferoval vždy nástroj od daného 23
výrobce cílového databázového systému, vyjma migrace z MySQL na MS SQL Server. To v současné době ze strany Microsoftu dokáže pouze DTS (Data Transformation Services) a ten v současnosti migruje pouze data a struktury bez procedur, ty je pak nutné přepsat kompletně ručně. Existuje i mnoho dalších nástrojů poskytující zjednodušení migrace, nicméně jsou to obvykle další investice, a to v případě, kdy výrobci databází umožňují použít svoje nástroje bezplatně, nemusí mít své opodstatnění. Název
Podporované zdrojové DB
Oracle SQL Developer 1.5 (Migration Workbench)
MySQL, MS SQL Server, MS Access, Sybase
Microsoft SQL Server Migration Assistant
MS Access, Oracle, Sybase, v budoucnu DB2 a Informix
MySQL Migration Toolkit
Oracle, MS SQL Server, MS Access, Sybase, MySQL
Tabulka 5.1: Stručný přehled migračních nástrojů výrobců
Výše uvedené tři nástroje pracují tak, že nejprve načtou zdrojovou databázi a dají na výběr, které struktury a data je potřeba migrovat, provedou úpravy datových typů, indexů, procedur a vypíší výsledek včetně varování a chyb, k nimž došlo. Tyto systémy dokáží velké množství problémů uvedených v této kapitole vyřešit, aniž by správce databáze musel nějakým způsobem zasahovat. Velmi záleží na tom, jak je databáze navržena a jak jsou napsány procedury. Je jasné, že čím více se vývojáři drží standardů, tím jednodušší je posléze migrace databáze na jiný systém. Po vyřešení všech vzniklých problémů je možné pokračovat dál v konverzi dat a cílovém umístění. Použití takovýchto nástrojů podle zdrojů snižuje dobu potřebnou pro migraci stávajících systémů až o 90 %, ale vždy samozřejmě záleží i na typu dat.
5.9 Shrnutí Chceme-li migrovat databázi, a je-li tato databáze navíc velmi obsáhlá, je její migrace na koleni bez migračních nástrojů velmi zdlouhavá a nákladná. Je také otázkou, zda je pak databáze plně pod kontrolou administrátorů a vývojářů. Migrace je vždy velmi náročná, ať už z hlediska nákladů, tak i pro rizika s tím spojená. Proto je důležité, aby si ti, kteří migraci provádějí, včas a do detailů uvědomovali, všechny možné problémy s tím spojené. Obecně se doporučuje takzvaná migrace na zkoušku, kdy současně běží oba systémy. Někteří zákazníci, kteří jsou ochotni testovat nové a nevyzkoušené, mohou využívat nový systém, kde se již za neúplného běhu většinou projeví problémy, které by při ostrém provozu mohly mít daleko negativnější dopad. Pokud je tedy takový zkušební provoz možný, je to nejlepší možná volba. Na závěr uvedu ještě dvě zásady, které je potřeba při migrování dat dodržovat, za prvé 24
jsou to časové rezervy, protože mohou nastat i velmi neočekávatelné situace, a za druhé testování. I při sebetriviálnější změně při postupu migrace je třeba provedené změny nejprve vyzkoušet, protože i taková triviální změna může i velmi závažně ovlivnit výsledek migrace. Co se týče migrace databází, je zřejmé, že toto téma je velmi obsáhlé a jeho dosah je velmi široký. Proto jsem nezabíhal do větších detailů, ale snažil jsem se dotknout těch co možná nejpodstatnějších témat s migrací souvisejících. [ORA7, ORA8, MSS7, MSS8, MSS9, MYS1, MYS3, SWI1]
25
6. Návrh metodiky pro výběr databázového systému 6.1 Úvod V rámci této kapitoly se budeme zabývat postupy, na základě kterých by mělo být jednodušší zvolit optimální databázový systém pro připravovaný projekt. Pro zjednodušení budeme brát v úvahu pouze tři výše uvedené databáze, avšak z hlediska dalšího použití by neměl být problém uvedené postupy nasadit i pro výběr jiných systémů. Před zahájením výběru je nutné vědět, na jakém systému běží současná data, jsou-li nějaká, jak náročné by bylo data přemigrovat; zda jsou pro výslednou aplikaci potřeba transakce či ne, existují-li nějaká hardwarová nebo softwarová omezení. Dále je třeba zvážit rozpočtová omezení a mnoho dalších faktorů, kterých se v této kapitole pokusím dotknout.
6.2 Hlavní faktory ovlivňující výběr 6.2.1 Existence stávajících dat a jejich případná migrace V dnešní době je méně obvyklé, že by aplikace byla zaváděna čistě na “zelené louce”. Zpravidla je nutné do aplikace pro začátek nějaká data alespoň naimportovat. Co se týče jednoduchého importu dat, tak to v současnosti prakticky žádný problém není. Problém však nastává, jde-li o nějakou rozsáhlejší databázi s různými integritními omezeními nebo dokonce s uživatelskými funkcemi a procedurami. V tom případě je nutné zvážit, jestli je potřeba databázi vůbec někam přesouvat nebo kompletně rekonstruovat, jestli není možné stávající databázi pouze rozšířit a ponechat ji tam, kde v současné době je. V případě, že aplikační logika celá spočívá mimo databázi, je možné celou databázi přesunout na jiný systém. Existuje mnoho užitečných nástrojů pro převod datových struktur i dat jako takových mezi jednotlivými systémy. V případě aplikační logiky na úrovni databáze už to problém být může, protože databáze používají různé způsoby popisu uživatelských funkcí a procedur, viz kapitola 3 a 5. Dalším závažným problémem, se kterým je možné se setkat během migrace databáze, je napojení nové databáze na stávající aplikaci, to je tématem další subkapitoly této práce. Problémy pak způsobují i další funkce specifické pouze pro určitý produkt, např. zamykání záznamů a tabulek, transakce, apod.
6.2.2 Architektura aplikace Pro rozšiřování stávající aplikace nebo vytvoření aplikace nové většinou platí to samé, co bylo řečeno v úvodu předcházející subkapitoly. Není-li nutné aplikaci celou přepsat, je lepší a daleko méně nákladné rozšířit tu stávající. I toto má však svá úskalí, protože v některých případech se může rozšiřování stávající aplikace stát i dražším, v rámci 26
chodu firmy ne plně využitelným nebo postrádajícím důležité funkce pro řízení chodu společnosti prostřednictvím IT. Nicméně z hlediska úspěšnosti dokončených projektů jsou ty vylepšující nebo částečně transformující ve velké většině případů vhodnější, i když mají třeba výsledný efekt nižší, zato oproti kompletně novému zpracování efekt de facto zaručený. Výběr datové základny úzce s aplikací jako takovou souvisí. Neobsahuje-li aplikace rozhraní pro práci s databází, které je schopné zajistit, že veškeré datové operace se dějí pouze v rámci instance oné třídy rozhraní, může použití ovladačů pro jiný systém způsobit konflikty, a to nejen díky jeho programovacímu rozhraní, ale i díky rozdílnosti jednotlivých dialektů jazyka SQL. Výše zmíněným „rozhraním” si představme metody a funkce, které volá aplikace, a kdy rozhraní na základě volání připraví dotaz nebo dotazy, které provede, a na jejich základě vrátí výsledek kódu aplikace. V případě, že by aplikace volala přímo SQL dotaz, je pak možné udělat i určitý překladač do jiného dialektu, pokud je to potřeba. Pokud ale aplikace pracuje přímo s ovladačem databázového systému, může být přepsání částí kódu aplikace pro jiný systém velmi náročné, nákladné a může způsobovat mnoho chyb. Pokaždé velmi závisí i na použitém vývojovém prostředí a jakým způsobem v něm provazování dat funguje. Dále je nutné zmínit také problematiku existence určité integrační platformy v rámci celopodnikového informačního systému. V současnosti se takováto řešení obvykle staví na společné datové základně, tzn. na jedné velké databázi. V tomto případě prakticky nemá smysl uvažovat o použití nějakého jiného řešení datové základny. Taková úvaha je na místě tehdy, když se do integrace teprve pouštíme. V tu chvíli máme k dispozici několik aplikací řídících například výrobu, skladování a objednávkový systém pro klienty. Pokud jsou to jako v tomto modelovém případě 3 nezávislé aplikace, které pracují každá nad svými samostatnými daty, dopouštíme se poměrně velmi neefektivního řízení. Jakmile je potřeba data mezi aplikacemi nějakým způsobem sjednotit, nejjednodušším způsobem je import a export dat mezi jednotlivými aplikacemi prostřednictvím dohodnutého datového formátu (v současnosti i v pohledu do budoucna je nejvhodnější použít formát XML pro jeho univerzálnost, možnost jednoduché kontroly validity a hlavně přenositelnosti mezi aplikacemi třeba i prostřednictvím XSL Transformace) nebo prostřednictvím sdílené databáze, kde je vše online a bez nutnosti další synchronizace. První volba je, nejde-li o skutečně triviální aplikace, obvykle nejjednodušší a vzhledem k implementaci oproti variantě druhé jak časově, tak i nákladově o mnoho výhodnější. V druhém případě, kdy je potřeba integrovat jednotlivé dílčí systémy do jednoho, je to hlavně o optimalizaci doby do zavedení hotového systému. Nemusí být pravdou, že aplikace obsahující nejvíce dat musí být nutně nejsložitější, a tedy že by integrovaná datová základna měla vycházet z jejích základů pro usnadnění transformace všech dílčích systémů. Ještě před výběrem datové platformy pro integraci je potřeba provést analýzu závislosti aplikace na daném databázovém systému. Dále je třeba zmínit i řešení v rámci podnikové sběrnice (Enterprise Service Bus), kdy je možné propojit několik databází do jednoho systému a jednotlivé komponenty komunikující s databázemi koncipovat jako služby. Pak aplikace ani nemusí rozeznat, s jakým typem databázového systému vůbec komunikuje. Nicméně otázka servisně orientované architektury (SOA - Service Oriented Architecture) není předmětem této práce. 27
6.2.3 Autentizace uživatelů V době stále masivnějšího rozvoje Internetu je otázka bezpečnosti, potažmo autentizace uživatelů pro přístup k důvěrným datům jednou z nejdůležitějších částí systému. Velmi záleží na tom, jakým způsobem má ověřování v rámci aplikace fungovat, zda-li má být na úrovni databáze, aplikace, přímo operačního systému, nebo jestli má být kombinované. Tato problematika souvisí i s licenčními politikami výrobců databázových systémů, protože různé úrovně licence mohou zpřístupňovat třeba jen určitý počet současně připojených uživatelů. Ověřování na úrovni databáze má hlavní výhody v tom, že při správné bezpečnostní politice není možné, aby se uživatel aplikace dostal k datům, na které ze své úrovně uživatelského přístupu nemá právo, a to ani v případě chyby v aplikaci, a hlavně je možné v rámci auditu databáze zjistit, zda je skutečně bezpečnostní politika správně dodržována. Tyto záležitosti se dají řešit i v aplikaci, která k databázi přistupuje pouze pod jedním nebo několika uživatelskými přístupy, nicméně to snižuje vypovídající hodnotu získaných dat a bez dalších informací ukládaných do databáze přímo aplikací zpravidla nejsme schopni zjistit, kdo kdy data četl, případně ukládal. V tomto případě platí, že čím vyššího zabezpečení dat chceme dosáhnout, tím vyšší granularitu přístupových práv a autentizaci blíže datům potřebujeme. U mnoha jednoduchých aplikací, zejména webových, obvykle přístup k datům obsluhuje pouze jedno uživatelské jméno a oprávnění pro přístup k datům a informace o změnách řídí pouze sama aplikace. Toto řešení je potenciálně rizikovější už kvůli možným bezpečnostním dírám aplikací, k nimž jsou zpravidla náchylnější než databázové systémy, a tak může nastat problém, kdy se někdo k databázi přihlásí mimo aplikaci a získá tím možnost operovat prakticky se všemi daty systému. V některých případech se používají různé kombinace zabezpečení společně s ověřováním na úrovni operačního systému nebo různých klientských certifikátů. Pak záleží, zda jsou informace o uživatelích v síti synchronizována přímo s databází uživatelů databáze s jim přiřazenými právy podle skupin nebo rolí, nebo je to řešeno na úrovni aplikace, a to částečně nebo zcela.
6.2.4 Licenční politiky výrobců databázových systémů V současnosti je většina databázových systémů nabízena formou placené licence a rozdíly v cenách jednotlivých verzí/edicí mohou být od výrobce k výrobci i výrazně rozdílné. Poslední dobou, kdy si svoje pevné místo začínají vydobývat i open-source databázové systémy, sílí tlak na velké výrobce proprietárních řešení, a tak se začínají i v jejich nabídkách objevovat licence za velmi slušných cenových podmínek, i když s poměrně omezenými možnostmi. Během fáze výběru databázového systému pro novou aplikaci je zvážení licenčních podmínek obzvláště důležité, je nutné uvažovat do budoucna, a to jakým způsobem a jak dlouho bude aplikace udržována, jak často se bude rozšiřovat a do jaké míry bude narůstat pravděpodobný počet uživatelů. Při nevhodném výběru se pak náklady na rozšiřování v budoucnu mohou poměrně hodně prodražit. Většina proprietárních databázových systémů totiž licencuje své produkty mimo jiné i na počet současně 28
otevřených spojení a v některých případech i na maximální velikost datových souborů, a při budoucím rozšíření aplikace spolu se zvýšením počtu uživatelů to může vést například k překročení počtu požadovaných současných spojení nebo překročení velikosti datových souborů. V opačném případě zase může dojít k tomu, že máme drahou licenci na software, který nedokážeme využít. Další možná omezení týkající se licencování je pro ilustraci možné nalézt v kapitole 3 v přehledu mnou vybraných databázových systémů pro tuto práci, avšak s tímto způsobem prodeje licencí je možné se setkat prakticky i u všech proprietárních systémů. Volba databázového stroje závisí ale i na hardware serveru, na kterém bude databázový systém běžet. V rámci jednotlivých úrovní licence totiž nejde jen o “měkké” prvky jako je omezení počtu současně otevřených spojení nebo maximální velikosti datových souborů. Jde například i o možnost využití pouze části operační paměti nebo počtu procesorů, které může systém v jednom okamžiku použít. Licencování na počet procesorů je v dnešní době vícejaderných procesorů poměrně ožehavé téma, někdy se vícejaderné procesory počítají podle počtu jader a někdy čistě podle počtu čipů (Intel Core2 Quad - 1 čip, 4 jádra). Někdy také závisí i na výrobci procesoru a někdy se “počet procesorů” počítá i podle různých koeficientů, záleží na výrobci databázového systému. Volba licence databázového systému by tedy měla jít ruku v ruce s koupí hardware, na němž bude systém nainstalován. Na druhou stranu ale existují i výše zmíněné open-source databázové systémy, u nichž do takové míry licenční podmínky řešit nemusíme, snad jen v případě, provádíme-li úpravy do původního kódu dané databáze. Prakticky všechny takové systémy jsou šířeny v rámci GNU licence, kdy každý musí v případě, že provedl nějaké změny do původního kódu, uvedené změny publikovat a změny dát i ostatním volně k dispozici pro možnost dalšího bezplatného použití a modifikací.
6.2.5 Použití transakcí Při návrhu celého systému je velmi důležité si položit otázku, zda je potřeba transakční model použít či ne. Je nutné si uvědomit, že při použití transakcí na serveru běží mnoho operací, které různě operují s daty, ukládají je a že tyto operace výkon databázového serveru “něco stojí”. Jsou samozřejmě aplikace, kde je prakticky nemyslitelné, aby transakce použity nebyly (finance, pojišťovnictví, obchod, medicína,…), ale jsou i další projekty (informační portály, CMS systémy, jednoduché webové aplikace), kde by se transakce mohly hodit jen v několika málo případech. Obecně jsou to systémy, v nichž jde hlavně o čtení dat, a kde je ochrana dat pro zápis z hlediska konzistence velmi malý nebo dokonce žádný problém jednoduše zajistitelný aplikací, a hlavně kde na základě zpracování aplikace jsou transakce bez využití další podpory transakčního zpracování prakticky neřešitelné. Jestliže použijeme databázi bez zapnutých transakcí, může práce s ní být o mnoho rychlejší a může to znamenat nižší potenciální náklady na hardware databázového serveru, nebo by bylo možné na jednom serveru provozovat až desítky podobných aplikací a tím výrazně ušetřit. Navíc jsou data daleko méně zamykána, což dostupnost dat v jistých případech velmi zvyšuje za velmi malou cenu nižších možností zajištění konzistence dat na úrovni databáze. Na druhou stranu je problém s dostupností dat při transakčním zpracování možná problémem architektury databáze nebo chybně zvolené 29
úrovně izolovanosti transakcí. Při návrhu je vždy potřeba brát v potaz možnost současného zápisu několika osob současně do jedné datové struktury, tyto věci je pak nutné řešit na úrovni aplikace. Obvykle se dělají různé obdoby zamykání dat. Pokud je ale potřeba s daty operovat primárně i jinak, než pro čtení nebo pouze pro jednoduché zápisy, stávají se struktury i data složitější a jednotlivé operace už se mohou skládat z několika různých dotazů, respektive datových operací. V tom případě kdyby v jednom nastala chyba nebo by bylo spojení s databází nečekaně přerušeno, mohlo by to mít za následek nekonzistenci dat. Aplikace, která by transakce nepoužívala, by musela být napsaná tak, aby k takovým problémům nemohlo dojít, což jde ve výše uvedených případech jen velmi těžko. Navíc když si uvědomíme, že v současnosti je velké procento těch jednodušších aplikací vytvářeno pomocí různých skriptovacích jazyků na straně serveru, nastává také problém toho, že spojení s databází je ukončeno vždy hned po doběhnutí skriptu. V některých situacích jsou například jinak velmi užitečné zámky nad daty v rámci transakce v tomto případě prakticky nepoužitelné za předpokladu, že není využit nějaký middleware, transakční monitor, který dokáže podobné problémy obejít.
6.3 Návrh řešení pro modelové situace 6.3.1 Existence stávajících dat a jejich případná migrace Tato subkapitola je rozdělena do čtyř základních částí, týkajících se původu a typu již existujících dat: 1. Jednoduchá data pro import. 2. Data ve formátu XML. 3. Data v existujícím DBMS (rozšíření databáze). 4. Data v existujícím DBMS a migrace na jiný DBMS. Vytvoření nové databáze spolu s importem jinde uložených dat je ideální způsob, který může ve finále způsobit vůbec nejmenší možné problémy (viz tab. 6.1). Je velké množství různých cest, jak data do databáze dostat, od různých jednoduchých textových souborů s oddělovači (CSV - Comma Separated Values, a obdobné), přes různé další formáty a převaděče až po univerzální formát XML (viz tab. 6.2), které většina dnešních databázových systémů již umí používat, nebo se dá pomocí transformace vyrobit de facto výpis databáze popsaný DML příkazy.
30
1. Jednoduchá data pro import (CSV, text, … ) Jednoduchý převod dat do datových struktur na úrovni DBMS obvykle prostřednictvím vestavěných utilit nebo dalších programů. Výhody
Nevýhody
Doporučení
• Data lze naimportovat prakticky do jakéhokoliv datového modelu. • V podstatě nezávisí na vybraném databázovém systému.
• V některých případech může nastat složitější úprava dat do formátu DBMS (hlavně datum a čas). • Data jako taková nemusejí zajišťovat integritu.
V tomto případě na vybíraném systému prakticky nezáleží.
Tabulka 6.1: Jednoduchá data pro import
2. Data ve formátu XML Jednoduchý převod dat do datových struktur na úrovni DBMS obvykle prostřednictvím vestavěných utilit nebo dalších programů. Výhody
Nevýhody
Doporučení
• Data lze naimportovat prakticky do jakéhokoliv datového modelu. • V podstatě nezávisí na vybraném databázovém systému.
• V některých případech může nastat složitější úprava dat do formátu DBMS (hlavně datum a čas). • Data jako taková nemusejí zajišťovat integritu.
V tomto případě na vybíraném systému prakticky nezáleží.
Tabulka 6.2: Data ve formátu XML
Problém, kvůli němuž se přechází na novou verzi aplikace, je obvykle buď výkon, nedostačující funkcionalita nebo v případě následné změny databázového systému také kompletní přepsání původní aplikace za použití odlišného vývojového prostředí.
31
3. Data v existujícím DBMS (rozšíření databáze) Aktualizace datového modelu, přidání nových struktur a revize integritních omezení. Výhody
Nevýhody
Doporučení
• Existuje vyzkoušený datový model, podle zkušeností se dá opravit a upravit, aby splňoval nové požadavky • Nižší náklady jak z licenčního, tak i administrativního pohledu. • Stávající aplikace mohou k databázi přistupovat i po jejím upgradu.
• Při úpravě datového modelu jsme limitováni již existujícími strukturami. • Nástavby databáze mohou vést ke snížení efektivního výkonu.
Pokud má projekt za cíl rozšíření funkčnosti stabilního systému s tím, že výrazně neovlivňuje stávající moduly aplikace, byla by změna databázového systému příliš nákladná a výsledek by byl vzhledem k nákladům příliš nejistý.
Tabulka 6.3: Data v existujícím DBMS
Pokud jde o problém související s výkonem, může být problém jak v systému, tak spíše i v chybném návrhu databázových struktur, odkud vyvstává otázka, zda-li vůbec přesun na jinou platformu potíže vyřeší. Nejprve je potřeba prověřit datový model a zjistit, jestli je datový model v pořádku, případně zda je možné struktury přesunout a za jakých nákladů. Dále je nutné mít se na pozoru ohledně různých chování transakcí, což je předmětem poslední subkapitoly této sekce a na další odlišnosti mezi jednotlivými systémy zejména co se týče dialektů jazyka SQL. 4. Data v existujícím DBMS a migrace na jiný DBMS Transformace datových struktur do nového DBMS, použití transformačních nástrojů nebo ručně, viz kapitola 6. Výhody
Nevýhody
Doporučení
• Možnost využití specifických vlastností nového DBMS. • Využití podpory vývojových nástrojů pro nový DBMS.
• V případě absence univerzálního konektoru k DB je nutné přepsat velkou část stávajících aplikací, aby mohly dále fungovat. • Náklady spojené s migrací a nákupem HW, licencí, školení pracovníků.
Databázi migrovat jen v případě, že je to nutné, například kvůli nové aplikaci nebo z licenčních důvodů. Při migraci se mohou objevit i závažné problémy, viz kapitola 6.
Tabulka 6.4: Data v existujícím DBMS a migrace
32
6.3.2 Architektura aplikace Existují 2 základní typy způsobu zpracování dat v databázových systémech, a to OLTP (Online Transaction Processing) a OLAP (Online Analytical Processing). Transakční systémy obsahují primární data, která slouží pro řízení běhu podniku, ukazují data vztahující se k danému okamžiku a pracují převážně transakčně. OLTP data jsou „živá”. Analytické systémy jsou ale navrženy pro potřeby analýzy, pracují s nimi obvykle aplikace Business Inteligence. OLAP data jsou obvykle připravovány na základě OLTP dat, kdy se obvykle různá data zjednodušují a agregují (např. počet koupených sportovních, společenských a jiných bot zjednodušíme na jednu kategorii s názvem obuv, pokud je to možné), navíc získávají další rozměr - čas, a tudíž je možné provádět velké množství analýz v rámci abstrakce tzv. multidimenzionální kostky (např. osa x: Čas, osa y: Parametr A, osa z: Parametr B), které by v případě OLTP zpracování nebylo možné nebo výpočetně příliš složité. O OLAP datech se často mluví jako o nástavbě OLTP dat. Dalším specifikem OLAP systémů je to, že narozíl od OLTP systémů, kdy je potřeba data z databáze získat okamžitě pro momentální potřebu uživatele, u OLAP systémů na rychlost zpracování na čas takový důraz kladen není, pracuje se tu s většími objemy dat a data jsou předpřipravena pro analytické použití. V rámci architektury IS/ICT existuje několik různých typů aplikací, kde prakticky každá vytvářená aplikace spadá do alespoň jednoho typu. Jejím jádrem je systém ERP, na které jsou napojeny další systémy pro podporu výroby, zákaznické podpory, dodavatelských řetězců (viz tab. 6.5). Tyto systémy jsou všechny závislé na databázi nebo databázích typu OLTP. Název
Popis
ERP (Enterprise Resource Planning)
Jádro IS/ICT firmy jako takové, řeší nákup, prodej, skladování, výrobu, finance, controlling a zdroje.
CRM (Customer Relationship Management)
Orientace na zákazníka, podpora a technické zázemí kontaktních center, elektronického obchodování a marketing.
SCM (Supply Chain Management)
Zefektivnění komunikace s dodavateli, snížení skladovacích nákladů, efektivnější výroba.
Tabulka 6.5: Přehled aplikací obvykle řešených pomocí OLTP
Nad tyto části systému bývá zařazována skupina analytických aplikací týkajících se business intelligence a na rozdíl od OLTP dat, která jsou určena pro provoz a obsahují detailní neredundantní informace, v zájmu rychlosti zobrazení výsledků vykazují určitá zjednodušení (např. již výše zmíněné slučování parametrů) a redundance dat pro významné urychlení bez nutnosti zásadního zkreslení. Takovým datům ale také déle trvá, než mohou být připraveny pro provoz.
33
Název
Popis
DWH (Data Warehouse, datový sklad)
Obvykle transformovaná a zjednodušená data relačního charakteru (ROLAP), pro uživatele pouze pro čtení, žádná data v nich nevznikají. Slouží pro potřeby vrcholového až středního managementu.
Data mart (Datové tržiště)
Jsou obdobou datových skladů, jen jsou dedikované pro určitou oblast, zejména geografickou, integrací několika datových tržišť vznikne jeden velký datový sklad.
Tabulka 6.6: Přehled aplikací obvykle řešených pomocí OLAP
Existuje mnoho testů, z nichž je možné vyčíst výkonnost v dané oblasti, proto je vhodné zvolit, do jaké kategorie zkoumaný projekt patří. V rámci výběru databáze je také potřeba brát v úvahu, jestli jde o typový aplikační software, kde východiskem projektu je customizace již hotového systému, zda existuje možnost výběru a jestli je potřeba data využívat i v jiných aplikacích, případně existuje-li určitá míra integrace mezi aplikacemi ať už za použití nějakého integračního middleware nebo nikoliv, například má-li být funkcionalita aplikace součástí nějakého portálu.
6.3.3 Autentizace uživatelů Existuje několik druhů autentizace uživatelů přistupujících k databázi. Hodně záleží na povaze vyvíjené aplikace, například informační portály nebo jednodušší webové aplikace obvykle mívají pouze jeden přístup do databáze, ale u složitějších systémů, majících mnoho úrovní přístupů a zabezpečení, se to musí řešit do větší hloubky. Jednotlivé typy způsobu připojení databáze, jimiž se v této kapitole budeme zabývat jsou: 1. Autentizace na úrovni aplikace. 2. Autentizace na úrovni serveru. 3. Autentizace na úrovni databázového systému.
34
1. Autentizace na úrovni aplikace Výhody
Nevýhody
Doporučení
• Pokud je na serveru více databází, snižuje se riziko nedovoleného průniku pouze na aktivní databázi. • Aplikace může spravovat přístupy nezávisle na systému.
• Pro možnost auditu databáze je nutné, aby to aplikace umožňovala, je-li potřeba audit do vyšší hloubky. • V aplikaci musejí být přístupy velmi dobře ošetřeny, protože aplikace má stejná oprávnění vůči DB na jakékoliv úrovni uživatelských oprávnění.
• Běžně pro různé webové aplikace na Internetu, kterých je na serveru více a jejichž správce bývá někdo jiný, než provozovatel. Údržba takových systémů je méně náročná a přesun celé aplikace na server s obdobnou softwarovou konfigurací je velmi jednoduchý. • V případě možnosti, že by v budoucnu aplikace využívala jiný DBMS, je kvůli odlišnostem v řízení přístupů mezi jednotlivými databázovými systémy záruka fungování. Celkově lze říci, že má-li aplikace fungovat s autentizací na úrovni aplikace, nemá to zásadní vliv na volbu databázového systému.
Tabulka 6.7: Autentizace na úrovni aplikace
V případě, že je nutné autentizaci provádět pomocí autentizace operačního systému nebo síťové správy uživatelských oprávnění, je například v případě platformy Windows jediná možnost, a to použití Microsoft SQL Server, protože ten jako jediný s hesly pro přístup do Windows umí přímo pracovat.
35
2. Autentizace na úrovni serveru Výhody
Nevýhody
Doporučení
• Aplikace mohou používat sdílenou databázi přístupů, což umožňuje efektivnější řízení oprávnění v rámci celé firmy • Aplikace mohou používat autentizaci přímo na úrovni operačního systému • Je možné používat různé výhody zabezpečení, jako SSL klientské certifikáty, apod., i když to databázový systém sám nepodporuje, navíc je možné přístup k databázi omezit jen na už autentizované uživatele, což znamená další zabezpečení dat
• Aplikace tohoto druhu jsou co se týče správy přístupů nejsložitější, protože aplikace musí využívat možností operačního systému nebo jiných aplikací • V případě, že nastane chyba v autentizačním systému, obvykle to má za následek výpadek několika aplikací najednou
• Tímto způsobem je možné velmi dobře zajistit zabezpečení firemních dat, správa přístupů je v celé firmě na jednom místě, tudíž se neobjeví například problémy s bývalými zaměstnanci V tomto případě už ale výběr databázového systému hraje velkou roli. Záleží na způsobu, jakým jsou ukládány přístupové informace, jsouli například uložené v databázi operačního systému, je nutné zjistit, zda DBMS dokáže s takovou databází pracovat a jakým způsobem, případně jestli je potřeba autentizaci řešit současně i na úrovni aplikace. Tento způsob obvykle funguje v kombinaci s jednou z ostatních uvedených možností.
Tabulka 6.8: Autentizace na úrovni serveru
Existují ale také způsoby jak synchronizovat například databázi Oracle se správou hesel v síti Microsoft Windows nebo se dá aplikace zabezpečit na úrovni aplikace. Jinak ale všechny výše zmíněné databázové systémy umožňují samostatnou správu hesel a přístupů. 3. Autentizace na úrovni databázového systému Výhody
Nevýhody
Doporučení
• Jsou-li správně nastavené bezpečnostní politiky systému, nemá pak uživatel možnost upravit nebo číst data, ke kterým nemá přímé oprávnění • Pokud DBMS umožňuje audit, dá se zjistit prakticky jakákoliv operace v systému bez nutnosti použití nějakého modulu aplikace
• Spravovat vyšší množství uživatelů v systémů je obtížnější • Uživatel má přístup k datům i přímo bez aplikace
Pomocí tohoto způsobu je možné prakticky bez obav řešit různé uživatelské role v rámci aplikace, DBMS zajistí, že neoprávněný uživatel se k jemu nepřístupným datům nemůže dostat ani v případě, že by nastala chyba v aplikaci nebo kdekoliv jinde. V případě, že je databázový server dedikován pro danou aplikaci, je to ideální způsob, jak řešit zabezpečení i audit.
Tabulka 6.9: Autentizace na úrovni databázového systému
36
6.3.4 Licenční politiky výrobců databázových systémů Jak bylo již zmíněno v kapitole 6.2.4, výrobci nabízejí širokou škálu úrovní licencování svých produktů. U mnou uvedených databázových systémů jsem v přehledu uvedl i jednotlivé licenční edice, viz kapitola 3. Za zmínku ale stojí i systémy, které jsou zpravidla poskytovány bezplatně na základě licence GNU GPL, nicméně pouze do chvíle, dokud nebyly provedeny změny v kódu, které nebyly dále publikované, což se ale příliš často nestává, a pokud ano, tak jsou obvykle takové licence i tak o poznání levnější než licence placených systémů. Donedávna byl poněkud problém využívat služeb proprietárních databázových systémů, pokud nebylo k dispozici dostatečné množství finančních prostředků z důvodu nepoměrně vysokých nákladů oproti open-source řešením. Pak přišly tzv. Express verze nebo také edice (obou mnou uváděných proprietárních systémů), které nabízejí základní funkcionalitu zcela zdarma (co znamená ona “základní funkcionalita” najdete v kapitole 3 u příslušných databází). V rámci těchto řešení se také může objevit problém s odhadem rozsahu databáze. U Express verzí je to patrně nejznatelnější, protože ve chvíli, kdy celou aplikaci postavíte na určité databázi a najednou zjistíte, že v ní dochází volné místo, je nutné rychle zakročit, a v daný moment je nákup licence obvykle tím nejšetrnějším opatřením. Zdá se, že volba nové možnosti Express edice je velmi výhodná, nicméně vždy je nutné nést riziko budoucích nákladů na rozšíření licence, což v některých případech nemusí přicházet v úvahu, a je vybráno jiné, například opensource řešení.
37
Úroveň licence
Popis
Doporučení
Enterprise
Nejobsáhlejší verze, prakticky nelimitovaná.
Použití pro velké systémy, kde je nutné zajistit co nejvyšší dostupnost, které jsou velmi zatížené a data v nich náročná na zpracování.
Standard
Limitovaná verze, kterou lze obvykle rozšířit.
Verze tohoto typu jsou obvykle limitovány počtem současně připojených uživatelů, počtu současně využitých procesorů, apod. Nicméně v rámci licence se určitá omezení dají obejít dokoupením uživatelů, procesorů,… Použití pro větší systémy, kde je výkon a stabilita důležitá.
Express
Odlehčená velmi limitovaná verze, je zdarma.
Tyto verze umožňují v omezeném měřítku využít funkce proprietárních DBMS bez licenčních poplatků. Nehodí se ale pro aplikace, které se do budoucna budou objemem dat výrazně zvětšovat, nebo na které bude kladen nárok na rychlost zpracování. Před použitím této verze je nutné zvážit dopady budoucího rozvoje aplikace a případné náklady na nákup méně omezující licence.
GNU
DBMS je šířen jako otevřený software, je zdarma.
Jsou to databázové systémy pracující prakticky bez omezení, je možné je nasazovat v libovolných podmínkách. V některých hlediscích nedosahují rychlosti, stability ani funkcionality jako některé proprietární databáze, ale v některých situacích je nasazení jednoduchosti velkým přínosem i co se týče rychlosti zpracování a výkonu, jako třeba v případě čistě netransakčního zpracování.
Tabulka 6.10: Typy licencí databázových systémů
6.3.5 Použití transakcí Všechny tři mnou uvedené databázové systémy transakce podporují, což platí obecně i u drtivé většiny ostatních. Nicméně například MySQL je při použití netransakčního režimu prostřednictvím datového formátu MyISAM velmi výkonné, a to za velmi přijatelnou cenu, respektive zdarma. Avšak je-li potřeba transakce použít a jde-li o velmi zatíženou a velkou databázi, je nutné volit jinak. Při transakčním zpracování je velmi důležité vědět, kdy a jak jsou během provádění transakcí data, se kterými jednotlivé transakce operují, zamykána, a jestli jde o zámek pro sdílení (shared lock) nebo pro výlučné použití (exclusive lock). Celkově je důležité vědět, jakým způsobem databázový systém data zamyká, na jaké úrovni a kolik úrovní 38
zamykání podporuje. Některé databázové systémy například umožňují zamykání dat na úrovni záznamu, ale v případě, že je na datech tabulky příliš mnoho takových zámků, provede se tzv. eskalace zámků a dojde k zamčení dat už na úrovni tabulky. Dále je také potřeba vědět, že čím vyšší je rychlost transakcí, tím nižší je úroveň izolovanosti, a to v sobě skýtá určité problémy s nekonzistencí přečtených nebo zapsaných dat - tzv.:
špinavá čtení (dirty reads) jsou data přečtená “naší” transakcí, u nichž je problém v tom, že jsou upravené nebo vložené jinou probíhající transakcí, která prozatím neprovedla jejich COMMIT, tudíž data nejsou stoprocentně konzistentní.
neopakovatelná čtení (nonrepeatable reads) zase způsobují, že v rámci jedné transakce mohou dva stejné dotazy za sebou obsahovat jiné výsledky u těch, které už načteny byly, tedy po operaci UPDATE nebo DELETE a byl u nich úspěšně provedený COMMIT.
skrytá čtení (Phantom reads) jsou obdobou neopakovatelných čtení, avšak jde o úpravy v rámci příkazu INSERT. Jde o nová data, ne data upravená, tudíž při opakovaném provedení dotazu je navráceno více řádků vyhovujících stejným podmínkám, než u předešlého. Jde tedy o to, že čím je vyšší je míra izolovanosti, tím více zámků musí systém vytvořit a tím vyšší pravděpodobnost čekání na uvolnění nějakého zámku je. Obecně platí, že čím více zápisů do tabulek během transakcí se provádí, tím nižší úroveň izolovanosti je vhodné použít.
Existuje pět úrovní izolovanosti jednotlivých transakcí, které jsou porovnány v tabulce 6.10. Úroveň read uncommitted umožňuje ostatním transakcím získávat i data, která doposud nebyla komitována, takže vždy zobrazuje aktuální stav databáze, u read commited je aktuálnost databáze omezena na data, která byla komitována před spuštěním dotazu. V případě použití repeatable read jsou při provádění příkazu SELECT uvalovány na dotyčná data sdílené zámky a při UPDATE nebo INSERT jsou data uzamčena exkluzivně a zámky se odblokují až po provedení operace COMMIT nebo ROLLBACK. Izolovanost Snapshot spočívá v tom, že data, s nimiž se v rámci transakce operuje, jsou pouze ta, která byla již od počátku transakce komitovaná, tedy transakce se chová, jakoby data byla stále ve stavu spuštění transakce s výjimkou těch úprav, které provedla sama transakce a její COMMIT je možné provést pouze v případě, že v průběhu transakce v operovaných datech nedošlo zvenku ke změnám. Rozdíl mezi snapshotem a serializable je v tom, že při použití izolovanosti serializable jsou uvaleny exkluzivní zámky na všechna zúčastněná data.
39
Úroveň izolovanosti
Špinavá čtení
Neopakovatelná čtení
Skrytá čtení
ano
Při použití této úrovně izolace je nutné, aby prakticky všechny možné konflikty, pramenící z úprav stejných dat několika transakcemi, byly ošetřeny na úrovni aplikace, nicméně umožňuje vemi nízké provozní náklady a velkou rychlost bez zamykání dat.
ano
Zámky pro čtení jsou uvalovány pouze na data již upravená jinou transakcí, tudíž je možné, že v průběhu transakce se některá data mohou změnit, nejvhodnější ochrana je plánování průběhu jednotlivých transakcí, aby šly po sobě, ne současně.
ano
Zámky pro čtení jsou v tomto případě uvalovány i v případě výběru dat, tudíž není možné během běžící transakce jí použitá data ovlivnit, absence zámků rozsahu ale může způsobit skrytá čtení, tudíž by se v tomto případě měla zajistit kontrola výběrů z rozsahu hodnot, případně oddělit fáze vkládání a čtení/úprav dat.
ne
Použití této úrovně má smysl v případě, že dané transakce budou probíhat buď samostatně a řízeně nebo v dobách klidu, transakce operuje s obrazem databáze ve chvíli započetí transakce, nejsou uvalovány zámky, tudíž umožňují bezproblémový běh zbytku systému, nicméně při jakékoliv změně v její množině dat není možné transakci komitovat.
ne
Případ veškerého zablokování úprav dat, s nimiž transakce pracuje, je třeba jejich průběh co nejvíce zkrátit, 1 transakce blokuje prakticky celý system.
Read uncommitted ano
ano
Read committed ne
ano
Repeatable read
ne
ne
Snapshot
ne
ne
Serializable ne
ne
Doporučení
Tabulka 6.11: Typy izolovanosti transakcí
I když databázové systémy transakce podporují, v leckterých případech se při jejich zpracování chovají odlišně (viz tab. 6.12), protože různé systémy považují za výchozí úroveň izolovanosti jednotlivých transakcí od sebe úroveň jinou. Pro každý systém je třeba předem zjistit, jak se při konkurenčním zpracováním transakcí chová a jaké jsou možnosti přepínání mezi úrovněmi izolovanosti transakcí.
40
Úroveň izolovanosti
Oracle Database
Read uncommitted
Snapshot Serializable
MySQL Server
-
ano
ano
výchozí
výchozí, dá se upravit možnost čekání na ostatní transakce
ano
-
ano
výchozí
odpovídá “serializable”
ano
-
chová se jako “snapshot”
ano
ano
Read committed
Repeatable read
Microsoft SQL Server
Tabulka 6.12: Rozdíly zpracování transakcí u vybraných DBMS
V některých případech jsou s transakcemi spojené další problémy, ne všechny databázové systémy dokáží pracovat samy, například v rámci distribuovaného prostředí nebo aplikace psané v jednodušších skriptovacích jazycích nedokáží udržet spuštěnou transakci při ukončení běhu skriptu, protože s jeho ukončením se automaticky uzavře i spojení s databází, a to včetně transakce. Je to dáno povahou těchto systémů a uzavíráním spojení po doběhnutí skriptu a nesouvisí to s možností HTTP hlaviček pro zachování otevřeného spojení. Pro tyto druhy omezení existují middleware, transakční monitory, platformy pro správu transakcí. V některých případech ale možnost použití nějakého middleware padá, zejména v projektech s nižším rozpočtem. Tabulka 6.13 ukazuje srovnání použití transakčního zpracování a zpracování bez nich.
41
Typ aplikace
Výhody
Nevýhody
Doporučení
Bez transakcí
• Značné zrychlení zpracování. • Univerzální datový model, lze použít prakticky na jakékoliv DB • Databáze je velmi jednoduchá.
• Kontrola integrity se musí kontrolovat i na úrovni aplikace, při přístupu mimo aplikaci může být porušena integrita dat. • Kbvykle zamykání na úrovni celého objektu pro zápis.
• Netransakční zpracování se hodí většinou pro jednodušší, převážně webové aplikace, kde je potřeba hlídat nároky na vytíženost DBMS kvůli mnoha aplikacím běžícím na jednom serveru. • Tyto aplikace by měly používat převážně čtení dat.
Transakční
• Velká část aplikace týkající se integrity běží na databázi. • Při připojení jakéhokoliv klienta k DB není možné zadat nekonzistentní data. • Při zpracování posloupnosti několika příkazů je nutné, aby všechny proběhly v pořádku, jinak se databáze vrátí do stavu před započetím transakce. • Zamykání většinou na úrovni záznamu.
• Problém hlavně s výkonností může nastat při nesprávné volbě úrovně izolovanosti (viz výše). • Při migraci mezi jinými DBMS může dojít k tomu, že se při shodné úrovni izolovanosti transakcí každý systém chová odlišně.
• Tam, kde je potřeba častých zápisů do databáze nebo je třeba některé aktivity rozdělit do posloupnosti několika DML příkazů, je transakční zpracování velmi důležité. • V případě, že databáze prakticky pouze data čte a zobrazuje nebo jsou vkládání a úprava dat velmi jednoduché, způsobuje transakční zpracování vyšší hardwarové i finanční nároky.
Tabulka 6.13: Srovnání transakčního a netransakčního zpracování
Na závěr je potřeba zdůraznit, že co se týče transakcí v databázových systémech, bývá někdy lépe méně než více, a to z důvodu náročnosti zamykání mnoha řádků v tabulkách a také čekání jednotlivých transakcí na uvolnění zámku, aby mohly pokračovat dále. Ještě jednou tedy uvádím, že čím více v rámci transakcí provádíme úprav a vkládání, tím nižší stupeň izolovanosti by měl být použit, pokud je to možné. Z tohoto přehledu je zřejmé, že způsobů zpracování transakcí je velké množství a není možné spoléhat na to, že si vybraný databázový systém s transakcemi poradí přesně podle našich požadavků, je potřeba to zohlednit ještě ve velmi časné fázi přípravy projektu. [ORA6, MSS6, MYS2, BAS1, POU1]
42
6.4 Shrnutí Níže uvedená tabulka 6.14 znázorňuje závislost parametrů diskutovaných v předchozích částech této kapitoly na jednotlivých skupinách typů projektů IS/ICT. Rozdělení do typů projektů vychází především z podkapitoly 6.3.2, kde jsou rozlišeny databázové aplikace ve způsobu zpracování (OLTP/OLAP). Tento výčet je rozšířen ještě o skupinu databázových aplikací, do které spadají různé jednodušší redakční systémy, portály a další obdobné webové aplikace, u nichž je kladen důraz na nižší cenu, dobu zpracování apod. Co se týče výkonu a dostupnosti systému, je nutné brát v úvahu, že takový systém obvykle kvalitativních hodnot ostatních skupin projektů nedosahuje. Nicméně v mnoha případech je právě takové řešení vhodnější, tudíž je potřeba ho zde uvést. Tabulka umožňuje porovnání jednotlivých parametrů pomocí uvedeného krátkého shrnutí s odkazem na část práce, kde je daná problematika řešena obsáhleji. Další informace o daných tématech se prolínají celou prací, nicméně hlavní části sdělení se vyskytují na daných místech označených čísly stránek v tabulce.
Kritérium / parametr
Stránka
Jednodušší informační portály a webové aplikace
Podnikové informační systémy (ERP, CRM, SCM,…)
Business Intelligence aplikace, DWH (OLAP)
Čtení / zápisy dat
33-34
Hlavně čtení
Mnoho zápisů i čtení
Pouze čtení
Transakce
38-42
Ne, mohou být, ale zvyšují náklady na licenci i provoz hardware.
Ano, důležité pro zachování konzistence dat.
Ne, v aplikacích tohoto typu nemají smysl.
Import dat z textu, CSV, ...
30-31
Obvykle, pracuje na jednoduchém principu transformace dat.
Málokdy, záleží na typu stávajících systémů, většinou se používá pokročilejší úroveň migrace.
Ne ve smyslu importu pro živý provoz dat, pouze pro analytické užití.
43
Kritérium / parametr
Stránka
Jednodušší informační portály a webové aplikace
Podnikové informační systémy (ERP, CRM, SCM,…)
Business Intelligence aplikace, DWH (OLAP)
Existující DBMS, rozšíření nebo migrace dat na jiný DBMS
31-32
Často rozšíření stávající databáze, použití jiného DBMS zřídka z hlediska nákladů, většinou jde o open-source.
Většinou rozšíření, svou roli ale hraje i optimalizace výkonu, a tedy migrace nebo zavedení nového systému.
Ne ve smyslu importu pro živý provoz dat, pouze pro analytické užití.
Import dat ve formátu XML
30-31
Časté napojení na další nezávislé systémy, nejjednodušší způsob komunikace pro opakovanou synchronizaci.
V rámci napojení jiných aplikací, často opakovaná synchronizace a standardizované formáty.
Ne ve smyslu importu pro živý provoz dat, pouze pro analytické užití.
Nová aplikace
26-27
Často typové aplikace, zpravidla opensource, kastomizace implementátorem, ne vývojáři, velká škálovatelnost, nízké náklady.
Často typové aplikace kastomizované přímo výrobcem, je to spolehlivější než samostatný vývoj – méně chyb, ale nižší flexibilita oproti plnému zakázkovému řešení.
Často typové aplikace kastomizované přímo výrobcem, je to spolehlivější než samostatný vývoj – méně chyb, ale nižší flexibilita oproti plnému zakázkovému řešení.
Transformace původní aplikace
26-27
Spíše nová aplikace a převod dat, v tomto případě také závisí na množství úprav provedených v aplikaci na úrovni implementátora.
Většinou, z hlediska nákladů a potenciální úspěšnosti projektu je výhodnější upravovat stávající aplikaci.
Většinou, z hlediska nákladů a potenciální úspěšnosti projektu je výhodnější upravovat stávající aplikaci.
Integrace aplikace v rámci většího systému
26-27
V rámci integrační platformy s využitím jiných podnikových DB.
Záleží na integrační platformě a jejím použitím v rámci systému.
V rámci integrační platformy s využitím jiných podnikových DB.
Autentizace uživatele na úrovni aplikace
34-35
Většinou, z hlediska nákladů na správu je to nejvýhodnější.
Poskytuje menší komfort pro správu uživatelů v podnikových sítích a odkrývá hrozby s tím spojené.
Možné, ale bezpečnostně rizikovější, což z hlediska citlivosti dat je prakticky nepřijatelné.
Autentizace uživatelů na úrovni serveru
35-36
V případě napojení na vnitřní síť, jinak je to z hlediska správy a bezpečnosti příliš nákladné.
Záleží na DBMS a jeho možnostech spolupráce se systémem, případně integrační platformou.
Některé vyžadují pouze systémovou autentizaci, kontrola přístupu na úrovni operačního systému v těchto případech bývá nejvhodnější.
44
Kritérium / parametr
Jednodušší informační portály a webové aplikace
Podnikové informační systémy (ERP, CRM, SCM,…)
Business Intelligence aplikace, DWH (OLAP)
36
Velká agenda ohledně správy uživatelských účtů, náročné na správu.
Pokud DBMS nepodporuje přímo systémové politiky, často synchronizace se serverem.
Umožňují, je ale nutné zvážit použití systémové politiky sítě / serveru.
Proprietární licence
37-38
Spíše express verze, v případě méně zatížených systémů robustnější systémy tohoto typu postrádají smysl.
Většinou, je nutná technická podpora ze strany poskytovatele DBMS i záruky ochrany dat, vyšší dostupnost, apod.
Většinou, je nutná technická podpora ze strany poskytovatele DBMS i záruky ochrany dat, vyšší dostupnost, apod.
Open – Source licence1
37-38
V drtivé většině případů tato volba vyhovuje požadavkům i na dostupnost a spolehlivost.
Záleží na nákladech, připadnou technickou podporu musí obvykle firma zajišťovat sama.
Záleží na nákladech, připadnou technickou podporu musí obvykle firma zajišťovat sama.
Autentizace uživatelů na úrovni DBMS
Stránka
Tabulka 6.14: Shrnutí kritérií výběru databázového systému
1
V této práci se nezabývám různými druhy licencování open-source databází, protože narozdíl od proprietárních databázových systemů to nemá vliv na funkcionalitu systému.
45
7. Závěry V této práci jsem se pokusil z mé strany pokud možno co nejlépe načrtnout způsob, jakým by se dalo postupovat při výběru databázového systému, máme-li zadání projektu. S postupem času při pronikání do problematiky jsem zjistil, že navrhnout nějaký obecný způsob pro výběr databázového systému v takovémto rozsahu a s přihlédnutím ke značným individuálním specifikám případných zadání je poměrně velmi náročné, kdybych se v delším časovém horizontu snažil vytvořit nějakou podrobnější metodiku, dostával bych se stále hlouběji, až bych vytvořil metodiku pro úplně všechny vytvářené projekty. Některé dílčí modelové situace by se možná daly ohodnotit a seřadit podle důležitosti, ale nepřišlo mi to vhodné, protože u různých projektů mohou být různé váhy a nemusí se to ani vztahovat k povaze dané aplikace. Tudíž se domnívám, že jakákoliv předem určená kvantifikace jednotlivých částí metodiky není možná. Původně se zdálo být jednodušší přesněji definovat postup výběru, nicméně nakonec jsem došel k závěru, že vzhledem k tomu, jaké všechny faktory výběr ovlivňují, je postup řekněme nejednoznačný, tudíž se tato práce dá brát spíše jako sada doporučení, které se dotýká zásadních bodů při výběru a přípravě databáze včetně nástinu problematiky migrace. Podle mého názoru by toto shrnutí informací mohlo přispět k tomu, aby například i vedoucí projektu, kteří se touto problematikou přímo nezabývají, měli jisté povědomí o tom, co výběr vhodného databázového systému obnáší. Pro vývojáře nebo designéra řešícího, kterou platformu vybere, tato práce rozhodně nemůže sloužit jako jednoduchá příručka bez nutnosti dohledávat další informace i jinde, ale spíše jako průvodce problematikou. Při psaní této práce jsem se snažil zaměřit se na to, jakým způsobem bych řešil problém výběru, co je nutné zjistit a jaké informace dát dohromady, aby se dalo rozhodnout, který ze systémů je pro daný projekt optimální. Při psaní jsem využil zkušeností z předchozího studia i jisté praxe v oboru a velmi jsem si rozšířil znalosti této problematiky. Informace, které jsem čerpal z různých zdrojů, jsem se snažil sjednotit, tak aby dávaly smysl, aby nebylo nutné je sáhodlouze hledat, a vše roztřídit do co možná nejlogičtějších celků.
46
8. Zdroje 8.1 Tištěné zdroje [ORA4] Loney K., Bryla B, Mistrovství v Oracle Database 10g, 1. vydání, Brno: Computer Press 2006, s. 38-39, 49, ISBN 80-251-1277-2 [ORA5] Loney K., Bryla B, Mistrovství v Oracle Database 10g, 1. vydání, Brno: Computer Press 2006, s. 72-73, 49, ISBN 80-251-1277-2 [MSS2] Beauchemin B., Berglund N., Sullivan D., A First Look at SQL Server 2005 for Developers, 1. vydání, Boston: Pearson Education 2004, s. 53-54, ISBN 0-321-18059-3 [MSS3] Beauchemin B., Berglund N., Sullivan D., A First Look at SQL Server 2005 for Developers, 1. vydání, Boston: Pearson Education 2004, s. 459-480, ISBN 0-32118059-3 [MSS4] Beauchemin B., Berglund N., Sullivan D., A First Look at SQL Server 2005 for Developers, 1. vydání, Boston: Pearson Education 2004, s. 19-20, ISBN 0-321-18059-3 [VIS1] Vývoj informačních systémů (pracovní sešit ke cvičením), Chlapek D., Řepa V., Stanovská I., 1. vydání, Praha: Oeconomica 2005, s. 109-111, ISBN 80-245-0977-6 [BAS1] Podnikové informační systémy, Basl J., Blažíček R., 2. výrazně přepracované a rozšířené vydání, Praha: Grada Publishing, a.s. 2008, s. 52 - 105, ISBN 978-80-2472279-5 [POU1] Informační systémy a elektronické podnikání, Pour J. a kol., 1. vydání, Praha: Ediční oddělení VŠE Praha, s. 46 - 83, ISBN 80-245-0227-5
8.2 Elektronické zdroje [WIK1] Database - Wikipedia, the free encyclopedia, online: http://en.wikipedia.org/wiki/Database [MAN1] Teorie relačních databází: Relační model dat, online: http://www.manualy.net/article.php?articleID=9 [WIK2] SQL - Wikipedie, otevřená encyklopedie, online: http://cs.wikipedia.org/wiki/SQL [ORA1] Oracle Database Preinstalation Requirements, online: http://download.oracle.com/docs/cd/B28359_01/install.111/b32002/pre_install.htm 47
[ORA2] Oracle Database Preinstalation Requirements, online: http://download.oracle.com/docs/cd/B28359_01/install.111/b32006/reqs.htm [ORA3] Database 11g | Oracle Database 11g | Oracle, online: http://www.oracle.com/database/index.html [ORA6] Data Concurrency and Consistency, online: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/consist.htm [ORA7] Oracle Database Documentation, online: http://www.oracle.com/technology/documentation/database.html [ORA8] Migration Technology Center, online: http://www.oracle.com/technology/tech/migration/index.hml [MSS1] Micrsoft SQL Server: System Requirements, online: http://www.microsoft.com/sql/prodinfo/sysreqs/default.mspx [MSS5] Microsoft SQL Server Editions and Pricing, online: http://www.microsoft.com/sql/howtobuy/editionspricing.mspx [MSS6] SET TRANSACTION ISOLATION LEVEL (Transact-SQL), online: http://msdn.microsoft.com/en-us/library/ms173763.aspx [MSS7] Download Details: SQL Server 2005 Books Online (September 2007), online: http://www.microsoft.com/downloads/details.aspx?FamilyID=be6a2c5d-00df-4220b133-29c1e0b6585f&DisplayLang=en [MSS8] Microsoft SQL Server: SQL Server 2005 Migration, online: http://www.microsoft.com/sql/solutions/migration/default.mspx [MSS9] Guide to Migrating from MySQL to SQL Server 2005, online: http://www.microsoft.com/sql/techinfo/whitepapers/MigrateMySQL.mspx [MYS1] MySQL AB :: MySQL 5.0 Reference Manual, online: http://dev.mysql.com/doc/refman/5.0/en/index.html [MYS2] MySQL :: MySQL 5.0 Reference Manual :: 12.4.6 SET TRANSACTION Syntax, online: http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html [MYS3] MySQL :: Migrating from Microsoft SQL Server and Access to MySQL, online: http://dev.mysql.com/tech-resources/articles/migrating-from-microsoft.html [TPC1] Overview of the TPC Benchmark C, online: http://www.tpc.org/tpcc/detail.asp
48
[TPC2] Transaction Processing Performance Council, online: http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=107091301 [TPC3] Transaction Processing Performance Council, online: http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=107032701 [SWI1] Database Migration. Database Conversion. Convert Database. Migrate Database. Migrate SQL. convert database. Stored Procedure Migration. Migrate Stored Procedures. Convert SQL, Convert Stored Procedures. Stored Procedure Conversion. Data Migration. Migrate Data, online: http://www.swissql.com/database-migrationsolution.html
49
