Adatbázisok, 2. rész: Az entitás-kapcsolat-modell spontán • vad • és • sütemény

Ki spontán, ki vad és mindenekelőtt: hol a torta?

A sorozat első részében azt tapasztaltuk, hogy az adatbázisok használata jó dolog, mert a fejlesztőnek már nem kell foglalkoznia az adattárolás alapvető funkcióival. Azt azonban már láttuk, hogy az ésszerű adatmodellezés elengedhetetlen. Vagy más szavakkal:

Mielőtt megkezdődhet egy értelmes adatbázis-tervezés, elengedhetetlen, hogy tisztában legyünk a való világ feltérképezendő szakaszával. Erre a célra Peter Chen által 1976-ban bevezetett entitás-kapcsolat modell ajánlott, amely leírja az entitásokat, vagyis a való világ dolgait, azok tulajdonságait és közöttük fennálló viszonyait. Ebben a cikkben kitérünk ennek a modellnek az alapjaira. Kemper és Eickler tankönyvében az entitáskapcsolati modellt a 2. fejezet tárgyalja.

Mivel a tényleges adattárolás a közös DBMS-ben a relációs modellen alapul, azaz táblázatos formában, azzal is foglalkoznunk kell, hogyan lehet az entitáskapcsolati modellt átalakítani relációs modellré. Sok esetben ez meglehetősen egyértelmű és jó adatbázis-sémákhoz vezet, amelyek nem tartalmazzák a sorozat első cikkében kiemelt problémákat, például az elbocsátásokat.

Az E/R modell

A valós világ azon részének modellezéséhez, amely számunkra érdekes, tisztáznunk kell a következő pontokat:

Milyen dolgok vannak a való világban?
Melyek a tulajdonságaik?
Hogyan kapcsolódnak egymáshoz?

A való világ említett dolgait entitásoknak, a tulajdonságokat pedig attribútumoknak nevezzük az Entitás-Kapcsolat-Modellben (vagy egyszerűen E/R-Modellben).

Hasonló entitások halmazát entitástípusnak is nevezzük. Hasonlóképpen a kapcsolattípusokról is beszélünk, ha két entitástípus közötti általános kapcsolatot értjük.

Ennek egyértelművé tétele érdekében térjünk vissza például az első részről: a címlistáról.

A most említett három kérdéssel kapcsolatban a következő megfigyeléseket tehetjük: A valós világban a címlistánkhoz tartozó dolgok elsősorban emberek. Az emberek lakásokban laknak, az apartmanok pedig helyenként. Az emberek jellemzői, amelyek a címlistánk szempontjából relevánsak, a vezeték- és utónév. Az utca és a házszám a lakás tulajdonságai, és a helynek helyneve és irányítószáma van.

A Chen jelölésben az entitástípusokat téglalapokkal, a kapcsolattípusokat pedig gyémántokkal jelöljük. Az attribútumokat általában ellipszisekkel ábrázolják az entitáskapcsolati diagramban. Ha vannak olyan attribútumok, amelyek alkalmasak egy egyedi entitás egyedi azonosítására, ezt aláhúzással lehet jelezni. Az ilyen tulajdonságokat kulcsattribútumoknak nevezzük. Példánkban a hely irányítószáma kulcsattribútum, mivel a hely egyértelműen meghatározva van, ha az irányítószám ismert.

E/R diagram a címlistához

Az entitástípusok közötti kapcsolatok még pontosabban jellemezhetők. Ahogy a példánkban az utolsó részben tárgyaltuk, egy személynek több lakása is lehet. Többen lakhatnak ugyanabban a lakásban. Ez egy úgynevezett N: M kapcsolat: egy entitás tetszőleges számú entitással kapcsolatba hozható a másik oldalon, és fordítva.

Az otthon és a hely viszonya viszont 1: N kapcsolat: Egy helyen több lakás is lehet, de egy lakás mindig csak egy helyen van.

Megvalósítás a táblázatokban

A relációs adatbázis-kezelő rendszerek (RDBMS) adatokat táblákban tárolnak. Tehát ennek megfelelően kell megvalósítanunk az E/R modellt a gyakorlati használat érdekében. Látható, hogy amit el akarunk tárolni, azok az entitások tulajdonságai. A táblázatok szempontjából abból áll, hogy az attribútumok egy táblázat oszlopává válnak. Minden entitástípushoz külön tábla jön létre.

Entitástípusok

