• Nem Talált Eredményt

3. Az elsődleges kulcson alapuló normálformák

3.4. Első normálforma

Az első normálforma az alap relációs modellben ismertetett reláció fogalom formális definíciójának a részeként is felfogható;7 történelmileg azért definiálták, hogy megtiltsa a többértékű attribútumokat, az összetett attribútumokat és ezek kombinációját. Azt mondja ki, hogy az attribútumok tartománya kizárólag atomi (egyszerű, oszthatatlan) értékeket tartalmazhat, és hogy a rekordokban bármely attribútum értéke csak egyetlen érték lehet az adott attribútum tartományából. Az 1NF ezáltal megtiltja, hogy egy rekordon belül az attribútumok értéke egy értékhalmaz, egy érték n-es vagy ezek kombinációja legyen. Más szóval, az 1NF nem engedi meg a relációkon belüli relációkat, illetve a relációkat mint attribútumértékeket a rekordokon belül. Az 1NF szerint tehát egy attribútum értéke kizárólag egyetlen atomi (vagy oszthatatlan) érték lehet.

8.8. ábra - Normalizálás 1NF-be. (a) Egy relációséma, amely nincs 1NF-ben. (b) Az OSZTÁLY reláció példa állapota. (c) Ugyanazon reláció 1NF változata redundanciával.

Tekintsük a 8.1. ábrán látható OSZTÁLY relációsémát, amelynek az elsődleges kulcsa az Oszám, és tegyük fel, hogy kibővítjük egy Ohelyszínek attribútummal, ahogyan a 8.8. (a) ábrán látható. Feltételezzük, hogy minden osztály több helyszínnel is rendelkezhet. Az OSZTÁLY séma és egy példa relációállapot látható a 8.8. ábrán.

Ahogy látható, nincs 1NF-ben, mert az Ohelyszínek nem atomi attribútum, ahogy a 8.8. (b) ábra első rekordja mutatja. Kétféleképpen tekinthetünk az Ohelyszínek attribútumra:

• Az Ohelyszínek tartománya atomi értékekből áll ugyan, de egyes rekordok ezen értékek halmazát tartalmazhatják. Ebben az esetben az Ohelyszínek nem függ funkcionálisan az Oszám elsődleges kulcstól.

• Az Ohelyszínek tartománya értékhalmazokból áll, ezért nem atomi. Ebben az esetben fennáll az Oszám → Ohelyszínek függés, mert minden ilyen értékhalmaz az attribútum tartományának egyetlen elemeként tekinthető.8

A 8.8. ábrán látható OSZTÁLY reláció egyik esetben sincs 1NF-ben; valójában még relációnak sem tekinthető az 1. alfejezetben definiált reláció fogalom alapján. Három fő technika létezik az első normálforma elérésére az ilyen relációk esetén.

7Ezt a feltétel már nem szerepel a beágyazott relációs modellben és az objektum-relációs rendszerekben (ORDBMS-ekben), amelyek megengedik a nem normalizált relációkat.

8Ebben az esetben az Ohelyszínek tartományát egy egyszerű helyszínekből álló halmaz hatványhalmazának tekinthetjük; azaz a tartomány az egyszerű helyszínek halmazának összes lehetséges részhalmazából áll.

1. Távolítsuk el az 1NF-et sértő Ohelyszínek attribútumot, és helyezzük el egy külön OSZT_HELYSZÍNEK relációban az OSZTÁLY Oszám elsődleges kulcsával együtt. Az új reláció elsődleges kulcsa az {Oszám, Ohelyszín} lesz, ahogy a 8.2. ábrán látható. Az OSZT_HELYSZÍNEK relációban az egyes osztályok minden helyszínéhez külön rekord tartozik. Ezzel felbontottuk a nem 1NF relációt két 1NF relációra.

2. Bővítsük ki a kulcsot az eredeti OSZTÁLY relációban úgy, hogy külön rekord tartozzon az osztályok minden egyes helyszínéhez, ahogy a 8.8. (c) ábrán látható. Ebben az esetben az elsődleges kulcs az {Oszám, Ohelyszín} lesz. A megoldás hátránya, hogy redundanciát vezet be a relációba.

3. Ha tudjuk, hogy az attribútum egy maximális számú értéket vehet fel — például tudjuk, hogy legfeljebb három helyszín tartozhat egy osztályhoz —, akkor helyettesítsük az Ohelyszínek attribútumot három atomi attribútummal: Ohelyszín1, Ohelyszín2 és Ohelyszín3. Ennek a megoldásnak a hátránya, hogy NULL értékeket vezet be, ha a legtöbb osztálynak háromnál kevesebb helyszíne van. Ráadásul hamis értelmezést sugall a helyszínek rendezettségére vonatkozóan, pedig ilyen rendezettség eredetileg nem is szerepelt a terveink között. Nehezebbé válik a lekérdezés is ezen attribútum alapján; például képzeljük el, hogyan írnánk meg az alábbi lekérdezést egy ilyen sémát használva: Listázzuk ki azokat az osztályokat, amelyiknek az egyik helyszíne Vác!

