Relációs adatbázis

1. A RELÁCIÓS ADATBÁZIS BELSŐ SZERKEZETE

A reláció (a tábla) voltaképpen egy adatok közötti struktúra. A szerkezet "mélyebb" elemzése az adatbázisban szereplő adatok közötti fontos kapcsotokra, összefüggésekre mutathat rá. Kiderülhet például, hogy az attribútumok nem mind "egyenlőek" az adatbázis szempontjából; bizonyos attribútumok (vagy ezek egy csoportja együtt) kitüntetett szerepet kapnak. Előfordulhat, hogy az attribútumok között valamilyen kapcsolat van, például, ha attribútum valamilyen két sorban megegyezik, akkor egy másik attribútum is ezt teszi.

1.1 A funkcionális függőség - Adatok közötti funkcionális kapcsolat

Ha egy relációnak egy P-vel jelölt attribútuma olyan, hogy minden egymástól különböző értékéhez a reláció Q attribútúmából különböző értékek tartoznak, akkor azt mondjuk, hogy P funcionálisan meghatározza Q -t, azaz Q funkcionálisan függ P-től.
Adatok között akkor áll fenn funkcionális kapcsolat, ha egy vagy több adat konkrét értékéből más adatok egyértelműen következnek. Például a személyi szám és a név között funkcionális kapcsolat áll fenn, mivel minden embernek különböző személyi száma van. Ezt a SZEMÉLYI_SZÁM -> NÉV kifejezéssel jelöljük.
A funkcionális függőség bal oldalát a függőség meghatározójának nevezzük. A jobb oldalon levő egy, csak egy értéket határoz meg a funkcionális függőség.
Nem áll fenn funkcionális függőség akkor, ha a meghatározó egy értékét több attribútum értékkel hozhatjuk kapcsolatba. Például a NÉV -> SZÜLETÉSI_ÉV állítás nem igaz, mert több személynek lehet azonos neve, akik különböző időpontokban születtek.
Az adatok közötti funkcionális függőségek az adatok természetéből következnek, nekünk csak fel kell ismerni ezeket a törvényszerűségeket. A tervezés során nagyon fontos, hogy ezeket pontosan felismerjük, és figyelembe vegyük.
A funkcionális függőség jobb oldalán több attributum is állhat. Például az AUTÓ_RENDSZÁM -> TÍPUS, TULAJDONOS funkcionális függőség azt fejezi ki, hogy az autó rendszámából következik a típusa és a tulajdonos neve, mivel minden autónak különböző a rendszáma, minden autónak egy tulajdonosa és típusa van.
Az is előfordulhat, hogy két attributum kölcsönösen függ egymástól. Ez a helyzet például a házastársak esetén
FÉRJ_SZEM_SZÁMA -> FELESÉG_SZEM_SZÁMA
FELESÉG_SZEM_SZÁMA <- FÉRJ_SZEM_SZÁMA.
Mindkét funkcionális kapcsolat igaz és ezt a FÉRJ_SZEM_SZÁMA <-> FELESÉG_SZEM_SZÁMA jelöléssel fejezzük ki. Természetesen a fenti összefüggés a többnejűség esetén nem teljesül.
A funkcionális függőség bal oldalán több attributum is megjelenhet, melyek együttesen határozzák meg a jobb oldalon szereplő attributum értékét. Például hőmérsékletet mérünk különböző helyeken és időben úgy, hogy a helyszínek között azonosak is lehetnek. Ebben az esetben a következő funkcionális függőség áll fenn az attributumok között: HELY, IDŐPONT -> HŐMÉRSÉKLET.

1.1.1 Teljes funkcionális függőség

Definició: Ha P-től függ Q attribútum, de P-nek semmilyen részhalmazától nem függ funkcionálisan. (pl P egyszerű adat!)
A funkcionális függőségek speciális esete a teljes funkcionális függőség. Erről akkor beszélhetünk, ha a meghatározó oldalon nincsen felesleges attributum. Például a RENDSZÁM, TÍPUS -> SZIN funkcionális függőség nem teljes funkcionális függőség, mivel a rendszám már egyértelműen meghatározza a kocsi szinét, ehhez nincs szükség a típusra is.
A funkcionális függőség bevezetése után a relációk egy másik, matematikai jelölésekre épülő leírását is bemutatjuk.

Általános formája:
reláció_név=({attributumok},{funkcionális függőségek listája})
Például:
SZEMÉLYEK=({SZEMÉLYI_SZÁM, NÉV, MUNKAHELY}, {SZEMÉLYI_SZÁM -> NÉV,
SZEMÉLYI_SZÁM -> MUNKAHELY})
írható le a funkcionális függőségekkel együtt, feltételezve, hogy mindenkinek csak egy munkahelye van.

1.1.2 Adatok közötti többértékű függőség

Az adatok között fennálló kapcsolatok közül nem mindegyike fejezhető ki a funkcionális függőség segítségével. Például minden embernek lehet több szakmája, illetve ugyanazzal a szakmával több ember is rendelkezhet. Ebben az esetben egyik irányban sincs egyértelmű függőség. Ez egy többértékű függőség, az egyik attributumhoz egy másik attributum csoportja, halmaza kapcsolódik. A többértékű függőség ábrázolására a dupla nyilat használjuk. SZEMÉLYI_SZÁM ->> SZAKMA. A funkcionális függőséghez hasonlóan, többértékű függőség esetén is előfordulhat, hogy egy attributum értékéből egynél több további attributum értéke következik. Az előző példát bővítve: SZEMÉLYI_SZÁM ->> SZAKMA, OKLEVÉL_KELTE
A funkcionális és a többértékű függőség között kapcsolat van. Nagyon gyakran ugyanazt a függőségi kapcsolatot kifejezhetjük funkcionális és többértékű függőséggel is. Ennek bemutatására nézzük meg a következő példát.
Egy üzemben különböző termékeket gyártanak, melyek mindegyike többfajta alkatrészből tevődik össze. Szeretnénk nyilvántartani termékenként a felhasznált alkatrészek mennyiségét. Ezt leírhatjuk funkcionális függőség segítségével TERMÉK_AZONOSÍTÓ,ALKATRÉSZ_AZONOSÍTÓ -> MENNYISÉG, mely azt fejezi ki, hogy egy termékbe adott mennyiségű alkatrészt építettek be. Másik oldalról többértékű függőséggel is kifejezhetjük az adatok kapcsolatát. TERMÉK_AZONOSÍTÓ ->> ALKATRÉSZ_AZONOSÍTÓ, MENNYISÉG. Ez azt fejezi ki, hogy minden termékbe az alkatrészek egy csoportját és azoknak bizonyos mennyiségét építették be.
A funkcionális függőségeket mindig előnyben kell részesíteni a többértékű függőséggel szemben. Általános szabályként kimondhatjuk azt, hogy először az összes funkcionális függőséget írjuk fel, majd a hiányzó kapcsolatok leírására használjuk csak a többértékű függőséget.

