Adatbázis alapjai Készítette: Siki Zoltán 1. Bevezetés 1.1. Adatbázis fogalma 1.2. Történelmi áttekintés 1.3. Adatbáziskezelők szerepe, célja 1.4. Különböző adatbázis modellek 1.4.1. Hierarchikus adatbázis modell 1.4.2. Hálós adatbázis modell 1.4.3. Relációs adatbázis modell 1. Bevezetés Az adatbáziskezelés szervezés tantárgy keretén belül az adatbázis tervezés elméletét, a relációs algebra alapjait, illetve a relációs adatbáziskezelők lekérdező nyelvét (SQL) és az Oracle adatbáziskezelő használatát (a teljesség igénye nélkül) ismertetjük. A könnyebb megértést számos minta példával illetve gyakorló feladattal igyekszünk megkönnyíteni. 1.1. Adatbázis fogalma Adatbázison köznapi értelemben valamely rendezett, valamilyen szisztéma szerint tárolt adatokat értünk, melyek nem feltétlenül számítógépen kerülnek tárolásra. Képzeljük el, hogy egy céghez naponta átlagban 20 levél érkezik. A cég irattárosa kellő adattárolási tapasztalat hiján a leveleket az irattár ajtajára vágott lyukon keresztül bedobja. Elképzelhető, hogy pár év eltelte után milyen reménytelen vállalkozás egy levelet megtalálni az irattárban. Ez az adathalmaz nem tekinthető adatbázisnak, ahhoz hogy adatbázis legyen nem elegendő a nagyszámú adat. Az adathalmaz csak akkor válik adatbázissá, ha az valamilyen rend szerint épül fel, mely lehetővé teszi az adatok értelmes kezelését. Természetesen ugyanazon adathalmazból többféle rendszerezés alapján alakíthatunk ki adatbázist. Például egy könyvtárban a könyveket rendezhetnénk a könyvek mérete vagy akár a szerző vagy szerzők testsúlya alapján. Ez már egy rendszert ad az adatok tárolásához. Íly módon minden könyv helye meghatározott. De bizonyára nehéz helyzetben lennénk, ha szerző és cím alapján próbálnánk meg előkeresni egy könyvet. Az adatok tárolásába bevitt rendszernek alkalmasnak kell lennie a leggyakrabban előforduló igények hatékony kielégítésére. Az adatbázisok mellé egy adatbáziskezelő rendszer (DBMS) is járul, mely az adatbázis vagy adatbázisok üzemeltetését biztosítja. Hagyományos adatbázis esetén ez a kezelő személyzet intelligenciájának része, elektronikus adatbázisok esetén pedig valamilyen szoftver.
1.2. Történelmi áttekintés Azóta rendelkezünk adatbázisokkal, mióta írásban vagyunk képesek rögzíteni adatokat. Ez az ókorban történhetett akár kőtáblákra vagy papirusz tekercsekre. Az adatbázisok fejlettebb formái később a kartoték rendszerek lettek, melyek a számítógépek megjelenéséig az alapvető adatbázis rendszerek voltak. A számítástechnika hőskorában az 50-es 60-as években az adatok tárolása még lyukszalagon, lyukkártyán történt, az adatok közvetlenül nem voltak elérhetők a számítógép számára. A mágneses háttértárolók elterjedésével az adatok tárolása egyszerűbbé, elérésük hatékonyabbá vált. Ezekben az időkben még nem léteztek univerzális módszerek illetve rendszerek, melyek segítségével az adatbázisokkal kapcsolatos problémák nagy része általánosan megoldható lett volna. A számítógépek fejlődésével együtt fejlődtek a programozói lehetőségek is. Az első számítógépeken csak a gépi kód (a bináris formában kiadott utasítások a mikroprocesszornak) állt rendelkezésre. Ezt első generációs programnyelvnek nevezzük. Ezt követték a második generációs (assembler) nyelvek, melyekben a gépi kód helyett úgynevezett mnemonikok és szimbólumok alkalmazhatók. Az első illetve második generációs programnyelvekben még nem készültek komoly adatbáziskezelő alkalmazások. Ezekre egyrészt a magas szintű nyelvek (3. generációs program nyelvek) COBOL, FORTRAN stb., másrészről a lemezes operációs rendszerek kialakulásáig kellett várni. Ekkor már komoly adatbázis alkalmazások születtek, melyek egyedi problémák megoldására voltak alkalmasak. Az adatbázisok méretének és számának gyors növekedése következtében az egyedi alkalmazások létrehozása fárasztó és időrabló feladattá vált, ezért a programfejlesztők törekedtek az adatbáziskezelés általános formában történő megfogalmazására. Ennek eredményeként jöttek létre az adatbázis kezelő rendszerek (DBMS) és a negyedik generációs nyelvek (4GL). Az adatbázis kezelő rendszerek számos eszközt nyújtanak az interaktív adatbevitel, menük létrehozása terén, melyek kialakítása a harmadik generációs nyelvekben sok sok oldal kód leírásával lenne csak lehetséges. A szabványos eszközök bevezetésével nem csak a programozói munka csökkent le, hanem az egységes felhasználói felület kialakítására késztetik a programozókat. Az objektum orientált programozási nyelvek térhódításával az adatbázis kezelő rendszerekkel kapcsolatos kutatások is az objektum orientált megközelítés irányába nyitott. A kereskedelmi forgalomban kapható adatbázis kezelők azonban még nem az objektumorientált megközelítésre épülnek.
1. generációs nyelvek Gépi kódú programozás 8C C0 8E D8 2. generációs nyelvek Assembler nyelvek 3. generációs nyelvek 4. generációs nyelvek 5. generációs nyelvek Objektum orientált nyelvek Imperatív nyelvek: Algol, FORTRAN, C, Pascal, Basic Logikai programozási nyelvek: Prolog, Lisp 1.3. Adatbáziskezelők szerepe, célja SmallTalk, C++, Java, Visual Basic MOV AX,ES MOV DS,AX var i, s:integer; s := 0; for i:=1 to 10 do s := s + i; (+ (cadr p1) (cadr p2) (/ 750 2)) class Complex { protected: double real, img; public: Complex(); ~Complex(); Complex& operator+(complex& a); } Manapság nem elégszünk meg egy adatbázissal, mely az adatokat rendszerezve tárolja, hanem az adatok kezeléséhez szükséges eszközöket is az adatbázis mellé képzeljük. Az így kialakult program rendszert adatbázis kezelő rendszernek (DBMS Database Management System) nevezzük. Egy DBMS egyszerűbb és gyorsabb megoldást kínál az űrlapokon alapuló alkalmazások kidolgozásában, az adatbázis adatokon alapuló jelentések készítésében. A DBMS-ek megváltoztatták a végfelhasználók adatnyerési lehetőségeit az egyszerű lekérdezési nyelvek bevezetésével. A lekérdező nyelvek lehetőséget nyújtanak a nem számítógépes szakemberek számára is tetszőleges lekérdezés gyors végrehajtására. A programozási eszközök mellett az operációs rendszerek illetve azoknak a háttértárakat kezelő része is komoly fejlődésen ment keresztül. Nem volt már szükség a fizikai fájlszerkezet pontos ismeretére, ezt az operációs rendszer illetve az adatbáziskezelő rendszer elfedte a felhasználó és a programozó elől is. Ma már az operációs rendszerek is lehetőséget nyújtanak szekvenciális, indexelt és közvetlen elérésű adatállományok létrehozására. (Ez nem igaz a PC DOS és UNIX operációs rendszerekre.) Az operációs rendszerek fájl kezelői azonban nem értelmezik a fájlok tartalmát, a fájlokat kezelő programoknak kell ismernie az adatok szerkezetét és az adatszerkezetben bekövetkezett változás, akár csak bővülés, esetén a változást a programokon is át kell vezetni. Az adatbázisokban gyakran előfordulnak olyan típusú adatok, melyeket az operációs rendszer vagy a harmadik generációs programnyelvek közvetlenül nem kezelnek, például dátum, időpont, pénzegység stb.
Az adatbáziskezelők az operációs rendszerekhez hasonlóan számos eszközt szolgáltatnak a gyakran előforduló problémák megoldására, de míg az operációs rendszerek a perifériák kezelésére és a fájlok használatára adnak lehetőséget, addig a DBMS-ek eszközei egy magasabb szintű absztrakcióra épülve az adatok logikai szintű elérését támogatják a rekordokon belüli bájt poziciók helyett, továbbá eszközöket tartalmaznak az adatok űrlap szintű kezelésére illetve jelentések és menük készítésére. Az adatbáziskezelők három alapvető feladat körre alapozódnak, melyek mindegyike a számítógépes hardvertől és környezettől való függetlenséggel kapcsolatos. Az általános cél az, hogy inkább az ember gondolkodásához, munkastílusához hozza közelebb az információs rendszer kidolgozását, minthogy az embereket kényszerítse a számítógép stílusú gondolkozásra. Függetlenség az aktuális hardver konfigurációtól Az adatbáziskezelő rendszer rejtse el a felhasználó és a fejlesztő elől is a számítógépek és azok perifériái között jelentkező különbségeket. Például a fejlesztőnek se kelljen törődnie a fizikai szintű adattárolással, ne kelljen közvetlenül lemez blokkokra, cilinderekre hivatkoznia. Az egyes megjelenítő eszközökön (képernyő, nyomtató) - azok típusától függetlenül - az alkalmazás ugyanúgy használható legyen és azonos eredményt szolgáltasson. Ily módon az egyik géptípusra kifejlesztett alkalmazás bármelyik, az adatbáziskezelő által támogatott hardver illetve szoftver környezetben módosítás nélkül használható. Függetlenség az adatelérés módjától Az egyes operációs rendszerek a fájlokra többfajta adatelérési módot (szekvenciális, indexelt, véletlen) kínálnak az alkalmazások készítőinek. Ez azonban maga után vonja, hogy a fejlesztőnek ezt figyelembe kell vennie és az egyes adatállományokat tárolási módjuknak megfelelően kell kezelni. Az adatbáziskezelőtől viszont elvárjuk, hogy az adatok tárolásáról és elérési módjáról maga rendelkezzék. A felhasználó vagy a fejlesztő számára csak a kérdés megfogalmazása és nem az eredmény előállítási módja legyen a feladat. Egy példával ezt úgy szemléltethetnénk, hogy a főnök is csak azt mondja a titkárnőjének, hogy kéri a múlt havi jelentéseket a raktárkészletről, de nem ad útmutatást az adatok elérési módjáról, mivel azt a titkárnő ismeri. Az adatbáziskezelőtől nem csak azt várjuk el, hogy önállóan gondoskodjék az adatok eléréséről, hanem azt is hogy ha több alternatíva is létezik azok közül az optimálisat válassza ki. Függetlenség az adatstruktúráktól Az adatbázisok szerkezetében beálló változások minél kevesebb módosítást okozzanak az alkalmazásokban. Például, ha az adatbázisokat új adatokkal kell bővíteni, akkor azokat a régebben elkészített alkalmazásokat, melyek ezeket az adatokat nem használják, változtatás nélkül tovább használhassuk. Az adatbáziskezelőket használva nagyobb hatékonyság érthető el az alkalmazások fejlesztésében. Így ugyanaz a feladat kisebb fejlesztőcsoporttal vagy rövidebb idő alatt oldható meg.
1.4. Különböző adatbázis modellek Az adatbáziskezelők fejlődése során többfajta logikai modell alakult ki, melyek főként az adatok közötti kapcsolatok tárolásában térnek el egymástól. A három alapvető modell a hierarchikus, a háló és a relációs modell. Ezek közül manapság a DOS/Windows 3.x/Windows 95/NT illetve UNIX operációs rendszerekben kizárólag a relációs modellre épülő adatbáziskezelőket használnak. Ezért itt csak röviden ismertetjük a másik két modellt. 1.4.1. Hierarchikus adatbázis modell A hierarchikus modell volt a legelső az adatbáziskezelőkben és egyben a leginkább korlátozott. Például az IBM IMS adatbáziskezelő rendszer alkalmazta ezt a modellt. A neve is utal rá, hogy az adatokat egy hierarchiában kell elrendezni. Ezt egy fa szerkezettel tehetjük szemléletessé. 1.1 ábra Hierarchikus adatmodell Az adatbázis több egymástól független fából állhat. A fa csomópontjaiban és leveleiben helyezkednek el az adatok. A közöttük levő kapcsolat, szülő gyermek kapcsolatnak felel meg. Így csak 1:n típusú kapcsolatok képezhetők le segítségével. Az 1:n kapcsolat azt jelenti, hogy az adatszerkezet egyik típusú adata a hierarchiában alatta elhelyezkedő egy vagy több más adattal áll kapcsolatban. A hierarchikus modell természetéből adódóan nem ábrázolhatunk benne n:m típusú kapcsolatokat (lásd a háló modellt). Emellett további hátránya, hogy az adatok elérése csak egyféle sorrendben lehetséges, a tárolt hierarchiának megfelelő sorrendben. A hierarchikus adatmodell alkalmazására a legkézenfekvőbb példa a családfa. De a főnökbeosztott viszonyok vagy egy iskola szerkezete is leírható ebben a modellben. Az iskola esetén többféle hierarchia is felépíthető. Egyrészt az iskola több osztályra bomlik és az osztályok tanulókból állnak. Másrészt az iskolát az igazgató vezeti, a többi tanár az ő beosztottja és a tanárok egy vagy több tantárgyat tanítanak.
1.2 ábra Iskola hierarchikus felépítése a diákok szemszögéből 1.4.2. Hálós adatbázis modell 1.3 ábra Iskola hierarchikus felépítése a tanárok szemszögéből A hálós adatmodell esetén az egyes azonos vagy különböző összetételű adategységek (rekordok) között a kapcsolat egy gráffal írható le. A gráf csomópontok és ezeket összekötő élek rendszere, melyben tetszőleges két csomópont között akkor van adatkapcsolat, ha őket él köti össze egymással. Egy csomópontból tetszőleges számú él indulhat ki, de egy él csak két csomópontot köthet össze. Azaz minden adategység tetszőleges más adategységekkel lehet kapcsolatban. ebben a modellben n:m típusú adatkapcsolatok is leírhatók az 1:n típusúak mellett. A hierarchikus és a hálós modell esetén az adatbázisba fixen beépített kapcsolatok következtében csak a tárolt kapcsolatok segítségével bejárható adat-visszakeresések oldhatók meg hatékonyan (sok esetben hatékonyabban mint más modellekben). További hátrányuk, hogy szerkezetük merev, módosításuk nehézkes. 1.4 ábra Hálós adatmodell
Az iskolai példánál maradva az egyes diákok illetve tanárok közötti kapcsolat hálós modellben írható le. Minden diákot több tanár tanít és minden tanár több diákot tanít. 1.4.3. Relációs adatbázis modell A relációs az egyik legáttekinhetőbb és a 80-as évektől kezdve a legelterjedtebb adatmodell. Ebben a modellben az adatokat táblázatok soraiban képezzük le. A legfontosabb eltérés az előzőekben bemutatott két modellhez képest az, hogy itt nincsenek előre definiált kapcsolatok az egyes adategységek között, hanem a kapcsolatok létrehozásához szükséges adatokat tároljuk többszörösen. Ezzel egy sokkal rugalmasabb és általánosabb szerkezetet kapunk. A relációs modellt részletesen tárgyaljuk a következőkben. 2. Relációs adatbázisok, alapfogalmak A relációs adatmodell kidolgozása Codd nevéhez fűződik (1971). Azóta fontos szerepet játszik az adatbáziskezelők alkalmazásában. A relációs modell előnyei a következők: A relációs adatszerkezet egyszerűen értelmezhető a felhasználók és az alkalmazás készítők számára is, így ez lehet közöttük a kommunikáció eszköze. A logikai adatmodell relációi egy relációs adatbáziskezelő rendszerbe módosítások nélkül átvihetők. A relációs modellben az adatbázistervezés a normál formák bevezetésével egzakt módon elvégezhető (ld. 3. fejezet). 2.1. Relációk és a velük kapcsolatos alapfogalmak A reláció nem más mint egy táblázat, a táblázat soraiban tárolt adatokkal együtt. A relációs adatbázis pedig relációk és csak relációk összessége. Az egyes relációkat egyedi névvel látjuk el. A relációk oszlopaiban azonos mennyiségre vonatkozó adatok jelennek meg. Az oszlopok névvel rendelkeznek, melyeknek a reláción belül egyedieknek kell lenniük, de más relációk tartalmazhatnak azonos nevű oszlopokat. A reláció soraiban tároljuk a logikailag összetartozó adatokat. A reláció sorainak sorrendje közömbös, de nem tartalmazhat két azonos adatokkal kitöltött sort. Egy sor és oszlop metszésében található táblázat elemet mezőnek nevezzük, a mezők tartalmazzák az adatokat. A mezőkben oszloponként különböző típusú (numerikus, szöveges stb.) mennyiségek tárolhatók. A reláció helyett sokszor a tábla vagy táblázat, a sor helyett a rekord, az oszlop helyett pedig az attribútum elnevezés is használatos.
2.1 ábra Relációk elemei Például egy személyi adatokat tartalmazó reláció a következő lehet: Személy Személyi szám Név Város Foglalkozás 1 650410 1256 Kiss lászló Győr kőműves 2 781117 0131 Nagy Ágnes Szeged tanuló 1 610105 1167 Kiss László Budapest lakatos 2.2 ábra Személyi adatok relációja Az előző relációból a személyi szám oszlopot elhagyva relációnak tekinthető-e a táblázat? Mivel nem zárható ki, hogy két azonos nevű és szakmájú személy éljen egy településen belül a személyi szám nélkül két azonos sor is szerepelhetne, mely a relációban nem megengedett. A reláció oszlopainak elnevezésére célszerű a tartalomra utaló elnevezést használni még akkor is, ha ez esetleg több gépeléssel is jár. Ehhez álljon itt a következő példa: R A B C 1206 389 274 967 2012 65 12 654 712 Anyag kód készlet egységár 1206 389 274 967 2012 65 12 654 712 2.3 ábra Példa az oszlopok helytelen és helyes elnevezésére Az előző két reláció ugyanazokat az oszlopokat tartalmazza, de a bal oldali esetben további feljegyzésekre van szükség az egyes oszlopok tartalmának leírására. A relációktól általában megköveteljük, hogy ne tartalmazzanak más adatokból levezethető vagy kiszámítható információkat. Például az anyag relációban (2.3 ábra) fölösleges lenne egy érték oszlopot is tárolni, mivel ez az adat a készlet és az egységár szorzataként kiszámítható a rendelkezésre álló adatokból. Hasonlóképpen a személyi szám mellett nincs értelme külön a születési dátumot nyilvántartani, mert az része a személyi számnak, abból előállítható.
3. Adatbázistervezés Az adatbázistervezés egy folyamat, mely több lépésből tevődik össze. Először az adatbázisban leképezendő rendszert elemzésnek vetjük alá és meghatározzuk a tárolandó adatok körét, azok egymásközötti kapcsolatait és az adatbázissal szemben felmerülő igényeket. Ezután következik a rendszer tervezé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. 3.1 ábra A tervezés lépései A tényleges tervezés ismertetése előtt néhány újabb fogalmat kell bevezetni - funkcionális függőség, reláció kulcs, redundancia, - melyek segítségével a tervezés módszertana egyszerűbben magyarázható. 3.1 Adatok közötti funkcionális kapcsolat 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 vagy pedig egy diagrammal.
3.2 ábra Funkcionális függőség diagram 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. Néhány évvel ezelőtt a SZEMÉLYI_SZÁM - > AUTÓ_TIPUS funkcionális függőség igaz volt, mert mindenkinek csak egy autója lehetett. Ma azonban ez már nem állja meg a helyét. 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 attribútum is állhat. Például az AUTÓ_RENDSZÁM -> TIPUS, 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. Ezt diagrammal is ábrázolhatjuk. 3.3 ábra Funkcionális függőség több meghatározott értékkel Az is előfordulhat, hogy két attribútum 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éget megengedő országokban nem teljesül. A funkcionális függőség bal oldalán több attribútum is megjelenhet, melyek együttesen határozzák meg a jobb oldalon szereplő attribútum é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 attribútumok között: HELY, IDŐPONT -> HŐMÉRSÉKLET. A fenti összefüggést az alábbi diagrammal is jelölhetjük:
3.4 ábra Funkcionális függőség összetett meghatározóval 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 attribútum. Például a RENDSZÁM, TÍPUS -> SZÍN 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 színé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=({attribútumok},{funkcionális függőségek listája}) Például: Az alábbi táblázat formában adott reláció Személyi szám Név Munkahely 3.5 ábra Reláció táblázatos megadása matematikai jelöléssel a következő formában 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.
3.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 mindegyik 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 attribútumhoz egy másik attribútum 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 attribútum értékéből egynél több további attribútum értéke következik. Az előző példát bővítve: SZEMÉLYI_SZÁM ->> SZAKMA, OKLEVÉL_KELTE 3.6 ábra Többértékű függőség diagram 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. 3.3 Reláció kulcs fogalma A reláció kulcs a reláció egy sorát azonosítja egyértelműen. A reláció - definíció 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ő attribútumok egyetlen részhalmaza sem alkot kulcsot a kulcsban szereplő attribútumok értéke nem lehet definiálatlan (NULL)
A definiálatlan (NULL) értékek tárolását a relációs adatbázis kezelők speciálisan oldják meg. Numerikus értékek esetén a NULL érték és a 0 nem azonos. Egy relációban tartsuk nyilván az osztály tanulóinak személyi adatait Diák Személyi szám Születési év Név 3.7 ábra Reláció kulcs SZEMÉLY_ADATOK=({ SZEMÉLYI_SZÁM, SZÜL_ÉV, NÉV}). A SZEMÉLYI_ADATOK relációban a SZEMÉLYI_SZÁM attribútum kulcs, mert nem lehet az adatok között két különböző személy azonos személyi számmal. A születési év vagy a név nem azonosítja egyértelműen a reláció egy sorát mivel ugyanazon a napon is született tanulók vagy azonos nevűek is lehetnek az osztályban. Vajon a személyi szám és a születési év kulcsa-e a személyi adatok relációnak? Együtt a reláció egy sorát azonosítják, de nem tesznek eleget a kulcsokra vonatkozó azon feltételnek, hogy a bennük szereplő attribútumok részhalmaza nem lehet kulcs. Ebben az esetben a személyi szám már kulcs, így bármelyik másik attribútummal kombinálva már nem alkothat kulcsot. Előfordulnak olyan relációk is, melyekben a kulcs több attribútum é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)} Napló Személyi szám Tantárgy Dátum Osztályzat 3.8 ábra reláció összetett kulccsal 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 analizisé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)} Konzultáció Tanár Időpont Diák 3.9 ábra Reláció több kulccsal 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 attribútumok kulcsot alkotnak, de ugyanilyen okból kifolyólag a DIÁK, IDŐPONT attribútumok is kulcsot alkotnak. Vegyük észre azt, hogy a kulcsok nem önkényes döntések következtében alakulnak ki, hanem az adatok természetéből következnek, mint a funkcionális vagy a többértékű függőség. A relációban külső kulcsot vagy kulcsokat is megkülönböztetünk. Ezek az attribútumok 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. 3.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 esetleg 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 Kiss Péter Adatbázis kezelés 64 12 Nagy Andrea Matematika 32 8 Szabó Miklós Adatbázis kezelés 64 4 Kovács Rita Matematika 32 5 Angol 48 3.10 ábra Redundanciát tartalmazó reláció 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ó papír 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 3.11 ábra Adatok többszörös tárolása 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.
Levezetett adatokat tartalmazhat egyetlen reláció is abban az esetben, ha egyes attribútumok értéke egyértelműen meghatározható a többi attribútum 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} 3.5 Redundancia megszüntetése, a relációk normál alakjai 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. 3.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ö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 Szakkörök Szakkör Tanár Diák Osztály Számítástechnika Nagy Pál Kiss Rita III.b Számítástechnika Nagy Pál Álmos Éva II.c Video Gál János Réz Ede I.a Video Gál János Vas Ferenc II.b 3.13 ábra Nem normál formájú reláció és első normál formája Annak eldöntése, hogy egy attribútumot egyszerűnek vagy összetettnek tekintünk nem mindig egyértelmű, az adatok felhasználásától is függ. A döntéseink során, hogy egy vagy több attribútumot tervezünk az adat tárolására, tartsuk szem előtt egyszerűbb több oszlopból egyet csinálni, mint egy oszlop tartalmát több részre vágni. Például egy vagy két attribútumban tároljuk a személyek vezeték és keresztnevét. Amennyiben a nevek között nem akarunk külön-külön kereszt és vezetéknév szerint keresni, akkor elfogadható lehet az egy mezőben tárolás. 3.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 forma 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 attribútuma teljes funkcionális függőségben van az összes reláció kulccsal
Konferencia Terem Időpont Előadás Férőhely B 10:00 Mitológia 250 A 8:30 Irodalom 130 B 11:30 Szinház 250 A 11:00 Festészet 130 A 13:15 Régészet 130 Konferencia Terem Időpont Előadás B 10:00 Mitológia A 8:30 Irodalom B 11:30 Szinház A 11:00 Festészet A 13:15 Régészet Termek Terem Férőhely A 130 B 250 3.14 Első normál formájú reláció és második normál alakú dekompozíciója Az előző ábrán látható első reláció a következő matematikai formában írható le KONFERENCIA = ({TEREM, IDŐPONT, ELŐADÁS, FÉRŐHELY}, {TEREM, IDŐPONT-> ELŐADÁS, TEREM->FÉRŐHELY}). A reláció attribútumai között két funkcionális függőség adható meg, minden egyes teremben egyidőben csak egy előadás lehet és minden terem befogadóképessége adott. A reláció kulcsa a TEREM, IDŐPONT attribútumok, ezek a reláció elsődleges attribútumai. A másodlagos attribútumok (ELŐADÁS, FÉRŐHELY) közül a FÉRŐHELY csak a reláció kulcs egy részétől függ, ezért nincs második normál formában. A felbontás után keletkezett két reláció már második normál formában van. KONFERENCIA = ({TEREM, IDŐPONT, ELŐADÁS}, {TEREM, IDŐPONT-> ELŐADÁS}) TERMEK = (TEREM, FÉRŐHELY}, {TEREM-> FÉRŐHELY}). Minden nem elsődleges attribútum teljes funkcionális függőségben van a reláció kulccsal (TEREM, IDŐPONT illetve TEREM). Azok a relációk, melyek reláció kulcsa csak egy attribútumból áll, mindig második normál formában vannak, ekkor ugyanis nem lehetséges, hogy csak a reláció kulcs egy részétől függjön egy nem elsődleges attribútum.
3.15 ábra Függőségi diagram Nézzünk egy másik példát is a második normál forma feltételeit megsértő relációra. Egy épület energia gazdálkodásának ellenőrzésére az egyes helységekben rendszeresen megmérik a hőmérsékletet. A mérési eredmények értékeléséhez nyilvántartjuk az egyes helységekben található radiátorok számát is. Hőmérsékletek Terem Időpont Hőmérséklet Radiátor 213 98.11.18 23 2 213 98.11.24 22 2 213 98.12.05 21 2 214 98.12.05 21 3 214 98.12.15 20 3 Konferencia Terem Időpont Hőmérséklet 213 98.11.18 23 213 98.11.24 22 213 98.12.05 21 214 98.12.05 21 214 98.12.15 20 Termek Terem Radiátor 213 2 214 3 A redundanciát ismét a táblázat két részre bontásával tudjuk megszüntetni.
3.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 attribútumokkal állnak kapcsolatban. Ezt a lehetőséget szünteti meg a harmadik normál forma. 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 attribútumok között. Ezt ismét egy példa segítségével mutatjuk be. Szakkörök Szakkör Tanár Születési év Képzőművész Sár Izodor 1943 Iparművész Sár Izodor 1943 Karate Erős János 1972 Szakkörök Szakkör Tanár Képzőművész Sár Izodor Iparművész Sár Izodor Karate Erős János Tanárok Tanár Születési év Erős János 1972 Sár Izodor 1943 3.16 ábra Második normál formájú reláció és harmadik normál formájú dekompozíciója 3.17 ábra Függőségi diagram A példában szereplő felső reláció második normál formában van, csak egy attribútumból áll a reláció kulcs és mindkét nem elsődleges attribútum teljes funkcionális függőségben van a reláció kulccsal. A reláció mégis tartalmaz redundanciát, mivel ugyanannak a tanárnak a születési éve többször is szerepel benne. A születési év funkcionálisan függ a tanár név attribútumtól. SZAKKÖRÖK = ({SZAKKÖR, TANÁR, SZÜLETÉSI ÉV}, {SZAKKÖR-> TANÁR, SZÜLETÉSI ÉV, TANÁR->SZÜLETÉSI ÉV}). A felbontás után a nem elsődleges attribútumok közötti függőséget kivettük az eredeti relációból: SZAKKÖRÖK = ({SZAKKÖR, TANÁR}, {SZAKKÖR->TANÁR}) TANÁROK = ({TANÁR, SZÜLETÉSI ÉV}, {TANÁR->SZÜLETÉSI ÉV}). Minden olyan reláció, mely második normál formában van és nincs vagy csak egy nem elsődleges attribútuma van, a harmadik normál forma feltételeit is kielégíti.