OKJ vizsga programozó - Adatbázis kezelés X-XIII. tétel

10-13. tételA normalizálás…

A relációs adatmodell

Az első ABKR-ek hálós vagy hierarhikus adatmodellt használták. Manapság a relációs adatmodell a legelterjedtebb. A népszerűséget annak köszönheti, hogy nagyon egyszerű deklaratív nyelvvel rendelkezik az adatok kezelésére, illetve lekérdezésére. A relációs adatmodell érték orientált, ez ahhoz vezet, hogy a relációkon értelmezett műveletek eredményei szinten relációk.

Ha adottak nem szükségszerűen egymást kizáró halmazok, akkor R egy reláció a halmazokon, ha (Descartes féle szorzat).

A relációs adatmodell szempontjából D_i az A_i attributum értékeinek tartománya (doméniuma). D_i lehet egész számok halmaza, karakter sorok halmaza, valós számok halmaza, stb. n a reláció foka.

Egy ilyen relációt egy táblázatban ábrázolhatunk:

R	A1	...	Aj	...	An
r1	a11	...	a1j	...	a1n
ri	ai1	...	aij	...	ain
rm	am1	...	amj	...	amn

ahol .

A táblázat sorai a reláció elemei. Nagyon sok esetben a tábla megnevezést használják a reláció helyett. A relációt a következőképpen jelöljük: R (A₁, A₂,..., A_n). A reláció nevét és a reláció attribútumainak a halmazát együtt relációsémának nevezzük.

Példa:

1.) Diákok

Név	SzületésiDátum	CsopKod
Nagy Ödön	1975-DEC-13	512
Kiss Csaba	1971-APR-20	541
Papp József	1973-JAN-6	521

Példa:

2.) Könyvek

Szerző	Cím	Kiadó	KiadÉv
C.J.Date	An Introduction to Database Systems	Addison-Wesley	1995
Paul Helman	The Science of Database	IRWIN	1994

Tulajdonságok

A relációs adatbázis relációi, vagy táblái a következő tulajdonságokkal rendelkeznek:

1. A tábla nem tartalmazhat két teljesen azonos sort, azaz két egyed előfordulás (sor) legalább egy tulajdonság (attribútum) konkrét értékében el kell, hogy térjen egymástól.

2. Kulcs értelmezése: egy S attribútumhalmaz az R reláció kulcsa ha:

a) R relációnak nem lehet két sora, melynek értékei megegyeznek az S halmaz minden attributumára.

b) S egyetlen valódi részhalmaza sem rendelkezik a) tulajdonsággal.

Ha a konkrét egyedek több olyan tulajdonsággal is rendelkeznek, amelyek értéke egyedi minden egyes előfordulásra nézve, akkor több kulcsjelöltről beszélhetünk. Ezek közül egyet elsődleges kulcsnak kell kijelölni. Az is megtörténhet, hogy nincs olyan tulajdonság, amelynek értéke egyedi lenne az egyed-előfordulásokra nézve. Ekkor több tulajdonság értéke együtt fogja jelenteni az elsődleges (összetett) kulcsot. Az 1. tulajdonságból következik, hogy mindig kell legyen elsődleges kulcs, ha más nem, a teljes sor mindig egyedi. Elsődleges kulcs értéke soha nem lehet null vagy üres.

3. A táblázat sorainak vagyis az egyed-előfordulásoknak a sorrendje lényegtelen.

4. A táblázat oszlopaira vagyis a tulajdonság típusokra, attributumokra nevükkel hivatkozunk, tehát, két attributumnak nem lehet ugyanaz a neve.

5. A táblázat oszlopainak a sorrendje lényegtelen.

Relációs adatbázis séma meghatározása

A relációs adatbázis sémáján az adatbázist alkotó relációk sémájának az összességét értjük. A relációkban tárolt konkrét értékek pedig alkotják a relációs adatbázist. Egy helyes relációs adatbázis sémát két módszerrel kaphatunk: az egyed-kapcsolat diagramot átírjuk relációsémákká, illetve egy létező relációs adatbázis sémát normalizálás segítségével normál formára hozzuk.

Az egyed-kapcsolat diagramok átírása relációs modellé

Három lépésben valósíthatjuk meg az E/K diagram átírását relációs modellé:

1) Az egyed-kapcsolat diagramban található egyedhalmazokat a relációs modellben relációként ábrázoljuk, ha E egy egyedhalmaz az egyed-kapcsolat diagramból egy relációval ábrázolható, melynek attribútumai az E egyedhalmaz attribútumai lesznek.

