1. Adat, információ, tudás. Metaadatok.

Strukturált, szemistrukturált és nem strukturált

adatok.

Adat, információ, tudás

Adatok: egymástól független adatok, leírnak egy tulajdonságot. Információ: adatokat
kontextusba helyez-zük, ebből információt nyerhetünk ki, az információból pedig tudást.

Metaadatok
Az adatbázis fogalmi vázának (séma/struktúra) megteremtésére vonatkozó adatok a technikai
metaadatok, melyek egy különösen védett helyen kerülnek tárolásra, hiszen ezek
elvesztése/sérülése az adatbázis hozzá-férhetetlenségét is eredményezhetik.

Strukturált adatok
Olyan adatok, ahol az adatok ábrázolása (szintaxisa) megfelel az adatok alkalmazása során
felhasznált je-lentésüknek (szemantika). Mivel a szemantikát a feldolgozás előtt ismernünk kell,
lehetőség van stabil, az adatszerkezetet jól tükröző sémák előzetes definíciójára. Ez az összes
rendelkezésre álló, jövőben megjelenő adat szintaktikáját leírja. Hatékonyan jellemezhetők a
relációs és objektumorientált adatmodelleken.

Nem strukturált adatok

Olyan adatok, amelyeknek az aktuális alkalmazás szempontjából semmilyen használható
szemantikája, és emiatt felismerhető szerkezete sincsen.

Szemistrukturált adatok
Olyan adatok, amelyek az aktuális alkalmazás szempontjából hordoznak értékes szemantikus
információkat, de reprezentációjuk eltér a hasznos szemantikus jelentés által meghatározottól.
Példa a szemistrukturált tulajdonságokra:

 Szabálytalan struktúra
 Implicit struktúra (az adatstruktúra nem vagy nem teljesen található meg az adatforrásban.)
 A struktúra nem azonos a hagyományos (relációs/objektumorientált) adatbáziskezelő
rendszerekben használt sémával.
 Gyakori, hogy csak böngészni szeretnék az adatokat.

Szemistrukturált adatokra példa: XML, RDF (forrásleíró rendszer, feladata, hogy bármilyen
forrásból, tehát azonosítóval rendelkező dolgokról egyszerű állításokat tesz.)

2. Adatbázis-kezelő fogalma, feladatai, felépítése, használói

Adatbázis-kezelő fogalma
A mai adatbázis-kezelő rendszerek bonyolult hardver-szoftver rendszerek, melyek
bonyolultsága/ komplexitása az operációs rendszerekkel mérhetőek össze, gyakran nagyobbak is
annál. A megtervezése/implementálása bonyolult feladat, amelyre kifinomult rendszerek
léteznek.

Az adatbázis-kezelő felépítése
A felépítéskor eredményesnek bizonyult a rétegzési koncepció, vagyis a rétegmodell. Ennek
alapgondolata, hogy az eredeti problémát több részre kell szedni úgy, hogy ezek egymásra
épüljenek, de minél kisebb felületen érintkezzenek.
3 rétegű modell:

 Legalsó réteg:
fizikai adatbázis (adatok fizikai tárolón való
elhelyezkedése)
 Középső réget:
Fogalmi adatbázis (A való világ egy
darabjának leképzelése, sajátos modell a valóság tükrözésére)
 Felső réteg:
Nézetek (amit és ahogy a felhasználó lát az adatbázisból)
Megjegyzés: a nézetekhez tartozó sémákat gyakran külső sémának is nevezik.
 i. Lekérdezés feldolgozó: alkalmazástól, felhasználótól kapott kéréseket fordítja az
adatbázis-menedzser által értelmezhető nyelvre + optimalizálás.
ii. Sémafeldolgozó: az adatbázis logikai leírását értelmezi és fordítja le, a sémának
mindig rendelkezésre kell állnia.
iii. Adatbázis-menedzser: kezeli a felhasználó lekérdezéseit és emellett járulékos
feladatokat lát el.
1. Járulékos feladatok:
a. Adatvédelem
b. Adatbiztonság
c. Integritás
i. Formális: adott mező értékkészlete.
ii. Referenciális: egy adat több helyen van, meg kell egyeznie.
iii. Strukturális: sémákra való előzetes feltételek ellenőrzése.
d. Szinkronitás: bővebben tranzakciókezelés.
iv. Állománykezelő: biztosítja a hozzáférést az adatbázishoz. (Adatbázis alatt
általában csak fizikai adatbázist értünk.)
Tevékenységi szintek: Képzetlen felhasználó, Alkalmazás programozó, Adatbázis
adminisztrátor, DBMS tervező.

Adatfüggetlenségek
Kétféle adatfüggetlenségről beszélhetünk:
 Fizikai: a fizikai működés sémáiban véghezvitt változások nem érintik a fogalmi adatbázist.
Ha teljesül, a fizikai adathordozó egy teljesen eltérő paraméterekkel rendelekező
adathordozóra is kicserélhető.
 Logikai: akkor beszélünk, ha a logikai adatbázis megváltozása nem jár az egyes
felhasználásokhoz-felhasználókhoz tartozó nézetek megváltozásával.
(Ez az elvárás nem teljesül minden esetben.)

3. Heap szervezés

Alapötlet
Itt a legegyszerűbb a megoldás ötlete: Az adatokat legalább annyi blokkban tároljuk, amennyit a
rekordok száma megkövetel, de nem rendelünk hozzá kiegészítő struktúrát.

Keresés
Ha egyetlen rekordot kell azonosítani, akkor a háttértárról betöltjük a memóriába az
adatállomány blokkjait, majd végigolvassuk, míg meg nem találjuk az keresett rekordot (lineáris
keresés). Szerencsés esetben ez az első, szerencsétlen esetben az utolsó.
Átlagos keresési idő:

Törlés
A törlendő rekordot megkeressük (ismert időigény), majd a rekord fejlécében jelezzük, hogy
felszabadult, vagyis felülírható a terület. Ezt követően a megváltozott blokkot még vissza kell
írni.
Beszúrás
Ügyelni kell arra, hogy a rekordok egyediséget biztosító mezőinek értéke egyedi maradjon a
beszúrás után.
Először a törlés által felszabadított területeken próbálkozunk, ha ott nincs hely, akkor az
állomány végén. Ha itt sincs elég hely, akkor tárhelybővítést kell kérni.
Módosítás
Egyszerű, ha az egyediséget biztosító mezők értéke nem változik. Ekkor meg kell keresni a
rekordot, felülírni, majd visszaírni a háttértárra. Egyéb esetekben gondoskodni kell az
egyediségről.
4. Hash-állományok
Alapötlet
A legegyszerűbb változatában minden rekordhoz
egy értéket rendelünk egy optimálisan megválasztott
hash függvénnyel. Ezt egyértelműen képezi le.

Egy optimális gyakorlati megoldás a vödrös hash-

elés. Az állományt felosztjuk B részre úgy, hogy
minden rész legalább egy blokkból álljon.
Létrehozunk egy vödörkatalógust, mely a vödrök
első blokkjára mutat. Definiálunk egy hash
függvényt, mely lehetőleg egyenletesen képezi le az állományt [0, B-1] tartományra.
Gyakran használt hash függvény a h(K) = (c × K) mod (B) függvény.

Keresés
1. Meghatározzuk a rekord kulcsát,
2. Kiszámoljuk a h(K)-t,
3. Kiolvassuk a vödör katalógus h(K)-adik bejegyzését, majd a blokkokban keressük a rekordot.
Vödrön belül lineáris keresést végzünk. Ha nem találjuk a kiolvasott vödörben, a keresett elem
nem található az adatbázisban. Ha van találat, elég az állomány részét kiolvasni.

Törlés
Hash tárolás esetében kikeressük a kívánt elemet, onnantól hasonló a heap-hez.

Beszúrás
Itt is ügyelni kell az egyediségre. Kiszámítjuk a h(K) függvény értékét, és kiolvassuk a megfelelő
bejegyzést. Végigolvassuk a vödör tartalmát, ha nem lenne egyedi, hibajelzést küldünk. Egyéb
esetben szabad vagy törölt helyre beírjuk az adatot. Ha minden hely foglalt, akkor új rekordot
kell elhelyezni.

Módosítás
Ha nem érint kulcsmezőt, akkor kikeressük, és módosítjuk. Ha kulcsmezőt érint, akkor egy törlés
és egy beszúrás egymás utáni végrehajtása kell, hiszen a módosított rekord feltehetően egy másik
vödörbe fog kerülni.

Megjegyzések
1. Törekedni kell a keresés gyorsítására, mert a diszkterület könnyen bővíthető erőforrás
2. Nem támogatja az intervallumkeresést

5. Indexelt állományok

Az indexelt szervezés alapgondolata, hogy a

keresés kulcsát egy indexállományban
megismételjük, és a kulcs-hoz egy mutatót
rendelünk, amely a tárolt adat helyére mutat. A
kulcsot és a mutatót is rögzített hosszú-sággal
ábrázoljuk.

Az indexállományt mindig rendezve tároljuk.

Például, ha a kulcs numerikus, akkor
egyértelmű a rendezés (vagy betűknél ABC,
stb.). Összetett kulcsok esetén nekünk kell definiálni a rendezés módját, azonban ennek
választása jelentősen befolyásolhatja a hatékonyságot. Két csoportja létezik, attól függően, hogy
mihez rendelünk mutatót.
 Ha minden egyes adatrekordhoz rendelünk egy indexet, akkor az a sűrűindex,
 Ha adatrekordok csoportjához (tipikusan blokkokhoz) rendelünk indexet, az a ritkaindex.
6. Ritka indexek, B* fák

Ritka index
Ritka indexek esetén az indexrekordok azt határozzák meg, hogy az adatállomány rekordjai mely
blokkban találhatóak. Ennek következtében a egy blokkon bleül az adatrekordok szabad
rekordoknak tekinthetők. Ritka index esetén az adatállomány is rendezetten kell tárolni olyan
értelemben, hogy a blokkokban egy megadott intervallumba eső adatok legyenek

Keresés
T.f.h. a k1 kulcsú rekordra van szükségünk. Az indexállományban megkeressük azt a rekordot,
amelynek k2 kulcsa nagyobb azok közül, amelyek még kisebbek k1-nél (vagy egyenlőek).
A keresés lehet bináris, hiszen az indexállomány kulcs szerint rendezett. A k2 kulcsú indexrekord
mutatója megcímzi a blokkot, amelyen belül kell megkeresni a k1 kulcsú adatrekordot.
Ez a keresés lehet lineáris, de rendezett tárolás esetén lehet bináris.

Törlés
Megkeressük a törölni kívánt rekordot. Amennyiben nem a legkisebb a blokkban, töröljük.
Ellenkező esetben az indexállományt is korrigálni kell az új legkisebb kulcsnak megfelelően.
Ha a keresett rekord volt az egyetlen a blokkban, akkor a rá mutató indexrekordot is törölni kell.