Eddig van egy táblázat az emberek számára, ahová a vezetékneveket és keresztneveket beírják, az utcák és házszámok oszlopokkal ellátott apartmanok táblázata, valamint az irányítószám és a helység neve oszlopokkal ellátott városok táblázata. Az egyes személyek, lakások és helyek, azaz az egyes entitások megfelelnek a táblázatok sorainak.

1: N kapcsolat

Most még fel kell térképezni a kapcsolatokat. Lakások és helyek esetében a kapcsolat feltérképezése egyszerű. Mivel egy lakás legfeljebb egy helyen található, és az irányítószám egyértelműen meghatározza a helyet, elegendő egy további oszlopot feltüntetni az irányítószám számára az apartmanok táblázatában. Az ebben az oszlopban szereplő érték hivatkozik a helyre. A helynevet viszont nem szabad bemásolni az apartmanok táblájába, különben redundanciát hoznánk létre: Az a tény, hogy egy bizonyos irányítószám egy adott helyre tartozik, már szerepel a Hely táblázatban, és máshol nem szabad megismételni.

Az apartmanok és a helyek közötti 1: N kapcsolat ábrázolása annyira bonyolult, mert egy kulcs már rendelkezésre áll a helyek irányítószámával együtt, és ez a kulcs közvetlenül használható referenciaként az Apartmanok táblázatban, mivel egy lakás csak egy helyen lehet tud. A Város tábla irányítószám oszlopát elsődleges kulcsnak (PK) is nevezik. Az elsődleges kulcs egyedileg azonosítja a táblázat egy sorát. A Lakás táblázatban az irányítószám lesz az idegen kulcs (FK). Az irányítószám nem maga az apartman tulajdona, hanem az a hely, ahol az apartman található. Éppen ezért az irányítószámot nem rögzítik a lakás attribútumaként az E/R modellben! Az idegen kulcs oszlop csak két entitás közötti kapcsolat létrehozására szolgál.

Fontos, hogy a kapcsolat egyszerű idegen kulcs oszlopon keresztül történő létrehozása csak akkor működjön, ha az idegen kulcsot N oldalra pakoljuk 1: N kapcsolatok esetén. Mivel egy helyen több apartman található, a táblázat egyetlen oszlopa a helyszínekhez nem lenne elegendő a kapcsolat bemutatásához!

Mesterséges kulcsok

Az emberek és az otthonok közötti kapcsolat esetében a kapcsolat táblázatokká történő lefordítása kissé bonyolultabb. Először is, az E/R modellben nem rögzítettünk olyan tulajdonságokat, amelyek egyedileg azonosíthatnák az embereket vagy az apartmanokat. Az első részben már megfontoltuk a számok egyszerű kiosztásának lehetőségét erre a célra. Ezután meg tudunk különböztetni két azonos nevű embert, akik még mindig különböző emberek, ha különböző számokat rendelünk hozzájuk. Az ilyen számot mesterséges kulcsnak vagy helyettesítő kulcsnak is nevezik. Ez nem az entitás valódi tulajdona, hanem mi adjuk hozzá, és csak az egyértelmű azonosíthatóság érdekében használják.

A hely irányítószámával természetesen azt lehetne vitatni, hogy valójában egy mesterséges kulcs is, mivel az irányítószámot szintén emberek készítették és önkényesen rendelték hozzá. Az irányítószám előállítása azonban nem áll rendelkezésünkre, mivel azt egy másik ügynökség (nevezetesen a posta) határozta meg. Emiatt az irányítószám természetes kulcsnak tekinthető. Csak akkor lehetne mesterséges kulcsról beszélni, ha utána hozzáadtuk ezt a kulcsoszlopot, és valószínűleg nem szerepelt az eredeti E/R diagramban. Egyébként nem szükséges, hogy az adatok beillesztésekor a mesterséges kulcs konkrét értékét felkockázzuk. A DBMS maga generálhatja az értéket egy mesterséges kulcs számára. Ennek például az az előnye, hogy ha több egyidejű beillesztési művelet van, akkor két felhasználó nem választhatja ki ugyanazt az értéket, ami hibákhoz vezetne.

N: M kapcsolatok

