Adatbázis-tervezés alatt jellemzően logikai adatbázis-tervezést értünk, hiszen az esetek túlnyomó többségében az adatbázis-kezelő rendszerek nem teszik lehetővé a fizikai struktúra lényeges befolyásolását. Adatbázis-tervezés kapcsán tipikusan relációs adatbázis-tervezést szokás érteni két okból is. Egyrészt ami a relációs adatbázisokra helyes tervezési módszer és nézőpont, az jellemzően a többi adatmodell alapján felépített adatbázisokra is alkalmazható, másrészt mert ez leggyakoriabb adatbázisfajta.

A helyes tervezés általában nem könnyű feladat, számos, helyenként ellentétes szempontot érdemes mérlegelni döntéseink előtt. Amire célszerű tekintettel lenni:

  • A létrehozott adatszerkezetben kódolt jellemzők és adatok a leírandó világot az adott célnak, nézetnek megfelelő teljességében reprezentálják.
  • Ne lehessen olyan lekérdezést megadni, amely a leírandó világgal nincs összhangban.
  • Adat (információ) ne vesszen el.
  • Az adatot és annak összetartozó részeit a lehető legkevesebb helyre kelljen beszúrni, illetve helyen kelljen módosítani vagy törölni.
  • Az adatbázis lekérdezésének hatékonyságát az adatszerkezet kialakítása ne rontsa jelentős mértékben.

Kulcselemek a tervezésben szerkesztés

A tervezést alapvetően meghatározza, hogy milyen információs egységekkel szeretnénk dolgozni, illetve az egyes adatelemek között milyen mélyebb összefüggés adott. Ezen lépések egyike sem formalizálható, nincs általános algoritmus a megoldásukra, hiszen az adatbázisokban bármilyen ismeretet leírhatunk, tárolhatunk, lényegében korlátozás nélkül.

Az adatelemek megválasztása nehéz feladat, sok tapasztalat kell egy megfelelő, minden felmerülő információs igényünket kielégítő, változtatást ritkán vagy egyáltalán nem igénylő jellemzőket (attribútumokat) megtaláljuk. Mivel minden esetet lefedő eljárás jelenleg nem ismeretes, ezért a legfontosabb alapelveket érdemes kiemelni:

  • Minden jellemző, amelyet egy individuum, objektum leírására érdekes, vagy az adatbázist felhasználó személyek és alkalmazások számára fontos jelenjen meg az adatbázisban. A több sokszor jobb.
  • Számos jellemző rendelkezik belső struktúrával (pl. cím, név). Csak annyira bontsd fel őket, amennyire feltétlenül muszáj, de annyira mindenképpen bontsd fel, amennyire szükséges. Megjegyzendő, hogy például a név esetében nagyon-nagyon sok felírási mód lehetséges: például a név része lehet a megszólítás (pl. professzor, excellenciás), títulusa (pl. dr.), ifj./id. megkülönböztetése, vezetéknév, középnév (ha van), keresztnév, egyéb utónév, családi állapotot jelölő név (pl. Gipszné Stukkó Mária esetében a Gipszné lehet ilyen). Természetesen, a címeknél sem egyszerűbb a helyzet.
  • Ha természetes, valós életben is használt egyedi azonosítója van egy individuumnak; ezeket, ha mindig elérhető és használható is, sose alkalmazd rekordok azonosítására. Erre egyrészt a megfelelő adatvédelem miatt van/lehet szükség, másrészt az idővel változó adatbázisokban egy esetleges korábbi értékre még szükség lehet, nem mindig célszerű felülírni az ilyen azonosítókat. Ugyanakkor mindig használd ezeket az azonosítókat a több, különböző leírással, adatokkal rendelkező, de azonos egyedet jelölő individuumok felismerésére.
  • Célszerű mindig egyetlen attribútumból álló, egyedi azonosítót előállítani minden különböző individuum számára (pl. számláló segítségével). A könnyebb kezelhetőség, illetve adatvédelmi szempontok érvényesíthetősége mellett a hatékonyabb kereshetőséget is biztosítja.

Funkcionális függőségek szerkesztés

A tervezés másik fontos eleme a jellemzők közötti összefüggések tudatosítása, elemzése és felhasználása a tervezés során. Az alábbiakban megmutatjuk, hogy a legtöbb probléma forrása abból eredeztethető, hogy esetlegesen nem figyelünk kellőképpen oda a jellemzők közötti „áthallásokra”. Az összefüggést formálisan is megadhatjuk: azt mondjuk, hogy egy A jellemző funkcionálisan függ egy B jellemzőtől, ha egy reláció (kitöltött táblázat) minden s és t elemére (sorára), ha s és t értéke megegyezik a B jellemzőn, akkor A értéken is megegyeznek. Mindezt B → A formában szokás jelölni. Értelemszerűen A → A mindig igaz.