Beszúrás
T.f.h. a k1 kulcsú rekordot akarjuk eltárolni. Először megkeressük azt a blokkot, amelyben a
rekordnak lennie kell (Bi blokk). Ha van elegendő hely, beírjuk a blokkba. Ha nincs, helyet kell
csinálni. Pl.: kérünk egy üres blokkot, majd a Bi blokk rekodjainak számát megfelezzük. Bi és Bn
között. Meghatározzuk a két blokkban a legkisebb elemeket, majd szükséges esetben Bi
indexrekorban korrigáljuk az értéket, a Bn-hez pedig új indexrekordot képezünk, amit
elhelyezünk az indexállományban. (Ehhez lehet, hogy az indexállományt is újra kell szervezni).

Módosítás
Ha nem érint kulcsot, a módosítás egyszerű (eddigiekhez hasonló.)
Ha érint kulcsot, akkor egy törlést követő beszúrás valósítja meg a rekord módosítását.

B* fák

Indexelt szervezésnél log2bi-vel arányos keresési idő érhető el. (kisebb, mint a heap, de nagyobb,
mint a hash.) A háttértár kihasználtsága kézben tartható. Ha bonyolítjuk a szervezést, lehetőség
van a blokkelérések számát csökkenteni logkbi-re (bizonyos esetekben, pl. nagyméretű
adatállományok vagy elég nagy k), jelentős a nyereség, viszont az indexeket egy k ágú fában kell
tárolni és ezt változáskor karban kell tartani.

A B* fák alapgondolata, hogy addig építünk egymásra ritka indexeket, ameddig az utolsó
index egyetlen blokkba bele nem fér. Tehát az i −1. index egyidejűleg ritka indexe az i. indexnek
és adatállománya az i −2. indexnek. A legalsó szint mutatói pedig az adatállomány egy-egy
blokkjára mutatnak. A B* fák ezen belül is olyan változatai ezen fáknak, ahol minden levele és
csomópontja pontosan blokkméretű és a gyökértől a levelekig vezető út mindig ugyan olyan
hosszú.
Elágazási tényező (blocking factor):

A fa magassága (heigh of tree): HTi = dlogfi bre

Keresés
Hasonló az egyszintű ritkaindexhez.
Beszúrás
Hasonló az egyszintű ritkaindexhez, annyi különbséggel, hogy van, amikor ügyelni kell a
fastruktúra kiegyen-lítettségét karban kell tartani.
Törlés
Megkeressük a kívánt adatot és töröljük, illetve az adatblokkban ha van lehetőség, összevonunk.
Módosítás
Hasonló az egyszintű ritkaindexhez.
7. Sűrű indexek

Ritka indexeknél két probléma merül fel: Az adatállományt rendezetten

kell tárolni, illetve a rendezettség miatt nincs mód arra, hogy egy-egy
új rekordot tetszőleges szabad helyre szúrjuk be (csökkentené a
háttértár kihasználtságát).

Ezekre nyújt megoldást a sűrű indexelés, ahol minden adatrekordhoz

egy-egy indexrekord tartozik. A blokkelérések számát ezzel nem lehet
csökkenteni, de a blokkon belüli keresést igen.

Megjegyzés: a sűrű indexelés önmagában nem egy állományszervezési módszer, erre mindig
épül egy másik módszer is (ritka index, hash, stb.). Ez a módszer elsősorban a fő állomány
kezelését könnyíti meg.

Sűrű index blokkszáma:

Hátrányok
 eggyel több indirekció kell,
 plusz adminisztráció.

Előnyök
 nem kell rendezetten tárolni, helytakarékos,
 gyorsítja a keresést,
 Több kulcs szerinti keresés.
 az adatállomány rekordjai szabaddá tehetőek, ha minden további hivatkozás a sűrű indexen
keresztül történik.

Keresés
Bináris kereséssel.
Törlés
Megkeressük a törölni kívánt rekordot, a törölt bitet szabadra állítjuk, a kulcsot pedig kivesszük
az indexál-lományból (ezt időnként tömörítjük).
Beszúrás
Hasonló a heap vagy hash-hez. Helyet keresünk, beállítjuk a foglaltsági jelzést, beírjuk az adatot.
A kulcsot és a tárolás helyére hivatkozó mutatót a kulcs szerint berendezzük az
indexállományba.
Módosítás
Megkeressük és módosítjuk. Ha kulcsmező is érintett, akkor az indexállományt újrarendezzük.

8. Változó hosszúságú rekordok kezelése

A változó hosszúság oka

 Egy mező hossza változó
 Ismétlődő mező(csoport) van a rekordban

Megoldás
Egy rekord változó hosszúságú részeit a rekord mezőlistájának végén helyezünk el, így a rekord
eleje fix hosszúságú marad.

Az első esetben a leggyakoribb megoldás, hogy a változó hosszúságú mező helyett egy fix
hosszúságú mutató van a rekordban, a mező tényleges tartalma egy külön állományban tárolódik.
(biztosítja, hogy az állomány egyféle rekordot tartalmaz, könnyebb karbantartás).

A második esetben három megoldás van:

 Lefoglalt hely módszer
(a maximális számú ismétlődéshez elengendő helyet foglalunk le),
 Mutatós módszer
(az első megoldáshoz hasonló),
 Kombinált módszer
(valamennyi helyet lefoglalunk, ha még több az ismétlődés, akkor mutatós módszer).
9. Részleges információ alapján történő keresés

Gyakori, hogy egy rekord több mezőjének értékét ismerjük, és keressük azon rekordokat,
amelyek ugyanezeket az értékeket tartalmazzák ugyanezen mezőikben. Feltételezzük, hogy
egyik sem kulcs.

 Minden mezőre építünk indexet:

Egyik lehetőség, hogy több mezőre építünk indexeket, és minden speciális mező-érték alapján
előállítunk egy találati rekordhalmazt, és ezek metszetét képezzük. Ez nem praktikus.
 Partícionált hash:
Másik lehetőség a feldarabolt (particionált) hash függvények alkalmazása.
Ezesetben a hash függvény h(m1, m2, ..., mk) = h1(m1) × h2(m2) × ...hk(mk) alakú, ahol mi-k a rekord
összesen k darab, releváns mezőinek értékét jelentik, hi az i-edik mezőre alkalmazott hash
függvény kom-ponens, × pedig a konkatenáció jele. A hi függvényeket úgy kell megválasztani,
hogy az x1 + x2 + ... + xk érték, azaz a teljes cím hossza éppen N legyen.

Használata
Az ismert mezők értékei alapján meghatározhatjuk az N hosszúságú bitmintának az ismert értékű
mezőhöz tartozó darabjait, a többi nyilván tetszőleges lehet. Mindazon vödröket végig kell
néznünk illeszkedő rekordok után, melyeknek sorszáma illeszkedik a kapott mintára.

10. Több kulcs szerinti keresés

Gyakori az igény, hogy nem kulcsmezők alapján készítsünk lekérdezéseket, keressünk vagy
listázzunk. Általában több mező szerint is támogatni kell az adatrekordok megtalálását. Gyakran
beszélnek ilyenkor is kulcsokról, azonban fontos hangsúlyozni, ha csak a fizikai keresés során
tekintünk egy mezőt kulcsnak. (Keresési kulcs: bármely mező lehet, nem csak kulcs)

Több mód is létezik arra, hogy több kulcs alapján lehessen keresni, pár példa:
1. Több indexállomány, minden keresési kulcshoz egyet.
2. Invertált állomány (def.: Az az indexállomány, amely nem kulcsmezőre tartalmaz
indexeket.)

Az invertált állomány mutatói:

1. Fizikai mutatók, melyek mutathatnak:
a. Az adatállomány megfelelő blokkjára,
b. az elsődleges kulcs szerint indexállomány megfelelő rekordjára,
2. Logikai mutatók, amelyek az adatállomány valamely kulcsának értékét tartalmazzák.

Az 1.(a) esetben az adatállomány rekordjai kötöttek és csak egyetlen invertált állomány esetén
használ-ható.
Az 1.(b) esetben eggyel több indirekción keresztül érhetjük el a keresett rekordot, de változáskor
csak az érintett mező(ke)t tartalmazó invertált állományt és indexállományt kell módosítani.
Ha a 2. megoldást választjuk, akkor az adatállomány rekordjai szabadok lehetnek, viszont nem
ismerjük még a keresett rekord címét. Ennek megtalálását hasheléssel vagy valamilyen indexes
módszerrel támogat-hatjuk.

11. Adatmodellek, modellezés

Adatbázis létrehozásakor a cél, hogy a való világ adatait tároljuk, információt szerezve belőle
ahelyett, hogy a világból tennénk. Nincs mód egy adott problémakörrel kapcsolatos minden adat
eltárolására, egy meghatározott, szűk kört kezelünk. Az adatoknak egy meghatározott szűk
körét használjuk fel. Tehát egy leegyszerűsített képet alkotunk világunkról.
Az adatbázis így a világ egy leegyszerűsített képét adja vissza.
A kialakításkor követhetünk bizonyos konvenciókat, ami számos előnnyel járhat (de
természetesen hátrányokkal is). Ezek egy része arra vonatkozik, hogy milyen formában, milyen
kapcsolatok kialakítását támogatjuk, illetve, hogy milyen műveleteket engedélyezünk az
adatainkon. Így adatmodelleket hozunk létre.

Egy adatmodell lényegében Formalizált jelölésrendszer adatok, adatkapcsolatok leírására,

amelyeken Műveletek hajthatók végre.

Az adatmodell tulajdonságai alapvetően meghatározzák az adatbázis tulajdonságait.

A felhasználónak a legfontosabb jellemző az adatbázis formája, amelyben a tárolt adatok közötti
összefüggések ábrázolva vannak. Az egyik alapegység a rekord/rekordtípus. Mivel az adatbázis
struktúráját jelentős részben a rekordtípusok közötti kapcsolatok határozzák meg, az
adatmodelleket aszerint osztályozzuk, hogy milyen kapcsolatok definiálása engedélyezett a
rekordtípusok között (miként kerül ábrázolásra).

Az adatmodelleket meghatározza, hogy az adatbázisban az adatok milyen struktúrában

tárolódnak, milyen mechanizmusokon keresztül lehet az adatokhoz hozzáférni. Így az
adatbáziskezelő rendszer legalapvetőbb tulajdonságait rögzíti.

12. Az ER modell és elemei

Az ER modell nem tekinthető teljesen adatmodellnek, mert nincsenek benne műveletek

definiálva, de formalizált jelölésrendszer az adattok/adatkapcsolatok leírására.

Az ER modellek elemei
 Egyedtípusok,
 Attribútumtípusok,
 Kapcsolattípusok.