2) Egy R kapcsolatot az E₁, E₂,..., E_m egyedhalmazok között az egyed-kapcsolat diagramból szintén egy relációval ábrázoljuk a relációs modellben, melynek attribútumai az E₁, E₂,..., E_m egyedhalmazok kulcsai. Ha ugyanazon attribútum nevek fordulnak elő át kell őket nevezni. Legyenek K₁, K₂,..., K_m az E₁, E₂,..., E_m egyedhalmazok kulcs attribútumainak a halmazai, ahol , akkor a relációs modellben kapott relációnak attribútumai a K₁, K₂,..., K_m. Ha a kapcsolatokhoz attribútumokat rendeltünk az E/K diagramon, a relációs modell relációjában a kulcsok mellett a kapcsolat attribútumai is szerepelnek.

3) Közös kulcsú relációk összevonása: Ha két relációnak van egy közös kulcsjelöltje, a két relációt összevonjuk és helyettesítjük egy relációval. Előnyök: kevesebb helyet foglal a reláció, lekérdezések hamarabb megválaszolhatók, nincsenek annyira szétdarabolva az összetartozó adatok.

Példa: Írjuk át a ??? példából az egyedhalmazokat. Az egyedhalmazok kulcsai a relációk kulcsai lesznek és ezt aláhúzással jelöljük a relációs modell relációi esetében is.

(1) Alkalmazottak (SzemSzám, Név, Fizetés)

(2) Managerek (SzemSzám)

(3) Részlegek (RészlegID, Név, Helység)

(4) Szállítók (SzállID, Név, Helység, UtcaSzám)

(5) ÁruCsoportok (CsopID, Név)

(6) Áruk (ÁruID, Név, MértEgys, MennyRakt)

(7) Vevők (VevőID, Név, Helység, UtcaSzám, Mérleg)

(8) Szerződések (SzerződID, Dátum, Részletek)

(9) Tételek (TételID, Dátum)

A kapcsolatok átírása a következő relációkat eredményezi:

(10) Dolgozik(SzemSzám, RészlegID)

(11) Irányít (SzemSzám, RészlegID)

(12) Árul (CsopID, RészlegID)

(13) Tartozik (CsopID, ÁruID)

(14) Szállít (SzállID, ÁruID, Ár)

(15) Elhelyez (VevőID, SzerződID)

(16) Tartalmaz (SzerződID, TételID)

(17) Szerepel (TételID, ÁruID, RendMenny, SzállMenny)

Nagyon fontos, hogy a kapcsolatokból kapott relációk kulcs attribútumait helyesen határozzuk meg, mert a következő lépésben szükségünk lesz rájuk. Egy relációnak több kulcsjelöltje is lehet, a tervező dönti el, hogy melyiket választja. Ha a kapcsolat bináris, E₁ és E₂ egyedhalmazok között áll fenn, legyen E₁ egyedhalmaz kulcs attribútumainak a halmaza K₁, E₂ egyedhalmaz kulcs attribútumainak a halmaza K₂, irányelvként elfogadhatjuk a következőket:

• 1:1 típusú kapcsolatok esetén lehet a K₁ vagy a K₂ is kulcsjelölt.

Például a Managerek és Részlegek egyedhalmazok közötti Irányít kapcsolat esetén a SzemSzám és a RészlegID is lehet kulcs.

• 1: n típusú kapcsolat áll fenn E₁ és E₂ egyedhalmazok között, akkor a kapcsolatnak megfelelő relációnak kulcsjelöltje a K₂.

Például a Részlegek és Alkalmazottak egyedhalmazok között a Dolgozik kapcsolat 1: n típusú, a Dolgozik relációnak a relációs adatmodellben a kulcsa a SzemSzám.

• n: m típusú kapcsolat áll fenn E₁ és E₂ egyedhalmazok között, akkor a kapcsolatnak megfelelő relációnak kulcsjelöltje összetett kulcs lesz, a K₁ és a K₂ egyesítése.

Például a Szállítók és Áruk közötti Szállít kapcsolat n: m típusú, így a kulcs összetett, SzállID és ÁruID együtt.

