přejít na obsah přejít na navigaci

Linux E X P R E S, Objektové databáze

Objektové databáze

Světu vládnou relační databáze, ale ještě není dobojováno, i ony mají své problémy. Jsou snad řešením objektové databáze? Zkusme se jim podívat na zoubek.


reklama

Relační databáze

Relační způsob uchovávání dat nás provází už hezkých pár let a za tato léta se ukázalo, že se nejedná o způsob špatný. Vždyť kdykoli nějaká společnost hledá databázistu, shání specialistu na nějaký RDBMS, a když někdo rozjíždí projekt, přemýšlí pouze, od jakého výrobce použije relační databázový systém. A není se čemu příliš divit. Práce s tabulkami, relacemi, klíči či indexy je velice jednoduchá, a přitom stojí na pevných matematických základech relačního kalkulu a relační algebry.

Zkratka RDBMS znamená Relational DataBase Management System a skrývají se pod ní veškeré relační databázové systémy jako MySQL, PostgreSQL, Oracle atd. Analogicky zkratka ODBMS v sobě skrývá Object DBMS a pokrývá databáze, o nichž je řeč v tomto článku.

Navíc mají většinou vyspělou sadu nástrojů (např. pro replikaci, zobrazení, ruční úpravu, API pro různé jazyky atd.) a jejich výkonnost je dostatečně ověřená i ve velmi náročných provozech, tak proč bychom je měnili? Svět se totiž posunul dále a už více než čtvrtstoletí tu máme objektový přístup k programování. A stále více a více se ukazuje, že je to cesta správná.

Tady se ukazuje nevýhoda relačního přístupu – není plně kompatibilní s objekty a při převodu je potřeba provádět transformace. Dnes se běžně vytváří v programech vrstva entit a následně perzistenční vrstva, která obsahu obsahuje sadu SELECTů, INSERTů a DELETů. V nejhorším případě to dělají programátoři ručně. Nešlo by to lépe?

Relační algebra, odnož predikátové logiky prvního řádu, je sada relací uzavřená na operátory. Relacemi jsou např. projekce (viz SELECT), selekce (viz WHERE), spojení (viz NATURAL JOIN) atd. Volně podle en.wikipedia.org

Objektové databáze

Stejně tak jako lidé postoupili od strukturálního programování k objektovému, tak si řekli, že by nebylo od věci neukládat data do tabulek a relací, ale do objektů tak, jak s nimi pracujeme přímo v programu. Bylo by přeci velice pěkné, když bych mohl objekt tak, jak ho mám, prostě uložit do databáze a o nic víc se nemuset starat.

Nemusel bych přemýšlet nad strukturami tabulek (tak aby dodržovaly „dobré mravy“ dané normami) a tvořit ruční INSERTy a SELECTy, jen bych databázovému stroji přes nějaké API řekl, načti mi uživatele s číslem 451, a dostal bych ho se všemi atributy naplněnými.

A přesně takto objektové databáze fungují. Místo tabulek jsou zde uloženy přímo objekty, včetně svých vlastností, a místo řádků se ukládají samotné instance objektů. Každý takto vložený objekt je jednoznačně identifikován svým OID, které na logické úrovni odpovídá ukazateli do virtuální paměti počítače a stejně tak se chová (při přesunu v paměti se změní i OID). Není tedy potřeba vytvářet primární klíče na objektech ani normalizovat databázi.

Objektové databáze také nabízejí využití možností vícenásobné dědičnosti, zapouzdření a polymorfizmu. Navíc vlastnosti (datové hodnoty) objektů nemusí být jen primitivního typu, ale mohou být dále strukturované jako například objekt (pomocí reference), množina nebo seznam.

Pojem zapouzdření znamená, že každý objekt obsahuje nejen datové hodnoty (vlastnosti), ale i funkce, které definují, jak je možné s těmito vlastnostmi zacházet.

Polymorfizmus umožňuje objektům zastupovat své potomky (ve smyslu dědičnosti) při volání metod. Program nemusí znát přesný typ objektu, který volá, ale ten se zjistí až za běhu a zavolá se metoda na správné třídě.

Pro vytváření nových tříd v databázi je definován nový speciální jazyk ODL (Object Definition Language). Nicméně v dnešní době se využívá vlastností pokročilých programovacích jazyků, jako je reflexe. Například v db4o stačí zavolat metodu set na objektu databáze, předat jí jako parametr obyčejný objekt a zbytek už si zařídí knihovna sama.