1.2 Reláció kulcs fogalma

Definíció.
Az A attribútumhalmaz egy K részhalmazát kulcsnak nevezzük ha

• a K értékei az R reláció mindegyik sorát egyértelműen meghatározza,
• de ha egyetlen attribútumot is elhagyunk K-ból, akkor ez már nem teljesül.

Egy reláció kulcsa tehát olyan attribútum-csoport, amelyben nincs olyan két sor, amelyeknek a kulcsban szereplő attribútumok értékei azonosak volnának.
Ha K egyetlen attribútumból áll, akkor a kulcsot egyszerűnek nevezzük, ha nem ilyen, akkor összetett.
Nyilvánvaló, hogy egy relációban mindig van kulcs (esetleg a teljes attribútumhalmaz). Az is világos, hogy egy relációnak több kulcsa is lehet. A reláció attribútumai közül azokat, amelyek legalább egy kulcsban szerepelnek, elsődleges attribútumoknak, a többieket másodlagosaknak (nem elsődlegeseknek) nevezzük.

A reláció kulcs a reláció egy sorát azonosítja egyértelműen. A reláció - definició szerint - nem tartalmazhat két azonos sort, ezért minden relációban létezik kulcs. A reláció kulcsnak a következő feltételeket kell teljesítenie

• az attribútumok egy olyan csoportja, melyek csak egy sort azonosítanak (egyértelműség)
• a kulcsban szereplő attributumok egyetlen részhalmaza sem alkot kulcsot
• a kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL)

Egy relációban tartsuk nyilván az osztály tanulóinak személyi adatait
SZEMÉLY_ADATOK=({ SZEMÉLYI_SZÁM, SZÜL_ÉV, NÉV}).
A SZEMÉLYI_ADATOK relációban a SZEMÉLYI_SZÁM attributum kulcs, mert nem lehet az adatok között két különböző személy azonos személyi számmal.
Előfordulnak olyan relációk is, melyekben a kulcs több attributum érték összekapcsolásával állítható elő.
Készítsünk nyilvántartást a diákok különböző tantárgyakból szerzett osztályzatairól az alábbi relációval:
NAPLÓ=({SZEMÉLYI_SZÁM, TANTÁRGY, DÁTUM, OSZTÁLYZAT)}
A NAPLÓ relációban a SZEMÉLYI_SZÁM nem azonosít egy sort, mivel egy diáknak több osztályzata is lehet akár ugyanabból a tantárgyból is. Ezért még a SZEMÉLYI_SZÁM és a TANTÁRGY sem alkot kulcsot. A SZEMÉLYI_SZÁM, TANTÁRGY és a DÁTUM is csak akkor alkot kulcsot, ha kizárjuk annak lehetőségét, hogy ugyanazon a napon ugyanabból a tantárgyból egy diák két osztályzatot kaphat. Abban az esetben, ha ez a feltételezés nem tartható (ennek a rendszer analíziséből kell kiderülnie!), akkor nem csak az osztályzat megszerzésének dátumát, hanem annak időpontját is tárolni kell. Ilyenkor természetesen a NAPLÓ relációt ezzel az új oszloppal ki kell bővíteni.
Nem csak összetett kulcsok fordulhatnak elő a relációkban, léteznek olyan relációk is, melyekben nem csak egy, hanem több kulcs is található. Ennek illusztrálására nézzük meg a következő relációt
KONZULTÁCIÓ=({TANÁR, IDŐPONT, DIÁK)}
A KONZULTÁCIÓ relációban a tanár illetve a diák oszlopban olyan azonosítót képzelünk, mely a személyt egyértelműen azonosítja (például személyi szám). Minden egyes diák több konzultáción vehet rész, minden tanár több konzultációt tarthat, sőt ugyanaz a diák ugyanannak a tanárnak más-más időpontokban tartott konzultációin is részt vehet. Ezekből következik, hogy sem a TANÁR, sem a DIÁK, sem pedig ez a két azonosító együtt nem kulcsa a relációnak. De egy személy egy időben csak egy helyen tartózkodhat. Ebből következik, hogy a TANÁR, IDŐPONT attributumok kulcsot alkotnak, de ugyanilyen okból kifolyólag a DIÁK, IDŐPONT attribútumok is kulcsot alkotnak.

1.3 A külső kulcs

Külső kulcsnak (vagy idegen kulcsnak) nevezzük egy relációnak azokat az attribútumait, amelyek egy másik relációban kulcsot alkotnak.
Külső kulcs nem azonosítja a rekordokat, tehát nem valódi kulcs, hacsak a táblák sorai közötti kapcsolatot fejezi ki.

1.3.1 Külső kulcs ugyanabban a táblában (Rekurzív kapcsolat)

A relációs adatmodellben megengedjük, hogy egy külső kulcs ugyanabban a táblában szerepeljen mint amiben maga a kulcs.

1.3.2 Külső kulcs párhuzamos kapcsolatban

A külső kulcs egy táblázatban többféle minőségben, jelentéssel is szerepelhet. Ilyenkor természetesen a külső kulcsnak annyi nevet adunk, amennyi jelentése van.

1.3.3 Külső kulcs egy-egy típusú kapcsolatban

Előfordulhat, hogy két táblázat kapcsolata olyan, hogy a külső kulcs és a között 1:1 kapcsolat van.
Külső kulcsot vagy kulcsokat is megkülönböztetünk egy relációban. Ezek az attributumok nem az adott relációban, hanem az adatbázis másik relációjában alkotnak kulcsot. Például ha a KONZULTÁCIÓ relációban a DIÁK azonosítására a személyi számot alkalmazzuk, akkor ez egy külső kulcs a személyi adatokat nyilvántartó relációhoz.

1.3.4 Generátorhalmaz

P attribútumhalmaz generátor, ha P-től függ Q attribútum halmaz és P-nek és a P-Q kapcsolatnak kevesebb eleme van, mint Q.
A tényleges tervezés ismertetése előtt korábbi fogalmakat konkretizálunk.

1.4 Redundancia fogalma

A logikai adatbázis tervezés egyik fő célja a redundanciák megszüntetése. Redundanciáról akkor beszélünk, ha valamely tényt vagy a többi adatból levezethető mennyiséget ismételten (többszörösen) tároljuk az adatbázisban. A redundancia, a szükségtelen tároló terület lefoglalása mellett, komplikált adatbázis frissítési és karbantartási műveletekhez vezet, melyek könnyen az adatbázis inkonzisztenciáját okozhatják. Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó tényeket tartalmaz. Megjegyezzük, hogy a fizikai tervezés során az adatbázis műveletek gyorsítása érdekében redundáns attribútumokat is bevezetünk.
A redundancia egyik fajtája, amikor ugyanazt a tényt többször tároljuk. Nézzük meg a következő relációt.



