Normalizálás
Üdv !
Az adatbázis normalizálás témájához keresek NAGYON SZAKÉRTŐ és lehetőleg tapasztalt emberkét/emberkéket egy konkrét, általam megoldott feladat leellenőrzésére, illetve esetleges hibajavításra :D A dolog elég sürgős lenne. Ha lesz jelentkező akkor majd dobok MSN címet. (A konkrét feladat nem nagy szám, de biztosra akarok menni lehetőleg)
Addig is üdv !
■ Az adatbázis normalizálás témájához keresek NAGYON SZAKÉRTŐ és lehetőleg tapasztalt emberkét/emberkéket egy konkrét, általam megoldott feladat leellenőrzésére, illetve esetleges hibajavításra :D A dolog elég sürgős lenne. Ha lesz jelentkező akkor majd dobok MSN címet. (A konkrét feladat nem nagy szám, de biztosra akarok menni lehetőleg)
Addig is üdv !
Munka rovat
Üdv !
egyetemi oktatás(kurzusok, termek, oktatók, hallgatók, szakok, órarend)
Ennyit kaptunk kiindulási pontnak. A feladat az, hogy ebből tervezzünk egy EK-modellt, majd abból írjunk relációs sémát, majd azt normalizáljuk. (Majd később le is kell kódolni, de egyenlőre csak ez a 3 dolog kell.)
Annyit adtak még segítségül, hogy a feladatban szereplő egyedeket célszerű felvenni. (Tehát amik a zárójelben vannak).
Szóval én első körben a következő megoldásra gondoltam (most egyből a relációs adatbázissémát írom le) :
termek(id, név, utca, épület, emelet, ajtó)
kurzusok(id, név, típus, időpont, létszám, korlát)
oktatók(eha, veznév, kernév, jelszó, jogosultság)
hallgatók(eha, veznév, kernév, jelszó, jogosultság)
órarend (hallgató_eha, kurzus_id)
oktat (oktató_eha, kurzus_id)
szakok (id, név)
felvették (hallgató_eha, szak_id, időpont)
az oktat, az órarend és a felvették az kapcsolótábla lenne. A szakokkal csak a hallgatók lennének kapcsolatban mert az oktatóknál a feladatom szempontjából most lényegtelen tudni hogy mely szakokon tanít esetleg. Szóval a hallgató - szak több-több kapcsolatot valósítaná meg a felvették kapcsolótábla. Továbbá ahogy látható, a hallgatóknak az órarend, az oktatóknak pedig az oktat tábla a kapcsolata a kurzusokkal. Mindegyik egy kapcsolótábla, mert több-több kapcsolatról van szó.
Namost ez így nem teljesen jó, mert van két teljesen fölösleges táblám. Az oktatók és a hallgatók tábla totál megegyezik, akkor meg minek szedjem külön őket ? Aztán ott van az oktat és az órarend kapcsolótábla is, amik szintén megegyeznek ! Szóval írjuk át kicsit a dolgokat :
termek(id, név, utca, épület, emelet, ajtó)
kurzusok(id, név, típus, időpont, létszám, korlát)
felhasználók(eha, veznév, kernév, jelszó, jogosultság)
órarend (felhasználó_eha, kurzus_id)
szakok (id, név)
felvették (felhasználó_eha, szak_id, időpont)
Tehát egybe vontam a hallgatókat és az oktatókat felhasználók néven és ekkor már csak egy órarend kapcsolótáblára van szükségem.
Most jön a lényeg !!!
Ez 3. normál formában van ???
Szerintem igen, mert :
1NF : első normál formában van, mert mindegyik attribútum eszerű (atomi), tehát nem lista, vagy összetett attribútum.
2.NF : második normál formában is van, mert ahol összetett kulcsom van, ott a másodlagos attribútumok (ilyen csak a felvették táblámban van) csak az összetett kulcstól függnek, külön-külön pedig egyiktől sem.
3. NF : szerintem harmadik normál formában is van, mert ahol összetett kulcsok vannak, ott a másodlagos attribútumok teljesen (azaz közvetlenül) függnek az összetett kulcstól. (megint csak a felvették tábláról és ugye az időpont attribútumról van szó)
Gyönyörű, akadémikus :)
Felvehetnél egy új mezőt, hogy az illető oktató vagy hallgató-e, de a modell még így is szörnyű lenne, tekintve hogy a modellezett intézményben lényegesen eltérő az oktatók és halgatók szerepe (fügetlenül attól, hogy per pillanat milyen tulajdonságok jutnak eszedbe). Megvalósíthatsz egy öröklődés-szerű szerkezetet pl:
személyek(eha, veznév, kernév, jelszó, jogosultság?)
oktatók(eha, egyébb oktatókra jellemező tulajdonságok)
hallgatók(eha, egyébb hallgatókra jellemező tulajdonságok)
Ez már szájíz kérdése, de én sose használnék mindneféle eha kódokat a saját rendszeremben, nekem így szimpatikusabb lenne:
személyek(id, eha, veznév, kernév, jelszó, jogosultság?)
oktatók(személy_id, egyébb oktatókra jellemező tulajdonságok)
hallgatók(személy_id, egyébb hallgatókra jellemező tulajdonságok)
A jogosultságot nem igazán értem. Az 1.NF-re írtad, hogy nincs összetett tulajdonság. Nem tudom milyen jogosultságokat szeretnél leképezni, de ha én lennék az értékelő ezen lovagolnék egy kicsit ;)
Jogos.. :)
Én itt most nem bonyolódnék ilyenekbe. Arra gondoltam hogy minden felhasználónak csak egyetlen jogosultsága lehetne (természetesen ez bármikor megváltoztatható), és ez a jogosultság magában hordozna több lehetőséget is. Én 3 jogosultságra gondoltam amik a "hallgató", "oktató", és az "adminisztrátor". Vagy lehetne 1, 2 ,3 is de ez most lényegtelen. Elmondom hogy képzeltem az egyszerű rendszert.
- Először is be kell jelentkezni, az EHA kóddal és a jelszó párossal.
(Ezért is nem használtam elsődleges kulcsnak a felhasználóknál az id -t mert akkor két elsődleges kulcs lenne, az id, és az EHA. Igen, az EHA szükséges, mert látott már valaki olyat hogy az id-vel (ami mondjuk "34") és a jelszóval kell bejelentkezni ? Hát persze hogy nem... Viszont igen, használhattam volna együtt is a kettőt, annak a tudatában, hogy az EHA kód az egy string lesz, az id viszont egy szám, és nyilván egy szám gyorsabb elsődleges kulcsként mint egy string. A gyakvezető "unszolására" viszint a csak EHA kód melett döntöttem.)
- Ha a bejelentkezés megtörtént, akkor kiolvasom a jogosultságot a felhasználó adataiból. Ha a jogosultsága "adminisztrátor", akkor elérhetőek lesznek a kurzus regisztráció/törlés/módosítás, terem regisztráció/törlés/módosítás etc....menüpontok illetve lehetőségek. Ha a jogosultság "hallgató", akkor csak a kurzus felvétel/leadás, és az órarend megtekintése menüpontok lesznek elérhetőek. (Meg a kijelentkezés, és például a jelszó módosítás). Ha a jogosultság pedig oktató, akkor csak az órarend megtekintése, jelszó módosítás, kijelentkezés lehetséges. (Persze jöhetne még ide a fórum opció meg egyebek de az most nekem nem kell).
Szóval erről lenne szó. Tehát a jogosultság attribútum itt most ezek szerint a szempontok szerint egyértelműen meghatározza hogy kiről is van szó, és csupán csak egy egyszerű string, vagy integer. Az EHA kód létjogosultságát és a "valóban jobb lenne egy id kulcsnak?" kérdést pedig föntebb kifejtettem.
Ha van még észrevétel szivesen várom :)
Nem is mondtam...
Nem összetett kulcsra gondoltam (nem is húztam alá az EHA-t). Az ID-s változatban az ID az elsődleges kulcs, az EHAra pedig egy "UNIQUE" constraintet lehet tenni oszt kész. (Amúgy példának okáért a Weblaborra sem az ID-del lépsz be, még is http://weblabor.hu/tagok/22793) a profilod oldala.
Amennyire én láttam, ahol DB-t tanítanak mindenhol a természetes azonosítót meg az összetett kulcsokat istenítik :)
Igazából itt a választott eszközhöz tartozó kultúra kéne legyen a meghatározó. Nevezetesen, ha Access-ben valósítod meg a dolgot, akkor minden féle gyönyörű összetett kulcsokkal indexelni, meg logikát a DB-be építeni. Ha meg mondjuk PHP-ben dolgozol, akkor az itteni "szokásjogot" követni. Persze, egy tökéletes univezumban...
Ha a DB terve önmagában lesz értékelve és nem az egész rendszer egyben, meg ha a további fejleszthetőség nem szempont akkor ez minden amit okoskodni tudtam a dologról :)
Igazad lehet...
Visszatérve az EHA kódra, én is teljesen úgy értettem a dolgot ahogy te, csak biztos nem fogalmaztam világosan, vagy egyértelműen :) Tehát szívem szerint én is úgy vettem volna föl a felhasználók sémát hogy :
felhasználók (id, EHA, veznév, kernév, jelszo, jogosultsag)
De a gyakvezető azt mondta hogy neki jobban tetszene (nemtommér) az, ha az id-t kihagynám és csak EHA lenne benne. Én itt egyedül a "megszokás"-t és a "gyorsaságot" tudtam fölhozni érvként, de végül mégis az jött ki hogy "jobb" ha nem lesz id a felhasználóknál. Szóval ezzel én nem értek egyet, de mivel itt pontok járnak érte ezért inkább nem kötöszködnék :)
A bővíthetőséget meg esetleg figyelembe véve, először is egyértelműen a jogosultságokat kéne kirobbantani a felhasználóktól és csinálni belőle még egy táblát + kapcsolótáblát.
De akkor ezek szerint amit csináltam az a szóban forgó keretek között nem rossz :)Minden bizonnyal lehetne még sok dolgot alakítgatni egy valódi rendszer esetében, de nekem most erre nincs szükségem egyenlőre.
Mesterséges kulcs
De miért a természetes?
Szóval persze, van olyan helyzet ahol nem használható mesterséges azonsító, de ennél jobb érveket várok ellene. :)
Ami mesterséges az nem feltétlenül auto_incrementet takar. Pl. 5-6 éve, amikor még nem volt divat a nontop net elérés, és meg kellett oldani hogy az egyes kirendeltségekben keletkező rekordok ne ütközzenek, a numerikus ID helyett más tipusú azonosítokat generáltunk. Ez egy külső kényszer. És ettől még mesterséges, nem összetett kulcsról van szó.
SAP, ABAP3 még nem nőtt fel a
Ez kicsit hitvita, lehet választani az EHA kód , vagy akármi mellé, ha nem tetszik, túl hosszú stb, egy mesterségeset.
Persze ez mindig redundancia, de van ilyen.
Én arról a gyakorlatról szándokoztam írni, amikor az összetett egyedi azonosító mellé tesznek egy autoincrement mezőt és ez lesz a kulcs. Ez se gond, gyors lesz, csak innét neked kell kézben tartani az adatbázisod integritását,konzisztenciáját, ez a baj vele. És hogy egy valós példát hozzak akkor ismét a joomla - virtuemart, ha már szóba hoztam. Ez sok ezer példányban fut a világban. Az order_item tábla kulcsa egy autoincrement mező. Be lehet vinni az táblába ugyanazt a tételt ezerszer, persze mindig más lesz az order_item_id. Hangsúlyozom, ez egy valós példa, nem én találtam ki. Ha order_id és order_item_number lenne a kulcs , akkor ezt nem lehetne. És Murphy óta tudjuk, hogy ami el tud romlani, az el is romlik.