Adatbázisok – adatmodellezés. (Az adatbázis-kezelő rendszerek feladata, tulajdonságai, egyed-kapcsolat modell, relációs adatmodell, az E/K diagram átalakítása relációs adatmodellbe. Adatbázisok tervezése, anomáliák, funkcionális és többértékű függőségek, implikációs probléma, attribútumhalmazok lezárása, dekompozíciók tulajdonságai, veszteségmentesség, függőségőrzés ellenőrzése, Boyce-Codd normálforma, 3NF, 4NF, dekomponáló algoritmusok.)
Az adatbázis-kezelő rendszerek feladata, tulajdonságai adatbázis : nagy mennyiségű adatok valamilyen rendezett tárolására alkalmas eszköz, melyhez általában DBMS is társul adatbázis-kezelő rendszer (DBMS): hálózatos környezetben több felhasználó számára biztosít adatbázisokhoz való hozzáférést (tulajdonképpen a szoftver és az adatbázis alkotja)
Az adatbázis-kezelő feladatai: • Konkurens hozzáférés támogatása Az osztott erőforrás-használat problémáját megoldja. (Például egyszerre többen szeretnének ugyanahhoz az adathoz hozzáférni – olvasni, írni azt. Hibákat eredményezhet!) • Nagymennyiségű adatok hatékony kezelése o optimális válaszidő A lekérdezés eredményére nem kell „sokat” várni o redundancia elkerülése Egyazon adatelem többszöri, felesleges megismétlése. • Integritásőrzés Az adatbázis megfelel a saját, belső törvényszerűségeinek (pl.: Füzesi Zsolt nem lehet -20 éves) • Védelem Rábízzuk az adatainkat a számítógépre, ekkor kezelje biztonságban azokat, pl.: készüljön fel minden lehetőségre (adatvesztés elkerülése a cél)
ANSI/SPARC architektúra
/három szintű architektúra/ absztrakt DBMS leírása 3 szinten • Külső szint Különböző felhasználók különbözőképpen látják az adatokat. Nem kell minden felhasználónak az egész adatbázist látni
(nézettáblák) , csak azt, ami érdekes az adott felhasználó számára • Koncepcionális szint Az egész adatbázis logikai struktúráját írja le: tartalmaz minden entitást, attribútumot és a kapcsolatokat. Itt valósulnak meg a korlátozások (integritás), innen származtathatóak a nézetek. Független a tárolástól! • Fizikai szint / belső szint Az adatok fizikai tárolását írja le, pl.: indexek , titkosítás, az adat szerkezete
Relációs adatbázisok, alapfogalmak
Codd – 1970. A reláció = 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. A relációnak van neve, egy relációs adatbázisban nem lehet kettő relációnak azonos. A relációnak vannak oszlopai, azoknak van nevük… Mezőnek nevezzük a sor és oszlop metszéspontjában lévő adatot. A sorok sorrendje nem rögzített Oszlop = attribútum, melynek van típusa. A relációs adatbázisban definiálhatunk megszorításokat.
Egyed-kapcsolat modell
Ez egy koncepciós adatmodell, azaz független az őt megvalósító adatbázis-kezelőtől és az adatmodelltől. Az adatbázis korlátozását, struktúráját jelzi. Részei: • egyedek Amiről adatot szeretnénk tárolni (pl.: személy) o erős entitás Létezése független minden más entitástól. Általában van egy azonosító attribútumuk. (pl.: hallgató: hallgató_id, név, cím) o gyenge entitás Létezése függ más entitások létezésétől. 1. ábra Tulajdonosnak nevezzük azt az entitást, melytől a gyenge entitás létezése függ. (pl.: hozzátartozó: hozzátartozó_id, alkalmazott_id, név) • attribútumok
az egyedeket az attribútumaikkal írjuk le, ezek a tulajdonságai (személy: azonosító, név, lakcím, ..) ahol a kulcsot az ábrázolásnál kiemeljük o
egyszerű attribútumok (email)
o
összetett attribútumok (cím: ország, város, utca, házszám)
o
számított attribútum (olyan attribútum amelynek értéke kiszámolható más hozzákapcsolódó attribútumok értékeiből, pl.: hallgató: azonosító, név, felvett kredit)
2. ábra
Kulcsokról: Azonosítók is lehetnek egyszerűk és összetettek. (egyszerű: személyi szám, név, cím… összetett: járat, dátum, indulás, érkezés) Ha az azonosító túl összetett, készítsünk egyszerűt! (azonosító, járat, dátum, indulás, érkezés) kulcs : azonosít egy egyedet szuperkulcs : minimális kulcs, ha egy attribútumot elveszünk, már nem kulcs, nem azonosít idegen kulcs = Mező, amely egy másik tábla elsődleges kulcsára hivatkozik • kapcsolatok Értelmes összefüggés két egyed között. A 3. ábra kapcsolatnak vannak attribútumai, ezek olyat tulajdonságok, melyek egyik entitásra sem jellemzőek. A kapcsolat foka azt mutatja meg, hány egyed vesz részt a kapcsolatban.(unary, 4. ábra binary, trenary, ez binary) (az unary az rekurzív, pl. alkalmazpttak esetén „a főnöke” kapcsolat) Típusai (pl.: személy – személyi szám)
o
1:1, egy az egyhez,
o
1:n , egy a többhöz, (pl.: Zsolti – sörök, melyeket szeret)
o n:m, több a többhöz, (pl.: hallgató – előadás)
E/K diagram átalakítása relációs adatmodellbe
Egyértelmű megfeleltetése végrehajtása (egyed – sor, az attribútumai – oszlopok). 1. ábra : a hozzátartozó táblájába bevesszük a dolgozó azonosítóját, mint egy idegenkulcsot. 2. ábra : a diák tábla a következő : [törzsszám, név, cím, email], ahol a törzsszám jó azonosító, ha egyedi 4. ábra : egy összekapcsoló tábla elkészítése, mely tartalmazza mindkét egyed azonosítóját, és a speciális adatokat. Elvégez : [hallgato_id, kurzus_id, oktató_id, dátum, osztályzat]
Adatbázisok tervezése
Ez többnyire olyan logikai tervezést jelent, ahol bizonyos követelményeknek kell megfelelni. Ehhez nincs előre definiált módszer, csak útmutató alapelvek + sok tapasztalat. • a leírandó világot az adatszerkezet attribútumai megfelelő részletességében jellemezzék • adat ne vesszen el • redundancia • hatékony lekérdezések készítése • egyed egyértelmű azonosíthatósága Egy relációs adatbázisban akkor léphet fel anomália, ha az redundáns (azaz 1 adatot több helyen tárolunk) • Beszúrási anomália [Gipsz Jakab, Budapest, 06203456789] felveszünk egy újabb telefonszámot [Gipsz Jakab, Budapest, 06307893456] => a redundáns tárolás miatt anomália lép fel, nem tudjuk melyik az igazi lakcíme • Törlési anomália ha az egyik sort eltávolítjuk a fentiek közül, nem tudjuk, hogy a helyes maradt meg vagy sem • Módosítási anomália Gipsz Jakab címe megváltozik, de csak 200 sorban írjuk át, így a 201. hibásan marad bent
Funkcionális és többértékű függőségek:
Az egyed B tulajdonsága funkcionálisan függ A-tól, ha A egy értékéhez pontosan egy érték tartozik B-ből, vagyis A funkcionálisan meghatározza B-t. • A → B B funkcionálisan függ A-tól (irányítószám → város) • A → B,C B és C funkcionálisan függ A-tól • A+B → C C funkcionálisan függ A és B-től (x és y koordináta → 2Dpont :) Függőségek típusai: • Teljes funkcionális függőség B funkcionálisan függ az A={A1,A2,…,An} tulajdonsághalmaztól, de nincs egyetlen olyan részhalmaza sem A-nak, amely funkcionálisan meghatározná B-t • Részleges funkcionális függőség B funkcionálisan függ az A={A1,A2,…,An} tulajdonsághalmaztól, de van olyan részhalmaza A-nak, amely funkcionálisan meghatározza B-t. • Tranzitív funkcionális függőség Ha B funkcionálisan függ az Atól, és C funkcionálisan függ B-től, akkor C tranzitíven függ A-tól
ARMSTRONG AXIÓMÁK Jelölés: α, β, γ halmazok.
a reláció attribútumaiból képezett tetszőleges
Reflexív: Bármely β ⊆ α esetén α→ β Bővíthető: Ha α→β, akkor αγ→βγ Tranzitív: Ha α→β és β→γ akkor α→γ Tétel: Az Armstrong axiómák helyesek és teljesek Helyesség: ha egy F függőségi halmazból az axiómák felhasználásával levezetünk egy újabbat, annak minden olyan reláció, amely F-nek eleget tesz, eleget tesz a levezetettnek is. Teljesség: Ha egy funkcionális függőség F-nek következménye, akkor az F-ből az Armstrong axiómák felhasználásával levezethető.
Implikációs probléma
Függőségi halmaz lezártja
Az F funkcionális függőségi halmaz lezártja F+ azokból a funkcionális függőségekből áll, melyek F-ből az Armstrong axiómák segítségével levezethetők.
Attribútumhalmazok lezárása
Egy adott függőségi halmaz szerint: {A1, A2, ... An}+={B| ∃ A1, A2, ... An →B, amely S-ből következik} Algoritmus (bemenet egy X attribútumhalmaz, és egy F függőségi halmaz, kimenet az X attribútumhalmaz F halmaz szerinti lezártja, X+ ): 1. X(0) = X 2. CIKLUS >> ha F-ben van olyan függőség, hogy Y→Z, ahol A részhalmaza a Z-nek, Y részhalmaza az X(i)-nek a. akkor X(i+1) = X(i) + A 3. kilépünk X(i)-vel Mi ennek az értelme? (a szerző megjegyzése: semmi) Miért jó? >>> kulcskeresés, X halmaz akkor kulcs, ha a lezártja az összes attribútum.
Normálformák • 0 NF Egy táblázat, semmi megkötés. • 1 NF A reláció minden sorában pontosan egy elemi (atomi) attribútumérték áll, tehát nincsenek benne többértékű mezők, és minden sora különböző (azaz van valamilyen kulcsa). Általában sok redundanciát tartalmaz. [dátum, vevőkód, termék_id, vevő neve, terméknév, db ] • 2 NF 1. normálformában van, és minden másodlagos tulajdonsága teljesen függ a kulcstól, vagyis nincs benne részleges funkcionális függőség. (ne legyen részkulcstól való függés) pl.: [dátum, vevőkód, termék_id, vevő neve, terméknév, db ] helyett [vevőkód,vevőnév], [rendelés_id,dátum, vevőkód,termék_id, termék név] Módszer: A relációt két relációra bontjuk a sértő függőség szerint. Ha szükséges, tovább folytatjuk. • 3 NF A reláció harmadik normálformában (3NF) van, ha 2NF-ben van, és egy másodlagos attribútum sem függ tranzitívan a reláció egyetlen kulcsától sem. pl.: [rendelés_id,dátum, vevőkód,termék_id], [termék_id, termék név]
• Boyce-Codd NF
Az R reláció BCNF-ben van, ha minden α→β funkcionális függőségre α szuperkulcs. pl.: OKTAT(tanar, diak, targy) nem BCNF • 4 NF Egy R reláció negyedik normálformában van, ha az A1,A2,...An → B1,B2,...Bm „nem triviális” többértékű függőség fennáll, akkor az {A1, A2..., An} szuperkulcs.
Azaz, ha egy reláció 4NF-ben van, akkor minden nem triviális többértékű függőség valójában olyan funkcionális függőség, amelynek a baloldala szuperkulcs. Kapcsolatok: 4 NF -ből következik a BCNF, amiből következik 3 NF. Az adatbázistervezés célja a BCNF-re hozás, ha ez nem valósítható meg, akkor 3NF-re hozás: ha BCNF-ben nem tudjuk biztosítani a függőségőrzést, akkor a 3NF-re bontást válasszuk, mert így mind a veszteségmentesség, mind a függőségőrzés biztosítható.
Dekomponáló algoritmusok
Olyan algoritmusok, melyek egy relációt magasabb normálformára hoznak. Pl.: 2NF -re hozás: Veszteségmentes, adott normálformában (1-4NF, BCNF) levő relációkat kapunk a következő felbontással: Az eredeti R relációt két másik relációra bontjuk a sértő α→β függőség szerint: 1. R1 sémája αβ 2. R2 sémája R-β A kapott R1 és R2 relációk közül R1 általában az kívánt normálformában van, R2-t meg kell vizsgálni, és ha szükséges, folytatni az eljárást.
Veszteségmentes, függőségőrző felbontás 3NF-re 1. Keressük meg F minimális bázisát, legyen ez F-. 2. Keressünk meg az Fhalmazban minden olyan függőségget, amelynek baloldala α: αàY1, αàY2,…. αàYk, és minden ilyenre készítsük el az (α,Y1, Y2, … Yk sémát) 3.A maradék attribútumokkal képezzünk egy másik sémát 4.Ha egyik sem tartalmaz egyetlen kulcsjelöltet sem, akkor egy kulcsjelölttel is készítsünk egy sémát.
Függőségőrzés ellenőrzése
Függőségőrző felbontás: az eredeti reláció-előfordulás visszakapható a felbontásban szereplő relációkból. A felbontásban az előfordulások R vetítettjei. Példa: Adott: R=(A, B, C) reláció és F={AàB, BàC} függőségek Vizsgáljuk meg, függőségőrző-e ez a felbontás: R egy felbontása: R1=(A, C) R2=(B, C)
Ekkor vegyük az ún. vetített függőségeket R1-ben: F1={AàA, CàC, AàC} Ahol AàC -t, F lezárásából kell vetíteni, hiszen nyilván az eredeti AàB, BàC függőségekből AàC azonnal adódik a tranzitivitási szabállyal. Tehát AàC-nek minden reláció előfordulás eleget tesz, így a dekomponálás után létrejövő reláció előfordulások is eleget tesznek. R2-beli vetített függőségek: F2= {BàB, CàC, BàC} A nem triviális függőségek F1-ben és F2-ben BàC és AàC. Vizsgáljuk meg, hogy ezekből levezethető-e minden, eredeti függőség. Látjuk, hogy AàB nem vezethető le, AàB ”elveszett” tehát a felbontás nem függőségőrző.
Veszteségmentesség
Egy felbontás akkor veszteségmentes, ha minden olyan információt visszanyerhetünk, ami az eredeti alakban szerepel. (pl.: egy 1NF táblát felbontunk, ekkor lesz több táblánk, ha jól csináltuk, egy JOIN-nal visszakapjuk az eredetit)
