3 Suhtlus andmebaasidega

Kõik tänapäevased infosüsteemid põhinevad mingitel andmetel. Infosüsteem hoiab andmebaasis kasutajate andmeid, kasutajad saavad teha päringuid andmebaasi, muuta seal andmeid, lisada andmeid. Andmete põhjal tehakse erinevaid aruandeid, nende põhjal analüüsitakse kasutajate soove, mis võimaldab süsteemi paremaks teha. Seega võib öelda, et andmed on üheks väga tähtsaks osaks infosüsteemis. Andmeid võib hoida tavalise tekstifailina või säilitada neid erinevate võimalustega andmebaasisüsteemides – relatsioonilistes või mitte.

Selleks, et süsteem andmebaasi kasutada saaks, on võimalik kasutada erinevaid vahendeid:

  • Võib kasutada andmebaasi poolt pakutud vahendeid. Selliste vahendite miinuseks on asjaolu, et andmebaasi vahetuse korral tuleb tavaliselt teha suuri muutusi kogu infosüsteemis.
  • Võib kasutada standardvahendeid, mis on mõeldud üldiseks kasutamiseks. Selliste vahendite eeliseks on asjaolu, et need võimaldavad vähese vaevaga vahetada andmebaasisüsteemi – muutusi tuleb teha ainult selles osas, mis kasutab konkreetse andmebaasisüsteemis spetsiifilisi omadusi.
Microsoft Windows keskkonnas kasutatakse andmebaasidega suhtlemiseks universaalset andmeühendust (Universal Data Access). Universal Data Access on Microsofti poolt kirjeldatud allikas [20, vaata »].

Universal Data Access (UDA) on kujunenud Microsofti strateegiaks võimaldamaks juurdepääsu suvalistele andmetele suvalises kohas. UDA annab võimsad vahendid suhtlemaks erinevate andmekogudega (relatsiooniliste või mitte-relatsioonilistega), annab lihtsad programmeerimiskeelest sõltumatud tehnoloogiad suhtluse teostamiseks. Need tehnoloogiad võimaldavad luua süsteeme, mis on lihtsalt hallatavad, mida on võimalik kasutada erinevates keskkondades ja platvormidel. UDA ei nõua andmete koondamist ühte punkti ega ühe konkreetse toote kasutamist; UDA põhineb avatud süsteemidel ja toetab lai-süsteeme ning töötab enamustel levinud andmebaasi-platvormidel. UDA on samm edasi levinud tehnoloogiatest nagu ODBC, RDO ja DAO, samas ta laiendab nende tuntud tehnoloogiate võimalusi.

Microsoft Data Access Components (MDAC) komponendid teevad võimalikuks UDA kasutamise. Nendeks komponentideks on ActiveX Data Access (ADO), Remote Data Service (RDS, varem tuntud Advanced Database Connector (ADC) nime all), OLE DB ja Open Database Connectivity (ODBC). Järgmine pilt illustreerib MDAC komponentide koostööd:

Joonis 3.1 Microsoft Data Access Components komponentide töö
Joonis 3.1 Microsoft Data Access Components komponentide töö

ADO ja OLE DB tööd Internetis illustreerib järgmine pilt:

Joonis 3.2 ActiveX Data Objects ja OLE DB töö internetirakendustes
Joonis 3.2 ActiveX Data Objects ja OLE DB töö internetirakendustes

3.1 OLE DB

Tänapäeva ärilahendused ei koosne ainult üksikutest lauaarvutitest ega neis töötavatest rakendustest, vaid tänapäevane rakendus ühendab endas lauaarvuteid, suurarvuteid ja Interneti tehnoloogiaid. Erinevate kasutuses olevate andmehoidlate hulk ja neis sisalduvate andmete erinevad kasutusviisid nõuavad, et rakendused suudaksid kasutada nii vana lähenemisviisi (üksikarvuti), kui uut (laivõrkude kasutamine). Selle tulemusena tekkis nõue lihtsalt kasutatava ja hallatava andmeühenduse süsteemi jaoks. OLE DB ongi spetsifikatsioon, mis kirjeldab hulga andmetega suhtlemiseks vajalikke liideseid, mis lubavad kasutada suurel hulgal suvalist tüüpi või suurust omavaid andmehoidlaid, seejuures garanteerides liideste koostöö. OLE DB on Microsofti poolt kirjeldatud allikates [21, vaata »] ja [22, vaata »].

