Bazsalanszky/adatb
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
adatb/db.org

18 KiB
Raw Blame History

Adatbázisok tételek

Adat, információ, tudás. Metaadatok. Strukturált, szemistrukturált és nem strukturált adatok

Adat

A körülöttünk lévő világ egy része,ami értelmezhető ugyan,de nem értelmezzük.

Információ

Az adathoz redelünk egy értelmet,egy jelentést.

Tudás

Kontextusba helyezett információ.

Metaadat

Adat, az adatról. Segéd adatok.

Szerkezeti(Strukturális) metaadat

pl. Hol található egy file fizikailag

Szemantikus(Üzleti információs) metaadat

Hogyan kell értelmezni egy adatot.

Üzemeltetési metaadat

Mi történt az adatokkal. pl. mikor lett módosítva.

Struktúrált adat

Olyan adat,amire struktúrális $\text{metaadat} << \text{adat}$ .

Semi-struktúrált adat

Olyan adat,amire struktúrális $\text{metaadat} \approx \text{adat}$ .

Nem struktúrált adat

Olyan adat,amihez egyáltalán nem értelmezünk.

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

Adatbázis kezelő fogalma

Az adatbáziskezelő, olyan hardware- softwarerendszer, amelyet 3 fő tulajdonság jellemez:

  • nagy adatmennyiség
  • gazdag struktúra
  • hosszú életciklus

Feladatai

Adatok sémájának meghatározása

A felhasználónak meg kell tudnia határoznia az adatbázis sémáját,azaz az adatok logikai rendjét. Ezt tipikusan egy adatdeviníciós nyelven teheti meg(data definition language,DDL). Ezeket az ún. technikai metaadatokat egy speciális védett helyen kerülnek eltárolásra

Adatok tárolása

A séma meghatározása után felvehetünk adatadokat az adatbázisba.

Hozzáférés az adatokhoz

A felhasználónak lehetősége lehet az egyes adatok megkeresésére, módosítására, valamint törléásére. Ezt tipikusan egy adatlekérdező és -manipulációs nyelven teheti meg(data manipulation language,DML).

Adatbázis-menedzser

A DBMS központi része az adatbázis-menedzser (database manager), amely a lefordított séma alapján kezeli a felhasználói lekérdezéseket

Adatvédelem(privacy)

Nem minden felhasználó férhet hozzá minden adathoz. A kölönböző felhasználókhoz külön jogokat rendelünk. Lehet olyan felhasználó,aki csak a olvasni tudja a tárolt adatokat, lehet olyan felhasználó, aki olvasni és módosítani is tudja az adatokat,de lehet olyan is,aki egyáltalán nem fér hozzá az adatokhoz.

Adatbiztonság(security)

Bizonyos adatok, igen nyagy értéket képviselhetnek, és ezért semmi képpen nem toleráljuk elvesztésüket,vagy részleges elvesztésüket. Ezért különböző eszközöket alkalmazunk az adatok biztonsága érdekében. Pl. naplózás,rednszeres mentés,kettőzött állományok elosztott működés, stb.

Integritás

Fontos,hogy az adabázisban tárolt adatok helyesek legyenek, ne legyenek ellentmondások. Ezért ezeket ellenőrizni kell.

Formai ellenőrzés

Ez viszonyla egyszerú elvégezni. Csak meg kell nézni hogy az adat megfelel-e egy elvárt formának. Pl. egy keresztnév nem tartalmaz számokat vagy testmagasság nem lehet három és fél méter (domain sértés).

Referenciális integritás

Számos esetben kell annak a feltételnek teljesülnie, hogy az adatbázisból az egyik helyről kiolvasott adatelemnek meg kell egyeznie valamely más helyről kiolvasott másik adatelemmel

Strukturális integritás

Ellenőriznünk kell, hogy nem sérült-e meg valamely feltételezés, amelyre az adatbázis szerkezetének megtervezésekor építettünk. Gyakori hiba, az egyértelműség megszűnése(pl több feleség). Ide tartoznak az adatbáziskényszerek ellenőrzése is.