Megkülönböztetünk ún. eseti és érdemi funkcionális függőséget. Az előbbi annyit jelent, hogy a vizsgált relációban – valamilyen baleset folytán – most éppen igaz ez az állítás, míg az utóbb szerint minden értelmesen, célnak megfelelő adatbázisban a jelzett összefüggés szükségszerűen fennáll. A tervezés szempontjából kizárólag az érdemi funkcionális függőségek fontosak, így a továbbiakban mindig érdemi funkcionális függőséget fogunk érteni funkcionális függőség (FF) alatt. Ha a jellemzők egy X részhalmaza a séma (tábla) minden jellemzőjét meghatározza, akkor azt mondjuk, hogy X szuperkulcs. Ha X egyetlen jellemzőből, vagy nem hagyható el jellemző belőle anélkül, hogy a szuperkulcs tulajdonság sérülne, akkor azt mondjuk, hogy X kulcs. Fontos tudni, hogy egy sémának akár több kulcsa is lehet.

Relációs adatbázis redundanciája szerkesztés

A relációs adatbázisok kialakítása esetében törekszünk arra, hogy különféle adategyüttesek redundanciáját csökkentsük. Redundancia alatt nem az adatok ismétlődését kell érteni, hanem a levezethető, többféleképpen előállítható adatok többszörös tárolását értjük. Fontos látni, hogy az r1 relációban a redundancia "Gipsz Jakab" vagy "1234 – Fő utca 2." együttes előfordulására vonatkozik, amennyiben feltesszük, hogy a személynév szükségszerűen meghatározza, hogy az illetőnek mi a bejelentett lakcíme. A redundanciát az értékek ismétlődése és a feltevés együttesen eredményezik. Önmagában sem a név, sem a lakcím előfordulása nem tekinthető redundánsnak, nem kell törekedni arra, hogy minden érték pontosan egyszer forduljon elő. A megadott feltételek miatt azt mondjuk, hogy a redundancia a relációs adatbázisok világában az ún. funkcionális függőség következtében előálló redundanciát jelentik.

r1 Név Bejelentett lakcím Telefonszám
1 Gipsz Jakab 1234 – Fő utca 2. 1234567890
2 Gipsz Jakab 1234 – Fő utca 2. 9876543210

Anomáliák szerkesztés

Miért kell a funkcionális függőségek okozta redundanciát csökkenteni? Azért, mert bizonyos változtatások az adatbázisban ellentmondásos adatokat eredményezhetnek, de legalábbis nemkívánatos állapotba juttatják az adatbázist. A relációs adatbázisok esetében pontosan akkor és csak akkor léphet fel valamilyen anomália, ha az adatbázis-szerkezet redundáns. Anomáliának nevezünk minden olyan jelenséget, amely egy adatbázis használata során nemkívánatos melléktermékként jelenik meg.

Beszúrási anomália szerkesztés

A beszúrási anomália – a fentieknek megfelelően – az a jelenség, amikor a beszúrás mellékhatásaként nem kívánt hatást váltunk ki az adatbázisban. A fenti példában mondjuk Gipsz Jakab egy újabb telefonszámához például a "4321 – Mellék utca 3." bejelentett lakcímet írnánk fel, akkor bizony a továbbiakban nem tudhatjuk, hogy mi Gipsz Jakab tényleges lakcíme. Ezt a jelenséget beszúrási anomáliának nevezzük.

Törlési anomália szerkesztés

Persze, az is előfordulhat, hogy Gipsz Jakab mindkét telefonszámát töröljük az adatbázisunkból, amit a megfelelő rekordok törlésével valósítunk. Ebben az esetben azzal a kellemetlen élménnyel szembesülhetünk, hogy Gipsz Jakab ismert lakcímét is töröltük, holott ez eredetileg nem volt feltétlenül szándékunkban. A jelenséget törlési anomáliának nevezzük. A probléma elkerülésére érdemes particionálni a fenti táblát, de abban az esetben – látni fogjuk – a helyreállítás okozhat gondot.

Módosítási anomália szerkesztés

Tegyük fel, hogy valamiért Gipsz Jakab 1234567890 telefonszámához tartozó címét meg akarjuk változtatni. Mivel a név szükségszerűen meghatározza a feltételezésünk szerint a bejelentett lakcímet, így a lakcím valamilyen más értékbe állításának eredményeképpen ismét ellentmondásos, de legalábbis nem teljes adatbázis keletkezik. Ez a jelenség a módosítási anomália.

Metszetképzési anomália szerkesztés

Rendundancia megszüntetése szerkesztés

A redundancia megszüntetését a tábláink (sémáink) kisebb egységekre való bontásával, (idegen szóval: dekompozíciójával) lehet megvalósítani. Ezt egyrészt indokolják a törlési anomáliánál látható problémák, másrészt azért, mert a relációs adatmodell meghatározása alapján a reláció egy halmaz; következésképp egy relációban (a tábla bármely kitöltésében) nem ismétlődhetnek elemek (sorok).

Veszteségmentesség szerkesztés

Függésőrző tulajdonság szerkesztés

Relációs adatbázisok teljessége szerkesztés

Szétválaszthatóság szerkesztés

Függetlenség szerkesztés