OLE DB liidesed moodustavad omaette andmesuhtluse harustandardi, mis tagab erinevate andmete kooskõla ja koostalitusvõime. OLE DB on arenenud tavalisest andmeühendusest kaugemale paigutades kogu relatsiooniliste andmebaasidega suhtlemiseks vajaliku funktsionaalsuse loogilistesse komponentidesse luues neile komponentidele ka suhtlemiseks vajalikud sündmused (events). Neid liideseid kasutades on võimalik luua väga lihtsaid andmetarnijaid (data providers), samas on võimalik luua väga keerulisi relatsioonilisi andmebaasisüsteeme. Tänu sellele saab luua selliseid komponente, mis paistavad tavaliste tabelitena, kuid tegelikult võib kõige selle taga olla väga keeruline funktsionaalsus.

3.1.1 OLE DB omadused ja kasulikkus

OLE DB omab mitmeid omadusi, mis teevad selle kasutamise väga mugavaks ning muudab OLE DB väga kasulikuks:

  • Ligipääs kõikidele andmetele sõltumata andmete formaadist või asukohast. See võimaldab kasutada mitte ainult andmebaase, vaid ka näiteks failisüsteemi saab vaadelda andmetena; samas ei pea andmed enam asuma samas arvutis, isegi mitte kohalikus võrgus.
  • Lihtsam programmeerida. Kui kasutada OLE DB omadusi, ei pea iga uue andmeformaadi jaoks lisatööd tegema, kuna OLE DB andmetarnijad teevad selle töö programmeerija eest.
  • Andmekesksed komponendid. OLE DB komponendid võimaldavad suhelda teiste komponentidega, samas ise ainult andmetega tegeledes.
  • Komponendid võivad käituda virtuaalsete tabelitena. Enamus graafilisi arendusvahendeid loevad andmetabeleid automaatselt, samas komponentidest andmete saamine võib osutuda keeruliseks, OLE DB komponendid on võimelised end esitlema kui tabel-kujul andmeid ja arendusvahenditel on neist lihtne aru saada.
  • Integreeritus Microsofti toodetega.
  • Täielik integreeritus ODBC-ga. OLE DB-d kasutavad vahendid omavad täielikku juurdepääsu ODBC draiveritele ja andmetele.

3.1.2 OLE DB ei ole ODBC asendus

ODBC-d peetakse heaks relatsiooniliste andmebaasidega suhtlemise vahendiks, aga kui tegemist ei ole SQL-il põhinevate andmetega, siis võib ODBC võimalustest väheseks jääda. Samas on OLE DB andmetarbijatele loodud kõik võimalused suhtlemaks ODBC tarnijatega. Järgnevad punktid aitavad valida kumba tehnoloogiat kasutada:

  • kui soovitakse kasutada standardseid relatsioonilisi andmebaase, on ODBC parim lahendus;
  • kui soovitakse luua andmeliides mitte-SQL andmetele, on OLE DB parim lahendus;
  • kui programmeeritakse OLE keskkonnas, on OLE DB parim lahendus;
  • kui soovitakse luua andmebaasi komponente, on OLE DB ainus lahendus.
Kahe liidese tehnilised erinevused on toodud järgmises tabelis:
ODBC OLE DB
Andmeühendus Andmebaasi komponendid
Programmeerimiskeele (C) tase Komponendid (Component Object Model – COM)
SQL-põhised andmed Tabelipõhised andmed
SQL-põhised standardid COM-põhised standardid
Andmebaasipõhised tarnijad Komponent-arhitektuur
Tabel 3.1 OLE DB ja ODBC tehniline võrdlus

3.1.3 Milleks kasutatakse OLE DB-d?

Tarkvara loojad, kes kasutavad OLE DB võimalusi loovad nelja tüüpi süsteeme: andmetarnijad (data providers), andmetarbijad (data consumers), andmeteenuste tarnijad (data service providers) ja ärikomponendid (business components).