Természetesen a típusokhoz tartoznak konkrét
példányok is, de a modellezés típus szinten
történik. Az egyedek bizonyos közös jegyek
alapján halmazokba rendeződnek. Egy-egy
halmaz neve az egyed típusa, elemei a
példányok.

Entitások
 Egyed:
a valós világban létező, logikai/fizikai szempontból saját léttel rendelkező dolog, amelyről
adatokat tárolunk.
 Tulajdonság:
az entitásokat jellemzi, amelye(ke)n keresztül az entitások megkülönböztethetők.
 Egyedhalmaz:
az azonos attribútumtípusokkal jellemzett egyedek összessége.

Kapcsolatok
Az egyedek ritkán léteznek elszigetelten, valamilyen kapcsolatban állnak egymással. Ezeket
fejezzük ki a kapcsolattípusokkal. Tehát Kapcsolat: entitások névvel ellátott viszonya.
(Kapcsolattípus: entitás típusok névvel ellátott sorozata.)

Funkcionalitás (kardinalitás)
A kapcsolatok különbözhetnek abban is, hogy egy entitáshalmaz egy eleméhez egy másik
entitáshalmaz hány elemét kötik
1. Egy-egy kapcsolat
Olyan (bináris) kapcsolat, amelyben a résztvevő entitáshalmazok példányaival
egy másik entitáshalmaznak legfeljebb egy példánya van kapcsolatban.
2. Több-egy kapcsolat
Egy K: E1, E2 kapcsolat több-egy, ha E1 példányaihoz legfeljebb egy E2-beli
példány tartozik, míg E2 példányai tetszőleges számú E1-beli példányhoz
tartoznak.
3. Több-több kapcsolat
Egy kapcsolat több-több funkcionalitású, ha nem több-egy egyik irányban sem.

Megjegyzés: a több-egy kapcsolatok kitüntetett szereppel bírnak, mert egyszerűen

ábrázolhatóak, de elegendően általánosak is.

Kulcs
Az ER modellezésnél az attribútumnak azt a halmazát, amely az entitás példányait egyértelműen
azonosítja, kulcsnak nevezzük. Legalább egy kulcsnak kell lennie.
13. Az ER diagram, ISA kapcsolatok, gyenge egyedhalmazok

A gyakorlatban az ER modelleket ER diagramokon szokás ábrázolni. Elemei:

 egyedhalmaz, attribútum, kapcsolat.

ISA kapcsolat
Gyakori, hogy egy entitáshalmaznak minden eleme rendelkezik egy másik, általánosabb
entitáshalmaz attri-bútumaival, de azokon kívül még továbbiakkal is. Ez a sajátos viszony az
"ISA" kapcsolat. (Az objektum-orientált modelleknél kitüntetett szerepe van).

Gyenge egyedhalmazok
Szintén gyakori, hogy a modellezés során egy entitáshalmaznak nem tudunk kulcsot
meghatározni, hanem ahhoz valamely kapcsolódó egyedekre is szükség van. Ebben az esetben
beszélünk gyenge egyedhalmazról. Ennek egyediségét egy vagy több tulajdonos egyedhalmaz
biztosítja, ami a gyenge egyedhalmazzal több-egy kapcsolatban áll. A kapcsolat neve
determináló kapcsolat. A gyenge egyedhalmaz példányait egyértelműen megkülönböztető
attribútumokat aláhúzással jelöljük.

14. A relációs adatmodell: adatok strukturáltsága és műveletek

A relációs adatmodelleken alapuló adatbázis kezelők ma a legelterjedtebbek.

Az adatok strukturáltsága
A relációs adatmodell mögött a halmazelméleti relációk elmélete húzódik meg.
Reláció: Halmazok Descartes-szorzatának részhalmaza.

Adott n halmaz, azonos elemeket nem tartalmazhatnak. A halmazokban található értékek egy-
egy domainből (tartomány) kerülnek ki. (D1, D2, ..., Dn).
A tartományok D1 ×D2 ×...×Dn Descartes-szorzatában megtalálhatók mindazon n-elem, amelyre
igaz, hogy vi ∈ Di, ∀i = 1, 2, ..., n-re.
A sorrendnek érdemi jelentősége sehol sincs.

Áttekinthetőbb ábrázolás a táblázatos forma. Az oszlopok (attribútumok) tartományokhoz

vannak hozzárendelve, amelyekből az egyes oszlopokban található értékek kikerülnek. Az egyes
attribútumok különböző értékeinek száma az attribútum kardinalitása. A táblázat sorai pedig a
reláció elemei.

További elnevezések:
 Adatbázis séma: több relációs sémát tartalmazó adatbázis estén, a sémák összessége,
 Reláció foka: a relációban lévő oszlopok száma,
 Reláció számossága: a relációban lévő sorok száma.

Szabályok:
 A reláció nem tartalmazhat két azonos sort,
 Az sorok sorrendje nem számít,
 Az oszlopoknak egyértelmű nevük van.

Műveletek
1. Egyesítés, unió (r1 ∪ r2),
2. Különbségképzés (r1 \ r2),
3. Descartes-szorzat (r1 × r2, mindent mindennel szorozni),
4. Vetítés, projekció (π, oszlopok elhagyása),
5. Kiválasztás, szelekció (σ, sorok elhagyása),
6. Természetes illesztés (r1 r2, azonos attribútum alapján illesztjük),
7. Θ illesztés (feltétellel történő natural join)
8. Hányados (r1 ÷ r2, az a reláció, amelyre igaz, hogy az r2-vel alkotott Descartes-szorzata a
lehető legbővebb részhalmaza r1-nek).

Megjegyzés: A metszetképzés nem alapművelet: A ∩ B = A \ (A \ B).

Megjegyzés: ezen alapműveletekből épül fel a relációs algebra.
15. Relációalgebra
Műveletek
 Relációs algebra: a relációs adatmodellben a relációkon megengedett műveletek
halmaza.

 Egyesítés, unió: feltétele, hogy az egyesítendő relációk fokának meg kell

egyeznie. Nem szükséges azonban, hogy azonos attribútumokból álljanak.
 Különbségképzés: feltétele, hogy az egyesítendő relációk fokának meg kell
egyeznie. Bevezethetnénk a metszetképzést, de az egyesítés és
különbségképzés műveletekkel kifejezhető.
 Descartes-szorzat: az operandusok szerkezetére ebben az esetbe nincs
megkötés.
 Vetítés, projekció: egyoperandusos művelet, azt jelenti, hogy a reláció összes
rekordjának egyes attribútumait megtartjuk, míg a többit elvetjük. Amennyiben
az eredmény ismétlődő sorokat tartalmaz azon ismétlődéseket meg kell
szüntetni.
 Kiválasztás, szelekció: egyoperandusos művelet, egy részhalmaz képzése a
reláción, amelynek vezérlésére egy logikai formula szolgál. A reláció minden
elemére kiértékeljük ezt a formulát és csak azokat vesszük be az új relációba,
amelyekre igaz értéket kaptunk. Ez az úgynevezett szelekciós feltétel, ami
kvantormentes, és 3 elemet tartalmazhat: konstansokat vagy az attribútumok
azonosítóit, aritmetikai összehasonlító operátorokat, logikai operátorokat
 Természetes illesztés: adott két reláció, melyeknek tipikusan van legalább egy –
de akár több – megegyező nevű attribútuma. Vegyük sorra a két reláció
rekordjait és válasszuk ki közülük azokat, amelyek a megegyező nevű
attribútumai érték szerint is megegyeznek. Fűzzük össze ezeket olyan
rekordokká, amelyben a mindkét relációban szereplő, azonos nevű és értékű
attribútumokat csak egyszer vesszük figyelembe. Ezen rekordból képzett reláció
lesz a természetes illesztés eredménye. Közös nevű attribútumok hiányában
Descartes-szorzatba megy át.
 Theta-illesztés: illesztés két reláció között feltétel megadásával. A két reláció
Descartes-szorzatából a feltételnek megfelelő sorokat vesszük csak be az új
relációba. A feltétel ugyan olyan felépítésű és tulajdonságú, mint a
kiválasztásnál.
 Hányados: a hányados az a reláció, aminek az egyik relációval vett Descartes
szorzata a lehető legbővebb részhalmaza a másik relációnak

A relációs algebra és annak lehetőségei már ismertek fent. Célszerű hangsúlyozni, hogy az ily
módon megfogalmazott adatbázis-lekérdezéseknél explicit módon elő kell írnunk, hogy mely
relációkon vagy reláción milyen műveleteket milyen sorrendben fogunk elvégezni, hogy a kívánt
eredményt kapjuk. A relációs lekérdezéseknek ez az egyik legjelentősebb tényezője a relációs
adatbáziskezelők sikerének.
A relációalgebra műveletei az előzőekben voltak definiálva.

16. Sorkalkulus, oszlopkalkulus

Elsőrendű nyelv, kvantorokat tartalmazhat, és ezen kvantorok sorvektor változókat
kvantifikálhatnak.

Relációs sorkalkulus

Felépítése szimbólumok > atomok > formulák > kifejezések.

A nyelv szimbólumaiból atomokat, alapformulákat hozhatunk létre, amelyek formulákká
építhetők, a formulák pedig kifejezésekké. Ezek alkalmasak arra, hogy segíségükkel relációkat
írjunk le.
Megjegyzés: A sorkalkulus kifejezőereje legalább akkora, mint a relációs algebráé, azonban
fordítva ez nem igaz! A sor/oszlopkalkulus kifejezőereje nagyobb, mint a relációs algebráé.
A sorkalkulus által kifejezett reláció: {t(k) | φ(t)}

 Szimbólumai(8):
1. zárójelek, aritmetikai relációk, logikai műveletek, sorváltozók, sorváltozók
komponensei, relációk, konstansok, kvantorok.
 Atomok
1. R(m)(s(m)): (ahol R alapreláció), akkor igaz, ha s ∈ R, azaz a sor benne van a
relációban
2. s(n)[i] θ s(k)[j], ahol 1 ≤ i ≤ n, 1 ≤ j ≤ k és θ aritmetikai relációjel
 3. s(n)[i] θ c
4. R(m)(c1, c2, …, cn)
 Formulák
1. minden atom formula
2. ha Ψ1 és Ψ2 formulák, akkor Ψ1 ⋀ Ψ2, Ψ1 ⋁ Ψ2, ¬Ψ1 is formulák
3. ha Ψ formula és s(n) egy szabad sorváltozója, akkor (∃s(n)) Ψ és (∀s(n)) Ψ is
formulák, amelyekben s(n) már kötött sorváltozó
 Kifejezések
felépítése: { s(m)| Ψ (s(m))}, ahol s(m) a Ψ (s(m)) formula egyetlen szabad sorváltozója

