Adatbázis rendszerek Definíciók: 5.3. Az adatbázis létrehozásának fő fázisai:

Adatbázis Rendszerek

5. Adatbázis tervezés 5.1. Definíciók 5.2. Adatbázis kialakításának kellékei 5.3 5.3.. Az adatbázis létrehozásának főbb fázisai 5. 5.4 4. Adatbázis tervezés 5.5 5.5.. Az adatbázisadatbázis-tervezés folyamata 5.6. Az adatbázisadatbázis-tervezés lépései 5.7 5.7.. Adatbázis rendszer rendszer tervezése 5.7 5.7..1. Rendszer tervezés elmélete 5.7.2. Rendszer tervezési technikák 5.7.3. Rendszer elemzés 5.7.4. Rendszer tervezés 5.7.5. Fizikai szint tervezése (szempontok)

Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika Tanszék 20 2011 11 Dr. Alhusain Othman [email protected]

1

5. Adatbázis tervezés


5.8. 5.8. Adat függetlenség 5.9. Adat biztonság 5.10. 5.10. Kapcsolatok az adatbázisban 5.10.1. Az 1:1 kapcsolat típus 5.10.2. Az 1: N kapcsolat típus 5.10.3. Az M: N kapcsolat típus 5.11. Adatbázis anomáliák (emlékeztető) 5.12. Adatbázis normalizálás 5.13. Normál formák 5.13.1. Első normálforma (1NF) 5.13.2. Második normálforma (2NF) 5.13.3. Harmadik normálforma (3NF) 5.13.4. BoyceBoyce-Codd normálforma (BCNF)

5.1 5.1.. Definíciók:

Adatbázis:

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. Egy adott szakterületet jellemző adatokból az adatok típusát és kapcsolatát leíró adatokból (métaadatok) és az adatkezelő rendszerből áll. Egy megvalósított adatmodell, amely - a valódi adatokon kívül - tartalmazza az adatok típusát, jellemzőit, adatcsoportok közötti kapcsolatokat leíró metaadatokat.

Adatmodell:

Olyan koncepciók gyűjteménye amelyek egy adatbázis szerkezetét egyértelműen leírják. 4


5. Adatbázis tervezés 5.3. Az adatbázis létrehozásának fő fázisai:

5. 5.2 2. Adatbázis kialakításának kellékei:

DDL:

SDL:

Storage Description Language, fizikai szerkezet DML:

Data Definition Language, adatszerkezet leíró nyelv

Data Manipulation Language, adatmanipulációs nyelv

DBMS: (Data Base Management System) adatbázis kezelő rendszer

5

Összegyűjtjük az adattárolási és adatfeldolgozási igényeket (specicikáció és analízis). Az adatokat az igények szerint csoportosítva és az egyes csoportok közötti összefüggéseket feltárva kialakíthatjuk az adatbázis magas színtű modelljét (koncepcionális séma) és lekérdezési sémákat. Kiválasztjuk az adatbázis kezelő rendszer típusát. A koncepcionális séma alapján megalkotjuk az alacsony szintű, logikai modellt (relációs, hálós, hierarchikus, objektum-orientált, stb..). Az igények szerint és a konkrét adatbázis-kezelő szoftverek ismeretében megtervezzük az adattárolási szerkezeteket és hozzáférési módokat (pl fastruktúra, indexelt hozzáférés). Továbbá elkészítjük az előre tervezhető adatbázis-kezelő műveletek (lekérdezések, tranzakciók) sémáit. A konkrét adatbázis-kezelő rendszer (pl. DB2, ORACLE, MS ACCESS) adatleíró és manipuláló nyelvének felhasználásával létrehozzuk az adatbázis szerkezetét és a lekérdezési sémákat, majd ezt követően feltöltjük az adatbázist az addig összegyűjtött adatokkal.

6

Adatbázis rendszerek – 5. 1


5. Adatbázis tervezés 5.5. Az adatbázis tervezés folyamata:

5.4. Adatbázis tervezés: Felhasználók

Alkalmazói program

adatbázis rendszer

Adatbázis-kezelő rendszer (DBMS) A lekérdezéseket kezelő szoftver komponens

Magának az alkalmazandó adatbázisadatbázis-kezelő rendszer adattárolási módjának és adatkezelési jellemzőinek megismerése nagyon lényeges Az információk hatékony kinyerése céljából: céljából:

A tárolt adatokat kezelő szoftver komponens

Relációs adatbázisok: Minden témakörnek megfelelni egy külön táblában. táblában. Meghatározni milyen kapcsolat rendszer áll fen a táblák között.

Operációs rendszer

métaadatok

tárolt adatok

8



5.6. Az adatbázisadatbázis-tervezés lépései:

5.6. Az adatbázisadatbázis-tervezés lépései: 5.6.1. Adatbázis céljai és feladatai megfogalmazása:

1.

Lépés: Fogalmi modell alkotása: Adatbázis céljai és feladatai megfogalmazása.

2.

Lépés: Logikai modell alkotása 1: A szükséges táblák meghatározása