Tanár	Tantárgy	Össz_óraszám	Tanított_órák
Fábián Zoltán	Adatbázis kezelés	64	12
Szűcs Gabriella	Matematika	32	8
Dulácska Ildikó	Adatbázis kezelés	64	4
Bencze Zsolt	Matematika	32	5

A fenti relációban a tantárgyak össz óraszámát annyiszor tároljuk, ahány tanár tanítja az adott tantárgyat. A példa kedvéért feltételeztük, hogy egy tantárgyat több tanár is tanít. A redundancia a következő hátrányokkal jár:
Ha egy tantárgy össz óraszáma megváltozik, több helyen kell módosítani a relációban.
Valahányszor egy új tanár kerül be a relációba ugyanannak a tantárgynak az előző soraiból kell elővenni az össz óraszám adatot.
Az utolsó sorban szereplő tantárgy (angol) esetén még nem került kitöltésre a tanár személye. Új tanárnak a listára történő felvételekor ezt az esetet másként kell kezelni. Ilyenkor csak két üres értéket (tanár, tanított órák) kell átírni.
A redundanciát meg kell különböztetni az értékek duplikált (többszörös) tárolásától. A duplikált adattárolásra szükségünk lehet a relációkban, míg a redundanciát el kell kerülni. Vizsgáljuk meg a következő relációt.



Termék	Alkatrész	Darab
Nyomtató papir	adagoló	1
Nyomtató	64Kb memória	2
Számítógép	1.2 Mb floppy	1
Számítógép	1 Mb memória	4