Relációs oszlopkalkulus
A relációs oszlopkalkulus elsősorban abban különbözik a sorkalkulustól, hogy sorváltozók
helyett egyszerű változók szerepelnek benne. Tapasztalat szerint bizonyos lekérdezések
egyszerűbben fogalmazhatóak meg ebben az esetben. Felépítése a sorkalkuluséhoz hasonló.

Ez az SQL nyelv alapja.

Oszlopkalkulus oszlopváltozó: egy koordinátája a sorváltozónak, mint vektornak

A oszlopkalkulus által kifejezett reláció: {x1, …, xk | Ψ(x1, …, xk)} ⇒ azon x = (x1, …,

xk) vektorok,
amikre Ψ(x1, …, xk) igaz, ahol Ψ egy megengedett formula és csak x 1, …, xk szabad
változók benne.

17. Biztonságosság

A biztonságos kalkulus célja, hogy a kalkulus kifejezés kiértékelhető legyen számítógépben

kezelhető méretű relációk/véges idő mellett is. Alapgondolata, hogy le kell szűkíteni azon
változóértékek halmazát, amelyek a sorkalkulus kifejezés formuláját igazzá tehetik egy olyan
halmazra, amely magából a bemeneti relációkból és az esetleges egyéb konstansokból áll.

Megjegyzés: a biztonságos sorkalkulus és a relációs algebra kifejezőereje ekvivalens.

 Azért van rá szükség, mert a megismert nyelvekkel kifejezhetünk olyan

halmazokat, amelyek számítása nem véges számítógéppel. Tehát véges idő
mellett végrehajtható műveletekre szűkítjük az eddigi kifejezéseinket. Ehhez
szűkíteni kell a változók értékeinek a halmazát.
 DOM (Ψ) = { Ψ-beli alaprelációk összes attribútumának értékei } U { Ψ-beli
előforduló konstansok }
 Biztonságos.
a. Minden a formulát kielégítő t DOM-beli.
b. Minden részformula is DOM-beli.
 Biztonságosság eldöntése:
a. (∀u) R(u) ∩ … alakú formulák mindig biztonságosak u-ban
b. (∃u) R(u) … alakú formulák ekvivalensek ⌐(∀u) ⌐R(u) –val

18. Relációs lekérdezések heurisztikus optimalizálása

A költségalapú optimalizálás legnagyobb hátránya az optimalizációs algoritmusnak a költsége.

Ezért gyakran használnak heurisztikát a megfelelő kifejezés kiválasztásához. Egy heurisztikus
optimalizálás szabályai a következők lehetnek:

1. Induljunk ki a kanonikus alakból (Descartes-szorzatokat, szelekciókat, projekciókat

tartalmaz ilyen sorrendben),
2. Bontsuk szét a szelekciók konjunkcióját szelekciók szorzatára, hogy minden szelekciónak
csak egy tényezője legyen (lehetőség, hogy a közbenső műveletek jóval kevesebb
rekordot adjanak végeredményként),
3. A kiértékelési fában vándoroltassuk lefelé a szelekciókat,
4. Határozzuk meg, hogy mely szelekció és join eredményezi a legkisebb relációkat.
Használjuk az asszociativitást, hogy ezek hajtódjanak végre először,
5. Ha egy join megegyezik egy Descartes-szorzattal, amit egy szelekció követ, használjunk
Θ-joint.
6. Törjük szét a projekciólistákat. Amennyire lehet, lökjük lefelé a fán a projekciókat.
 7. Keressük meg azokat a részfákat, ahol pipeline-t lehet alkalmazni.

Ha betartjuk a szabályokat, akkor több relációs algebrait fát kapunk. Ezek csomópontjánál újabb
heurisztikák alapján algoritmusokat és pipeline-okat alkalmazunk.
Ezeknek meghatározható a költsége, melyek közül a legolcsóbbat választjuk.

19. Relációalgebrai kifejezések transzformációi, ekvivalens kifejezések

Egy adott lekérdezéshez formális úton több, egymással ekvivalens relációs algebrai alakot is
konstruálhatunk, amelyek általában különböző költségekkel hajtható végre.

Ekvivalens kifejezések
Példaként az alábbi lekérdezés (add meg azon betétesek nevét, akiknek a számlája Bázelben
van):

Ennek a formának a költsége nagyon nagy lenne, hiszen három reláció illesztése után végezné
csak el a szelekciót. Sokkal hatékonyabb lenne így:

Ez takarékosabb, mert először végrehajt egy szelekciót, majd ezt követően illeszti a maradék
kifejezéssel.
A legkisebb költségű végrehajtási terv megtalálása az optimalizáló feladata. Első teendője, hogy
az adott lekérdezésekhez ekvivalens algebrai alakokat találjon meg, majd ezekhez alternatív
végrehajtási terveket kell készítenie.

Ekvivalencia szabályok

Az ekvivalens alakok legenerálásához szükség van szabályokra, amelyek mentén az optimalizáló

el tudja végezni a feladatát.

 Θ1, Θ2, Θ3 predikátumok,

 L1, L2, L3 attribútumhalmazok,
 E1, E2, E3 egyedhalmazok.

Szabályok a teljesség igénye nélkül, példaként:

20. Relációs lekérdezések költségbecslés alapú optimalizálása

Az előzőleg felsorolt azonosságok alkalmazásával a fordító először felsorol minden, az

eredetivel ekvivalens kifejezést, amelyekhez hozzárendelhetőek végrehajtási tervek. Ezek közül
a megfelelő kiválasztásának folya-mata a költségoptimalizálás.

Minden végrehajtási tervre kiszámíthatjuk a költséget, és kiválaszthatjuk a legolcsóbbat.

Hátránya, hogy egyszerre akár túl sok ilyen terv is készülhet, ami rengeteg munkát jelent a
rendszernek. Például 3 relációt hatféleképpen illeszthetünk egymáshoz, és ezt még szorozni kell
kettővel a zárójelektől függően.

Általános esetben n reláció joinjai ekvivalens alakjainak száma:

Szerencsére nincs szükség az összes ekvivalens kifejezésre. Némi heurisztikával kezelhetőbb

méretűvé csökkenthető a problématér. Azonban az egyik legnagyobb probléma, hogy nem
minden esetben képes megtalálni az optimális megoldást. Ennek oka, hogy az algoritmus mohó
lévén mindig a lokálisan legjobb megoldást választja, nem mérlegeli, hogy rosszabb lokális
megoldás esetén jobb globális megoldást kapnánk. Sajnos olyan algoritmus nem létezik, amely
kis komplexitás mellett képes lenne az optimális megoldást legenerálni, ezért be kell érni
szuboptimális megoldásokkal.

21. Katalógusban tárolt információk

A lekérdezés feldolgozásához valamilyen becsült (fontos, hogy becsült, nem egzakt)

költségmérték hozzá-rendelése alapján végezhető. A becslés elvégzéséhez az adatbázis-kezelő
rendszernek a relációkról különböző statisztikákat kell vezetnie.

A statisztikákat elvileg minden adatbázis módosítás után vezetni kellene, de ez nagyon

megterhelő a rendszernek. Valójában akkor történik, ha a rendszernek "van rá ideje", emiatt a
statisztika nem mindig konzisztens, de általában elég jó. A statisztikákat a rendszer egy
katalógusban tárolja.

Katalógusban tárolt információk a relációkra vonatkoztatva

 nr: a relációkban lévő rekordok száma,

 br: a relációkban lévő blokkok száma,
 sr: a relációkban lévő rekordok mérete,
 fr: a reláció blocking factor-a,
 V(A,r): hány különböző értéke fordul elő az A attribútumnak az r relációban.

(V (A, r) = |πA(r)|.
Spec.: Ha A kulcs, akkor V (A, r) = nr),

 SC(A,r): azon rekordok várható száma, amelyek kielégítenek egy egyenlőségi feltételt A
attribútumra. (Selection Cardinality).

Megjegyzés: ha A egyediséget biztosít, akkor SC(A, r) = 1. Egyéb esetben, ha az eloszlás nem

ismert, akkor feltesszük, hogy egyenletesen oszlik el. Ekkor, SC(A, r) =

Katalógus információk az indexekről

Az indexek ugyan gyorsíthatják a keresést, de a létrehozás és karbantartás nagyobb

adminisztrációs feladat, mint ami a használat során megtérülhet. (A hash állományokat itt
speciális indexeknek tekintjük).

Az indexeket az alábbi paraméterekkel jellemezhetjük:

 fi: az átlagos pointer-szám a fa struktúrájú indexek csomópontjaiban,
 HTi: a fa magassága. Pl.: Heap szervezésre épített B* fa esetén HTi = dlogfi bre, Hash
állománynál HTi = 1.
 LBi: az i index legalsó szintű blokkjainak a száma (levélszintű indexblokkok száma, Lowest
Level index Blocks).
22. A lekérdezés költsége: szelekció, indexelt szelekció, join műve-letek és algoritmusok,
egyéb műveletek

A lekérdezés költsége

A lekérdezés kiértékelés költségének meghatározása történhet az igényelt és a felhasznált

erőforrások alapján (processzoridő, háttértárhoz fordulás, stb.). Válaszidő alapján nem éri meg,
mert nagyon sok mindentől függ, így az nem pontos.

A nagy adatbázis-kezelő rendszerekben a költség becslésére a háttértár blokkműveleteinek

számát veszik alapul, mert ez minden más tényezőtől független. A használható költségmérték
megalkotásához fontos a probléma megfelelő szintű egyszerűsítése. (Alapfeltételezések:
blokkelérési idő azonos, nem számít a lemez forgási iránya/sebessége, nincs különbség olvasás
és írás között.)
Jelölés: Ealg = az algoritmus becsült költsége (estimate).
Szelekció
A legalacsonyabb szintű művelet. Egyszerű esetben egyetlen állományban tárolódnak, ezért a
keresési mű-velet csupán egy fájlra korlátozódik.

Alap szelekciós algoritmusok

1. Lineáris keresés: Minden rekordot beolvasunk, és megvizsgáljuk, hogy teljesül-e a feltétel.
EA1 = br,

Összehasonlítás alapú szelekció

Join operáció
Egymásba ágyazott ciklus illesztés (Nested loop join)
Költséges eljárás, legrosszabb esetben br + nr · bs.
Ha a két reláció befér a memóriába, akkor br + bs.

Blokk alapú egymásba ágyazott ciklus illesztés (block nested loop join)
Okosabb, mint a Nested loop join, mert kihasználja a tárolás fizikai sajátosságait. Azáltal lesz
gyorsabb, hogy blokk alapú összehasonlítást végez.
Legrosszabb esetben br + br · bs, legjobb esetben br + bs.