Andmetarnijad võivad olla suvaliste andmete edastajad rakendusele. Andmeteks ei pea olema relatsioonilised andmebaasisüsteemid (nendega suhtlemiseks võib kasutada ka ODBC-d), andmeteks võib kasutada kõike alates väga lihtsatest andmeformaadid nagu logifailid ja lõpetades väga keeruliste süsteemidega nagu näiteks e-maili süsteemid ja ADABAS süsteemid. OLE DB võimaldab luua ka kirjete (kirjehulga) liideseid andmetele, mis teeb andmetarnija kasutamise lihtsamaks.

Andmetarbijad on rakenduste osad, mis vajavad oma tööks andmeid, siin sisalduvad ka arendusvahendid, programmeerimiskeeled jms. Kõik need rakendused kasutavad mingil moel andmeid, tavaliselt kasutatakse andmete saamiseks andmetarnijaid.

Andmeteenuste tarnijad kujutavad endast andmebaasi komponente nagu päringu- või kursormootor (cursor engine), mis on iseseisvad tooted ja suudavad samal ajal suhelda olemasolevate OLE DB andmetarnijatega.

Sel ajal kui rakendused laienevad laivõrkudesse, muutuvad üha tähtsamaks korduvakasutusega ärikomponendid, mis võivad asuda nii kohalikus kui kaugarvutis. Korduvkasutusega komponentidesse koondatakse funktsionaalsus, mida on vaja mitmes rakenduses – igas rakenduses pole mõtet sama funktsionaalsust uuesti looma hakata, piisab olemasoleva komponendi kasutamisest. OLE DB ärikomponendid koondavad endas põhiliselt andmetega suhtluseks vajaminevat funktsionaalsust.

Hetkel eksisteerivatest OLE DB toodetest annab ülevaate lisa 2; kõige värskemad andmed võib leida allikast [23, vaata »].

3.1.4 Kus kasutatakse OLE DB liideseid?

OLE DB liidesed on kasulikud kõikidele tarkvara loojatele, kelle tooted kasutavad mingil moel mingeid andmeid. Järgnevas on toodud vaid mõned näited, kus OLE DB osutub kasulikuks:

  • Ärimaastikul tehakse pidevalt arvutusi, milles on vaja koguda andmeid mitmetest kohtadest – andmeid on vaja saada kiiresti, neid on vaja kiirelt analüüsida, uusi tehinguid on vaja väga kiirelt sooritada.
  • Tööstuses kasutatakse süsteeme (CAD/CAM), mis garanteerivad, et teatud osad on alati kõige uuemad. Selleks on vaja süsteemil pidevalt suhelda nende osade tootjate andmebaasidega.
  • Kindlustuses on tähtis, et kindlustusagendid oleksid pidevalt ühenduses oma peaserveriga. Ka siis, kui nad viibivad kliendi juures (oma kontorist eemal) – sellisel juhul on väga tähtis andmete edastuse kiirus ja samas ka turvalisus.
  • Kõikjal kasutatakse e-maili süsteeme kui kriitilisi andmeallikaid (data source) – süsteemist saab filtreerida andmeid (maile), neid grupeerida jne.

3.2 ADO

ActiveX Data Objects (ADO) on Microsofti strateegiline kõrgtaseme liides erinevate andmetega suhtlemiseks. Täieliku ülevaate ADO-st ja tema kasutusvõimalustest annavad allikas [24, vaata »] ja [25, vaata »].

3.2.1 ADO ülevaade

ADO võimaldab kokkuhoidlikku kõrgtasemelist andmete juurdepääsu, mis omakorda lubab luua lõppkasutaja andmebaasi kliente ja äriobjekte mitmekihilises infosüsteemis kasutades selleks erinevaid rakendusi, vahendeid, programmeerimiskeeli või kasvõi Interneti brauserit. ADO on ainus andmebaasi liides mida on vaja tunda loomaks ühe kuni mitmekihilisi klient/server või veebipõhiseid andmebaasi lahendusi. ADO peamised eelised on kiirus, lihtsus, vähene mälu- ja kettaruumi vajadus.

