Relációs adatmodell és normalizálás

Az ER-modell azt fogalmazza meg, milyen dolgokat és kapcsolatokat tartunk nyilván. A relációs modell ehhez logikai táblaszerkezetet ad: megnevezi a relációkat, az attribútumokat, az azonosítókat és a hivatkozásokat. Még nem a lemezen elfoglalt helyet vagy az indexek fizikai felépítését tervezzük. A logikai modell alapján később konkrét adatbázis-kezelőben hozhatjuk létre a táblákat.

Egy rekord egy konkrét tényt ír le. A KURZUS reláció egyik sora például a C11 azonosítójú Webes arculat kurzus adatait tartalmazza. A kurzus címe attribútum, a Webes arculat ennek egy értéke. A mező kifejezést a gyakorlatban gyakran az oszlopra használjuk; egy konkrét cella az adott rekord adott attribútumának értékét mutatja.

A reláció fokszáma az attribútumainak száma, kardinalitása pedig a benne lévő rekordok száma. A fejléc nem adatrekord. Az alábbi reláció fokszáma 4, kardinalitása 3. Új kurzus felvételekor a kardinalitás változik, a fokszám ugyanannyi marad; új attribútum bevezetése a sémát módosítja.

Az értéktartomány, más néven domén, az attribútum megengedett értékeit írja le. A férőhely egész szám, nálunk 1 és 40 közötti értékkel; a kurzusazonosító szöveges kód; a cím nem üres szöveg. Az adattípus a technikai lehetőségeket, az üzleti szabály pedig a ténylegesen elfogadható értékeket határozza meg. Egy egész számos oszlop önmagában még nem tiltja a negatív férőhelyet.

A matematikai reláció halmaz: nincs benne két azonos sor, és a sorok sorrendje nem hordoz jelentést. Az attribútumot a neve azonosítja, nem a képernyőn elfoglalt helye. SQL-táblákban és lekérdezési eredményekben megfelelő korlátozás vagy DISTINCT nélkül ismétlődés is előfordulhat; a gyakorlati megvalósítást ezért tudatosan kell a logikai modellhez igazítani.

A tervezéskor a kulcsjelöltek közül egyet elsődleges kulcsnak választunk. A többi kulcsjelölt alternatív kulcs. A minimális itt nem azt jelenti, hogy az összes jelölt közül a legkevesebb oszlopot tartalmazza: azt jelenti, hogy az adott jelöltnek nincs fölösleges összetevője. Egy egyoszlopos és egy kétoszlopos minimális jelölt egyaránt lehet érvényes.

Az elsődleges kulcs nem ismétlődhet és nem tartalmazhat hiányzó értéket. Jó választás, ha stabil, rövid és minden rekordhoz rendelkezésre áll. A név általában rossz azonosító: két embernek lehet azonos neve, és a név megváltozhat. A mesterséges tanuló_id azonosító megoldja az azonosítást, de önmagában nem tiltja, hogy ugyanazt a személyt tévedésből kétszer vegyük fel.

Összetett kulcsról beszélünk, ha több attribútum együtt szükséges az egyértelmű azonosításhoz. A JELENTKEZÉS relációban a (tanuló_id, kurzus_id) pár megfelelő, ha ugyanaz a tanuló ugyanarra a konkrét kurzuskiírásra legfeljebb egyszer jelentkezhet. Egyik oszlop sem elegendő önmagában. Ha ugyanarra a kiírásra ismételt jelentkezéseket is megőrzünk, más azonosítást kell választani, vagy az esemény sorszámával kell bővíteni a kulcsot.

Az idegen kulcs egy reláció egy vagy több attribútuma, amely egy hivatkozott reláció kulcsértékéhez kapcsolódik. A kurzus oktató_id mezője az OKTATÓ oktató_id kulcsára hivatkozik. A hivatkozott kulcs lehet elsődleges vagy megfelelő egyediségi korlátozással védett alternatív kulcs. Összetett kulcsra a teljes, megfelelő sorrendű és kompatibilis értéktípusú oszlopkombinációval kell hivatkozni.