A fent említett három megoldás közül általában az elsőt tekintjük a legjobbnak, mert nem okoz redundanciát, és teljesen általános, nincs korlát az értékek maximális számára vonatkozóan. Valójában ha a második megoldást választjuk, akkor a későbbi normalizációs lépésekben további dekompozícióval úgyis az első megoldáshoz jutunk.

8.9. ábra - Beágyazott relációk normalizálása 1NF-be. (a) A DOLG_PROJ reláció

sémája a Projektek beágyazott reláció attribútummal. (b) A DOLG_PROJ reláció példa

állapota mutatja a beágyazott relációkat mindegyik rekordban. (c) A DOLG_PROJ

szétbontása DOLG_PROJ1 és DOLG_PROJ2 relációkra az elsődleges kulcs

hozzávételével.

Az első normálforma az olyan többértékű attribútumokat is tiltja, amelyek maguk is összetettek. Ezeket beágyazott relációknak hívjuk, mert minden rekord egy relációt foglalhat magában. A 8.9. ábra mutatja, hogy hogy nézne ki a DOLG_PROJ reláció, ha megengednénk a beágyazást. Minden rekord egy dolgozó egyedet reprezentál, és az egyes rekordokon belül a PROJEKTEK(Pszám, Órák) reláció reprezentálja a dolgozó projektjeit, és hogy hány órát dolgozik az adott dolgozó az egyes projekteken. A DOLG_PROJ reláció sémája a következőképpen írható fel:

DOLG_PROJ(Szsz, Dnév, {PROJEKTEK(Pszám, Órák)})

A halmazt jelölő kapcsos zárójelek mutatják azt, hogy a PROJEKTEK attribútum többértékű, míg a PROJEKTEK-et alkotó attribútumokat kerek zárójelek között soroljuk fel. Érdekes módon az összetett objektumokat és az XML adatokat támogató mai trendek megkísérlik lehetővé tenni és formalizálni a beágyazott relációk használatát a relációs adatbázisrendszereken belül, amit korábban az 1NF tiltott.

Figyeljük meg, hogy az Szsz a DOLG_PROJ reláció elsődleges kulcsa a 8.9. (a) és (b) ábrákon, míg a Pszám részleges kulcsa a beágyazott relációnak; ez azt jelenti, hogy a Pszámnak a beágyazott relációban minden egyes rekordon belül egyedi értékkel kell rendelkeznie. Ahhoz, hogy 1NF-be normalizáljuk ezt a relációt, kivesszük azt az attribútumot, amely beágyazott relációként szerepel, új relációt készítünk belőle, és hozzávesszük az eredeti reláció elsődleges kulcsát; az új reláció elsődleges kulcsa az eredeti reláció elsődleges kulcsának és a

részleges kulcsnak a kombinációja lesz. A felbontás és az elsődleges kulcs átvétele eredményezi a DOLG_PROJ1 és DOLG_PROJ2 sémákat, ahogyan a 8.9. (c) ábrán látható.

Ezt az eljárást rekurzívan alkalmazhatjuk egy olyan relációra, amely többszintű beágyazást tartalmaz, hogy eltávolítsuk a beágyazásokat a relációból, és 1NF relációkat hozzunk létre. Ez akkor hasznos, ha egy nem normalizált, többszintű beágyazást tartalmazó relációsémát szeretnénk átkonvertálni 1NF relációkba. Óvatosan kell kezelni azt a szituációt, amikor egynél több többértékű attribútum fordul elő egy relációban. Tekintsük például a következő nem 1NF relációt:

SZEMÉLY(Szsz, {Rendszám}, {Telefonszám})

Ez a reláció azt a tényt szemlélteti, hogy egy személynek több autója és több telefonja lehet. Ha a fenti második lehetőséghez hasonló stratégiát követünk, akkor egy olyan relációt kapunk, amelynek kulcsát az összes attribútum együtt alkotja:

SZEMÉLY_1NF(Szsz, Rendszám, Telefonszám)

Hogy elkerüljük a Rendszám és a Telefonszám közötti extra, nem létező kapcsolatok bevezetését, az értékeik minden lehetséges kombinációját szerepeltetjük minden Szsz esetén, megnövelve ezzel a redundanciát. Ez olyan problémákhoz vezet, amelyeket többértékű függésekkel és a 4NF-fel kezelünk, amelyekről a 9. fejezetben lesz szó. A fentebb bemutatott SZEMÉLY relációsémában lévő két többértékű attribútum kezelésének helyes módja, hogy szétbontjuk a relációsémát két külön relációra a korábban tárgyalt első stratégiát követve: P1(Szsz, Rendszám) és P2(Szsz, Telefonszám).