Minta adatbázis tervezésre

A fejezet későbbi részeiben az itt bemutatott minta adatbázist fogom használni az SQL nyelv és az Entity Framework bemutatásához.

A minta adatbázis egy könyv nyilvántartó rendszer lesz, ami képes könyvek adatait tárolni.

A tervezés első lépéseként át kell gondolni, hogy egy könyvnek milyen tulajdonságai vannak. Egyedi azonosítónak használhatjuk az ISBN számot, mivel ez minden könyv esetén egyedi. Minden könyvnek van címe, továbbá szerzője és egy kiadási éve, valamint egy kiadója. A szerző egy összetett tulajdonság, mivel a szerzőknek van kereszt- és vezetéknevük, illetve további adataik. Jelen esetben nem bonyolítjuk túl a dolgot, a szerző csak vezetéknévvel és keresztnévvel fog rendelkezni.

A kiadó is egy összetett tulajdonság, mivel a nevén kívül rendelkezik még sok egyéb adattal. Szintén nem bonyolítjuk túl a dolgot, a kiadó esetén csak nevet és címet fogunk tárolni.

Az elsődleges tulajdonság specifikációk alapján elkészíthetjük az adatbázisunk kezdetleges egyed-kapcsolat modelljét. Ez az alábbi ábrán látható:

Ez alapján már megvalósítható lenne az adatbázisunk, mivel van kulcs tulajdonságunk, vagyis a jelenlegi modellünk kielégíti az első normálforma követelményeit. Ha így hagynánk az adatbázist, akkor bizony egy csomó redundancia maradna benne. Ezért fel kell bontani az adatbázisunkat.

Egy kiadó több könyvet is kiadhat, illetve egy szerző több könyvet is írhat. Ezért a szerzőnek és a kiadónak létrehozunk egy-egy külön egyedtípust. Ezeket az egyedtípusokat pedig kapcsolatok segítségével illesszük majd be a modellbe.

A felbontás elvégzése után a modell a következőféleképpen fog kinézni:

A felbontás után a modellünk az első normál forma követelményeit nem elégíti ki, mivel a szerző és a kiadó egyedtípusok esetén nincs kulcs tulajdonságunk. A kiadó esetén a név használható egyedi azonosítóként, mivel a kiadók cégek (az egyszerűség kedvéért a magánkiadásoktól jelen modellben eltekintünk), a cégek bejegyzésével pedig a cégbíróság foglalkozik. A jelenlegi jogszabályok alapján pedig nem lehet két azonos nevű cég.

A szerző esetén azonban sem a vezetéknév, sem a keresztnév nem tekinthető önmagában egyedi kulcsnak. Összetéve alkalmazhatóak lennének összetett kulcsként, azonban ha összetett kulcsot alkalmazunk, akkor az a probléma, hogy a Kovács egy igen gyakori vezetéknév, valamint az István is. Ha csak statisztikai szempontból vizsgáljuk a lehetőségeket, akkor könnyen belátható, hogy előfordulhat olyan eset, hogy két Kovács István nevű szerzőnk legyen, akik különböznek, de jelenlegi modell szerint nem megkülönböztethetőek.

A probléma orvosolható, ha további tulajdonságokkal egészítjük ki a szerző táblát, például egy születési évvel, aztán az új tulajdonságunkat szintén egy összetett kulcs részévé tesszük. Könnyen belátható, hogy ez nem egy jó megoldás, mivel adódhat olyan eset, hogy ugyanabban az évben született a két szerző. Ha ez nem is áll fent, akkor is az összetett kulcskezelés nagymértékben lassítani fogja a rendszert.

A helyes és jó megoldás ilyen esetben az, hogy fel kell venni egy egyedi azonosító tulajdonságot az egyedtípusba. Ezt jelen esetben elnevezzük SZID-nek, ami a szerző ID (identification) szavakból képződik.

Ezután következhet a kapcsolatok kialakítása. A kiadó és a szerző is kapcsolattá fog alakulni, mivel ezek kapcsolatban állnak a könyvvel. A végleges egyed-kapcsolat modell a következő lesz:

A kapcsolatok esetén az összekötő vonalak mellett fel kell tüntetni a kapcsolat típusát. A létrehozott egyed-kapcsolat modellből létrehozható a relációs séma modell. A relációs modellben az egyedek rekordoknak (adatbázis sorai) feleltethetőek meg. Ezeknek a gyűjtője lesz majd a tábla, amely a modellben megadott tulajdonságokkal rendelkezik.

A kapcsolatokra nincs relációs megfelelő, ezért kialakításuk kapcsolódási pontok felvételével lehetséges. A kapcsolódási pontokat abban az egyedtípusban kell kialakítani, amit felbontottunk. Jelen esetben ez a könyv lesz. A kapcsolódási pontok majd tulajdonságként realizálódnak a táblában. Ezen tulajdonságok kiemelt szereppel fognak rendelkezni, mivel ezek külső kulcsok lesznek.

A végleges relációs implementációban a könyv tábla ki fog még egészülni két mezővel. Ezeknek a KiadóNév és az SZID mezők lesznek. A külső kulcs egy táblában egy olyan kulcs, amely egy másik tábla elsődleges kulcsára mutat, így ezen mutatókon keresztül a relációs algebra eszköztárával kezelhető a kapcsolat. A relációs táblákat Táblanév(mező1, mező2, mezőN) formátumban szokás jelölni modellezés során. A külső kulcs mezők szaggatott vonallal vannak aláhúzva, míg az elsődleges kulcs mezők egyszeres folytonos aláhúzással rendelkeznek.