3.

Lépés: Logikai modell alkotása 2: A táblák szükséges mezőinek meghatározása

4.

Lépés: Logikai modell alkotása 3: A kapcsolatok felállítása a táblák között

5.

Lépés: A modell tesztelése: Az adatbázis terv finomítása

Kell tisztázni: Az adatbázis létrehozásának célját. Az adatbázis használati módját. Az adatbázissal szemben támasztott követelményeket. Az adatbázis által elvégezendő részfeladatokat. Adatbázis felhasználói Adatgyűjtés: Jelenlegi adat rögzítés. Használatos űrlapok, jelentések, kinyomtatások, összesítések Tárolandó adatok köre meghatározása: szőkítés de teljes körősség.

9

10




3.6. Az adatbázis adatbázis--tervezés lépései:

5.6.2. A szükséges táblák meghatározása:

3.6.3. A táblák mezőinek meghatározása:

Normalizálás Az információk témakörre lebontása Témakörök meghatározása Táblák Mezők meghatározása Táblák oszlopai Kerülni kell az úgynevezett „többszöri adatbevitel”. Kerülni kell az úgynevezett „értékes adattörlést”.

11

Kell dönteni, hogy a táblában szereplő egyedekről mit szeretnénk megtudni. A tábla minden egyes rekordjában ugyanazon jellemzők értékeit tároljuk a különböző egyedekről. Minden mező álljon közvetlen kapcsolatban a tábla témakörével. Az olyan mező, ami egy másik tábla tárgykörét érinti, lehet, hogy abba a táblába tartozik. Ne felejtsünk ki egyetlen információt sem. Tekintsük át még egyszer az adatbázisadatbázis-tervezés első - lépésében körvonalazott információk körét. Lehetőleg soha ne tároljunk számított adatot, amely a táblák más mezőjéből vagy mezőiből kalkulálhatók. Az információt a lehető legkisebb egységekben tároljuk. Kerüljük a redundáns mezőket, amelyek más táblákban már szerepelnek. 12






5.6.3. A táblák mezőinek meghatározása:

5.6.4. A kapcsolatok felállítása a táblák között:

Nézzük meg, vanvan-e a táblának olyan mezője (vagy mezői), amely egyértelműen azonosítja a tábla rekordjait, és betöltheti az elsődleges kulcs szerepét. Ha nincs, akkor vegyünk fel egy ilyen mezőt, amely akár egy egyszerű sorszámozással biztosítja a rekordok egyértelmű azonosítását. Gondolkodni kell azon, milyen mezőneveket használjunk a táblában az adatok megkülönböztetésére, a mezők milyen adattípusúak (szöveges, szám, dátum, stb.) és milyen hosszúak legyenek. Van Van--e a mezőknek esetleg valamilyen jellemző alapértéke illetve formátuma, tudunktudunk-e valamilyen szabályt felállítani a bevihető adatok körére. Kell meghatározni hogy, melyek azok a mezők, amelyek kitöltése mindenképpen szükséges egy rekordnál és melyek maradhatnak üresek.

Vizsgáljuk meg, mely táblák tartoznak valami módon egymással. Vannak--e kapcsolatban a különböző táblák, vagy talán un. Vannak Átfogó kapcsolótáblát be kell iktatni. A kapcsolat létrejöttéhez meg kell vizsgálnunk, melyik az a mező, ami a kapcsolatot biztosítja a két tábla között.

A kulcs mezőt mindkét kapcsolódó táblának tartalmaznia kell. Meg kell vizsgálnunk a kapcsolat típusát (egy az egyhez, egy a többhöz, több a többhöz) és a kapcsolat minőségét, az adatintegritási szabályokat.

13

14




5.7 5.7.. Adatbázis rend rendszer szer tervezése:

5.6.5. Adatbázis terv finomítása:

5.7 5.7..1. Rendszer tervezés elmélete:

Táblák, mezők, és kapcsolatok elméleti meghatározása után újból át kell néznünk a tervet, azt elemeznünk kell, hogy az esetleges hiányosságok kiderüljenek. A táblák fizikailag is létrehozni, és teszt adatokkal tölteni. A szükséges űrlapok, jelentések, lekérdezések prototípusát is elkészíthetjük. Eközben kiderülhet az, hogy a mezők adattípusát, méretét megfelelően határoztukhatároztuk-e meg, s a táblák közötti kapcsolatot biztosító mezők nem mondanakmondanak-e ellent az adatintegritási szabályoknak. Fény derülhet arra is, helyesen választottukválasztottuk-e meg a táblák elsődleges kulcsát, a beviendő adatok nem sértiksértik-e a táblák közötti kapcsolatokat. Ezek ismeretében korrigáljuk, finomítsuk az adatbázis tervét, ami többször bizonyos tervezési lépések megismétlésével jár.