Index alapú egymásba ágyazott ciklus illesztés (indexed nested loop join)
Ez az algoritmus kihasználja, hogy az egyik relációhoz van indexünk. Ha a Nested loop join
belső ciklusába az indexelt relációt tesszük, akkor nem szükséges minden s beli rekordot
végigvizsgálnunk, mert a keresés index alapján kisebb költséggel is elvégezhető.
Költség: br + nr · c, ahol c a szelekció költsége s-en.

Összefésülés alapú illesztés (merge join)

Az illesztés elvégezhető, ha mindkét relációt először rendezzük az illesztési feltételnek megfelelő
attribútum szerint. Ezután elég csak végigolvasni mindkét relációt, hiszen az illeszkedő elemek a
rendezés következtében egymás után kerülnek. Költség: br + bs + rendezés. Ha a relációk igen
nagyok, és hatékonyan rendezhető, gyakran ez a legkisebb költségű illesztés.

Hash-illesztés (hash join)

Az egyik relációt hash-táblán keresztül érjük el, miközben a másik reláció egy adott rekordjához
illeszkedő rekordokat keressük. Ebben az esetben a join algoritmus belső ciklusát a hash-
állomány segítségével történő keresés váltja fel.

Egyéb műveletek
 Ismétlődés szűrése:
először rendezni kell, majd utána törölni. Költség: a rendezés költsége,
 Vetítés:
minden rekordra végrehajtjuk, aztán töröljük az ismétlődéseket.
Ha rendezett, a költség br, általánosan br + rendezés,
 Egyesítés:
Mindkét relációt rendezzük, majd összefésülésnél kiszűrjük a duplikációkat,
 Metszetképzés:
Rendezés, majd összefésülés (csak a közös rekordokat figyelembe véve),
 Különbségképzés:
 Mindkét relációt rendezzük, összefésülésnél csak azok maradnak, amik az első relációban
szerepeltek.

23. Materializáció és pipelining

Materializáció (megtestesítés, létrehozás)

Egy relációs fa felépítése: levelekben vannak a relációk, a csomópontok pedig a műveleteket
jelölik. A fa alapján a materializációs stratégia lépései könnyen nyomon követhetőek. Az első
lépés egy olyan művelet, amelyhez az operandusok rendelkezésre állnak.

A stratégia minden relációt kiszámít a fában, miközben létrejönnek közbülső relációk is.
A materializáció költsége tehát a végrehajtott operációk költségének összege, plusz a közbülső
relációk tárolásának és visszaolvasásának költsége.

Pipelining
A kiértékelés hatékonysága növelhető, ha redukáljuk az ideiglenesen tárolásra kerülő rekordok
számát. A pipeline lényege, hogy a részegységek az előttük álló elemből kapott
részeredményekből a sorban következő számára állít elő részeredményeket, így kiküszöbölhetjük
a tárolás szükségességét.

Előnye, hogy kicsi a memóriakövetelmény, mert az eredményeket nem tároljuk sokáig, egyből
továbbadjuk.

Hátránya az, hogy hogyha nincs közbülső reláció, akkor nem tudunk rendezni sem.

Kétféle pipeline-t különböztetünk meg: az igényirányított és a termelőirányított.

 Az igényirányított esetben maga a rendszer fordul a pipeline tetejéhez és kér rekordokat.
Ha a pipeline megkapja ezt a kérést, kiszámítja és átadja a rendszernek.
 Termelőirányított pipeline esetén a csővezeték mentén elhelyezkedő műveletek nem várnak
kérésre. A pipeline legalsó szintjén minden művelet folyamatosan generálja a rekordokat és
egy pufferbe teszi, amíg az meg nem telik. Minden szinten minden művelet egymástól
függetlenül dolgozik.

24. A kiértékelési terv kiválasztása

Az ekvivalens kifejezések generálása csak az első lépése az optimalizálásnak. A második

lépésben minden kifejezéshez konkrét algoritmusokat kell rendelni. Meg kell mondani, hogy
milyen műveleteket milyen sorrendben, milyen algoritmus szerint, milyen munkafolyamatba
szervezve hajtsuk végre.

25. Relációs adatbázis sémák tervezése ER diagramból

Korábban volt szó az ER diagramról, amely szemléletes ábrázolásmódja következtében

hatékonyan támo-gatja a valóság modellezésének folyamatát. Természetes, hogy ER
diagramokat relációs sémákká szeretnénk alakítani, így alapozva meg a valóságot jól modellező
relációs sémák kialakítását. Az átalakítás teljes, ha megmondjuk, hogy az ER diagram elemeit
hogyan kell a relációs adatmodell megengedett adatstruktúráiba transzformálni.

1. Az egyedhalmazokat olyan relációs sémával ábrázoljuk, amely tartalmazza az entitáshalmaz

összes attribútumát. A reláció minden n-ese az entitáshalmaz egyetlen példányát fogja
azonosítani. Ha az entitáshalmazok között olyan is van, amelynek egyes attribútumait egy
entitáshalmaz ISA kapcsolaton keresztül meghatározza, a specializált entitáshalmazhoz
rendelt relációs sémába az általánosabb enti-táshalmaz attribútumait is fel kell venni. (Tehát
egy entitáshalmaz egy eleme jelent egy sort, ahol az oszlopok értékei az egyed attribútumai)
 2. A kapcsolattípusokat olyan relációs sémákká alakítjuk, amely attribútumai között szerepel a
kapcso-latban résztvevő összes entitáshalmaz kulcsa is. Feltételezzük, hogy két
egyedhalmaz valamely kulcsa nem azonos nevű még akkor sem, ha az entitáshalmazok
megegyeznek. Névkonfliktust az attribútu-mokat átnevezéssel kezelhetjük. Az így kapott
relációban minden n-es olyan entitáspéldányokat rendel egymáshoz, amelyek a szóban
forgó kapcsolatban vannak egymással.

A kapcsolatok relációs sémákba alakítására a kapcsolat funkcionalitása és egyéb tulajdonságai

függvé-nyében számos más lehetőség is van, amelyek adott esetben jobbak is lehetnek ezeknél a
módszereknél.

Megjegyzés: Egy több-egy kapcsolat két relációs sémába történő leképezésekor a "több" oldalon
álló egyedhalmaznak megfelelő relációban az idegen kulcsnak megfelelő attribútumok NULL
értéket vehetnek fel. Két relációs sémába szervezéskor az eredeti információ kinyeréséhez eggyel
kevesebb natural join művelet szükséges.
Észrevehető, hogy az ER diagram relációs sémákba szervezésekor az egyedek és a kapcsolatok
formális megkülönböztethetősége elveszik.

26. Anomáliák (módosítási, törlési, beszúrási)

A redundáns relációnak megfelelő kapcsolatban rengeteg kellemetlenség fordulhat elő. Ezeket

hívjuk anomáliáknak.
(Ha egy relációban valamely attribútum értékét a relációban található más attribútum(ok)
értékéből lehet kikövetkeztetni egy ismert szabály szerint, akkor a relációt redundánsak hívjuk)

Módosítási anomália
T.f.h. címeket tárolunk és az egyik lakos címe megváltozik. A változást elvileg annyi helyen kell
átvezetni, ahány helyen az említett lakos címe szerepel. Ha csak egy helyen elmarad, később
különböző helyekről többféle címet is kiolvashatunk. Ez nem csak többletmunka, hanem logikai
ellentmondás is keletkezhet.

Beszúrási anomália
Ennek lényege, hogy nem tudunk tetszőleges adatokat nyilvántartásba venni, ha nem ismert egy
másik adat, amivel a tárolandó adat meghatározott kapcsolatban áll. (Nem szúrható be olyan
elem, amelynek azon mezője kitöltetlen, vagyis NULL, amely a reláció definíciója szerint nem
lehet kitöltetlen.) Illetve, ha már létező egyedhalmazt akarunk felvenni, melynek legalább az
egyik attribútuma időközben megváltozott, úgy nem dönthető el, hogy melyik a helyes.

Törlési anomália
Ha csak egy attribútum értékét szeretnénk törölni, akkor előfordulhat, hogy ez valamiért nem
lehetséges. Ilyenkor ettől az attribútumtól úgy szabadulhatunk meg, ha az egész sort töröljük, de
ilyenkor elveszhetnek szükséges információk is. Ezt megoldhatja a felációk függőségének
felbontása.

A felbontással számos probléma is felmerülhet (eredeti reláció helyreállítása, jó felbontás

készítése, mitől jobb egy felbontás stb.)

27. Adatbázis kényszerek

Azokat a szabályokat értjük ezalatt, amelyek segítségével az adatbázisunk tartalmát olyan módon
lehet jellemezni/korlátozni, hogy az valamely tervezésnek, illetve elképzelt/elvárt feltételnek
megfeleljen.

Leggyakrabban használt kényszerek

 értékfüggő kényszerek (Pl.: 0 < TESTMAGASSÁG < 300),

 értékfüggetlen kényszerek:
– Tartalmazási függőség
(az idegen kulcsok értékeinek halmaza részhalmaza a neki megfeleltethető
kulcsértékek halmazának),
– Funkcionális függőség,
– Többértékű függőség.
28. Funkcionális függőségek

A relációs adatbázisok hatékony működésének egyik központi kérdése a relációkon belüli

redundancia csök-kentése. Hogyan keletkezhet? Két oka lehet:

1. Egy n-est több sorban is fel kell használnunk más n-es(ek) azonosításához,
2. Ha feltételezzük, hogy nincs két ugyan olyan tulajdonságú n-es, akkor minden sorban, ahol
megjelent egy attribútuma, törvényszerűen megjelent egy másik attribútuma is, ami
felesleges.

Utóbbit úgy lehet megfogalmazni, hogy az A attribútum értéke egyértelműen meghatározza B

értékét, tehát minden sorban, amelyben A jelenségnek megfelelő matematikai konstrukciót
funkcionális függőségnek nevezik.

Definíció: Legyen adott az R(A1, A2, ..., An) relációs séma, ahol Ai-k, i = 1, 2, ..., n alap
attribútumok. Legyen X és Y a reláció attribútumainak két részhalmaza: X ⊆ R és Y ⊆ R. Ha
bármely, az R sémára illeszkedő r reláció bármely két t, t0∃r(R) sorára fennáll az, hogy ha t[X] =
t0[X], akkor t[Y ] = t0[Y ], akkor azt mondjuk, hogy az Y attribútumok funkcionálisan függenek az
X attribútumoktól. Vagyis X értékei meghatározzák Y értékeit. Jelölés: X −→ Y .

29. Relációs sémák kulcsai

Az ER modelleknél is használtuk a kulcs fogalmát, illetve a fizikai szervezésnél is, azonban itt
egy újabb értelmében használjuk majd.

Definíció (Relációs séma kulcsa ): X-et pontosan akkor nevezzük kulcsnak az R relációs sémán,
ha

Szuperkulcs, kulcs

Definíció (Szuperkulcs): X-et szuperkulcsnak nevezzük, ha igaz, hogy X −→ R, vagyis akkor,

