Adatbázis-kapcsolati rétegek

A cél: a különböző adatbázisok közötti, illetve a programozási nyelvek és az adatbázisok

közötti kapcsolatok szabványos, egységes nyelven való megvalósítása. Annak lehetővé tétele, hogy
bármely adatot bármilyen programból elérhessünk, függetlenül attól, hogy milyen adatbázis-kezelő
rendszer (DBMS) felügyeli az adatokat (természetesen megfelelő jogosultság birtokában). Az
adatbázis-kapcsolati réteg tehát egy közbülső réteget alkot az adatbázis és az alkalmazás között. [1]
Az adatbázis-kapcsolati rétegek emellett azt is lehetővé teszik, hogy a különböző típusú DBMS-
ek között adatokat forgalmazzunk.

Miért szükséges?
- Az adatbázis-kezelő rendszerek (DBMS) szabadon implementálják az SQL-szabványok által előírt
adattípusok egyes válfajait (pl. az int típus egyes rendszerekben kétbájtos, máshol négybájtos; a
lebegőpontos számok ábrázolására több szabvány létezik).
- Az SQL-nyelv elemeinek implementálása is eltérő lehet az egyes DBMS-ekben.
- A programozási nyelvek nem minden DBMS elérését támogatják natívan (olyan, a nyelvbe
beépített függvényekkel, amelyek közvetlenül az adatbázisnak küldik az adatbázis által
értelmezhető parancsot).

Az adatbázis-kapcsolati réteg helye:

Az alkalmazás (programkörnyezet) és az adatbázis között helyezkedik el. Így
- nem szükséges az összes programozási nyelven minden DBMS natív támogatása; a programozási
nyelv által nem ismert DBMS-ek a kapcsolati rétegen keresztül is elérhetőek (a programozási
nyelvben csak a kapcsolati réteget kezelő függvényeket kell megvalósítani);
- ehhez a kapcsolati rétegnek rendelkeznie kell az elérni kívánt DBMS-ek driver-ével
(illesztőprogramjával), és természetesen a tényleges adatbázis paramétereivel (host, felhasználói
adatok, adatbázisnév…).

A kapcsolati rétegek legfontosabb feladatai:

- parancs-konverzió (a programkörnyezettől érkező, az adott DBMS-ben nem implementált
parancsok emulálása)
- adat-konverzió (a két rendszer esetlegesen eltérő adatábrázolásának áthidalása)
- a kapcsolat menedzselése
- hibakezelés; információ nyújtása a sikeres műveletvégzésről vagy a hibáról
- párhuzamos adatelérés felügyelete
A további részekben néhány adatbázis-kapcsolati réteget mutatunk be. [2] A bemutatásra kerülő
kapcsolórétegeken kívül számos más megoldás is létezik!

1. ODBC (Open DataBase Connectivity)

A Microsoft hagyományos (és nem túl modern) megoldása az adatforrások transzparens (az
alkalmazások felől átlátható) kezelésére.
„Az adatforrás adatok olyan forrása, amely az adatokhoz való hozzáféréshez szükséges
kapcsolati információkkal van társítva.” [3]
 Az adatforrás lehet valamilyen adatbázis-szerver (pl. MS SQL Server, Oracle Server, MySQL),
de adatforrásként használhatunk számolótáblákat (pl. MS Excel) vagy szövegfájlokat is. Az
adatforrás használatához telepíteni kell az adatforrás ODBC-meghajtóját (pl. MySQL esetén a
MySQL Connector/ODBC alkalmazást). A kapcsolati adatok:
- a kiszolgáló helye
- az adatbázis neve
- a felhasználó neve és jelszava
- az ODBC-illesztőprogram esetleges további beállításai

1.1. Az ODBC-adatforrások típusai