Az idegen kulcs értéke rendszerint ismétlődhet: több kurzusnak lehet ugyanaz az oktatója. Hiányzó értéket csak akkor engedünk meg, ha a kapcsolat opcionális. Egy kurzushoz itt kötelező oktatót rendelni, ezért az oktató_id nem lehet NULL. Az idegen kulcs oszlopának puszta elnevezése még nem biztosítja a hivatkozások érvényességét; a megvalósításban korlátozást is létre kell hozni.

A tervet rekordok nélkül is megadhatjuk: OKTATÓ(oktató_id, név, email), KURZUS(kurzus_id, cím, férőhely, oktató_id). A kulcsot aláhúzással vagy PK felirattal jelölhetjük. Az idegen kulcsot FK jelölés, a hivatkozott reláció és a célattribútum megnevezése teszi félreérthetetlenné. Fontosabb az egyértelmű jelmagyarázat, mint egy adott rajzolóprogram használata.

A diagramon a nyíl a hivatkozó idegen kulcstól a hivatkozott kulcs felé mutat. Ez a hivatkozás iránya, nem időbeli folyamat vagy adatmozgás. Az oktató–kurzus kapcsolat 1:N: egy kurzus pontosan egy oktatóhoz tartozik, egy oktató pedig nulla vagy több kurzust vezethet. A nyilak mellett a részvétel minimumát és maximumát külön is megadhatjuk.

Az egyedintegritás az elsődleges kulcs egyediségét és hiánytalanságát biztosítja. A hivatkozási integritás azt mondja ki, hogy a nem hiányzó idegenkulcs-értékhez létezzen megfelelő hivatkozott rekord. Az értéktartomány-integritás a típusokat és megengedett értékeket védi. Üzleti szabály például az is, hogy egy pontszám 0 és 100 között lehet.

Mi történjen, ha törölnénk azt az oktatót, akinek még kurzusai vannak? Több érvényes döntés létezik, de ezeket előre rögzíteni kell. Nálunk a törlést elutasítjuk, amíg át nem adjuk a kurzusokat más oktatónak. A kapcsolódó kurzusok automatikus törlése olyan adatvesztést okozna, amelyet ez a nyilvántartás nem kíván. Az automatikus törlés csak megfelelő üzleti indokkal használható.

A tanuló_id → tanulónév függés a nyilvántartás szabálya: ugyanazon azonosítóhoz ugyanabban az állapotban egy név tartozik. A fordított függés nem feltétlenül igaz, mert különböző tanulóknak lehet azonos nevük. A függés nem azt jelenti, hogy a név számítással előállítható az azonosítóból; azt jelenti, hogy az azonosító ismeretében egyértelműen megtaláljuk.

Egy mintatáblából függést biztosan cáfolhatunk: két azonos X mellett különböző Y ellenpélda. Néhány sorból azonban általában nem bizonyíthatjuk a szabályt. Ha a jelenlegi kurzuscímek különböznek, attól még nem lesz cím → kurzus_id függés: később azonos című új kiírás is készülhet. A függéseket a teljes életciklusra érvényes követelményekből vezetjük le.

Y teljesen függ X-től, ha X meghatározza Y-t, de X egyetlen valódi részhalmaza sem elegendő ehhez. A jelentkezés dátuma teljesen függ a (tanuló_id, kurzus_id) pártól: ugyanaz a tanuló különböző kurzusokra különböző napokon jelentkezhet, és ugyanarra a kurzusra a tanulók sem szükségképpen egyszerre jelentkeznek.

Részleges függésnél az összetett meghatározó egy kisebb része is elegendő. A tanulónév a jelentkezési táblában függ a teljes kulcspártól is, de már a tanuló_id önmagában meghatározza. Ezért az összetett kulcshoz képest részlegesen függ. Hasonlóan a kurzuscím a kurzus_id-től függ; nem kell hozzá a tanuló.

Tranzitív függés láncolatban jelenik meg. Ha kurzus_id → oktató_id és oktató_id → oktatónév, akkor kurzus_id → oktatónév is következik. A normalizálás szempontjából akkor problémás a közvetítő, ha nem a reláció kulcsa: az oktató neve így minden hozzá tartozó kurzusban újra megjelenik. Nem minden logikai következtetési lánc jelent automatikusan 3NF-sértést; a kulcsokat és a függő attribútumokat is vizsgálni kell.