Az E/K modellben a specializáló ("az_egy") hierarchiák mögött az a filozófia áll, hogy a hierarchiát olyan egyedek népesítik be, amelyek amelyek specializáló kapcsolatokon keresztül kapcsolódnak egymáshoz. Emiatt természetes, hogy az általános egyedhalmazhoz egy olyan relációt készítünk, amelynek a sémája tartalmazza az egyedhalmaz attribútumait. Ami az alosztályokat illeti, ha egy általános osztálynak több alosztálya is van, minden alosztályban megismételjük az általános egyedhalmaz kulcsát. A specializáló kapcsolatokhoz nem készítünk relációkat. Ehelyett a specializáló kapcsolatokat burkolt formában az a tény fejezi ki, hogy a kapcsolódó egyedeknek ugyanazok a kulcsértékei. A fenti példa esetén, a Managerek reláció fogja azon alkalmazottak személyi számait tárolni akik managerek. Ha a managereket keressük megtaláljuk őket a Managerek relációban és az a tény, hogy a személyi számukat tároljuk biztosít minket arról, hogy a managerek is alkalmazottak és ha a többi attribútum értékére vagyunk kíváncsiak egy manager esetében, ezeket megtaláljuk az Alkalmazottak relációban a személyi szám segítségével.

Közös kulcsú relációk összevonása:

o Alkalmazottak és Dolgozik közös kulcsa SzemSzám, az Alkalmazottak relációt kiegészítjuk a RészlegID-al, így minden alkalmazott esetében tudjuk, melyik részlegnél dolgozik. Tudjuk, hogy egy alkalmazott csak egy részlegnél dolgozhat. Eredményként kapjuk:

Alkalmazottak (SzemSzám, Név, Fizetés, RészlegID)

o Részlegek és Irányít közös kulcsa a RészlegID, a Részlegek relációt kiegészítjük a managere személyi számával, át is kereszteljük ManSzemSzám-á, hogy világosabb legyen mit tartalmaz az attribútum. Eredményként kapjuk a:

Részlegek (RészlegID, Név, Helység, ManSzemSzám)

Kérdés: - ha a Részlegek-ben van egy olyan sor, mely az Irányít-ban hiányzik, vagyis épp nincs managere az egyik részlegnek a ManSzemSzám-hoz használhatunk egy speciális nullértéket, amit NULL-lal fogunk jelölni. Amikor NULL szerepel egy sor valamely attribútumhoz tartozó komponensében, az azt jelenti, hogy a sornak ehhez az attribútumához nincsen megfelelő érték megadva. A NULL érték nem 0 (zéró), nem üres karaktersor, hanem egy speciális érték.

o ÁruCsoportok és Árul közös kulcsa a CsopID, tehát kiegészíthetjük az ÁruCsoportok relációt a RészlegID-al, amelyik az illető árucsoportot árulja. Egy árucsoportot egy részleg árul, az Árul kapcsolat 1: n típusú a Részlegek és ÁruCsoportok között. Eredményként kapjuk a:

ÁruCsoportok (CsopID, Név, RészlegID)

o Hasonlóan Áruk és Tartozik összevonása után:

Áruk (ÁruID, Név, MértEgys, MennyRakt, CsopID)

o Szerződések és Elhelyez összevonása eredményeként:

Szerződések (SzerződID, Dátum, Részletek, VevőID)

o Tételek és Tartalmaz összevonása után:

Tételek (TételID, Dátum, SzerződID)

Az összetett kulcsú Szállít és Szerepel nem vonható össze más relációkkal, mivel ezek m: n típusú kapcsolatokat modellálnak.

Az összevont relációkon kívül még megmaradt relációk, ahhoz, hogy az adatbázisséma teljes legyen a közös kulcsú relációk összevonása után:

Managerek (SzemSzám)

Szállítók (SzállID, Név, Helység, UtcaSzám)

Vevők (VevőID, Név, Helység, UtcaSzám, Mérleg)

Szállít (SzállID, ÁruID, Ár)

Szerepel (TételID, ÁruID, RendMenny, SzállMenny)

A Managerek relációt esetleg elhagyhatnánk, ha nincs olyan managerünk, aki nem irányít részleget. Ha minden manager irányít egy részleget, akkor megtaláljuk őket a Részlegek relációban. Ha megengedtük volna, hogy egy részleget több manager is irányítson, akkor az Irányít kapcsolat a Részlegek és Managerek között 1: n típusú kapcsolat lett volna. Ebben az esetben a kapcsolat relációvá való átírása után kapott Irányít relációban csak a SzemSzám lett volna kulcs, nem vonhattuk volna össze a Részlegekkel, hanem a Managerek relációval vonhattuk volna össze, minden manager személyi száma mellett szerepelt volna annak a részlegnek az ID-je, amelyiket irányítja. Ugyanaz a RészlegID több manager-nél is szerepelhet.