Gépi adatforrások: „A gépi adatforrások egy adott számítógépen a Windows
beállításjegyzékében tárolják a kapcsolati információt. Ezek az adatforrások csak azon a
számítógépen használhatók, amelyen definiálták őket. Lehetnek felhasználói és
rendszeradatforrások. A felhasználói adatforrásokat csak az aktuális felhasználó használhatja, és
csak az ő számára láthatók. A rendszeradatforrásokat minden felhasználó használhatja az adott
számítógépen, azok minden felhasználó és rendszerszintű szolgáltatás számára láthatók. A gépi
adatforrások különösen akkor hasznosak, ha növelni szeretné a biztonságot, ezeket ugyanis csak a
bejelentkezett felhasználók használhatják.” [3]
Fájladatforrások: „A fájladatforrások (más néven DSN-fájlok) a kapcsolati információt
szövegfájlban, nem a Windows beállításjegyzékében tárolják. Használatuk általában sokkal
rugalmasabb, mint a gépi adatforrásoké. A fájladatforrások például bármely olyan számítógépre
másolhatók, amelyen megtalálható a megfelelő ODBC-illesztőprogram, így az alkalmazások az
általuk használt számítógépekhez pontos és következetes kapcsolati információra hagyatkozhatnak.”
[3]

1.2. Az ODBC-struktúra
A programkódból érkező parancsok a Driver Manager-hez érkeznek, majd a megfelelő driver-
en keresztül az adatforráshoz.

Az ODBC-struktúra [2]

A Driver Manager feladatai:

- fogadja és értelmezi a programkódból érkező ODBC-függvényhívásokat
- alapvető szintaktikai ellenőrzéseket hajt végre
- végrehajt bizonyos parancs- és adatkonverziókat
- szükség esetén betölti a megfelelő driver-t a memóriába
- továbbítja a parancs megfelelő változatát a driver-nek
- adminisztrálja a kapcsolatokat
- a visszaérkező hibaüzeneteket kezeli és megfelelő formában továbbítja a programkódhoz
A meghajtók (driver-ek):
- konkrét adatforrás-típushoz kapcsolódnak
- a bejövő parancsokat az adatforrás saját nyelvére alakítják
- megvalósítják a kapcsolatfelvételt az adatforrással
- kezelik az adatforrás által visszaküldött adatokat
- egységesítik a hibaüzeneteket

1.3. Példa az ODBC használatára (MySQL elérése PHP-ből ODBC-n keresztül)

A leggyakrabban használt DBMS-ekhez a PHP nyelv rendelkezik natív eléréssel. A MySQL
adatbázisok a PHP nyelvből akár a mysqli, akár a PDO objektum segítségével elérhetők. A régebbi
megoldásokkal való kompatibilitás miatt azonban ODBC-kapcsolaton keresztül is csatlakozhatunk a
MySQL-adatbázisokhoz. A példa nem tartalmazza a webszerver és az adatbázis-szerver telepítéséhez
szükséges információkat!
Az ODBC-n keresztül történő eléréshez telepíteni kell a MySQL Connector/ODBC alkalmazás
megfelelő verzióját (a példában a 32 bites verzió látható). A sikeres telepítést követően:
a) Indítsa el a Vezérlőpultot, abban a Felügyeleti eszközöket, majd az ODBC-adatforrások megfelelő
(esetünkben 32 bites) változatát!
b) A Felhasználói adatforrás fülön válassza a
hozzáadás gombot, majd a legördülő listából a
MySQL ODBC unicode driver-t! A Befejezés gomb
megnyomásával megnyílik az adatforrás szerkesztő
ablaka.
c) Az adatforrás neve (DSN) tetszőleges, az eddigi
adatforrásokétól különböző név lehet. A leírás
megadása hasznos, de nem kötelező.
d) A Server és a Port beállítását (a MySQL alapértel-
mezett telepítése esetén) a képen láthatja.
e) A felhasználói nevet és a jelszót nem kötelező a
párbeszédablakon megadni, de a kapcsolat tesztelése
idejére érdemes kitölteni.
f) Az elérhető adatbázisok megjelennek a legördülő listában, majd a Test gombbal ellenőrizhetjük,
hogy a kapcsolat beállításai helyesek-e. A beállítások az OK gombbal menthetők.
g) (A Details gomb megnyomásával a kapcsolat beállításai tovább pontosíthatók.)
h) A webszerver valamely mappájában hozzuk létre a következő tartalmú PHP-fájlt:
<!DOCTYPE html>
<html>
<head>
<meta charset="windows-1250">
<title>MySQL-ODBC teszt</title>
</head>
<body>
<?php
$conn = odbc_connect('mysql_teszt', 'root', '');
if (!$conn) { die("Adatbázis-hiba!"); }
$sql = "select * from ugynokok order by ugynok_nev";
$res = odbc_exec($conn, $sql);
if (!$res) { die("Lekérdezési hiba!");}
echo '<table border="1">';
echo '<tr><th>Ügynök neve</th><th>Telefonszáma</th></tr>';
while (odbc_fetch_array($res)) {
$nev = odbc_result($res, 'ugynok_nev');
$tel = odbc_result($res, 'telefon');
echo "<tr><td>$nev</td><td>$tel</td></tr>";
}
echo '</table>';
?>
</body>
</html>
 Amennyiben a DSN létrehozásakor megadott adatbázis tartalmaz ugynokok nevű táblát, és
