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)

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!

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

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

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?

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. :) )

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?

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).

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

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

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ő.

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

● 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.

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

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