ADO omadused, mis võimaldavad luua klient/server ja veebi süsteeme, sisaldavad järgnevat:

  • Sõltumatult loodavad objektid. Kui tavaliselt tuleb objekte (ODBC ühendus, päring jt.) luua kindlas järjekorras, siis ADO võimaldab iga sellist objekti (va. vea- ja väljaobjekt) sõltumatult luua. See võimaldab kokku hoida programmeerimise aega ja ka suurendab rakenduste efektiivsust.
  • Uuendatavaid andmeid võimaldatakse hoida (koguda) lokaalselt, et siis kõik korraga serverile saata.
  • Eelnevalt defineeritud sisend-väljundandmetega protseduuride toetus.
  • Erineva iseloomuga päringuobjektide loomine.
  • Päringuparameetrite toetus (nt. kindla ridade arvuga päring).
  • Mitme kirjehulga objekti (Recordset) tagastuse toetus eelsalvestatud protseduurides.
  • Eraldiseisvad (ja töötavad) objektid rakendustes.

ADO võimaldab lihtsalt kasutada andmetega suhtlemiseks vajalikke objekte. Järgmisel joonisel on toodud ADO objektid ja nendevahelised suhted:

Joonis 3.3 ActiveX Data Objects objektid ja nendevahelised suhted
Joonis 3.3 ActiveX Data Objects objektid ja nendevahelised suhted

Nagu jooniselt selgub, pole kõik objektid kohustuslikud. Seejuures pole tegelikult ka näiteks Connection objekt kohustuslik, mis tähendab, et Recordset objekti võib luua kasutades Connection objekti meetodit Execute, kuid samas saab Recordset objekti luua ka ilma esmalt Connection objekti loomata (andes kogu ühenduse loomiseks vajaliku info kirjehulga objekti avamisel parameetrina).

3.2.2 ADO objektid

Kuigi ADO objektid on sõltumatult loodavad ja kasutatavad, eksisteerivad nende vahel siiski hierarhilised suhted:

ADO objektide hierarhia

Mõnel objektil on määratud kogumid, meetodid ja atribuudid (properties):

ADO kogumid ja atribuudid

ADO defineerib mitmeid objekte võimaldamaks ühendust andmebaasidega, päringute ja muudatuste tegemist andmebaasis jne. Järgnevas antakse ülevaade ADO objektidest ja nende omavahelistest seostest. Iga objekti juures on näidatud selle objekti kogumid ja kui objekt sõltud mõnest objektist, siis ka see.

Ühenduse objekt (Connection) esindab unikaalset sessiooni (ühendust) andmetega (andmebaasiga).

Ühenduse objekt
Tavalise klient-server süsteemi puhul võib ühenduse objekt esindada reaalset võrguühendust kliendi ja serveri vahel. Ühenduse objekt võimaldab:
  • määrata ühenduseks vajalike atribuutide väärtused enne ühenduse loomist;
  • määrata, kus luuakse kursorid (cursor) – kas serveris või kliendi pool;
  • määrata vaikimisi valitavat andmebaasi;
  • määrata transaktsioonide isoleerituse taset;
  • määrata andmeallika tarnija (OLE DB provider);
  • luua ja katkestada ühendust andmetega;
  • täita käske (käsuobjekt) – teha päringud, muuta andmeid, käivitada salvestatud protseduure jne; kui käsk tagastab andmekirjeid, siis luuakse ja tagastatakse kirjehulga objekt;
  • hallata transaktsioone: alustada ja lõpetada transaktsioon, luua transaktsioone üksteise sisse (kui andmetarnija seda võimaldab);
  • tagastada vigade kogumi (Errors).

Käsuobjekt (Command) esindab käsku (päring, lause), mida saab rakendada andmeallikale.

Käsuobjekt
Käsuobjekt võimaldab:
  • defineerida käsu teksti (näiteks SQL lauset);
  • defineerida parameetritega päringuid või salvestatud protseduuride väljakutseid kasutades Parameters kogumit ja Parameter atribuute;
  • käivitada käske, mis tagastavad kirjeid – selle tulemusena luuakse ja tagastatakse kirjehulga objekt;
  • määrata käsu tüüpi optimiseerimaks käsu täitmist – nt tüüp võib määrata, et käsk on salvestatud protseduur või tagastab kõik read tabelis;
  • määrata, kas käsk salvestatakse enne täitmist – käsk kontrollitakse (kompileeritakse) enne täitmist ja salvestatakse; see toiming võib küll esimest käsu täitmist aeglustada, kuid kui käsku täidetakse mitmeid kordi, siis järgmised täitmised on tunduvalt kiiremad;
  • määrata käsu täitmise aegumist (aeg, mille jooksul peab käsk saama täidetud või sellest loobutakse);
  • siduda käsuobjekti ühenduse objektiga;
  • määrata objektile nimi, mille abil ühenduse objekt saab käsuobjekti välja kutsuda;
  • saata käsuobjekti kirjehulga objektile saamaks andmeid.
