Adatbázisok 5. gyakorlat. Jövő hét utáni héten ZH! (Adatmodellezés, normalizálás) és kötprog doksi leadás (adatmodell rész)

Az előadások a következő témára: "Adatbázisok 5. gyakorlat. Jövő hét utáni héten ZH! (Adatmodellezés, normalizálás) és kötprog doksi leadás (adatmodell rész)"— Előadás másolata:

1 Adatbázisok 5. gyakorlat

2 Jövő hét utáni héten ZH! (Adatmodellezés, normalizálás) és kötprog doksi leadás (adatmodell rész)

3 Dokumentáció követelmények ● Papíron, nyomtatva kell beadni ● Elektronikus formában vagy kézzel írva nem elfogadható! ● Tartalma: ● Az adatbázis E-K diagramja ● Az ebből képzett relációs adatbázisséma – Normalizálva 3NF-ig, részletesen levezetve – Külső kulcs feltételek egyértelmű jelölésével!

4 Ismétlés ● Kapcsolatok leképezése – hogy jön ki az új séma kulcsa? ● Kívánság?

5 Fogalmak ● Funkcionális függés ● Redundancia ● Dekompozíció

6 Redundancia ● Egy adatot a szükségesnél többször tárolunk ● Ezt általában nem szeretjük Hol van ebben a táblában redundancia?

7 Redundancia ● Egy adatot a szükségesnél többször tárolunk ● Ezt általában nem szeretjük Hol van ebben a táblában redundancia? Sok itt az egyforma sor, nemde? Meg tudjátok így is mondani, ki milyen nemű? (Emlékezetből mondani cheat. :) )

8 Funkcionális függés ● Egy attribútumhalmaz meghatároz egy másikat ● Ha rossz helyen van, redundanciát okozhat ● „Érezni” kell, hol van Hol van ebben a táblában funkcionális függés?

9 Funkcionális függés ● Egy attribútumhalmaz meghatároz egy másikat ● Ha rossz helyen van, redundanciát okozhat ● „Érezni” kell, hol van Hol van ebben a táblában funkcionális függés? Város és utca együtt meghatározzák az irányítószámot. (Budapestre nem működik, ott kerület is van.) A személyi számból kiderül az illető neme. (BTW, a születési dátuma is.) Minden, csak egy adott kulcstól különböző attribútumo(ka)t tartalmazó attribútumhalmaz funkcionálisan függ ettől az adott kulcstól (def szerint).

10 Funkcionális függés ● Jelölése: A → B, kiolvasva „B funkcionálisan függ az A-tól” vagy „A-tól funkcionálisan függ B” ● A és B attribútumhalmazok ● Példák: ● {város, utca} → irányítószám – Ha budapesti címeket is szeretnénk tárolni, ez már nem igaz, {város, kerület, utca} → irányítószám viszont igen. ● személyi_szám → nem

11 Dekompozíció (felbontás) ● Szétbontjuk a táblát több táblára ● Első számú fegyverünk a redundancia ellen ● Később meglátjuk, hogyan használhatjuk fel hatékonyan erre a célra

12 Dekompozíció (felbontás) ● Séma felbontása A → B funkcionális függés mentén: 1.Létrehozunk egy új sémát az A ∪ B attribútumhalmazból. Az új séma kulcsa az A lesz. 2.Az eredeti sémából töröljük B-t 3.Az eredeti sémában A külső kulcs lesz az új sémára ● Ha séma helyett konkrét táblát bontunk fel, akkor az 1. lépésben az új táblát az eredetiből az A ∪ B attribútumhalmazra vett projekcióval állítjuk elő.

13

14 7*4 = 28 mező 6*4 + 3*2 = 30 mező De akkor miért jó ez nekünk?

15 ● Kevés sornál úgy tűnik, csak annyi változott, hogy több mezőt tárolunk ● De elértük, hogy: ● ha egy adott utcát átsorolnak egy másik irányítószámhoz, vagy megváltozik a neve, csak egy helyen kell átírni ● ha kitörlünk mindenkit egy utcából, attól még tudni fogjuk, hogy mi az irányítószáma ● felvehetünk egy új utcát anélkül, hogy hozzárendelnénk embert – Vegyük észre, hogy a felbontás előtt ez nem lehetséges, mivel akkor a személyi számhoz is NULL-t kellene írnunk, amit nem tehetünk, mivel az kulcs.

16 A következő órán megnézzük ● Hogyan lehet felderíteni, hogy redundancia van egy táblában? ● Ha ez megvan, hogyan tudjuk azt megszüntetni felbontással? ● azaz ● normalizálunk ami a ZH-ban is benne lesz

17 Köszönöm a figyelmet! Ne felejtsétek el, 2 hét múlva ZH és doksi leadás!