1. díl - Úvod do databází v Javě

Java Databáze Úvod do databází v Javě

Tímto tutoriálem započneme velké téma, kterým je práce s databázemi v Javě.

K čemu databázi?

Možná vás napadlo, k čemu vlastně potřebujeme nějakou databázi. Data bychom stejně dobře mohli ukládat do nějakých textových souborů, binárek, XML nebo něčeho podobného. Určitě by to nějak fungovalo, nebo ne?

Označení databáze je vlastně nepřesné a v odborné literatuře se setkáme s označením RDBMS (Relation DataBase Management System). Česky je to přeloženo jako "systém řízení báze dat", což zní opravdu hrozně a proto budu dále používat označení databázový stroj nebo RDBMS. Databázový stroj není jen úložiště dat. Jedná se o velmi sofistikovaný a odladěný nástroj, který za nás řeší spoustu problémů a zároveň je extrémně jednoduchý k použití. S databází totiž komunikujeme jazykem SQL, kterým jsou v podstatě lidsky srozumitelné věty. Nad tímto jazykem vznikly i objektové nadstavby, ale o nich později.

Spolu s ukládáním dat je ale třeba dále řešit mnoho dalších věcí. Asi by nás napadlo např. zabezpečení nebo optimalizace výkonu. RDBMS toho ale dělá ještě mnohem více, řeší za nás problém současné editace stejné položky několika uživateli ve stejný okamžik, který by jinak mohl zapříčinit nekonzistenci databáze. RDBMS data v tomto případě zamkne a odemkne až po vykonání zápisu. Dále umožňuje spojovat několik dotazů do transakcí, kdy se série dotazů vykoná vždy celá nebo vůbec. Nestane se, že by se vykonala jen část. Tyto vlastnosti databázového stroje jsou shrnovány zkratkou ACID, pojďme si ji vysvětlit.

ACID

ACID je akronym slov Atomicity (nedělitelnost), Consistency (validita), Isolation (izolace) a Durability (trvanlivost). Jednotlivé složky mají následující význam:

  • Atomicity - Operace v transakci se provedou jako jedna atomická (nedělitelná) operace. Tzn. že pokud nějaká část operace selže, vrátí se databáze do původního stavu a žádné části transakce nebudou provedeny. Reálný příklad je např. převod peněz na bankovním účtu. Pokud se nepodaří peníze odečíst z jednoho účtu, nebudou ani připsány na účet druhý. Jinak by byla databáze v konzistentním stavu. Pokud bychom si práci s daty řešili sami, mohlo by se nám toto velmi jednoduše stát.
  • Consistency - Stav databáze po dokončení transakce je vždy konzistentní, tedy validní podle všech definovaných pravidel a omezení. Nikdy nenastane situace, že by se databáze nacházela v nekonzistentním stavu.
  • Isolation - Operace jsou izolované a navzájem se neovlivňují. Pokud se sejde v jeden okamžik více dotazů na zápis do stejného řádku, jsou vykonávány postupně, jako ve frontě.
  • Durability - Všechna zapsaná data jsou okamžitě zapsána na trvanlivá úložiště (na pevný disk), v případě výpadku el. energie nebo jiného přerušení provozu RDBMS vše zůstane tak, jak bylo těsně před výpadkem.

Databáze (přesněji databázový stroj) je tedy černá skříňka, se kterou naše aplikace komunikuje a do které ukládá veškerá data. Její použití je velmi jednoduché a je odladěna tak, jak bychom si sami zápis dat v programu asi těžko udělali. Vůbec se nemusíme starat o to, jak jsou data fyzicky uložena, s databází komunikujeme pomocí jednoduchého dotazovacího jazyka SQL, viz dále. V dnešní době se vůbec nevyplatí zatěžovat se otázkou ukládání dat, jednoduše sáhneme po hotové databázi, kterých je obrovský výběr a jsou většinou zadarmo. O databázi občas hovoříme jako o 3. vrstvě aplikace (1. vrstva je uživatelské rozhraní, 2. vlastní logika aplikace, 3. je právě datová vrstva).

Relační databáze

K ukládání dat se téměř výhradně používají tzv. relační databáze. Tento pojem označuje databázi založenou na tabulkách. Každá tabulka obsahuje položky jednoho typu. Můžeme mít tedy tabulku uzivatele, další tabulku clanky a další třeba komentare.