Képzeljünk el egy képzési központot, amely a tanulókat, kurzuskiírásokat, oktatókat és jelentkezési eredményeket egyetlen nagy táblába írja. Minden új jelentkezéskor újra begépeli a tanuló és a kurzus adatait, valamint az oktató nevét és emailcímét. Egy 20 fős kurzus oktatói emailcíme akár 20 sorban ismétlődik; több kurzus esetén még többször.

A redundancia nem egyszerűen azt jelenti, hogy valamilyen érték többször látható. Az O7 idegen kulcs ismétlődése a különböző kurzusokban szükséges kapcsolatot fejez ki. Az O7-hez tartozó emailcím külön tárolt másolatai viszont ugyanazt az oktatói tényt ismétlik, ezért eltérhetnek egymástól. A tervezés célja az, hogy minden tény a megfelelő helyre kerüljön.

Módosítási anomália: Barta Nóra emailcímének változásakor minden érintett sort frissíteni kell. Ha egyet kihagyunk, a nyilvántartás ellentmondásos lesz. Beszúrási anomália: egy új, még jelentkező nélküli kurzust nem tudunk szabályosan felvenni, ha az egyetlen tábla kulcsa tanulót is megkövetel. Törlési anomália: az utolsó jelentkezés törlésekor véletlenül a kurzus és oktató adatai is eltűnhetnek.

A normalizálás során különválasztjuk a különböző tárgyú tényeket, majd kulcsokkal kötjük össze őket. Nem elég azonban „minél több táblát” készíteni. Minden bontást meg kell indokolni, a kulcsokat meg kell őrizni, és meg kell vizsgálni, visszaállítható-e az eredeti információ. A tárolási igény csökkenhet, de az elsődleges cél a következetes és karbantartható szerkezet; a több kulcs és index miatt a fizikai méret nem minden esetben lesz kisebb.

Egy feliratkozási lapon Mira mellé ezt írjuk a kurzusok cellába: „C11, C12”, a pontszámokhoz pedig „85, 72”. A jelentkezések így listákba kerülnek. Nem tudunk egyetlen kurzusra megbízhatóan szűrni, és két párhuzamos lista esetén könnyen felcserélődhet, melyik eredmény melyik kurzushoz tartozik. A kurzus1, kurzus2, kurzus3 oszlopok szintén ismétlődő csoportot alkotnak és önkényes felső korlátot vezetnek be.

Az 1NF kialakításakor minden konkrét jelentkezést saját sorba teszünk. Mira két jelentkezése két sor lesz, a tanuló adatai ekkor még megismétlődnek. A kurzus és az eredmény összetartozását megőrizzük: nem állítunk elő minden kurzus–pontszám kombinációt. Az atomi sorokra bontás nem jelenti egymástól független listák vak összeszorzását.

A táblánkat a (tanuló_id, kurzus_id) kulcspár azonosítja. Mira azonosítója kétszer szerepelhet, a C11 kurzushoz több tanuló tartozhat, de a T101–C11 pár csak egyszer jelenik meg. A név, cím és oktatói adatok ismétlődése még nem sérti az 1NF feltételeit: ezeket a következő normálformák segítségével rendezzük.

Az atomiság a feladattól függ. Egy szöveg karakterekre bontható, mégis kezelhető egyetlen értékként. A tanulónév maradhat egy mező, ha a rendszer egész névként használja. Ha a vezetéknév és keresztnév külön feldolgozási cél, külön attribútumokat tervezünk. A vessző jelenléte önmagában nem bizonyít többértékűséget; a cella jelentését kell megvizsgálni.

A sémában minden rekord ugyanazokhoz az attribútumokhoz tartozik, és az attribútumnevek egy reláción belül egyértelműek. Egy képernyőn használt rendezés nem része az 1NF logikai követelményeinek. SQL-ben a sorok azonosítására PK vagy megfelelő UNIQUE és NOT NULL korlátozásokat használunk; a kimenet rendezését külön ORDER BY írja elő.