Käsuobjekt pole tegelikult kohustuslik, kuna kirjehulga objekt on võimeline päringuid teostama kasutades SQL lauseid. Kui aga soovitakse käsu salvestamist või kasutada parameetreid, siis on käsuobjekt vajalik. Samas ei toeta mõned andmetarnijad käsuobjekte.

Parameetri objekt (Parameter) esindab parameetritega päringut või salvestatud protseduuri esitava käsuobjekti parameetrit või muutujat. Parameetri objekt on kasutatav läbi Parameters kogumi.

Parameetri objekt
Paljud andmetarnijad toetavad parameetritega käske – need on käsud, kus tegevus defineeritakse ainult ühe korra, aga muutujate (või parameetritega) muudetakse käsku (nt saab parameetriga määrata päringu tingimuse või sorteeritava välja). Parameetrid võivad olla ka salvestatud protseduuride sisend-väljund muutujad või tagastatavad väärtused. Parameetri objekt võimaldab:
  • luua parameetreid;
  • lisada parameetreid Parameters kogumisse;
  • seada või tagastada parameetri nime;
  • seada või tagastada parameetri väärtust;
  • seada või tagastada erinevaid parameetrit iseloomustavaid argumente (nt Type – tüüp, Size – suurus);
  • edastada suuri andmemahte parameetritele.
Sõltuvalt andmetarnija funktsionaalsusest võib osa parameetri objekti funktsionaalsusest puududa.

Kirjehulga objekt (Recordset) esindab kogu päringu tulemusena tagastatud kirjete hulka. Samas on võimalik korraga vaadelda ainult ühte konkreetset kirjet.

Kirjehulga objekt
Kirjehulga objekt on ADO põhiline objekt, millega toimub töö andmetega. Kõik Kirjehulga objektid koosnevad kirjetest (Record, tabeli rida) ja väljadest (Field, tabeli veerg). Kirjehulga objekt esindab andmebaasi kursorite kogu funktsionaalsust ja sellest tulenevalt on objekt ka ADO keerulisim objekt. ADO defineerib neli kursori tüüpi:
  • Dynamic kursor lubab näha objekti tagastatud andmete muutusi ja lisamisi, mis toimuvad sel ajal, kui kirjehulga objekt on avatud; lubatud on ka erinevad liikumised kirjete vahel; samuti lubatakse järjehoidjast (bookmark) sõltuvaid liikumisi, kui andmetarnija seda võimaldab.
  • Keyset kursor käitub nagu Dynamic kursor, ainuke erinevus on, et lisatud ja kustutatud kirjetele juurdepääs puudub; kõik liikumised kirjete vahel on lubatud.
  • Static kursor tagastab staatilise koopia andmetest, st mingeid muutusi andmetes ei kajastu; kõik liikumised kirjete vahel on lubatud.
  • Forward-only kursor lubab ainult edaspidi liikumist kirjetes; andmete muutusi ei ole võimalik näha.
Kursori tüüp määratakse kas enne andmete lugemist või antakse vastav parameeter andmete lugemisega koos (kui seda tehtud pole, avatakse Forward-only kursor). Mõned andmetarnijad ei toeta kõiki kursori tüüpe.

Kirjete lugemisel on vajalik määrata andmeallikas, selleks võib kasutada ühenduse objekti, kuid mõnede andmetarnijate puhul ei ole ühenduse objekti määramine kohustuslik – sellisel juhul määratakse andmeallikas ja tarnija kirjete lugemise meetodi väljakutsel. Tegelikult ADO loob sel juhul ka ühenduse objekti, kuid seda pole võimalik eraldi kasutada, seega kui samal andmeallikal luuakse ja kasutatakse mitmeid kirjeobjekte, siis on siiski soovitav luua eraldi ühenduse objekt.