Az előző táblázat a termék oszlopban többször tartalmazza a nyomtató és számítógép adatokat. Ez azonban nem okoz redundanciát, mivel egy termék több alkatrészből is állhat, így nem ugyanannak a ténynek a többszörös tárolásáról van szó, hanem egy másik tényt fejezünk ki, melyhez elengedhetetlen a duplikált tárolás. A duplikált és a redundáns adatok között a funkcionális függőségek vizsgálatával tehetünk különbséget. Ezt majd a normál formák ismertetésénél tesszük meg.
A redundancia fordul elő akkor is, ha levezett vagy levezethető mennyiségeket tárolunk a relációkban. Az ilyen mezőket számított mezőknek hívjuk.
Levezetett adatokat tartalmazhat egyetlen reláció is abban az esetben, ha egyes attributumok értéke egyértelműen meghatározható a többi attributum alapján, például, ha a kerületet is nyilvántartjuk az irányítószám mellett.
A redundáns adatok megszüntetésére két mód van. A levezetett adatokat tartalmazó relációkat vagy attribútumokat el kell hagyni. A relációkban tárolt redundáns tényeket a táblázatok szétbontásával, dekompozíciójával szüntethetjük meg (a 3.10 példában szereplő relációt kettő relációra bontjuk fel
Órák = {Tanár, Tantárgy, Tanított_Órák} és Össz_órák = {Tantárgy, Össz_óraszám}
Fizikai redundanciáról beszélünk, ha az adatokat többszörösen tároljuk egy reláción belül vagy több relációban.
Logikai redundanciáról beszélünk, ha különböző relációkban tárolunk azonos adatokat. A logikai redundancia alkalmas külnböző relációk közötti kapcsolóattribútum szerepére, ezért ilyenkor kívánatos. Ezt az esetet gyenge logikai redundancának hívjuk egyébként erős logikai redundanciáról beszélünk.

1.5 Normálformák - a redundancia megszűntetése

Az adatbázis-tervezés folyamatában az adatbázisban leképezendő rendszert elemzésnek vetjük alá és meghatározzuk a tárolandó adatok körét, azok egymás közötti kapcsolatait és az adatbázissal szemben felmerülő igényeket. Ezután következik a rendszertervezés, melynek eredménye az adatbázis logikai modellje. Végül fizikai szinten képezzük le a logikai adatbázis modellt a felhasználható szoftver és hardver függvényében.
A logikai tervezés célja egy redundancia mentes reláció rendszer, relációs adatbázis. A reláció elmélet módszereket tartalmaz a redundancia megszüntetésére az úgynevezett normál formák segítségével. A következőkben a relációk normál formáinak definícióját mutatjuk be példákon keresztül. A normál formák előállítása során a funkcionális és a többértékű függőség, valamint a reláció kulcs fogalmát használjuk fel. A normál formák képzése során leegyszerűsítve, olyan relációk felírása a cél, melyekben csak a reláció kulcsra vonatkozó tényeket tárolunk. Öt normál formát különböztetünk meg. A különböző normál formák egymásra épülnek, a második normál formában levő reláció első normál formában is van. A tervezés során a legmagasabb normál forma elérése a cél. Az első három normál forma a funkcionális függőségekben található redundanciák, míg a negyedik és ötödik a többértékű függőségekből adódó redundanciák megszüntetésére koncentrál.
A normál formákkal kapcsolatban két újabb a relációkhoz kapcsolódó fogalommal kell megismerkedni. Elsődleges attribútumnak nevezzük azokat az attribútumokat, melyek legalább egy reláció kulcsban szerepelnek. A többi attribútumot nem elsődlegesnek nevezzük.

1.5.1 Első normál forma (1NF)

Egy reláció első normál formában van, ha minden attribútuma egyszerű, nem összetett adat. A könyvben eddig szereplő valamennyi reláció kielégíti az első normál forma feltételét. Mintaképpen álljon itt egy olyan reláció, melynek attribútumai is relációk.


Szakkör	Tanár	Diákok
Számítástechnika	Nagy Pál
		Név	osztály
		Kiss Rita	III.b
		Álmos Éva	II.c
Video	Gál János
		Név	osztály
		Réz Ede	I. a
		Vas Ferenc	II. b

1.5.1.1 Hogyan hozzuk 1NF-re egy relációt:
1. lehetőség:
Ha több értéket tartalmaz egy mező egy sorban, akkor annyi sorra bontjuk a sort, ahány értéket tartalmaz a mező.
2. lehetőség:
Két vagy több relációra bontjuk az eredeti relációt és közös azonosítóval hivatkozunk a közös értékekre. Az egyikben az azonosító kulcs lesz, a többi relációban pedig a külső kulcs lesz.

1.5.2 Második normál forma (2NF)

Az első normál forma nem elegendő feltétel a redundanciák megszüntetésére. Egy reláció második normál alakjában nem tartalmazhat tényeket a reláció kulcs egy részére vonatkozóan. A második normál pontos definíciója két feltétellel írható le.
A reláció első normál formában van
A reláció minden nem elsődleges attributuma teljes funkcionális függőségben van az összes reláció kulccsal.
Gyakorlatban ez azt jelenti, hogy egyszerű értékek szerepelnek a mezőkben és minden másodlagos attribútum teljes funkcionális függőségben van.
Megjegyzés:
Ha a kulcs egy attributumból áll, akkor a reláció 2NF.
Ha csak egy mező van a relációban, akkor 2NF.

1.5.2.1 Hogyan hozzuk 2NF-re egy relációt?
Kiemeljük a kulcsból azokat az attribútumokat, amelyek önállóan is meghatározzák a másodlagos attribútumokat.
Az előző lépésszerint összetartozó elsődleges és másodlagos attribútumokból reációt állítunk elő.
Azokat a másodlagos attribútumokat, amelyek csak a kulcstól függ a kulcsban szereplő elsődleges attribútumokkal egy táblába fogjuk össze.

1.5.3 Harmadik normál forma (3NF)

A második normál formájú relációkban nem lehetnek olyan tények, amelyek a reláció kulcs részeihez kapcsolódnak. Azonban ennek ellenére is lehet bennük redundancia, ha olyan tényeket tartalmaznak, amelyek a nem elsődleges attributumokkal állnak kapcsolatban. Ezt a lehetőséget szünteti meg a harmadik normál forma definíciója. Egy reláció harmadik normál formában van, ha
A reláció második normál formában van.
A reláció nem tartalmaz funkcionális függőséget a nem elsődleges attributumok között.

1.5.3.1 Hogyan hozzuk 3NF-re egy relációt?
Megszüntetjük a másodlagos attribútumok közötti funkcionális függőséget, azaz szintén törr relációra bontjk az eredeti relációt.
(Idáig kell!)

1.5.4 Boyce/Codd normál forma (BCNF)

A normál formák tárgyalása során eddig olyan relációkra mutattunk példákat, melyeknek csak egy reláció kulcsa van. A normál formák definiciója természetesen alkalmazható a több kulccsal rendelkező relációkra is. Ebben az esetben minden attributum, mely valamely kulcsnak a része, elsődleges attributum, de ez az attributum függhet egy másik, ezt nem tartalmazó kulcs részétől. Ha ez a helyzet fennáll, redundaciát tartalmaz a reláció. Ennek a felismerése vezetett a harmadik normál forma egy szigorúbb definiciójához, a Boyce/Codd normál formához.
Minden elsődleges attributum teljes funkcionális függőségben van azokkal a kulcsokkal, melyeknek nem része

1.5.5 Negyedik normál forma (4NF)

Sajnos még a Boyce/Codd normál forma is tartalmazhat redundanciát. Mindeddig csak a funkcionális függőségeket vizsgáltuk, a többértékű függőségeket nem. A további két normál forma a többértékű függőségekből adódó redundancia kiszűrését szolgálja.
Egy reláció negyedik normál formában van, ha egy XY többértékű függőséget tartalmazó relációban csak az X és Y-ban megtalálható attributumokat tartalmazza.
Képzeljük el azt, hogy egy relációban tároljuk az apa, és gyermekeinek nevét valamint a gyermek hobbiját. Minden apának több gyermeke és minden gyereknek több hobbija is lehet.
Hosszú ideig a negyedik normál formát tartották a normalizálás utolsó lépésének. A többértékű függőségek külön relációkban tárolásával azonban információt veszthetünk.
A normál formák tárgyalása végén megjegyezzük, hogy a harmadik normál formáig mindenféleképpen érdemes normalizálni a relációkat. Ez a redundanciák nagy részét kiszűri. Azok az esetek, melyekben a negyedik illetve az ötödik normál formák alkalmazására van szükség, ritkábban fordulnak elő. Az ötödik normál forma esetén a redundancia megszüntetése nagyobb tároló terület felhasználásával lehetséges csak. Így általában az adatbázis tervezője döntheti el, hogy az ötödik normál formát és a nagyobb adatbázist vagy a redundanciát és a komplikáltabb frissítési, módosítási algoritmusokat választja.

1.6 Anomáliák az adatbázisban

Az egyes normálformákkal az adatbázisban meglévő bizonyos anomáliák szüntethetők meg. Ezek közül most azokkal foglalkozunk, amelyek a 2NFre hozással szűrhetők ki.

1.6.1 Módosítási anomália

AElőfordulhat; hogy valamely attribútum értékeit módosítani kell. Ha például az ELADÁS adatbázisban a termékkódokon (TKÓD) akarunk változtatni, akkor a TKÓD oszlop minden elemét meg kell vizsgálni, és minden olyan sorban végre kell hajtani a módosítást, amelyben a módosítandó kód szerepel. A TERMÉKI relációban viszont a TKÓD oszlopban minden kód csak egyszer szerepel, tehát csak egy helyen kell módosítani. Azt mondhatjuk tehát, hogy a 2NF-re hozással a módosítási anomáliát szüntettük meg.

1.6.2 Törlési anomália

Az adatbázisunk lehet olyan, hogy ha benne egy sort törlünk, alapvető információkat veszítünk el. Ha pl. az ELADÁS adatbázisban {082, 110} kulcsú rekordot töröljük, akkor ez a 110-es videóra vonatkozó információk elvesztését eredményezné. Viszont ha a törlést az ELADÁS2 adatbázisban végezzük el, nincsen baj, mert a TERMÉKI adatbázisban megmarad ez az információ.
A 2NF-es forma tehát megszünteti ezt az anomáliát.

1.6.3 Bővítési anomália

AA bővítési anomália fogalmát is példánkon mutatjuk be. Tegyük fel, hogy az ELADÁS relációt egy új információval kellene bővíteni, mondjuk a hajszárító termékkel, aminek kódja: 002; ára: 2000 Ft. Ezeket az információkat az eladó ismeri, de nem tudja beírni az ELADÁS relációba, mert eddig még nem adtak el ilyen terméket, (nem készült róla számla) és így nincsen kulcsunk rá. A TERMÉKI relációba viszont könnyen bevihetők ezek az adatok. Ez azt jelenti, hogy a 2NF-es relációval elkerülhető a bővítési anomália.

1.6.4 Inkonzisztencia

Egy adatbázis akkor inkonzisztens, ha egymásnak ellentmondó értékeket tartalmaz. Ilyen esetek jöhetnek létre akkor, ha egy adatbázis frissítésekor, módosítás törlés vagy új érték felvitelekor a kapcsolatban lévő relációk tábláit nem módosítjuk megfelelően.

1.6.5 Tranzakció

A tranzakció általános fogalom. Amikor egy rendszer egy kiinduló állapotból átalakul egy végső állapotba, az egy ideig eltart és az átalakulás során instabil állapotban van, vagy lehet. Ha az átalakulás folyamata megszakad valamilyen külső okból, vagy hibás működés eredményeként, akkor a kiindulási állapot már nem érvényes, a cél állapotot pedig még nem érte el a rendszer. A rendszer inkonzisztenssé válhat, illetve a rendszer integritása sérülhet.
Ez adatbázisok esetén azt jelentheti, hogy egyes mezők, rekordok vagy akár egész táblák tartalma nem lesz megfelelő, vagy megsérül, adatvesztés a következménye.
A tranzakció a rendszerbe beépített olyan alrendszer, amely az állapotváltozás előtt automatikusan elmenti az állapot paramétereit, és csak akkor törli az előző állapot elmentett értékeit, ha a tranzakció sikeresen lezajlott, vagyis a cél állapotot elértük. Hiba esetén automatikusan visszaállítja a kiinduló állapotot a rendszer.

1.7 Az adatmodell időfüggvényének szerepe az adatmodell kialakításában.

A törzsadatok olyan adatok, amelyek a rendszer életciklusának jelentős részében nem változnak. Ilyen esetekben el lehet térni olyan elvektől, amelyek általában igazak a táblákra. Lehetséges szótárakat létrehozni, amelyek azonosítására például nem természetes kulcsokat használunk, hanem például magát az adat elnevezését, mivel boztisítani tudjuk a rendszerben a megfelelő, általános egyediséget.
Felmerül a kérdés, hogy az adatok archiválásakor vajon szükséges-e ezeket a táblákat is archiválni? A válasz nem, mivel ezeknek a tábláknak az értéke statikus.

1.8 Fizikai tervezés

Ha egy saját tervezésű szoftverrel óhajtjuk kezelni adatainkat a fizikai tervezés szintjébe bele kell, hogy értsük annak az eszközrendszernek a tervezését is, amely a file-ok fizikai kezelését végzi. Ilyenkor meg kell tervezni a fileszerkezetet is, az elérés módját, a rekordok címzését, az indexelés módját, az elérési útvonal kezelését stb. Mivel a modern rendszerek ezeknek a terheknek a jó részét leveszi a vállunkról ezért céldszerű az adatbázis- kezelési feladatokat DBMS-ekkel megoldani. Köztes megoldás az olyan rendszerek használata, mint a CLIPPER, DBASE, stb, amely bizoyos funkciókat levesz a programozó válláról. Az adatbázis táblák tervezése és létrehozása már nem a programozó szoftverének a feladata, de a fizikai elhelyezkedés a könyvtárstruktúrában, az adattáblák elérése, az indexek megnyitása, bezárása a programozó feladata.
A relációs adatbázisok esetében a logikai tervezés során a relációk már elnyerhetik végleges alakjukat, melyeket egyszerűen leképezhetünk az adatbázis-kezelőben. A fizikai tervezés során inkább arra koncentrálunk, hogy a logikai szerkezet mennyire felel meg a hatékony végrehajtás feltételeinek, illetve milyen indexeket rendeljünk az egyes relációkhoz.
A relációkon végrehajtott művelet együttest tranzakciónak nevezzük és általában a tranzakciók gyors végrehajtását kívánjuk elérni.
A fizikai tervezés során előfordulhat, hogy a relációkba szándékosan redundanciákat építünk a hatékonyabb tranzakció kezelés érdekében. Ez visszalépésnek tűnhet a logikai tervezés során követett következetes redundancia megszüntető manipulációkhoz képest. A lényeges különbség viszont az, hogy itt a redundancia ellenőrzött módon kerül be a relációba, nem csak véletlenül maradt ott a hiányos tervezés miatt. Gyakran előfordul például az, hogy a sűrűn együtt szükséges adatokat egy relációban tároljuk a lehető leggyorsabb visszakeresés érdekében.

1.8.1 Indexek fogalma és felépítése

A relációkban tárolt információk visszakeresését az indexek nagymértékben meggyorsíthatják, így a tervezés során nagy hanjgsúlyt kell fektetni a helyes indexek kiválasztására, szem előtt tartva azt is, hogy az indexek számának növelésével az adatok beviteléhez illetve módosításához szükséges idő megnövekszik az indexek frissítése miatt. A relációkhoz kapcsolt indexek segítségével az index kulcs ismeretében közvetlenül megkaphatjuk a kulcsot tartalmazó sor fizikai helyét az adatbázisban. Az indexek képzésére két módszer terjedt el, a hash kódok és a bináris fák.

1.8.2 Hash kódok

A hash kódokat manapság már csak hálós vagy jierarchikus modellben használják. Ennek a kódolási technikának az a lényege, hogy egy számítási algoritmus alapján magából az index kulcsból alakul ki a hash kód, melynek alapján egy táblázatból kiolvasható a keresett értéket tartalmazó sor fizikai címe vagy egy számítási algoritmus adja meg a keresett értéket. A hash kód számítási algoritmusa nem mindig ad különböző érté keket az index kulcsokra. Ez abból is következik, hogy csak véges hosszúságú hash táblát tudunk kezelni. Minnél jobb a hash algoritmus, annál kevesebb lesz a kulcsütközés.

1.8.3 A hash kód kulcsütközés kezelése

Azokban az esetekben amikor különböző kulcsértékekhez ugyanazt a címet adja, ezeket a különböző kulcsú rekordokat szinonimoknak mondjuk. A szinonim rekordokat kezelni kell (Például külön táblákba tesszük a különbözö betűvel kezdődő neveket, és ott más módszerrel finomítjuk a keresést. Ez az elosztott altáblák módszere) Nyilván annál jobb egy hash leképezés minél kevesebb szinonim van.

Példa hash leképezésre: alkalmasan nagy prímszámmal osztjuk a numerikusnak tekintett kulcsot, és a maradék lesz a cím.
Kulcs szerinti közvetlen feldolgozásra a jó hash leképezés hatékonyabb az indexnél, ezért a hash leképezést előszeretettel alkalmazták a hierarchikus és hálós modellben.

A relációs adatbázisoknál nem használják, mert:

• nem tesz lehetővé szekvenciális elérést
• csak kulcs szerint lehet keresni, egy rekord más mezője szerint nem.

Az azonos kódot adó kulcsokat összeláncolják a hash táblában. A láncok növekedésével természetesen a reláció sorainak eléréséhez szükséges idő is növekedik. A hash kód alapján történő visszakeresés nagyon gyors.

1.8.4 Bináris fa

Ma már szinte kizárólag a bináris fákat alkalmazzák a relációs adatbázisokban. Ennél a módszernél a bináris keresést alkalmazzuk. Ehhez az index kulcsokat növekvő vagy csökkenő sorrendbe kell rendezni. A fa szerkezetet azért használják, mert nagy adatbázisok esetén az összes index kulcs nem tartható egyidőben a memóriában. A fa gyökere és csomópontjai nem tartalmazzák az index kulcshoz tartozó sor fizikai helyét, hanem csak a fa levelei. A keresés mindig a gyökértől kezdődik, a megfelelő ág felé folytatódik, és akkor ér véget, ha egy levélhez érünk. Ha a levélben tárolt index kulcs azonos a keresettel, akkor megtaláltuk a keresett értéket, ellenkező esetben sikertelen volt a keresés.
A bináris fák felépítésénél arra törekszenek, hogy a fa valamennyi ága azonos hosszúságú legyen. Az ily módon felépített fát kiegyensúlyozott fának hívják. A kiegyensúlyozott fákban találhatjuk meg a lehető legkevesebb összehasonlítással a keresett elemet.
A gyakorlati megoldásokban a hatékonyság kedvéért a csomópontokban nem csak egy index kulcs értéket tárolnak, hanem a háttértár tárolási egységének megfelelő számút. Mivel a PC-s rendszerek olvasási egysége 2- 4-8-16-32 vagy 64 kb, ezért egy lap általában ekkora. A bináris fák segítségével egy konkrét index kulcsot vagy az index kulcsok egy tartományát kereshetjük meg. A reláció sorait az index kulcs szerinti növekvő vagy csökkenő sorrendben is végigjárhatjuk, ami tulajdonképpen a bináris fa Bal-Közép-Jobb vagy Jobb-Közép-Bal bejárását jelenti. Ez hash kód esetén nem lehetséges.

1.8.5 Asszociatív rendszerek

Az utóbbi évtizedben kialakult és nem túlságsan széles körben elterjedt rendszerek, amelyek hardver szinten támogatják a memóriatartalom alapján az adateléréseket. Ezeket asszociatív memóriának hívjuk. A operációs rendszerek tárgykörben volrt rüla szó. Ezek segítségével lehet olyan tárolási és keresési módokat létrehozni, amelyek a tartalom alapján adnak eredményeket. A gyakorlatban speciális célhardver és célszoftver segítségével lehet alkalmazni csak őket.

1.8.6 A hálózati adatkezelés problémái

Az adatbáziskezelési feladatoka valós helyzetekben bonyolódnak, amikor hálózati hozzáféréssel kezeljük az adatbázisokat. Az alapszituáció az, hogy egyidejűleg többen is írnak az adatbázisba és olvasnak onnan. A filekezelő rendszerek általában a file-ok megnyitását kizárólagos módon (exclusive) engedélyezik, ami azt jelenti, hogy többen ugyanazt a file-t írásra nem nyithatják meg. Az adatbáziskezelők a filekezelő rendszerekkel ellentétben megosztott hozzáférést (share) engedélyeznek, ami azt jelenti, hogy egy időben többen is módosíthatják az adatbázist. Milyen problémák merülhetnek fel?



• Egyidejűleg olvasnak többen egy táblából. Ez nem probléma, mivel a kiolvasás nem változtatja meg az adatok tartalmát.
• Valaki olvas egy adatbázis táblából, más valaki ír bele. Ez problematiks, de az adatbáziskezelő rendszerek ilyenkor az éppen olvasott rekordra úgynevezett olvasási zárolást (lock)-ot alkalmaznak, ami azt jelenti, hogy amíg a rekord tartalmát teljesen ki nem olvassa a rendszer az alatt az idő alatt más nem módosíthatja a rekord tartalmát. Ezt a Clipper, DBASE stb esetén a programozónak külön le kellett programoznia, majd az olvasás végrehajtása után ki kellett kapcsolnia. Ekkor persze felmerül a kérdés, hogy az olvasás után következő írásról, és ezáltal a megváltozott tartalomról hogyan értesül az olvasást végrehajtó. Általában csak akkor értesül, ha mégegyszer kiolvassa az adatokat. Nagyon speciális rendszerek esetén a hálózaton keresztül nyitvatartott kapcsolatokat felhasználva az adatbáziskezelő képes értesíteni a klienseket a változásról és azok újraolvassák a megváltozott rekordokat.
  Van olyan rendszer, amely a rekord szintű zárolás esetén engedi azoknak a mezőknek a módosítását, amelyeket nem olvas más a táblából!
• A fenti eset egy speciális válfaja, amikor új rekordot visznek fel a táblába olvasás közben. Mivel az új rekord nem lehet még az olvasás tárgya, ezért azt szabadon megteheti a rendszer.
• Többen akarnak írni egy táblába. Amennyiben ezek az írási folyamatok különböző rekordok módosítását jelentik, akkor nyilván elvileg elképzelhető. Ekkor rekordszntű zárolást alkalmaznak a rendszerek és az írás végeztéig az adott rekord nem írható és olvasható más folyamat által. Ha a zárolt rekordot módosítani akarja egy másk folyamat, akkor kénytelen várnia, az előző folyamat írásának befejeztéig.
• Többen egy időben több rekord (akár az összes) tartalmát ismódosítani akarják. Ebben az esetben a rendszerek táblaszintű zárolást alkalmaznak, ami azt jelenti, hogy a tábla tartalmához más nem fér hozzá a módosítás ideje alatt. A táblaszintű zárolás időtartama hosszú is lehet, mivel a tábla méretét elvileg nem korlátozza semmi. Minden olyan esetben, amikor a zárolás miatt egy másik folyamat kénytelen várni, akkor a várakozó folyamat ciklikusan megnézi, hogy haszálhatja-e már a rekordokat. A várakozás nem tarthat a végtelenig, mert sajnos ez az eset nem különbözik a hardverhibától, ezért a folyamatok túl hosszú várakozás esetén holtponti helyzetbe juthatnak. (Lásp Operációs rendszerek) Ennek a megoldása érdekében a folyamatok egy idő mlva timeout-ot jeleznek, amely után felaszabadítják a lefoglalt erőforrásaikat, "elszáll" a rendszer.

A timeout helyzetek elkerülése érdekében a teljes táblák zárolását csak olyanesetben szabad és szokták megengedni, amikor biztonságosan és gyorsan futhat le az illető folyamat.

1.8.7 Tervezés a feldolgozási módok szerint

Interaktív (real-time vagy on-line) esetben fontos, hogy a kérdésekre adandó válaszok ideje megfelelően rövid legyen. Ez a fajta feldolgozási mód átlagosan kevésbé terheli le az adatbázis eredményét szolgáltató számítógépeket! Ha egyidejűleg sokan végeznek ilyen feldolgozást, akkor a válaszidők növekedhetnek. Ilyenkor az adatbázis szolgáltató hardvert, szoftvert jelentősen túl kell tervezni, hogy minden körülmények között is elfogadható válaszidőket produkáljon. Jellemzően hálózatokon keresztül érkeznek a válaszok a kliens gépekhez, a hálózatoknak az átviteli kpacitása véges, ezért az ilyen rendszerek alapvetően kliens-szerver üzemmódban működnek, és nagy szerepe van az adatok optimalizálásának!
Batch jellegű rendszerekben a kéréseket ütemezni lehet, ezáltal a feladatok akkor hajtódnak vége, amikor van rá elég erőforrás, processzoridő, memória, stb..., ezáltal nagyobb átlagos kihasználtságot lehet elérni, azonban a válaszidők a választott erőforráskezelési stratégiától függően változóak, de jellemzően hosszabbak is lehetnek.
Ha az adatokat off-line kérdezzük le, az azt jelenti, hogy a kapcsolatok csak időnként élnek, az adatokat egy helyi rendswzerben is rtárolni kell, és rendszeres időközönként szinkronizálni kell az adatokat a központi rendszerrel, adatbázissal. A szinkronizációhoz természetesen az egyes tranzakciók időpontját is rögzíteni kell, mivel a frissítések oda-vissza meg kell, hogy történjenek és mindig az utolsó módosítás lesz a mérvadó versenyhelyzetben. Ilyenkor óriási szerepe van a szinkronizációs mechanizmusnak. A szinkronizációt olyan időben kell elvégezni, amikor lehetőleg kicsi az adatbázis forgalma. Biztosítani kell a tranzakciós kezelést a szinkronizáció közben, hiszen az siokáig is eltarthat és a kapcsolat menet közben megszakadhat.
Elosztott adatbázisokról (distributed) beszélünk, amikor az adatbázis egyes részeit nem közös helyen tároljuk. S az egyes részek közötti kapcsolat, a frissítési, szinkronizációs kérdéseket itt is meg kell oldani. Nyilván úgy érdemes elhelyezni az adatbázis egyesrészeit, hogy azok a feldolgozás helyéhez "közel" legyenek. Érdemes a különböző helyeken lévő adatbázisokfiikai szerkezetét, kezelési módját egységessé tenni.

1.8.8 Hálózati, adatbázisokkal kapcsolatos biztonsági kérdések

Az adatok általában nem nyilvánosak, ezért az adatokhoz való hozzáférés módját is szabályozni kell. A szabályozás alapja mindenkor:

• felhasználói név
  Itt is ugyanolyan neveket kell hazsnálni, mint általában a szervereken, különböző belépési szituációkban
• jelszó
  A jelszó természetesn hasonlóan , mint más heélyzetekben nehezen kitalálható, kis és nagybetűket és számokat tartalmazó lehetőleg zagyva karaktersorozat. Nem szabad leírni, nem szabad a hozzátartozók adatait használni. A jelszavak tárolását titkosítva egyutas titkosítással célszerű megoldani, ami annyit jelent, hogy nincsen a titkosító kódnak inverzfüggvénye. Hálózaton keresztül csak a titkosított jelszó közlekedhet.
• a felhasználói névhez tartozó jogosultságok Általában az adatbázisokhoz a jelszó egyúttal egy tipizálható hozzáférési jogosultságot is jelent. Lehetséges a hozzáféréseket adatbázisszinte, táblaszinten vagy rekordszinten is kezelni. Sőt előfordulhat az is, hogy mezők szintjén szabályozzuk a hozzáférést.

A hozzáférésnek a tipikus szintjei:
• Nincs hozzáférés
• Olvasási hozzáférés
• Módosítási hozzáférés.
• Adminisztrációs hozzáférés

Felmerül a kérdés, hogy miért nem az adatokat titkosítjuk?
Nagy mennyiségú adat és intenzív használat esetén jelentős teljesítményromlást okozhat az adatok titkosítása, azonkívül esetleges rendszerösszeomás esetén a szervízfunkciók alkalmazását nehezíti. A védett anyagot általában olyan rendszeren helyezik el, amely védett az illetéktelen hozzáférés ellen, így az adatok nem kerülhetnek illetéktelenek kezébe.

1.9 Összekapcsolás

Az összekapcsolás művelete két vagy több relációt kapcsol össze egy-egy attributum érték összehasonlításával. Az összekapcsolás leggyakoribb esete amikor az attributumok egyezését vizsgáljuk, ezt egyen összekapcsolásnak nevezzük.

Ez egy speciális szorzás mely a következő műveletsorral írható le

1. Vegyük az első reláció egy sorát
2. Az összekapcsolási feltételt vizsgáljuk meg a második táblázat összes sorára, ha igaz, adjuk mindkét reláció sorát az eredményhez
3. Folytassuk az 1. ponttal amig van még sor az első relációban

Az összekapcsolás eredmény relációjában az első reláció csak azon sorai szerepelnek, melyekre található a feltételt kielégítő sor a második relációban. Gyakran arra van szükség, hogy az első reláció valamennyi sora szerepeljen legalább egyszer az eredmény relációban. Ezt a fajta összekapcsolást külső összekapcsolásnak nevezzük.




2. ADATBÁZIS-KEZELŐKBEN ALKALMAZHATÓ ADATTÍPUSOK

Az adatbáziskezelő szoftverek napjainkra eléggé egységesekké váltak a bennük alkalmazható adattípusokat tekintve. Tipikusan az alábbi adattípusokat kezelhetünk ezekkel a rendszerekkel:
Szöveg
Általában maximum 255 karakter hosszú lehet. Az adatbázis definiálásakor meg kell adnunk a szöveg hosszát.
Numerikus típusok
Egyes rendszerekben külön kezelik az egész és a lebegőpontos típusokat, míg más esetekben közös a kezelés. Ennek megfelelően a numerikus típusoknál alapvetően egész típus esetén megkülönböztethetünk rövid egészet (1 byte-on tároljuk), egész típust (két byte-on tárolva) és hosszú egészet (4 byte-on tárolva). Ez megegyezik a legelterjedtebb általános célú programozási nyelvek típusaival, sokszor még az elnevezés is ugyanaz. Ezen adattípusok méretei adottak.
A lebegőpontos típusok tárolása esetén meg kell adnunk, hogy hány tizedesjegy pontossággal szeretnénk tárolni az adatokat és maga az adat hány jegy pontosságú legyen. Adatbázis-kezelő rendszertől függően lehet beállítani a maximális értékeket és a rendszerektől függ a belső ábrázolás mikéntje is. Például a Clipper DBASE stb... rendszerek esetében a számokat nem binárisan kódolva, hanem ascii kódokkal leírva tárolják az adatbázisban.
Numerikus típust akkor alkalmazunk egy adatbázisban, hogyha a mező értékével matematikai, logikai vagy statisztikai műveleteket kell majd végrehajtanunk!
A logikai értékek egy speciális fajtája a currency, azaz pénznem. Ez csak abban különbözik a többi numerikus értéktől, hogy formátumában hordozza az illető ország vagy az előre beállított pénznem megjelenési formáját is, továbbá csak két tizedes pontossággal számol.
Dátum, idő
A numerikus típus egy speciális fajtája, ugyanis a dátumokkal számolni lehet! A dátumoknak speciális formájuk van. A tárolás belső formája lehet string vagy numerikus, de minden esetben megkülönböztetjük az előbbi adattípusoktól, csak konverziós függvényeken keresztül lehet a fenti adattípusokba átkonvertálni és vissza. A dátum típusú tárolási egység megadásakor meg kell határoznunk a dátum formátumát. Általában megkülönböztethetünk rövid és hosszú dátumot, amely különbözhet az évszámok kiírásában, vagy különbözhet a hónap és a hét napja kiírásában. (2001.01.12 rövid alak, 2001 január 12, szombat – hosszú alak) Különböző nyelvi területeken természetesen az adott területre jellemző dátumformátumokat határozhatunk meg, amennyiben az adatbázis-kezelő ezt lehetővé teszi.
A dátum típus mérete mindig adott, tehát a formátum meghatározásával egyúttal meghatározzuk az elfoglalt terület nagyságát is.
Az idő érték általában a dátum érték része, vagy legalábbis a két fajta adattípus konvertálható egymásba. Az idő kezelése során 12 vagy 24 órás napi idővel számolhatunk, illetve egyes rendszerekben a délelőttöt és délutánt a DE, DU vagy angolszász esetben AM, PM jelekkel jelöljük.
Logikai érték
A jól ismert Logikai változóknak megfelelő érték. Egyes rendszerekben ezt Igen-Nem, Boolean vagy hasonló névvel illetik. Két értéket tartalmazhat: Igaz-Hamis. A rendszerekben ezek szinonimájaként használatosak: Igen- Nem, Yes-No, .Y.-.N., True-False, .T.-.F., vagy az 1, 0 illetve a nem nulla-nulla értékpárok.
Az alábbi esetben biztosan Igaz, és biztosan hamis értéket tartalmaznak a kifejezések: (1 =1), (1 > 1)
Ha nem vagyunk biztosak az értékadésban, akkor a fenti kis trükkel tudsunk magunkon segíteni!
A logikai érték mindig 1 byte hosszúságú, bár ez így redundanciát okoz, mivel egy bit is elegendő lenne, de az ennél kisebb érték kezelése a mai modern számítógépeken sebességcsökkenéssel jár.
Megjegyzés (MEMO)
Nem minden rendszer tartalmazza az alábbi mezőtípust, de ahol igen ott az alábbiak igazak rá.
Struktúrálatlan szövegek tárolására alkalmas adattípus. A mérete korlátos, de a korlát megfelelően nagy 1-4-16- 32-64 KB. Rendezésekben, lekérdezésekben ezt az adattípust nem célszerű használni. Kezelésekor stringből (szövegből) kell kiindulni. Általában a tárolás modja különbözik az egyéb adatok tárolásától, sokszor (Clipper, DBASE Foxpro) az megjegyzés adatokat külön file-ban kezelik a rendszerek, de legalábbis speciálisan helyezik el a file-ban. A megjegyzés adattípus változását sokszor nem helyben kwezeli le a rendszer, hanem inkább egy új példányt hoz létre az eredeti pédlány helyett, amiben a módosított értékekkel együtt tároja a régi adatokat, így az ilyen adattíypus használata az adatbázis méretének rohamos növekedésével járhat együtt. Csak indokolt esetben célszerű alkalmazni.

BLOB
Bináris adatok, objektumok tárolására alkalmas adattípus. Nem minden adatbázis-kezelő rendszer alkalmazza, csak azok, ahol az objektumok kezelése megoldott az operációs rendszer más komponenseivel egyetértésben. A windows alatt kifejlesztett adatbáziskezelők többnyire ilyenek. Segítségükkel a rendszerben ,megadott bármilyen objektumtípust tárolhatunk az adatbázisban. Ennek a tárolásnak persze van egy hátránya: Az adatbázis mérete óriásira duzzadhat. Speciális függvények és kezelési módszerek vonatkozhatnak rájuk. Alternatívát jelenthet az, ha például képállományokat szeretnénk tárolni, ha nem magát a képet, hanem a képre mutató elérési utata tároljuk egy szöveg típusú mezőben, majd a képen végrehajtott módosításokat, műveleteket külső szoftver segítségével végezzük el.




3. AZ ADATBÁZIS-RENDSZER DOKUMENTÁLÁSA

Adokumentálásnak az alábbiakat kell tartalmaznia:

• Az adatbázis rendszer által tárolt adatokat
• Az adatok belső és külső logikai szerkezetét
• Az adatmodell szerinti táblák felépítését, az adatok formátumát
• Az adatbázis fizikai megvalósítását, a használt adatbázis-kezelő leírását, telepítését, a táblák generálásának módját
• A használt lekérdezéseket, azoktól elvárt adatokat
• A lekérdezések eredményeit megjelenítő listák riportok definícióját, formátumát
• Az egyes felhasználó eljárások leírását és haszálatának módját illetve forrásanyag esetén a forrásanyagot.
• Tesztelési eredményeket, a módszerek és a felhasznált adatok bemutatásával.
• Az archiválás módját és menetét tartalmazó előírásokat
• A rendszer indításához, leállításához és archiválásához, illetve módodításához szüksége mindenféle azonosítót és jelszót (biztonságos formában)
• Minden fenti dokumentációt lehetőség szerint írott és elektronikus formában is.

Abban az esetben, ha az adatbázis-kezelő rendszert valamilyen standard vagy általánosan elterjedt fejlesztő rendszerrel végeztü vagy végezzük, akkor a rendszer újragenerálásához szükséges adatok, információk a rendszer által előállított generátor file-okban található. Ilyen esetben ezeket az állományokat kell letárolni, biztonságos módon, megadva azokat a körülményeket, esetleg a fejlesztői rendszer teljes telepítzőkészletével egyetemben. Ilyenkor célszerű használni a rendszer saját dokumentáló tulajdonságait is.
Az utólagos módosítások tárolása is fontos feladat. A módosítások tárolására ma már vannak úgynevezett CSV jellegű rendszerek, amelyek a források megváltozását tárolják adatbázisban, visszakereshető módon.