void storePilot (string pilotName, int pilotsPoints)
{
  Pilot pilot1 = new Pilot(pilotName, pilotsPoints);
  db.Set(pilot1);
}

Pro načítání dat z objektové databáze existuje jazyk OQL (Object Query Language). Jak je vidět už podle názvu, jeho syntaxe je velice blízká SQL. V následujícím příkladu si povšimněte, že odpadla potřeba spojovat tabulky, protože vše je dostupné přes objektové vazby:

SELECT o.customer_id.get_name(), o.room_id.id
FROM orders o
WHERE o.check_day(o.room_id.id, datefrom, dateto) = 1;

Další velice zajímavou možností je vytvořit dotaz pomocí QBE (Query By Example). Princip tohoto přístupu spočívá v tom, že databázi předáme částečně naplněný objekt a ta nám ho dohledá ve svém zdroji a doplní ostatní vlastnosti. Přesněji řečeno vrátí nějaký kontejner naplněný objekty, které původnímu objektu odpovídají. Uvedu zde jeden ilustrační příklad:

Pilot retrievePilotByName (string pilotName)
{
  Pilot proto = new Pilot("Michael Schumacher", 0);
  IObjectSet result = db.Get(proto);
  if (result.HasNext())
    return (Pilot)result.Next();
  else
    return null;
}

Současnost

Abych vás přesvědčil, že objektové databáze nejsou jen na papíře několika profesorů či v hlavě autorů scifi, uvedu příklad několika skutečně existujících databázových strojů. Všechny je samozřejmě možné zprovoznit pod Linuxem.

db4o

Výborná open-source embedded objektová databáze. Umožňuje víceuživatelský přístup, obsahuje podporu transakcí a ctí ACID principy. API dostupné pro Javu a pro .NET Framework, platformně nezávislé. Automaticky verzuje objektové schéma.

Embedded databáze je opakem klient-server přístupu. Distribuuje se v podobě knihovny, která se přilinkuje přímo k programu. Není tedy potřeba zprovozňovat externí databázový server.

Caché

Nejrozšířenější proprietární objektová databáze, která umožňuje k datům přistupovat také pomocí SQL dotazů. Nabízí transakční zpracování, masivní škálovatelnost, real-time analýzy a webový přístup k databázi. Připravená pro Javu a .NET a certifikovaná na Red Hat a SUSE Enterprise Linux.

Objectivity/DB

Jedná se o distribuovanou (data mohou být transparentně replikována na různých serverech), škálovatelnou databázi s nejširším výběrem API – pro C++, Javu, Python, Smalltalk a obecný ODBC. K dipozici je i 64bitová verze. Stáhnout si můžete 60denní trial, nebo plnou placenou verzi.

ObjectStore

Objektová databáze, která může být použita v C++, nebo Javě. Nabízí robustní systém cachování, transakční zpracování, online zálohy a replikace, škálování nebo podporu clusterů. K dispozici je testovací embedded verze omezená na jeden proces, případně placená plná verze.

ObjectDB

Volně dostupná (pro osobní a nekomerční použití) objektová databáze pro Javu. Může pracovat jak v klient-server, tak v embedded režimu. Bohužel se zdá, že aktivita na tomto zajímavém projektu zcela utichla.

Jak je vidět, vývojáři mají z čeho vybírat, ať už vyrábí svůj malý projekt a nemohou nebo nechtějí utrácet, nebo hledají robustní řešení pro velkou firmu. Přestože podpora pro Linux většinou znamená podporu pro Javu, není až na pár výjimek v tomto oboru u výrobců opomíjen.

Budoucnost

Máme nadějné a užitečné funkce, máme širokou nabídku produktů, zdálo by se, že rozkvětu popularity objektových databází mezi uživateli nic nestojí. Realita je ale jiná. Přestože se tu a tam používají, ani po dvaceti letech vývoje hlavní dálnicí určitě nejsou.

Snad za to může nevyspělost produktů (přestože marketingové oddělení jednotlivých produktů tvrdí pravý opak), spíše bych to ale přičítal setrvačnosti trhu. Podíváme-li se na rozdělení množství kódu pomocí strukturálního a pomocí objektového programování, také nelze říct, že objektové vítězí.

Například nejrozšířenějším jazykem webu je bezesporu PHP a drtivá většina stránek pomocí něj generovaných si s objekty netyká. Je tedy vidět, že z historických důvodů často není ani potřeba objekty ukládat.