Ka käsuobjekti kasutamine andmete lugemiseks ei ole kohustuslik, selle asemel võib SQL lause määrata kirjete lugemise meetodi väljakutsel.

Kirjeobjekt (Record) esindab konkreetset kirjet (rida) kirjehulga objektis.

Kirjeobjekt
Kirjeobjekt võimaldab:
  • seada või tagastada kirjega seotud ühenduse objekti;
  • määrata/küsida kirje kasutamise õigusi;
  • määrata/küsida kirje staatust;
  • määrata/küsida kirje tüüpi;
  • luua või sulgeda ühendust andmeallikaga.

Väljaobjekt (Field) esindab kirje välja (veergu) kirjehulga objektis. Väljaobjekt on kasutatav läbi Fields kogumi.

Väljaobjekt
Väljaobjekt võimaldab:
  • tagastada välja nime;
  • vaadata või muuta väljaga esitatavaid andmeid;
  • tagastada välja iseloomustavaid parameetreid (nt Type – välja andmetüüp);
  • tagastada välja andmebaasis määratud suurus – sellest suuremat väärtust ei saa välja salvestada;
  • tagastada välja tegelikku suurust;
  • teha kindlaks, millist funktsionaalsust konkreetne väli võimaldab (Attributes atribuut ja Properties kogum);
Sõltuvalt andmetarnija funktsionaalsusest võib osa väljaobjekti funktsionaalsusest puududa.

Atribuudiobjekt (Property) esindab ADO objekti iseloomustavaid (dünaamilisi) atribuute. Atribuudiobjekt on kasutatav läbi Properties kogumi.

Atribuudiobjekt
ADO objektid omavad kahte tüüpi atribuute: sisse-ehitatud ja dünaamilisi. Sisse-ehitatud atribuudid on defineeritud ADO-s ja kohe kasutatavad ja need ei ole esindatud atribuudiobjekti poolt, st nad pole kasutatavad Properties kogumi kaudu. Dünaamilised atribuudid defineeritakse andmetarnija poolt ja nad on kasutatavad Properties kogumi kaudu.

Atribuudiobjektil on neli sisseehitatud atribuuti:

  • Name on atribuuti tekstiline identifikaator;
  • Type on täisarv, mis tähistab atribuudi tüüpi;
  • Value sisaldab atribuudi väärtust;
  • Attributes sisaldab atribuuti iseloomustavaid parameetreid.

Veaobjekt (Error) sisaldab andmeallika või tarnija poolt tagastatud veateadet. Veaobjekt on kasutatav Errors kogumi kaudu.

Veaobjekt
Iga ADO objektil (või selle poolt) teostatav operatsioon võib tagastada vigu – kõik sellised ühe operatsiooni tulemusena tekkivad vead pannakse Errors kogumisse. Uue vea tekkimisel kogum tühjendatakse ja täidetakse uute veaobjektidega. Veaobjekt sisaldab ainult andmetarnija vigu, mitte ADO objektide vigu (mis tuleb lahendada programselt). Veaobjekt sisaldab atribuute, mis kirjeldavad viga täpsemalt; vea kohta on võimalik teada saada:
  • veateksti;
  • veale spetsiifilist numbrit;
  • vea esilekutsunud objekti;
  • SQL vigu.
Errors kogum on defineeritud ühenduse objektil, seega peab korrektseks veatöötluseks olema defineeritud ka ühenduse objekt.

3.3 ODBC

Open Database Connectivity (ODBC) on laialt kasutatav programmeerimisliides (Application Programming Interface – API) andmebaasidega suhtlemiseks. ODBC põhineb X/Open ja ISO/IEC käsu-taseme liideste (Call-Level Interface – CLI) spetsifikatsioonil andmebaaside programmeerimisliideste jaoks ja kasutab struktuurpäringukeelt (Structured Query Language – SQL) andmebaasidega suhtlemiseks. Põhjalik ülevaade ODBC-st on leitav allikatest [26, vaata »] ja [27, vaata »].