Rendszer elemzés: Tárolandó adatok körét: Adatbázissal szemben felmerülő igényeket: Rendszer tervezés: Megvizsgáljuk a relációk közötti kapcsolatokat, ennek eredménye a rendszer specifikáció, vagy logikai modell. A fizikai szint leképzés: képezzük le a logikai adatbázis modellt a felhasználható szoftver és hardver függvényében.

15

16



5.7 5.7.. Adatbázis rend rendszer szer tervezése: 5.7 5.7..1. Rendszer tervezés elmélete:

5.7 5.7.. Adatbázis rend rendszer szer tervezése: 5.7 5.7..2. Rendszer tervezési fogalmak:

Rendszer elemzés:

Tárolandó adatok körét: Adatbázissal szemben felmerülő igényeket:

Rendszer tervezés:

Megvizsgáljuk a relációk közötti kapcsolatokat, ennek eredménye a rendszer specifikáció, vagy logikai modell.

A fizikai szint leképzés:

képezzük le a logikai adatbázis modellt a felhasználható szoftver és hardver függvényében. 17

Funkcionális függőség: 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. Például a személyi szám és a nem között funkcionális kapcsolat áll fenn, mivel minden embernek lehet határozni a nemét a személyi száma alapján.

18






5.7 5.7..2. Rendszer tervezési fogalmak:


Reláció kulcs: A reláció kulcs egy relációnak egy sorát azonosítja egyértelműen. A reláció 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).

Redundancia: A logikai adatbázis tervezés egyik fő célja a redundanciák megszüntetése. A redundanciáról akkor beszélünk, ha valamely tényt vagy többszörösen tároljuk, vagy a többi adatból levezethető mennyiséget ismételten 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. A megoldás: normálizáció

19

20






5.7 5.7..3. Rendszer elemzés:

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

Az indexek logikailag egy rendezett listaként foghatóak fel. Fizikailag a rendezett sorrendet táblába rendezett mutatók biztosítják. 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 hangsúlyt kell fektetni a helyes indexek kiválasztására. Az indexek számának indokolatlan 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.

Elemzési elvek: Adatállományok lebontása és/vagy csoportosítása. Kapcsolat és átfedések a csoportok között. különböző jogosultsági és hozzáférési szinteket kell határozni.

21

22





5.7 5.7..4. Rendszer tervezés:

5.7 5.7..5. Fizikai szint tervezése:

A rendszertervezés során a rendszerelemzés alatt összegyűjtött információk alapján egy kész logikai modellt kell előállítni. A logikai modell közvetlenül felhasználható az adatbázis kialakításakor. A logikai szint megalkotásakor már figyelembe veszünk olyan szempontokat, amelyek már a konkrét használattal kapcsolatosak. A tervezési folyamatok során mérlegelnünk kell, hogy a táblák mezőinek számát növeljük meg, vagy több táblában helyezzük el az információkat, és így a táblák közötti kapcsolatrendszerre helyezzük át a hangsúlyt. Szintén a táblák kialakításának fontos szempontja és befolyásoló tényezője, hogy előre rögzítsünk tulajdonságokat az információ mennyiséget, vagy hagyjuk meg a lehetőséget a későbbi bővítésre

23

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 tervezéskor figyelembe kell vennünk a táblákban történő tranzakciók gyakoriságát, hiszen nem mindegy, hogy egy háttér információkat tartalmazó tábláról van szó, amit néhány adminisztrátor használ, vagy pedig gyakori és mindenki által kezelt tábláról van szó. Az index állományok segítségével gyorsabban kereshetünk a tábláink között, azonban egy új rekord beszúrása több időt vesz igénybe. A végleges adatstruktúra kialakításkor fontos szempont ugyanazon adatok különböző módokon történő rögzítése. Ezen problémák elkerülése érdekében, ahol csak lehet, meg kell szüntetni a szöveges adatrögzítési feladatokat, ezt checkbox (többválasztós), rádió (egyválasztós), vagy legördülő mező alkalmazásával lehet elkerülni.

24




5.8 5.8.. Adat függetlenség:

5.8 5.8.. Adat függetlenség:

5.8 5.8..1. Logikai függetlenség:

5.8.2. Fizikai függetlenség:

Logikai szinten az adatbázis leírása megváltoztatható anélkül, hogy a fizikai szinten változás történne. Az adatszerkezet megváltozása csak métaadatokban jelent változást. Az adatbázis használata közben szükségessé válhat a fogalmi adatbázis módosítása, például új objektumok bevezetése (új táblák létrehozása), vagy régi objektumok új információval való kibővítése (pld. egy meglévő táblákhoz új oszlop hozzáadása), vagy feleslegessé vált objektumok törlése (többé nem használt táblák …). A fogalmi sémán számos változtatás hajtható végre anélkül, hogy ezek a létező felhasználói nézeteket érintenék. Néhány, a fogalmi sémán végrehajtott változtatás igényelheti az érintett felhasználói szintek módosításait. Az alkalmazói programoknak ügy szintén az esetek többségében minden változtatás nélkül kell hogy futnak. Ha van egy olyan változtatás ami mindenképpen a felhasználói séma átírását igényli, akkor ebben az esetben szükségessé válhat egyes alkalmazói programok módosítása is.

