IT rekvalifikace s garancí práce. Seniorní programátoři vydělávají až 160 000 Kč/měsíc a rekvalifikace je prvním krokem. Zjisti, jak na to!
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Lekce 1 - Ú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?

RDBMS

RDBMS - Databáze v Javě - JDBC

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 nekonzistentní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:

Jméno Příjmení Datum narození Počet článků
Jan Novák 11.3.1984 17
Tomáš Marný 1.2.1989 6
Josef Nový 20.12.1972 9
Michaela Slavíková 14.8.1990 1

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.

V příští lekci, Návrh MySQL databáze v IntelliJ IDE, si nainstalujeme MySQL databázi, potřebné pluginy a konektory a připravíme si testovací data.


 

Všechny články v sekci
Databáze v Javě - JDBC
Přeskočit článek
(nedoporučujeme)
Návrh MySQL databáze v IntelliJ IDE
Článek pro vás napsal David Hartinger
Avatar
Uživatelské hodnocení:
108 hlasů
David je zakladatelem ITnetwork a programování se profesionálně věnuje 15 let. Má rád Nirvanu, nemovitosti a svobodu podnikání.
Unicorn university David se informační technologie naučil na Unicorn University - prestižní soukromé vysoké škole IT a ekonomie.
Aktivity