Databázovou tabulku si můžeme představit třeba jako tabulku v Excelu. Tabulka uzivatele by mohla vypadat asi takto:

Tabulka uživatelů v Excelu

Položky (konkrétně zde uživatelé) ukládáme na jednotlivé řádky, sloupce pak označují atributy (vlastnosti, chcete-li), které položky mají. Databáze je většinou typovaná, to znamená, že každý sloupec má pevně stanovený datový typ (číslo, znak, krátký text, dlouhý text...) a může obsahovat hodnoty jen tohoto typu. Tedy stejně jako proměnné v Javě. Pokud chceme s relační databází rozumně pracovat, každý řádek v tabulce by měl být opatřený unikátním identifikátorem. U uživatelů by to mohlo být třeba rodné číslo, mnohem častěji se však používají identifikátory umělé a to tak, že uživatele prostě očíslujeme. K tomu se dostaneme později.

Slovo relační označuje vztah (anglicky relation). Ten je mezi tabulkami nebo mezi entitami v jedné tabulce. To si ale necháme na jindy a zatím budeme pracovat jen s jednou tabulkou zároveň.

Rozpor objektového a relačního přístupu

Objektový svět a svět relačních databází (svět relační) jsou velmi rozdílné. Jedná se o 2 odlišné filozofie, o kterých si zde troufnu prohlásit, že jsou neslučitelné.

Relační databáze jsou ověřený způsob jak pracovat s daty. I když existují i databáze plně objektové, firmám se do nich nyní nevyplatí investovat peníze a proto se zatím neprosadily. Po revoluci v programování a příchodu objektů samozřejmě nastal problém s ukládáním dat, jelikož relační databáze objektově nefungují a objekty ukládat neumí. Existuje několik možností, jak se s tímto vypořádat.

1. Neobjektové programování

První možností je samozřejmě programovat úplně bez objektů. Tím bychom však šli proti proudu, nemohli bychom používat žádné komponenty 3. stran a náš kód by byl velmi nekvalitní. Jelikož Java je objektový jazyk, ani by to v něm dost dobře nešlo.

2. Databázový Wrapper

Přístup tzv. wrapperu nám umožňuje s databází pracovat jako s objektem, nicméně komunikujeme s ní stále v jejím jazyce SQL. Mícháme tedy objektový a relační kód. Přístup je jakýmsi kompromisem a vyžaduje filozofii OOP trochu ohnout. Výhodou je zachování výkonu a schopností databáze za cenu mírné degradace myšlenek OOP.

Data z databáze vidíme nejčastěji jako hodnoty v tabulce (ta je objektem) a přicházíme o možnost přidělit entitám nějakou funkcionalitu. Tu místo toho sdružujeme do tzv. manažerů.

Tento přístup v Javě zastupuje JDBC (jako Java DataBase Connectivity). Je to jednotné rozhraní, které podporuje všechny významné databáze. Stačí pouze stáhnout tzv. connector od výrobce dané databáze a můžeme s ní v Javě pomocí JDBC komunikovat v jejím nativním jazyce SQL. Teoreticky stačí jen změnit Connector a naše hotová aplikace najednou pracuje s úplně jinou databází, aniž bychom měnili javovský kód. JDBC mapuje základní typy sloupců na javovské datové typy.

3. Objektově relační mapování

Objektově relační mapování (ORM) jde ortodoxně za myšlenkou OOP. Z databáze tedy místo pole hodnot dostáváme rovnou objekty a ty na sobě mají metody. V jazyce SQL vůbec nekomunikujeme, tabulky v databázi vidíme jako kolekce objektů, se kterými můžeme pracovat běžnými prostředky jazyka. Jsme vlastně úplně odstíněni od toho, že pracujeme s relační databází. Zní to skvěle, že?

Háček je samozřejmě v tom, že na pozadí dochází k velké degradaci výkonu databáze, SQL dotazy se generují automaticky a jsou často neefektivní. Velké obchodní aplikace jsou často napsané pomocí ORM a kritické části jsou napsané jen s JDBC. Dalším problémem ORM je, že je velmi složité (ne k použití, ale k naprogramování). Java nám naštěstí nabízí odladěné ORM, čili nemusíme nic řešit. ORM je v Javě specifikováno JPA (Java Persistence API), což je popis rozhraní pro objektovou práci s daty. Nejčastěji používaná konkrétní implementace je Hibernate. Konkurenčním rozhraním je ještě JDO.