Fizikai szinten az adatbázis leírása megváltoztatható anélkül, hogy a logikai szinten változás történne. Az adattárolási szerkezet és a hozzáférési módok változása nem vonja maga után a koncepcionális séma- és az alkalmazói program megváltozását. Röviden mondható hogy, egy jól szervezett adatbázisban a fizikai séma megváltoztatható, anélkül, hogy változtatni kellene a fogalmi sémán, vagy hogy újra kellene definiálni a nézeteket, a külső szintet.

25

26


5. Adatbázis tervezés 5.10 5.10.. Kapcsolatok az adatbázisban:

5.9 5.9.. Adat biztonság:

A falhasználók egyes csoportjai nem látják (nem láthatják) a teljes adatbázist illetve annak részeit is esetleg másképpen látják. Minden felhasználó a látási szintjén (tartományon) belül teljesen kell hogy követhető és rekonstruálható a tevékenysége. Egy felhasználói szinten kell tervezni a különböző végrehajtható műveleteket hogy a hiba eredménnyel járó végrehajtás nulla csökkenjen (kötések).

Az adatbázis táblái között leggyakrabban (de nem mindig) létezik kapcsolat. A kapcsolat lehet Zérós-, Egyes-, vagy Többes típusú. Ha egyik rekord létezik a forrás táblán, viszont egyáltalán nem létezik egy cél táblán, ilyen kapcsolat a két tábla között Zéró-kapcsolatot szokták nevezni. Zérós Kapcsolat: Zérós rekord nem kötelezően de létezhet a cél táblán. Egyes Kapcsolat: Egyes rekord kell hogy legalább egyszer létezik a cél táblán. Többes Kapcsolat: Többes rekord kell hogy többször létezik a cél táblán.

27

28



5.10 5.10.. Kapcsolatok az adatbázisban:

5.10.1.. Az 1 : 1 Kapcsolat: 5.10.1

A kapcsolat létezése:

Definíció:

Két egyed halmaz között akkor van kapcsolat, ha legalább egy elemnek az első halmazból van kapcsolata legalább egy elemmel a másik halmazból.

Kapcsolat típusok: Totális: Amennyiben egy kapcsolatban résztvevő egyedtípus minden

egyede valóban részt vesz a kapcsolatban, azaz minden egyede kapcsolatban van legalább egy másik egyeddel, akkor az egyedtípus teljes (totális) részvételéről beszélünk. Parciális: Ha létezik az egyedtípusnak olyan előfordulása, amely nem létesít kapcsolatot egyetlen más egyeddel sem, akkor az őt tartalmazó egyedtípus A kapcsolat tipusa az határozza hogy, egy adott egyedtípushoz tartozó egyed hány másik egyedtípushoz tartozó egyeddel van kapcsolatban.

Grafikon:

Házastársi kapcsolat

Számszerűség: – – –

Akkor beszélünk 1:1 kapcsolatról (egy-egy), ha a kapcsolatban résztvevő egyedtípusok egyedei legfeljebb egy (és nem több!) másik egyedtípusbeli egyeddel létesítenek kapcsolatot. Az 1:1 kapcsolatok nagyon hasznosak a Null- értékű cellák (mezők) eleminasában.

1: 1 1: N M:N

N-ágú kapcsolat: Több bináris kapcsolat

29

30




5.10.1.. Az 1 : 1 Kapcsolat: 5.10.1

5.10.2.. Az 1 : N Kapcsolat: 5.10.2

Tábla:

Definíció:

Emberek és személyi számaik:

Kovács József

12045678

Nagy Lajos

32551230

Andrásy Botond

23511114

Kiss István

01234567

Nagy Istvánné

01010101

Az 1: N kapcsolat esetében az egyik oldal egyedei legfeljebb egy másik oldalbeli egyeddel létesíthetnek kapcsolatot, míg a másik oldal előfordulásai között biztosan van legalább egy olyan egyed, amely több (legalább kettő) előző oldalbeli egyeddel van kapcsolatban.

Tulajdonság:

Az 1:N kapcsolat típus nagyon elterjedt az adatbázisok táblai között. A legjobban mutatható a VAN E logikai kifejezésben.

31

32



5.10.2.. Az 1 : N Kapcsolat: 5.10.2

5.10.2.. Az 1 : N Kapcsolat: 5.10.2

Grafikon:

Tábla:

Egy embernek több autója lehet, de egy autónak legfeljebb egy tulajdonosa van.

Ember

E1 E2 … … E3

Van-e

* * … … *

Auto

A1 A2 … … A3

Egy szülő (anya vagy apa) és gyerekek (az "1" re mutató nyíl használata) nyilvántartása egy táblán Kissné Nagy Valéria

Kiss Norbert

Tóth Lajosné

Tóth Mária

Tóth Lajosné

Tóth Fatime

Tóth Lajosné

Tóth András

Kovács József

Kovács Laszló

Kovács József

Kovács Heidi

33

34