ha X tartalmaz kulcsot

Ha egy kulcs csak egy attribútumból áll, akkor egyszerű kulcs, egyébként összetett kulcs a neve.

Kulcsok néhány fontos tulajdonsága:

1. A kulcs a relációnak egy és csakis egy elemét (sorát) határozza meg,
2. Egy kulcs attribútumai nem lehetnek NULL-ok.

Elsődleges kulcs

Ha X és Y az R relációs sémának egyaránt kulcsai, miközben , akkor az R relációs

sémának több kulcsa is van.

Ezek közül kiválasztunk egyet, amelyet elsődleges kulcsnak nevezünk, a többi kulcsot pedig
kulcsjelöltnek.

30. Armstrong axiómái a funkcionális függőségekről

Adottak az R sémán az X, Y, Z, attribútumhalmazok.

 Ha X ⊆ Y, akkor Y → X (triviális függőség),

 Ha X → Y és Y → Z, akkor X → Z, (tranzitivitás),

 Ha X → Y, akkor XZ → Y Z (bővíthetőség).

Igazságtétel
Az Armstrong axiómák igazak, alkalmazásukkal csak igaz függőségek állíthatóak elő adott
függéshalmazból.

Teljesség tétel
Az Armstrong axiómák teljesek, azaz belőlük minden igaz függőség levezethető.

Következmények
 Ha X → Y és X → Z, akkor X → Y Z (egyesítési szabály),

 Ha X → Y és W Y → Z, akkor XW → Z (pszeudotranzitivitás),

 Ha X → Y és Z ⊆ Y, akkor X → Z (felbontási szabály).

31. Az első normálforma (1NF)

Relációs sémák normálformái

A normálformák tulajdonképpen megszorítások a relációs séma tulajdonságaira vonatkozóan

annak érdeké-ben, hogy a sémákra illeszkedő relációkkal végzett műveletek során egyes
nemkívánatos jelenségeket elkerülhessünk.

Az első normálforma

Definíció Egy relációs séma 1NF alakú (vagy normalizált), ha csak atomi attribútum-értékek
szerepelnek benne.

Megjegyzés: Az 1NF alak definíciója nem a redundancia csökkentését szolgálja. Egyszerűen

csak kiin-dulási alapot teremt a további normalizálás számára.

32. A második normálforma (2NF)

Definíció (elsődleges és másodlagos attribútum): Egy R relációs séma A ∈ R attribútuma

elsődleges attribútum, ha A eleme a séma valamely K kulcsának. Egyébként másodlagos
attribútum.

Tehát egy relációs séma kulcsai az attribútumokat két diszjunkt halmazba sorolják.

Definíció (2NF): Egy 1NF relációs séma 2NF alakú, ha benne minden másodlagos attribútum a
séma bármely kulcsától teljesen függ. (Másodlagos attribútum nem függ egyetlen kulcs egyetlen
valódi részhal-mazától sem.)

Ennek célja már a redundanciacsökkentés. Ha megsértjük a 2NF definícióját, és lehetővé tesszük

a másodlagos attribútumnak részkulcsától való függést, akkor ebben a másodlagos attribútumban
a redundáns tárolás megvalósulhat.
33. A harmadik normálforma (3NF)

Definíció (3NF, 1. definíció): Egy 1NF R séma 3NF alakú, ha egyetlen másodlagos attribútuma
sem függ tranzitívan (∃Y ⊂ R hogy X → Y, ¬(Y → X), Y → A, tehát X → A) egyetlen kulcstól
sem.

Definíció (3NF, 2. definíció): Egy 1NF R séma 3NF alakú, ha ∀X → A, X ⊆ R, A ∈ R

nemtriviális függőség esetén
 X szuperkulcs, vagy
 A elsődleges attribútum.

34. A Boyce-Codd normálforma (BCNF)

Definíció (BCNF, 1. definíció):

Egy 1NF R séma BCNF alakú, ha ∀A ∈ R attribútum és ∀X ⊆ R kulcs esetén ¬(∃Y ),
hogy X → Y, ¬(Y → X), Y → A és . Tehát egyáltalán nincs tranzitív függőség kulcstól.

Definíció (BCNF, 2. definíció):

Egy 1NF R séma BCNF alakú, ha ∀X → A, X ⊆ R, A ∈ R nemtriviális függőség esetén
X szuperkulcs.

Megjegyzendő, hogy minden olyan séma, amely legfeljebb két attribútumot tartalmaz,
törvényszerűen BCNF.

Tétel: Ahhoz, hogy egy (R, F) sémáról eldöntsük, hogy BCNF-e, elég az F-beli funkcionális
függőségek vizsgálata.
A két definíció közvetlen következménye, hogyha egy séma BNCF alakú, akkor 3NF is.

35. ACID tulajdonságok adatbázis-kezelő rendszerekben

Tranzakció
Egy program egyszeri futása, amelynek vagy minden művelete hatásos, vagy belőle semmi sem.

ACID tulajdonságok
Ahhoz, hogy egy tranzakció egy DBMS konkurens környezetben is értelmezhető legyen,
hagyományosan további tulajdonságokat is, illetve minél többet ezek közül elvárják, hogy
teljesüljenek. Ezek az ún. ACID tulajdonságok.

 Atomicitás (a tranzakció definíciójából),

 Consistency (konzisztencia): csak sikeresen lefutott tranzakcióknak van hatása az adatbázis

tartalmára, ekkor a tranzakciók az adatbázist egy másik konzisztens állapotba viszik át.

 Isolation (izoláció): minden tranzakció úgy fut le, mintha közben más tranzakció nem
futna.

 Durability (tartósság): ha egy tranzakció már sikeresen lefutott, akkor annak a hatása "nem
veszhet el".

36. Lost update, non-repetable read, phantom read, dirty read

Tegyük fel, van T1, T2 tranzakciónk. Ezeket a további négy példában fogjuk használni majd.

Lost update
T.f.h. előbb T1 majd T2 tranzakció is kiolvassa a táblában szereplő A értéket. Majd előbb T1 végzi
el ezen az A = A + 1 műveletet, utána pedig T2. Ezt követően T2 "WRITE"-olja A értékét, végül
ugyan ezt megteszi T1-is. Ezzel T1 felülírta T2 eredményét, így az elveszett.

Általánosítva: több tranzakció ugyanazon adategységen végez módosításokat úgy, hogy egy T1
tranzakció felülírja a másik, T2 tranzakció által végzett művelet eredményét.

Non-repetable read
T.f.h. ∃A, B, C adategység. T1 tranzakció kiolvassa A-t és B-t, majd elvégzi a B = A + B
műveletet, majd ezt visszaírja B-be. Ezt követően T2 elvégzi az A = A + 1 műveletet, és visszaírja
A-ba. Végül T1 kiolvassa A-t és C-t, elvégzi a C = A + C műveletet és visszaírja C-t. Azonban
ekkor már A-nak a megváltozott értékét olvassa ki.

Általánosítva: egy olyan T1 tranzakció különböző eredményeket kap egy adategység többszöri
olvasásakor, mert egy másik, T2 tranzakció időközben módosított azt.

Phantom read
T.f.h. T1 tranzakció végrehajt egy lekérdezést. Ezt követően T2 töröl/beszúr olyan értékeket, mely
a lekér-dezés feltételeinek megfelelnek. Majd T1 újra végrehajtja az előző lekérdezést, azonban
eltérő eredményeket kap.

Általánosítva: T1 tranzakció többször is végrehajtja ugyan azt a lekérdezést, miközben egy másik
tranz-akció olyan rekordokat szúr be vagy töröl, amelyek kielégítik a T1 lekérdezés szelekciós
feltételét. Így a korábbi lekérdezés más rekordhalmazt adhat vissza, mint az utána következő(k).

Dirty read
T.f.h. előbb T1 kiolvassa a táblában szereplő A értéket, majd elvégzi ezen az A = A + 1 műveletet.
Azonban azelőtt, hogy ez sikeresen befejeződött volna, T2 is elvégzi ezt a műveletsort, és végül
lezárja. Ha T1 végül sikertelennek bizonyul, küld egy "ABORT" utasítást.

Általánosítva: egy T2 tranzakció olyan adatot olvas, melyet egy másik T1 tranzakció azelőtt írt az
adat-bázisba, hogy sikeresen befejeződött volna. Ha a T1 tranzakció végül valóban sikertelennek
bizonyul, akkor a piszkos adat az adatbázisból mihamarabb eltávolítandó.

Izolációs elv
Feltételezzük, hogy egy tranzakció elvárt, korrekt eredménye az, amit akkor kapunk, ha a
tranzakció futása közben más tranzakció nem fut.

Megjegyzés: egy ütemezés akkor korrekt, ha sorosítható.

Sorosíthatóság
Egy ütemezés pontosan akkor sorosítható, ha létezik olyan soros ütemezés (soros ekvivalens
ütemezés), amelynek minden hatása a módosított adatokra azonos az adott ütemezésével.

37. Problémák a zárakkal: pattok és éhezés

A patt
Tegyük fel, egy Tm tranzakció azért nem tud továbblépni, mert egy olyan A adategység
felszabadulására vár, amin egy olyan Tn 6= Tm tranzakció tart fenn zárat, ami viszont azért nem
tud továbblépni és zárat felsza-badítani, mert ehhez olyan adategységnek kell felszabadulnia,
amit Tm tart zárva, akkor pattról, holtpontról (deadlock) beszélünk.
Természetesen elképzelhető ez kettőnél több tranzakció esetén is.

Megoldási lehetőségek deadlockra

1. A tranzakciók lockoljanak mindent egyszerre a futás kezdetén, ami nekik szükséges.
Amit nem foglaltak le, azt később ne is próbálják lefoglalni.
2. Ha egy tranzakció túl sokáig várakozik, akkor valószínűleg patthelyzetbe került, ezért
abortálandó.
3. Az adategységekhez valamilyen egyértelmű sorrendet rendelünk, és a zárat csak ennek a
sorrendnek megfelelően lehet kérni.
4. Folyamatosan monitorozzuk a zárak elhelyezését, és ha pattot érzékelünk, akkor a pattot
okozó valamely tranzakciót kilőjük.

Ez utóbbi megoldáshoz szükséges egy várakozási gráf.

Várakozási gráf

Olyan irányított gráf, ahol a gráf csomópontjai a tranzakciók, egy élt pedig akkor rajzolunk a Ti
csomópont-ból a Tj csomópontba, ha Ti tranzakció bármely okból várakoztatja Tj tranzakciót úgy,
hogy az nem tud továbbmenni.
Tétel: Adott időpillanatban kizárólag akkor nincs patt, ha a várakozási gráf körmentes (DAG).
Éhezés
Ha egy tranzakció egy adategység lockolására vár, de közben más tranzakciók mindig lockolják
előtte a kérdéses adategységet, akkor éhezésről beszélünk. Egy lehetőség az éhezés elkerülésére,
ha feljegyezzük a sikertelen zárkéréseket, és ha egy adategység felszabadul, akkor a zárat csak a
zárkérések sorrendjében ítélünk oda (FIFO stratégia).

