1. diel - Úvod do databáz v Jave

Týmto tutoriálom začneme veľkú tému, ktorou je práca s databázami v Jave.

Na čo nám je databáza?

Možno vám napadlo, na čo vlastne potrebujeme nejakú databázu. Dáta by sme predsa mohli ukladať do nejakých textových súborov, binárok, XML alebo niečoho podobného. Určite by to nejako fungovalo, alebo nie?

RDBMS

Označenie databáza je vlastne nepresné a v odbornej literatúre sa stretneme s označením RDBMS (Relation DataBase Management System). Slovensky je to preložené ako "systém riadenia bázy dát", čo znie naozaj hrozne, a preto budem ďalej používať označenie databázový stroj alebo RDBMS. Databázový stroj nie je len úložisko dát. Jedná sa o veľmi sofistikovaný a vyladený nástroj, ktorý za nás rieši množstvo problémov a zároveň je extrémne jednoduchý na použitie. S databázou totiž komunikujeme jazykom SQL, ktorým sú v podstate ľudsky zrozumiteľné vety. Nad týmto jazykom vznikli aj objektové nadstavby, ale o nich neskôr.

Spolu s ukladaním dát je ale treba ďalej riešiť mnoho ďalších vecí. Asi by nám napadlo napr. zabezpečenie alebo optimalizácia výkonu. RDBMS toho ale robí ešte oveľa viac, rieši za nás problém súčasnej editácie rovnakej položky niekoľkými používateľmi v rovnaký okamih, ktorý by inak mohol zapríčiniť nekonzistenciu databázy. RDBMS dáta v tomto prípade zamkne a odomkne až po vykonaní zápisu. Ďalej umožňuje spájať niekoľko otázok do transakcií, kedy sa séria otázok vykoná vždy celá alebo vôbec. Nestane sa, že by sa vykonala len časť. Tieto vlastnosti databázového stroja sú zhŕňa skratka ACID, poďme si ju vysvetliť.

ACID

ACID je akronym slov Atomicity (nedeliteľnosť), Consistency (validita), Isolation (izolácia) a Durability (trvanlivosť). Jednotlivé zložky majú nasledujúci význam:

• Atomicity - Operácie v transakcii sa vykonajú ako jedna atomická (nedeliteľná) operácia. Tzn. že ak nejaká časť operácie zlyhá, vráti sa databáza do pôvodného stavu a žiadne časti transakcie nebudú vykonané. Reálny príklad je napr. prevod peňazí na bankovom účte. Ak sa nepodarí peniaze odpočítať z jedného účtu, nebudú ani pripísané na účet druhý. Inak by bola databáza v nekonzistentnom stave. Ak by sme si prácu s dátami riešili sami, mohlo by sa nám toto veľmi jednoducho stať.
• Consistency - Stav databázy po dokončení transakcie je vždy konzistentný, teda validný podľa všetkých definovaných pravidiel a obmedzení. Nikdy nenastane situácia, že by sa databáza nachádzala v nekonzistentnom stave.
• Isolation - Operácie sú izolované a navzájom sa neovplyvňujú. Ak sa zíde v jeden okamih viacero otázok na zápis do rovnakého riadku, sú vykonávané postupne, ako vo fronte.
• Durability - Všetky zapísané dáta sú okamžite zapísané na trvanlivé úložiská (na pevný disk), v prípade výpadku el. energie alebo iného prerušenia prevádzky RDBMS všetko zostane tak, ako bolo tesne pred výpadkom.

Databáza (presnejšie databázový stroj) je teda čierna skrinka, s ktorou naša aplikácia komunikuje a do ktorej ukladá všetky dáta. Jej použitie je veľmi jednoduché a je vyladená tak, že zápis dát v programe by sme si sami asi ťažko takto urobili. Vôbec sa nemusíme starať o to, ako sú dáta fyzicky uložené, s databázou komunikujeme pomocou jednoduchého dotazovacieho jazyka SQL, viď ďalej. V dnešnej dobe sa vôbec neoplatí zaťažovať sa otázkou ukladania dát, jednoducho siahneme po hotovej databáze, ktorých je obrovský výber a sú väčšinou zadarmo. O databáze občas hovoríme ako o 3. vrstve aplikácie (1. vrstva je používateľské rozhranie, 2. je vlastná logika aplikácie a 3. je práve dátová vrstva).

Relačná databáza

Na ukladanie dát sa takmer výhradne používajú tzv. relačné databázy. Tento pojem označuje databázu založenú na tabuľkách. Každá tabuľka obsahuje položky jedného typu. Môžeme mať teda tabuľku user, ďalšiu tabuľku article a ďalšiu napríklad comment.

Databázovú tabuľku si môžeme predstaviť napríklad ako tabuľku v Exceli. Tabuľka user by mohla vyzerať asi takto:

Položky (tu konkrétne používatelia) ukladáme na jednotlivé riadky, stĺpce potom označujú atribúty (vlastnosti, ak chcete), ktoré položky majú. Databáza je väčšinou typovaná, to znamená, že každý stĺpec má pevne stanovený dátový typ (číslo, znak, krátky text, dlhý text...) a môže obsahovať hodnoty iba tohto typu. Teda rovnako ako premenné v Jave. Ak chceme s relačnou databázou rozumne pracovať, každý riadok v tabuľke by mal byť opatrený unikátnym identifikátorom. Pri používateľoch by to mohlo byť rodné číslo, oveľa častejšie sa však používajú identifikátory umelé a to tak, že používateľov jednoducho očíslujeme. K tomu sa dostaneme neskôr.