5.10.3.. Az M : N Kapcsolat: 5.10.3

5.10.3.. Az M : N Kapcsolat: 5.10.3

Definíció:

Grafikon:

Az M :N kapcsolat esetében mindkét oldal tartalmaz legalább egy olyan egyedet, amely több másik oldalbeli előfordulással van kapcsolatban. Tulajdonság: Az M:N kapcsolat párosul összetettebb egyed struktúrával. Az M:N kapcsolatot egy adatbázisban a legjobban kifejezhető több tábla használatában, ahol egy rekord az egyik táblából kapcsolódik több rekordhoz egy másik táblában. A legjobban mutatható a TÖBBEK CSINALNAK TÖBBET logikai kifejezésben.

Színészek játszanak színdarabokban.

Szinész

35

Játszik

Darab

36



5. Adatbázis tervezés 5.11 5.11.. Adatbázis anomáliák 5.11.1. Bevezetés:

5.10.3.. Az M : N Kapcsolat: 5.10.3 Tábla:

Egy táblázatos példa a több- több (M:N) kapcsolatokra, a lóverseny fogadók és a lovak nyilvántartása. Egy másik példa, egyetemen a hallgatók és a kurzusok nyilvántartása ahol egy hallgató több kurzus vehet fel, és egy kurzushoz több hallgató tartozhat. Szentpéteri István

AlföldCsillaga

Szentpéteri István

Overdose

Kovács Vazul

FehérMax

Károlyi Elek

Kiss zürkeség

Elek valaki

FehérMax

Az adatstruktúra megalkotásánál a kezelés hatékonyságára is gondolni kell. A rossz adatmodell adat többszörözés (redundanciához ) vezethet. A redundancia mellett számos egyéb műveleti nehézséget is okozhatnak a modell hiányosságai, ezek közül legszembetőnúbb az hogy, nem az összetartozó adatok kerülnek egy relációba (anomáliák). Hogy melyik mezők kerülnek egy relációba, maga után vonja hogy a mezők közötti összetartozási viszony, és a mezők közötti függőségek határozza meg. A legfontosabb függőségi típus a funkcionális függőség, mely megközelítőleg megfogalmazva azt jelenti, hogy az egyik mező minden értékéhez a másik mező egy értéke kapcsolható.

37


38


5.11 5.11.. Adatbázis anomáliák 5.11.2. Emlékeztető:

5.11 5.11.. Adatbázis anomáliák 5.11.2. Emlékeztető:

5.11.2.1. Redundanciák: A redundanciáról akkor beszélünk, ha valamely adat (tényt) többszörösen tároljuk az adatbázisban, vagy a többi adatból levezethető mennyiséget ismételten tároljuk.

5.11.2.2. Anomáliák: Beszúrási anomália: Amikor egy rekord felvitelekor, felesleges, már letárolt információkat is újra be kell vinni; Módosítási anomália: Amikor egy információegység módosításához több helyen is módosítani kell az adatbázisban, ami nem csak többletmunkát okoz, de növeli az inkonzisztens (nem egyértelmű) állapot valószínűségét is, ha valahol elmarad a módosítás; Törlési anomália: A törlési anomália azt jelenti, hogy egy információelem megszűnésekor más, hozzá nem tartozó információk is elvesznek.

Felesleges adattárolás. Komplikált adatbázis frissítési és karbantartási műveletekhez vezet. Okozhat adatbázis inkonzisztenciáját.

Megoldás:

Normálizáció Relációs modellezés és tervezés Strukturált tervezés Logikai tervezés Több táblás tervezés 39


40


5.11 5.11.. Adatbázis anomáliák:


5.11.2. Emlékeztető:

5.11.2. Emlékeztető: 5.11.2.2. Anomáliák: Bövítési (beszúrási) anomália: Amikor egy rekord felvitelekor, felesleges, már letárolt információkat is újra be kell vinni;

5.11.2.2. Anomáliák:

Beszúrási anomália:

Módosítási anomália: Törlési anomália:

41

42








5.11.2.2. Anomáliák:

5.11.2.2. Anomáliák: Törlési anomália: A törlési anomália azt jelenti, hogy egy információelem megszűnésekor más, hozzá nem tartozó információk is elvesznek.

Módosítási anomália:

Amikor egy információegység módosításához több helyen is módosítani kell az adatbázisban, ami nem csak többletmunkát okoz, de növeli az inkonzisztens (nem egyértelmű) állapot valószínűségét is, ha valahol elmarad a módosítás;

43


44


5.12 5.12.. Adatbázis normalizálás:


5.12.1. Definíció: A normalizációt lehet definiálni mint ”szétbontó műveletek sorozata, amelyek eredményeként egymással kapcsolatban álló relációkat kapunk”. A helyes modell megtervezésére irányuló elvek és módszerek normalizálás néven is ismeretesek. Így a normalizációt lehet definiálni mint sorozat lépés amelyben a relációs adatmodell létrehozható és javítható (korrigálható) egyben. A normalizálás tehát egy tervezési metodika, amely segítséget nyújt a helyes, anomália mentes relációs sémák és adatbázis kialakításában.