annak van ugynok_nev és telefon mezője, akkor a program helyesen lefut. Kapcsolatot létesít az
ODBC-vel, majd a létrehozott kapcsolatra elküldi a megfelelő select-parancsot, végül az
eredményeket feldolgozza egy ciklus segítségével.

2. JDBC
A JDBC egy alkalmazás-programozási
interfész (API) Java nyelven készülő
programokhoz. A működéshez szükséges
osztályokat a java.sql csomag tartalmazza, ezt
importálni kell az olyan programok esetén,
amelyek a JDBC-t használni kívánják.
Az ODBC-hez hasonlóan a Java-
programból a JDBC API-nak adunk
utasításokat. A Driver Manager kezeli az
egyes típusú adatbázisokhoz való
kapcsolódást biztosító meghajtókat (driver-
eket).
A tényleges kapcsolat létrehozása előtt a
megfelelő driver-t regisztrálni kell, a kérésünk
csak ezután kerül a megfelelő adatbázishoz.
A JDBC megfelelő driver-én keresztül az ODBC-adatforrások is elérhetőek. [4]

3. OLE DB
„Az ODBC-alapú adatkezelés megoldja a
relációs adatok egységes elérésének és ALKALMAZÁS
kezelésének a kérdését.” [5] Az informatikában
azonban nagyon sok olyan adatot használunk,
amelyek nem relációs sémában tárolódnak
(lehetnek például hierarchikus adatok – mint a OLE DB adatszolgáltató
fájlrendszerek –, dokumentumok vagy
levelezési rendszerek). Ezek az adatok nem
érhetők el ODBC-alapon. ODBC adatszolgáltató
A nem csupán relációs adatokkal dolgozó
alkalmazások felé tehát újabb réteget kell
biztosítani. A Microsoft 1997-ben vezette be az
OLE DB (Object Link Embedding) techno- pl. pl. MS nem
lógiát. Az OLE DB ún. provider-eken keresztül MySQL Oracle SQL relációs
kommunikál az adatforrásokkal. Mivel az OLE
DB az ODBC-hez is biztosít provider-t
(MSDASQL néven), ezért a technológia
magába foglalja a relációs adatforrások elérését is, ugyanakkor lehetőséget ad a más sémájú adatok
elérését is.
Az OLE DB-alapú adatelérés egy COM interfészre támaszkodik a legkülönbözőbb, nem
feltétlenül relációs adatok elérésére. Ezért, az ODBC-alapú adateléréssel szemben, amely
platformfüggetlen, az OLE DB-alapú adatelérés csak COM-támogatást élvező platformokon
használható. [5]

4. ADO.NET
Az ADO.NET a Microsoft által kifejlesztett ADO (ActiveX Data Objects) magas szintű felület
.NET-es továbbfejlesztése. Az OLE DB-n túl biztosítja az ActiveX-adatobjektumok elérést is.
 Az ADO.NET tehát a .NET keretrendszer olyan része, amely elsősorban a relációs és más