Visszatérve a példánkhoz, először hozzáadunk egy oszlopot egy mesterséges elsődleges kulcshoz a személyeknek szóló táblázatban és az apartmanok táblázatában, ezeket „PNr” -nek hívjuk, a személyi számot pedig „WNr” -nek. . Ezekkel a kulcsokkal most megmutathatjuk az ember és az otthona közötti kapcsolatot. Ugyanakkor, csakúgy, mint az egy a sokhoz viszony esetében, nem állíthatunk egyszerűen oszlopot idegen kulcsként egyik oldalon sem. Az embernek koncepcionális modellünk szerint több lakása is lehet, tehát itt egyetlen oszloppal sem tudunk boldogulni. Modellünk szerint azonban egy lakásban többen is lakhatnak, így egy idegen kulcs oszlop sem segítene a Lakás táblázatban.

A megoldás az, hogy külön táblázatot készítünk az N: M kapcsolattípus számára „él”. Ebben az úgynevezett kapcsolattáblázatban egy sor jön létre minden személy és egy lakás közötti kapcsolatra. A kapcsolattábla oszlopai a kapcsolattípusban részt vevő összes entitástípus számára idegen kulcs oszlopok. Példánkban szükségünk van egy táblára, amely „él” a „PNr” és a „WNr” oszlopokkal. Például, ha a 2-es számú személy az 1-es számú lakásban él, akkor ezt a kombinációt egy sorba írjuk be a kapcsolati táblázatba.

Kompozit elsődleges kulcs

Magához a kapcsolattáblához nincs szükség mesterséges elsődleges kulcsra. Mivel azonban a kapcsolati táblázatban a személyi szám és az apartmanszám kombinációja egyedülálló, összetett elsődleges kulcsként használható. (Végül is egy ember különböző lakásokban élhet, és különböző emberek egy lakásban élhetnek, de az a tény, hogy egy személy többször ugyanabban a lakásban él, nem lenne ésszerű tény, és ezért nem szabad beírni a táblázatba.)

A címadatbázis táblázatai

Kapcsolattípus attribútumok

Egyébként a kapcsolattípusoknak is lehetnek tulajdonságaik. Címlista példánk kiterjesztéseként tekintsük át röviden a termékek és megrendelések modellezésére szolgáló E/R diagramot. Egy személy több megrendelőlapot küldhet, de megrendelést csak egy személy ad le. Minden termék több terméket is tartalmazhat. Termék természetesen többször is megrendelhető.

Ha egy adott terméket többször fel kell venni egy megrendelésbe - például az ügyfél egyszerre öt rózsaszín fogkefét rendel -, a megrendelés mennyisége a kapcsolat jellemzője! Végül lehetnek olyan ügyfelek, akik csak egy fogkefét akarnak megrendelni, és ugyanaz a megrendelés, amely öt fogkefét tartalmaz, egyetlen sárga gumikacsát is tartalmazhat. A rendelési mennyiség következésképpen nem lehet se a termék se önmagában, se a megrendelés nyomtatványa, hanem, mint már említettük, a termék és a megrendelés kapcsolatának tulajdonsága.

E/R modell megrendelések útján

Az entitástípusokhoz hasonlóan az attribútum is oszlopként kerül megvalósításra egy táblázatban. Mivel a „tartalmaz” kapcsolattípus N: M kapcsolattípus, az átalakításhoz mindenképp egy kapcsolattábla szükséges, amelyhez egyszerűen hozzáadódik a rendelési mennyiség oszlopa. A két idegen kulcs kombinációja továbbra is a kapcsolattábla elsődleges kulcsa. Egy megrendelés nem tartalmazhatja ugyanazt a terméket kétszer, különböző mennyiségekkel. Fogalmilag ennek sem lenne értelme.

Asztalok megrendelésekhez és termékekhez; vegye figyelembe az "összeg" oszlopot

módszer

Tehát összegezzük azokat a lépéseket, amelyek az E/R modelltől a táblákig vezettek minket:

Az egyes Entitás típusa: Táblázat létrehozása
Az egyes tulajdonság: Oszlop létrehozása
Bármely asztalhoz, természetes nélkül kulcs: Mesterséges kulcs hozzáadása
Az egyes 1: N kapcsolattípus: Adjon idegen kulcs oszlopot N oldalra
Minden N: M kapcsolat: Adjon hozzá kapcsolati táblázatot idegen kulcs oszlopokkal a kapcsolatba bevont entitástípusokhoz, és tegye azokat összetett elsődleges kulcsokká; vegye figyelembe a kapcsolattípus meglévő attribútumait