Jelikož snaha zjednodušit ukládání dat a stále častěji objektů do databáze byla stále větší, zrodila se konkurence čistokrevným objektovým databázím v podobě Object-Relational Mappers (zkráceně ORM). Jedná se o vrstvu aplikační logiky, která se vloží mezi objektovou hierarchii v programu a relační databázi a ta zde automatizuje transformaci objektů používaných v programu do tabulek v databázi a naopak. Mezi nejznámější ORM patří Hibernate pro Javu či .netTiers pro .NET Framework.

Na první pohled je ale vidět, že ORM problém nekompatibility neřeší, jen ho odsouvají na někoho jiného. Stále někdo musí provádět transformace a „odvděčí“ se nám nižším výkonem při přístupu do databáze.

Nechme ale volbu na programátorovi. Věřím, že až budete příště zakládat nový projekt, vzpomenete si, že objektové databáze existují a zvážíte, jestli pro vás nejsou lepší volbou. Možná ne, ale třeba také ano.

Nahoru

Odkazy

(Jako ve škole)
Průměr: 3,33 | Hodnotilo: 9
 

Top články z OpenOffice.cz

Příspěvky

Objektové databáze
daks 19. 11. 2007, 09:04:25
Odpovědět  Odkaz 
Není už dost přeobjektováno? Nejsou všechny ty rafinovanosti (nedejbože vícenásobné) dědičnosti, zapouzdření a bůhví čeho ještě spíš překážkou než usnadněním? Není to opruz když jsou konstanty součástí objektu, jako třeba v C#?
Lukáš Zapletal Re:Objektové databáze
zapletal 19. 11. 2007, 10:17:59
Odpovědět  Odkaz 
Tyhlety "rafinovasti" už jdou dělat dávno ve většině pokročilých relačních databází. O překážku se určitě nejedná, to byste jako chtěl ustrnout a už dál nevyvíjet nové technologie? Kde bychom s takovým přístupem skončili?
Re:Re:Objektové databáze
daks 19. 11. 2007, 11:12:49
Odpovědět  Odkaz 
Otázkou je, kterým směrem se ten vývoj ubírá, taková ta nucená čistá objektovost nemusí být vždycky ku prospěchu věci.
Re:Re:Re:Objektové databáze
lzap 21. 01. 2008, 20:50:55
Odpovědět  Odkaz 
Nic nuceneho tam nevidim, objektove databaze poskytuji v nekterych pripadech krome lepsiho provazani s objektovymi jazyky take vyssi vykon.
Objektové databáze
michal 21. 11. 2007, 20:55:58
Odpovědět  Odkaz 
Aj Zope pouziva objektovu databazu, ktora sa da pouzit aj samostatne ZODB http://launchpad.net/zodb
Objektové databáze
petr_p 9. 12. 2008, 16:03:42
Odpovědět  Odkaz 
Autor pokládá za výhodu zbytnost převodu dat na objekty a vyvozuje z toho vyšší rychlost. Znamená to, že objektové databáze jsou natvrdo navázané na vnitřní reprezentaci objektu daného programovacího jazyka a mezi jazyky jsou nepřenositelné?
Re:Objektové databáze
Helena Palovksá 26. 09. 2009, 05:22:24
Odpovědět  Odkaz 
Jde o rychlost programátorovu, že vyvíjí rychleji. Pokud jde o rychlost provádění transakcí, tak záleží jak kdy. Objekové databáze mohou mít vnitřní reprezentaci výhodnější pro danou strukturu, oproti ryze relačnímu uspořádání. Ale ryze relační uspořádání je historie.
Jinak přenositelnost mezi jazyky má být zaručena "bindingy" do různých jazyků, a tím, že se užívá pouze určitý metamodel objektových typů.
Objektové databáze
Helena Palovksá 26. 09. 2009, 05:34:52
Odpovědět  Odkaz 
Autor pomýlení píše, že zapouzdření spočívá v tom ,že "každý objekt obsahuje nejen datové hodnoty (vlastnosti), ale i funkce, které definují, jak je možné s těmito vlastnostmi zacházet". To není zapouzdření. Zapouzdření je oddělení interface od implementace, což dává možnost vylepšit implementaci bez změny interface, což je ve své podstatě rozdělení zodpovědnosti. Vlastník objektu zodpovídá za interface, implementace je na jeho rozhodnutí.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

David Kovář

David Kovář (*1981) z Telče je absolvent ČVUT. Zaměstnán na pozici mezi vývojářem, analytikem a konzultantem u jedné jihlavské společnosti. Ve volném čase rád kromě počítačů prohání kolo nebo florbalový míček.


  • Hodnocení autora: *