az adatbazison, amin dolgozunk, ez pontosan igy van megvalositva.
es meg van egy adatvedelmi tabla, ahol a szemely azonositok flag-ekkel vannak ellatva, pl level stop, cimzett ismeretlen, stb.
Szoval megint nem voltam eleg vilagos...
lenne egy 'emberek' tabla, benne az amit minden emberrol tarolunk (nev,cim,telefonszam).
Azutan lenne egy 'ugyfelek', akinek a kulcsa egyben idegen kulcs az 'emberek'-re, es tartalmazza az ugyfel-specifikus adatokat.
Azutan lenne egy 'dolgozok', amiben szinten hivatkozna az emberekre, de benne lenne a fizetes, telephely stb.
Azutan lenne meg az 'ugynokok' tabla (ez nem aktualpolitika, hanem a kulso cegek velunk kapcsolatot-tarto dolgozoi :), aki szinten az 'emberek'-en alapulna...
Na most ugye minő eretnek felvetés, hogy egy dolgozó kazettát kölcsönözzön.
ResetGomb: Nem jó az adatvéfelmi érved, mert amennyiben a dolgozó kölcsönö - tehát bekerül külön a kölcsönző táblába is - ugyanúgy ki lehet gyűjteni, tehát amennyiben akarod ugyanezt a statisztikát elkészítheted az adott munkaerőre.
Válogasd ki azokat az ügyfeleket, akiknek a következő adatai megegyeznek a valamely dolgozó azonos adataival ÉS x kazettákat kölcsönöztek.
Amúgy ez a probléma - mármint, hogy egy személy tábla plusz specializált táblák, ezek a logikai tervezéshez tartoznak, a két külön táblába való szétszedés - ami ugye technikai, jogi, egyéb átmeneti indokkal történik - tartozik a fizikai tervezéshez.
Úgyhogy véleményem szerint a Személy tábla + kölcsönzés tábla + alkalmazotti adatok tábla a jó megoldás ebben az esetben. Pláne ORACLE esetén - nested táblák, stb.
Ez azonban nem elvi, inkább gyakorlati kérdés. Egy dolgozóról sokkal több adatot kell tárolni, mint egy ügyfélről. Ezért mindenképpen lenne egy tábla, amiben a dolgozók plussz adatait tárolnád.
Az ember + dolgozo-kieg táblából csinálnál egy dolgozo view-t, amivel aztán úgy dolgoznál, mintha önálló tábla lenne.
Illetve jut eszembe egy ellenérv is, habár az nem technikai jellegű.
Adatvédelmi, személyiségi jogi problémákat vetne fel, ha ki tudnád gyűjteni, hogy pl. mely dolgozó kölcsönöz ki x-jellegű videókat.
Halassy a kérdést a specializáció-generalizáció címszó alatt tárgyalja.
kurva jo! :-)))
egyebkent amennyire en latom, a logikai es a fizikai data modelben ezt kulonvalasztjak. tehat a logikai data modelben van kulon alkalmazott es ugyfel tabla es csak a fizikaiban rakjak ossze "emberre".
de a te eseted egyertelmuen fizikai adatmodel.
Mikor Oracle-tanfolyamon voltunk volt egy videokolcsonzesi ceg volt a pelda a Designer-hez, ott volt a cegnek egy ugyfel-tablaja, meg egy alkalmazott-tablaja... kerdeztem, mit szolnanak egy 'ember' tablahoz, ami mindkettonek az 'alaptablaja' lenne, de a tobbiek es az oktato leszavaztak...
Na igen. mégis, érdekes, hogy képesek ugyanazt a személyt több különböző "adatbázisban" eltárolni. Aztán jön a kavar, és az értetlenkedés : de hát nállunk nyilvántartás van ! Több is! :))
Amikor rögzítik ezen adatokat, akkor a gép adjon egy "iktatószámot" a papírnak. Ezt a rögzítő feljegyzi a papírra, amelyeket aztán ebben a sorrendben irattároznak.
A program meg majd kilöki, hogy "jé az 346789-en ugyanaz a csirke van, mint a 574311-en".
Ekkor előkeresik mindkét papírt és mehet a tetemrehívás. :-(
Bocs, de nem voltam egyértelmű. Ez a 0NF-re volt példa. Ha ilyenek nincsenek benne, akkor az adatbázis legalább 1NF-ben van.
A lényeg az azonosítótól való funkcionális függőségen van. Ha van egy személy adattáblád, akkor a Gipsz Jakab lehet akár azonosító is. Van még egy nyelv oszlopod is.
Ha minden olyan sorban, ahol a Gipsz Jakab azonosító, a nyelv oszlopban mindíg ugyanaz az érték szerepel (törvényszerüen), pl. magyar, akkor a tulajdonság funkcionálisan függ az azonosítótól. (Mert pl. a nyelv az anyanyelvet jelöli.) Ha több ilyen is van (vagy lehet!), mert a nyelv a nyelvtudást jelöli, akkor az funkcionálisan független.
Ekkor ezt a táblát két (vagy három) táblára kell bontani: személy és nyelvtudás vagy személy - nyelvek - nyelvtudás.
Van egy apro-csepro csekelyseg, amit nem mondtam:-)
Szoval itt a egy "utolagos" adatbazist kell csinalni, tehat nem lehet azt mondani hogy, 'ervenytelen adatot nem fogadok el', hanem ami papirt a rogzito a kezeben tart, az le kell tudja rogziteni... ja es nincs torles (passzivalas), eppen az az egyik szempont hogy a torzslapok elveszteset/hamisitasat lehessen kutatni...
ez a pelda mikor lenne 1NF?
ha a nyelv megnevezeset egy ID-val helyettesitem, vagy keszitek egy kulon tablat, ahol mondjuk:
szemely_id, nyelv_id, nyelv_primary_key
1 (GipszJ) 1 (angol) 1
1 (GipszJ) 2 (nemet) 2
es a az elozo tablaba csak a nyelv_pk-t rakom bele?
Egyel igen, én csináltam.
Nem fogadták el.
Maradt az MS SQL szerveren megvalósított, a nyolcvanas évekből ittmaradt, "adatbázis" , ahol a táblák közti relációkat és a vlaidálást az "adatbázist" használó alkalmazás végezte.
Ahol ugyanaz az azonosító két táblában két különbő méretű, illetve típusú mezőben volt tárolva.
Na én eddig gyakorlatban ilyen adatbázist láttam közelről.
Ahol a mezők 70%-nak senki nem tudta a jelentését, csak azt, hogy valahol használja a progi, de hogy miért és mire?
Ja, igen, még az iskolai feladatokban láttam normalizált adatbázisokat.
Van két táblád. Az egyikben egy oszlop neve az, hogy ADOSZAM. Egy másik táblában van egy oszlop, aminek a neve DOLGOZO_KOD. Ha mindkettőben gyakorlatilag kizárólag az APEH által adott adószám van, akkor ezek szinonímák. (Másként hívják, de ugyanazt jelenti)
Homoníma:
Van két táblád. Mindkettőben az az oszlop neve, hogy TERMEK_KOD. De a tartalmuk az egyik esetben az EAN kód (vonalkód), míg másik esetben az ITJ szám. Ezek homonímák. (Ugyanúgy hívják őket, de mást jelentenek.)
Így az elmondottak alapján jó megoldás, gondolom a csirke minden adata a törzslapon volt nyilvántartva (tehát csirke = törzslap).
Persze, kérdés, hogy mért kap egy csirke két törzslapot - hiszen ha az előzőt elvesztette, akkor az elvesztett törzslapot törölni kell -, vagy hogy, hogyan lehet duplázni a törzslapot. Törzslap sorszáma körbefordul, érdkes kérdés, mert azért egy long int-be elég sok szám belefér, egy id típusú mezőbe meg még több.
Egy rendszertervező minden adattáblára tesz egy ID típusú mezőt mint elsődleges kulcsot.
Mindenesetre a teljes probléma ismerete nélkül hülyeség lenne bármilyen tippet i adni.
Ezért fontos az, hogy megbeszélje az ember a tényleges felhasználóval, hogy mi fog történni.
Halassy féle tanmese, saját hibájáról: Egy biztosításhoz gy ügyfél tartozik. Általában. Csak ő elfelejtette megkérdezni az utolsó embert, aki a több ügyfeles biztosítással foglalkozott.
[na, ez így nem biztos, hogy pontos, de a lényeg érthető azt hiszem :))]
Amgy a kulcsok és indexek elméleti, majd fizikai tervezése külön móka :))
Egy nagyon elemi dolog epp ma jott elo: mi legyen a csirke-torzslap nyilvantartas kulcsa:
1) a csirke sorszama... logikus, de nem jo, mert egy csirke esetleg tobb torzslapot is kaphatott (ha az elozot elvesztette)
2) a torzslap sorszama... meg logikusabb, csakhogy nincs garancia hogy nem volt (akar rosszindulatu!) duplazas, nem fordult korbe a sorszam, stb
3) tehat technikai kulcsot kell csinalni, ket indexxel (csirkeszam es torzslapszam)
Közben összeszedtem néhány tippet.
Bár a Halassy szebben mondja el :))
Mindig rajzold le, az összes táblát - na jó egy határig, a 300 egyedes adatbázist nem célszerű -, és sokat rágódj rajta.
Külön mezőbe írd oda, hogy mi a célja a kapcsolótábláknak, kapcsolatoknak - mért kapcsolódik a Tantárgy a Hallgatóhoz két táblán keresztül? Fakultatív tárgyak listája, Tanulmányi eredmények.
SSADM - ből ajánlják az egyed-kapcsolat mátrixot - bár én még nem használtam, egyszer majd kipróbálom.
Minden egyedet sorokan és oszlopokban egyforma sorrendben felírsz, és a kapcsolatokat ki xeled (vagy valahogy jelölöd).
Persze nagy gyengéje, hogy olyan esetben nem működik, amikor két egyed között több kapcsolat is létezik.
Jó dolog a relációs adatbázisnál a normalizálás, de első lépésként mindig gyomláld ki a homonimákat és szinonimákat, és mindig írd le magadnak, hogy az adott kapcsolat illetve egyed miért került be, és miért így. Később jól jöhet, amikor vadul keresed, hogy mi a fenéért van az ott.
És ilyenkor azért össze is szeded a gondolatod.
Mindig gondolj a bővíthetőségre.
Lehet, hogy ma csak három nyelv fogadható el a személyes adatok között, vagy csak egy legfelősbb végzettség, de lehet, hogy két hónap múlva változtatnak, és akkor szétszdheted az egészet.
Bátran használj nem sztenderd adatformákat. Az érdemjegyet ne int-ként, vagy byte-ként add meg, hanem definiáld érdemjegy típusú adatként. Ilyenkor leírod, hogy ez azt jelenti, hogy, és már meg is van a validálási szabályod későbbre. A legtöbb adatbáziskezelő már úgyis támogatja a User Defined adatokat.
Amikor csinálod, gyakran írjál próbaadatokat, akár papíron is. Ilyenkor kiderülhetnek logikai bukfencek, és jobb már az elején rájönni, mint később az első két tábla elszúrása miatt, az egészet előről kezdeni.