Funkcionális függőségek

Legyen egy reláció

R (A₁, A₂,..., A_n), ahol A_i attribútumok.

Jelöljük az attribútumok halmazát

A = {A₁, A₂,..., A_n}.

Legyenek X és Y az R reláció attribútumhalmazának részhalmazai, vagyis . Ezeket a jelöléseket használjuk a továbbiakban, ha esetleg nem ismételjük meg.

Értelmezés: X attributum (attribútumhalmaz) funkcionálisan meghatározza Y attribútumot (attribútumhalmazt) (vagy Y attribútum (attribútumhalmaz) funkcionálisan függ X attributumtól (attribútumhalmaztól)), ha R minden előfordulásában ugyanazt az értéket veszi fel Y, amikor az X értéke ugyanaz.

Más értelmezés: X attributum (attribútumhalmaz) funkcionálisan meghatározza Y attribútumot (attribútumhalmazt), ha R két sora megegyezik az X attribútumain (azaz ezen attribútumok mindegyikéhez megfeleltetett komponensnek ugyanaz az értéke a két sorban), akkor meg kell egyezniük az Y attribútumain is. Ezt a függőséget fomálisan -el jelöljük.

Relációs algebrai műveletek (lásd ???) segítségével a következőképpen értelmezhetjük a funkcionális függőséget:

, ha sor esetén, melyre , akkor .

Példa: SzállításiInformációk reláció:

SzállID	SzállNév	SzállCím	ÁruID	ÁruNév	MértEgys	Ár
111	Rolicom	A.Iancu 15	45	Milka csoki	tábla	25000
222	Sorex	22 dec. 6	45	Milka csoki	tábla	26500
111	Rolicom	A.Iancu 15	67	Heidi csoki	tábla	17000
111	Rolicom	A.Iancu 15	56	Milky way	rúd	20000
222	Sorex	22 dec. 6	67	Heidi csoki	tábla	18000
222	Sorex	22 dec. 6	56	Milky way	rúd	22500

Funkcionális függőségek:

SzállID SzállNév

SzállID SzállCím.

Mivel mindkét függőségnek ugyanaz a bal oldala, SzállID, ezért egy sorban összegezhetjük:

SzállID {SzállNév, SzállCím}

Szavakban, ha két sorban ugyanaz a SzállID értéke, akkor a SzállNév értéke is ugyanaz kell legyen, illetve a SzállCím értéke is.

Ezenkívül:

ÁruID ÁruNév

ÁruID MértEgys (azzal a feltevéssel, ha más mértékegységben árulják az árut, más ID-t is kap).

Hasonlóan egy sorban:

ÁruID {ÁruNév, MértEgys}

A funkcionális függőséget felhasználva adhatunk még egy értelmezést a reláció kulcsának. Egy vagy több attribútumból álló halmaz a reláció kulcsa, ha:

1. Ezek az attribútumok funkcionálisan meghatározzák a reláció minden más attribútumát, azaz nincs az R-ben két különböző sor, amely mindenik -n megegyezne.

2. Nincs olyan valódi részhalmaza -nak, amely funkcionálisan meghatározná az R összes többi attributumát, azaz a kulcsnak minimálisnak kell lennie.

Példa: a SzállításiInformációk reláció kulcsa a {SzállID, ÁruID}, egy szállító egy árut egy árban szállít egy adott pillanatban. Nincs a táblában 2 sor, ahol ugyanaz legyen a SzállID és az ÁruID is. Csak a SzállID nem elég kulcsnak, mert egy szállító több árut is szállíthat, az ÁruID sem elég, mert egy árut több szállító is ajánlhat.

Szuperkulcsoknak nevezzük, azon attribútumhalmazokat, melyek tartalmaznak kulcsot. A szuperkulcsok eleget tesznek a kulcs definíció első feltételének, de nem feltétlenül tesznek eleget a minimalitásnak. Tehát minden kulcs szuperkulcs.

Értelmezés: Az R (A₁, A₂,..., A_n) reláció esetén attribútum prim, ha létezik egy C kulcsa az R-nek, úgy hogy . Ha egy attribútum nem része egy kulcsnak, akkor nem prim attribútumnak nevezzük.