5.12.2. Normalizációs eljárás: Az ER diagramok átírásából kapott reláció sémák még nem véglegesek. Az adatbázis tervezésének következő szakasza az egyes relációs sémákban szereplő attribútumok egymás közötti kapcsolatainak ellenőrzése. A kapcsolatokat ûn. függőségekkel írjuk le. Az ellenőrzés, és ha szükséges, az azt követő sémaátalakítási folyamaton keresztül elérhető lesz a normálizáció.

45


46




5.12.3. A normalizáció céljai és haszna: A normalizálás célja, hogy a lehető legkisebbre csökkentsük az adatbáziskezelő rendszerben a használat során előforduló potenciális hibaforrásokat. A normalizáció alkalmazásával csökken a tárolási igény. Megszűnnek vagy legalább csökkennek az anomáliák. Logikailag áttekinthetőbb lesz az adatbázis.

5.12.4. Függőségek az adatbázisban: 1. Determináns: X determináns a következő egyenletben mert értékétől függ Y értéke. Y=X+1 2. Funkcionális függőség: A fenti egyenletben Y funkcionálisan függ X-től mert Y értéke függ X értékétől.

47

48






5.12.4. Függőségek az adatbázisban: 3. Tranzitiv funkcionális függőség:

5.12.4. Függőségek az adatbázisban: 4. Teljes funkcionális függőség:

A következő egyenlet rendszerben Z tranzitiv funkcionális függőségben X-el, mivel Y funkcionálisan függ X értékétől, és Z funkcionálisan függ Y értékétől. Y=X+1 Z=Y2 USD meghatározza hogy a FizetőEszköz US Dollar

• • •

Kanadai Dollar függ ettől hogy a FizetőEszközKód CAD

•

A teljes funkcionális függőségben Y függ csak X értékétől és nem mástól,, és X kombinálva Z-vel nem határozhat meg Y mástól Y--t. Így X mint determináns nem alkothat összetett kulcsot. Pld.: A következő táblában összetett külcs (VáltóÉrték VáltóÉrték,, Ország), szortírozva a VáltóÉrték VáltóÉrték--el, el, az Ország meghatározza a Lakosság Lakosság--ot, ot, a Lakosságot viszont meg van határozva csak az OrszágOrszág-al és nem a VáltóÉrték--el. VáltóÉrték el. Így a funkcionális függőség teljes a Lakosság és az Ország között, mert a . VáltóÉrték nem relevans a Lakossághoz nézve.

49

50





5.12.4. Függőségek az adatbázisban: 5. Multi- értékes funkcionális függőség:

5.12.4. Függőségek az adatbázisban: 6. Ciklikus funkcionális függőség:

• Történik listás (multi-értékű) mezőknél. • A multi-értékek függenek az elsődleges külcstől. • Létezik triviális- és nem triviális-funkcionális függőség (két mezős illetve több mezős tábláknál).

• A ciklikus függőséget lehet modellezni kör alakú struktúrával. • A függőség lehet direkt vagy indirekt. • Pld1.: Y függ X-től, és az ellenkező is igaz. • Pld2.: X kapcsolódik Y-re, Y kapcsolódik Z-re, és Z kapcsolódik X-re, következés képen Z kapcsolódik X-re.

51

52


5. Adatbázis tervezés 5.13 5.13.. Normál Formák:

5.13 5.13.. Normál Formák:

A relációk közötti felállított tervezési irányelveket követelmények formájában szokás adni, több, egymásra épülő követelmény alakjában. Az egyes követelményeket szokás normálformáknak is nevezni. Az egyes normálformáknak megfelelő ellenőrzéseket, vizsgálatokat és módosítási lépéseket normalizációs lépéseknek nevezzünk. A normálformák fokának emelkedésével egy egyre szigorodó követelményrendszert reprezentálnak, ill. feltételrendszert jelentenek. A feltételek egymásra épülése alapján az egyes normálformákat rangsorba lehet helyezni. A rangsor alján elhelyezkedő, leglazább feltételt nevezzük első normálformának. Bár egy adatbázis struktúra több normál formára lehet bontani, a gyakorlat szempontjából csak az első három normálformának van jelentősége. 53

5.13.1. Első normálforma (1NF): Az Első normálformában van a relációs séma, ha minden mezője funkcionálisan függ a kulcsmező csoporttól. E szerint, a függőségi rendszerben léteznie kell egy kulcsnak, s minden más mezőnek ettől kell függenie.

Másképen:: Másképen

