Az idegen kulcsot tartalmazó relációt nevezzük. Elsődleges és idegen kulcs megszorítások. 3.4. Normalizált kapcsolatok halmaza

Utolsó frissítés: 2017.02.07

Az adatbázisok tartalmazhatnak táblázatokat, amelyeket különféle hivatkozások kapcsolnak össze. A kapcsolat különböző típusú entitások közötti asszociációt jelent.

A kapcsolat kiválasztásakor egy elsődleges vagy szülő tábla (elsődleges kulcstábla / főtábla) és egy függő, utódtábla (idegen kulcstábla / gyermektábla) kerül kiválasztásra. A gyermektábla a szülőtáblától függ.

Az idegen kulcsokat a kommunikáció szervezésére használják. Az idegen kulcs egy tábla egy vagy több oszlopát jelöli, amely egyben egy másik tábla lehetséges kulcsa is. Az idegen kulcsnak nem kell egyeznie a főtábla elsődleges kulcsával. Bár általában egy függő táblából származó idegen kulcs a fő tábla elsődleges kulcsára mutat.

A táblák közötti kapcsolatok a következő típusúak:

1-1

Egy a sokhoz

sok a sok(soktól sokig)

Egytől egyig kommunikáció

Ez a fajta kapcsolat nem gyakran található. Ebben az esetben egy entitás objektuma csak egy másik entitás egy objektumához társítható. Például egyes webhelyeken egy felhasználónak csak egy blogja lehet. Vagyis kapcsolat keletkezik: egy felhasználó - egy blog.

Az ilyen típusú kapcsolatok gyakran azt jelentik, hogy egy nagy táblázatot több kicsire osztanak fel. Az elsődleges szülőtábla ebben az esetben továbbra is gyakran használt adatokat tartalmaz, míg a gyermekfüggő tábla jellemzően a ritkábban használt adatokat tárolja.

Ebben a tekintetben a függő tábla elsődleges kulcsa egyben egy idegen kulcs is, amely a főtábla elsődleges kulcsára hivatkozik.

Például a Felhasználók tábla a felhasználókat jelöli, és a következő oszlopokkal rendelkezik:

UserId (azonosító, elsődleges kulcs)

Név (felhasználónév)

A Blogok táblázat pedig a felhasználói blogokat jelöli, és a következő oszlopokkal rendelkezik:

BlogId (azonosító, elsődleges és idegen kulcs)

Név (blog neve)

Ebben az esetben a BlogId oszlop a UserId oszlopból származó értéket tárolja a felhasználók táblázatában. Vagyis a BlogId oszlop elsődleges és idegen kulcsként is működik.

Egy a sokhoz kapcsolat

Ez a leggyakoribb kapcsolattípus. Az ilyen típusú kapcsolatokban egy utódtábla több sora a szülőtábla egyetlen sorától függ. Például egy blogon több cikk is szerepelhet. Ebben az esetben a blogok táblája a szülő, a cikkek táblája pedig a gyermek. Vagyis egy blog - sok cikk. Vagy egy másik példa, több futballista is játszhat egy futballcsapatban. És ugyanakkor egy futballista egyszerre csak egy csapatban játszhat. Vagyis egy csapat - sok játékos.

Legyen például egy Cikk nevű táblázat, amely a blogcikkeket képviseli, és a következő oszlopokkal rendelkezik:

Cikkazonosító (azonosító, elsődleges kulcs)

BlogId (idegen kulcs)

Cím (cikk címe)

Szöveg (cikk szövege)

Ebben az esetben a cikkek táblázat BlogId oszlopa tárolja a blogok tábla BlogId oszlopának értékét.

sok a sok kapcsolat

Ezzel a kapcsolattípussal az A táblázat egy sora a B tábla sok sorához társítható. A B tábla egy sora pedig az A tábla sok sorához társítható. Tipikus példa a hallgatók és a kurzusok: egy hallgató több kurzust vegyen fel, és ennek megfelelően több hallgató is beiratkozhat egy tanfolyamra.

Egy másik példa a cikkek és a címkék: egy cikkhez több címke, több cikkhez pedig egy címke definiálható.

Az SQL Serverben azonban adatbázis szinten nem tudunk közvetlen sok-többhöz kapcsolatot létrehozni két tábla között. Ez egy segédprogramozási táblázaton keresztül történik. Néha az állomásozó táblázatból származó adatok külön entitást képviselnek.

Például cikkek és címkék esetén legyen egy Címkék táblázat, amely két oszlopból áll:

TagId(azonosító, elsődleges kulcs)

Szöveg (címkeszöveg)

Legyen egy közbenső ArticleTags tábla is a következő mezőkkel:

TagId (azonosító, elsődleges és idegen kulcs)

ArticleIdId (azonosító, elsődleges és idegen kulcs)

Technikailag két egy-a-többhöz kapcsolatot fogunk kapni. Az ArticleTags táblázat TagId oszlopa a Címkék táblázat TagId oszlopára fog hivatkozni. Az ArticleTags táblázat ArticleId oszlopa pedig a Cikkek tábla ArticleId oszlopára fog hivatkozni. Ez azt jelenti, hogy az ArticleTags tábla TagId és ArticleId oszlopai egy összetett elsődleges kulcsot képviselnek, és egyben idegen kulcsok a Cikkek és Címkék táblákkal való kapcsolathoz.

Referencia adatok integritása

Az elsődleges és az idegen kulcs megváltoztatásakor a következő szempontokat kell figyelembe venni: hivatkozási adatok integritása(hivatkozási integritás). Az alapötlet az, hogy egy adatbázisban két tábla ugyanazokat az adatokat tárolja a konzisztencia megőrzése érdekében. Az adatintegritás a táblák közötti helyesen felépített kapcsolatokat képviseli, a köztük lévő megfelelő hivatkozásokkal. Milyen esetekben sérülhet meg az adatok integritása:

Törlési anomália(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(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áliák(frissítési anomália). Ilyen rendellenesség esetén ugyanannak a táblának több sora is tartalmazhat ugyanahhoz az objektumhoz tartozó adatokat. Ha az egyik sorban módosítja az adatokat, az ütközhet egy másik sorban lévő adatokkal.

Törlési anomália

A törlési anomália feloldásához két megszorítás egyikét kell beállítania az idegen kulcson:

Ha egy függő tábla sora szükségszerűen megköveteli a fő tábla sorát, akkor az idegen kulcshoz lépcsőzetes törlés van beállítva. Ez azt jelenti, hogy amikor a főtáblából törlünk egy sort, a kapcsolódó sor(ok) törlődnek a függő táblából.

Ha egy függő tábla sora nem engedélyez kapcsolatot a fő tábla soraival (vagyis egy ilyen kapcsolat nem kötelező), akkor az idegen kulcs NULL értékre lesz állítva, 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 adatok függő táblához való hozzáadásakor az idegen kulcsot jelentő oszlopnak nullázhatónak kell lennie. Így, ha a hozzáadott objektumnak nincs kapcsolata a főtáblával, akkor az idegen kulcs oszlop NULL értéket fog tartalmazni.

Frissítési anomáliák

A frissítési anomália problémájának megoldására normalizálást használnak, amelyet később tárgyalunk.

Utolsó frissítés: 2019.04.27

Az idegen kulcsok lehetővé teszik a táblák közötti kapcsolatok létrehozását. Az idegen kulcs egy függő, alárendelt tábla oszlopaira van beállítva, és a főtábla egyik oszlopára mutat. Az idegen kulcs általában egy kapcsolódó főtábla elsődleges kulcsára mutat.

Az idegen kulcs táblaszintű beállításának általános szintaxisa a következő:

IDEGEN KULCS (1. oszlop, 2. oszlop, ... oszlopN) REFERENCIÁK fő_tábla (fő_tábla_oszlop1, fő_tábla_oszlop2, ... fő_tábla_oszlopN)

Idegenkulcs-kényszer létrehozásához a FOREIGN KEY után adja meg az idegen kulcsot képviselő táblázatoszlopot. A REFERENCES kulcsszó után pedig a kapcsolódó tábla neve, majd zárójelben annak a kapcsolódó oszlopnak a neve, amelyre az idegen kulcs fog mutatni. A REFERENCES kifejezés után ON DELETE és ON UPDATE kifejezések találhatók, amelyek a főtáblából egy sor törlésekor, illetve frissítésekor határozzák meg a műveletet.

Például definiáljunk két táblát, és kapcsoljuk össze őket idegen kulccsal:

TÁBLÁZAT LÉTREHOZÁSA Ügyfelek (ID INT PRIMARY KEY AUTO_INCREMENT, Életkor INT, Keresztnév VARCHAR(20) NOT NULL, Vezetéknév VARCHAR(20) NOT NULL, Telefon VARCHAR(20) NOT NULL EGYEDI); TÁBLÁZAT RENDELKEZÉSEK LÉTREHOZÁSA (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Ügyfelek (Id));

Ebben az esetben a Vevők és a Megrendelések táblák vannak meghatározva. Az ügyfelek a fő, és az ügyfelet képviselik. A megrendelések függőek, és az ügyfél által leadott megrendelést jelentik. A Rendelések tábla a CustomerId oszlopon keresztül kapcsolódik a Vevők táblához és annak Id oszlopához. Vagyis a CustomerId oszlop egy idegen kulcs, amely az Ügyfelek tábla Id oszlopára mutat.

Használhatja a CONSTRAINT operátort egy idegenkulcs-kényszer nevének megadásához:

TÁBLÁZAT LÉTREHOZÁSA Rendelések (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT orders_custonmers_fk FORIGN KEY (CustomerId) REFERENCES Ügyfelek (Id));

TÖRLÉSRE és FRISSÍTÉSRE

Az ON DELETE és ON UPDATE utasítások segítségével beállíthatja azokat a műveleteket, amelyek akkor hajthatók végre, ha egy kapcsolódó sort törölnek vagy módosítanak a főtáblából. A következő lehetőségek használhatók műveletként:

CASCADE: Automatikusan törli vagy módosítja egy függő tábla sorait, ha a fő tábla kapcsolódó sorait törli vagy módosítja.

SET NULL: Amikor töröl vagy frissít egy kapcsolódó sort a főtáblából, az idegen kulcs oszlopot NULL-ra állítja. (Ebben az esetben az idegen kulcs oszlopnak támogatnia kell a NULL beállítást)

KORLÁTOZÁS: Elutasítja a fő tábla sorainak törlését vagy módosítását, ha a függő táblában vannak kapcsolódó sorok.

NO ACTION: ugyanaz, mint a KORLÁTOZÁS.

ALAPÉRTELMEZETT BEÁLLÍTÁS: Amikor töröl egy kapcsolódó sort a főtáblából, az idegen kulcs oszlopát az ALAPÉRTELMEZETT attribútum használatával megadott alapértelmezett értékre állítja. Annak ellenére, hogy ez a lehetőség elvileg elérhető, az InnoDB motor nem támogatja ezt a kifejezést.

Lépcsőzetes törlés

A lépcsőzetes törlés lehetővé teszi az összes kapcsolódó sor automatikus törlését a függő táblából, amikor töröl egy sort a főtáblából. Ehhez használja a CASCADE opciót:

TÁBLÁZAT Rendelések LÉTREHOZÁSA (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Ügyfelek (Id) ON DELETE CASCADE);

Az ON UPDATE CASCADE kifejezés hasonló módon működik. Amikor megváltoztatja egy elsődleges kulcs értékét, a hozzá tartozó idegen kulcs értéke automatikusan megváltozik. Mivel azonban az elsődleges kulcsok nagyon ritkán változnak, és általában nem ajánlott a változó értékű oszlopokat elsődleges kulcsként használni, az ON UPDATE kifejezést ritkán használják a gyakorlatban.

NULL beállítása

Amikor a SET NULL opciót állítja be egy idegen kulcshoz, az idegen kulcs oszlopának NULL-al kell lennie:

TÁBLÁZAT Rendelések LÉTREHOZÁSA (ID INT ELSŐDLEGES KULCS AUTO_INCREMENT, Ügyfélazonosító INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Ügyfelek (Id) ON DELETE SET NULL);

Az ábrán egy táblázat látható (5-ös fokozat), amely egy feltételezett vállalkozás alkalmazottairól tartalmaz néhány információt. A táblázat sorai a soroknak felelnek meg. Minden sor tulajdonképpen egy valós objektum (jelen esetben egy alkalmazott) leírása, amelynek jellemzőit az oszlopok tartalmazzák. A relációs kapcsolatok entitáshalmazoknak, a sorok pedig az entitásoknak felelnek meg. A táblázat relációs kapcsolatot reprezentáló oszlopait hívjuk attribútumok.

Minden attribútum egy tartományon van definiálva, így a tartomány egy adott attribútum érvényes értékeinek halmazaként fogható fel. Ugyanazon kapcsolat több attribútuma, sőt különböző kapcsolatok attribútumai is meghatározhatók ugyanabban a tartományban.

Egy olyan attribútumot hívunk meg, amelynek értéke egyedileg azonosítja a sorokat kulcs (vagy egyszerűen kulcs). A kulcs a Személyi szám attribútum, mivel ennek értéke a vállalat minden alkalmazottja esetében egyedi. Ha a sorokat csak több attribútum értékének összefűzésével azonosítjuk, akkor a relációnak összetett kulcsa van.

Elsődleges kulcs- relációs adatmodellben egy kapcsolat egyik lehetséges kulcsa, elsődleges kulcsként (vagy alapértelmezett kulcsként) kiválasztva.

Egy reláció több kulcsot is tartalmazhat. Az egyik kulcs mindig deklarálva van elsődleges, értékei nem frissíthetők. Az összes többi relációs kulcsot meghívjuk lehetséges kulcsok.

Elméleti szempontból minden potenciális (lehetséges) relációs kulcs ekvivalens, azaz azonos egyediségi és minimalitási tulajdonságokkal rendelkezik. Az elsődleges kulcsot azonban általában a lehetséges kulcsok közül választják ki, amely bizonyos gyakorlati célokra, például létrehozáshoz a legkényelmesebb külső kulcsokat más szempontból, vagy fürtözött index létrehozásához. Ezért főszabály szerint a legkisebb méretű (fizikai tároló) és/vagy a legkevesebb attribútumot tartalmazó kulcsot választják elsődleges kulcsnak.

Ha elsődleges kulcs egyetlen attribútumból áll, ezt nevezzük egyszerű kulccsal.

Ha elsődleges kulcs két vagy több attribútumból áll, úgy hívják összetett kulcs. Tehát a keresztnév, vezetéknév, családnév, útlevélszám, útlevélsorozat külön-külön nem lehet elsődleges kulcs, mivel kettő vagy több személynél ugyanaz lehet. De nincs két azonos típusú, azonos sorozatú és sorszámú személyi okmány. Ezért egy személyekre vonatkozó adatokat tartalmazó relációban az elsődleges kulcs az attribútumok egy részhalmaza lehet, amely a személyes dokumentum típusából, sorozatából és számából áll.

A hierarchikus és hálózati adatmodellektől eltérően a relációs modellben nem szerepel a csoportkapcsolat fogalma. A különböző relációk sorai közötti asszociációk tükrözésére a kulcsaik megkettőzését használják.

Azokat az attribútumokat, amelyek más kapcsolatok kulcsainak másolatai, hívják idegen kulcsok.

Például az OSZTÁLY és az ALKALMAZOTT kapcsolatok közötti kapcsolat az elsődleges kulcs másolásával jön létre "Osztályszám" az első kapcsolattól a másodikig. Tehát egy adott részleg alkalmazottainak listájának megszerzéséhez szükséges: 1) A DEPARTMENT táblából állítsa be az attribútum értékét "Osztályszám" , amely ennek a „Osztálynévnek” felel meg. 2) válassza ki az összes rekordot az EMPLOYEE táblából, attribútumérték "Osztályszám" amely megegyezik az előző lépésben kapottal. Annak érdekében, hogy megtudja, melyik osztályon dolgozik egy alkalmazott, fordított műveletet kell végrehajtania: 1) Határozza meg "Osztályszám" az ALKALMAZOTT táblázatból. 2) A kapott értéket felhasználva megtaláljuk a bejegyzést a RÉSZLET táblázatban.

