Adatbázis-kezelők


  1. ADATBÁZIS-KEZELŐK

    2. 1.1 Adatbázis-kezelők nyelvi elemei

    1.2 A file-kezelő

    Az adatbáziskezelő rendszerek nagyon magas szintű nyelvek, de voltaképpen filekezelést végeznek. Az adatbázist alkotó fele-okban lévő adatok fizikailag pontosan úgy vannak tárolva mint minden más esetben: bináris jegyek kombinációjaként. Az adatbázisok létrehozásakor mi a logikai szerkezetet (az adatbázis sémáját) adjuk meg, az adatbáziskezelő rendszer fordítja ezt le, készíti el a "fizikai" file-okat, és kialakítja a logikai kapcsolatoknak megfelelő fizikai kapcsolatokat az adatok között.
    Ezeket a feladatokat a file-kezelő (fele-manager) végzi ami az DBMS fő része. Ez vezérli a file-ok létrehozását, a rekordok "beszúrását" (felvitelét) a törléseket; a módosításokat. A fele-kezelő tartja nyilván az adatok (fizika helyét, a köztük lévő kapcsolatokat, stb. Erre a célra a file-kezelő mélyén elhelyezkedő adatszótár (Data Dictionary) szolgál.

    1.3 A lekérdező nyelv

    A lekérdező nyelv egy interaktív eszköz, amelynek segítségével dialógus folytathatunk a rendszerrel. Ilyen például az SQL-nyelv. Az ilyen nyelveknek az a lényege, hogy nagyon könnyen felírhatók bennük "ad-hoc" kérdések, amelyekre rendszer azonnali választ ad. (lásd az SQL SELECT parancsát).
    Az adatbáziskezelő rendszereknek, mint nyelveknek két fajtája van: a. egyik az ún. beépülő típusú, befogadó típusú (host-típusú), amelyik voltaképpen nem is igazi programnyelv, hiszen csak egy másik valódi program nyelvvel (COBOL, PL1, PASCAL stb.) együtt használható fel alkalmazó: programok írására, alkalmazói rendszerek felépítésére. Ilyen az SQL nyelv is. A másik típus valóságos programozási nyelv. Ezeknél ahhoz, hogy alkalmazói rendszereket készítsünk az adatbázis felhasználására, nem kell más programnyelvet bekapcsolni. Erre példa a dBase (III, IV, V) vagy a Clipper nyelv.

    1.4 Segédfeladatok az adatbáziskezelőkben

    Az adatbáziskezelő rendszerek a fő funkciókon kívül több "segédfeladatot" is ellátnak. Ezek közül kiemeljük a következőket.
    Adatvédelem, adatbiztonság. Nem minden felhasználónak van joga az adatbázis minden adatához hozzáférni. Amikor a felhasználó programján keresztül az adatbázishoz fordul egy jelszóval kell azonosítani magát. Ezt az adatbáziskezelő rendszer értékeli, és csak azokhoz az adatokhoz engedi hozzáférni, amelyekhez annak jogosultsága van. Az adatok védelme nagy adatbázisoknál rendkívül fontos dolog, hiszen az adatbázis tönkretétele nagyon nagy károkat okozhat (gondoljunk egy óriási bank adatbázisára). Az adatok védelmének szoftver eszközökkel történő biztosítása programozói szemszögbál nézve igen érdekes, de nagyon nehéz feladat.
    Az integritási feltételek teljesülésének figyelése. Az adatbázis adataival kapcsolatban gyakran meg lehet fogalmazni olyan feltételeket; amelyek ellenőrzésével az adatbázis létrehozásakor kiszűrhetők azok az input adatok, amelyek nem az adott adatbázisba valók (hibásak). Az adatbázis belső szerkezete is hordozhat olyan információkat, amelyek meghatározzák, hogy új adatok bevitele esetén ezek illeszkednek-e az adatbázishoz. Például kiköthetjük, hogy a dátum nevű adattétel nem vehet fel az 1900-as évek előtti dátumot, vagy előfordulhat, a rendszer olyan, hogy két adat megegyezése valahol az adatbázisban maga után hozza másik két adat megegyezését. Az ilyen típusú információkat integritási feltételeknek nevezzük. Az adatbáziskezelő feladata ezen integritási feltételek teljesülésének vizsgálata is.
    Szinkronizáció. Különösen hálózatban-üzemelő nagy adatbázisoknál, egyidejűleg nagyon sok felhasználó fordulhat esetleg ugyanazon adathoz. Ráadásul úgy, hogy egyik éppen módosítani akarja, a másik pedig lekérdezni. Ezeknek az ún. holtpont helyzeteknek a megoldása nagyon nehéz feladat.

    1.5 Adatbázis statisztikák

    Mivel az adatbáziskezelő rendszerekben az adatokhoz való hozzáférés a központi szoftver vezérlése alatt megy végbe, ezért az ilyen rendszerek minden, az adatokkal kapcsolatos műveletről feljegyzést vezetnek, mindent naplóznak. Ezeknek az adatoknak a felhasználásával azokhoz a műveletfajtákhoz, amelyek gyakran szerepelnek különféle gyorsításokat (pl. indexelés) hajthat végre a rendszer.

    1.6 Az adatbázis adminisztrátor

    Az adatok központosítása lehetővé teszi, hogy egy személy az un. adatbázis adminisztrátor (ABA) (nagy adatbázisok esetén ez több személy is lehet) feleljen a teljes adatszervezésért, a biztonságért, az egész rendszerért.
    Az ABA adja ki a különféle jelszókat, engedélyez hozzáféréseket, módosításokat. Mivel minden releváns információ "egy fejben" van, így könynyebb biztosítani az adatbázis konzisztenciáját és integritását. Az adatbázis adminisztrátort speciális szoftverek segíthetik.

    1.7 A 4GL-ek

    A 4GL-ek (Fourth Generation Languages = Negyedik Generációs Nyelvek) adatbáziskezelő rendszerek, amelyekkel nagyon kényelmesen, gyorsan :rhatók fel adatbázis-alkalmazások, rendszerfejlesztések.
    Nincs mindenki által elfogadott definíció arra, hogy pontosan mit tekinünk 4GL-nek. Mindenesetre fóbb paraméterekként a következők sorolhatók :el.
    A 4GL segítségével képernyőn könnyen és gyorsan tervezhető meg az input és a módosítás. A felhasználónak nincsen más dolga, mint a képernyőn megjelenő képen (ábrán) kitölteni a mezőket. Bizonyos mezők letilthatók, vagyis ezekbe nem lehet beírni. Több adatbázis-táblán egyszerre is végrehajthatók a képernyőn keresztül bevitelek, módosítások.
    A másik fontos tulajdonsága a 4GL-eknek, hogy rendelkeznek olyan, az output megvalósítására szolgáló eszközzel, amelyekkel jól formázott, sablonokból előállítható listák írhatók ki (akár több adatbázis táblából is) anélkül, hogy programot kellene írnunk. Ez azt jelenti, hogy szabványos kiírási képeket definiálhatunk, azt könyvtárba foglaljuk és szükség szerint építjük bele "grafikusan" a különféle felhasználói programokba.
    A 4GL-tulajdonságú adatbáziskezelő rendszerekben nem csak az input, output támaszkodhat képernyőelemekre, hanem más felhasználói műveletek is (Pl. keresés, módosítás, stb. az adatbázisban). Azt szokták mondani, hogy 4GL esetén vagy 4GL tulajdonságú adatbáziskezelő alkalmazásakor csak azt kell megmondani, mivel mit akarunk elvégezni, de azt nem, hogy hogyan, tehát az eljárásnak, a procedúrának nincs szerepe, azaz a nyelv nem eljárásorientált.
    A 4GL jellemzője az is, hogy az előbbiekben említett "képi" megoldásokkor a 4GL programkódokat is generál, amiket a programozó módosíthat, átírhat.

    1.8 Integrált CASE eszközök

    A korszerű, relációs modellre támaszkodó adatbáziskezelő rendszerek közül sokban megtalálható a CASE csomag (CASE = Computer Aided Softver Engineering = Számítógéppel támogatott szoftver technológia) A CASE többek között lehetővé teszi az adatbázistervező számára az un. egyed-tulajdonság diagramok interaktív felrajzolását, az adatbázisséma létrehozását, módosítását. A CASE-zel automatikusan generáltatók a tényleges táblák, relációk, (lásd később) és elvégezhetők bizonyos normalizálási teendők is (lásd később)

    1.9 Az ANSI/SPARC modell

    A 70-es években az adatfeldolgozásban nagyon elterjedt az adatbázis szemlélet, és számos adatbáziskezelő rendszer jött létre. Abból a célból, bizonyos szabványosítást lehessen elvégezni a fogalmak és a terminológiák tekintetében, az ANSI/X3/SPARC bizottság elkészített egy ANSI/SPARC modellt.
    A belső nézet a tárolt, fizikai adatbázist jelenti.
    A belső koncepcionális leképezés a belső nézet a koncepcionális sémát, az un. logikai sémáját hozza létre
    A külső koncepcionális leképezés a logikai sémákból külső nézeteket hoz létre.
    A felhasználók az alkalmazások használatán keresztül általában csak a külső nézetekkel találkoznak.
    Az adatbázisok tervezésénél a logikai séma megalkotása a legfontosabb

    1.10 Logikai, fizikai szerkezet

    Az adatbáziskezelésben (általában az adatkezelésben) a logikai jelző azt jelenti, hogy felhasználó-orientált, azaz a felhasználó számára érthető. Például egy adatbázis tervezésénél logikai szerkezetben írjuk le a dolgokat, amikor a valóságos világ objektumait képezzük le adatmodellé.
    A fizikai jelző azt fejezi ki, hogy az adatok szerkezete "gépközeli" azaz a memóriában való tárolás, a file- kezelés szempontjából tekintjük az adatok szerkezetét, úgy ahogy a rendszerprogramozó "látja" amikor az adatbáziskezelő fordítóprogramjait írja.

    1.11 A programok és az adatok függetlensége

    Ez az adatbázisok fontos tulajdonsága. A program és az adatok függetlenségén azt értjük, hogy kis módosítások az adatbázis struktúráján megtehetők anélkül, hogy az alkalmazói programot módosítani kellene. Természetesen teljes függetlenség nem valósítható meg, de minél nagyobb ez a függetlenség, annál jobb a rendszer.

    1.12 Az adatbázis életciklusa

    A felhasználó számára kész termékként átadható, üzemeltethető adatbázisok (a kezelő-programokkal együtt) többlépcsős folyamaton keresztül jönnek létre nagyjából egy adott séma szerint.

    1. Az első lépcső az adatbázissá formálandó valóságos probléma megér~, a korlátozó feltételek felismerése, a lehetséges variációk feltérképezése, ami valamilyen rendszerelemzési módszer segítségével történik. Sok ilyen módszer van ilyen például az SSADM, amellyel az életciklus több feladata is megoldható, de fontos eleme az első lépcső megoldására alkalmas része is.
    2. A második lépésben megalkotjuk az adatmodellt (az egyed-kapcsolat modellt), meghatározzuk a kulcsokat.
    3. Adatmodellünket normalizálási procedúrának vetjük alá a következő lépésben.
    4. A normalizálás után létrejön az adatbázist alkotó táblák halmaza, ilyeket az adatbázis adminisztrátor az adatbáziskezelő rendszer programmal (SQL-ben a CREATE TABLE paranccsal) definiál.
    5. A következő lépés a különféle file-ok létrehozása, az indexelés, és a szükséges nézetek definiálása.
    6. Ezután a lekérdezések megtervezése következik. Bár ez a folyamat aokdik lépése, de minden előtte lévő lépést is befolyásol, mivel szinte minden amiatt történik az adatbázisban, hogy lekérdezéseket adhassunk fel.
    7. A képernyőtervet a beviendő adatok és a kimenő eredmények határozzák meg; itt voltaképpen az ember-gép kapcsolatot, a felhasználó és az alkalmazási rendszer kapcsolatát határozzuk meg. A képernyőterv alkalmas is, hogy egyszerűbb kérdés-felelet dialógust szerkesszünk meg, amelyek segítségével a nem profi alkalmazók jól definiált feladatokat oldhatnak meg.
    8. Létrehozhatunk a képernyőn olyan menüket, amelyek egy sor lehetőséget kínálnak fel a felhasználónak aki különféle sorrendben választhat a menüpontok közül abból a célból, hogy kitűzött feladatát megoldja.
    9. A listázási terv szintén fontos eleme az adatbáziskezelésnek. Itt speáljuk mit és milyen standard táblázatban akarunk kiírni az adatbázisból lekérdezett eredményekből. A legtöbb DBMS-ben megtalálhatók az un. "report writer"-ek, a listázó programok, amelyek segítségével könnyen tudjuk szerkeszteni az output formátumát.
    10. A következő lépés a tesztelés megtervezése. Ez természetesen nemcsak az adatbázistervezés fontos eleme, hanem bármilyen más program írásakor is lényeges szerepe van; kulcs-lekérdezések, input és karbantartó képernyőképek, listázó programok szolgálnak az adatbázis helyességének illetve az egész rendszer életképességének ellenőrzésére. Nagy jelentősége van egy teszt-adatbázisnak, ami pontosan olyan, mint az "élő" adatbázis, de a benne szereplő adatokat úgy tervezzük meg, hogy a lehető legtöbb esetet reprezentálják.
    11. Az utolsó lépés a rendszer átadása, amikor a felhasználó megkapja az adatbázist, az alkalmazói programokat és elkezdődhet az adatbázis feltöltése.

    1.13 Objektum-orientált adatbázisok

    Az adatbázisok egy új generációját jelentik az objektum-orientált adatbázisok (illetve adatbáziskezelők). Ez a filozófia abban tér el az eddigiektől, hogy integrálja az adatkezelés és az adatdefiniálás mechanizmusát. Ez a gyakorlatban azt jelenti, hogy az adattáblák definiálásakor nem csak a mezők típusát, és méretét definiáljuk, hanem az mező validálási információit, formátum információit, kezdőértékét, indexelését stb... Ilyen módon az adatbázis kezelése során nem kell plusz eljárásokat írni azadatbevitel és megjelenítés minde esetét tekintve, hanem ha egy adatot beviszünk vagy megjelenítünk, akkor a rendszer önmagától képes a megfelelő vizsgálatokra és formátumok alkalmazására. (Nagyon szépen látdszik ez a fajta gondolkodás a Microsoft Access tábladefiniálásakor)
    Magában az adatbázistervezésben az objektum-orientált szemlélet nem jelent lényeges eltérést az egyedkapcsolat modellhez képest, a korszerű adatbáziskezelő rendszerek (pl. a 4GL-ek) viszont teljességgel követik az objektum-orientált nyelvek filozófiáját.


  2. AZ ADATMODELLEK ÉS A LOGIKAI-SÉMA

    3. 2.1 Az egyed fogalma

    Egyednek hívunk minden olyan dolgot (objektumot), ami minden más objektumtól megkülönböztethető és amiről adatokat tároltunk.
    Az egyed konkrét dolgok absztrakciója, konkrét dolgokat fog egybe. Például az autó mint egyed sok autót jelent. Egy adott egyed által képviselt konkrét elemek halmazát egyedhalmaznak is szoktuk nevezni. Például a dolgozó nevű egyed egyedhalmaza az összes dolgozókból áll, a személy egyedhalmaz az összes személyt tartalmazza, az érzelem egyedhalmaz az összes érzelem.
    Az egyed egy konkrét értékét az egyed egy előfordulásának nevezzük, de az előfordulás helyett mondhatunk egyedértéket is.
    Megjegyzés.
    A szerzők egy része egyed helyett egyedtípust mond. Ebben a felfogásban az egyednek két szintjét különböztetjük meg: az első szint (az egyedtípus) az absztrakciós szint, a második pedig az előfordulás szint.

    2.2 A rekordtípus

    Az adatbáziskezelő rendszerekben (elsősorban a hálós, hierarchikus modelleken alapulókban) az egyedtípust rekordtípusnak hívjuk. Ez a legkisebb címezhető egység (ennél kisebb részeire nem lehet hivatkozni az adatbázisnak).

    2.3 A tulajdonság fogalma, Azonosítók

    Az egyedeket tulajdonságokkal (attribútumokkal) írjuk le, a tulajdonság az egyed egy jellemzője, ami megadja, meghatározza az egyed e részletét. A tulajdonság is absztrakció, amely több elemet foglal magába, tehát konkrést előfordulásokból áll.
    A tulajdonságok lehetnek:

    Az azonosítók létrehozása esetenként az egyed természetes tulajdonságaiból adódik. Erre példa a személyi szám a személyek azonosítása terén. Ekkor beszélhetünk egyszerű azonosítóról. Amikor nem lehet ilyen azonosítót alkalmazni, két lehetőségünk van:

    2.4 Kulcs

    A menniyben a tulajdonságok vagy a tulajdonságok egy csoportja egyértelműen meghatározza, hogy az egyed melyik értékéről, előfordulásáról van szó, akkor ezeket kulcsoknak nevezzük.

    2.5 Többértékű vagy összetett tulajdonságok

    Ha a tulajdonságok olyanok, hogy több értékkel rendelkeznek, akkor összetett vagy többértékű tulajdonságnak hívjuk.

    2.6 A kapcsolat fogalma

    Kapcsolatnak nevezzük az egyedek közötti viszonyt. A kapcsolat mindig valóságos objektumok közötti viszonyt fejez ki, hiszen az egyed ilyen objektumokat képvisel;
    A kapcsolat is absztrakció: két egyed értékei közötti konkrét viszonyokat fejez ki. A konkrét kapcsolatokat a kapcsolat értékeinek (előfordulásainak) nevezzük.
    A kapcsolódó egyedek között általában nem egyenrangú a viszony, hanem lehet egyfajta irányításról beszélni. A kapcsolat meghatározója a tulajdonos (owner) és a kapcsolat másik oldalán lévő egyed vagy egyedek a tagok (member).
    Az egyedek közötti kapcsolat lehet kötelező, félig kötelező, opcionális. Kötelező kapcsolatról beszélünk, ha
    Az adatmodell időfüggvényének szerepe az adatmodell kialakításában.
    Az archiválás problémaköre (inaktív egyed-előfordulások).

    2.7 A kapcsolat fokai

    Kapcsolat egyidejűleg több egyed között is lehet. Ha a kapcsolat n egyedet "köt össze" akkor n-edfokúnak nevezzük.
    A leggyakoribb a bináris (másodfokú) kapcsolat, amikor is két egyed között van viszony.
    Speciális bináris kapcsolat a rekurzív bináris kapcsolat. Ilyenről van szó akkor, ha az egyeden belül az előfordulások vannak kapcsolatban. Pl.: a dolgozó egyedben benne vannak a vezetők is (általában ők is dolgozók), de a többi dolgozóval speciális kapcsolátban vannak: vezetői-beosztotti kapcsolatban.
    Gyakoriak a valóságos világ objektumai között a harmadfokú (angolul ternary) kapcsolatok, vagyis olyanok amikor három egyed között van viszony.

    2.8 A kapcsolatok fajtái

    Egy kapcsolat voltaképpen az egyedhalmazok elemei közötti viszonyt fejezi attól függően, hogy az egyedhalmaz elemei milyen módon kapcsolódik egymáshoz, azaz egy adott egyed egy előfordulásához hány előfordulás kapcsolódik a másik egyedből három esetet különböztetünk meg

    1. Egy-egy típusú kapcsolat (1:1 kapcsolat)
      A kapcsolat lelet olyan, hogy az egyik egyedhalmaz mindegyik eleméhez a másik egyedhalmaznak pontosan egy eleme kapcsolódik (tehát a két egyedhalmaz egymásba kölcsönösen egyértelműen képezhető le. Az ilyen kapcsolatot egy-egy (jelben 1 :1) típusúnak nevezzük.
    2. Egy-több típusú kapcsolat (1:N kapcsolat)
      Azt mondjuk, hogy az A egyed és a B egyed között egy-több (jelben: 1:N) típusú kapcsolat van, 1a az A egyedhalmaz mindegyik eleméhez a B egyedhalmaznak több eleme is tartozhat.
    3. Több-több típusú kapcsolat (N:M kapcsolat)
      Több-több (jeIben N:M) típusú kapcsolatnak nevezzük az A egyed és a B egyed közötti kapcsolatot; ha az A egyedhalmaz minden eleméhez B halmaz több eleme is tartozhat, továbbá B minden eleméhez A több eleme is kapcsolódhat.

    2.9 A kardinalitás

    Az egyedek a kapcsolat szempontjából az un. kardinalitási számmal is jellemezhetők. Az egyed krdinalitási száma a kapcsolatban azt adja meg, hogy egy egyed egy előfordulásához a másik egyedből maximálisan hány előfordulás kapcsolódhat, azaz az N:M kapcsolatban a kardinalitási szám : max. (N), max. (M).

    2.10 A belső szerkezete, belső tulajdonságai

    Egy adatmodellben valamennyi egyedet egyenként véges számú tulajdonsággal írunk le. Ezek a tulajdonságok együttesen alkotják az egyed belső szerkezetét, és az egyed belső tulajdonságainak hívjuk.

    2.11 Az egyed külső tulajdonságai

    Az egyedek kapcsolatainak összességét külső tulajdonságoknak hívjuk

    2.12 A settipus fogalma

    Az adatbáziskezelő rendszerekben (elsősorban a hálós és hierarchikus modellen alapulókban) két egyedtípust (agyaz rekordtípust) a köztük lévő kapcsolattal együtt settipusnak nevezzük. Ezt névvel látjuk el; így a feldolgozás során hivatkozni lehet rá (a rekordtípushoz képest eggyel magasabban címezhető egység).
    A settipusban a kapcsolatnak mindig "irányt" is adunk, rajzban ezt nyíllal fejeszük ki. Az egyik rekordtípust (a.miből a nyíl vezet) tulajdonosnak (owner) a másikat (amibe a nyíl vejet) taginak (member) nevezzük. (1.14 ábra)

    2.13 A kapcsolatok ábrázolásának különféle módjai

    A kapcsolatok ábrázolására több módszer terjedt el.

    1. Vonalas összekötés
      A legegyszerűbb ezek közül az, amikor két egyedtípust egy egyenessel, vagy kifejezve a kapcsolat irányát egy nyíllal kötünk össze.
    2. A Chen féle jelölés
      Egyes szerzők a Chen féle jelölést használják. A kapcsolatot itt rombusz jelöli; amibe beírjuk a kapcsolat "tartalmát", nevét is. Ennél a jelölésnél megadjuk a kapcsolat fajtáját és a zérus minimális kardinalitást is (körrel). Nyíllal jelölhetjük a kapcsolat irányát is. A magyar nyelvben nehezebb felírni a kapcsolat tartalmát, mint azokban a nyelvekben, ahol a rag a főnév előtt van (pl. angol, német, stb.).
    3. A "varjú-lábas" ábrázolás
      A kapcsolatban előforduló egyedeket dobozokba írjuk, a kapcsolatot egy vonal jelképezi, amely összeköti a dobozokat, a kapcsolat típusát az egy oldalon egy vonal, a több oldalon három kis vonal jelöli.

    2.14 Egyed-szupertípus, egyed-altípus

    Amennyiben több egyedtípus ugyanazon tulajdonságtípusokkal rendelkezik, úgy ezek az egyedtípusok egy magasabb szintű egyedtípusba vonhatók össze. Ezt az absztrakciót generalizálásnak nevezzük.
    Azt az egyedtípust amit több egyedtípusból generalizálunk egyed-szupertípusnak, az öt alkotó egyedtípusokat pedig egyed-altípusoknak nevezzük.
    Az egyed-szupertípust más szemszögből is nézhetjük; azt mondhatjuk, az egyed-altípusok az egyed- szupertípus specializációi.
    Egy egyed-szupertípus egy kapcsolatban, lehet egyed-altípus egy másik kapcsolatban. Ha az egyed-szupertípus és az egyed-altípus kapcsolatok egy struktúrát hoznak létre, akkor ezt generalizációs hierarchiának nevezzük.
    Az egyed-altípusokat két csoportra sorolhatjuk. Ezek lehetnek ugyanis diszjunktak, vagyis olyanok, amelyeknek nincsen közös elemük. A generalizációnál azt mondhatjuk, hogy a tulajdonságokat az egyed-altípusok öröklik az egyed-szupertíustól.

    2.15 Aggregáció

    Az aggregáció egy másik absztrakció az egyed-szupertípus és az egyedaltípus között. Az aggregáció esetén az altípus része az egyed szupertípusnak. Pl. egy szoftverterméknek része a program és a felhasználói kézikönyv.
    Az aggregációnál a tulajdonságok nem öröklődnek, mindegyik egyednek saját tulajdonságai vannak.


  3. AZ ADATMODELL ÉS AZ ADATBÁZISOK


    4. Az előbbiekben megismert elemekből többféle adatmodell hozható létre.

    3.1 Az adatmodell fogalma

    Az adatmodell egyszerű, tulajdonságok és kapcsolatok halmaza, amely absztrakt módon tükrözi a valós objektumoknak, szak jellemzőinek (tulajdonságainak) és viszonyainak (kapcsolatainak) elvont kategóriáit.
    Az adatmodell egy olyan séma, amelyben megadjuk milyen tulajdonságok határozzák meg az egyedeket, milyen egyedek szerepelnek a sémában, és ezek között milyen kapcsolatok vannak. Az adatbázisokat különféle adatmodell szerint építhetjük fel. Az adatmodell meghatározza az adatbázis szerkezetét, sémáját. Az adatmodell, adatbázismodell szavak ugyanazt jelentik.
    Az egyedet, a tulajdonságot és a kapcsolatot adatmodell-elemeknek nevezzük. Attól függően, hogy ezekből milyen módon hozzuk létre az adatmodell szerkezetét, különféle adatmodelleket kapunk. Három adatmodell terjedt el az elmúlt 30 év alatt.
    Az első két modellről (a hierarchikusról és a hálósról) úgy látszott, hogy velük sikerült véglegesen "megfogni" az adatfeldolgozást. A harmadikról (a `relációsról) sokan azt hittük, hogy zsákutca. A nyolcvanas évek elejére kiderült, hogy az utóbbi jóslat tévedés volt; ma már a relációs modell szinte egyeduralkodóvá vált.
    Az, hogy milyen modellre alapozva végezzük az adatfeldolgozást, az adatbázis megszerkesztését meghatározza az adatbáziskezelő rendszert, a nyelvet is. Minden egyes modellre számos nyelvet dolgoztak ki.

    3.2 A hálós adatmodell

    A "történelem" folyamán nem ez volt időben az első adatmodell, de mivel úgy tekinthető, mint a hierarchikus általánosítása (azaz a hierarchikus ennek speciális esete), ezért a hálós adatmodell ismertetésével kezdjük.
    A hálós adatmodell szerkezetét gráffal adjuk meg. Ebben a gráfban a csomópontok az egyedek, az élek pédig a kapcsolatot fejezik ki. Az egyedeket tulajdonságaikkal írjuk le.
    A hálós adatmodell adatbázisaiban az egyedek (tehát az előfordulásaik) közötti kapcsolatot listaszerkezettel (pointerek, mutatók használatával) adják meg.

    3.3 A hierarchikus adatmodell

    A hierarchikus adatmodell szerkezetét specilis gráffal adjuk meg, fával.
    A csomópontok itt is egyedeket jelentenek és a nyilak a kapcsolatokat fejezik ki.
    A hierarchikus adatmodellre épülő adatbázisok kezelésére számos adatbáziskezelő rendszert dolgoztak ki.

    3.4 A relációs adatmodell

    A relációs adatmodell más filozófiára épül, mint az előbbi kettő. Ennél az adatmodellnél a három adatmodellelem közül a kapcsolat nem játszik szerepet, pontosabban szólva a kapcsolat nem, csak a lehetőség épül be az adatmodellbe. A relációs adatmodellnél a tulajdonságok kapják a fő hangsúlyt, a tulajdonságokkal definiáljuk az adatmodell szerkezetét.
    Az olvasó bizonyára észrevette, hogy az előbbi két modellben a gráffal történő leírásban éppen a tulajdonságok nem szerepeltek, ezeket külön adtuk meg.
    A relációs adatmodellben az egyedet egy táblázattal adjuk meg, a táblát oszlopai a tulajdonságok. A táblázat sorai az egyed értékei (vagyis a táblázat maga éppen az egyedhalmaz). A táblázat egy-egy sorát a tulajdonságok konkrét értékei adják.
    A relációs adatmodellben létrehozott adatbázisokat több táblázattal adjuk meg (ne felejtsük el, minden tábla egy egyedhalmaz), de a táblázatok (tehát az egyedek) közötti kapcsolatokat nem definiáljuk az adatmodell felírásakor. Ez nem azt jelenti, hogy nincsen közöttük kapcsolat, de ezeket a kapcsolatokat például egyszerűen az fejezi ki, hogy két táblának van közös oszlopa (mindkét táblában szerepel ugyanaz a tulajdonság).
    Miért hívják ezt a modellt relációsnak?

    3.5 Reláció definíciója

    Legyenek D1, D2,...Dn adott halmazok. E halmazok Descartes szorzatán azt a D halmazt értjük, amelyeknek az elemei a (v1,v2,...,vn) érték n-esek, amelyekben v1 elme D1-nek, v2 eleme D2, nek stb... Azaz minden halmazból kiveszünk pontosan egy elemet és a megadott sorrendben egymás után írjuk. Az így kapott elemsorozat lesz a szorzathalmaz egy eleme.
    A Descartes szorzat egy R részhalmazát relációnak nevezzük. A D,, D~,..., D„ halmazokat a reláció tartományainak (domain), a reláció egy elemét n-esnek (elem n-esnek, angolul taple-nak) nevezzük. Az R reláció elemeit gyakran rekordoknak hívjuk.
    A továbbiakban az adatbázis egy "oszlopát" attribútumnak nevezzük. Úgy is fogalmazhatunk, hogy az attribútum egy változó, ami az oszlopba írt értékeket "veszi fel" a tartományban szereplő értékek közül, azaz a tartományt az adott attribútum értékkészletének tekinthetjük.
    Jelöljük a továbbiakban az attribútumokat az A1,A2,..., An indexes nagybetűkkel, ezeket együtt (vagyis az attribútumok halmazát) A-val, azaz A = { A1,,A2~,..., An} .
    Megadtuk tehát a relációs adatmodell két definícióját. Az egyik definíció szerint a relációs adatbázis táblázatokból áll, a táblázatokat az oszlopok definiálják. A másik definíció szerint a relációs adatbázis relációkból áll.
    Az olvasó bizonyára észrevette, hogy voltaképpen elnevezésbeli különbségről van szó. A továbbiakban vegyesen használjuk a táblázat ill. reláció elnevezést.
    Az attribútumok számát (az oszlopok számát) az R reláció fokának, a sorok számát pedig a reláció számosságának nevezzük. Ahelyett, hogy n-ed fokú, gyakran mondjuk, hogy n változós.
    A relációs adatbázist röviden jelölni, a következő módon lehet:
    R ( A1,A 2,..., An).
    alakban tesszük, ahol R a reláció neve, Ai pedig egy attribútum.
    A továbbiakban a reláció nevét és az attribútumokat nagybetűkkel jelöljük.
    Az R (A2,A2,..., An) alakot a reláció sémájának nevezzük.
    Gyakran attribútum helyett egyszerűen oszlopnevet mondunk sőt még egyszerűbben azt mondjuk, hogy a reláció oszlopokból áll. (pl. az SQL nyelvben) Több adatbáziskezelő rendszerben mezőnek nevezzük az attribútumot, és a mező értékeiről beszélünk (pl. dBASE IIL, IV.)

    3.6 Reláció, tábla, adatbázis

    Az előbbiekben egy táblát (relációt) adatbázisnak neveztünk. A relációs adatbázisok általában nem egyetlen relációból, táblából állnak, hanem több tábla alkot egy adatbázist. Azt, hogy egy adatbázist hány táblára bontunk szét, vagy hány táblát fogunk össze egy adatbázisba, már az adatbázis megtervezésekor eldöntjük. A táblákra bontásnál az attribútumok közötti kapcsolat jelentősen befolyásolja, hogy mely oszlopok kerülnek egy táblába.
    Egy adatbázis nem egymástól független. táblák halmaza, hiszen így semmit sem érnénk velük. A relációs adatbázisokban a különböző táblákat közös attribútumokkal (oszlopokkal) kötjük össze. Az ilyen oszlopokat kulcsoszlopoknak, (kulcsmezőknek) is szoktuk nevezni.

    3.7 Egyedtípus és reláció kapcsolata

    Valójában minden egyedtípus egy relációnak felel meg. Ezzel vége is van a hálós (hierarchikus) illetve a relációs adatmodell közötti kapcsolatnak.
    Miben áll a különbség ettől a ponttól kezdve?
    Abban, hogy amíg a hálós (hierarchikus) modellben az egyedtípusok közötti kapcsolatot is megadjuk, azaz két egyedből egy settípust hozunk létre és listaszerkezettel valósítjuk meg az előfordulások kapcsolatait, vagyis pontosan megmondjuk, hogy a tulajdonos egyedtípus mindegyik előfordulásához a tag egyedtípus melyik előfordulása tartozik addig a relációs modellben nem rögzítjük a kapcsolatot. Természetesen, mint az előbbi pontban láttuk a relációs adatbázis táblái között is van kapcsolat (azonos tartalmú oszlopokon keresztül) de az egyik reláció soraihoz (rekordjaihoz) nem fűzzük hozzá a másik reláció sorait.
    Ezt úgy is mondhatjuk, hogy a hálós adatmodellben az egyedek előfordulásai között statikus kapcsolat van, amit az ezekkel dolgozó adatbáziskezelő rendszerek ki is használnak, addig a relációk között ez a kapcsolat nem statikus hanem dinamikus.



Egy szintet vissza, vagy vissza a főmenübe.