Ebben a szakaszban egy képzeletbeli bonyolultabb adatbázis tervezési feladatot nézünk meg.
1. A feladat meghatározása
A megrendelő kér egy olyan adatbázist, amellyel Konferenciák szervezését lehet megoldani a helyszínen lévő termek, előadók, jelentkezők és szálláshelyek szempontjából.
2. A fogalmak tisztázása
Az adatbázisban tehát vannak az alábbi fogalmak:
Több konferenciáról van szó, tehát konferencia egyedtípusra lesz szükség.
Egy konferencián gyakran több előadóterem van, ezért létrehozzuk a terem egyedtípust. Dönteni kell, hogy egy teremben a helyeket sorszámok alapján (sor+székszám) tartjuk nyilván, vagy egész egyszerűen azt nézzük, hogy hány szék van a teremben. Ez utóbbi egyszerűbb, ezért most ezt választjuk.
Minden konferencián vannak előadások, tehát lesz egy eloadas egyedtipus. A konferencia előadásainak van címe, esetleg rövid tartalma, előadója, témaköre (ha muszáj), hossza és egyéb tetszés szerinti adata.
Minden előadás egy megadott konferenciához tartozik, de egy konferencián több előadás is lehet,
tehát konferencia - előadás egyedtípusok 1:n kapcsolatban állnak.
Több előadó szerepel, tehát lesz egy eloado egyedtípus. Egy előadást egy előadó tart, de egy előadó több előadást is tarthat, tehát: eloado - eloadas 1:n kapcsolatban áll.
Egy előadás egy teremben található, de egy teremben több előadás is lehet, ezért eloadas-terem n:1.
Lehetséges, hogy a konferenciához tartozik egy idobeosztas nevű egyedtípus, amely tartalmazza a terem, az időpont és az előadás információkat. Ekkor az idobeosztas - konferencia, n:m kapcsolatban van. Ezzel most nem bonyolítom az adatbázist.
Több látogató van egy konferencián, tehát lesz egy latogato egyedtípus. Egy látogató több előadáson is részt vehet, és természetesen egy előadáson több látogató van, tehát a latogato-eloadas kapcsolata n:m.
Létre kell hozni egy kapcsoló egyedtípust, hogy a latogato-eloadas n:m kapcsolatot le lehessen kezelni, mondjuk legyen a neve reszvetel. Ekkor latogato-reszvetel 1:n és reszvetel-eloadas m:1 kapcsolatot alkot.
Több szálláshely van, tehát lesz egy szallashely egyedtipus.
Egy szálláshelyen több szoba/ágy van. Célszerűen a szobákat, ágyakat meg kell jelölni, tipikusan az adott szálláshely adottságainak felhasználásával, ami természetesen nem látható előre. Nem akarunk teljesen általános megodlást, ezért úgy vesszük, hogy csak szobákat adunk ki, amelyek valahány ágyasak lesznek, és a szobákat fizetik ki majd a látogatók. Lesz tehát egy szoba egyedtípus.
Egy szoba csak egy szálláshelyen létezik, de egy szálláshelyen több szoba van, tehát: szoba-szallashely n:1 kapcsolat.
A látogatók folglalnak szobákat a szálláshelyen, tehát lesz egy foglalas egyedtípus. Mivel lehetnek olyanok, akik nem a szervezők által intézett szálláshelyen lesznek, ezért nem kötelező minden látogatót beregisztrálni a foglalas egyedtípusba.
A fenti egyedtípusok olyan adatokat tartalmaznak, amelyek csak bővülhetnek, nem tartalmaznak esemény jellegű adatokat.
A konferenciák lehetnek ugyanabban a városban többször is, ráadásul lehetnek ugyanazok a szálláshelyek, ezért a konferencia - szálláshely n:m kapcsolatban vannak. Ilyenkor létrehozzuk az aktuális szálláshelyek egyedtípust, aszallas néven így konferencia - aszallas 1:N és aszallas-szallashely M:1.
Egy konferencián több termet is használnak és egy terem több konferenciához is tartozhat, így a konferencia-terem egy n:m kapcsolat. Létrehozzuk az eddigiek alapján a szokásos kapcsolótáblát konfterem néven, konferencia-konfterem 1:n és konfterem-terem m:1.
A fenti egyedtípusok fontos tulajdonságai a fentiek alapján:
- Konferencia (ID, Elnevezés, Város, utca, időpont tól-ig, Szervező. )
- Terem (ID, elnevezés, férőhely, esetleg elérési hely)
- Konfterem(ID, KonferenciaID, TeremID)
- Eloado (ID, Nev, Cim, Telefon, Munkassag, weblap, email)
- Eloadas (ID, KonferenciaID, EloadoID, TeremID, Cim, Téma, Ido, Allapot)
Megjegyzés: Gyakori, hogy az előadók lemondják az előadást, ezért van szükség állapot bejegyzésre.
- Latogato(ID, nev, cim, telefon, anyja neve)
Megjegyzés: Látható, hogy a látogatók adatai az előadók adatainak egy részhalmazát alkotják, ezért lehetne a két táblát egyesíteni és egy mezővel megkülönböztetni, hogy látogató-e vagy előadó.
- Szallashely(ID, Varos, Utca, Hazszam, Telefon, Fax)
- aszallas(ID, KonferenciaId, SzallashelyID)
- Szoba(ID, Szobaazonosító, SzallashelyID, Ferohely, emelet, szám, komfortfokozat, ár, Idopont)
Megjegyzés: előfordul, hogy egy szállást felújítanak vagy szezononként más az ára vagy változik a komfortfokozat. Ilyenkor két megoldás van. Az nem jó, ha a szoba tulajdonságát átírják, mert akkor a korábban tárolt adatoknál is változik az ár. Az egyik lehetőség az, hogy a szobát valami speciális jellel újból felvesszük, vagy a szoba azonosítója marad és az aktuáis tulajdonságokat egy külön táblában rögzítjük.
- Reszvetel (ID, LatogatoID, EloadasID)
Megjegyzés: Ezzel a táblával tudjuk azt megállapítani, hogy melyik látogató melyik előadáson vesz vagy vett részt. Például kitöltethetünk egy tetszési adathalmaz az előadásokról minőségbiztosítási céllal.
- Foglalas(ID, SzobaID, LatogatoID, Erkezes, Tavozas, Fizetve, fizetesi_bizonylat)
Megjegyzes: Célszerű az, ha a látogatók között felvesszük a szervező nevű látogatót, aki fizet majd az előadók helyett. Az adatbázis kapcsolatainak listája itt tekinthető meg:
Ezzel az adatbázis szerkezetét nagyjából meg is terveztük.