A nagy jelentkezési tábla összetett kulcsának két része van: tanuló_id és kurzus_id. A tanulónév csak az elsőtől, a kurzuscím és oktatói adatok csak a másodiktól függenek. A jelentkezés_dátuma és pontszám viszont a kettő együttese alapján határozható meg. A bontás során az egymáshoz tartozó adatokat a megfelelő meghatározóval együtt emeljük külön relációba.

Létrehozzuk a TANULÓ relációt tanuló_id elsődleges kulccsal. Ebben a tanuló nevét csak egyszer tároljuk. A KURZUS_2NF relációba a kurzus kiírásadatai és egyelőre az oktató adatai kerülnek, kurzus_id kulccsal. A JELENTKEZÉS a két azonosítót, a jelentkezés dátumát és a pontszámot őrzi. Ebben mindkét azonosító idegen kulcs is: külön-külön hivatkoznak a megfelelő törzsadatokra.

A JELENTKEZÉS összetett elsődleges kulcsa és két külön idegen kulcsa nem ugyanaz a korlátozás. A PK a párok egyediségét, a két FK a létező tanulót és kurzust biztosítja. Ha a két oszlopot külön-külön UNIQUE-nak tennénk, megtiltanánk, hogy egy tanuló több kurzusra járjon, illetve hogy egy kurzusra több tanuló jelentkezzen.

A bontás után egy tanuló újabb jelentkezésekor nem kell újra rögzíteni a nevét. A kurzus jelentkezés nélkül is tárolható. Ugyanakkor az oktató neve több külön kurzus sorában továbbra is ismétlődhet: a 2NF ezt még nem szünteti meg, mert a tranzitív függések a következő lépés tárgyai.

Ha minden kulcsjelölt egyetlen attribútumból áll, részleges függés nem lehet: a nem kulcsattribútumot nem határozhatja meg a kulcs valamely nem üres, kisebb része. Az, hogy csak a kiválasztott PK egyoszlopos, még nem elég: egy másik, összetett kulcsjelölt miatt is vizsgálni kell a részleges függést. Ezért a kulcsjelöltek feltárása megelőzi a normálforma megállapítását.

A KURZUS_2NF táblában a kurzus_id meghatározza az oktató_id-t, az oktató_id pedig az oktató nevét és emailcímét. Az oktató_id nem kulcs ebben a táblában: O7 több kurzusban szerepel. Az oktatónév és email nem kulcsattribútumok. Ez a függőség megsérti a 3NF feltételeit, és fennmaradó módosítási anomáliát eredményez.

Az oktató saját adatait külön OKTATÓ relációba helyezzük, oktató_id kulccsal. A KURZUS relációban a kurzus_id, kurzuscím és az oktató_id idegen kulcs marad. A TANULÓ és JELENTKEZÉS szerkezete ebben a lépésben nem változik. A végső modell négy relációból áll: TANULÓ, KURZUS, OKTATÓ és JELENTKEZÉS.

Az O7 oktató nevét és emailcímét most egyetlen helyen tároljuk. A C11 és C13 kurzus ezt az oktatót hivatkozza. Emailváltozáskor csak az OKTATÓ megfelelő rekordját kell módosítani. Egy még kurzushoz nem rendelt új oktató is felvehető, és egy kurzus törlése nem törli automatikusan az oktatót.

A megadott függőségek mellett mind a négy reláció 3NF-ben van. Az OKTATÓ-ban az id határozza meg a saját adatokat; a KURZUS-ban a kurzus id-je a címét és oktatóját; a TANULÓ-ban a tanuló id-je a nevét; a JELENTKEZÉS-ben a teljes páros kulcs a dátumot és eredményt. Az állítás a rögzített követelményekre épül, nem minden elképzelhető alkalmazásra.

A „minden függés csak az elsődleges kulcsból indulhat” mondat hasznos lehet a kezdő példákban, de általános 3NF-definíciónak túl erős. Alternatív kulcsok is meghatározhatnak adatokat, a pontos 3NF pedig bizonyos kulcsattribútumokra végződő függéseket is megenged. A minden nem triviális funkcionális függés meghatározóját szuperkulcsként megkövetelő szigorúbb forma a Boyce–Codd-normálforma, BCNF.