JPA mapuje tabulky na konkrétní třídy (entity). Mapování určíme buď pomocí XML nebo pomocí anotací. Synchronizaci databáze s objektovou strukturou zajišťuje EntityManager.

Názory na ORM jsou velmi kontroverzní, např. že samotná jeho myšlenka je nesprávná, jelikož generovaný SQL kód zkrátka nemůže být efektivní a je nutné pomýšlet na jeho konečnou podobu, odstínění tedy není úplné. Osobně mám k ORM neutrální postoj a pokud mi někdo spolu s jazykem poskytne standardizované a odladěné ORM, rád ho použiji. Pokud ne, obejdu se bez něj.

4. Objektové databáze

Kromě databází relačních existují i již zmíněné databáze objektové. Ty řeší problém neslučitelnosti objektového a relačního přístupu. Poskytují stejný komfort, jako ORM, ale vnitřně není třeba data převádět do tabulek, ukládají se rovnou jako objekty. Teoreticky neexistuje výkonnostní ani jíný důvod, proč by neměly nahradit databáze relační. V praxi se ale bohužel téměř nepoužívají a můžeme jen doufat, že se to časem změní. Zájemci se mohou podívat např. na projekt MongoDB.

V dalších tutoriálech si vyzkoušíme základní práci s databází v Javě pomocí JDBC.


 

  Aktivity (1)

Článek pro vás napsal David Čápka
Avatar
Autor pracuje jako softwarový architekt a pedagog na projektu ITnetwork.cz (a jeho zahraničních verzích). Velmi si váží svobody podnikání v naší zemi a věří, že když se člověk neštítí práce, tak dokáže úplně cokoli.
Unicorn College Autor se informační technologie naučil na Unicorn College - prestižní soukromé vysoké škole IT a ekonomie.

Jak se ti líbí článek?
Celkem (9 hlasů) :
55555


 


Miniatura
Všechny články v sekci
Databáze v Javě - JDBC
Miniatura
Následující článek
Návrh MySQL databáze v NetBeans IDE

 

 

Komentáře

Avatar
solskier1
Člen
Avatar
solskier1:

Som naozaj rád že sa niekto podujal na základy databáz. Jedno veľké Ďakujem :)
sdraco naučil si ma už asi viac než dosť čím ale nehovorím aby si prestal :D

Odpovědět 2.1.2014 17:10
Čo si sám nenakódiš nevieš.
Avatar
David Čápka
Tým ITnetwork
Avatar
Odpovídá na solskier1
David Čápka:

Já jen tak nepřestanu, to se neboj :D

Odpovědět  +3 9.1.2014 18:56
Miluji svou práci a zdejší komunitu, baví mě se rozvíjet, děkuji každému členovi za to, že zde působí.
Avatar
Lenka
Neregistrovaný
Avatar
Lenka:

Ahoj mám dotaz.
Mám vytvořit jednoduchou databázi.
požadavky
• Práce musí obsahovat minimálně 3 třídy.
• Celkový počet příkazových řádek min. 200.
• Komunikace s uživatelem v textovém režimu (žádná grafika).
• V programu povinně práce se soubory.
Je možné že prací se soubory znamená že v jedné třídě třeba nadefinuji filmy a v druhé je přečtu?
Jsem úplný začátečník :)

 
Odpovědět 12.1.2014 9:04
Avatar
solskier1
Člen
Avatar
Odpovídá na Lenka
solskier1:

Ja si myslím že je to jedno veď si spravíš proste triedu PracaSoSubormi a v nej budeš mať metódy na vkladanie a aj načítanie dát nemalo by to predsa zabrať veľa riadkov :) Druhá trieda by mohla byť trieda kde nadefinuješ užívateľské rozhranie a tá tretia by bola trieda kde len spravíš metódu main ;) aj keď predpokladám že keď si začiatočník tak nikto od teba nebude chcieť prácu s SQL databázami tak si pozri tu na devbook.cz prácu so súbormi je to jednoducho napísané a zrozumiteľné :)

Odpovědět 12.1.2014 15:39
Čo si sám nenakódiš nevieš.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 4 zpráv z 4.