18. Normalizálás relációs adatbázisokban, normálforma fogalma az adatbázistervezésben.

Normál forma - relációs adatmodellben egy kapcsolat olyan tulajdonsága, amely azt a redundancia szempontjából jellemzi, amely potenciálisan logikailag hibás mintavételi vagy adatváltozási eredményhez vezethet. A normál formát olyan követelmények összességeként határozzuk meg, amelyeknek egy relációnak meg kell felelnie.

Az adatbázis normál formájúvá alakításának folyamatát ún normalizálás . A normalizálás célja az adatbázis-struktúra olyan formába hozása, amely minimális redundanciát biztosít, vagyis a normalizálásnak nem célja a munka termelékenységének csökkentése vagy növelése, illetve az adatbázis mennyiségének csökkentése vagy növelése. A normalizálás végső célja az adatbázisban tárolt információk esetleges inkonzisztenciájának csökkentése.

A redundancia kiküszöbölése általában a relációk felbontásával történik oly módon, hogy minden relációban csak elsődleges tények tárolódnak (vagyis olyan tények, amelyek nem következtethetők le más tárolt tényekből).

Funkcionális függőségek.

A relációs adatbázis strukturális és szemantikai információkat is tartalmaz. Az adatbázis szerkezetét a benne lévő kapcsolatok száma és típusa, valamint a kapcsolatok sorai között létező egy-a többhez kapcsolatok határozzák meg. A szemantikai rész leírja azon funkcionális függőségek halmazát, amelyek ezen kapcsolatok attribútumai között léteznek. Határozzuk meg a funkcionális függést.

19. 1NF: Alapvető definíciók és transzformációs szabályok.

Az első normál forma tárgyalásához két definícióra van szükség:

Egyszerű tulajdonság - attribútum, amelynek értékei atomi (oszthatatlanok).

Komplex attribútum - több, azonos vagy különböző tartományon definiálható atomi attribútum összekapcsolásával kapjuk (vektornak vagy adataggregátumnak is nevezik).

Az első normál forma meghatározása:

egy reláció 1NF-ben van, ha az összes attribútum értéke atomi. . Ellenkező esetben ez egyáltalán nem tábla, és az ilyen attribútumokat le kell bontani.

Nézzünk egy példát:

A vállalkozás HR osztályának adatbázisában szükséges a munkavállalókról olyan információkat tárolni, amelyek bemutatására megkísérelhető

ALKALMAZOTT (EMPLOYEE_NUMBER, NÉV, SZÜLETÉSI DÁTUM, MUNKA_TÖRTÉNETE, GYERMEKEK).

Ennek a kapcsolatnak a gondos mérlegeléséből az következik, hogy az attribútumok "munkatörténet"És "gyermekek"összetettek, ráadásul az attribútum "munkatörténet" egy másik összetett attribútumot is tartalmaz "fizetés_történet".
Ezek az egységek így néznek ki:

 ÁLLÁS_TÖRTÉNET (RECEPTION_DATE, NAME, SALARY_HISTORY),

 BÉRET_TÖRTÉNET (POINTMENT_DATE, SALRY),

 GYERMEKEK (CHILD_NAME, BIRTH_YEAR).

Ezek kapcsolata a ábrán látható. 3.3.

3.3. ábra. Kezdeti hozzáállás.

Ahhoz, hogy az eredeti MUNKAVÁLLALÓ relációt az első normál alakba hozzuk, négy relációra kell bontani, amint ez a következő ábrán látható:

3.4. Normalizált kapcsolatok halmaza.

Itt az egyes kapcsolatok elsődleges kulcsa kék kerettel van kiemelve, az idegen kulcsok neve kék betűtípussal. Emlékezzünk vissza, hogy az idegen kulcsok a forrásrelációban létező funkcionális függőségek ábrázolására szolgálnak. Ezeket a funkcionális függőségeket nyilakkal ellátott vonalak jelzik.

A normalizációs algoritmust E.F. Codd a következőképpen írja le:

• A fa tetején lévő relációtól kezdve (3.3. ábra) felvesszük annak elsődleges kulcsát, és minden közvetlenül alárendelt relációt kibővítünk az adott elsődleges kulcs tartományának vagy tartományainak kombinációjával.
• Minden ilyen módon kibővített reláció elsődleges kulcsa a reláció kiterjesztése előtti elsődleges kulcsából és a szülő reláció hozzáadott elsődleges kulcsából áll.
• Ezt követően minden nem egyszerű tartomány törlődik a szülőrelációból, a fa legfelső csomópontja eltávolításra kerül, és ugyanez az eljárás megismétlődik a többi részfánál is.

20. 2NF: Alapvető definíciókés az átalakítási szabályokat.