Szinkronitás

Fontos,hogy a különböző felhasználók által, egyidőben végzett műveleteknek ne legyenek nemkívánatos mellékhatásai. Ezt tanzakciókezeléssel módszereivel oldjuk meg. pl. zárak.

Felépítése

A felépítésének leírásához egy rétegmodellt alkalmazunk. A legegyszerűbb adatbázis kezelő modelle 3 rétegből áll:

Fizikai adatbázis

Itt valósul meg az adatok,valamint az adat struktúrák fizikai tárolása.

Fogalmi(logikai) adatbázis

Ez a való világ egy részének leképezése,egy sajátos modell,ahogyan az adabázis tükrözi a valóság egy részét.

Nézetek

Ez az amit a felhasználók látnak. Az adatbázisban szereplő adatok és metaadatok egyes megjelenítései.A nézetekhez tartozó sémákat gyakran külső sémának (external schema) is nevezik.

Felhasználói

Képzetlen felhasználó (naive user)

A felhasználók legszélesebb rétege, akik csak bizonyos betanult ismeretekkel rendelkeznek a rendszerről.

Alkalmazás programozó

Az a szakember, aki a (képzetlen) felhasználó által használt programot készíti és karbantartja. Ez olyan feladat, amely programozót igényel, de megoldásához nem feltétlenül szükséges, hogy az illető belelásson az adatbázis belső szerkezetébe is.

Adatbázis adminisztrátor

Hagyományosan így nevezzük azt a személyt, aki az adatbázis felett gyakorlatilag korlátlan jogokkal bír. Kizárólag ő végezhet egyes feladatokat,mint pl:

Generélás

Adatbázisok létrehozása, szerkezetének kialalítása.

Jogosultságok karbantartása

A hozzáférések jogának naprakészen tartása, módosítása.

Szerkezetmódosítás

Az adatbázis eredeti szerkezetének

Mentés-visszaállítás.

Célszerű lehet adatbiztonsági okokból időnként vagy bizonyos időközönként másolatot készíteni az adatbázisról. Ha az adatbázis megsérül, ez a másolat teszi lehetővé a visszaállítást a mentés időpontjának állapotába.

DBMS tervező/programozó (DBMS designer/programmer)

Tudja, hogyan kell DBMS-t készíteni, ami különösen specializált tudást igényel.

Heap szervezés

Általános jellemzői

Jelentése halmaz, kupac. Ez a legegyszerűbb tárolási megoldás. Legalább annyi blokkot használ fel,amennyit a rekordok száma és mérete megkövetel,de nem rendelünk hozzás semmilyen segédstruktúrát.

Műveletek heap szervezésben

Keresés

Mivel nem rendelkezik semmilyen segéd struktúrával ezért lineáris keresést alkalmazunk. Ez általánosan $\frac{\text{blokkok száma}+1}{2}$ blokkműveletet igényel. (Mivel egy keresés nem végezhető el 0 blokkműveletből,ezért kell a $+1$ )

Törlés

Először meg kell keresni a törlendő rekodot,majd a felécben jelezni,hogy a rekord felszabadult. Ezek után a megváltoztatott blokkot vissza kell írni.

Következményei: Az előbb felvázolt metódus egy gyakori következménye a szétszódódott lemezterület. Erre megoldást jelenthet a lemezterületek összegyűjtése és egyesítése.

Beszúrás

Először mindenképpen ellenőrizni kell a rekod egyedidégét,majd szabad tárolóhelyet kell találni. Ha nincs, állománybővítés szükséges(adminisztrátor feladata).

Módosítás

Először meg kell keresnünk a blokkot,amiben a keresett rekord található. Majd a rekord módosítása után a blokkot vissza kell írni a háttértárra.

Hash-állományok

A hash-címzés során a kesesés kulcsának bitmintájából csonkolás segítségével is kinyerhető egy cím, amely alapján a keresett rekord megtalálható.

