[© Nacsa Sándor, 2008. május 28.] Amikor a Visual Studio 2008 kapcsán legutóbb arról kérdezett a Computerworld, hogy milyen technológiai trendek befolyásolják az egész szoftveripar fejlődését, megfogalmazódott bennem az interneten, a web "felhőjében" létrejövő "szupererőforrások" koncepciója, mint amire egyre inkább támaszkodniuk kell majd a szoftver műhelyeknek a saját fennmaradásuk érdekében. Akkor ott sem mód, sem terjedelem nem állt ahhoz rendelkezésre, hogy ennek mibenlétét kifejtsem. A "Win32 utáni" történésekre fókuszáló, vadi új blogom megnyitásához azonban választani sem tudnék ennél jobb témát.
Az új "szupererőforrások a felhőben" egyik jellegzetes példája az SQL Server Data Services (SSDS). Első ránézésre nem több ez, mint az ún. mixelt alkalmazások természetes adatplatformja, amikor adataink nem a desktop-on, se nem valamiféle hálózati szerveren, hanem magában a felhőben kerülnek tárolásra. Még azt sem kell tudnunk, hogy a felhőt alkotó globális adatközpontok között hogyan oszlanak meg az adatok. Amit tudunk (az SSDS esetében) az, hogy több példányban van minden tárolva, még földrajzilag is redundáns módon, és mivel maga a szolgáltatás a Microsoft SQL Server adatbázis architektúráján alapszik rendkívül magasfokú rendelkezésre állást és nagy megbízhatóságot biztosítanak nekünk. Adatvédelmi, vállalati szintű biztonsági és valós idejű tükrözésen alapuló adatbázis replikációs funkciók működnek a háttérben anélkül, hogy erről nekünk kellene gondoskodnunk.
No de milyen adatbázist kínál nekünk az SSDS? Itt ér bennünket az első meglepetés, mert egyáltalán nem a jól ismert SQL Server adatbázist kapjuk. A szolgáltatás ugyanis nem a relációs modellen alapszik, hanem az ún. entitás-attribútum-érték (Entity-Attribute-Value — EAV) modellen. Az SSDS esetében teljesen flexibilis entitásokat tárol a rendszer, amelyeknek előre nem meghatározott attribútumai vannak. Dinamikusan lehet egy adott entitáshoz újabb attribútumokat felvenni, korábbiakat törölni, egy attribútum értékét megváltoztatni. Ezek az entitások adott típusúak lehetnek, amelyeket a "Kind" meta-attribútum határoz meg. Természetesen van egyedi azonosítójuk, amely az "ID" meta-attribútum értéke szerinti. Van még továbbá verziójuk is: a "Version" meta-attribútum szerint. Ez utóbbit kizárólag a rendszer használja. Az entitás szintű flexibilitást jól mutatja a fejlesztés vezetőjének, Nigel Ellis-nek az előadásából vett mellékelt ábra (érdemes megnézni magát az előadást is a hivatkozásból elérhető videófelvételen!):
Sokakban felmerülhet a kérdés, hogy miért van szükség ilyen rugalmasságra már az alapoknál?
A válasz pedig roppant logikus. Általánosságban nem rögzíthető előre egy adott entitás tulajdonságainak (attribútumainak) a köre. Ezzel már a relációs modell megjelenése előtt találkoztak az adatbázis fejlesztők, mégpedig az első egészségügyi rendszereknél. Amikor az orvos egy aktuális diagnózist készít nem veheti figyelembe a tünetek teljes körét, hanem csak azokat, amelyeket a beteg panasza és a saját vizsgálatai alapján relevánsnak ítél. Ha a beteg elmegy egy másik orvoshoz, akkor egy újabb diagnózis készül, ami általánosságban különbözni fog az előzőtől mind a tünetek köre, mind azok leírása tekintetében. Még ha érdemben ugyanazt diagnosztizálta a másik orvos, akkor is különbözhet ennek a diagnózisnak az adatbázis rekordja az előzőétől. Más beteg és más panasz esetében pedig eleve jelentősen más lesz majd ez a rekord.
A "diagnózis" entitás esetében tehát az adatbázis tervezésekor nem tudjuk előre rögzíteni az attribútumokat, még érdemben azonos diagnózis esetében sem. A betegségek teljes körében előforduló, legkülönbözőbb diagnózisok esetében pedig a lehetséges tünetek köre hatalmas számosságú: több ezer, vagy akár több tízezer — ki tudja? Ha azonban még tudnánk is, ekkora oszlopszámú relációs táblát aligha lenne értelme definiálnunk, hiszen annak minden sorában legfeljebb néhány tucatnyi oszlop lenne ténylegesen kihasználva. Tehát még más érv is szól a fenti rugalmasság mellett (mint ahogyan még továbbiak is).
Háttérinformáció: Az általunk jól ismert adatintenzív alkalmazásoknál (vállalati ügyvitel stb.) megszoktuk, hogy az adatbázis séma előre rögzíthető. Megszoktuk azt is, hogy az ilyen sémák könnyen és hatékonyan kifejezhetők a relációs modell segítségével, a relációs adatbáziskezelő rendszerek pedig kényelmessé teszik az ilyen feladatok programozását is. Ehhez képest az egészségügyi rendszerek területén komoly nehézségekkel találták szemben magukat a szoftverfejlesztők. Jacob Anhøj 2003-as Generic Design of Web-Based Clinical Databases című tanulmánya ezt bőségesen illusztrálja. Érdemes betekinteni a probléma első példaértékű megoldásába is ahhoz, hogy jobban értsük a különbségeket: ld. Managing Attribute–Value Clinical Trials Data Using the ACT/DB Client–Server Database System (1998). Végezetül nem árt átlapozni Prakash Nadkarni honlapját, aki a téma vezető szaktekintélye. Minden olyan területen szükség van szerinte ilyen flexibilis entitás támogatásra, ahol "az egy objektumot leíró attribútumok potenciális száma több nagyságrenddel meghaladja az egy adott objektumot konkrétan leíró tulajdonságok számát".
Ne gondoljuk ugyanakkor, hogy egy ennyire ennyire általános modellre csak az egészségügyi alkalmazásoknál van szükség. Az Interneten használatos cookie-ek adatbázisban való tárolására is ez az ideális modell. A szoftverek tervezésénél pedig igen gyakran előfordul, hogy nem látjuk előre a lehetséges attribútumok körét és ezért nyitott adatstruktúrát használunk, amelyben attribútum-érték párok vannak. A W3C által definiált Resource Description Framework (RDF) is jól ki tudja használni az EAV modellre épülő adatbázist a maga <erőforrás, állítás, objektum> hármasának köszönhetően. Az RDF pedig a web további evolúcióját meghatározó, ún. szemantikus web egyik fő komponense, amikor már a tudás is reprezentálva lesz, nem csak az adat és az információ, mint jelenleg.
Az SQL Server Data Services tehát nem egyszerűen a jól ismert relációs adatbáziskezelési képességeket helyezi ki a felhőbe (majd legfeljebb az első változatok után, lásd ezt a bejegyzést követő valamelyik folytatásban, a későbbiek során!), hanem az EAV modellnek köszönhetően megalapoz egy ennél minőségileg többre képes szupererőforrás szolgáltatást. Nem valamiféle szuper relációs adatbáziskezelő tehát, hanem a jelenlegi ismeretek szerinti lehető legáltalánosabb szuper adatbáziskezelő. Nem csak a jelenlegi adatbáziskezelésen alapuló alkalmazásaink adatait tudjuk minden eddiginél potenciálisan nagyobb erőforrás környezetbe kihelyezni, hanem számunkra merőben új adatbáziskezelést is igénybe tudunk venni. Olyat, ami az egészségügyi alkalmazásokhoz, vagy a szemantikus web támogatásához szükséges. Mindezt anélkül, hogy nekünk magunknak, mint alkalmazási szoftver fejlesztőknek kellene fabrikálnunk valamiféle erre alkalmas adatbáziskezelő szolgáltatást.
(Folyt. köv. mert itt még nem ér véget az SQL Server Data Services, mint egy jellegzetes "szupererőforrás a felhőben" bemutatása. Újabb "tételek" következnek tehát, amelyek újabb és újabb aspektusát mutatják majd be ennek szuperőforrás jellegnek. Tessék követni tehát bejegyzéseimet!)
