Relációs adatmodell
A Wikipédiából, a szabad lexikonból.
A relációs adatmodell a számítógépes adatfeldolgozás során használatos elméleti modellek egyike. Jelenleg szinte egyeduralkodónak számít az adatkezelésben (egy másik jelentős adatkezelési lehetőség a hálós adatmodell; lásd még adatmodell,tudásreprezentáció). A relációs adatmodell a matematikai, konkrétan a halmazelméleti reláció fogalmára épít.
Gyakorlati, fizikai megvalósulása a relációs adatbázis, amelynek lényege, hogy az adatokat több táblázatba osztjuk szét, és a táblázatok között azok bizonyos oszlopai relációkat fejeznek ki. A relációs adatmodell alapján működő szoftvereket relációs adatbáziskezelőknek nevezzük.
Az adatmodellt dr. Edgar F. Codd 12 szabálya írja le, amelyeket 1970-ben publikált.
[szerkesztés] Matematikai és informatikai alapok
Ebben az adatmodellben véges sok tulajdonsággal, jellemzővel, jeggyel, idegen szóval attribútummal bíró véges sok egyedet vagyunk képesek (legalábbis a gyakorlatban) leírni. Minden jellemző attribútum is csak véges sok értéket vehet fel, ezek a tulajdonságok vagy értékek.
- Például ha egy használtautó-kereskedésben autókat akarunk leírni, akkor az autókat a rendszámmal, vagy más, egyedi jellemzővel azonosíthatjuk; az attribútumok lehetnek a márka (a „márka” jegy által felvehető tulajdonságok pl.: Audi, BMW, Ford, Lada, Opel, Volkswagen); a típus (pl. Focus, A8, Astra, Golf); a futott kilométerek (ez esetben a tulajdonság-értékek számok); a gyártás ideje (ekkor a felvehető értékek évszámok); és az eladási ára az egyes autóknak.
Egy egyed a rá jellemző valamennyi tulajdonsággal együtt alkot egy rekordot. A sok egyed sok rekordot jelent, ha egy táblázatot úgy készítünk el, hogy sorainak címkéi, fejlécei az egyedek, oszlopainak címkéi pedig az attribútumok legyenek, akkor jutunk az adattáblához. Az adattábla az egyedek halmaza és a jegyek halmazai között egy relációt határoz meg (matematikailag: ha az egyedek halmaza Ω, és n db. jegyünk-attribútumunk van: A1, A2, ..., An, akkor minden sor az Ω×A1×A2×...×An direkt szorzat, vagyis egy reláció egy-egy eleme.
[szerkesztés] Egy példa
A táblázatok (szaknyelven: adatbázis táblák) minden sora egyforma szerkezetű. Egy-egy sor a valóság egy egyedének a leírását (például egy személy, egy bankszámla, egy postázási cím) tartalmazzák. A táblázat sorait rekordoknak is nevezzük. Az oszlopok mindig a leírt egyed egy-egy tulajdonságát (például irányítószám, vezetéknév, bankszámlaszám, stb.) tárolják. Az oszlopok szokásos megnevezése még a mező. Tehát a mezők felelnek meg az attribútumoknak.
Példa adatbázis tábla, betegek nyilvántartására:
| TAJ szám | Vezetéknév | Keresztnév | Születési dátum |
|---|---|---|---|
| 123 456 789 | Kovács | István | 1933.03.03 |
| 987 654 321 | Horváth | Géza | 1967.12.23 |
Az adatbázis táblák egyes oszlopai (mezői) különleges jelentőségűek: ezek a kulcsmezők. A kulcsmezők írják le két adatbázis tábla között a relációt.
A relációs adatmodellben ajánlott, hogy minden táblának legyen elsődleges kulcsa (primary key), amellyel a tábla egy-egy sora azonosítható. Így a betegeket leíró táblában - ha az elsődleges kulcs a TAJ szám -, nem kerülhet be két beteg ugyanolyan TAJ számmal. A külső kulcsok esetében nincs ilyen előírás, ezek ugyanis hivatkozások egy másik tábla elsődleges kulcsára.
Példa külső kulccsal rendelkező adatbázis táblára:
| Lelet száma | TAJ szám | Lelet kérés dátuma | Lelet elkészült | Leírás |
|---|---|---|---|---|
| 17543 | 123 456 789 | 2004.08.18. | 2004.08.19. | Sürgős |
| 17544 | 123 456 789 | 2004.08.19. | 2004.08.23. | Kontroll vizsgálat |
| 17545 | 987 654 321 | 2004.08.23. | 2004.08.25. | Dr. Szabónak átküldeni |
Ebben a példában a tábla elsődleges kulcsa a Lelet száma, és tartalmaz egy külső kulcsot is, mégpedig a TAJ szám mezőt, amely a betegeket leíró tábla elsődleges kulcsára hivatkozik, létrehozva ezzel a relációt a két tábla között.
Itt, a példában a reláció alapján tudjuk megállapítani, hogy melyik lelet melyik betegé: a lelet rekordjában lévő TAJ szám mező kulcsként hivatkozik a betegek nyilvántartására, itt kikereshetjük ez alapján a beteget, és máris tudjuk a nevét. Nincs szükség arra, hogy a beteg nevét feleslegesen tároljuk minden lelet mellett. Ez nemcsak azért előnyös, mert a tárolókapacitással takarékoskodunk. Sokkal fontosabb előny ennél, hogy az adatokat egy, és csakis egy helyen kell karbantartani, ha valami változás következik be (például javítjuk valakinek a keresztnevét).
[szerkesztés] Kiegészítés
[szerkesztés] Codd szabályai
Az alábbiak a 12 szabály C.J. Date megfogalmazásában:
[szerkesztés] A 0. szabály
Ahhoz, hogy egy rendszer RELÁCIÓS-nak, ADATBÁZISNAK, és KEZELŐ rendszernek legyen nevezhető, elfogadható - a rendszernek a RELÁCIÓKKAL foglalkozó adottságait (kizárólag) az ADATBÁZIS KEZELÉSÉRE kell használnia.
[szerkesztés] I. Az egységes megjelenésű információ szabálya
Ez a szabály egyszerűen csak annyit ír elő, hogy az adatbázisban szereplő összes információt egy, és csak egy megadott formában lehet ábrázolni, nevezetesen a sorokba szedett táblázatokon belül egy-egy oszlop pozícióban. (vízszintes és függőleges koordinátarendszerben – a ford.)
[szerkesztés] II. Garantált lokalizálhatóság szabálya
Ez a szabály lényegében az elsődleges kulcs alapkövetelményének megfogalmazása másképpen. Azt mondja ki, hogy az adabázisban minden egyes skaláris értékre logikailag úgy kell hivatkozni, hogy megadjuk az azt tartalmazó táblázat és az oszlop nevét, valamint a megfelelő sor (azt tartalmazó sor) elsődleges kulcsának az értékét.
[szerkesztés] III. A NULL értékek egységes kezelése
Az adabáziskezelő rendszernek (DBMS) olyan módszerrel kell támogatnia a "hiányzó és nem felhasználható információt" amely egységes, és eltér az összes „rendes” érték kezelésétől (például numerikus értékek esetében, "nullától vagy más számtól különböző"-ként), továbbá független az adattípustól. Ebbe az is beletartozik, hogy ezeknek a reprezentációknak a kezelését a szoftvernek módszeresen kell végeznie.
[szerkesztés] IV. A relációs modell alapján aktív online katalógust kell üzemben tartani
A rendszernek támogatnia kell egy online, beépített katalógust, amely a szokásos lekérdező nyelvet használó feljogosított felhasználók előtt nyitva áll.
[szerkesztés] V. A teljeskörű „adatnyelv” szabálya
A rendszernek legalább egy olyan relációs nyelvet kell támogatnia, amelynek
- (a) lineáris a szintaxisa,
- (b) interaktívan és alkalmazási programokon belül is lehet használni, továbbá
- (c) támogatja az adat definiáló műveleteket (beleértve az adatok megjelenítési képeinek meghatározására szolgálókat), az adatmódosító (manipulációs) műveleteket (frissítés és visszakeresés is), biztonsági és jósági (integritási) korlátokat, valamint a tranzakció kezelési műveleteket (begin, commit, és rollback: elkezdés, jóváhagyás és visszagörgetés).
[szerkesztés] VI. A nézetek frissítésének szabálya
A rendszernek képesnek kell lennie az adatok elméletileg frissíthető minden nézetének frissítésére.
[szerkesztés] VII. Magas szintű beszúrás, frissítés és törlés
A rendszernek támogatnia kell az INSERT, UPDATE, és DELETE (új adat, módosítás, törlés) operátorok halmaz szintű, egyidejű működését.
[szerkesztés] VIII. Fizikai szintű adatfüggetlenség
A fizikai adatfüggetlenség akkor áll fenn, ha az alkalmazások (programok) és a felhasználók adatelérési módja független az adatok tényleges (fizikai) tárolási és elérési módjától.
[szerkesztés] IX. Logikai szintű adatfüggetlenség
Logikai adatfüggetlenség akkor áll fenn, ha az adatbázis logikai szerkezetének megváltoztatása nem igényli az adatbázist használó alkalmazások (programok) megváltoztatását.
[szerkesztés] X. Jóság (integritás) függetlenség
Az adatok jóságának (érvényességének) korlátait az adatfeldolgozási programoktól függetlenül kell tudni meghatározni, és azokat katalógusban kell nyilvántartani. Legyen lehetséges a szóban forgó korlátokat - úgy és amikor szükséges - megváltoztatni, anélkül hogy a meglévő alkalmazásokat szükségtelen módon zavarnánk.
[szerkesztés] XI. Elosztástól való függetlenség
A meglévő alkalmazások működése zavartalan kell, hogy maradjon
- (a) amikor sor kerül az adatbázis kezelő szoftver elosztott változatásnak bevezetésére a rendszerben
- (b) amikor a meglévő elosztott adatokat a rendszer újra szétosztja
[szerkesztés] XII. Megkerülhetetlenség szabálya
Ha a rendszernek van egy alacsony szintű (egyszerre egy rekordot érintő) interfésze, akkor azt az interfészt ne lehessen a rendszer megkerülésére használni, például a relációs biztonsági vagy jósági (integritás védelmi) korlátok megsértésével.
[szerkesztés] Források
- C.J. Date: An Introduction to Database Systems, (5.kiadás) 389 – 393 oldal
- Demetrovics - Denev - Pavlov: A számítástudomány matematikai alapjai. Nemzeti Tankönyvkiadó, Bp.


Based on work by