A legegyserűbb változatában egy ún. hash függvényt használunk,ami egy egyértelmű címet ad.Ezzel ugyan sokkal gyorsabb a keresés,mint hagyományos módszerekkel,de a háttértárakat ebben a formában igen rosszul használja ki.

Egy gyakori megoldás erre a vödrös hash-elés,ahol az egyes blokkok vödrökbe vannak elhelyezve. Keresés során a hash függvénnyel megkaphatjuk,hogy a keresett rekord melyik vödörben található.

Műveletek vödrös hash szervezésben

Keresés

Először lefutattjuk a kulcson a hash függvényt. Ez alapján tudjuk,hogy melyik vödörben található a keresett rekord. Ezek után a vödörben lényegében lineáris keresést alkalmazunk.

Beszúrás

Előszür a hash függvény alapján megkeressük,hogy melyik vödörbe tartozik a rekord,majd megkeressük a rekord kulcsát a vödörben. Ha megtalátuk akkor, hibaüzenetet küldünk. Ha nem találtuk meg,akkor az első szabad vagy törölt helyre beírjuk. Végül a módosított blokkot visszaírjuk a háttértárra.

Törlés

Megkeresés utá a felécben jelezni,hogy a rekord felszabadult. Ezek után a megváltoztatott blokkot vissza kell írni.

Módosítás

Ha nem a kulcs mezőt módosítjuk,akkor az a módosítás a szokott módon történik. Ha kulcs mező is módosul akkor a törlés és a beszurás műveletet kell alkalmazni egymás után.

Indexelt állományok

Az indexelt szervezés alapgondolata: a keresés kulcsát egy ún. indexállományban (kb. katalógus) megismételjük, és a kulcshoz egy mutatót rendelünk, amely a tárolt adatrekord helyére mutat.

Az indexállományt mindig rendezve tartjuk. Ha a kulcs numerikus, akkor a rendezés triviális. Ha szöveges, akkor lexikografikus rendezést alkalmazhatunk. Összetett kulcs (composite key) esetén, vagyis amikor a kulcs több mezőből áll, definiálnunk kell a rendezés módját. Általában nincs akadálya, hogy több indexállományt is létrehozzunk ugyanazon adatállományhoz,különböző (vagy különbözően rendezett) kulcsmezőkkel.Ezért ebben a kontextusban a (keresési) kulcs lesz minden, ami szerint egy indexet felépítünk, illetve a keresést végezzük.

Két alapvetően különböző megvalósítás lehetséges:

  1. indexrekordot rendelünk minden egyes adatrekordhoz (sűrű index)
  2. indexrekordot rendelünk adatrekordok egy csoportjához, tipikusan az egy

blokkban levőkhöz. (ritka index)

Ritka index, B*-fák

Ritka index

Ebben az esetben indexrekordot redot az adatrekordok egy csoportjához rendeljül. Ez hasonlít a szótárban található első és utolsó szó megjelölése az egyes oldalak tetején.

Keresés

Keresés során először az index állományon bináris keresést alkalmazunk a keresett kulcsra. Ha megtaláljuk, akkor megkapjuk,hogy a keresett rekord melyik blokkban található. Ezek után a blokkon belül lineáris keresést alkalmazunk (vagy ha rendezett akkor bináris keresést).

Beszúrás

Először meg kell keressük azt a blokkot, amelyben a rekodnak lennie kellene, ha az állományban lenne. Ha ebben a blokkban van elég hely, akkor a rekordot beírjuk a blokkba. Ha nincs , akkor helyet kell csinálnuk neki. Erre egy lehetőség lehet az, ha létrehozunk egy új blokkot és a korbábban megtalát blokk rekorjait megfelezzük az új blokkal. Ez után frissítenünk kell az index struktúrát is az blokkokban található kulcsoknak megfelelően.

Törlés

Először megkeressük azt a blokkot,amelyik a rekordot tartalmazza. Ha ebben a blokkban nem a legkisebb kulcsot akarjuk törölni,akkor ezt egyszerűen elvégezhetjük, a keletkező lyukat pedig mozgatással megszüntethetjük. Ha a legkisebb kulcsot töröltük a blokkban akkor az indexállományt is firssíteni kell.

