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

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

K čomu databáze?

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

RDBMS

Označenie databázy 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 "databázový systém", č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 odladený nástroj, ktorý za nás rieši veľa 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 objektovej nadstavby, ale o nich neskôr.

Spolu s ukladaním dát je ale potrebné ďalej riešiť mnoho ďalších vecí. Asi by nás napadlo napr. Zabezpečenia alebo optimalizácie výkonu. RDBMS toho ale robí ešte oveľa viac, rieši za nás problém súčasnej editácia rovnaké položky niekoľkými užívateľmi v rovnaký okamih, ktorý by inak mohol zapríčiniť nekonzistentnosti databázy. RDBMS dáta v tomto prípade zamkne a odomkne až po vykonaní zápisu. Ďalej umožňuje spájať niekoľko dotazov 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ú zhrňované skratkou ACID, poďme si ju vysvetliť.

ACID

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

• Atomicita - Operácie v transakcii sa vykonajú ako jedna atomická (nedeliteľná) operácie. Tzn. že ak nejaká časť operácie zlyhá, vráti sa databázy 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ázy v konzistentnom 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ázy nachádzala v nekonzistentnom stave.
• Isolation - Operácie sú izolované a navzájom sa neovplyvňujú. Ak sa zíde v jeden okamih viac dotazov 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žisko (na pevný disk), v prípade výpadku el. energie alebo iného prerušenie 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še aplikácie komunikuje a do ktorej ukladá všetky dáta. Jej použitie je veľmi jednoduché a je odladená tak, ako by sme si sami zápis dát v programe asi ťažko 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 ukladanie dát, jednoducho siahneme po hotové databázu, ktorých je obrovský výber a sú väčšinou zadarmo. O databázu občas hovoríme ako o 3. vrstve aplikácie (1. vrstva je užívateľské rozhranie, 2. vlastné logika aplikácie, 3. je práve dátová vrstva).

Relačnej databázy

Na ukladanie dát sa takmer výhradne používajú tzv. Relačnej 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 uzivatele, ďalšiu tabuľku clanky a ďalšie potrebné komentare.

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

Meno	priezvisko	dátum narodenia	počet článkov
Jan	Novák	11.3.1984	17
Tomáš	márny	1.2.1989	6
Josef	nový	20.12.1972	9
Michaela	Slavíková	14.8.1990	1

Položky (konkrétne tu uží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 typová, 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 len tohto typu. Teda rovnako ako premenné v Jave. Ak chceme s relačné databázou rozumne pracovať, každý riadok v tabuľke by mal byť opatrený unikátnym identifikátorom. U užívateľov by to mohlo byť napríklad rodné číslo, oveľa častejšie sa však používajú identifikátory umelé a to tak, že používateľa 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 jednotlivými subjektmi v jednej tabuľke. To si však 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. Jedná sa o 2 odlišné filozofie, o ktorých si tu trúfam vyhlásiť, že sú nezlučiteľné.

Relačné databázy sú overený spôsob ako pracovať s dátami. I keď existujú aj databázy plne objektovej, 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, keďže relačné databázy objektovo nefungujú a objekty ukladať nevie. 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 iš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. Wrapper nám umožňuje s databázou pracovať ako s objektom, však 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še hotová aplikácie naraz 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 miesto pole 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 kolekcia objektov, s ktorými môžeme pracovať bežnými prostriedkami jazyka. Sme vlastne úplne odtienené od toho, že pracujeme s relačné databáz. Znie to skvele, že?

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 odladené ORM, čiže nemusíme nič riešiť. ORM je v Jave špecifikované JPA (Java Persistence API), čo je opis rozhranie pre objektovú prácu s dátami. Najčastejšie používaná konkrétnej implementácie je Hibernate. Konkurenčnom rozhraním je ešte TÝKAJÚCE SA PREVÁDZKOVEJ.

JPA mapuje tabuľky na konkrétne triedy (entity). Mapovanie určíme buď pomocou XML alebo pomocou anotácií. Synchronizáciu databázy s objektovú š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ívna a je nutné pomýšľať na jeho konečnú podobu, odtienenie teda nie je úplné. Osobne mám k ORM neutrálny postoj a ak mi niekto spolu s jazykom poskytne štandardizované a odladené 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ši problém nezlučiteľnosti objektového a relačného prístupu. Poskytujú rovnaký komfort, ako ORM, ale vnútorne netreba 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čnej. 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.