38. Ütemezések fajtái

Soros, nem soros ütemezés

Ha a tranzakciók egy rendszerben szigorúan egymás után futnak le úgy, hogy egy időben csak
egyetlen tranzakció fut, akkor ez egy soros ütemezés. Egy soros ütemezés mindig
megvalósítható, problémamentes, ha a tranzakciók külön-külön megvalósíthatók, és az
izolációjuk természetes módon teljesül. Minden más esetben nem soros ütemezések.

Nem soros ütemezés azonban lehet sorosítható, vagy nem sorosítható.

Definíció (Sorosítható ütemezés): egy ütemezés pontosan akkor sorosítható, ha létezik olyan
soros ütemezés (soros ekvivalens) amelynek minden hatása a módosított adatokra azonos az
adott ütemezésével.

39. Tranzakció modellek

Definíció (Egyszerű tranzakciós modell): Akkor beszélünk erről, ha:

 csak egyfajta zár létezik,
 egy adatelemen egyidőben csak egyetlen zár lehet.

Adott adatelemen zár elhelyezésének következménye, hogy a LOCK . . . UNLOCK műveletek

között már tranzakció nem férhet az adatelemekhez. Ugyanakkor feltételezzük, hogy a zárat
elhelyező tranzakció az adatelemet írta/olvasta is.

Sorosítási gráf (precedenciagráf)

Olyan irányított gráf, amelynek a csomópontjai a tranzakciók, egy élt pedig akkor rajzolunk a Ti
csomópontból a Tj csomópont felé, ha van olyan A adategység, amelyen egy adott S ütemezésben
a Ti tranzakció zárat helyezett el, majd a zár felszabadítása után a Tj tranzakció helyez el zárat A-
n.

Tétel: egy S ütemezés csak akkor sorosítható, ha a precedenciagráf DAG.

A sorosítási gráf segítségével tehát a sorosíthatóság eldöntése visszavezethető kör keresésére egy
irányított gráfban. Ez minden zárkeresési művelet előtt elvégzendő, így az egyidejűleg futó
tranzakciókés az általuk közösen használt adatelemek számának függvényében az ütemező
működése jelentősen lassulhat.

40. Kétfázisú zárolás (2PL)

Egy tranzakció a kétfázisú zárolás protokollt követi, ha az első zárfelszabadítást megelőzi

mindegyik zárkérés.
Tehát a tranzakció az első fázisban zárakat kér, a másodikban pedig felszabadítja azokat.

Tétel: Ha egy legális ütemezés minden tranzakciója a 2PL protokollt követi, akkor az ütemezés
sorosít-ható.

Zárpont
Az az időpont, amikor a 2PL szerinti tranzakció az utolsó zárját is megkapja.

RLOCK-WLOCK modell
Kétfjata zár létezik

 RLOCK: Ha a T:
RLOCK A érvényes, akkor más tranzakció is olvashatja A-t, de senki sem írhatja.
(megosztható)
 WLOCK: Ha a T:
W LOCK A érvényes, akkor más tranzakció nem férhet hozzá A-hoz. (nem megosztható)

Az UNLOCK művelet után minden zár felszabadul, ami legális ütemezések esetén a tranzakció
végetérte előtt bekövetkezik.
Itt is van lehetőség sorosítási gráffal eldönteni, hogy egy ütemezés sorosíthatóságát.

Megyjegyzés: A hatékonyság amiatt növekedik, mert a READ . . . READ szekvenciák esetén nem
kell élet húzni két tranzakció közé.

Tétel: Egy WLOCK-RLOCK modellbeli S ütemezés sorosítható csakis akkor, ha a sorosítási

gráf DAG.
Tétel: Ha egy legális ütemezés minden tranzakciója a 2PL protokollt követő, WLOCK-RLOCK
modell szerinti tranzakciók vannak, akkor az ütemezés sorosítható.

41. A fa protokoll

Hierarchikus adategységek
Eddig a mechanizmusok függetlenek voltak attól, hogy az adategységek milyen struktúrába
vannak szervez-ve, illetve szervezettek-e egyáltalán. Belátható, hogy ezen információk
felhasználásával tovább növelhető a hatékonyság.

Kihasználva a hierarchikus szerkezetet, lehetőség van arra, hogy egy adategység zárolása esetén
minden alacsonyabban lévő adategységet egyidejűleg zároljunk.

A fa protokoll
Az egyszerű tranzakció modellt követjük és egy csomópont zárolása nem jelenti a gyerekek
zárolását is.

Szabályok
1. egy tranzakció az első LOCK-ot akárhova teheti,
2. további LOCK-ok csak akkor helyezhetők el, ha az adategység szülőjére ugyanaz a
tranzakció már rakott zárat,
3. egyazon tranzakció kétszer ugyanazt az adategységet nem zárolhatja.

Vegyük észre, hogy az UNLOCK-ra nincs megkötés, emiatt a fa protokoll nem feltétlenül
kétfázisú.

Tétel: A fa protokollnak eleget tevő legális ütemezések sorosíthatóak.

42. A figyelmeztető protokoll

Az egyszerű tranzakció modellt követjük, de egy csomópont zárolása a gyerek és az összes

leszármazott zárolását is jelenti (implicit lock).

Zárműveletek

 LOCK A: zárolja A-t és az összes leszármazott csomópontot is. Két különböző tranzakció
nem tarthat fenn egyidejűleg zárat ugyanazon az adategységen.
 WARN A: figyelmeztetést rak A-ra. Ekkor azt más tranzakció nem zárolhatja.
 UNLOCK A: eltávolítja a zárat vagy a figyelmeztetést.

Szabályai ugyan azok, mint az egyszerű modellben, továbbá:

 1. Egy tranzakció első művelete kötelezően LOCK gyökér vagy WARN gyökér.
2. LOCK A vagy WARN A akkor helyezhető el, ha A szülőjén ugyan az a tranzakció már
helyezett el WARN-t.
3. UNLOCK A akkor lehetséges, ha A gyerekein már ugyanaz a tranzakció nem tart fenn
sem LOCK-ot, sem WARN-t.
4. Kétfázisú: az első UNLOCK után nem következhet LOCK vagy WARN.

Tétel: A figyelmezetető protokollt követő legális ütemezések zárkonfliktus-mentesek, és

sorosíthatóak.

43. Tranzakcióhibák kezelése, commit pont

Nem foglalkoztunk azokkal az esetekkel, amikor a tranzakció nem fut le teljesen. Ahhoz, hogy
hatékonyan kezelhessük ezeket, gyűjtsük össze az okokat:

1. A tranzakció félbeszakad,
2. Az ütemező patt miatt kilövi,
3. A sorosítás biztosítása miatt lövi ki,
4. Rendszerhiba lép fel, az adatbázis hibásan működik,
5. A háttértár tartalma (is) megsérül.

Az 1-3 esetben memória- vagy háttértár-struktúra érintetlen a 4-5 hibákkal szemben (ilyenkor a
tartalom is sérül, érdemes a backup).

Első lépésben csak az 1-3. esetekkel foglalkozunk (tranzakcióhiba).

Definíció (konzisztens állapot): Az adatbázisnak olyan állapota, amely csak teljesen lefutott
tranzakciók hatását tükrözi (l. ACID tulajdonságok).

Mivel a tranzakciók idő előtt, ill. irregulárisan is befejeződhetnek, a konzisztencia fenntartása

automati-kusan nem valósul meg. Szükség van olyan módszerre, amely az egyes tranzakcióknak
ezt a tulajdonságát biztosítják. Ezekhez szükséges a készpont.

Definíció (készpont): Az az időpillanat, amikor egy tranzakció futása során már minden
befejeződött, ami a tranzakció 1-3. okok miatti abortját eredményezheti.

Ez a commit nem feltétlenül azonos azzal, hogy minden eredmény véglegesedett.

Piszkos adat
Olyan adat, amit az előtt írt valamely tranzakció az adatbázisba, mielőtt committálták volna.

Ez az adat az adatbázisból mihamarabb eltávolítandó. Előfordulhat, hogy egy másik tranzakció

olvassa a piszkos adatot, és az a tranzakció már sikeres. Ennek ellenére nem tekinthető helyesnek
a kapott eredmény, ez is eltávolítandó. Ez iterálitan is előfordulhat, ekkor lavináról beszélünk.

44. Szigorú 2PL

A tranzakcióhibák kezelésének gyakori módszere. Egy tranzakció ezt a protokollt követi, ha

2PL, illetve
1. nem ír az adatbázisba, amíg a készpontját el nem érte,
2. a zárait csak az adatbázisba írás után engedi el.

Azaz a COMMIT, az adatbázisba írás, zárak elengedése pontosan ebben a sorrendben

következik. Az egyes szabály az adatbázis helyreállításának szüksége ellen, a második a piszkos
adat olvasása ellen szükséges.

Mindez csak akkor igaz, ha nem kell rendszerhibával számolni. Ez ellen más módszerekkel kell
védekezni.
Tétel: A szigorú kétfázisú protokollt követő tranzakciókból álló legális ütemezések sorosíthatók
(kétfázisú) és lavinamentesek (nincs piszkos adat olvasás).

45. Agresszív és konzervatív protokollok

Hogyan befolyásolják a tranzakciók a teljesítményt?

 Számos műveletet igényel a zártáblák kezelése, a zárakra várakozó sorok karbantartása,

pattok érzékelése stb.
 A később abortált tranzakciók által végzett műveletek mind kárbavesznek, csakúgy, mint
az általuk igényelt és fel nem oldott zárak felkutatása és felszabadítása,
 Nem szigorú 2PL esetén az adatbázis helyreállítása, lavinaeffektus felszámolása szintén
csökkenti a teljesítményt.

Agresszív protokoll
(Optimista konkurenciakezelés):
Egy protokoll agresszív, ha megpróbál olyan gyorsan lefutni, amennyire csak lehetséges, nem
törődve azzal, hogy ez esetleg aborthoz is vezethet (keveset foglalkozik a zárakkal).

Konzervatív protokoll
(Pesszimista konkurenciakezelés):
Egy protokoll konzervatív, ha megkísérli elkerülni olyan tranzakciók futtatását, amelyek nem
biztos, hogy eredményesek lesznek.

46. Védekezés rendszerhibák ellen

A rendszerhibák elleni védekezés általános módszere a naplózás. Számos módja lehet, a alább a
leggyakori-abbak.

Definíció (Napló): A napló a mi értelmezésünk szerint az adatbázison végrehajtott változások

története.