Nagyon gyakran egy kapcsolat elsődleges kulcsa több attribútumot tartalmaz (ebben az esetben hívják meg összetett) - lásd például az ábrán látható GYERMEKEK összefüggést. 3.4 19. kérdés. Ezzel egyidejűleg bevezetjük a fogalmat teljes funkcionális függőség.

Meghatározás:

egy nem kulcs attribútum funkcionálisan teljes mértékben függ egy összetett kulcstól, ha funkcionálisan a teljes kulcs egészétől függ, de funkcionálisan nem függ egyik alkotó attribútumától sem.

Példa:

Legyen egy SUPPLY (N_SZÁLLÍTÓ, TERMÉK, ÁR) kapcsolat.
Egy szállító különböző termékeket szállíthat, és ugyanazt a terméket különböző szállítók szállíthatják. Akkor a kapcsolat kulcsa "N_beszállító + termék". Minden szállító ugyanazon az áron szállítson árut. Ekkor a következő funkcionális függőségeink vannak:

• N_beszállító, termék -> ár
• termék -> ár

Az árattribútum nem teljes funkcionális függése a kulcstól a következő anomáliához vezet: amikor egy cikk ára megváltozik, a kapcsolat teljes áttekintése szükséges ahhoz, hogy megváltoztassuk a szállítóiról szóló összes rekordot. Ez az anomália annak a következménye, hogy két szemantikai tény egy adatstruktúrában egyesül. A következő kiterjesztés megadja a relációkat a 2NF-ben:

• SZÁLLÍTÁS (N_SUPPLIER, PRODUCT)
• PRODUCT_PRICE (PRODUCT, PRICE)

Szóval adhatsz

A második normál forma meghatározása: Egy reláció 2NF-ben van, ha 1NF-ben van, és minden nem kulcs attribútum funkcionálisan teljes mértékben függ a kulcstól.

21. 3NF: Alapvető definíciókés az átalakítási szabályokat.

A harmadik normálforma tárgyalása előtt be kell vezetni a fogalmat: tranzitív funkcionális függőség.

Meghatározás:

Legyen X, Y, Z valamilyen reláció három attribútuma. Ebben az esetben X --> Y és Y --> Z, de nincs fordított megfeleltetés, pl. Z -/-> Y és Y -/-> X. Ekkor Z tranzitívan függ X-től.
Legyen egy reláció TÁROLÁS ( CÉG, RAKTÁR, KÖTET), amely információkat tartalmaz a raktárakból árut fogadó cégekről és e raktárak mennyiségéről. Kulcs attribútum - "cég". Ha minden vállalat csak egy raktárból tud árut fogadni, akkor ebben a tekintetben a következő funkcionális függőségek vannak:

• cég -> Készlet
• Készlet -> hangerő

Ebben az esetben anomáliák lépnek fel:

• ha jelenleg egyetlen cég sem kap árut a raktárból, akkor a mennyiségére vonatkozó adatok nem vihetők be az adatbázisba (mivel a kulcsattribútum nincs megadva)
• ha a raktár mennyisége megváltozik, meg kell tekinteni a teljes kapcsolatot, és módosítani kell a kártyákat az ehhez a raktárhoz kapcsolódó összes vállalatnál.

Ezen anomáliák kiküszöböléséhez az eredeti relációt két részre kell bontani:

• TÁROLÁS ( CÉG, KÉSZLET)
• STORAGE_VOLUME ( KÉSZLET, HANGERŐ)

A harmadik normál forma meghatározása:

Egy reláció 3NF-ben van, ha 2NF-ben van, és minden nem kulcs attribútum nem függ tranzitív módon az elsődleges kulcstól.

Az InterBase a következő típusú korlátozásokat használhatja:

• PRIMARY KEY - a tábla elsődleges kulcsa.
• EGYEDI – egyedi táblakulcs.
• IDEGEN KULCS- idegen kulcs, hivatkozást biztosít egy másik táblához, és garantálja a hivatkozási integritást a szülő és a között gyermek asztalok.

Megjegyzés a terminológiához

Ha olyan vagy, mint ennek a kurzusnak a szerzője abban, hogy szeretsz átfogóan, különböző szerzők különböző műveiben választ keresni egy téged érdeklő kérdésre, akkor a definíciókban némi zavart észlelhetsz. fő (mester) -> beosztott (részlet) táblázatok. Emlékezzünk vissza, hogy a főtáblát gyakran szülőtáblának, az alárendelt táblát pedig gyermektáblának nevezik.

Ez valószínűleg annak köszönhető, hogy ezeket a definíciókat hogyan értelmezik a helyi és SQL szerver DBMS-ekben.

A helyi DBMS-ekben a fő tábla az, amely a fő adatokat tartalmazza, az alárendelt tábla pedig további adatokat. Vegyünk például három kapcsolódó táblázatot. Az első az eladásokról, a második a termékekről, a harmadik pedig a vásárlókról tartalmaz adatokat:

Rizs. 18.1.

Itt a fő információ az értékesítési táblában tárolódik, így ez a fő (szülő) tábla. A termék- és vásárlói táblázatokban további információkat tárolnak, ami azt jelenti, hogy gyerekekről van szó. Ez érthető: egy lánynak nem lehet két biológiai anyja, de egy anya képes két lányt világra hozni.

De az SQL adatbázis-kiszolgálókban a kapcsolatok definíciója más: amikor egy tábla egyik mezője egy másik tábla mezőjére hivatkozik, akkor az ún. idegen kulcs. És azt a mezőt, amelyre hivatkozik, úgy hívják szülő ill elsődleges kulcs. Az idegen kulccsal rendelkező táblát (hivatkozás egy másik táblában lévő rekordra) gyakran gyermeknek nevezik, a táblát pedig szülőkulcs- szülői. A kapcsolatok meghatározásakor is azt mondják, hogy egy szülőnek csak egy egyedi rekordja lehet, amelyre több rekord is hivatkozhat gyermek asztal.

Tehát a fenti példában az értékesítési táblának két idegen kulcsa van: a termékazonosító és a vevőazonosító. És az ábra jobb oldalán lévő mindkét táblázat rendelkezik szülőkulcs"Azonosító". Mivel ugyanaz a vásárló vagy termék többször is megjelenhet az értékesítési táblázatban, kiderül, hogy az ábra jobb oldalán mindkét táblázat szülő, a bal oldali pedig gyermek. Mert most tanulunk InterBase - SQL adatbázis szerver, ezektől a definícióktól fogunk eligazodni a következő előadásokban. Hogy ne törjük tovább az agyunkat ezen a zűrzavaron, azonnal egyezzünk meg: gyermek asztal idegen kulcsa van (IDEGEN KULCS) egy másik táblához.

ELSŐDLEGES KULCS