A tanfolyamok nyilvántartásához új igény érkezik: tudni szeretnénk, milyen oktatási nyelveken érhető el egy kurzus, és melyik eszközcsomag használható hozzá. A példában ez a két választás egymástól független. A C21 kurzus magyarul vagy angolul végezhető, és a résztvevő laptopot vagy tabletet választhat; mind a négy kombináció megengedett.

Egyetlen KURZUS_LEHETŐSÉG(kurzus_id, nyelv, eszköz) táblában ezért négy sor szükséges. A teljes hármas azonosítja a sort: a kurzus_id önmagában nem határoz meg egy nyelvet vagy eszközt, és a kurzus–nyelv párhoz is több eszköz tartozik. Ha nincs további funkcionális függés, ez a háromoszlopos reláció akár BCNF-ben is lehet, mégis fölöslegesen ismétli a két független tényt.

Ha egy harmadik eszközcsomagot vezetünk be, minden meglévő nyelv mellé új sort kell írnunk. Ha egy sor kimarad, a tábla tévesen azt sugallja, hogy az adott nyelv mellett az új eszköz nem választható. A függőség nem kurzus_id → nyelv, mert több nyelv van, hanem kurzus_id ↠ nyelv; hasonlóan kurzus_id ↠ eszköz.

Két relációra bontunk: KURZUS_NYELV(kurzus_id, nyelv) és KURZUS_ESZKÖZ(kurzus_id, eszköz). Mindkettőben a két oszlop együtt a kulcs. A kurzus_id idegen kulcsként egy külön KURZUS törzsrelációra hivatkozik. Nem a két kapcsolótábla egymásra hivatkozik kurzus_id-val, hiszen ez egyikben sem egyedi.

A függetlenség kulcsfontosságú feltétel. Ha angol oktatás csak laptopon, magyar pedig csak tableten lehetséges, a hármasokat nem szabad két független listára bontani: az összekapcsolás tiltott párokat hozna létre. Ilyenkor a nyelv–eszköz kombináció maga is tárolandó tény. A 4NF nem azt jelenti, hogy a táblában egyetlen többértékű attribútum sem szerepelhet: az 1NF-ben már atomi cellákkal dolgozunk, a 4NF a sorok közötti többértékű függéseket vizsgálja.

A jól normalizált modell több kisebb táblából áll. Ez megkönnyíti a karbantartást, de a kérdésekhez gyakran több reláció adatait kell felhasználni. A relációs műveletek adják meg, hogyan szűrjük, szűkítsük és kapcsoljuk össze az adatokat. Az eredmény is reláció, így további művelet bemeneteként használható.

A relációs kalkulus elsősorban azt fejezi ki, milyen feltételeknek megfelelő adatokat keresünk. Az algebra műveletek kombinációjával írja le az eredmény előállítását. Az SQL deklaratív lekérdezőnyelv: a kívánt eredményt adjuk meg, a végrehajtás fizikai módját a kezelő optimalizálja. Az alábbi algebrai jelölések tanulási eszközök, nem egy adott programban változtatás nélkül végrehajtható parancsok.

Átnevezésnél, RENAME vagy ρ művelettel, például a pontszám oszlopot eredménynek nevezzük az előállított relációban. A rekordok száma és a tárolt értékek nem változnak. Ez nem azonos az eredeti SQL-tábla szerkezetének tartós módosításával: lekérdezésben az AS álnév az eredmény fejlécét változtatja meg.

A korlátozás, RESTRICT vagy σ, az adott feltételt teljesítő teljes sorokat tartja meg. A pontszám ≥ 85 feltétel három sort választ ki a négyből. Az oszlopok száma változatlan. Összetett feltételnél ÉS, VAGY, illetve tagadás is használható, de ezek jelentését pontosan meg kell határozni.