Módosítás

A módosítás egyszerű, ha nem érint kulcsot. Ekkor meg kell keresni a szóban forgó rekordot, elvégezni a módosítást, majd az érintett adatblokkot visszaírni a háttértárra. Ha a módosítás kulcsmezőt is érint, akkor egy törlést követő beszúrás valósíthatja meg egy rekord módosítását.

B*-fák

Az alapgondolat az, hogy az indexállományban való keresést meggyorsíthatjuk, ha az indexállományhoz is (ritka) indexet készítünk hasonló szabályok szerint.Az eljárás mindaddig folytatható, ameddig az utolsó index egyetlen blokkba be nem fér.A legalsó szint mutatói az adatállomány egy-egy blokkjára mutatnak, a fölötte levő szintek mutatói pedig az indexállomány egy-egy részfáját azonosítják.

Keresés

Hasonló az egyszintű ritka indexek esetéhez,azomban ebben az esetben több lépésben kell elvégeznünk a keresést:

A fa (azaz az indexállomány) gyökeréből indulunk. Ebben a blokkban megkeressük azt a rekordot.amely kulcsa a legnagyobb azok közül,amelyek kisebbek még a keresett kulcsnál(vagy egyenlő). Ez a rekord a mutatója a fa egy alsóbb szintjére vezet. Ha az előző lépéseket addig ismételjük, amíg meg nem találjuk a keresett rekordot.

Beszúrás

Az eljárás nagy mértékben megyegyezik a ritka indexbe beszúrással, viszont ügyelni kell arra is, hogy a fa kiegyenlítettsége ne károsodjon. Ez azt is igényelhetni, hogy az index állomány minden szintjén néhány blokk megváltozzon.

Törlés

Megkeressük a kívánt adatot és töröljük. Az adatblokkokat lehetőség szerint összevonjuk. Összevonáskor, vagy ha egy adatblokk utolsó rekordját is töröltük, a megszűnt blokkhoz tartozó kulcsot is ki kell venni az indexállomány érintett részfájából. Ehhez adott esetben a fa minden szintjén szükség lehet néhány blokk módosítására.

Módósítás

Megegyezik a ritka index beli módosítás elvével.

Sűrű indexek, előnyök és hátrányok

Minden adatrekordhoz tartozik egy index rekord. Ez általában még mindig a rekodot tartalamzó blokkra mutat,de elképzelhető az is, hogy közvetlenül az adatrekordra mutat. Emiatt az adatokat nem kell rendezni. Ez nagy előny a ritka indexel szemben, hiszen ez nagyban megnehezítette a beillesztést.

Fontos megjegyezni azomban, hogy a sűrű indexelés önmagában nem állományszervezési módszer. Hash vagy ritka indexre építhet.

A sűrű indexnek hátrányai is vannak. Ezek közé tartozik a nagyobb hely igény (a plusz indexelés miatt), az egyel több indirekció a rekord eléréséhez és több adminisztrációval is jár.

Viszont támogatja a több kulcs szerinti keresést és az adatállomány rekordjai szabadokká tehetők, ha minden további rekordhivatkozást a sűrű indexen keresztül történik.

Műveletek sűrűindexel

Keresés

Az indexállományban megkeressük a kulcsot, pl. bináris kereséssel. A hozzá tartozó mutatóval elérhetjük a tárolt rekordot.

Törkés

Először megkeressük a törlendő rekordot. A hozzátartozó törölt bitet szabadra állítjuk,majd a kulcsot kivesszük az indexállományból, és az indexállományt időnként tömörítjük.

Beszúrás

Keresünk egy szabad helyet a tárolandó rekordnak. Ha nem találunk akkor az állomány végére vesszük föl. A kulcsot és a tárolásm helyére hivetkozó mutatót a kulcs szerint berendezzük az indexállományba.

Módosítás