ELSŐDLEGES KULCS- Az elsődleges kulcs a korlátozások egyik fő típusa az adatbázisban. Az elsődleges kulcsot úgy tervezték, hogy egyedileg azonosítsa a rekordot a táblában, és egyedinek kell lennie. Elsődleges kulcsok A PRIMARY KEY táblákban található, amelyeket általában szülőnek (szülőnek) neveznek. Az elsődleges kulcsot nem szabad összetéveszteni a helyi adatbázisok elsődleges indexeivel, az elsődleges kulcs nem index, hanem megszorítás. Az elsődleges kulcs létrehozásakor InterBase automatikusan létrehoz neki egyedi index. Ha azonban megteremtjük egyedi index, ez nem jön létre elsődleges kulcs megszorításai. Egy táblának csak egy elsődleges kulcsa lehet, PRIMARY KEY.

Tegyük fel, hogy van egy táblázat az alkalmazottak listájával. A Vezetéknév mező ismétlődő értékeket (névrokonokat) tartalmazhat, ezért nem használható elsődleges kulcsként. Ritka, de vannak névrokonok, akiknek ráadásul ugyanaz a neve. Még ritkábban vannak teljes névrokonok, így még mindhárom mező „Vezetéknév” + „Keresztnév” + „Patronymic” nem garantálja a rekord egyediségét, és nem lehet elsődleges kulcs. Ebben az esetben a megoldás, mint korábban, egy azonosító mező hozzáadása, amely ennek a személynek a sorozatszámát tartalmazza. Az ilyen mezőket általában automatikus növekedésűvé teszik (a következő előadásokban az automatikus növekedésű mezők megszervezéséről lesz szó). Így,

Elsődleges kulcs egy vagy több mező egy táblázatban, amelyek kombinációja minden rekord esetében egyedi.

Ha az elsődleges kulcs egyetlen oszlopot tartalmaz (mint ez a leggyakrabban előfordul), akkor az ELSŐDLEGES KULCS megadót használjuk, amikor oszlop meghatározása:

TÁBLÁZAT LÉTREHOZÁSA Prim_1(Stolbec1 INT NOT NULL ELSŐDLEGES KULCS, Stolbec2 VARCHAR(50))

Ha az elsődleges kulcs több oszlopra épül, akkor a specifikátor az összes mező meghatározása után kerül elhelyezésre:

TÁBLÁZAT LÉTREHOZÁSA Prim_2(Stolbec1 INT NEM NULL, Stolbec2 VARCHAR(50) NOT NULL, ELSŐDLEGES KULCS (Stolbec1, Stolbec2))

Amint a példákból látható, az elsődleges kulcs rendelkeznie kell egy NOT NULL oszlop(ok) megszorítással.

EGYEDI

EGYEDI- egyedi kulcs. Az EGYEDI megadó azt jelzi, hogy a mező minden értékének egyedinek kell lennie, ezért az ilyen mezők sem tartalmazhatnak értékeket NULLA. Mondhatnánk, hogy az EGYEDI kulcs az elsődleges kulcs alternatívája, de vannak különbségek. A fő különbség az, hogy csak egy elsődleges kulcsnak kell lennie, míg több egyedi kulcs is lehet. Ezenkívül egy EGYEDI kényszer nem építhető fel ugyanarra az oszlopkészletre, amelyet az ELSŐDLEGES KULCS vagy más EGYEDI kényszerhez használtak. Az egyedi kulcsok, az elsődleges kulcsokhoz hasonlóan, olyan táblákban találhatók, amelyek más táblák szülői.

Egy EGYEDI megszorítással deklarált oszlop, mint az elsődleges kulcs, felhasználható a hivatkozási integritás érvényesítésére a szülő és a között. gyermek asztalok. Ebben az esetben az idegen kulcs gyermek asztal erre a mező(k)re fog hivatkozni. Az elsődleges kulcshoz hasonlóan egyedi kulcs létrehozásakor a egyedi index. De fordítva nem. Példa egy tábla létrehozására egy elsődleges és két egyedi kulccsal:

TÁBLÁZAT LÉTREHOZÁSA Prim_3(Stolbec1 INT NEM NULL ELSŐDLEGES KULCS, Stolbec2 VARCHAR(50) NEM NULL EGYEDI, Stolbec3 FLOAT NEM NULL EGYEDI)

IDEGEN KULCS

IDEGEN KULCS- külső kulcs. Ez egy nagyon hatékony eszköz a táblák közötti hivatkozási integritás biztosítására, amely lehetővé teszi nemcsak a megfelelő hivatkozások jelenlétének figyelését, hanem automatikus kezelését is. Az idegen kulcsokat olyan táblák tartalmazzák, amelyek más táblák gyermekei (Child). Referencia integritás pontosan egy idegen kulcs biztosítja, amely az elsődleges ill

És így csendben közeledtünk egy nagyon fontos témához - az elsődleges és az idegen kulcsokhoz. Míg az előbbit szinte mindenki használja, az utóbbiakat valahogy figyelmen kívül hagyják. De hiába. Az idegen kulcsok nem jelentenek problémát, valódi segítséget jelentenek az adatintegritásban.

1.2.5. Elsődleges kulcs

Sokat beszéltünk már a kulcsfontosságú területekről, de soha nem használtuk őket. A legérdekesebb az, hogy minden működött. Ez a Microsoft SQL Server és az MS Access adatbázisok előnye, esetleg hátránya. Ez a trükk nem működik a Paradox táblákban, és kulcsmező nélkül a táblázat csak olvasható lesz.

A kulcsok bizonyos mértékig megszorítások, és a CHECK utasítással együtt is figyelembe vehetők, mivel a deklaráció hasonló módon történik, és még a CONSTRAINT utasítást is használja. Nézzük meg ezt a folyamatot egy példán keresztül. Ehhez létrehozunk egy táblázatot két mezőből: „guid” és „vcName”. Ez a "guid" mezőt állítja be elsődleges kulcsként:

TÁBLÁZAT LÉTREHOZÁSA Globally_Unique_Data (guid egyedi azonosító DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid ELSŐDLEGES KULCS (Útmutató))

A legjobb rész itt a CONSTRAINT vonal. Mint tudjuk, a kulcsszó után a megszorítás neve következik, és ez alól a kulcsdeklaráció sem kivétel. Az elsődleges kulcs elnevezéséhez javasoljuk, hogy használjon olyan nevet, mint például a PK_name, ahol a név annak a mezőnek a neve, amelyből elsődleges kulcs lesz. A PK rövidítés az elsődleges kulcsból származik.

Ezt követően a megszorításoknál használt CHECK kulcsszó helyett egy PRIMARY KEY operátor található. Ez jelzi, hogy nem ellenőrzésre, hanem elsődleges kulcsra van szükségünk. A kulcsot alkotó egy vagy több mező zárójelben van feltüntetve.

Ne feledje, hogy nincs két sor azonos értékű kulcsmezőben, amelyben az elsődleges kulcs megszorítása megegyezik egy egyedi megszorítással. Ez azt jelenti, hogy ha a vezetéknév tárolására szolgáló mezőt elsődleges kulcsnak állítja be, akkor egy ilyen táblázatba nem lehet két különböző nevű Ivanovot írni. Ez sérti az elsődleges kulcsra vonatkozó megkötést. Ez az oka annak, hogy a kulcsok kényszerek, és ugyanúgy deklarálódnak, mint a CHECK kényszer. De ez nem csak az elsődleges kulcsokra és az egyediséget biztosító másodlagos kulcsokra igaz.