A vetület, PROJECT vagy π, csak a kiválasztott attribútumokat őrzi meg. A kurzus_id vetülete a C11, C12 és C13 értékeket adja. A halmazalapú algebrában a két C11 eredménysor egyetlen sorrá válik. SQL-ben a SELECT kurzus_id alapból megtarthatja az ismétlődést; a halmazjellegű vetülethez SELECT DISTINCT kurzus_id használható. A szűrés és vetítés sorrendjét úgy válaszd, hogy a szükséges feltételattribútum ne vesszen el túl korán.

Egy nyílt napon két bemutatóterem és három idősáv közül választhatunk. Szeretnénk elkészíteni az összes lehetséges terem–idősáv párt, még az események tényleges beosztása előtt. A TEREM és IDŐSÁV relációk keresztszorzata éppen ezt a hat kombinációt adja.

A keresztszorzat még nem mondja meg, melyik kombinációt foglaltuk le. Csak lehetőségeket állít elő. Ha a két relációban azonos nevű attribútum van, előbb átnevezzük, vagy egyértelmű minősítéssel különböztetjük meg őket. Például terem.név és idősáv.név helyett használható teremnév és idősávnév.

Az eredmény azonosítható a két kiinduló reláció kulcsának együttesével. A példában (terem_id, sáv_id) kulcsjelölt. Az egyes kulcsrész önmagában ismétlődik, hiszen minden terem három időponthoz, minden időpont két teremhez kapcsolódik.

A méret gyorsan nő. Két 1000 és 10 000 rekordos reláció keresztszorzata 10 000 000 rekordot adhat. Ez nem azt jelenti, hogy egy adatbázis-kezelő minden JOIN esetén ténylegesen létrehozza az összes ilyen sort: a végrehajtás hatékonyabb lehet. Logikai értelemben azonban az összes lehetséges párosítás megértése segít az összekapcsolási feltétel jelentésének felismerésében.

Legyen A a robotika szakkörre, B a videókészítő szakkörre jelentkező tanulók azonosítóinak relációja. A két eredmény egy-egy tanuló_id attribútumot tartalmaz, azonos értéktartománnyal. Így értelmesen összehasonlíthatók. Ha az egyik táblában személyazonosítók, a másikban ugyanilyen típusú teremkódok szerepelnének, a technikailag hasonló oszlop nem biztosítana megfelelő jelentést.

A ∪ B a legalább egy szakkörre jelentkezőket adja. A közösen szereplő T102 csak egyszer jelenik meg, mert relációs halmazműveletet végzünk. SQL-ben az UNION eltávolítja a duplikált eredménysorokat, az UNION ALL viszont megőrzi őket. Ez utóbbi nem ugyanaz a halmazművelet.

A ∩ B azok azonosítóit adja, akik mindkét szakkörben jelen vannak. A − B csak a robotikára, de videókészítésre nem jelentkezőket adja. B − A más eredmény: a különbség nem felcserélhető. Az unió és metszet viszont a két bemenet felcserélésekor ugyanazt az eredményt adja.

A kompatibilitás azonos számú és megfelelően egymáshoz rendelt doménű attribútumot kíván. Az attribútumokat szükség esetén átnevezzük. SQL-ben a SELECT-listák megfelelő pozíciói alapján illesztjük az eredményeket, ezért az oszlopsorrend itt különösen fontos. A nevek egyezése önmagában nem elég, az értékek jelentését is egyeztetni kell.

Egyesítés után a korábbi kulcs egyedisége nem feltétlenül marad meg, ha a bemenetek eltérő, egymástól független azonosító-kiosztást használnak. Két szervezet „1” id-jű rekordja nem biztos, hogy ugyanazt a személyt jelenti. Ha azonos személyekről készítünk részlistákat ugyanabból a közös azonosítórendszerből, mint itt, akkor a tanuló_id következetes azonosító marad.

A normalizáláskor a kurzus és az oktató adatait szétválasztottuk. Most arra kérdezünk rá: melyik kurzusnak ki a felelős oktatója? A KURZUS minden sorához azt az OKTATÓ rekordot illesztjük, amelynek oktató_id értéke megegyezik a kurzusban tárolt idegen kulccsal.