Sűrű indexelés esetén a módosítás viszonylag egyszerű: megkeressük a módosítandó rekordot tartalmazó adatblokkot, majd a módosított tartalommal visszaírjuk a háttértárra. Ha a módosítás kulcsmezőt is érintett, akkor az indexállományt újrarendezzük.

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

Változó hosszú ságú rekordok oka

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

Megoldások

Általános megoldás

Egy rekord változó hosszúságú részeit a rekord mezőlistájának a végén helyezzük el. Így a rekord eleje fix hosszúságú marad.

Megoldás változó hosszúságú mezőre

Gyakrori megoldás az,hogy a mező helyére egy fix hosszúságú mutatót rakunk,ahol a mező tényleges tartalma van. Így egy állomány csak egy féle rekordot tartalmaz.

Megoldás ismétlődő mezőkre

Erre több megoldás is létezik:

  • A maximális számú ismétlődésnek elegendő helyet foglalunk le minden rekordnak
  • Mutatók használata

Részleges információ alapján történő keresés

Gyakran megesik, hogy egy rekord több mezéjét is ismerjük és meg akarjuk keresni azokat a rekordokat, amelyek ugyanezen értékeket tárolják. A továbbiakban úgy vesszük, hogy egyik ismert mező sem kulcs.

Index felépítése

Egy lehetőség lehet több (esetleg minden) mezőre egy index felépítése. Ezek után minden megadott értékre alapján előállíthatunk rekord halmazokat, majd ezek metszetét képezve megkapjuk a kívánt eredményt. Ez nem túl praktikus.

Particionált(feldarabolt) hash-függvény

Veszünk egy hash függvényt, amely

\begin{align} h(m_1,m_2,\ldots,m_k)=h_1(m_1)*h_2(m_2)*\ldots*h_k(m_k) \end{align}

alakú, ahol az $m_i\text{-k}$ a rekord összes $k$ darab, releváns mezőjének az értékeit jelentik, $h_i$ az $i\text{-edik}$ mezőre alkalamazott hash függvény komponens, a $*$ pedig a konkatonáció (összefűzés) jele.

Az ismert mezők értékei alapján meghatározhatjuk az $N$ hosszúságú bitmintának az ismert darabjait. Mindenazon vödröket kell megnézni amelyeknek a sorszáma illeszkedik a kapott bitmintára.

Több kulcs szerinti keresés támogatása

Fontos, hogy egy adatbáziskezelő ne csak elsődleges kulcs szerint tudjon keresni, hanem egyéb mezők alapján is. Ezeket a mezőket keresési kulcsoknak nevezzük.

Indexelt megoldás

Invertált állomány fogalma

Azt az indexállományt, amely nem kulcsmezőrea tartalmaz indexeket, invertált állománynak nevezzük.

Invertált állomány mutatói

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

  1. <<elso>>Fizikai mutatók, amelyek pl. mutathatnak

    1. <<elso.a>>közvetlenül az adatállomány megfelelő blokkja (esetleg rekordja)
    2. <<elso.b>>az adatállomány elsődleges kulcsa szerinti (sűrű) indexállomány megfelelő rekorjára
  2. <<masodik>> Logikai mutatók, amelyek az adatállomány valamely kulcsának értékét tartalmazzák

Az /Bazsalanszky/adatb/src/commit/4c266eacf12f67174fedd6b7e347532aecdbae62/elso.a esetben az adatállomány rekordjai kötöttek és ráadásul csak egyetlen inverált állomány esetén használható.

Az /Bazsalanszky/adatb/src/commit/4c266eacf12f67174fedd6b7e347532aecdbae62/elso.b esetben egyel több indirekción keresztül elrejtjük a keresett rekordot, de az adatrekord megváltoztatásakor csak az érintett mezőhöz (vagy mezőkhöz) tartozó invertált állományt kell frissíteni.

A /Bazsalanszky/adatb/src/commit/4c266eacf12f67174fedd6b7e347532aecdbae62/masodik. lehetőségben az adatállomány rekordjai szabadok lehetnek, viszont nem ismerjük a keresett rekord címét.