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 databázu?

Možno vás napadlo, na čo vlastne potrebujeme nejakú databázu. Dáta by sme rovnako dobre 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ázy je vlastne nepresné av 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 odladený 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ás 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ŕňané skratkou 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. Pokiaľ sa nepodarí peniaze odpočítať z jedného účtu, nebudú ani pripísané na účet druhý. Inak by bola databáza v nekonzistentnom stave. Pokiaľ 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 viac 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 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 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 užívateľské rozhranie, 2. vlastná logika aplikácie, 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 používateľa, ď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 používateľa by mohla vyzerať asi takto:

Položky (konkrétne tu 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. Pokiaľ chceme s relačnou 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ť potrebné rodné číslo, oveľa častejšie sa však používajú identifikátory umelé a to tak, že uží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. Aj keď 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 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 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 kolekcia objektov, s ktorými môžeme pracovať bežnými prostriedkami jazyka. Sme vlastne úplne odtienení od toho, že pracujeme s relačnou databázou. 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 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, odtienenie teda nie je úplné. Osobne mám k ORM neutrálny postoj a pokiaľ 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šia problém nezluč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.