A C11 kurzus O7-re hivatkozik, ezért Barta Nóra adatait kapja. A C12 O8-ra hivatkozik, így Varga Balázsét. A C13 ismét O7-re hivatkozik, ezért ugyanaz az oktató két külön eredménysorban jelenik meg. Az oktatói rekord tárolása egy helyen történik, de a lekérdezés több kurzus mellett is megjelenítheti az adatát.

A megfelelően érvényesített kötelező FK és az oktatói kulcs egyedisége miatt minden kurzushoz pontosan egy oktatói sor illeszkedik; ebben a példában három eredménysor lesz. A természetes kapcsolás eredményének fokszáma 3 + 3 − 1 = 5. Explicit SQL JOIN esetén a SELECT-lista határozza meg a megjelenő oszlopokat, így nem alkalmazható rá automatikusan ez a fokszámképlet.

A JOIN leírható keresztszorzat és korlátozás kombinációjaként: először elképzeljük az összes rekordpárt, majd kiválasztjuk azokat, ahol KURZUS.oktató_id = OKTATÓ.oktató_id. Az eredményből elhagyjuk a második, azonos értékű oktatóazonosító-oszlopot. Ez logikai felépítés, nem a végrehajtási terv kötelező formája.

Ha egy belső egyenlőségkapcsolásnál nincs illeszkedő érték, az érintett rekordhoz nem keletkezik eredménysor. Ha egyik rekordpár sem illeszkedik, az eredmény üres: nem keresztszorzat. A természetes kapcsolás közös attribútum nélküli különleges esetben ad keresztszorzatot, mert nincs megkötendő közös érték. LEFT JOIN-nál a bal oldali sor megmaradhat hiányzó jobb oldali értékekkel; ez külön művelet.

Veszélyes, ha két táblában véletlenül azonos nevű, de eltérő jelentésű oszlop szerepel. A természetes kapcsolás minden közös nevet figyelembe vesz. Gyakorlati lekérdezéseknél az explicit ON feltétel és megfontolt oszloplista jobban láthatóvá teszi a kívánt kapcsolatot. A KURZUS.név és OKTATÓ.név például nem kapcsolómező.

A veszteségmentesség nem azt jelenti, hogy az összes attribútum valahol megmaradt. Az értékek közötti összetartozást is meg kell őrizni. Ha csak azt jegyezzük fel, kik jártak kurzusra, és milyen pontszámok születtek, de elveszítjük a pontszám és jelentkezés kapcsolatát, a rekonstruált tábla téves eredményeket rendelhet a tanulókhoz.

A fő példában a JELENTKEZÉS tartalmazza a tanuló_id és kurzus_id értékeket, ezért a TANULÓ-val és KURZUS-sal pontosan tudjuk összekapcsolni. A kurzus megtartja az oktató_id-t, így az oktatói rész is helyesen rekonstruálható. Az eredeti négy jelentkezési rekord minden adatát visszakapjuk.

A mintarekordokkal végzett próbavisszakapcsolás hasznos, de a sémaszintű bizonyítást nem helyettesíti. Két relációra történő, funkcionális függőségekre épülő bontásnál elegendő feltétel, hogy a közös attribútumok meghatározzák legalább az egyik kapott reláció összes attribútumát. A kurzus_id meghatározza a kurzus saját adatait; a tanuló_id a tanulóét; az oktató_id az oktatóét.

A függőségmegőrzés azt jelenti, hogy az eredeti függőségeket a kapott kisebb relációkban ellenőrizhető szabályokból együtt is következtethetjük. Nem kell minden ellenőrzéshez nagy összekapcsolást végrehajtanunk. A tanuló_id → tanulónév a TANULÓ-ban, a kurzus_id → oktató_id a KURZUS-ban, az oktató_id → email az OKTATÓ-ban ellenőrizhető. A teljes jelentkezési kulcsra vonatkozó függés a JELENTKEZÉS-ben marad.

A rossz bontást álrekordok is elárulhatják. Tegyük fel, hogy T101 a C11-en 85, a C12-n 72 pontot kapott. Ha a tényeket TANULÓ_KURZUS(tanuló_id, kurzus_id) és TANULÓ_PONT(tanuló_id, pontszám) relációra bontjuk, a tanuló_id szerinti JOIN négy kombinációt eredményez. A C11–72 és C12–85 sorok sosem voltak valósak. Ez a példa különbözik a 4NF független listáitól: itt a pontszám nem független a kurzustól.