Az első normálformát lehet jellemezni a következő tulajdonságokkal: Egy reláció 1NF, ha minden sorban pontosan egy attribútum értéke van reprezentálva Nincs felőlről lefelé (top-to-bottom )sorrend a sorokon Nincs balról jobb felé sorrend az oszlopokon Nincs duplikáció a sorokon Minden sor és oszlop keresztezésében (cella) van egyetlen egy érték. Az összes oszlopok regulárisak (nincs bújtatott komponensek, pld. sor-, objektum- id-k

1NF-re hozás:

– Sorok szétbontása – Több relációra bontás Az oszlopok száma és sorrendje minden sorban azonos Minden oszlop csak meghatározott értéket vehet fel az attribútum értéktartományából

54




5.13 5.13.. Normál formák:

5.13 5.13.. Normál Formák: 5.13.1. Első normálforma (1NF):

5.13.1. Első normálforma (1NF): Példák nem felelnek meg az 1NF-nek:

Elsődleges kulcs nélküli tábla. Tábla a legalább egy nullás attribútummal. Tábla nézet amely feltételezi sorrendet a kulcs mezőn kívül.

55

56





5.13.2. Második normálforma (2NF):

A második normálformában van a reláció, ha az első normálformát teljesíti, és ezen felül minden nem kulcs mező a teljes kulcstól függ, de nem függ a kulcs bármely részhalmazától. Ezzel azt fejezzük ki, hogy a kulcsközponti szerepet játszik a relációban, minden mezőnek a teljes kulcstól, s nem annak egy részétől kell függnie. A második normálformát sokszor az eredeti reláció feldarabolásával lehet elérni.


Másképen:: Másképen

A Második normálformát lehet jellemezni a következő tulajdonságokkal: Egy reláció 2NF, ha 1NF és minden másodlagos attribútum teljesen függ a kulcstól Ha a kulcs egyszerű (nincs része): 2NF Ha nincs másodlagos attribútum: 2NF Nincs részleges függőség

Több relációra való felbontás:

Kiemeljük a kulcsból azokat az attribútumokat, amelyek önállóan meghatározzák a másodlagos attribútumokat Ezekből új relációt képezünk A kulccsal teljes függésben lévő attribútumokat a kulcs elsődleges attribútumaival új táblában fogjuk össze új relációk elsődleges kulcsai idegen kulcsként bekerülnek az 57 eredeti relációba

58

5. Adatbázis tervezés 5.13 5.13.. Normál Formák: 5.13.2. Második normálforma (2NF): • Szerzo és Konyv tábla között 1:N kapcsolat van. • Kiadó adatok statikusak, egy Kiadó több könyvet kiadhat. • Tema adatok statikusak.


Szerzo szerzo 1


Konyv szerzo (IK) Konyvcim ISBN oldal N kiado kiado_cim kiado_tel. tema fikcio nem_fikcio

5.13.2. Második normálforma (2NF): • Szerzo és Konyv tábla között 1:N kapcsolat van. • Kiadó és Tema statikus adatok különítése 2NF-ban.

Konyv szerzo (IK) konyvcim ISBN oldal Kiado kiado kiado_cim kiado_Kontakt kiado_tel.

59

Szerzo szerzo Szerzo szerzo

Tema tema fikcio nem_fikcio

Konyv szerzo (IK) Konyvcim ISBN oldal kiado kiado_cim kiado_tel. tema fikcio nem_fikcio 60








• 2NF-ban létrehozunk több 1:N kapcsolat: • Szerzo és Konyv tábla között 1:N kapcsolat van. • Kiado és Konyv között 1:N kapcsolat van. • Tema és Konyv között 1:N kapcsolat van.

• Szerzo, Kiado, Tema táblák egy oldal és Konyv tábla között 1:N kapcsolat van. • Elsődleges kölcsök a statikus tablákban kötjük a Konyv dinamikus tábla mint része az összetett elsődleges kölcsnek.

Konyv szerzo (IK) konyvcim ISBN oldal

Szerzo szerzo

Kiado

Szerzo szerzo

kiado kiado_cim kiado_tel. tema fikcio nem_fikcio

Tema

kiado kiado_cim kiado_Kontakt kiado_tel.

Konyv szerzo (IK) konyvcim ISBN kiado (IK) tema (IK) oldal

Konyv szerzo (IK) Konyvcim ISBN

tema fikcio nem_fikcio

Kiado kiado kiado kiado_cim kiado_Kontakt kiado_tel.

Szerzo szerzo

Szerzo szerzo


61








• Szerzo, Kiado, Tema táblák egy oldal és Konyv tábla között 1:N kapcsolat van. • Elsődleges kölcsök a statikus tablákban kötjük a Konyv dinamikus tábla mint része az összetett elsődleges kölcsnek.

• Szerzo és Konyv táblák között 1:N kapcsolat van. • Kiado, Tema táblák egy oldal és Konyv tábla között 1:N nem azonosító kapcsolat van.

Konyv szerzo (IK) konyvcim ISBN kiado (IK) tema (IK) oldal Kiado kiado kiado_cim kiado_Kontakt kiado_tel.

Szerzo szerzo

Szerzo szerzo




64

5. Adatbázis tervezés 5.13 5.13.. Normál Formák:


5.13.3. Harmadik normálforma (3NF):

5.13.3. Harmadik normálforma (3NF): A Harmadik normálformában van a reláció, ha teljesíti a második normálformát és ezenkívül igaz, hogy nem áll fenn tranzitív függőség, azaz nem áll fenn az egyik nem kulcs mezőből egy másik nem kulcs mezőbe irányuló függőség. A kulcs ugyanis a köztes mezőn keresztül, tranzitíven határozza meg a másik mező értékét. Ezért a köztes mező egyfajta kulcs szerepet játszik a másik mezőnél. A tranzitív függőség feloldás is szintén a reláció feldarabolásával történik. Ehhez kiemeljük a tranzitív függést egy külön relációba. Az eredeti táblában csak a kapcsolatot biztosító mező marad meg.

Másképpen: A reláció 3NF, ha 2NF és: Nincsenek tranzitív függőségek. A tranzitív függőség egy olyan függőség láncolat, amelyben az elsődleges kulcs meghatároz valamilyen attribútumot, és az attribútum meghatároz egy harmadik attribútumot. A kapcsolat 3NF ha minden mező a relációban amely nem kulcs mező kell hogy direkt módon függjön az elsődleges kulcstól. 3NF-be hozás: A reláció felbontása A tranzitív függőséget egy új relációba helyezzük. Az eredeti relációban meghagyjuk az összes többi attribútumot. Az új reláció elsődleges kulcsa a kiindulási táblában idegen kulcsként szerepel.

65

66








• Az M:N kapcsolat átírása áttekinthető formában.

• Az M:N kapcsolatban eredményez „duplikált” rekordok hol az „egyedi” rekordok kívánatosak. Join lekérdezes eredményezhet duplikált rekordok egy M:N kapcsolatban

Dolgozo dolgozo

Feladat feladat

Dolgozo dolgozo

Feladat feladat

Munka

dolgozo (IK) feladat (IK)

Biztosít egyedi „Munkak”

67

68







• A 3NF transzformáció önti a rekord duplikációt új táblában.

• A 3NF transzformáció tranzitiv függőség szeparálása új táblában.

Ugyfel

Beszalito

Ugyfel

Beszalito

Dolgozo

Ugyfel

ugyfel

beszalito

ugyfel

beszalito

dolgozo

ugyfel

fizetoeszk. kod

fizetoeszk. kod

fizetoeszk. Kod (IK)


osztaly


fizetoeszk

fizetoeszk

cim

cim

varos

cim

Valtoar cim

Valtoar cim

Penzváltás

1. A varos tamaszkodik az osztalyra. 2. Az osztaly tamaszkodik a dolgozora 3. Következésképen a varos indirekt módon (tranzitiv módon) tamaszkodik a dolgozora.

fizetoeszk. kod fizetoeszk

A fizetoeszkoz adatai közös a két táblában

Valtoar

Tranzitiv függőség megoldott!

Minden osztaly egy varosban van

Ugyfel és beszalito függetlenek egymástől

Penzváltás osztaly varos

3NF transzformáció rendeli a fizetoeszkoz adatai új táblában 69

70




5.13 5.13.. Normál Formák: 5.13.4. Boyce-Codd normálforma (BCNF):

5.13.4. Boyce-Codd normálforma (BCNF):

•

A normál formák definíciója alkalmazható a több jelölt kulccsal rendelkező relációkra is (un. Surrogate és Natural keys). Ebben az esetben minden attribútum, mely valamely kulcsnak a része, elsődleges attribútum, de ez az attribútum függhet egy másik, ezt nem tartalmazó kulcs részétől. Ha ez a helyzet fennáll, redundanciát tartalmaz a reláció. Ennek a felismerése vezetett a harmadik normál forma egy szigorúbb definíciójához, a Boyce/Codd normál formához. BCNF tulajdonságai: Minden reláción belüli nem triviális függőség van. BCNF-re hozás: felbontással A Boyce-Codd normál forma egy erősebb normál forma, ami közvetlenül ellenőrizhető a funkcionális függőségek szempontjáből Ha BCNF, akkor biztosan 3NF is. Ha a relációban csak egy jelölt kulcs található akkor a reláció 3FN és Boyd-Codd formában van. Determinánsoknak kulcsjelölteknek kell lenniük.

Ugyfel-cim

Ugyfel-nev

ugyfel-id (IK)

ugyfel-id

Ugyfel-id (IK)

cim

ugyfel-nev

Ugyfel-nev

Ugyfel

Ugyfel-id (IK)

cim

Ugyfel-id UgyfelStockJ Tartozas

email valtas jjelveny tartozas Aktivitasi-datum Napok-kredit

tel

Ugyfel

tel fax

Ugyfel-tel

Ugyfel-fax ugyfel-id (IK)

Ugyfel-id(IK)

Aktivitasi-datum

valtas

Napok-kredit

fax

jelveny

Ugyfel-email Ugyfel-id(IK) email

71

72


5. Adatbázis tervezés 5.13 5.13.. Normál Formák: 5.13.4. Boyce-Codd normálforma (BCNF): •

73


Adatbázis rendszerek Definíciók: 5.3. Az adatbázis létrehozásának fő fázisai:

Recommend Documents