sémájú adatforrásokhoz való hozzáférést támogatja. Az ADO.NET több módot is kínál az adatok
kezelésére a natív kapcsolaton keresztüli direkt adateléréstől az összetett adatmodelleken alapuló
(akár aszinkron) adatkezelésig.
- Natív kapcsolat: direkt SQL utasítások végrehajtása a fizikai adatbázison.
- Logikai relációs modell: a fizikai adatbázis szerveződésének felépítése és adattárolás a
memóriában.
- Egyszerű objektumrelációs modell (LINQ to SQL): az adatbázis-információk leképezése
objektumorientált szerkezetre a sémának megfelelően.
- Entitás alapú objektumrelációs modell (ADO.NET Entity Framework): az adatbázis-információk
speciális, paraméterezhető leképezése objektumorientált szerkezetre. [6]
Kétféle adatelérési réteget nyújt számunkra. Az egyik a folyamatos kapcsolat melletti (managed
provider), a másik pedig a kapcsolat nélküli réteg (dataset). A kapcsolat nélküli réteg használata
esetén a lekért adatokból egy másolatot készítünk (a másolatot adatkészletnek vagy dataset-nek
nevezzük), majd a későbbiekben ezzel dolgozunk tovább, így egy szétkapcsolt adatarchitektúrát
kapunk. A szétkapcsolt adatarchitektúra előnye, hogy kevesebb az adatforgalom a kliens és a szerver
között. A hátránya, hogy nem mindig a legfrissebb adatokat látjuk. Folyamatos kapcsolat esetén a
provider osztályok biztosítják az adatforrás és a kliens közötti adatáramlást.
A legfontosabb provider-ek:
a) OLEDB.NET (SQL Server 6.5 és korábbi; Access; Sybase; …)
b) ODBC.NET (olyan adatforrásokhoz, amelyhez nincs újabb provider)
c) SQLServer (SQL Server 7.0-tól)
d) Oracle (Oracle 8i-től) [7]

Források:
1. Sulinet Tudásbázis: Kliens-szerver hierarchia. Az ODBC lényege. Elektronikus forrás:
http://tudasbazis.sulinet.hu/hu/szakkepzes/informatika/adatbazis-kezeles/kliens-szerver-
hierarchia/az-odbc-lenyege (2015.11.07-i megtekintés)
2. Barabás Péter: Adatbázis rendszerek II. Előadásjegyzet. Elektronikus forrás: http://www.iit.uni-
miskolc.hu/iitweb/export/sites/default/users/barabas/Targyak/db2/ea4.pdf (2015.11.07-i
megtekintés)
3. Microsoft Support: ODBC-adatforrások felügyelete. Elektronikus forrás:
https://support.office.com/hu-hu/article/ODBC-adatforr%C3%A1sok-fel%C3%BCgyelete-
b19f856b-5b9b-48c9-8b93-07484bfab5a7# (2015.11.07-i megtekintés)
4. Cser Lajos: Számítógépes adatbázis-kezelés. Előadásjegyzet. Elektronikus forrás:
http://www.stud.u-szeged.hu/Cser.Lajos/files/db2013-n/02-dbms-ny.pdf (2015.11.07-i
megtekintés)
5. Hatvany Csaba: Bevezetés az adatkezelésbe. Elektronikus forrás:
http://prog.hu/cikkek/908/bevezetes-az-adatkezelesbe (2015.11.07-i megtekintés)
6. Giachetta Roberto: Eseményvezérelt alkalmazások fejlesztése II. Előadásjegyzet.
http://people.inf.elte.hu/asjuaai/Targyak%20-%20ProgInfo%20B/Esemenyvezerelt%20
alkalmazasok%20fejlesztese%202/ea/11%20-%20ADO.NET-Adatkezel%C3%A9s
%20a%20.NET%20keretrendszerben/elte_eva2_ea11_dia.pdf (2015.11.07-i megtekintés)
7. Barabás Péter: Adatbázis rendszerek II. Előadásjegyzet. Elektronikus forrás: http://www.iit.uni-
miskolc.hu/iitweb/export/sites/default/users/barabas/Targyak/db2/ea6.pdf (2015.11.07-i
megtekintés)