Slovo relačné označuje vzťah (anglicky relation). Ten je medzi tabuľkami alebo medzi entitami v jednej tabuľke. To si ale necháme na inokedy a zatiaľ budeme pracovať len s jednou tabuľkou zároveň.

Rozpor objektového a relačného prístupu

Objektový svet a svet relačných databáz (svet relačný) sú veľmi rozdielne. Ide o 2 odlišné filozofie, o ktorých si tu trúfnem vyhlásiť, že sú nezlučiteľné.

Relačné databázy sú overený spôsob ako pracovať s dátami. Hoci existujú aj databázy plne objektové, firmám sa do nich teraz neoplatí investovať peniaze a preto sa zatiaľ nepresadili. Po revolúcii v programovaní a príchode objektov samozrejme nastal problém s ukladaním dát, pretože relačné databázy objektovo nefungujú a objekty ukladať nevedia. Existuje niekoľko možností, ako sa s týmto vysporiadať.

1. Neobjektové programovanie

Prvou možnosťou je samozrejme programovať úplne bez objektov. Tým by sme však šli proti prúdu, nemohli by sme používať žiadne komponenty 3. strán a náš kód by bol veľmi nekvalitný. Keďže Java je objektový jazyk, ani by to v ňom dosť dobre nešlo.

2. Databázový Wrapper

Prístup tzv. wrappera nám umožňuje s databázou pracovať ako s objektom, ale komunikujeme s ňou stále v jej jazyku SQL. Miešame teda objektový a relačný kód. Prístup je akýmsi kompromisom a vyžaduje filozofiu OOP trochu ohnúť. Výhodou je zachovanie výkonu a schopností databázy za cenu miernej degradácie myšlienok OOP.

Dáta z databázy vidíme najčastejšie ako hodnoty v tabuľke (tá je objektom) a prichádzame o možnosť prideliť entitám nejakú funkcionalitu. Tú namiesto toho združujeme do tzv. manažérov.

Tento prístup v Jave zastupuje JDBC (ako Java DataBase Connectivity). Je to jednotné rozhranie, ktoré podporuje všetky významné databázy. Stačí iba stiahnuť tzv. connector od výrobcu danej databázy a môžeme s ňou v Jave pomocou JDBC komunikovať v jej natívnom jazyku SQL. Teoreticky stačí len zmeniť Connector a naša hotová aplikácia zrazu pracuje s úplne inou databázou bez toho, aby sme menili javovský kód. JDBC mapuje základné typy stĺpcov na javovské dátové typy.

3. Objektovo relačné mapovanie

Objektovo relačné mapovanie (ORM) ide ortodoxne za myšlienkou OOP. Z databázy teda namiesto poľa hodnôt dostávame rovno objekty a tie na sebe majú metódy. V jazyku SQL vôbec nekomunikujeme, tabuľky v databáze vidíme ako kolekcie objektov, s ktorými môžeme pracovať bežnými prostriedkami jazyka. Sme vlastne úplne oprostení od toho, že pracujeme s relačnou databázou. Znie to skvele, však?

Háčik je samozrejme v tom, že na pozadí dochádza k veľkej degradácii výkonu databázy, SQL dotazy sa generujú automaticky a sú často neefektívne. Veľké obchodné aplikácie sú často napísané pomocou ORM a kritické časti sú napísané len s JDBC. Ďalším problémom ORM je, že je veľmi zložité (nie na použitie, ale na naprogramovanie). Java nám našťastie ponúka vyladené ORM, čiže nemusíme nič riešiť. ORM je v Jave špecifikované JPA (Java Persistence API), čo je popis rozhrania pre objektovú prácu s dátami. Najčastejšie používaná konkrétna implementácia je Hibernate. Konkurenčným rozhraním je ešte JDO.

JPA mapuje tabuľky na konkrétne triedy (entity). Mapovanie určíme buď pomocou XML alebo pomocou anotácií. Synchronizáciu databázy s objektovou štruktúrou zaisťuje EntityManager.

Názory na ORM sú veľmi kontroverzné, napr. že samotná jeho myšlienka je nesprávna, pretože generovaný SQL kód skrátka nemôže byť efektívny a je nutné pomýšľať na jeho konečnú podobu, oprostenie teda nie je úplné. Osobne mám k ORM neutrálny postoj a ak mi niekto spolu s jazykom poskytne štandardizované a vyladené ORM, rád ho použijem. Ak nie, zaobídem sa bez neho.

4. Objektové databázy

Okrem databáz relačných existujú aj už spomínané databázy objektové. Tie riešia problém nezlúčiteľnosti objektového a relačného prístupu. Poskytujú rovnaký komfort ako ORM, ale vnútorne nie je potrebné dáta prevádzať do tabuliek, ukladajú sa rovno ako objekty. Teoreticky neexistuje výkonnostný ani iný dôvod, prečo by nemali nahradiť databázy relačné. V praxi sa ale bohužiaľ takmer nepoužívajú a môžeme len dúfať, že sa to časom zmení. Záujemcovia sa môžu pozrieť napr. na projekt MongoDB.

V ďalších tutoriáloch si vyskúšame základnú prácu s databázou v Jave pomocou JDBC.

V budúcej lekcii, Návrh MySQL databázy v IntelliJ IDE, si nainštalujeme MySQL databázu, potrebné pluginy a konektory a pripravíme si testovacie dáta.