Ebben a példában az elsődleges kulcs egy egyedi azonosító (GUID) típusú mező. A mező alapértelmezett értéke a NEWID szerver eljárás eredménye.

Figyelem

Egy táblához csak egy elsődleges kulcs hozható létre

A példák egyszerűsítése érdekében kulcsként célszerű numerikus típust használni, és ha az adatbázis megengedi, jobb lesz, ha „autoincrement” típusú (automatikusan növekvő/csökkentő szám). Az MS SQL Serverben ez a mező az IDENTITY, az MS Accessben pedig egy „számláló” típusú mező.

A következő példa bemutatja, hogyan hozhat létre terméktáblázatot elsődleges kulcsként automatikusan növekvő egész mezővel:

TÁBLÁZAT LÉTREHOZÁSA Termékek (azonosító int IDENTITY(1, 1), termék varchar(50), ár pénz, mennyiség numerikus (10, 2), CONSTRAINT PK_id PRIMARY KEY (id))

Ezt a kulcstípust fogjuk leggyakrabban használni, mert a kulcsmező olyan számokat tárol, amelyek könnyen érthetőek, és könnyebben és vizuálisabban kezelhetők.

Az elsődleges kulcs egynél több oszlopból állhat. A következő példa egy táblázatot hoz létre, amelyben az "id" és a "Product" mezők alkotják az elsődleges kulcsot, ami azt jelenti, hogy mindkét mezőben egyedi index jön létre:

TÁBLÁZAT LÉTREHOZÁSA Termékek1 (azonosító int IDENTITY(1, 1), termék varchar(50), ár pénz, mennyiség numerikus (10, 2), CONSTRAINT PK_id PRIMARY KEY (azonosító, [termék neve]))

A programozók nagyon gyakran hoznak létre egy adatbázist egy kulcsmezővel egész szám formájában, ugyanakkor a feladat egyértelműen kimondja, hogy bizonyos mezőknek egyedinek kell lenniük. Miért nem hoz létre azonnal elsődleges kulcsot azokból a mezőkből, amelyeknek egyedinek kell lenniük, és nem kell külön megoldásokat készíteni erre a problémára.

A többoszlopos elsődleges kulcs egyetlen hátránya a kapcsolatok létrehozásának problémája. Itt különféle módszerekkel kell kilépni belőle, de a probléma még megoldható. Csak be kell írnia egy egyedi azonosító típusú mezőt, és létre kell hoznia a kapcsolatot ezzel. Igen, ebben az esetben kapunk egy egyedi elsődleges kulcsot és egy egyedi azonosító típusú mezőt, de ennek eredményeként ez a redundancia nem lesz nagyobb, mint ugyanaz a tábla, ahol az elsődleges kulcs az egyedi azonosító, és egyediségi megszorítás van beállítva a kötelező mezőkre. egyedinek kell lennie. Mit válasszunk? Ez az adott feladattól és attól függ, hogy mivel kényelmesebben dolgozik.

1.2.6. Külső kulcs

Az idegen kulcs egyben CONSTRAINT kényszer is, és két tábla közötti kapcsolatot reprezentálja. Tegyük fel, hogy két táblázata van:

• Nevek – az emberek nevét tartalmazza, és azonosító mezőkből (kulcsmező), névből áll.
• A Phones egy telefontábla, amely egy azonosítóból (kulcsmezőből), egy idegen kulcsból áll a névtáblázathoz való csatlakozáshoz, valamint egy karakterlánc mezőből a telefonszám tárolására.

Egy embernek több telefonja is lehet, ezért az adattárolást különböző táblázatokra osztottuk. Az 1.4. ábra szemlélteti két tábla kapcsolatát. Ha már dolgozott linkelt táblákkal, akkor ez elég lesz Önnek. Ha először hall a kapcsolatokról, akkor próbáljuk meg közelebbről megvizsgálni a problémát.

Például vegyünk egy háromfős asztalt. Az 1.3. táblázat a "Nevek" tábla tartalmát mutatja. Csak három sor van, és mindegyiknek megvan a maga egyedi főkulcsa. Az egyediség kedvéért a táblázat létrehozásakor a kulcsot automatikusan növekvő mezővé tesszük.

1.3. táblázat A nevek táblázat tartalma

1.4. táblázat. A Telefonok táblázat tartalma

Az 1.4. táblázat öt telefonszámot tartalmaz. A főkulcs mező egy egyedi mesterkulcsot is tartalmaz, amely szintén automatikusan növelhető. A másodlagos kulcs egy kapcsolat a nevek tábla elsődleges kulcsával. Hogyan működik ez a kapcsolat? Petrovnak az 1-es az elsődleges kulcsa a nevek táblában. A Telefonok táblában a másodlagos kulcsban keressük az 1-es számot, és megkapjuk Petrov telefonszámait. Ugyanez vonatkozik a többi bejegyzésre is. A kapcsolat vizuálisan az 1.5. ábrán látható.

Ez a fajta adattárolás nagyon kényelmes. Ha nem lehetne kapcsolódó táblákat létrehozni, akkor a Nevek táblában minden telefonszámot egy mezőbe kellene beírnunk. Ez kényelmetlen a használat, a karbantartás és az adatok visszakeresése szempontjából.

Egy táblázatban több Név mezőt is létrehozhat, de felmerül a kérdés, hogy hányat. Egy embernek csak 1 telefonja lehet, de nekem például 3 van, a munkahelyieket nem számítva. A mezők nagy száma adatredundanciához vezet.

A nevek táblában minden telefonhoz külön sort hozhatunk létre vezetéknévvel, de ez csak egy ilyen egyszerű példánál egyszerű, amikor csak a vezetéknevet kell megadni, és több telefonnal is könnyedén több bejegyzést is megadhatunk Petrovnak. számok. Mi van, ha 10 vagy 20 mező van? Tehát két idegen kulccsal összekapcsolt tábla létrehozása látható az 1.6-os listában.

Felsorolás 1.6. Idegen kulccsal összekapcsolt táblák létrehozása

CREATE TABLE Nevek (idName int IDENTITY(1,1), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName),) CREATE TABLE Telefonok (idPhone int IDENTITY(1,1), idName int, vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone), CONSTRAINT FK_idName FOREIGN KEY (idName) HIVATKOZÁSOK Nevek (idName))

Kérjük, figyelmesen olvassa el a lista tartalmát. Ez elég érdekes, mert néhány olyan operátort használ, amelyeket már tárgyaltunk, és egy további példa hasznos lenne. Mindkét táblához létrejön egy kulcsmező, amely az első helyen áll, int típusú és automatikusan növekszik, 1-től kezdve, eggyel lépésekben. A kulcsmező egy CONSTRAINT megszorítással főkulccsá válik.