Mivel később részletesebben elemezzük, ez a lépésenkénti megközelítés elvezetett minket egy táblákból álló adatbázis-tervezéshez, amely nem tartalmaz redundanciát.

Elsődleges és idegen kulcsok

Az elsődleges és az idegen kulcsok (PK és FK) esetében a következő pontokat mondhatjuk el:

A PK értéknek egyedinek kell lennie, és azonosítania kell egy sort a táblázatban
Ha a PK több oszlopból áll, akkor az oszlopokban szereplő értékek kombinációjának egyedinek kell lennie
Az FK kapcsolatot hoz létre egy másik táblával
Az egyik táblázat FK oszlopa egy másik táblázat oszlopához kapcsolódik (ez általában egy PK oszlop)
Csak azok az értékek engedélyezettek az FK oszlopban, amelyekre vonatkozik

Tervezési szintek

A példánkban a tervezés két különböző szintjén dolgoztunk. Fogalmi szinten létrehoztuk az E/R modellt. Tisztán koncepcionális modellként teljesen független az adatbázisoktól! Használhatnánk az E/R modellt olyan dolgok modellezésére is, amelyeket utólag nem akarunk megvalósítani egy adatbázisban. Ennek ellenére hasznos a célunk szempontjából, mivel utat nyit számunkra egy jó adatbázis-séma kialakításához.

A relációs modell adatbázis-sémájának megvalósítása a megvalósítás szintjén történik.

Az adatbázis-tervezés fizikai szintje még mindig megvan, de mivel az első részben tárgyalt fizikai adatelérés elvonatkozik a DBMS-től, nem először kell ezzel foglalkoznunk.

A relációs modell

Mivel létezik entitáskapcsolati modell és relációs modell, és ezek a kifejezések hasonlóak, fennáll az összetévesztés veszélye! Mivel az E/R modell és a relációs modell két teljesen különböző dolog. Mint az imént láttuk, a tervezés különböző szintjein is játszanak! Az angol „relationship” szót nem németül „Relation” -nek, hanem „Relationship” -nek fordítják. A relációs modell nevét a matematika kapcsolatairól kapta. Amint azt az első részben már leírtuk, az adatbázisok relációs modellje Edgar F. Codd 1972-es esszéjéhez vezet vissza.

Kapcsolatok a matematikában

A matematikában egy relációt úgy definiálunk, mint n másik D1, ... Dn halmaz derékszögű szorzatának részhalmazát, amelyeket doméneknek vagy értéktartományoknak is nevezünk. A derékszögű szorzat vagy kereszttermék D1 ×… × Dn az elemek lehetséges páros kombinációinak halmazát jelöli D1-től Dn-ig. Az R reláció tehát: R ⊆ D1 ×… × Dn

Vegyünk egy relációt R ⊆ D1 × D2, ahol D1 az összes ötjegyű egész halmaza, D2 pedig az összes lehetséges karakterlánc halmaza. A D1 × D2 ekkor az ötjegyű számok és az esetleges karakterláncok összes lehetséges kombinációja. A hozzátartozó helynevekkel rendelkező irányítószámok listája, mint például a helytáblázatunk, ennek egy részhalmaza!

Tehát céljaink szempontjából meg tudjuk érteni a relációt mint táblázatot (beleértve annak tartalmát is). (Egy későbbi időpontban látni fogjuk, hogy ez egyszerűsítés, és vannak olyan részletek, amelyekben a DBMS táblázatai és a kapcsolatok eltérnek.)

Összegzés

Az adatbázisokról szóló sorozat második cikkében az adatbázis tervezését vizsgáltuk. Megismertük az entitáskapcsolati modellt, mint olyan fogalmi modellt, amellyel a való világban a dolgok feltérképezhetők tulajdonságaikkal, és hogyan kapcsolódnak egymáshoz. Láttuk azt is, hogyan lehet egy entitás kapcsolati modellt átalakítani táblákból álló relációs modellvé. Erre az átalakításra azért van szükség, mert a DBMS táblákban tárolja az adatokat, és közvetlenül nem tud mit kezdeni az E/R modellekkel.

kilátások

A következő részben a mai címjegyzékünkhöz tervezett relációs adatbázis-modellt valós DBMS-ben valósítjuk meg. Azt is leírja, hogyan lehet táblákat létrehozni egy DBMS-ben SQL-el. A következő egy részben elmélyítik az E/R modellt, és további kapcsolattípusokat és azok megvalósítását a relációs modellben tárgyalják.