A formális jelölés nem új eljárás: ugyanazokat a lépéseket rövidebben mutatja. Az általános betűk helyett maradjunk a központi példa jelentéssel bíró rövidítéseinél. T a tanuló_id, C a kurzus_id, N a tanulónév, L a kurzuscím, O az oktató_id, V az oktatónév, E az oktatói_email, D a jelentkezés dátuma, P a pontszám.

A kiinduló R(T, C, N, L, O, V, E, D, P) reláció kulcsa {T, C}. A függések: T → N; C → L, O; O → V, E; (T, C) → D, P. Tranzitivitás miatt C → V, E is következik. A kulcs teljességét az ellenőrzi, hogy T önmagában több kurzussal, C önmagában több tanulóval fordulhat elő.

A 2NF alak: TANULÓ(T, N), KURZUS_2NF(C, L, O, V, E), JELENTKEZÉS(T, C, D, P). Kulcsaik rendre {T}, {C}, {T, C}. A kurzushoz tartozó összes oktatói adat ebben a lépésben még együtt marad, mert a részleges függéseket már megszüntettük, a tranzitív függést még nem.

A 3NF alakhoz az O → V, E függés alapján a KURZUS_2NF relációt KURZUS(C, L, O) és OKTATÓ(O, V, E) relációkra bontjuk. A másik kettő változatlan. A közös O meghatározza az OKTATÓ minden attribútumát, ezért ez a kétrelációs bontás veszteségmentes.

A kulcsjelöltek vizsgálatához attribútumlezárást is használhatunk. X⁺ azoknak az attribútumoknak a halmaza, amelyeket a megadott függésekből X alapján meghatározhatunk. A {T, C} lezárása tartalmazza T-t, C-t, majd N-t, L-t, O-t, V-t, E-t, D-t és P-t: az egész sémát. T lezárása csak T és N, C lezárása C, L, O, V és E. Ezért egyik kulcsrész sem azonosít önmagában minden adatot.

A gyakorlati vizsgálatot az adatok jelentésével kezdjük. Először felsoroljuk, milyen tényeket kell tárolni, majd megadjuk az azonosítókat és a függéseket. Ezután ellenőrizzük a többértékű cellákat, a részleges és tranzitív függéseket, végül szükség esetén a független többértékű függéseket. Az egyes bontásokhoz a közös attribútumok és hivatkozások biztosítanak kapcsolatot.

Nem kell minden problémát kizárólag alulról építkező táblabontással megoldani. Egy jó ER-modell alapján eleve jól elkülönülhetnek a tanulói, kurzus- és oktatói tények. A normalizálás ekkor ellenőrző és finomító eszköz: megmutatja, maradt-e fölösleges adatismétlés vagy rejtett függés a logikai tervben.

A 3NF nem garantálja, hogy minden elképzelhető redundancia megszűnik. A 4NF példában a funkcionális függések rendben voltak, de két független választás összes kombinációjának tárolása okozott gondot. Ugyanakkor egy tábla szétbontása önmagában sem érték: a bizonyítható, veszteségmentes és a követelményeket megőrző terv a cél.

Az ismétlődő id, a több JOIN vagy a nagyobb táblaszám nem bizonyít hibát. A tervet konkrét műveletekkel próbáljuk ki: fel tudunk-e venni új oktatót kurzus nélkül, új kurzust jelentkezés nélkül; egy oktatói adat változását egyetlen helyen javítjuk-e; egy jelentkezés törlése megőrzi-e a többi önálló tényt?

A tanulási folyamat végén olvasd össze a sémát az eredeti igényekkel. A modellben minden tárolandó ténynek legyen helye, minden kulcsnak indoka, minden FK-nak pontos célja, és minden hiányzó érték megengedésének üzleti magyarázata. A normalizálás a logikai szerkezet minőségét javítja; a teljesítmény hangolása és fizikai tárolás tervezése további feladat.