A Telefonok tábla leírásában az utolsó sor egy számunkra új deklarációt tartalmaz, mégpedig egy idegen kulcs deklarálását az IDEGEN KULCS operátor segítségével. Amint látja, ez is egy korlátozás, és egy kicsit később látni fogja, miért. Zárójelben van feltüntetve az a táblázatmező, amelyet egy másik táblához kell kapcsolni. Ezt követően jön a REFERENCES (link) kulcsszó, a tábla neve, amellyel a kapcsolatot kell létrehozni (Names) és zárójelben a mező neve ("idName"). Így létrejött egy kapcsolat, amelyet az 1.4. ábra mutat be.

Figyelem!

Az idegen kulcs csak egy másik tábla elsődleges kulcsára vagy egyedi megszorítására hivatkozhat. Ez azt jelenti, hogy a REFERENCES kulcsszó után táblanévnek kell lennie, és csak egy elsődleges kulcs vagy egy EGYEDI kényszerű mező adható meg zárójelben. Más mezők nem adhatók meg.

Most, ha meg tudja tölteni adatokkal a táblákat. A következő három csapat hozzáadja az 1.3. táblázatban látható három nevet:

INSERT INTO Nevek(vcName) VALUES("Petrov") INSERT INTO Nevek(vcName) VALUES("Ivanov") INSERT INTO Nevek(vcName) VALUES("Sidorov")

Ha már dolgozott SQL-lel, akkor bejegyzéseket adhat hozzá a telefontáblázathoz. Ezeket a parancsokat kihagyom, de a CD-n a Chapter1 könyvtárában az Foreign_keys.sql fájlban láthatod.

Most az a feladatunk, hogy megnézzük, mik az idegen kulcs korlátozó műveletei, találjuk ki. Explicit kapcsolatot adtunk meg két mező között különböző táblákban. Ha olyan rekordot próbál felvenni a telefontáblázatba az "idName" mezőben olyan azonosítóval, amely nem létezik a vezetékneveket tartalmazó táblázat azonos nevű mezőjében (a név másra változtatható), hiba történik. . Ez megszakítja a kapcsolatot a két tábla között, és az idegen kulcs megszorítása nem teszi lehetővé a kapcsolat nélküli rekordok létezését.

A korlátozás a rekordok módosítására vagy törlésére is vonatkozik. Például, ha megpróbál törölni egy Petrov vezetéknevű sort, idegen kulcs kényszerhiba lép fel. Nem törölhet olyan rekordokat, amelyek külsőleg kapcsolódó sorokkal rendelkeznek. Először is törölnie kell az összes telefonszámot ehhez a bejegyzéshez, és csak ezután lesz lehetőség a Petrov vezetéknévvel rendelkező sor törlésére.

Idegenkulcs létrehozásakor megadhatja a CASCADE TÖRLÉSÉRE vagy a CASCADE UPDATE CASCADE-re. Ebben az esetben, ha törli Petrov rekordját a Nevek táblából, vagy megváltoztatja az azonosítót, akkor a Telefonok tábla Petrov sorához tartozó összes rekordja automatikusan frissül. Soha. Nem, nagybetűvel kell írni: SOHA ne tedd ezt. Mindent kézzel kell törölni vagy módosítani. Ha a felhasználó véletlenül töröl egy bejegyzést a nevek táblából, akkor a megfelelő telefonok is törlődnek. Nincs értelme idegen kulcsot létrehozni, ha a korlátozások fele eltűnik! Mindent manuálisan kell elvégezni, és soha nem javasolt az azonosítók megváltoztatása.

Maguk a táblák törlését is az alárendelt táblával kell kezdeni, vagyis a Telefonszámmal, és csak ezután törölheti a fő nevek táblát.

Végül megmutatom, hogyan lehet két táblázatból gyönyörűen egyeztetni a neveket és a telefonszámokat:

SELECT vcName, vcPhone FROM nevek, telefonok WHERE Names.idName=Phones.idName

Az ilyen lekérdezésekről részletesebben a 2. fejezetben fogunk beszélni. Egyelőre egy példát hoztam fel, hogy lásd a csatolt táblák erejét.

Egy tábla legfeljebb 253 idegen kulcsot tartalmazhat, ami még a legösszetettebb adatbázisokhoz is elegendő. Személy szerint olyan adatbázisokkal kellett dolgoznom, ahol az idegen kulcsok száma táblánként nem haladta meg a 7-et. Ha több, akkor valószínűleg az adatbázis rosszul van megtervezve, bár vannak kivételek.

Maga a tábla is maximum 253 idegen kulcsot tartalmazhat. A táblákban lévő idegen kulcsok kevésbé gyakoriak, általában legfeljebb 3. Leggyakrabban egy táblának sok hivatkozása lehet más táblákra.

Az idegen kulcs ugyanarra a táblára hivatkozhat, amelyben létrehozták. Például van egy táblázat a munkaköri címekről egy szervezetben, ahogy az 1.5. táblázatban látható. A táblázat három mezőből áll: elsődleges kulcs, idegen kulcs és munkakör. Bármely szervezetnek több beosztása lehet, de logikus lenne egy táblázatban feltüntetni a nevüket és az alárendeltségüket. Ehhez az idegen kulcsot hozzá kell rendelni a pozíciótábla elsődleges kulcsához.

1.5. táblázat. Táblázat belső hivatkozással

Ennek eredményeként azt kapjuk, hogy a főigazgatónak nulla idegen kulcsa van, i.e. ez a pozíció az összes többi élén áll. A kereskedelmi igazgatónál és a főigazgatónál az idegen kulcs a főigazgatói sorra mutat. Ez azt jelenti, hogy ez a két pozíció közvetlenül a vezérigazgató alá tartozik. Stb.

Nézzük meg, hogyan hozhatjuk létre mindezt SQL lekérdezésként:

TÁBLÁZAT LÉTREHOZÁSA Pozíciók (idPosition int IDENTITY(1,1), idParentPosition int, vcName varchar(30), CONSTRAINT PK_idPosition PRIMARY KEY (idPosition), CONSTRAINT FK_idParentPosition FOREIGN KEY (idParentPosition) REFERENCESPosition)

Mint látható, az idegen kulcs egyszerűen ugyanarra a táblára hivatkozik, amelyet létrehozunk. A CD-n a Chapter1 könyvtárban az idegen_kulcsok_self.sql fájlban láthatunk példát ennek a táblának az elkészítésére, adatokkal való kitöltésére és a pozíciók alárendeltségük figyelembevételével történő megjelenítésére. A következő fejezetben részletesebben megvizsgáljuk az ilyen táblázatokkal való munka lehetőségét.

Egy-egy kapcsolat

Eddig azt a klasszikus összefüggést néztük, amikor a fő adattábla egy sora megfelel a kapcsolódó tábla egy sorának. Ezt a kapcsolatot egy-a-többhöz hívják. De vannak más kapcsolatok is, és most egy másikat fogunk megvizsgálni – egytől egyig, amikor a főtábla egyik rekordja a másik rekordjához kapcsolódik. Ennek megvalósításához elegendő mindkét tábla elsődleges kulcsát összekapcsolni. Mivel az elsődleges kulcsok nem ismételhetők, mindkét táblában csak egy sor kapcsolható össze.

