Az 5. fejezettől a 7. fejezetig a relációs modell és a hozzá kötődő nyelvek különböző aspektusait tárgyaltuk. Minden relációséma attribútumokból, a relációs adatbázisséma pedig relációsémákból áll. Eddig azt feltételeztük, hogy az attribútumok az adatbázis-tervező elgondolása vagy pedig egy koncepcionális adatmodellben (például ER-ben vagy EER-ben) felírt adatbázisséma-terv leképezése alapján lettek csoportosítva egy relációsémába. Ezekben a modellekben a tervező azonosítja be az egyedtípusokat és a kapcsolattípusokat, valamint ezek attribútumait, és ez az attribútumok természetes és logikus csoportosítását eredményezi a relációkban, amikor a 7. fejezetben ismertetett leképezési eljárásokat követjük. Ennek ellenére szükségünk van egy olyan formális mértékre, amely megmondja, hogy miért lehet jobb az attribútumok relációsémákba történő egyik csoportosítása, mint a másik. Eddig a koncepcionális tervekről (3. és 4. fejezet) és azok relációs modellre történő leképezéséről (7. fejezet) szóló tárgyalásainkban nem adtunk a megfelelőségre vagy jóságra semmilyen mérőszámot, amellyel a tervünk minőségét mérhetnénk, csak a tervező intuícióját. Ebben a fejezetben olyan elméleti ismeretekről tárgyalunk, amelyeknek célja a relációsémák kiértékelése a terv minősége szempontjából — azaz hogy formálisan megmérjük, hogy miért jobb az attribútumok relációsémákba történő egyik csoportosítása, mint a másik.
Két szinten beszélhetünk a relációsémák jóságáról. Az egyik a logikai (vagy koncepcionális) szint, amely azt írja le, hogy a felhasználók hogyan értelmezik a relációsémákat és az attribútumaik jelentését. Ha ezen a szinten jó relációsémáink vannak, akkor lehetővé válik, hogy a felhasználók tisztában legyenek a relációkban szereplő adatok jelentésével, és ezáltal helyesen tudják formalizálni a lekérdezéseiket. A másik az implementációs (vagy tárolási) szint, amely azt írja le, hogy hogyan tárolódnak és módosulnak a rekordok az alaprelációkban. Ez a szint csak a (fizikailag, állományokban tárolt) alaprelációk sémáira vonatkozik, míg a logikai szinten mind az alaprelációk, mind a nézetek (virtuális relációk) sémáira kíváncsiak vagyunk. Az ebben a fejezetben ismertetett relációs adatbázis-tervezési elmélet elsősorban az alaprelációkra vonatkozik, bár a megfelelőség bizonyos kritériumai a nézetekre is érvényesek, ahogyan arról majd a 8.1. alfejezetben írunk.
Sok más tervezési feladathoz hasonlóan az adatbázis-tervezés is két megközelítést felhasználva hajtható végre: alulról felfelé vagy felülről lefelé. Az alulról felfelé tervezési módszer (amelyet szintézis alapú tervezésnek is neveznek) az egyes attribútumok közötti alapvető kapcsolatokat tekinti kiindulópontnak, és azokat használja fel a relációsémák építéséhez. A gyakorlatban ez a megközelítés nem igazán népszerű[26], mert az a probléma vele, hogy kiindulásképpen össze kell gyűjteni egy csomó bináris kapcsolatot az attribútumok között. Ezzel szemben a felülről lefelé tervezési módszer (amelyet analízis alapú tervezésnek is neveznek) számos, relációkba szervezett attribútumcsoportból indul ki, amelyek természetes módon összetartoznak, mint például egy számla, egy űrlap vagy egy jelentés. A relációkat ezután külön-külön és együtt is elemezzük, amely további dekompozíciókhoz vezet mindaddig, amíg el nem érjük az összes kívánt tulajdonságot. Az ebben a fejezetben tárgyalt elmélet mind a felülről lefelé, mind az alulról felfelé tervezési megközelítés esetében alkalmazható, de praktikusabb felülről lefelé való tervezéssel használni.
A fejezetet azzal kezdjük, hogy informálisan bemutatjuk a jó és a rossz relációsémák néhány ismertetőjegyét a 8.1. alfejezetben. A 8.2. alfejezetben definiáljuk a funkcionális függés fogalmát, amely egy attribútumok közötti formális megszorítás; ez a megszorítás a legfőbb eszköz arra, hogy formálisan megmérjük az attribútumok relációsémákba történő csoportosításának a megfelelőségét. A funkcionális függések tulajdonságait is tanulmányozzuk és elemezzük. A 8.3. alfejezetben a normálformákat és a funkcionális függéseken alapuló normalizálási folyamatot ismertetjük. Ezután további normálformákat definiálunk, hogy a relációsémák megfeleljenek bizonyos elvárt megszorításoknak, amelyeket funkcionális függésekkel fejezünk ki. A normalizálási eljárás a relációkra vonatkozó tesztek sorozatának az alkalmazásából áll, amelyek ellenőrzik, hogy a relációk megfelelnek-e ezeknek az egyre szigorodó követelményeknek, és ha szükséges, felbontják a relációkat. A 8.4. alfejezetben a normálformák általánosabb definícióit ismertetjük, amelyek közvetlenül alkalmazhatók bármely tervre, és nem igénylik a lépésről lépésre végrehajtott elemzést és normalizálást.
A 9. fejezetben folytatjuk a jó relációsémák tervezéséhez kapcsolódó elmélet tárgyalását. Ismertetjük a relációk dekompozíciójának elvárt tulajdonságait (nemadditív join tulajdonság és a funkcionális függések megőrzésének tulajdonsága), majd néhány algoritmus bemutatásával rátérünk az adatbázis-tervezés alulról felfelé történő megközelítésére. Ezek az algoritmusok bemenetként funkcionális függések egy halmazát kapják, és egy kívánt normálformájú relációs tervet eredményeznek, miközben betartják a fent említett elvárt tulajdonságokat. Bemutatunk egy általános algoritmust annak eldöntésére, hogy egy dekompozíció rendelkezik-e a veszteségmentes join tulajdonsággal. A 9. fejezetben további függéstípusokat és magasabb normálformákat is definiálunk, amelyek tovább javítják a relációsémák jóságát.
Azon olvasók, akik csak a normalizálás informális bevezetése iránt érdeklődnek, a 8.2.3. és 8.2.4. alfejezeteket átugorhatják. Ha a kurzus nem fedi le a 9. fejezetet, javasoljuk a 8. fejezeten kívül a dekompozíció elvárt tulajdonságainak gyors áttekintését a 9.1. alfejezetben, valamint a nemadditív join tulajdonság bináris dekompozíciók esetén történő tesztelésének az áttanulmányozását.
Mielőtt belekezdenénk a relációs adatbázis-tervezés formális elméletének tárgyalásába, ebben az alfejezetben négy, a relációs sématervezés minőségére vonatkozó informális mérőszámot mutatunk be:
az attribűtumok szemantikájának az érthetősége;
a rekordokban megjelenő redundáns információk mennyisége;
a rekordokban megjelenő NULL értékek mennyisége;
az álrekord-generálási lehetőség kizárása.
Ezek a mérőszámok nem teljesen függetlenek egymástól, ahogy majd látni fogjuk.
Amikor relációsémákba csoportosítjuk az attribútumokat, feltételezzük, hogy az egy relációhoz tartozó attribútumok egy bizonyos valós világbeli jelentéssel rendelkeznek, és megfelelő értelmezés társul hozzájuk. A relációk szemantikája a rekordokban megjelenő attribútumértékek értelmezését jelenti. Az 5. fejezetben megnéztük, hogy hogyan értelmezhetünk egy relációt tények egy halmazaként. Ha a 3. és 4. fejezetben leírt koncepcionális tervezést gondosan hajtjuk végre, és a 7. fejezetben leírt leképezési eljárást szisztematikusan követjük, akkor a relációséma-tervnek világos jelentéssel kell bírnia.
Általánosságban elmondható, hogy minél egyszerűbb megmagyarázni egy reláció szemantikáját, annál jobb a relációséma-terv. Ennek illusztrálására tekintsük a 8.1. ábrát, amelyen az 5.3. ábrán látható VÁLLALAT relációs adatbázisséma leegyszerűsített változata látható, valamint a 8.2. ábrát, amely e séma relációinak példa állapotait mutatja. A DOLGOZÓ relációséma jelentése roppant egyszerű: Minden rekord egy dolgozót reprezentál, egy-egy értékkel a dolgozó nevére (Dnév), személyi számára (Szsz), születési dátumára (Szdátum), címére (Lakcím), valamint azon osztály számára (Oszám) vonatkozóan, ahol a dolgozó dolgozik. Az Oszám attribútum külső kulcs, amely egy, a DOLGOZÓ és az OSZTÁLY közötti implicit kapcsolatot jelképez. Az OSZTÁLY és a PROJEKT sémák szemantikája szintén egyértelmű: Az OSZTÁLY rekordjai egy-egy osztály egyedet, a PROJEKT rekordjai pedig egy-egy projekt egyedet reprezentálnak. Az OSZTÁLY Ovez_szsz attribútuma összekapcsolja az osztályt azzal a dolgozóval, aki az adott osztály vezetője, a PROJEKT Oszám attribútuma pedig összekapcsolja a projektet az őt irányító osztállyal. Mindkettő külső kulcs attribútum. Az a könnyedség, amellyel a relációk attribútumainak a jelentését elmagyarázhatjuk, annak az informális mérőszáma, hogy milyen jól van megtervezve a reláció.
A 8.1. ábrán látható másik két relációséma szemantikája egy kicsit össszetettebb. A OSZT_HELYSZÍNEK rekordjai egy osztályszám (Oszám) mellett az adott osztály helyszíneinek egyikét (Ohelyszín) tartalmazzák. A DOLGOZIK_RAJTA rekordjai tárolják a dolgozó személyi számát (Szsz), azon projektek egyikének a számát, amelyeken az adott dolgozó dolgozik (Pszám), valamint azt az időtartamot, ahány órát az adott dolgozó hetente az adott projekten dolgozik (Órák). Mindkét sémának azonban jól definiált és egyértelmű értelmezése van. Az OSZT_HELYSZÍNEK séma az OSZTÁLY egy többértékű attribútumát reprezentálja, míg a DOLGOZIK_RAJTA egy M:N kapcsolatot ír le a DOLGOZÓ és a PROJEKT között. A 8.1. ábrán látható összes relációséma tehát könnyen magyarázhatónak, ezért a tiszta szemantika szempontjából jónak tekinthető. Ezek alapján a következő informális tervezési irányelvet fogalmazhatjuk meg.
1. irányelv. Úgy kell megtervezni a relációsémákat, hogy könnyű legyen megmagyarázni a jelentésüket. Ne keverjük az attribútumokat több egyed- és kapcsolattípusból egy relációban. Intuitívan elmondható, hogy ha egy relációséma megfelel egy egyedtípusnak vagy egy kapcsolattípusnak, akkor könnyen értelmezhető és magyarázható a jelentése. Egyébként ha a reláció több egyed és kapcsolat keverékének felel meg, akkor az szemantikailag félreérthető lehet, és ezért a relációt nem lehet olyan könnyen magyarázni.
A 8.3. (a) és (b) ábrán látható relációsémák szintén tiszta szemantikával rendelkeznek. (Az olvasó most figyelmen kívül hagyhatja a relációsémák alatti vonalakat; azok arra szolgálnak, hogy illusztrálják a funkcionális függések jelölését, amelyről a 8.2. alfejezetben lesz szó.) A 8.3. (a) ábrán látható DOLG_OSZT relációséma relációinak egy rekordja egy dolgozót reprezentál, de további információkat is tartalmaz — nevezetesen annak az osztálynak a nevét (Onév), ahol a dolgozó dolgozik, valamint az osztályvezető személyi számát (Ovez_szsz). A 8.3. (b) ábrán látható DOLG_PROJ relációséma relációinak egy rekordja összekapcsol egy dolgozót egy projekttel, de tartalmazza a dolgozó nevét (Dnév), a projekt nevét (Pnév) és a projekt helyszínét (Phelyszín) is. Bár ezzel a két relációsémával logikailag semmi gond nincs, hibás terveknek minősülnek, mert megsértik az 1. irányelvet azáltal, hogy különböző valós világbeli egyedek attribútumait keverik; a DOLG_OSZT a dolgozók és az osztályok, a DOLG_PROJ pedig a dolgozók, a projektek és a DOLGOZIK_RAJTA kapcsolat attribútumait keveri. Használhatók nézetként, de problémákat okozhat, ha alaprelációként használjuk őket, ahogy az a következő alfejezetből kiderül.
A sématervezés egyik célja, hogy minimalizálja az alaprelációk (és ezáltal a hozzájuk tartozó állományok) tárigényét. Az attribútumok relációsémákba történő csoportosításának jelentős hatása van a tárigényre. Hasonlítsuk össze például a 8.2. ábrán látható DOLGOZÓ és OSZTÁLY alaprelációk által elfoglalt tárhelyet a 8.4. ábrán látható DOLG_OSZT alaprelációéval, amely a DOLGOZÓ-ra és az OSZTÁLY-ra alkalmazott természetes összekapcsolás eredménye.
8.4. ábra - Példa állapotok a 8.2. ábra relációira alkalmazott természetes összekapcsolással kapott DOLG_OSZT és DOLG_PROJ relációkhoz. Ezek hatékonysági szempontok miatt alaprelációként tárolhatók.
A DOLG_OSZT-ban az egy konkrét osztályhoz (Oszám, Onév, Ovez_szsz) tartozó attribútumértékek az adott osztályon dolgozó minden egyes alkalmazottnál megismétlődnek. Ezzel szemben az egyes osztályokra vonatkozó információk csak egyszer jelennek meg a 8.2. ábra OSZTÁLY relációjában. Csak az osztály száma (Oszám) ismétlődik a DOLGOZÓ relációban külső kulcsként minden olyan dolgozónál, aki az adott osztályon dolgozik. Hasonló megjegyzéseket tehetünk a DOLG_PROJ relációra (lásd a 8.4. ábrát), amely kiegészíti a DOLGOZIK_RAJTA relációt a DOLGOZÓ és a PROJEKT egyes attribútumaival.
Egy másik súlyos probléma a 8.4. ábrán látható relációk alaprelációként történő felhasználásával a karbantartási anomáliák problémája. Ezeket csoportosíthatjuk beszúrási, törlési és módosítási anomáliákra.[27]
Beszúrási anomáliák . A beszúrási anomáliáknak két típusát különböztethetjük meg, amelyeket a következő példákkal szemléltetünk a DOLG_OSZT relációban:
Ahhoz, hogy egy új dolgozó rekordot szúrjunk be a DOLG_OSZT-ba, vagy annak az osztálynak az attribútumértékeit kell megadni, ahol ez a dolgozó dolgozik, vagy pedig NULL-okat (ha a dolgozó még semelyik osztályon sem dolgozik). Ahhoz például, hogy beszúrjunk egy új rekordot egy olyan dolgozóval, aki az 5-ös számú osztályon dolgozik, úgy kell megadnunk az 5-ös osztályhoz tartozó attribútumértékeket, hogy konzisztensek legyenek a DOLG_OSZT más rekordjaiban található, az 5-ös osztályhoz tartozó értékekkel. A 8.2. ábrán látható terv esetén nem kell aggódnunk emiatt a konzisztenciaprobléma miatt, mert a dolgozó rekordjában csak az osztály számát adjuk meg; az 5-ös osztályra vonatkozó minden más attribútumértéket csak egyszer szerepeltetünk az adatbázisban, az OSZTÁLY reláció rekordjaként.
A DOLG_OSZT relációba nehézkes új osztály beszúrni, ahol még egyetlen dolgozó sem dolgozik. Ennek az egyetlen módja az, ha NULL értékeket írunk a dolgozó attribútumaihoz. Ez azért okoz problémát, mert az Szsz a DOLG_OSZT elsődleges kulcs, és minden rekordnak egy dolgozó egyedet kellene reprezentálnia, nem pedig egy osztály egyedet. Ráadásul amikor az első dolgozót hozzárendeljük ehhez az osztályhoz, onnantól kezdve nincs szükségünk erre a NULL értékeket tartalmazó rekordra. Ez a probléma nem lép fel a 8.2. ábrán látható terv esetén, mert az osztályt az OSZTÁLY relációba visszük be, akár dolgozik ott dolgozó, akár nem, és ha egy dolgozót hozzárendelünk ehhez az osztályhoz, akkor a megfelelő rekordot a DOLGOZÓ-ba szúrjuk be.
Törlési anomáliák . A törlési anomáliák a fent leírt második beszúrási anomáliához kapcsolódnak. Ha egy olyan dolgozó rekordot törlünk ki a DOLG_OSZT-ból, amely az utolsó, egy adott osztályon dolgozó alkalmazottat reprezentálja, akkor elveszítjük az adott osztályra vonatkozó információkat az adatbázisból. Ez a probléma nem merül fel a 8.2. ábrán látható adatbázisban, mert az OSZTÁLY rekordokat külön tároljuk.
Módosítási anomáliák . Ha a DOLG_OSZT-ban módosítjuk egy konkrét osztály valamely attribútumának az értékét (például az 5-ös számú osztály vezetőjét), akkor az összes olyan rekordot módosítanunk kell, amely az adott osztályon dolgozó alkalmazotthoz tartozik; máskülönben az adatbázis inkonzisztenssé válik. Ha nem módosítunk néhány rekordot, akkor ugyanazon osztályra vonatkozóan az osztályvezető személyi száma két különböző értéket fog fölvenni a különböző dolgozó rekordokban, és ez helytelen lenne.[28]
A felsorolt három anomália alapján felírhatjuk a következő irányelvünket.
2. irányelv. Az alaprelációk sémáit úgy kell megtervezni, hogy a relációkban ne forduljanak elő beszúrási, törlési és módosítási anomáliák. Ha mégis lennének anomáliák, akkor azokat világosan jelezzük, és győződjünk meg róla, hogy az adatbázist módosító programok helyesen működnek.
A második irányelv konzisztens az első irányelvvel, és annak egyfajta átfogalmazott változata. Láthatjuk azt is, hogy szükségünk van egy formálisabb megközelítésre ahhoz, hogy eldöntsük, hogy egy terv megfelel-e ezeknek az irányelveknek. A 8.2-től 8.4-ig tartó alfejezetek fogják megadni nekünk ezeket a formális fogalmakat. Fontos azonban megjegyeznünk, hogy ezeket az irányelveket néha muszáj megsértenünk, hogy növeljük bizonyos lekérdezések hatékonyságát. Ha például egy fontos lekérdezés egy dolgozó osztályáról és a dolgozó attribútumairól kér le információkat, akkor a DOLG_OSZT sémát használhatjuk alaprelációként. Ekkor azonban a DOLG_OSZT-ban lévő anomáliákat figyelembe kell vennünk és számolnunk kell velük úgy, hogy amennyiben az alapreláció módosul, ne maradjon inkonzisztencia az adatbázisban (például triggerek vagy tárolt eljárások használatával, amelyek automatikus módosításokat hajtanak végre). Általánosságban tanácsos anomáliamentes alaprelációkat használni, és nézeteket megadni a fontos lekérdezésekben gyakran hivatkozott attribútumok összekapcsolására. Ezzel csökkenthetjük a lekérdezésekben szereplő összekapcsolási műveletek számát, egyszerűbbé téve ezzel a lekérdezés helyes felírását, ráadásul sok esetben ez a hatékonyságot is növeli.[29]
Bizonyos sématervekben sok attribútumot csoportosítunk egy „kövér” relációba. Ha sok olyan attribútum van, amely nem értelmezhető a reláció minden rekordjában, akkor azokban a rekordokban rengeteg NULL értéket kapunk. Ez a tárolási szinten helypazarlást jelent, és problémát fog okozni az attribútumok jelentésének a megértése, illetve logikai szinten az összekapcsolások megadása.[30] Egy másik probléma a NULL-okkal, hogy hogyan kezeljük őket az olyan csoportosító műveletekkel, mint például a COUNT vagy a SUM. A szelekció és az összekapcsolás művelete összehasonlításokat tartalmaznak. Ha NULL értékek vannak jelen, az eredmény megjósolhatatlan lesz. Ráadásul a NULL-ok többféle értelmezésben szerepelhetnek, amelyek a következők:
Az attribútum nem értelmezhető ebben a rekordban.
Nem tudjuk, hogy az attribútum értéke ebben a rekordban létezik-e.
Az érték létezik, de hiányzik, azaz még nem rögzítettük.
Mivel minden NULL-t ugyanúgy reprezentálunk, ezzel összemossuk a lehetséges különböző jelentéseit. Ezért egy újabb irányelvet fogalmazhatunk meg.
3. irányelv. Amennyire csak lehetséges, ne tegyünk az alaprelációkba olyan attribútumokat, amelyek gyakran vesznek fel NULL értéket. Ha a NULL-ok elkerülhetetlenek, akkor győződjünk meg róla, hogy csak kivételes esetekben alkalmazzuk, nem pedig a reláció rekordjainak többségében.
A tárhely hatékony kihasználása és az összekapcsolások elkerülése az a két egymásnak ellentmondó követelmény, amelyek meghatározzák, hogy bevegyük-e a NULL értékeket tartalmazó oszlopokat a relációba, vagy külön relációt hozzunk létre ezen oszlopok számára (a megfelelő kulcs oszlopokkal együtt). Ha például csak a dolgozók 10%-ának van külön irodája, akkor nehéz megindokolni, hogy bevegyünk egy Szobaszám attribútumot a DOLGOZÓ relációba; ehelyett inkább egy DOLG_SZOBÁK(Dszsz, Szobaszám) relációt hozhatunk létre, kizárólag a külön irodával rendelkező dolgozókhoz tartozó rekordokkal.
Tekintsük a 8.5. (a) ábrán látható DOLG_HELYSZÍNEK és DOLG_PROJ1 relációsémákat, amelyeket a 8.3. (b) ábrán látható egyetlen DOLG_PROJ reláció helyett használhatunk. A DOLG_HELYSZÍNEK egy rekordja azt jelenti, hogy a Dnév nevű alkalmazott egy olyan projekten dolgozik, amelynek a helyszíne Phelyszín. A DOLG_PROJ1 egy rekordja azt a tényt írja le, hogy az Szsz személyi számú dolgozó Órák órát dolgozik hetente azon a projekten, amelynek a neve, száma és helyszíne Pnév, Pszám és Phelyszín. A 8.5. (b) ábra a DOLG_HELYSZÍNEK és a DOLG_PROJ1 relációállapotait mutatja, amelyek a 8.4. ábrán látható DOLG_PROJ relációnak felelnek meg, és amelyeket a DOLG_PROJ-ra alkalmazott megfelelő projekció (π) műveleteket alkalmazva kapunk meg (egyelőre tekintsünk el a 8.5. (b) ábrán látható szaggatott vonalaktól).
8.5. ábra - A 8.3. (b) ábra DOLG_PROJ relációjának különösen rossz terve. (a) A DOLG_HELYSZÍNEK és a DOLG_PROJ1 relációsémák. (b) A 8.4. ábra DOLG_PROJ relációjának a DOLG_HELYSZÍNEK és DOLG_PROJ1 relációkra történő vetítésének az eredménye.
Tételezzük fel, hogy a DOLG_PROJ helyett a DOLG_PROJ1-et és a DOLG_HELYSZÍNEK-et használjuk alaprelációkként. Ez egy különösen rossz sématervet eredményez, mivel a DOLG_PROJ1-ből és a DOLG_HELYSZÍNEK-ből nem tudjuk visszanyerni azokat az információkat, amelyek eredetileg a DOLG_PROJ-ban voltak. Ha megkísérlünk végrehajtani egy természetes összekapcsolást a DOLG_PROJ1 és a DOLG_HELYSZÍNEK relációkra, akkor az eredmény sokkal több rekordot fog tartalmazni, mint amennyi eredetileg a DOLG_PROJ-ban volt. A 8.6. ábrán csak a 8.5. (b) ábra szaggatott vonalai fölötti rekordokra alkalmazott összekapcsolás eredményét láthatjuk (hogy csökkentsük az eredményül kapott reláció méretét). Azokat az extra rekordokat, amelyek nem szerepltek a DOLG_PROJ-ban, álrekordoknak nevezzük, mert érvénytelen, hamis információkat reprezentálnak. A 8.6. ábrán csillaggal (*) jelöltük az álrekordokat.
8.6. ábra - A 8.5. ábra DOLG_PROJ1 és DOLG_HELYSZÍNEK relációinak a szaggatott vonalak fölötti rekordjaira alkalmazott természetes összekapcsolás eredménye. A kapott álrekordokat csillaggal jelöltük meg.
A DOLG_PROJ felbontása a DOLG_HELYSZÍNEK-re és a DOLG_RPOJ1-re nem célszerű, mert ha összekapcsoljuk őket egy természetes összekapcsolással, akkor nem kapjuk vissza az eredeti helyes információkat. Ez azért van, mert ebben az esetben a Phelyszín az az attribútum, amely összekapcsolja a DOLG_HELYSZÍNEK-et és DOLG_PROJ1-et, és a Phelyszín nem elsődleges kulcs és nem is külső kulcs sem a DOLG_HELYSZÍNEK-ben, sem a DOLG_PROJ1-ben. Ezek után informálisan kimondhatunk egy újabb tervezési irányelvet.
4. irányelv. Úgy kell megtervezni a relációsémákat, hogy oly módon lehessen őket összekapcsolni (elsődleges kulcs, kulső kulcs) attribútumpárok egyenlősége alapján, amely garantálja, hogy nem keletkeznek álrekordok. Kerüljük azokat a relációkat, amelyek olyan, azonos szerepű attribútumokat tartalmaznak, amik nem (külső kulcs, elsődleges kulcs) kombinációk, mert az ilyen attribútumok alapján történő összekapcsolás álrekordokat eredményezhet.
Ezt az informális irányelvet nyilván formálisabban is meg kell fogalmazni. A 9. fejezetben ismertetünk egy formális feltételt, amit nemadditív (vagy veszteségmentes) join tulajdonságnak hívunk, és amely garantálja, hogy bizonyos összekapcsolások nem állítanak elő álrekordokat.
A 8.1-től 8.4-ig terjedő alfejezetekben informálisan ismertettünk olyan szituációkat, amelyek problémás relációsémákhoz vezetnek, és informális irányelveket javasoltunk a jó relációs tervezéshez. A bemutatott problémák, amelyek további elemző eszközök nélkül is felismerhetők, az alábbiak:
anomáliák, amelyek felesleges munkát okoznak egy relációba való beszúrás, illetve egy reláció módosítása folyamán, és amelyek információk véletlen elvesztését okozhatják egy relációból való törlés folyamán;
tárpazarlás, valamint a szelekciós, a csoportosítási és az összekapcsolási műveletek elvégzésének a nehézsége a NULL értékeknek köszönhetően;
érvénytelen és hamis adatok előállítása nem megfelelően kapcsolódó alaprelációk összekapcsolása során.
A fejezet további részében olyan formális fogalmakat és elméletet ismertetünk, amelyeket arra használhatunk, hogy segítségükkel különálló relációsémák jóságát és rosszaságát precízebben definiáljuk. Először a funkcionális függést mint az elemzés egy eszközét ismertetjük. Ezután a relációsémákra vonatkozó három normálformáról és a Boyce–Codd-normálformáról írunk. A 9. fejezetben további normálformákat definiálunk, amelyek az adatfüggés újabb típusain, a többértékű függésen és a kapcsolásfüggésen alapulnak.
[26] Egy kivétel, amelynél mégis ezt a megközelítést alkalmazzák a gyakorlatban, azon a modellen alapul, amelyet bináris relációs modellnek hívnak. Példa rá a NIAM módszer (Verheijen és van Bekkum, 1982).
[27] Ezeket az anomáliákat Codd (Codd (1972)) azonosította, hogy legalizálja a relációk normalizálásának szükségességét, amelyről a 8.3. alfejezetben fogunk beszélni.
[28] Ez nem annyira komoly probléma, mint a többi, mivel az összes rekordot egyetlen SQL utasítással módosíthatjuk.
[29] A több alaprelációt összekapcsoló nézeteken alapuló lekérdezések hatékonysága attól függ, hogy a DBMS hogyan implementálja a nézetet. Sok RDBMS materializálja a gyakran használt nézeteket, és így nem olyan gyakran kell végrehajtaniuk az összekapcsolásokat. A DBMS felelős azért, hogy a materializált nézeteket aktualizálja (azonnal vagy periodikusan), valahányszor az alaprelációk módosulnak.
[30] Ez azért van, mert a belső és külső összekapcsolások különböző eredményt adnak, ha NULL-ok is érintettek az összekapcsolásban. A felhasználóknak ezért tisztában kell lenniük a különböző összekapcsolás-típusok jelentésével. Bár a hozzáértő felhasználók számára ez ésszerű lehet, mások számára azonban nem feltétlenül az.