Triviális funkcionális függőség: ha , akkor ,

Példa: {SzállID, ÁruID}SzállID.

Minden triviális függőség érvényes minden relációban, mivel amikor azt mondjuk, hogy “két sor megegyezik X minden attribútumán, akkor megegyezik ezek bármelyikén is”.

Nem triviális egy funkcionális függőség, ha az Y-ok közül legalább egy különbözik az X-ektől, vagyis

úgy hogy .

Teljesen nem triviális egy funkcionális függőség, ha az Y-ok közül egy sem egyezik meg az X-ek valamelyikével, vagyis

-re .

Parciális függőség: Ha C egy kulcsa az R relációnak, az Y attribútumhalmaz valódi részhalmaza a C-nek () és B egy attribútum, mely nem része az Y-nak (), akkor az -t egy parciális függőség. (B függ a kulcs egy részétől).

Példa: parciális függőségre

SzállID SzállNév.

A SzállításiInformációk relációban {SzállID, ÁruID} a kulcs, tehát

{SzállID, ÁruID}SzállNév,

mivel a kulcs funkcionálisan meghatároz minden más attribútumot, de a SzállNév függ a kulcs egy részétől is.

Tranzitív függőség: Legyen egy attribútumhalmaz és B egy attribútum, mely nem része Y-nak (). Egy

funkcionális függőség tranzitív függőség, ha Y nem szuperkulcs R relációban és nem is valódi részhalmaza R egy kulcsának.

Honnan a tranzitív elnevezés? Amint látjuk, Y nem kulcs, nem része a kulcsnak, tehát egy nemtriviális funkcionális függőség az, hogy Y funkcionálisan függ az R kulcsától (C-től). Tehát és , és erre mondhatjuk, hogy B tranzitív függőséggel függ C-től.

Példa: Rendelések (RendelésSzám, Dátum, VevőID, VevőNév, Részletek), egy cég rendeléseit tartalmazó reláció. A különböző vevők rendeléseket helyeznek el a cégnél, a cég más-más számot ad a különböző rendeléseknek, így a RendelésSzám elsődleges kulcs lesz, tehát kulcs révén funkcionálisan meghatározza az összes többi attribútumot:

RendelésSzám VevőID.

Ezenkívül fennáll a

VevőIDVevőNév

funkcionális függőség. Tehát a VevőNév tranzitív függőséggel függ a RendelésSzám-tól.

Problémák:

Azokat a problémákat, amelyek akkor jelennek meg, amikor túl sok információt probálunk egyetlen relációba belegyömöszölni, anomáliának nevezzük. Az anomáliáknak alapvető fajtái a következők:

1. Redundancia: Az információk feleslegesen ismétlődnek több sorban, mint például a SzállításiInformációk reláció esetében a szállító címe ismétlődik

2. Módosítási problémák: Megváltoztatjuk az egyik sorban tárolt információt, miközben ugyanaz az információ változatlan marad egy másik sorban. Például, ha a szállító címe változik, de csak egy sorban változtatjuk meg, nem tudjuk, melyik a jó cím. Jó tervezéssel elkerülhetjük azt, hogy ilyen hibák felmerüljenek.

3. Törlési problémák: Ha az értékek halmaza üres halmazzá válik, akkor ennek mellékhatásaként más információt is elveszthetünk. Ha például töröljük a Rolicom által szállított összes árut, az utolsó sor törlésével elveszítjük a cég címét is.

4. Illesztési problémák: Ha hozzáilleszteni akarunk egy szállítót, amely nem szállít egy árut sem, a szállító címét kitöltjük úgy, hogy az áruhoz "null" értékeket viszünk be, melyet majd utólag ki kell törölni, ha el nem felejtjük.

Relációk felbontása

Az anomáliák megszüntetésének az elfogadott útja a relációk felbontása (dekompozíció-ja). R felbontása egyrészt azt jelenti, hogy R attribútumait szétosztjuk úgy, hogy ezáltal két új reláció sémáját alakítjuk ki belőlük. A felbontás másrészt azt is jelenti, hogyan töltsük fel a kapott két új reláció sorait az R soraiból.

Legyen egy R reláció sémával, R-et felbonthatjuk S és T két relációra, amelyeknek sémái , illetve , úgy, hogy

1. = , ahol létezik legalább egy és úgy hogy