A következő példa két olyan táblát hoz létre, amelyek elsődleges kulcskapcsolattal rendelkeznek:

TÁBLÁZAT Nevek LÉTREHOZÁSA (idName egyedi azonosító DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid ELSŐDLEGES KULCS (idName)) TÁBLÁZAT LÉTREHOZÁSA Telefonok (idPhone egyedi azonosító DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINTIDP (PRIMARYIDPhone) CONSTRAINT FK_idPhone IDEGEN KULCS (idPhone) HIVATKOZÁS Nevek (idName))

Csak az egyik táblához kell idegen kulcs. Mivel a kapcsolat egy az egyhez, nem mindegy, hogy melyik táblában kell létrehozni.

sok a sok

A legösszetettebb kapcsolat a sok a sokhoz, ahol egy tábla sok rekordja megegyezik egy másik tábla sok rekordjával. Ennek megvalósításához nem elegendő két tábla.

Először is meg kell értenünk, mikor használható a sok-sok kapcsolat? Tegyük fel, hogy van két táblázata: a ház lakóinak listája és a telefonszámok listája. Egy lakáshoz több telefonszám is tartozhat, ami azt jelenti, hogy egy vezetéknévhez két telefonszám tartozhat. Kiderült, hogy egy-a többhez kapcsolat van. Másrészt egy lakásban (közösségi lakásban vagy csak bérlőben) lehet két család, aki a tulajdonos telefonját használja, ami azt jelenti, hogy a telefon és a lakó közötti kapcsolat is egy a sokhoz. A legnehezebb megoldás pedig az, hogy egy kommunális lakásban van két telefon. Ebben az esetben mindkét számot a lakás több lakója használja. Így kiderül, hogy „sok” család használhat „sok” telefont (sok-sok kommunikáció).

Hogyan valósítsunk meg egy sok-sok kapcsolatot? Első pillantásra ez lehetetlen a relációs modellben. Körülbelül 10 évvel ezelőtt hosszú időt töltöttem a különféle lehetőségek keresésével, és ennek eredményeként egyszerűen létrehoztam egy táblázatot, amely tele volt redundáns adatokkal. De egy nap kaptam egy feladatot, aminek köszönhetően a feltételekből kitűnő megoldás született - két táblát kellett létrehoznom a lakások lakóiról és telefonszámairól, és csak egy elsődleges kulcsot kellett beépíteni bennük. Ebben a táblázatban nincs szükség idegen kulcsokra. De az asztalok közötti kapcsolatnak egy harmadik, összekötő asztalon keresztül kell lennie. Első pillantásra ez nehéz és nem egyértelmű, de ha megérti ezt a módszert, látni fogja a megoldás teljes erejét.

Az 1.6. és 1.7. táblázat példákat mutat be a vezetéknevekre és a telefonszámokra. Az 1.8. táblázat pedig a csatolási táblázatot mutatja.

1.6. táblázat. Vezetéknév táblázat

1.7. táblázat. Telefon asztal

1.8. táblázat. Telefon asztal

Lássuk most, milyen lesz az adatkeresési logika a sok-sok kapcsolatban. Tegyük fel, hogy meg kell találnunk az összes Ivanovhoz tartozó telefont. Ivanov elsődleges kulcsa egyenlő 1-gyel. A hivatkozási táblázatban megtaláljuk az összes olyan rekordot, amelynél a „Kapcsolat a névvel” mező 1-gyel egyenlő. Ezek az 1-es és a 2-es rekordok lesznek. Ezekben a rekordokban a „Kapcsolat a telefonnal” mezőben ott van 1-es és 2-es azonosítók, és Ez azt jelenti, hogy Ivanov birtokolja a telefontáblázatban szereplő számokat, amelyek az 1. és 2. sorban találhatók.

Most oldjuk meg az inverz problémát – határozzuk meg, hogy ki férhet hozzá az 567575677 telefonszámhoz. A telefonszámtáblázatban ez a szám a 3-as kulcsot tartalmazza. Minden olyan rekordot keresünk a csatolási táblázatban, ahol a „Telefon kapcsolat” mezőben ez egyenlő 3. Ezek 4-es és 5-ös számú rekordok, amelyek a "Névhivatkozás" mezőben 2-es, illetve 3-as értéket tartalmaznak. Ha most megnézi a vezetéknevek táblázatát, a 2. és 3. számban Petrov és Sidorov látható. Ez azt jelenti, hogy ez a két lakó az 567575677-es telefonszámot használja.

Tekintse át mindhárom táblázatot, és győződjön meg arról, hogy megértette, melyik telefonszám melyik lakoshoz tartozik, és fordítva. Ha látja ezt az összefüggést, megérti, hogy ez olyan egyszerű, mint három fillér, és gyorsan megvalósíthatja a projektjeiben.

TÁBLÁZAT Nevek LÉTREHOZÁSA (IDName egyedi azonosító DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid ELSŐDLEGES KULCS (idName)) TÁBLÁZAT LÉTREHOZÁSA Telefonok (idPhone egyedi azonosító DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINThonidP (PRIMARYidPhonePK) CREATE TABLE LinkTable (idLinkTable egyedi azonosító DEFAULT NEWID(), idName egyedi azonosító, idPhone egyedi azonosító, CONSTRAINT PK_idLinkTable PRIMARY KEY (idLinkTable), CONSTRAINT FK_idPhone FOREIGN KEY (IDLinkTable) CONSTRAINT N KULCS (idName REF) ERENCES Nevek (idName ) )

Az összekapcsoló táblának két idegen kulcsa van, amelyek a nevekre és telefonszámtáblákra hivatkoznak, valamint egy elsődleges kulcs, amely biztosítja a rekordok egyediségét.

A GUID mezőt választottam elsődleges kulcsnak, mert így kényelmesebb megoldani ezt a problémát. A helyzet az, hogy rekordokat kell beszúrnunk két táblába, és mindkét esetben ugyanazt a kulcsot kell megadnunk. A GUID érték előállítható, majd felhasználható, amikor adatokat szúr be mindkét táblába.

Kulcsként használhatunk automatikusan növekvő mezőt is, de ebben az esetben a probléma egy kicsit nehezebben, vagy inkább kényelmetlen a megoldása. Például telefonszám hozzáadásakor először be kell szúrni a megfelelő sort a táblázatba, majd meg kell keresni, meg kell határozni a sorhoz rendelt kulcsot, majd létre kell hozni a kapcsolatot.

Ebben a szakaszban csak a táblázatok létrehozására szorítkozunk, de a 2.8-as részben visszatérünk ehhez a témához, és megtanuljuk, hogyan kell dolgozni a kapcsolódó táblázatokkal. Az egy az egyhez és az egy a többhez kapcsolattal végzett munka nem nagyon különbözik, mert ebben a sémában csak két tábla vesz részt. A sok-sok kapcsolatok egy kicsit bonyolultabbak a hivatkozási tábla miatt, ezért ezzel külön foglalkozunk a 2.27. szakaszban.