Mondjuk, hogy a következő ER diagramom van:
Most, ha a kapcsolatot egy School a Student mezőben NULL értékek lehetnek (mert egy Student nem kötelező, hogy School) legyen, például:
Tehát a helyes módszer (az elolvasottak alapján) egy keresztezőtábla létrehozása a kapcsolat ábrázolásához, például:
Így nem NULL értékek jelen lehetnek a School_has_Student táblázatban.
De mi a hátrányai annak, ha nullázhatatlan idegen kulcsot használunk metszetábla létrehozása helyett?
Szerkesztés:
Tévesen választottam (school_id, student_id) a táblázat, amely sok-soká tette a kapcsolatot. A helyes elsődleges kulcsnak student_id kellett volna lennie:
Megjegyzések
- Nincsenek ‘ s ” helyes ” módon. ‘ csak az Ön igényeinek leginkább megfelelő módja van.
- Egyetértek Dokival a hamis feltételezésben, de talán ‘ még mindig elég világosak ahhoz, hogy válaszolhassanak?
- Van egy hamis feltételezés, de elég könnyű kiegyenesíteni és megmagyarázni a különbséget.
- visszavontam a közeli szavazásomat , de a ” mondat Tehát a helyes módszer (az olvasottak alapján) egy keresztezőtábla létrehozása, amely a ” azt a benyomást kelti, hogy el kell mondania, melyik feszültségforrás mondta neked, hogy ez a ” helyes ” mód. Minden korábban olvasott tankönyvben az 1: n kapcsolatok kanonikus módja egyetlen idegen kulcs. Vagy félreértett valamit?
- @Doc Brown nem emlékszem ‘ nem emlékszem arra, hogy hol olvastam, de biztos vagyok benne, hogy az azt írja, hogy egy keresztezőtábla volt a helyes módon. Egyébként meg tudnád adni annak a könyvnek a nevét, amely azt mondja, hogy az 1: n kapcsolatot (opcionális részvétellel az: 1 oldalon) egyetlen idegen kulcs segítségével kell ábrázolni, érdekel, hogy elolvassam, mit mondanak erről a témáról.
Válasz
A két modell különböző összefüggéseket képvisel.
Csatlakozási táblázat használatával , Ön sok-sok-sok kapcsolatot modellez.
Egyszerű idegen kulcs használatával egy-a-sokhoz viszonyt modellez.
A semmissé váló külföldi hátránya kulcs nem tudja modellezni a sok-sok kapcsolatot, ha ezt próbálja megvalósítani.
A kérdésre adott szerkesztése alapján hatékonyan osztja fel a hallgatói táblázatot két táblába ugyanazzal a kulccsal. Általában ezt látom olyan táblákon, amelyek túl sok mezővel rendelkeznek, ezért valaki ketté osztja őket, hogy könnyebben kezelhetők legyenek (én úgy hívom, hogy ajakrúzsot tesznek a disznóra).
A diákasztal felosztásával azt készíted, hogy a második tábla opcionális, mert a második táblában nem kell rekordnak lennie. Ami nagyon hasonlít egy olyan mezőre, amelyet nem kell beállítani, mert null lehet.
Ha egy-a-sokhoz kapcsolatot akarsz, akkor sokkal jobb, ha egyetlen táblázatot használsz, és engedélyezed az iskolai azonosítót hogy nullás legyen a hallgatói táblázatban. Nincs ok a mezők nullák elkerülésére, még egy idegen kulcs esetén sem. Ez azt jelzi, hogy a külföldi kapcsolat opcionális: a fejlesztők és a DBA-k ezt egyértelműen megértik, és az alapul szolgáló adatbázis-motornak minden bizonnyal jól kell működnie.
Ha aggódsz a csatlakozások miatt, ne aggódj. Jól definiált szemantika létezik arra vonatkozóan, hogy a csatlakozások hogyan működnek null mezőkkel. Egyetlen tábla használatával három táblázat helyett két táblához csatlakozhat.
Megjegyzések
- Tehát ha egy a sokhoz viszonyot modellezök (opcionális részvétellel az: 1 oldalon) idegen kulcsot kell használnom annak ellenére, hogy
NULLértékei lehetnek? - @Tom igen, hogy pontosan hogyan modellezhető. Bár technikailag lehetséges a csatlakozási tábla használata, az adatmodell sokaknak sokak számára lehetővé teszi, így kiváltókra és adatbázis-logikára lesz szükség ennek megakadályozásához. Jobban jársz, ha úgy korlátozod a kapcsolatot, hogy lehetetlen helytelen adatokat adni.
- Szerkesztettem a kérdésemet.Csak a
student_id-t csináltam elsődleges kulcsként aSchool_has_Studenttáblázatban, amely a sokakat megtartotta. Milyen hátrányai vannak ennek a módszernek egy idegen kulcs használatával? - @Tom szerkesztettem a válaszomat.
Válasz
Ön egy fenti megjegyzésben írta:
az “Adatbázis-rendszerek alapjai” című könyv […] szerint [.. .] azt javasoljuk, hogy kereszteződési táblázatot használjon, ha az idegen kulcs oszlopban sok NULL érték található (például: ha az alkalmazottak 98% -a nem kezel osztályt)
Ha sok NULL érték van az idegen kulcs oszlopban, akkor a programjainak ezzel a többnyire üres oszloppal kell foglalkozniuk minden egyes feldolgozott rekordnál. Az oszlop valószínűleg elfoglal némi lemezterületet annak ellenére, hogy az esetek 98% -ában üres, a kapcsolat lekérdezése azt jelenti, hogy lekérdezzük azt az oszlopot, amely nagyobb hálózati forgalmat eredményez, és ha olyan ORM-et használ, amely osztályokat generál a táblákból, akkor a programjainak is több helyre lesz szükségük oldalt a szükségesnél Az ection tábla ezt elkerüli, csak olyan linkrekordok lesznek szükségesek, ahol az egyenértékű idegen kulcs különben nem lenne NULL.
Ezzel szemben, ha nem csak néhány NULL érték van, akkor mondjuk 50% -ot vagy annál többet A kapcsolatok nem NULL értékűek, a kereszteződési tábla használata ellentétes hatást eredményez – nagyobb lemezterület, nagyobb bonyolultság, ami nagyobb hálózati forgalmat eredményez stb.
Tehát a kereszteződési tábla használata csak egyfajta optimalizálás, ésszerű csak egy konkrét eset, és különösen manapság, amikor a lemezterület és a memória olcsóbbá vált, és sokkal ritkábban volt rá szükség. Ne feledje, hogy az “Adatbázis-rendszerek alapjai” eredetileg több mint 20 évvel ezelőtt íródott (találtam hivatkozást a második kiadásra 1994-ből), és azt hiszem, ez az ajánlás akkor már ott volt. 1994 előtt a téroptimalizálás valószínűleg sokkal fontosabb volt, mint manapság, mivel a tömeges tárolás még mindig drágább volt, a számítógépek és a hálózatok pedig sokkal lassabbak voltak, mint manapság.
Megjegyzendő egy válogatós megjegyzéshez: a A fenti állítás csak azt próbálja megelőlegezni, amit az “Adatbázis-rendszerek alapjai” szerzője ajánlása során figyelembe vett, azt hiszem, durva, általános megállapítást tett, amely a legtöbb rendszerre érvényes. Egyes adatbázisokban vannak más lehetséges optimalizálások, például a “ritka oszlopok”, amelyek még inkább elavulttá teszik a kereszteződési tábla használatát.
Tehát ne tévessze meg ezt az ajánlást. A könyv nem mondja el inkább a keresztezési táblákat részesítse előnyben a {0,1}:n kapcsolatok számára általában, vagy – ahogy írta -, hogy ez a “helyes út”. Használjon ehhez hasonló optimalizálásokat, amelyek csak akkor bonyolítják a programokat nagyon szükségük van rájuk.
Megjegyzések
- Ön ‘ sokat feltételez a adatbázis, különös tekintettel arra, hogy az OP nem ‘ nem említett egy konkrétat. ‘ több mint valószínű, hogy az adatbázis elég okos ahhoz, hogy használhassa csak egy kis hely a ritka oszlopok számára.
- @gardenhead: mi készteti Önt arra, hogy ez ” több mint valószínű “?
- Az a tény, hogy az adatbázisok rendelkeznek évtizedek óta létezik, és nagyon optimalizáltak, mivel a legtöbb infrastruktúra kritikus elemét képezik.
- @gardenhead: úgy hangzik számomra, hogy nagyon sok indokolatlan feltételezést teszel, mint én. Ennek ellenére lásd a szerkesztésemet.
Válasz
A koncepcionális modell így fog kinézni, ami nagyon unortodox hogy kevesebbet mondjak:
A fizikai modell így fog kinézni, ami zavaró hogy kevesebbet mondjak (az emberek azt hiszik, hogy M: M, ha nem látják jól):
Javaslatom:
Ha tetszik, sok oszlop (FK vagy más), amely nem vonatkozik a legtöbb diákra, szétválasztja a táblázatokat szereptáblákba 1: 1 relekkel. De ez nem azért van, mert FK, azért, mert az oszlopok nem vonatkoznak a legtöbb sorra.
Egyébként , A nullable FK az adatbázis normális része, és a csatlakozási táblák általában M: M relek.
Az 1: 1 relek gyakori felhasználása azoknak a szereplési tábláknak, amelyek oszlopai csak akkor alkalmazhatók, ha az entitás egy bizonyos típusú, és BLOB oszlopokat vonnak ki teljesítmény vagy tárolási szempontokból. A nullértékek elkódolása az FK-kban nem egy általános használat erre.
Válasz
Más válaszok mellett szeretném felhívni a figyelmet arra, hogy az idegen kulcs nullértéke félreérthető. Ez azt jelenti:
1) A tanuló iskolája (ha van ilyen) ismeretlen (ez a “null” általános jelentése – az érték ismeretlen)
2) Ez ismert, hogy a hallgatónak van-e iskolája, és nincs is.
Ha a null szabványos jelentését használja, akkor hogyan képviselné a „kulcsa nincs iskolának” a külföldi kulcsmodellben. Ebben az esetben: valószínűleg létre kell hoznia egy “nincs iskola” bejegyzést, azzal a saját azonosítóval az iskolai táblázatban. (Nem ideális)
Megjegyzések
- A ” Az adatbázis-rendszerek alapjai című könyv ” megemlíti, hogy a
NULL, ez azt jelentheti: 1) Ismeretlen érték. 2) Nem érhető el vagy visszatartott érték. 3) Nem alkalmazható attribútum (szerintem ez az értelmezés azt jelenti, hogy megadhat egyNULLidegen kulcs esetén). - Ez a ‘ hasznos lista, de a null (vagy bármelyik érték) szemantikája felhasználó által meghatározható.jelenthet bármit is, amit a tervező mond, és nem korlátozódik erre a listára. A kérdés az, hogy hogyan lehet megkülönböztetni a különböző jelentéseket, amikor többre lehet szükség (vagy akár akaratlanul is menthető)
- Tehát azt javasolja, hogy hozzon létre egy metszés táblázatot ahelyett, hogy semmissé váló idegen kulcsot használnék?
- @Tom Igen, úgy gondolom, hogy ez jobb ebben az esetben
- @BradThomas – hogy elkerülje ugyanazt a kétértelműséget metszéspontos tábla használatakor, képviselné-e a 2. esetet (ismert, hogy a hallgató nincs iskola) a kereszteződési táblázatban egy NULL School_ID azonosítóval?
Válasz
Az adatbázis táblákban ez szerepel kényszerűségnek nevezett szép dolog. Tehát nagyon könnyű elkészíteni a kereszteződési táblázatot, amely lehetővé teszi, hogy minden hallgató közül csak 1 jelenjen meg a táblázatban, de sok iskola szerepeljen ebben a táblázatban. Hatékonyan ad egy
elméletet, de jó, de végül az Ön által feltett kérdések után fogod modellezni az adatbázisodat.
Ha gyakran szeretnéd feltenni a kérdést: “melyik diák van az iskolámban”, akkor valóban a teljes diáktáblázatot akarod megkérdezni, vagy könnyű metszéspont-tábla.
Adatbázisokban: optimalizáljon a feltett kérdésekre.
Válasz
Ott olyan felhasználási eset, amikor egy harmadik táblázat használata valóban értelmes lehet. A példa tisztán hipotetikusnak tűnhet, de remélem, hogy jól szemlélteti a véleményemet. Tegyük fel, hogy további oszlopokat ad hozzá a students táblához, és egy bizonyos ponton úgy dönt, hogy az oszlopokban az egyediséget több oszlopban lévő összetett indexen keresztül érvényesíti. Nagyon valószínű, hogy “Tartalmaznia kell a school_id oszlopot is, és itt a dolgok rendetlenné válnak. Az SQL tervezésének módja miatt több azonos rekordot kell beilleszteni, ahol school_id NULL lehetséges lesz. Ez technikai szempontból teljesen logikus, de ellentmondásos és váratlan eredményekhez vezethet. Másrészt az egyediség érvényesítése a metszéstábla egyszerű.
Nemrég egy ilyen “opcionális” kapcsolatot kellett modelleznöm, ahol az egyediség korlátozásának követelménye az időbélyeg oszlopának volt köszönhető. A nullázhatatlan idegen kulcs hagyása a táblázatban hirtelen a rekordok beillesztésének lehetősége ugyanazzal az időbélyeggel (tegyük fel, hogy alapértelmezett, be van állítva olyan rekordokra, amelyeket még nem auditáltak / jóváhagytak oved yet) – és az egyetlen kiút az érvénytelen oszlop eltávolítása volt.
Tehát, mint láthatja, ez “meglehetősen konkrét eset, és ahogy mások megjegyezték, a legtöbbször teljesen rendben vagy az NULL értékeket. Ez valóban a modelled egyedi követelményeitől függ.
Válasz
A már elküldött sok jó javaslat mellett személyesen én is “Nem rajongok az idegen kulcsokért, kivéve, ha azok valóban szükségesek. Először ott van az Ön által hivatkozott M: M kapcsolat. Ráadásul egy idegen kulcs meghívása és ezáltal a táblaadatok behúzása a lekérdezésekbe összetettebbé válik, táblázat mérete, lassabb teljesítmény. Amint mások mondták, a semmissé váló FK mezők nem támogatottak, és adatok integritási problémákat okozhatnak.
Ha olyan állapotot definiál, ahol a diákiskola ismeretlen vagy üres, akkor a NULL nem fogja megkülönböztetni ezeket a feltételeket. (ismét visszatérünk az adatok integritásához.) A Tulains szereptábla-javaslata elegáns és tisztán lehetővé teszi a null értékeket.