ODBC on loodud sellisel kujul, et maksimaalselt vähendada programmeerimistööd – sama rakendus võib suhelda erinevate andmebaasisüsteemidega kasutades sama koodi. Rakendused kasutavad ODBC liidest, mis omakorda kasutab andmebaasi-spetsiifilisi draivereid. Selline lähenemisviis eraldab rakendusest andmebaasispetsiifilised funktsioonide väljakutsed – samuti nagu printeri draiver eraldab tekstitoimeti töö printeri-spetsiifiliste funktsioonide väljakutsetest. Selleks, et kasutada uut andmebaasisüsteemi rakenduses, pole vaja teha muud, kui installeerida vastav draiver, rakenduses muutuste tegemine pole vajalik.

3.3.1 ODBC arhitektuur

ODBC arhitektuur koosneb neljast komponendist: rakendus, draiveri haldus (driver manager), draiver ja andmeallikas. Järgnev pilt illustreerib nende nelja komponendi suhteid:

Joonis 3.4 Open Database Connectivity arhitektuur
Joonis 3.4 Open Database Connectivity arhitektuur
Nagu jooniselt selgub, võib eksisteerida mitu andmeallikat, seega saab rakendus kasutada korraga mitut andmebaasi. ODBC API-t kasutatakse kahes kohas: alguses rakenduse ja draiveri halduse vahel ning seejärel draiveri halduse ja draiverite vahel. Draiveri halduse ja draiveri vahelist liidest nimetatakse ka teenuse tarnija liideseks (Service Provider Interface).

Rakendus on tavaline programm, mis kasutab ODBC liidest andmetega suhtlemiseks. Rakendusi võib üldistades liigitada kolmeks:

  • Üldised rakendused on ette nähtud töötama mitme andmebaasiga korraga. Näiteks võib tuua tabeltöötlusprogramme, mis vajavad andmeid, et neid siis omakorda analüüsida.
  • Vertikaalsed rakendused täidavad ühte kindlat tüüpi ülesannet nagu näiteks tellimuse sisestamine või andmete jälgimine. Need rakendused töötavad andmetega, mida kontrollivad rakenduse loojad, konkreetse kliendi jaoks töötavad need rakendused ühe andmebaasiga. Rakendused on loodud selliselt, et nad pole seotud ühegi konkreetse andmebaasiga, samas võivad nad toetada kindlat hulka (sarnase funktsionaalsusega) andmebaase.
  • Tellitud rakendused on ette nähtud täitmaks kliendispetsiifilisi ülesandeid.
Kõik rakendused kasutavad siiski mõningaid üldisi meetodeid, mis defineerivad ODBC rakenduse üldise töö:
  • andmeallika valimine ja sellega ühenduse loomine;
  • täitmiseks mõeldud SQL lause saatmine;
  • tulemuste saamine;
  • veatöötlus;
  • transaktsiooni lõpetamine;
  • ühenduse katkestamine andmeallikaga.

Draiveri haldus on sisuliselt teek (library), mis haldab rakenduse ja draiveri vahelist suhtlust. Draiveri haldus eksisteerib põhiliselt selleks, et lahendada mõningaid paljudele rakendustele üldisi probleeme nagu näiteks andmeallika nime järgi õige draiveri valimine, draiverite laadimine ja eemaldamine, funktsioonide väljakutsed draiveritest. See kõik lihtsustab rakenduse tööd, kuna rakendus ei pea muretsema millist draiverit kuna kasutada, ei pea hoolitsema draiveri laadimise/eemaldamise eest ega selle eest, et alati valitakse just õige funktsioon õigest draiverist.

Draiverid on teegid, mis realiseerivad funktsioone ODBC liideses. Iga draiver on andmebaasi-spetsiifiline, seega omab see ka ainult seda funktsionaalsust, mis on vastaval andmebaasil. Draiverid täidavad järgmisi ülesandeid:

  • andmeallikaga ühenduse loomine ja katkestamine;
  • draiveri halduse poolt mittekontrollitud vigade kontrollimine;
  • transaktsioonide alustamine – see on rakenduse eest peidetud;
  • SQL lausete saatmine andmeallikale täitmiseks; see hõlmab ka ODBC SQL-i modifitseerimist selliselt, et see vastaks andmebaasi SQL-ile;
  • andmete saatmine rakenduselt andmeallikale ja vastupidi; see hõlmab ka andmeallikalt saadud andmete teisendamist rakenduse poolt määratud tüüpidesse;
  • andmebaasi-spetsiifiliste vigade teisendamine ODBC vigadeks.
