4.1 Bevezetés
Ha az adatbázistáblákat normál táblákká alakítja, elemezheti a köztük lévő kapcsolatokat. A két kapcsolódó tábla között kölcsönhatásba lépő elemek számát számosságnak nevezzük. A Cardinality segít szabályozni, hogy milyen hatékonyan particionálja az adatokat táblákba.
Elméletileg minden entitás kapcsolatot tarthat fenn egymással, de a gyakorlatban háromféle kapcsolat létezik az entitások között:
- 1-1
- Egy a sokhoz
- sok a sok
4.2 Egyéni kommunikáció
Ha az A entitásnak csak egy példánya van a B entitás minden egyes példányához, akkor azt mondják, hogy egy az egyhez viszonyban állnak (gyakran "1:1"-ként jelölik). Az ER diagramokon az ilyen kapcsolatot egy vonal jelzi, amelynek mindkét végén egy kis oszlop található:
Az 1:1-es kapcsolat általában azt jelzi, hogy a két tábla adatait a legjobb egyesíteni, hacsak nincs jó okunk arra, hogy elkülönítsük őket.
Bizonyos körülmények között azonban ésszerű az 1:1 arányú táblák használata. Ha a tábláiban vannak opcionális adatokat, például leírásokat tartalmazó mezők, és ezek sok esetben üresek, érdemes az összes leírást egy külön táblába áthelyezni, ami lehetővé teszi, hogy megszabaduljon a gyakori hiányosságoktól és növelje az adatbázis hatékonyságát. .
Ezután az adatok megfelelő leképezéséhez minden táblában legalább egy azonos oszlopot kell tartalmaznia (a legjobb, ha elsődleges kulcsot választ).
4.3 Egy-a többhez kapcsolat
Ez a fajta kapcsolat akkor fordul elő, ha az egyik tábla rekordja egy másik táblában több entitáshoz van társítva. Például ugyanaz az ügyfél több rendelést is leadhat, vagy egy könyvtárlátogató több könyvet is kölcsönözhet egy látogatás során. Az egy a sokhoz kapcsolatokat (vagy röviden 1:M) egy diagramban fejezzük ki szarkalábak jelölésével, az alábbi példában látható módon:
1:M kapcsolat alkalmazásához adatbázis tervezése során egyszerűen adja hozzá az elsődleges kulcsot az "egy" táblából attribútumként a "sok" táblához. Ha az elsődleges kulcs egy másik táblában van, azt "idegen kulcsnak" nevezik. Az "egy" tábla a szülő tábla, míg a "sok" tábla a gyermek tábla.
4.4 Sok-sok kapcsolat
Ha egy tábla több entitása összekapcsolható egy másik több entitással, akkor a rendszer több a sokhoz (vagy M:M) kapcsolattal rendelkezik. Ilyen kapcsolat van például a tanulók és az osztályok között, hiszen minden diák több különböző órára járhat, és ennek megfelelően sok diák érkezhet egy-egy órára.
Az ER diagramon ez a típusú kapcsolat a következőképpen jelenik meg:
Sajnos lehetetlen közvetlenül megvalósítani egy ilyen kapcsolatot az adatbázisban. Ezért fel kell osztani két egy-több kapcsolatra.
Ehhez létre kell hoznia egy új entitást a két tábla között. Ha M:M kapcsolat jön létre az értékesítés és a termékek között, akkor az új entitást "eladott termékeknek" nevezhetjük, mert ez fogja képviselni az egyes eladások tartalmát.
Az "eladott áruk" és az "eladások" táblázat és az "áru" táblázat az 1:M típus szerint lesz összekapcsolva. A különböző modellekben az ilyen közbenső entitásokat különbözőképpen hívják - "összekötő táblák", "asszociatív entitások" vagy "csomóponttáblák".
Minden hivatkozási tábla bejegyzés a szomszédos táblák két különböző entitását köti össze (és további információkat is tartalmazhat). Például egy hivatkozási táblázat a tanulók és az osztályok között így nézhet ki:
4.5 Kötelező vagy sem?
A linkelemzés másik megközelítése annak meghatározása, hogy a kapcsolódó entitások közül melyik előfeltétele egy másik entitás jelenlétének. Az opcionális linkoldalt egy kör jelöli a törzsön.
Például ahhoz, hogy egy államnak saját képviselője legyen az ENSZ-ben, léteznie kell a világtérképen, de az ellenkező állítás hamis lesz:
Két entitás függhet egymástól (azaz egyik nem létezhet a másik nélkül).
Rekurzív hivatkozások
Néha egy táblázat hivatkozhat önmagára. Például egy alkalmazotti tábla tartalmazhat egy „menedzser” attribútumot, amely ugyanabban a táblában egy másik alkalmazottra utal. Ez a rekurzív kapcsolat.
Extra csatlakozások
A hivatkozások redundánsnak minősülnek, ha egynél többször szerepelnek. Általában az egyik törölhető fontos információk elvesztése nélkül. Például, ha a „tanárok” entitás nem csak közvetlenül, hanem közvetetten is „osztályokon” keresztül kapcsolódik a „tanárok” entitáshoz, akkor célszerű a „diákok” és „tanárok” entitások közötti kapcsolatot megszüntetni. Ezt a döntést az indokolja, hogy csak tanórákon keresztül lehet tanulókat tanárhoz rendelni.
4.6 Az adatok hivatkozási integritása
Az elsődleges és az idegen kulcs megváltoztatásakor figyelembe kell venni egy olyan szempontot, mint az adatok hivatkozási integritása . Fő ötlete az, hogy két táblát tartson egy adatbázisban, amelyek konzisztens módon tárolják ugyanazokat az adatokat.
Az adatintegritás a táblák közötti, megfelelően felépített kapcsolatokat jelenti, a köztük lévő helyes hivatkozással. Milyen esetekben sérülhet meg az adatintegritás:
- Törlési anomália . Akkor fordul elő, ha egy sort törlünk a főtáblából. Ebben az esetben a függő táblából származó idegen kulcs továbbra is a fő tábla törölt sorára hivatkozik.
- Beillesztési anomália . Akkor fordul elő, ha egy sort beszúrunk egy függő táblába. Ebben az esetben a függő táblából származó idegen kulcs nem egyezik a fő tábla egyik sorának elsődleges kulcsával.
- Frissítési anomália. Egy ilyen anomália esetén egy tábla több sora tartalmazhat ugyanahhoz az objektumhoz tartozó adatokat. Ha az egyik sorban módosítja az adatokat, azok ütközhetnek egy másik sor adataival.
Törlési anomália
A törlési anomália feloldásához az idegen kulcsot két megszorítás egyikére kell beállítani:
Ha egy függő tábla sora szükségszerűen megköveteli a fő tábla sorát, akkor az idegen kulcs kaszkádtörlésre van állítva. Ez azt jelenti, hogy egy sor törlésekor a fő táblából a kapcsolódó sor(ok) törlődnek a függő táblából.
Ha egy függő tábla egy sora nem engedélyez kapcsolatot a fő tábla egy sorával (vagyis egy ilyen kapcsolat nem kötelező), akkor az idegen kulcs NULL lesz, amikor a kapcsolódó sort törli a főtáblából. Az idegen kulcs oszlopának nullázhatónak kell lennie.
Beillesztési anomália
A beszúrási anomália feloldásához függő adattáblázathoz való hozzáadásakor az idegen kulcsot jelentő oszlopnak nullázhatónak kell lennie. Így, ha a hozzáadandó objektumnak nincs kapcsolata a főtáblával, akkor az idegen kulcs oszlop értéke NULL lesz.
Frissítési anomáliák
A frissítési anomália probléma megoldása érdekében a normalizálást alkalmazzák, amelyet korábban tárgyaltunk.
GO TO FULL VERSION