Prostředek, díky kterému se aplikace domluví s databázemi

Přehled standardu ODBC Pro přístup k datům se dnes stále velmi často používá rozhraní ODBC (Open DataBase Connectiv...


Přehled standardu ODBC
Pro přístup k datům se dnes stále velmi často používá rozhraní ODBC (Open
DataBase Connectivity). Přesto je technologie ODBC poměrně málo známá a z této
neznalosti plynou buď nepřiměřená očekávání, nebo nevyužití potenciálu této
technologie. Podívejme se tedy, jaké možnosti ODBC nabízí.Standard ODBC je v
současnosti stále nejrozšířenější technologií pro přístup k datům. Tento
produkt byl vytvořen firmou Microsoft. Z toho plyne, že je určen pro prostředí
Windows v posledních verzích pak pouze pro jejich 32bitovou variantu.
Specifikace první verze ODBC byla vytvořena v roce 1992, ale první implementace
byla k dispozici až o rok později. Od té doby prodělalo ODBC bouřlivý vývoj a v
nedávné době byla uvedena verze 3.5. Nových vlastností však již v poslední době
ubývá, neboť Microsoft již dává prioritu svému novému standardu OLE DB.
Vzhledem k tomu, že bylo ODBC na počítačích s Windows první technologií svého
druhu, nese si s sebou některé vlastnosti, na které dnes již můžeme pohlížet
jako na archaické.
Architektura řešení
ODBC používá vrstevnatou architekturu. Jedna z vrstev přijímá požadavky od
klienta a řídí zpracování dat (budeme jí říkat jádro) a druhá vrstva zajišťuje
komunikaci s konkrétním databázovým serverem (té budeme říkat ovladač). Jádrem
ODBC je "ODBC Driver Manager", který je fyzicky reprezentován .DLL knihovnou.
Driver Manager má jedno API rozhranní, které je určeno pro aplikace a jehož
prostřednictvím je nabízena funkcionalita ODBC. ODBC Driver Manager komunikuje
dále s jednotlivými ovladači (jsou také ve formě .DLL knihoven).
Driver Manager za běžných okolností odstiňuje aplikaci od komunikace s
ovladačem. Současně řídí, jaké ovladače budou nataženy do paměti nebo naopak
uvolněny.
Ve většině případů funguje Driver Manager pouze jako most, který převádí volání
ODBC na identické volání ovladače. Provádí však i základní validaci parametrů
volaných funkcí. Některé funkce ODBC API jsou implementovány přímo v něm.
Konfigurace ODBC
Pro konfiguraci ODBC se používá program ODBC Administrátor. Ten je standardně
instalován do Ovládacích panelů Windows, ale je možné jej spouštět i přímo.
ODBC Administrátor umožňuje zejména manipulovat s aliasy (vytvářet, modifikovat
a mazat je). Dále tento program umožňuje nastavovat sdílení databázových
připojení (Connection Pooling), trasování ODBC volání a další systémové
parametry. Podrobněji jsou všechny tyto činnosti popsány dále.
Jak již bylo naznačeno, rozhraní ODBC je v podobě API. Toto rozhraní je tudíž
vhodné spíše pro vývojové nástroje, pracující na nižší úrovni (jako je např.
C++). Přesto je však v ODBC uplatňován objektový přístup. Ačkoliv to explicitně
autoři ODBC neuvádějí, lze v architektuře ODBC vystopovat pět objektů (viz 1.
obr.).
Databázová spojení
Driver Manager reprezentuje veškeré funkce, které se týkají celého prostředí
ODBC. Spravuje také jednotlivé instalované databázové ovladače. Tyto ovladače
se starají o zpracování veškerých dotazů a funkcí pro manipulaci s daty. Přes
každý ovladač může být realizováno více připojení k různým datovým zdrojům
(odpovídajícího typu).
Na každém databázovém spojení může být aktivní jeden nebo i více příkazů. Mohou
to být běžné SQL dotazy, ale také příkazy pro zjišťování dostupných tabulek.
Některé příkazy generují také resultset tj. výsledek v podobě tabulky, který je
generován zejména dotazy typu SELECT. Po resultsetu je možné se pohybovat
pomocí kurzoru. Ke každému resultsetu (dotazu) je u ODBC možné vytvořit pouze
jeden kurzor. Možnosti pohybu kurzoru po resultsetu jsou dány typem
databázového ovladače (viz dále).
Jak již vyplynulo z výše uvedeného, většina komunikace s datovým zdrojem je v
ODBC vedena v jazyce SQL. Speciální funkce (které nejsou založené na SQL) jsou
vytvořeny pouze pro zjišťování informací ze systémového katalogu.
Zpracování dotazů
Zpracování dotazů je v architektuře ODBC zcela řešeno ovladačem. Ten má dvě
možnosti buď může dotazy zpracovávat sám lokálně, anebo může dotaz odeslat na
databázový server. Druhý případ připadá v úvahu pouze u klient-serverových
databázových systémů, neboť s desktopovými databázemi obvykle nelze komunikovat
v jazyce SQL.
Jelikož ODBC nemá vlastní "Query Processor", vznikají u ODBC problémy v
případě, že je potřeba vytvořit dotaz do heterogenních datových zdrojů nebo
použít jednotnou SQL gramatiku v programu pro komunikaci s datovými zdroji
různých typů.
Pro první případ ale nabízí ODBC náhradní řešení. Jako ODBC ovladač je totiž
možné použít nějaký "Query Engine", který bude schopen takový dotaz do
heterogenních datových zdrojů zpracovat. Tento "Query Engine" může dále získat
přístup k jednotlivým datovým zdrojům také přes ODBC.
Aliasy
ODBC umožňuje vytvářet pojmenovaná spojení na konkrétní datové zdroje. Každé
toto pojmenované spojení s sebou nese informace o konfiguraci přístupu k tomuto
zdroji. V originální terminologii se těmto pojmenovaným připojením říká poněkud
zavádějícím pojmem "Data Source". Proto budeme používat neutrálnějšího názvu
"Alias". S aliasy se setkáváme u jiných technologií přístupu k datům.
Specifickou vlastností je, že ODBC rozlišuje podle způsobů uložení 3 druhy
aliasů:
Systémové systémové aliasy jsou uloženy ve společné části registrační databáze
Windows a jsou tudíž použitelné pouze na daném počítači. Tento typ aliasů je
vhodný pro takové aplikace, které jsou provozovány všemi uživateli na daném
počítači a nebo takové aplikace, které jsou provozovány bez přihlášení
uživatele (různé služby, pracující na pozadí).
Uživatelské uživatelské aliasy jsou uloženy v uživatelské části registrační
databáze Windows a jsou tudíž použitelné pouze jedním uživatelem (a dle způsobu
instalace Windows také možná jen na daném počítači). Tento typ aliasů je vhodný
pro takové aplikace, kde každý uživatel používá jiné nastavení databázového
připojení. Jelikož takový alias není jiným uživatelům přístupný, mohou se u
aplikací, nepříliš náročných na bezpečnost, uložit údaje pro autentizaci
uživatele přímo do aliasu.
Souborové souborové aliasy jsou uloženy v malém souboru (.dsn) v souborovém
systému (lokálním nebo síťovém). Vhodným umístěním souboru s aliasem můžeme
regulovat přístup uživatelů k aliasu. Takové aliasy mohou být snadno s aplikací
kopírovány a centrálně administrovány. Tento typ aliasů může také jako jediný
být snadno sdílen na síti v rámci celé organizace.
Systémové a uživatelské aliasy se někdy souhrnně nazývají "strojové aliasy"
(machine aliases). Možnost správy nakonfigurovaných a pojmenovaných připojení k
databázím jsou u ODBC velmi flexibilní.
ODBC také nenutí vývojáře k používání aliasů. Pomocí ODBC API je možné oslovit
konkrétní ovladač a ten spojit s datovým zdrojem. Tento režim práce je vhodný
spíše pro různé "databázové utility", které potřebují často komunikovat s
různými zdroji, které nejsou pojmenované. Pro klasické aplikace, které pracují
stále se zdrojem jedním, jsou aliasy stále optimální variantou.
Chyby a diagnostika
Prakticky u všech typů aplikací je potřeba korektně zajistit ošetření chybových
stavů. Aplikace, založené na ODBC tedy musejí být také schopny diagnostiky chyb.
Každá funkce ODBC vrací nějakou hodnotu. Tato hodnota indikuje, jestli volaná
funkce proběhla úspěšně nebo nikoliv. V případě, že vrácená hodnota indikuje
nějakou chybu, je třeba získat podrobnější chybové hlášení. Pro získání
podrobnějšího chybového hlášení slouží funkce SQLGetDiagRec a SQLGetDiagField.
Chybová hláška, která je prostřednictvím těchto funkcí získána, je v přesně
definovaném tvaru a obsahuje např. jméno ovladače, který chybu vygeneroval a
případně jméno použitého aliasu. Dále je také vrácena chybová informace v
"nativním tvaru". Tento "nativní tvar" je specifický pro databázový ovladač a
neexistuje žádný obecný způsob, jak takovým chybám porozumět.
Diagnostika jde u ODBC poměrně daleko. Rozpoznat je možné snadno nejen chybový
stav od bezchybného, ale ODBC nabízí také univerzálně použitelný číselník
častých typů chyb. I v obecné aplikaci, která není vytvářena pro jeden
konkrétní databázový ovladač, je možné v okamžiku, kdy nastane nějaká chyba,
nejen ji zobrazit uživateli, ale podle typu chyby modifikovat chování aplikace
a snažit se chybu obejít.
Pro podporu vývojářů také ODBC umožňuje zachytávat volání ODBC a ukládat tyto
informace do žurnálu (Logu). Tyto informace mohou přispět ke snazšímu
vyhledávání chyb při ladění aplikací.
Translátory
Obvyklým problémem v prostředí klient server je kódování národních znakových
sad. Server a klient totiž často používají jiné kódování národních sad. Pokud
má např. server provádět správné třídění, je třeba, aby data byla na serveru
uložena ve správném kódování národních znaků kterým server rozumí a umí je
správně třídit. Na druhou stranu je ale zase potřeba, aby na klientském
počítači byly informace zobrazeny správně v kódování klienta. Z tohoto důvodu
je často potřeba provádět mezi serverem a klientem překlad znakových sad.
V ODBC je tento problém řešen komplexně. V systému mohou být zaregistrovány DLL
knihovny, které zajišťují překlad textových řetězců v národním kódování. Tyto
knihovny se označují jako "překladatelé" (translators). Těchto knihoven může
být v systému zaregistrováno několik a všechny fungují se všemi ovladači.
Implementace takové knihovny je poměrně jednoduchá stačí implementovat funkce
SQLDriverToDataSource a SQLDataSourceToDriver.
Connection pooling
Poslední verze ODBC umožňují také zvýšit výkon databázových aplikací
následujícím způsobem: Kdykoliv je nějaké spojení k databázi vytvořeno, je
přidáno do sdíleného zásobníku (Connection pool), ze kterého může být převzato
jinými aplikacemi. Jelikož spojení nemusí být znovu sestavováno, ušetří se tím
nějaký čas. Tento čas je poměrně malý a některý typ aplikací (zejména webové
aplikace) provádějí připojování k databázi velmi často na velmi krátkou dobu.
Spojení k databázi může být také sdíleno více komponentami v rámci jednoho
procesu.
"Connection Pool" je spravován Driver Managerem. Spojení na databázi je vyjmuto
ze zásobníku, když jej nějaká aplikace začne používat (zavolá funkci SQLConnect
nebo SQLDriverConnect). Do zásobníku je naopak vráceno, když aplikace přestane
spojení využívat (zavolá funkci SQLDisconnect). Pokud spojení, uložená v
zásobníku, nejsou využívána po nějakou delší dobu, jsou ze zásobníku zcela
odstraněna, aby zbytečně nebyly blokovány systémové prostředky.
Aby bylo možné spojení na databáze sdílet, ovladač musí podporovat několik
funkcí. Jednak musí být schopen (na pokyn "Pool Manageru") zjistit, jestli je
spojení na databázi ještě aktivní jestli nedošlo např. k odpojení od sítě.
Ovladač také musí bezpečně podporovat multithreading (běh ve více vláknech).
Pokud chce aplikace využívat "Connection pooling", musí při inicializaci o tuto
službu ODBC požádat.
Ovladače
Dokumentace ODBC rozlišuje 2 typy ODBC ovladačů souborové ovladače (File-Based
Drivers) a databázové ovladače (DBMS-Based Drivers). Toto rozdělení
databázových systémů odpovídá přibližně výše uvedené definici desktopových
databází a klient-serverových databází. Z pohledu ODBC však mezi těmito typy
ovladačů nejsou žádné podstatné rozdíly.
Rozhraní pro tvorbu ovladačů je u ODBC zveřejněno. Výrobci databázových systémů
tedy mohou ke svým produktům dodávat ODBC ovladač a tak zpřístupnit databázový
systém mnoha různým existujícím aplikacím. Je také třeba upozornit, že některé
ODBC ovladače mohou vyžadovat lokální instalaci klientského prostředí
příslušného databázového systému.
Dobře je u ODBC řešena konfigurace databázových připojení. Každý ovladač totiž
potřebuje úplně jinou sadu parametrů a každý provádí jejich jinou validaci.
Tyto záležitosti by bylo obtížné provádět obecně.
ODBC tudíž šlo jinou cestou. Každý ovladač provádí konfiguraci databázových
připojení sám. Když uživatel v ODBC Administrátoru zvolí vytvoření nového
aliasu, ODBC Administrátor vyvolá ovladač a zavolá SQLConfigDataSource a tato
funkce se postará o zobrazení dialogového okna. Tvůrce ovladače si sám toto
okno navrhuje, sám vytvoří programový kód pro validaci vkládaných hodnot apod.
Tuto funkci lze také použít pro "tiché" vytvoření nějakého aliasu jako
parametry se při vyvolávání této funkce uvedou parametry pro alias. Problém je,
že ten, kdo funkci vyvolává, musí znát parametry, které příslušný ovladač
vyžaduje pro vytvoření aliasu.
Dostupnost ovladačů je asi nejsilnější stránkou ODBC. Dostupných ovladačů jsou
v současné době stovky a prakticky neexistuje databázový systém, ke kterému by
nebyly k dispozici. Pro některé databázové systémy zejména pro desktopové
databáze a pro starší klient-serverové databáze bývá často k dispozici více
ovladačů od různých dodavatelů. Tyto ovladače se od sebe zpravidla liší zejména
podporovanou funkcionalitou (viz dále) a podporou různých verzí databázového
systému. U nových klient-serverových databází dodává ODBC ovladače sám
dodavatel. V takovém případě je pochopitelně nejvhodnější použít jeho ovladač.
Úrovně podpory API
Jednotlivé technologie pro přístup k datům se musejí vyrovnávat s různými
úrovněmi podporované funkcionality u různých typů databázových systémů a
potažmo u různých ovladačů. ODBC definovalo 3 úrovně funkcionality, které jsou
označovány jako Core (Level 0), Level 1 a Level 2. V anglické literatuře jsou
tyto úrovně funkcionality označovány jako "Conformance levels". Tyto úrovně na
sebe navazují tedy např. Level 2 obsahuje vše, co vyžaduje Level 1. Každý
ovladač musí specifikovat, jakou úroveň funkcionality podporuje. Přesněji
řečeno ovladač deklaruje, jaké požadavky z hlediska jejich úrovně splňuje
bezezbytku. Ovladač může podporovat více, ale nikoliv méně. Aplikace si zase
může kdykoliv pomocí funkce SQLGetInfo zjistit, jakou funkcionalitu může od
ovladače očekávat.
Podporovaná funkcionalita u jednotlivých úrovní je v ODBC ve verzích 3.x
definovaná takto:
Core Tato úroveň podpory je určena pro nejjednodušší desktopové databázové
systémy. Tato úroveň zahrnuje pouze základní operace, jako je načítání
resultsetu, pohyb resultsetem směrem dopředu, spouštění SQL příkazů nebo
potvrzování transakcí (COMMIT) avšak nikoliv rušení transakcí. Ovladač také
musí podporovat napojování sloupců v resultsetu na vyhrazená místa v paměti
(pomocí funkce SQLBindCol) a pracovat s parametry v dotazech. Vyžadována je též
podpora základních funkcí pro práci se systémovým katalogem zjišťování
informací o tabulkách a sloupcích, datových typech apod. V této úrovni je také
vyžadovaná podpora zjišťování podporovaných skalárních funkcí a datových typů.
Rovněž je zde podporována diagnostika a základní práce s chybami.
Level 1 V této úrovni je přidávána větší podpora pro práci se systémovým
katalogem. Je vyžadována podpora práce s uloženými procedurami a pohledy,
ovladač musí umět zjišťovat primární klíč tabulky a zobrazit dostupné (lokální)
databázové servery (se kterými je schopen spolupracovat). Důležitá je podpora
obousměrných kurzorů. Dále přibývá podpora rušení transakcí (ROLLBACK), podpora
asynchronního vyvolávání funkcí, podpora práce s více resultsety (např. od
uložené procedury).
Level 2 Tato úroveň podpory je nejvyšší. Vyžaduje podporu práce s databázovými
zámky, podporu izolačních úrovní transakcí (isolation levels) a práci s
uživatelskými oprávněními (jejich zjišťování ze systémového katalogu).
Vyžadována je též podpora "záložek" u kurzorů.
SQL gramatika
Aby ale situace nebyla příliš jednoduchá, ODBC definuje ještě 3 úrovně podpory
SQL gramatiky, které musí ovladače podporovat. Každý ovladač tedy deklaruje
úroveň podpory API funkcí a nezávisle na tom úroveň podpory SQL gramatiky.
Úrovně SQL gramatiky jsou odvozeny z úrovní, které specifikuje standard ANSI
SQL-92. Jak už bylo uvedeno, ODBC definuje 3 úrovně SQL gramatiky minimal, core
a extended. Opět tyto úrovně jsou inkrementální (core splňuje všechny požadavky
úrovně minimal). Podívejme se tedy na úroveň podpory podrobněji:
Minimal Tato úroveň podporuje pouze základní operace. Podporovány jsou příkazy
CREATE TABLE, DROP TABLE, DELETE FROM WHERE, INSERT INTO VALUES, UPDATE SET
WHERE a SELECT FROM WHERE ORDER BY. Pracuje pouze s datovými typy CHAR, VARCHAR
a LONG VARCHAR.
Core V této úrovni jsou přidány příkazy pro práci s indexy, restrukturalizaci
tabulek, agregační funkce a funkce pro práci s uživatelskými právy. Přidány
jsou zde také další numerické datové typy.
Extended Tato nejvyšší úroveň SQL gramatiky přidává podporu "outer joinů",
zamykání (SELECT FOR UPDATE), skalární funkce a podporuje datové typy datum a
čas.
Detailní informace o jednotlivých úrovních podpory (ať již funkcionality API
nebo SQL gramatiky) je možné dohledat v dokumentaci k ODBC, která je mimo jiné
součástí MSDN.
Aplikace je při běhu schopna všechny detaily o podpoře získat pomocí funkce
SQLGetInfo. Tato funkce je schopna popsat driver pomocí několika desítek
atributů, které definují určité příznaky funkcionality.
Jak získat ODBC
ODBC je sice instalováno na kdejakém počítači, ale kde získat "čistou" a
aktuální instalaci? Ta je dodávána k většině vývojových nástrojů od Microsoftu,
jako součást vývojářské služby MSDN a lze ji také zdarma získat na Webu
Microsoftu.
Pro provoz ODBC v českých zemích může být vhodné používání lokalizované verze,
kde je administrační program a základní sada ovladačů v české podobě. Tuto
lokalizovanou verzi je nejlépe získat na webových stránkách Microsoftu a je
také součástí MSDN.
Všechny jazykové verze je možné za splnění jistých podmínek šířit s aplikacemi.
Tyto podmínky jsou podrobně popsány v licenčních smlouvách a na Webu Microsoftu.
Závěr
Doufáme, že tento přehled vlastností a architektury ODBC vám umožní udělat si
přesnější obrázek o fungování této technologie. Snad budete mít díky uvedeným
informacím možnost předejít mnohým problémům, které vycházejí z nepochopení
možností a limitů této technologie.
0 2285 / pen
Zaostřeno na odbc
ODBC je sice co do funkcionality do značné míry překonáno, avšak dodnes je de
facto standardem. Pro tuto technologii je k dispozici nejvíce ovladačů k
nejvíce databázovým systémům. Jelikož je rozhraní pro tvorbu ovladačů
zveřejněné, není problém vytvářet ovladače vlastní. Jádro ODBC neimplementuje
téměř žádnou funkcionalitu veškerá funkcionalita leží na jednotlivých ODBC
ovladačích. Pokud jde o ovladače od klient-serverových databází, jsou veškeré
požadavky dále přenášeny na databázový server. Jelikož tato technologie
nepřináší žádný sdílený dotazovací stroj (Query Engine), jsou problémy se
zpracováním dotazů do heterogenních datových zdrojů, s nejednotnou SQL
gramatikou a s vytvářením ovladačů pro datové zdroje, které SQL nativně
nepodporují.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.