Draiverid jagunevad oma arhitektuuri poolest kaheks:
  • Faili-põhised draiverid on draiverid, mis suhtlevad otse füüsiliste andmetega. Sel juhul koosneb draiver tegelikult kahest osast: ta on nii draiver kui ka andmeallikas – käsitleb ODBC väljakutseid ja täidab ise ka SQL lauseid.
  • Andmebaasi-põhised draiverid suhtlevad andmetega läbi andmebaasimootori. Sel juhul käsitleb draiver ainult ODBC väljakutseid, SQL laused saadetakse andmebaasimootorile töötlemiseks.
Eksisteerib ka mittestandardseid ODBC draivereid, mis täidavad spetsiaalülesandeid.

Andmeallikas on lihtsalt andmete saamise koht. See võib olla fail, andmebaas relatsioonilises andmebaasisüsteemis või ka pidev andmevoog. Andmeallika eesmärgiks on koguda kogu andmevahetuseks vajalik tehniline info ühte kohta ja peita see lõppkasutaja eest. Seega kasutaja saab küll andmeid näha, kuid ei pea teadma, kus need andmed füüsiliselt asuvad ega ka seda, kuidas need kätte on saadud.

3.3.2 X/Open ja ISO CLI standard

ODBC (alates kolmandast versioonist) ühtlustub X/Open ja ISO CLI standardiga (on selle alamhulgaks). Selle ühtlustumise tulemusena on ODBC-le lisatud järgmised omadused:

  • Üks suuremaid uusi omadusi ODBC 3.0-is on deskriptorite kasutamine. Deskriptor on andmestruktuur, mis sisaldab infot kas veerunimede kohta päringu tulemuses või SQL lause dünaamiliste parameetrite kohta. Deskriptorid võimaldavad otsest ja ühtset juurdepääsu veergudele või parameetritele. Nii veeru kui parameetri andmed on kirjeldatud kahe deskriptoriga: üks kirjeldab seisu rakenduse poolel, teine serveri poolel. Operatsioone, mis seovad (binding) parameetreid või päringu tulemuse veerge, nimetatakse kirjutamiseks deskriptorite piirkonda (descriptor area); operatsioone, mis loevad päringu tulemuse või parameetrite metaandmeid, nimetatakse lugemiseks deskriptorite piirkonnast.
  • ODBC 3.0-s sisaldub kogu funktsioonide resultaadiks saadud tulem diagnostikas. Iga keskkond, ühendus, lause ja ka deskriptor omab diagnostika piirkonda. Selles piirkonnas sisalduvad ka kõik funktsioonide töö tulemusena tekkivad vead ning hoiatused. ODBC laiendab diagnostikat järgmiste omadustega:
    • diagnostika piirkond on laiendatav;
    • diagnostika piirkonnast andmete lugemine ei hävita neid;
    • staatuse info on järjestatud (tähtsuse või kriitilisuse järgi);
    • kui viga esineb ainult mõnes veerus, mitte kogu reas, siis märgitakse ära viga põhjustanud veerud.
  • Päringu tulemuse veeru nimed ühtlustuvad X/Open ja ISO CLI standardiga.
  • Lisatud on uued atribuudid ja funktsioonid.

Samas sisaldab ODBC ka mõningaid omadusi, mida pole veel standardiga vastavusse viidud:

  • mitmerealise andmete võtmised päringu tulemusest;
  • parameetrite massiivid;
  • reakaupa sidumine;
  • positsioneerimine;
  • fikseeritud pikkusega järjehoidjad;
  • ODBC kursorite tüübid;
  • väljund ja sisend/väljund parameetrid;
  • salvestatud protseduuride toetus.

Lisaks sellele, et ODBC 3.0 ühildub standarditega, sisaldab ta ka hulga uusi omadusi:

  • Lisatud on uued andmetüübid nagu näiteks suured täisarvud.
  • Andmetöötluse rühmitamine (Batches).
  • Nimelised parameetrid.
  • Laiendatud veateated.
  • Laiendatud järjehoidjad.
  • Tulemuse ja parameetrite ridade ignoreerimise võimalus.
  • Muutujate sidumise laiendused.
  • Infopäringute (spetsiaalfunktsioon SQLGetInfo) laiendused
  • SQL-92 standardiga ühildumine.