Általában az alábbi szerkezetű rekordokat tartalmazza:

 ([ID], begin),
 ([ID], commit),
 ([ID], abort),
 ([ID], [adategység], [új érték], [régi érték]) (ha lehet tudni, hogy undo nem lesz, akkor az új
érték nem kell),

Alapszabály, hogy a naplót azelőtt írjuk, mielőtt a naplózott műveletre sor kerülne (kiv.: abort
művelet naplózása).

47. Hatékonysági kérdések

A helyreállítás képességének igénye miatt a napló stabil tárban (háttértáron, diszken) tárolandó.
Ennek költ-sége a háttértárra írt naplóblokkok számával arányos.
A gyakorlatban a naplóblokkokat valamilyen lapozási stratégiával kezelik. Számos napló oldal
lehet egyidejűleg a memóriában és egy lapmenedzser gondoskodik a háttértárra kiírásról,
meghatározott stratégia és feltételek szerint.
Tipikus, hogy ugyanez igaz az adatbázis blokkokra is.

Ha változtatunk az adatbázisunkon, a változás elveszhet egy rendszerösszeomlás esetén, ha a

naplót vagy a megváltozott adatbázis oldalakat nem írjuk ki a stabil tárba.
Hatékonyabb, ha a naplót írjuk, mert a napló tömörebben tartalmazza a változásokat, mint maguk
az adatbázis oldalak. Ekkor tehát kevesebb blokkműveletet kell végeznünk.
Ugyanakkor szabály, hogy egy tranzakció vége után a napló akkor is kiírandó a háttértárra, ha a
lapozási stratégia ezt még nem követelné meg, hiszen ezáltal ralik a tranzakció tartósan - akár
megismételhetően - végrehajtottá (az ACID-ból a tartósság így teljesül).

Az adatbázis oldalakat lehet a naplótól függetlenül is, egy másik lapozási stratégia szerint
cserélni.

48. A redo protokoll

Nevét onnan kapta, hogy olyan tranzakciókezclést valósít meg, amely rendszerhiba (és
tranzakcióidba) után szükségtelenné teszi az undo műveletet, csak redo kell.

Két része: redo naplózás, redo helyreállítás.

A redo naplózás
A szigorú 2PL finomítása. Lépései:
1. (T, begin) naplóba
2. (T, A t (A új értéke)) naplóba, ha T változtatja A adategység értékét,
3. (T, commit) naplóba, ha T elérte a commit pontját,
4. napló stabil tárba írása, ha még nem történt meg (végleges, ami eddig eljutott),
5. Az értékének tényleges beírása,
6. piszkos DB blokkok diszkre írása,
7. zárak elengedése.

A redo helyreállítás

Az adatbázist egy konzisztens állapotba viszi át a helyreállítás végére.

Lépései:
 Zárak felszabadítása,
 Napló vizsgálata visszafelé (feljegyezzük, hogy mire találtunk (T, commit) eseményt),
 Addig megyünk vissza, amíg nem találunk egy konzisztens állapotot,
 A 2. pontnak megfelelő tranzakciókra vonatkozó bejegyzések segítségével az adatbázisban
található értékeket felülírjuk az újakkal.

A redo helyreállítás eredményeként a 2. pontnak megfelelő tranzakciók hatása megmarad, a

többié elvész, és az adatbázis egy újabb konzisztens állapotba kerül.

49. Ellenőrzési pontok

A redo helyreállításnál könnyen előfordulhat, hogy igen régi időpontra kell a naplóban visszafelé
menni ahhoz, hogy alkalmas időpontot találjunk a helyreállítás megkezdésére. Ezen a problémán
segítenek az ellenőrzési pontok, amikor kikényszerítik az adatbázisnak egy konzisztens állapotát:

1. Ideiglenesen megtiltjuk új tranzakciók indítását, a futóknak megvárjuk a végét,

2. megkeressük azon memóriablokkokat, amelyek módosultak, de nem kerültek háttértárra,
3. ezeket visszaírjuk a háttértárra,
4. ellenőrzési pont (checkpoint) tényét naplózzuk,
5. a naplót kiírjuk a háttértárra.

Előnyök
 redo helyreállításnál csak a legutóbbi ellenőrzési pontig kell a naplóban visszamenni,
  emiatt a napló korábbi részei eldobhatók,
 csökkenti a lavinák számát.

Hátrány
Csökkenti a tranzakciós teljesítményt.

Ütemezés
 Adott idő eltelte után,
 adott számú tranzakció után,
 a kettő kombináltja.

Mivel az ellenőrzési pontokra elsősorban a helyreállításkor van szükség, ez pedig ritka

eseménynek számít, ezért ellenőrzési pontokat is viszonylag ritkán iktatnak be.
Következmény: a helyreállítás tovább tart.

50. Időbélyeges tranzakciókezelés R/W modellben

A tranzakciók sorosíthatósága biztosításának egy másik módja. Akkor praktikus elsősorban, ha a

tranzakciók között kevés a potenciális sorosítási konfliktus.

Az időbélyeges tranzakciókezelés során az adategységekhez egy (vagy néhány) járulékos adatot

rendelünk hozzá (időbélyeg). Segítségével eldönthető, hogy egy tranzakció adott adategységre
vonatkozó kérése sérti-e a sorosíthatóságot. Ha igen, akkor a tranzakciót abortálni kell, így ez
alapvetően egy agresszív protokoll.

Definíció (időbélyeg): Olyan érték, amelyet minden tranzakcióhoz szigorú egyediséget biztosítva
rendelünk hozzá, és amely arányos a tranzakció kezdőidejével. Jele: t(Tranzakció).

Figyelembe véve, hogy

1. az időbélyegek a tranzakcióknak egy egyértelmű sorrendjét határozzák meg, illetve,

2. képzelhetjük úgy, mintha a tranzakciók a kezdőidejükben (csaknem) zérus idő alatt
futnának le, A kezdőidők növekvő sorrendjébe állítva a tranzakciókat ez lehet egy soros
ekvivalens ütemezés.

Működés
1. Megvizsgálja minden írás-olvasás előtt a hivatkozott adategység időbélyegét,
2. ha ez a sorosítási szabályokkal összhangban van (ld. később), akkor az adategység
időbélyegét felülírja a műveletet végrehajtó tranzakció időbélyegével,
3. ha nincs összhangban, akkor pedig abortálja a tranzakciót.

Időbélyeges tranzakciókezelés R/W modellben

Definíció (olvasási és írási idő):

 R(A):
az adategység olvasási ideje, annak a tranzakciónak az időbélyege, amely legutóbb olvasta
az A adategységet.
 W (A):
az adategység olvasási ideje, annak a tranzakciónak az időbélyege, amely legutóbb írta az A
adategységet.

Összefoglalva

1. abort T, ha T olvasni akar, és t(T ) < W (A), vagy

T írni akart és t(T ) < R(A), vagy t(T ) < R(A).
 2. a READ művelet elvégzendő, ha t(T ) ≥ W (A)

3. WRITE elvégzendő, ha t(T ) ≥ R(A) és t(T ) ≥ W (A)

51. Az időbélyeges R/W modell és a 2PL összehasonlítása

Elképzelhető, hogy egy ütemezés sorosítható

 időbélyegesen, de kétfázisú zárakkal nem

 időbélyegcscn is és zárakkal is
(pl. minden olyan ütemezés, amelyben a tranzakciók nem használnak közös adatokat),
 kétfázisú zárakkal, de időbélyegesen nem,
 időbélyegesen sem és zárakkal sem.

Tanulság: sem a zárakkal, sem az időbélyegekkel való sorosítás nem jobb egyértelműen a
másiknál.

52. Tranzakcióhibák és az időbélyegek

Elképzelhető, hogy T2 olvas T1 által előállított értéket, majd később T1 abortál bármely ok miatt.
Ez a piszkos adat olvasásának esete, amikor lavinaveszéllyel kell számolni.

Megoldási ötletek
1. elfogadjuk a lavinákat, hiszen az időbélyeges tranzakciókezelést tipikusan olyan
környezetben használ-juk, ahol kevés az abort, tehát a lavina még kevesebb, vagy
2. megakadályozzuk a piszkos adat olvasását pl. azzal, hogy nem írunk az adatbázisba, amíg a
tranzakció el nem érte a készpontját.

Lépések
1. Módosítások csak munkaterületen elvégezve,
2. Tranzakció eléri a készpontját,
3. írások véglegesítése az adatbázison.

Az írásokkal azonban baj van. Az időbélyeg ellenőrzése a készpont előtt kell, hogy történjen,
hiszen utána már a tranzakció akkor sem abortálhat, ha az időbélyegek vizsgálatából ez
következne, így azután egy írandó adatelem időbélyegének ellenőrzése és tényleges írása között
jelentős idő telhet el, ami problémát okozhat. Pl.: Elvégeztünk egy írást A-n, ennek megfelelően
beállítottuk az írási időbélyegét, de A megváltozott értékét más tranzakciók mégsem látják, mert
csak munkaterületen történt az írás.

Megoldás
A tényleges írásig A-ra zárat kell tenni. Ha T közben abortál, akkor a zárat el kell engedni és
IV(.A) értékét helyreállítani.

További alternatívák
 akkor ellenőrizzük az időbélyegeket, amikor az írási/olvasási igény megjelenik,
 közvetlenül a készpont előtt ellenőrizzük az időbélyegeket.
Az első esetben (pesszimista stratégia) a zárak hosszabbak, de az abort valószínűsége kisebb,
míg a másik esetben (optimista stratégia) éppen fordítva van.
53. Verziókezelés időbélyegek mellett (MVCC)

Feltételezés: minden adatelem írásakor a régi értéket is megőrizzük.

Kézenfekvő megoldás, ha idősor jellegű adatokat kívánunk tárolni (betegek adatai, tőzsdei
árfolyamváltozások, szoftver projektek verziói stb.).
Fizikai megoldás: pl. egyszer írható optikai diszkek.

Előny
Segít az időbélyeges tranzakciókezelés mellett az abortok számát is csökkenteni, ha a verzió
keletkezési idejét (értsd: időbélyegét) is tároljuk.

Hátrány
Ha a T tranzakció írni akarja A-t, akkor abort T kell t(T ) < R(A) esetén.
Verziók esetén csak akkor kell abort, ha van egy Ai változat, amelyre W (Ai) < t(T ) < R(Ai)
(hiszen annak a tranzakciónak, amely Ai-t olvasta, valójában azt az értéket kellett volna olvasnia,
amit T hozna létre).

Összefoglalva
 alapvetően konzervatív módszer (pesszimista stratégia),
 hatékonyan támogatja a sok/hosszú olvasási tranzakciókat,
 több háttértárat igényel,
 bonyolultabb adat visszakeresési algoritmus,
 a DBMS-nek kell felderítenie, ha egy verzió a futó tranzakciók számára már közömbös,
így törölhető