Tiek izsaukta relācija, kas satur ārējo atslēgu. Primārās un ārējās atslēgas ierobežojumi. Att.3.4. Normalizēts attiecību kopums

Pēdējā atjaunināšana: 07/02/2017

Datu bāzēs var būt tabulas, kas ir savstarpēji saistītas ar dažādām saitēm. Attiecības atspoguļo dažādu veidu entītiju saistību.

Atlasot relāciju, tiek atlasīta primārā vai vecāktabula (primārās atslēgas tabula/galvenā tabula) un atkarīgā pakārtotā tabula (svešās atslēgas tabula/bērntabula). Bērnu tabula ir atkarīga no vecāku tabulas.

Saziņas organizēšanai tiek izmantotas svešās atslēgas. Ārējā atslēga apzīmē vienu vai vairākas kolonnas no vienas tabulas, kas ir arī iespējamā atslēga no citas tabulas. Ārējai atslēgai nav jāatbilst primārajai atslēgai no galvenās tabulas. Lai gan, kā likums, ārējā atslēga no atkarīgās tabulas norāda uz primāro atslēgu no galvenās tabulas.

Attiecības starp tabulām ir šāda veida:

Viens pret vienu

Viens pret daudziem

daudzi pret daudziem(daudziem daudziem)

Komunikācija viens pret vienu

Šāda veida savienojums netiek atrasts bieži. Šajā gadījumā vienas entītijas objektu var saistīt tikai ar vienu citas entītijas objektu. Piemēram, dažās vietnēs lietotājam var būt tikai viens emuārs. Tas ir, rodas attiecības: viens lietotājs - viens emuārs.

Bieži vien šāda veida attiecības ir saistītas ar viena liela galda sadalīšanu vairākos mazos. Šajā gadījumā primārajā vecāktabulā joprojām ir bieži pieejami dati, savukārt pakārtotajā tabulā parasti tiek glabāti dati, kuriem tiek piekļūts retāk.

Šajā sakarā atkarīgās tabulas primārā atslēga vienlaikus ir arī ārējā atslēga, kas atsaucas uz galvenās tabulas primāro atslēgu.

Piemēram, tabulā Lietotāji ir attēloti lietotāji, un tajā ir šādas kolonnas:

UserID(id, primārā atslēga)

Vārds (lietotājvārds)

Tabulā Emuāri ir lietotāju emuāri, un tajā ir šādas kolonnas:

BlogId (identifikators, primārā un ārējā atslēga)

Vārds (emuāra nosaukums)

Šādā gadījumā slejā BlogId tiks saglabāta lietotāju tabulas UserId kolonnas vērtība. Tas nozīmē, ka BlogId kolonna darbosies gan kā primārā, gan kā ārējā atslēga.

Attiecības viens pret daudziem

Šis ir visizplatītākais savienojuma veids. Šāda veida attiecībās vairākas rindas no pakārtotās tabulas ir atkarīgas no vienas rindas vecāktabulā. Piemēram, vienā emuārā var būt vairāki raksti. Šajā gadījumā emuāru tabula ir vecākais, bet rakstu tabula ir bērns. Tas ir, viens emuārs - daudzi raksti. Vai vēl viens piemērs, futbola komandā var spēlēt vairāki futbolisti. Un tajā pašā laikā viens futbolists vienlaikus var spēlēt tikai vienā komandā. Tas ir, viena komanda - daudzi spēlētāji.

Piemēram, izveidosim tabulu ar nosaukumu Raksti, kas attēlo emuāru rakstus un kurā ir šādas kolonnas:

Raksta ID(id, primārā atslēga)

BlogId (svešā atslēga)

Nosaukums (raksta nosaukums)

Teksts (raksta teksts)

Šajā gadījumā rakstu tabulas kolonnā BlogId tiks saglabāta vērtība no emuāru tabulas kolonnas BlogId.

attiecības daudz pret daudziem

Izmantojot šāda veida attiecības, vienu rindu no tabulas A var saistīt ar daudzām rindām no tabulas B. Savukārt vienu rindu no tabulas B var saistīt ar daudzām rindām no tabulas A. Tipisks piemērs ir studenti un kursi: viens students var apgūt vairākus kursus, un attiecīgi vienā kursā var iestāties vairāki studenti.

Vēl viens piemērs ir raksti un tagi: vienam rakstam var definēt vairākus tagus, un vairākiem rakstiem var definēt vienu tagu.

Taču SQL Server datu bāzes līmenī mēs nevaram izveidot tiešu daudzu pret daudziem attiecību starp divām tabulām. Tas tiek darīts, izmantojot papildinstalācijas tabulu. Dažreiz dati no šīs stadijas tabulas ir atsevišķa vienība.

Piemēram, rakstu un tagu gadījumā lai ir tabula Tags, kurā ir divas kolonnas:

TagId(identifikators, primārā atslēga)

Teksts (taga teksts)

Lai būtu arī starptabula ArticleTags ar šādiem laukiem:

TagId (identifikators, primārā un ārējā atslēga)

ArticleIdId (identifikators, primārā un ārējā atslēga)

Tehniski mēs iegūsim divas attiecības viens pret daudziem. Kolonnā TagId no tabulas ArticleTags būs atsauce uz sleju TagId no tabulas Tags. Un tabulas ArticleId kolonna ArticleId attiecas uz sleju ArticleId no tabulas Articles. Tas nozīmē, ka tabulas ArticleTags kolonnas TagId un ArticleId attēlo saliktu primāro atslēgu un ir arī ārējās atslēgas attiecībām ar tabulām Articles un Tags.

Atsauces datu integritāte

Mainot primārās un ārējās atslēgas, jāievēro šāds aspekts: atsauces datu integritāte(atsauces integritāte). Tās pamatideja ir izveidot divas tabulas datu bāzē, kurās tiek glabāti tie paši dati, lai saglabātu konsekvenci. Datu integritāte atspoguļo pareizi izveidotas attiecības starp tabulām ar pareizām saitēm starp tām. Kādos gadījumos var tikt pārkāpta datu integritāte:

Dzēšanas anomālija(dzēšanas anomālija). Rodas, kad no galvenās tabulas tiek izdzēsta rinda. Šajā gadījumā ārējā atslēga no atkarīgās tabulas turpina atsaukties uz izdzēsto rindu no galvenās tabulas

Ievietošanas anomālija(ievietošanas anomālija). Rodas, ja rinda tiek ievietota atkarīgajā tabulā. Šajā gadījumā ārējā atslēga no atkarīgās tabulas neatbilst nevienas no galvenās tabulas rindas primārajai atslēgai.

Atjaunināt anomālijas(atjaunināšanas anomālija). Ar šādu anomāliju vienas tabulas vairākās rindās var būt dati, kas pieder vienam objektam. Mainot datus vienā rindā, tie var būt pretrunā ar datiem citā rindā.

Dzēšanas anomālija

Lai atrisinātu dzēšanas anomāliju, ir jāiestata viens no diviem ārējās atslēgas ierobežojumiem:

Ja rindai no atkarīgās tabulas obligāti ir nepieciešama rinda no galvenās tabulas, ārējā atslēga tiek iestatīta kaskādes dzēšana. Tas nozīmē, ka, dzēšot rindu no galvenās tabulas, saistītā rinda tiek dzēsta no atkarīgās tabulas.

Ja rinda no atkarīgās tabulas neatļauj nekādas attiecības ar rindu no galvenās tabulas (tas ir, šādas attiecības nav obligātas), ārējā atslēga tiek iestatīta uz NULL, kad saistītā rinda tiek dzēsta no galvenās tabulas. Šajā gadījumā ārējās atslēgas kolonnai jābūt nullei.

Ievietošanas anomālija

Lai atrisinātu ievietošanas anomāliju, pievienojot datus atkarīgajai tabulai, kolonnai, kas apzīmē ārējo atslēgu, jābūt nullei. Tādējādi, ja pievienotajam objektam nav savienojuma ar galveno tabulu, ārējās atslēgas kolonnā būs NULL vērtība.

Atjaunināt anomālijas

Lai atrisinātu atjaunināšanas anomālijas problēmu, tiek izmantota normalizācija, kas tiks apspriesta vēlāk.

Pēdējā atjaunināšana: 27.04.2019

Ārējās atslēgas ļauj izveidot attiecības starp tabulām. Ārējā atslēga tiek iestatīta kolonnās no atkarīgas, pakārtotas tabulas un norāda uz vienu no galvenās tabulas kolonnām. Parasti ārējā atslēga norāda uz primāro atslēgu no saistītās galvenās tabulas.

Vispārējā sintakse ārējās atslēgas iestatīšanai tabulas līmenī ir šāda:

ĀRĒJĀ ATSLĒGA (kolonna1, kolonna 2, ... kolonnaN) ATSAUCES galvenā_tabula (galvenā_tabulas_sleja1, galvenā_tabulas_sleja2, ... galvenā_tabulas_slejaN)

Lai izveidotu ārējās atslēgas ierobežojumu, pēc FOREIGN KEY norādiet tabulas kolonnu, kas attēlos ārējo atslēgu. Un pēc atslēgvārda REFERENCES tiek norādīts saistītās tabulas nosaukums, un pēc tam iekavās tās saistītās kolonnas nosaukums, uz kuru tiks norādīta ārējā atslēga. Pēc izteiksmes REFERENCES ir izteiksmes ON DELETE un ON UPDATE, kas norāda darbību, attiecīgi dzēšot un atjauninot rindu no galvenās tabulas.

Piemēram, definēsim divas tabulas un saistīsim tās, izmantojot ārējo atslēgu:

CREATE TABLE Klienti (ID INT PRIMARY KEY AUTO_INCREMENT, Vecums INT, Vārds VARCHAR(20) NOT NULL, Uzvārds VARCHAR(20) NOT NULL, Tālrunis VARCHAR(20) NOT NULL UNIQUE); CREATE TABLE Pasūtījumi (ID INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) ATSAUCES Klienti (ID));

Šajā gadījumā tiek definētas tabulas Klienti un Pasūtījumi. Klienti ir galvenais un pārstāv klientu. Pasūtījumi ir atkarīgi un atspoguļo klienta veikto pasūtījumu. Tabula Pasūtījumi caur sleju CustomerId ir saistīta ar tabulu Klienti un tās sleju Id. Tas nozīmē, ka sleja CustomerId ir ārējā atslēga, kas norāda uz kolonnu Id no tabulas Klienti.

Varat izmantot operatoru CONSTRAINT, lai norādītu ārējās atslēgas ierobežojumu nosaukumu:

CREATE TABLE Pasūtījumi (ID INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT orders_custonmers_fk FOREIGN KEY (CustomerId) ATSAUCES Klienti (ID));

IESLĒGTS DZĒŠANA un ATJAUNINĀŠANA

Izmantojot ON DELETE un ON UPDATE priekšrakstus, jūs varat iestatīt darbības, kas tiek veiktas, kad no galvenās tabulas tiek attiecīgi dzēsta vai mainīta saistītā rinda. Kā darbību var izmantot šādas opcijas:

KASKĀDE: automātiski dzēš vai maina rindas no atkarīgas tabulas, kad tiek dzēstas vai mainītas saistītās galvenās tabulas rindas.

SET NULL: Dzēšot vai atjauninot saistītu rindu no galvenās tabulas, ārējās atslēgas kolonna tiek iestatīta uz NULL. (Šajā gadījumā ārējās atslēgas kolonnai ir jāatbalsta NULL iestatījums)

IEROBEŽOT: noraida galvenās tabulas rindu dzēšanu vai modifikāciju, ja atkarīgajā tabulā ir saistītas rindas.

NAV DARBĪBAS: tas pats, kas IEROBEŽOT.

IESTATĪT NOKLUSĒJUMU: Dzēšot saistītu rindu no galvenās tabulas, ārējās atslēgas kolonnai tiek iestatīta noklusējuma vērtība, kas norādīta, izmantojot atribūtu DEFAULT. Neskatoties uz to, ka šī opcija principā ir pieejama, InnoDB dzinējs neatbalsta šo izteiksmi.

Kaskādes dzēšana

Kaskādes dzēšana ļauj automātiski izdzēst visas saistītās rindas no atkarīgās tabulas, kad dzēšat rindu no galvenās tabulas. Lai to izdarītu, izmantojiet opciju CASCADE:

CREATE TABLE Pasūtījumi (ID INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) ATSAUCES Klienti (ID) ON DELETE CASCADE);

Izteiksme ON UPDATE CASCADE darbojas līdzīgi. Mainot primārās atslēgas vērtību, ar to saistītās ārējās atslēgas vērtība automātiski mainās. Tomēr, tā kā primārās atslēgas mainās ļoti reti un parasti nav ieteicams izmantot kolonnas ar mainīgām vērtībām kā primārās atslēgas, izteiksme ON UPDATE praksē tiek izmantota reti.

Iestatījums NULL

Iestatot svešajai atslēgai opciju SET NULL, ārējās atslēgas kolonnai ir jābūt NULL atļautai:

CREATE TABLE Pasūtījumi (ID INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) ATSAUCES Klienti (ID) ON DELETE SET NULL);

Attēlā parādīta tabula (5. pakāpes attiecība), kas satur informāciju par hipotētiskā uzņēmuma darbiniekiem. Tabulas rindas atbilst kortežām. Katra rinda faktiski ir viena reālās pasaules objekta (šajā gadījumā darbinieka) apraksts, kura īpašības ir ietvertas kolonnās. Relāciju attiecības atbilst entītiju kopām, un korteži atbilst entītijām. Tiek izsauktas tabulas kolonnas, kas attēlo relāciju attiecības atribūti.

Katrs atribūts ir definēts domēnā, tāpēc domēnu var uzskatīt par derīgu vērtību kopu konkrētam atribūtam. Vienā domēnā var definēt vairākus vienas un tās pašas attiecības atribūtus un pat dažādu attiecību atribūtus.

Tiek izsaukts atribūts, kura vērtība unikāli identificē korešus taustiņu (vai vienkārši taustiņu). Atslēga ir atribūts Personāla numurs, jo tā vērtība katram uzņēmuma darbiniekam ir unikāla. Ja korteži tiek identificēti, tikai savienojot vairāku atribūtu vērtības, tad tiek uzskatīts, ka relācijai ir salikta atslēga.

Primārā atslēga- relāciju datu modelī viena no potenciālajām attiecību atslēgām, kas atlasīta kā primārā atslēga (vai noklusējuma atslēga).

Relācija var saturēt vairākas atslēgas. Viena no atslēgām vienmēr tiek deklarēta primārs, tā vērtības nevar atjaunināt. Visas pārējās attiecību atslēgas tiek izsauktas iespējamās atslēgas.

No teorētiskā viedokļa visas potenciālās (iespējamās) attiecību atslēgas ir līdzvērtīgas, tas ir, tām ir vienādas unikalitātes un minimāluma īpašības. Tomēr primārā atslēga parasti tiek izvēlēta no potenciālajām atslēgām, kas ir visērtākā noteiktiem praktiskiem mērķiem, piemēram, izveidei ārējā atslēgas citos aspektos vai izveidot kopu indeksu. Tāpēc, kā likums, par primāro atslēgu tiek izvēlēta tā, kurai ir vismazākais izmērs (fiziskā krātuve) un/vai kurā ir vismazākais atribūtu skaits.

Ja primārā atslēga sastāv no viena atribūta, to sauc ar vienkāršu atslēgu.

Ja primārā atslēga sastāv no diviem vai vairākiem atribūtiem, to sauc saliktā atslēga. Tātad vārds, uzvārds, uzvārds, pases numurs, pases sērijas nevar būt primārās atslēgas atsevišķi, jo tās var būt vienādas diviem vai vairākiem cilvēkiem. Bet nav divu viena veida personas dokumentu ar vienādu sēriju un numuru. Tāpēc attiecībās, kas satur datus par cilvēkiem, primārā atslēga var būt atribūtu apakškopa, kas sastāv no personas dokumenta veida, tā sērijas un numura.

Atšķirībā no hierarhiskajiem un tīkla datu modeļiem, relāciju modelim nav grupas attiecību jēdziena. Lai atspoguļotu asociācijas starp dažādu attiecību kortežiem, tiek izmantota to atslēgu dublēšana.

Tiek izsaukti atribūti, kas ir citu attiecību atslēgu kopijas svešās atslēgas.

Piemēram, attiecības starp NODAĻA un DARBINIEKA attiecībām tiek izveidotas, kopējot primāro atslēgu "Nodaļas_numurs" no pirmajām attiecībām uz otrajām. Tādējādi, lai iegūtu konkrētās nodaļas darbinieku sarakstu, ir nepieciešams: 1) No tabulas NODAĻA iestatiet atribūta vērtību "Nodaļas_numurs" , kas atbilst šim “Department_Name”. 2) atlasiet visus ierakstus no tabulas DARBINIEKI, atribūta vērtību "Nodaļas_numurs" kas ir vienāds ar iepriekšējā solī iegūto. Lai noskaidrotu, kurā nodaļā darbinieks strādā, jāveic apgrieztā darbība: 1) Noteikt "Nodaļas_numurs" no DARBINIEKU tabulas. 2) Izmantojot iegūto vērtību, atrodam ierakstu tabulā NODAĻA.

18. Normalizācija relāciju datu bāzēs, normālās formas jēdziens datu bāzes projektēšanā.

Normāla forma - attiecības īpašība relāciju datu modelī, raksturojot to no redundances viedokļa, kas potenciāli var novest pie loģiski kļūdainiem datu izlases vai mainīšanas rezultātiem. Parastā forma ir definēta kā prasību kopums, kas relācijai ir jāatbilst.

Tiek saukts datu bāzes pārveidošanas process parastajā formā normalizēšana . Normalizācija ir paredzēta, lai datu bāzes struktūru izveidotu tādā formā, kas nodrošina minimālu dublēšanu, tas ir, normalizēšana nav paredzēta, lai samazinātu vai palielinātu darba produktivitāti vai samazinātu vai palielinātu datu bāzes apjomu. Normalizācijas galīgais mērķis ir samazināt datubāzē glabātās informācijas iespējamo nekonsekvenci.

Liekas likvidēšana parasti tiek veikta, sadalot attiecības tā, lai katrā attiecībā tiktu saglabāti tikai primārie fakti (tas ir, fakti, kas nav izsecināti no citiem saglabātajiem faktiem).

Funkcionālās atkarības.

Relāciju datu bāze satur gan strukturālu, gan semantisku informāciju. Datu bāzes struktūru nosaka tajā ietverto attiecību skaits un veids, kā arī relācijas viens pret daudziem, kas pastāv starp šo relāciju kortežiem. Semantiskā daļa apraksta funkcionālo atkarību kopumu, kas pastāv starp šo attiecību atribūtiem. Definēsim funkcionālo atkarību.

19. 1NF: pamata definīcijas un transformācijas noteikumi.

Lai apspriestu pirmo normālo formu, ir nepieciešamas divas definīcijas:

Vienkāršs atribūts - atribūts, kura vērtības ir atomāras (nedalāmas).

Sarežģīts atribūts - tiek iegūts, savienojot vairākus atomu atribūtus, kurus var definēt vienā vai dažādos domēnos (to sauc arī par vektoru vai datu apkopojumu).

Pirmās normālās formas definīcija:

relācija ir 1NF, ja visu tās atribūtu vērtības ir atomāras. . Pretējā gadījumā tā vispār nav tabula un šādi atribūti ir jāsadala.

Apskatīsim piemēru:

Uzņēmuma personāla daļas datu bāzē ir nepieciešams uzglabāt informāciju par darbiniekiem, ko var mēģināt uzrādīt saistībā ar

DARBINIEKS (EMPLOYEE_NUMBER, VĀRDS, DZIMŠANAS DATUMS, DARBA_VĒSTURE, BĒRNI).

Rūpīgi apsverot šīs attiecības, izriet, ka atribūti "darba vēsture" Un "bērni" ir sarežģīti, turklāt atribūts "darba vēsture" ietver vēl vienu sarežģītu atribūtu "algas_vēsture".
Šīs vienības izskatās šādi:

 DARBA_VĒSTURE (RECEPTION_DATE, NAME, SALARY_HISTORY),

 ALGAS_VĒSTURE (PIEMĒROŠANAS_DATUMS, ALGA),

 BĒRNI (CHILD_NAME, BIRTH_YEAR).

To savienojums ir parādīts attēlā. 3.3.

3.3.att. Sākotnējā attieksme.

Lai sākotnējā relācija SERVANT nonāktu pirmajā normālā formā, tā ir jāsadala četrās attiecībās, kā tas parādīts nākamajā attēlā:

Att.3.4. Normalizēts attiecību kopums.

Šeit katras attiecības primārā atslēga ir iezīmēta ar zilu rāmi, ārējo atslēgu nosaukumi ir zilā fontā. Atgādiniet, ka ārējās atslēgas tiek izmantotas, lai attēlotu funkcionālās atkarības, kas pastāv avota relācijā. Šīs funkcionālās atkarības ir norādītas ar līnijām ar bultiņām.

Normalizācijas algoritmu apraksta E.F. Codd šādi:

• Sākot ar relāciju koka augšpusē (3.3. attēls), tiek ņemta tā primārā atslēga un katra uzreiz pakārtotā relācija tiek paplašināta, ievietojot šīs primārās atslēgas domēnu vai domēnu kombināciju.
• Katras šādi izvērstas relācijas primārā atslēga sastāv no primārās atslēgas, kas relācijai bija pirms paplašinājuma, un pievienotās galvenās relācijas primārās atslēgas.
• Pēc tam visi nevienkāršie domēni tiek dzēsti no vecākrelācijas, koka augšējais mezgls tiek noņemts un tā pati procedūra tiek atkārtota katram atlikušajam apakškokam.

20. 2NF: pamata definīcijas un pārveidošanas noteikumi.

Ļoti bieži attiecību primārā atslēga ietver vairākus atribūtus (tādā gadījumā to sauc salikts) - skatiet, piemēram, attēlā parādīto sakarību BĒRNI. 3.4. 19. jautājums. Vienlaikus tiek ieviests jēdziens pilnīga funkcionālā atkarība.

Definīcija:

atribūts, kas nav atslēga, ir funkcionāli pilnībā atkarīgs no saliktas atslēgas, ja tas ir funkcionāli atkarīgs no visas atslēgas kopumā, bet nav funkcionāli atkarīgs no neviena no tās sastāvā esošajiem atribūtiem.

Piemērs:

Lai pastāv sakarība PIEGĀDE (N_PIEGĀDĀTĀJS, PRODUKTS, CENA).
Piegādātājs var piegādāt dažādas preces, un vienu un to pašu preci var piegādāt dažādi piegādātāji. Tad attiecību atslēga ir "N_piegādātājs + produkts". Ļaujiet visiem piegādātājiem piegādāt preces par vienādu cenu. Tad mums ir šādas funkcionālās atkarības:

• N_piegādātājs, produkts -> cena
• produkts -> cena

Cenas atribūta nepilnīgā funkcionālā atkarība no atslēgas noved pie šādas anomālijas: mainoties preces cenai, ir nepieciešams pilnīgs attiecību skatījums, lai mainītu visus ierakstus par tās piegādātājiem. Šī anomālija ir sekas tam, ka vienā datu struktūrā ir apvienoti divi semantiskie fakti. Šāds paplašinājums sniedz attiecības 2NF:

• PIEGĀDE (N_SUPPLIER, PRODUCT)
• PRODUCT_PRICE (PRODUCT, PRICE)

Tātad jūs varat dot

Otrās normālās formas definīcija: Relācija ir 2NF, ja tā ir 1NF un katrs bezatslēgas atribūts ir pilnībā funkcionāli atkarīgs no atslēgas.

21. 3NF: pamata definīcijas un pārveidošanas noteikumi.

Pirms apspriest trešo normālo formu, jāievieš jēdziens: pārejoša funkcionālā atkarība.

Definīcija:

Lai X, Y, Z ir kādas attiecības trīs atribūti. Šajā gadījumā X --> Y un Y --> Z, bet nav reversās atbilstības, t.i. Z -/-> Y un Y -/-> X. Tad Z ir transitīvi atkarīgs no X.
Ļaujiet pastāvēt relācija STORAGE ( STINGRS, NOLIKTAVA, APJOMS), kurā ir informācija par uzņēmumiem, kas saņem preces no noliktavām, un šo noliktavu apjomiem. Atslēgas atribūts - "stingrs". Ja katrs uzņēmums var saņemt preces tikai no vienas noliktavas, tad šajā sakarā pastāv šādas funkcionālās atkarības:

• stingrs -> krājums
• krājums -> apjoms

Šajā gadījumā rodas anomālijas:

• ja šobrīd neviens uzņēmums nesaņem preces no noliktavas, tad datus par tās apjomu nevar ievadīt datu bāzē (jo atslēgas atribūts nav definēts)
• ja mainās noliktavas apjoms, ir nepieciešams apskatīt visas attiecības un mainīt kartes visiem uzņēmumiem, kas saistīti ar šo noliktavu.

Lai novērstu šīs anomālijas, sākotnējā attiecība ir jāsadala divās daļās:

• GLABĀŠANA ( STINGRS, AKCIJA)
• STORAGE_VOLUME ( KRĀJUMI, VOLUME)

Trešās normālās formas definīcija:

Relācija ir 3NF, ja tā ir 2NF un katrs bezatslēgas atribūts nav pārejoši atkarīgs no primārās atslēgas.

InterBase var izmantot šādus ierobežojumu veidus:

• PRIMARY KEY - tabulas primārā atslēga.
• UNIQUE - unikāla galda atslēga.
• SVEŠA ATSLĒGA- ārējā atslēga, nodrošina saiti uz citu tabulu un garantē atsauces integritāti starp vecāku un bērnu galdi.

Piezīme par terminoloģiju

Ja esat līdzīgs šī kursa autoram ar to, ka jums patīk vispusīgi, dažādos dažādu autoru darbos meklēt atbildes uz sev interesējošu jautājumu, tad definīcijās jūs nevarat nepamanīt neskaidrības. galvenais (meistars) -> padotais (detaļas) tabulas. Atcerieties, ka galveno tabulu bieži sauc par vecāktabulu, bet pakārtoto tabulu bieži sauc par bērnu tabulu.

Iespējams, tas ir saistīts ar to, kā šīs definīcijas tiek interpretētas lokālajās un SQL servera DBVS.

Vietējās DBVS galvenā tabula ir tā, kurā ir galvenie dati, un pakārtotajā tabulā ir papildu dati. Ņemsim, piemēram, trīs saistītas tabulas. Pirmajā ir dati par pārdošanu, otrajā - par produktiem un trešajā - par klientiem:

Rīsi.

18.1.

Šeit galvenā informācija tiek glabāta pārdošanas tabulā, tātad tā ir galvenā (vecāku) tabula. Papildu informācija tiek glabāta preču un klientu tabulās, kas nozīmē, ka tie ir bērni. Tas ir saprotams: vienai meitai nevar būt divas bioloģiskās mātes, bet viena māte ir diezgan spējīga dzemdēt divas meitas. Bet SQL datu bāzes serveros ir atšķirīga attiecību definīcija: kad viens tabulas lauks attiecas uz lauku citā tabulā, tas tiek saukts sveša atslēga . Un jomu, uz kuru tas attiecas, sauc vecāks vai primārā atslēga . Tabulu, kurai ir ārējā atslēga (saite uz ierakstu citā tabulā), bieži sauc par bērnu, bet tabulu ar vecāku atslēga - vecāku. Arī attiecību definīcijā viņi saka, ka vecākam var būt tikai viens unikāls ieraksts, uz kuru var atsaukties vairāki ieraksti.

bērnu galds Tātad iepriekš minētajā piemērā pārdošanas tabulā ir divas ārējās atslēgas: produkta ID un klienta ID. Un abām tabulām attēla labajā pusē ir vecāku atslēga "Identifikators". Tā kā pārdošanas tabulā viens un tas pats klients vai prece var parādīties atkārtoti, izrādās, ka abas tabulas attēla labajā pusē ir vecāki, bet kreisajā pusē ir bērns. Jo mēs tagad mācāmies InterBase - SQL datu bāzes serveri, mēs vadīsimies pēc šīm definīcijām turpmākajās lekcijās. Lai vēl vairāk nemodinātu mūsu smadzenes par šo neskaidrību, vienosimies uzreiz: bērnu galds

ir ārējā atslēga (ĀRĒJĀ ATSLĒGA) citai tabulai.

PRIMĀRĀ ATSLĒGA PRIMĀRĀ ATSLĒGA - primārā atslēga ir viens no galvenajiem ierobežojumu veidiem datu bāzē. Primārā atslēga ir paredzēta, lai unikāli identificētu ierakstu tabulā, un tai ir jābūt unikālai. Primārās atslēgas PRIMARY KEY atrodas tabulās, kuras parasti sauc par vecāku (Parent). Primāro atslēgu nedrīkst jaukt ar lokālo datu bāzu primārajiem indeksiem, primārā atslēga nav indekss, bet gan ierobežojums. Veidojot primāro atslēgu InterBase automātiski izveido viņam unikāls indekss automātiski izveido viņam. Tomēr, ja radām , tas neradīs. Tabulai var būt tikai viena primārā atslēga PRIMARY KEY.

Pieņemsim, ka jums ir tabula ar darbinieku sarakstu. Laukā Uzvārds var būt dublētās vērtības (vārdu kopas), tāpēc to nevar izmantot kā primāro atslēgu. Tas ir reti, bet ir vārdabrāļi, kuriem turklāt ir vienādi vārdi. Vēl retāk ir pilni vārdi, tāpēc pat visi trīs lauki “Uzvārds” + “Vārds” + “Patronims” nevar garantēt ieraksta unikalitāti un nevar būt primārā atslēga. Šajā gadījumā risinājums, tāpat kā iepriekš, ir pievienot identifikatora lauku, kurā ir šīs personas sērijas numurs. Šādi lauki parasti tiek izveidoti ar automātisku palielināšanu (par automātiskās palielināšanas lauku organizēšanu mēs runāsim nākamajās lekcijās). Tātad,

Primārā atslēga ir viens vai vairāki tabulas lauki, kuru kombinācija katram ierakstam ir unikāla.

Ja primārajā atslēgā ir viena kolonna (kā tas visbiežāk notiek), PRIMARY KEY norādītājs tiek izmantots, kad kolonnas definīcija:

IZVEIDOT TABULU Prim_1 (Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50))

Ja primārā atslēga ir veidota uz vairākām kolonnām, tad precizētājs tiek ievietots pēc visu lauku definēšanas:

IZVEIDOT TABULU Prim_2(Stolbec1 INT NOT NULL, Stolbec2 VARCHAR(50) NOT NULL, PRIMARY KEY (Stolbec1, Stolbec2))

Kā redzams no piemēriem, primārā atslēga ir jābūt NOT NULL kolonnas(-u) ierobežojumam.

UNIKĀLS

UNIKĀLS- unikāla atslēga. UNIQUE precizētājs norāda, ka visām šī lauka vērtībām ir jābūt unikālām, tāpēc arī šādi lauki nevar saturēt vērtības NULL. Var teikt, ka UNIKĀLA atslēga ir alternatīva primārajai atslēgai, taču pastāv atšķirības. Galvenā atšķirība ir tā, ka jābūt tikai vienai primārajai atslēgai, savukārt var būt vairākas unikālas atslēgas. Turklāt UNIKĀLU ierobežojumu nevar izveidot uz tās pašas kolonnu kopas, kas tika izmantota PRIMARY KEY vai citam UNIKĀLAjam ierobežojumam. Unikālās atslēgas, tāpat kā primārās atslēgas, ir atrodamas tabulās, kas ir citu tabulu vecāki.

Kolonnu, kas deklarēta ar UNIKĀLU ierobežojumu, piemēram, primāro atslēgu, var izmantot, lai ieviestu atsauces integritāti starp tās vecāku un bērnu galdi. Šajā gadījumā ārējā atslēga - vecāku. Arī attiecību definīcijā viņi saka, ka vecākam var būt tikai viens unikāls ieraksts, uz kuru var atsaukties vairāki ieraksti attieksies uz šo lauku(-iem). Tāpat kā ar primāro atslēgu, kad tiek izveidota unikāla atslēga, a automātiski izveido viņam. Bet ne otrādi. Piemērs tabulas izveidei ar vienu primāro un divām unikālajām atslēgām:

IZVEIDOT TABULU Prim_3(Stolbec1 INT NOT NULL PRIMARY KEY, Stolbec2 VARCHAR(50) NOT NULL UNIQUE, Stolbec3 FLOAT NOT NULL UNIQUE)

SVEŠA ATSLĒGA

SVEŠA ATSLĒGA- ārējā atslēga. Tas ir ļoti spēcīgs rīks atsauces integritātes nodrošināšanai starp tabulām, kas ļauj ne tikai uzraudzīt pareizo saišu klātbūtni, bet arī automātiski tās pārvaldīt. Ārējās atslēgas ir ietvertas tabulās, kas ir citu tabulu atvasinājumi (bērns). Atsauces integritāte tiek nodrošināta tieši ar ārējās atslēgas palīdzību, kas attiecas uz primāro vai

Un tā mēs klusi piegājām pie ļoti svarīgas tēmas – primārās un ārējās atslēgas. Kamēr pirmos izmanto gandrīz visi, pēdējos kaut kā ignorē. Bet velti. Ārējās atslēgas nav problēma, tās ir reāls palīgs datu integritātē.

1.2.5. Primārā atslēga

Mēs jau esam daudz runājuši par galvenajiem laukiem, bet mēs nekad tos neesam izmantojuši. Interesantākais ir tas, ka viss izdevās. Tā ir Microsoft SQL Server un MS Access datu bāzu priekšrocība vai varbūt trūkums. Šis triks nedarbosies Paradox tabulās, un bez atslēgas lauka tabula būs tikai lasāma.

Zināmā mērā atslēgas ir ierobežojumi, un tos var uzskatīt kopā ar CHECK priekšrakstu, jo deklarācija notiek līdzīgā veidā un pat izmanto priekšrakstu CONSTRAINT. Apskatīsim šo procesu ar piemēru. Lai to izdarītu, mēs izveidosim tabulu ar diviem laukiem “guid” un “vcName”. Tādējādi lauks "ceļvedis" tiek iestatīts kā primārā atslēga:

IZVEIDOT TABULU Globally_Unique_Data (ceļvedis unikālais identifikators DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (Guid))

Labākā daļa šeit ir CONSTRAINT līnija. Kā zināms, šim atslēgvārdam seko ierobežojuma nosaukums, un atslēgas deklarācija nav izņēmums. Lai nosauktu primāro atslēgu, iesaku izmantot nosaukšanas veidu PK_name, kur nosaukums ir tā lauka nosaukums, kuram jākļūst par primāro atslēgu. Saīsinājums PK nāk no primārās atslēgas.

Pēc tam atslēgvārda CHECK vietā, ko izmantojām ierobežojumos, ir operators PRIMARY KEY. Tas norāda, ka mums nav nepieciešama pārbaude, bet gan primārā atslēga. Viens vai vairāki lauki, kas veidos atslēgu, ir norādīti iekavās.

Atcerieties, ka divām rindām nevar būt vienādas vērtības atslēgas laukā, kurā primārās atslēgas ierobežojums ir identisks unikālam ierobežojumam. Tas nozīmē, ka, ja uzvārda glabāšanas lauku padarīsit par primāro atslēgu, tad šādā tabulā nevarēs ierakstīt divus Ivanovus ar dažādiem vārdiem. Tas pārkāpj primārās atslēgas ierobežojumu. Tāpēc atslēgas ir ierobežojumi un tiek deklarētas tāpat kā CHECK ierobežojums. Bet tas neattiecas tikai uz primārajām atslēgām un sekundārajām atslēgām ar unikalitāti.

Šajā piemērā primārā atslēga ir unikālā identifikatora (GUID) tipa lauks. Šī lauka noklusējuma vērtība ir NEWID servera procedūras rezultāts.

Uzmanību

Tabulai var izveidot tikai vienu primāro atslēgu

Lai vienkāršotu piemērus, kā atslēgu vēlams izmantot ciparu tipu, un, ja datu bāze atļauj, tad labāk būs “autoincrement” tipa (automātiski pieaugošs/samazinošs skaitlis). MS SQL Server šis lauks ir IDENTITĀTE, bet MS Access tas ir “skaitītāja” tipa lauks.

Šajā piemērā parādīts, kā izveidot produktu tabulu ar automātiski pieaugošu vesela skaitļa lauku kā primāro atslēgu:

IZVEIDOT TABULU Produkti (id int IDENTITY(1, 1), product varchar(50), cena nauda, ​​daudzuma skaitlisks(10, 2), CONSTRAINT PK_id PRIMARY KEY (id))

Šis ir atslēgas veids, ko izmantosim visbiežāk, jo atslēgas laukā tiks saglabāti skaitļi, kas ir viegli saprotami un ar kuriem būs vieglāk un vizuālāk strādāt.

Primārā atslēga var sastāvēt no vairākām kolonnām. Tālāk sniegtajā piemērā tiek izveidota tabula, kurā lauki "id" un "Produkts" veido primāro atslēgu, kas nozīmē, ka abos laukos tiks izveidots unikāls indekss:

IZVEIDOT TABULU Produkti1 (id int IDENTITY(1, 1), Product varchar(50), Cena nauda, ​​Daudzums skaitlisks(10, 2), CONSTRAINT PK_id PRIMARY KEY (id, [Product Name]))

Ļoti bieži programmētāji izveido datu bāzi ar atslēgas lauku vesela skaitļa formā, bet tajā pašā laikā uzdevumā ir skaidri norādīts, ka noteiktiem laukiem ir jābūt unikāliem. Kāpēc gan uzreiz neizveidot primāro atslēgu no tiem laukiem, kuriem jābūt unikāliem un nebūs jārada atsevišķi risinājumi šai problēmai.

Vienīgais vairāku kolonnu primārās atslēgas trūkums ir attiecību izveides problēma. Šeit jums ir jāizkļūst no tā, izmantojot dažādas metodes, taču problēmu joprojām var atrisināt. Jums vienkārši jāievada unikālā identifikatora tipa lauks un jāizveido savienojums, izmantojot to. Jā, šajā gadījumā mēs iegūstam unikālu primāro atslēgu un unikālā identifikatora tipa lauku, taču šī dublēšanās rezultātā nebūs lielāka par to pašu tabulu, kurā primārā atslēga ir unikāls identifikators, un laukiem, kas ir obligāti, ir iestatīts unikalitātes ierobežojums. esi unikāls. Ko izvēlēties? Atkarīgs no konkrētā uzdevuma un tā, ar ko jums ir ērtāk strādāt.

1.2.6. Ārējā atslēga

Ārējā atslēga ir arī ierobežojums CONSTRAINT un atspoguļo attiecības starp divām tabulām. Pieņemsim, ka jums ir divas tabulas:

• Vārdi – satur cilvēku vārdus un sastāv no identifikatora laukiem (atslēgas lauks), vārda.
• Tālruņi ir tālruņu tabula, kas sastāv no identifikatora (atslēgas lauka), ārējās atslēgas savienojuma izveidei ar nosaukumu tabulu un virknes lauka tālruņa numura saglabāšanai.

Vienam cilvēkam var būt vairāki telefoni, tāpēc datu krātuvi sadalījām dažādās tabulās. Attēlā 1.4 vizuāli parādītas attiecības starp divām tabulām. Ja esat jau strādājis ar saistītajām tabulām, tad ar to jums pietiks. Ja par savienojumiem dzirdat pirmo reizi, tad mēģināsim sīkāk aplūkot problēmu.

Piemēram, ņemsim trīs cilvēku galdu. 1.3. tabulā parādīts tabulas "Vārdi" saturs. Ir tikai trīs rindas, un katrai no tām ir sava unikālā galvenā atslēga. Unikalitātes labad, veidojot tabulu, atslēgu padarīsim par automātiski augošu lauku.

1.3. tabula Tabulas Nosaukumi saturs

1.4. tabula. Tabulas Telefoni saturs

Tabulā 1.4 ir pieci tālruņu numuri. Galvenās atslēgas laukā ir arī unikāla galvenā atslēga, kuru var arī automātiski palielināt. Sekundārā atslēga ir saistība ar tabulas Nosaukumi primāro atslēgu. Kā šis savienojums darbojas? Petrovam ir numurs 1 kā primārā atslēga tabulā Vārdi. Tabulā Tālruņi sekundārajā atslēgā mēs meklējam numuru 1 un iegūstam Petrova tālruņu numurus. Tas pats attiecas uz pārējiem ierakstiem. Vizuāli savienojums ir redzams 1.5. attēlā.

Šāda veida datu glabāšana ir ļoti ērta. Ja nebūtu iespējams izveidot saistītās tabulas, tad tabulā Vārdi mums būtu jāievada visi tālruņu numuri vienā laukā. Tas ir neērti no lietošanas, apkopes un datu izguves viedokļa.

Tabulā var izveidot vairākus Names laukus, bet rodas jautājums – cik. Vienam cilvēkam var būt tikai 1 telefons, bet man, piemēram, 3, neskaitot darba. Liels skaits lauku izraisa datu dublēšanu.

Tabulā Vārdi var izveidot atsevišķu rindu ar uzvārdu katram tālrunim, taču tas ir viegli tikai tik vienkāršam piemēram, kad jāievada tikai uzvārds un ar vairākiem tālruņiem var viegli veikt vairākus Petrova ierakstus cipariem. Ko darīt, ja ir 10 vai 20 lauki? Tātad divu tabulu, kas saistītas ar ārējo atslēgu, izveide ir redzama sarakstā 1.6.

Uzskaitījums 1.6. Ar ārējo atslēgu saistīto tabulu izveide

CREATE TABLE Nosaukumi (idName int IDENTITY(1,1), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName),) CREATE TABLE Tālruņi (idPhone int IDENTITY(1,1), idName int, vcPhone varchar(10), CONSTRAINT PK_idPhone PRIMARY KEY (idPhone), CONSTRAINT FK_idName SVEŠĀ ATSLĒGA (idName) ATSAUCES Vārdi (idName))

Lūdzu, rūpīgi pārskatiet saraksta saturu. Tas ir diezgan interesanti, jo tajā tiek izmantoti daži no operatoriem, kurus mēs jau esam aplūkojuši, un būtu noderīgs papildu piemērs. Abām tabulām tiek izveidots atslēgas lauks, kas ir pirmais, ir int tipa un tiek automātiski palielināts, sākot no 1, soli pa vienam. Atslēgas lauks tiek padarīts par galveno atslēgu, izmantojot ierobežojumu CONSTRAINT.

Tabulas Phones aprakstā pēdējā rindā ir mums jauna deklarācija, proti, ārējās atslēgas deklarācija, izmantojot operatoru SVEŠĀS ATSLĒGA. Kā redzat, tas ir arī ierobežojums, un nedaudz vēlāk jūs redzēsit, kāpēc. Tabulas lauks, kas jāsaista ar citu tabulu, ir norādīts iekavās. Pēc tam seko atslēgvārds REFERENCES (saite), tabulas nosaukums, ar kuru jābūt savienojumam (Names) un iekavās lauka nosaukums ("idName"). Tādējādi esam izveidojuši savienojumu, kas parādīts 1.4. attēlā.

Uzmanību!

Ārējā atslēga var atsaukties tikai uz citas tabulas primāro atslēgu vai unikālu ierobežojumu. Tas nozīmē, ka aiz atslēgvārda REFERENCES ir jābūt tabulas nosaukumam un iekavās var norādīt tikai primāro atslēgu vai lauku ar UNIKĀLU ierobežojumu. Citus laukus nevar norādīt.

Tagad, ja varat aizpildīt tabulas ar datiem. Nākamās trīs komandas pievieno trīs nosaukumus, ko redzējām 1.3. tabulā:

INSERT INTO Vārdi(vcName) VALUES("Petrov") INSERT INTO Vārdi(vcName) VALUES("Ivanov") INSERT INTO Vārdi(vcName) VALUES("Sidorov")

Ja jau esat strādājis ar SQL, varat pievienot ierakstus tālruņa tabulai. Es izlaidīšu šīs komandas, taču tās var redzēt failā Foreign_keys.sql, kas atrodas kompaktdiska 1. nodaļas direktorijā.

Mūsu uzdevums tagad ir redzēt, kādas ir ārējās atslēgas ierobežojošās darbības, izdomāsim to. Mēs esam norādījuši skaidru attiecību starp diviem laukiem dažādās tabulās. Ja mēģināsit tālruņa tabulai pievienot ierakstu ar identifikatoru laukā "idName", kas neeksistē tāda paša nosaukuma laukā (vārdu var mainīt uz citu) tabulā ar uzvārdiem, tiks parādīta kļūda. . Tas pārtrauks attiecības starp abām tabulām, un ārējās atslēgas ierobežojums neļaus ierakstiem pastāvēt bez attiecībām.

Ierobežojums attiecas arī uz ierakstu maiņu vai dzēšanu. Piemēram, ja mēģināt dzēst rindu ar uzvārdu Petrov, radīsies ārējās atslēgas ierobežojuma kļūda. Jūs nevarat izdzēst ierakstus, kuriem ir ārēji saistītas rindas. Pirmkārt, jums ir jāizdzēš visi tālruņa numuri šim ierakstam, un tikai pēc tam būs iespējams izdzēst rindu ar uzvārdu Petrovs.

Veidojot ārējo atslēgu, varat norādīt ON DELETE CASCADE vai ON UPDATE CASCADE. Tādā gadījumā, ja izdzēšat Petrova ierakstu no tabulas Vārdi vai mainīsit identifikatoru, visi ar Petrova rindu saistītie ieraksti tabulā Tālruņi tiks automātiski atjaunināti. Nekad. Nē, tas jāraksta ar lielajiem burtiem: NEKAD to nedariet. Viss ir jādzēš vai jāmaina manuāli. Ja lietotājs nejauši izdzēš ierakstu no tabulas Vārdi, tiek dzēsti arī attiecīgie tālruņi. Nav jēgas izveidot ārējo atslēgu, ja puse no tās ierobežojumiem pazūd! Viss ir jādara manuāli, un nekad nav ieteicams mainīt identifikatorus.

Pašu tabulu dzēšana jāsāk arī ar pakārtoto tabulu, tas ir, ar Tālruņiem, un tikai pēc tam var izdzēst galveno tabulu Vārdi.

Visbeidzot, es jums parādīšu, kā skaisti saskaņot vārdus un tālruņu numurus no divām tabulām:

SELECT vcName, vcPhone FROM Vārdi, tālruņi WHERE Names.idName=Phones.idName

Par šādiem vaicājumiem sīkāk runāsim 2. nodaļā. Pagaidām es sniedzu piemēru, lai jūs varētu redzēt saistīto tabulu spēku.

Tabulā var būt līdz 253 ārējām atslēgām, kas ir pilnīgi pietiekami pat vissarežģītākajām datu bāzēm. Man personīgi nācās strādāt ar datu bāzēm, kurās ārējo atslēgu skaits nepārsniedza 7 vienā tabulā. Ja to ir vairāk, tad visticamāk datubāze ir izveidota nepareizi, lai gan ir izņēmumi.

Arī pašā tabulā var būt ne vairāk kā 253 ārējās atslēgas. Ārējās atslēgas tabulā ir retāk sastopamas, parasti ne vairāk kā 3. Visbiežāk tabulā var būt daudz saišu uz citām tabulām.

Ārējā atslēga var atsaukties uz to pašu tabulu, kurā tā ir izveidota. Piemēram, jums ir tabula ar amatu nosaukumiem organizācijā, kā parādīts 1.5. tabulā. Tabulā ir trīs lauki: primārā atslēga, ārējā atslēga un amata nosaukums. Jebkurai organizācijai var būt daudz amatu, taču būtu diezgan loģiski to nosaukumus un pakļautības struktūru attēlot vienā tabulā. Lai to izdarītu, ārējā atslēga ir jāsaista ar pozīcijas tabulas primāro atslēgu.

1.5. tabula. Tabula ar iekšējo saiti

Rezultātā mēs iegūstam, ka ģenerāldirektoram ir nulles ārējā atslēga, t.i. šī pozīcija stāv visu pārējo priekšgalā. Komercdirektoram un vispārējo lietu direktoram ārējā atslēga norāda uz ģenerāldirektora rindu. Tas nozīmē, ka šīs divas pozīcijas ir tieši pakļautas izpilddirektoram. Un tā tālāk.

Apskatīsim, kā mēs varam to visu izveidot kā SQL vaicājumu:

IZVEIDOT TABULU pozīcijas (idPosition int IDENTITY(1,1), idParentPosition int, vcName varchar(30), CONSTRAINT PK_idPosition PRIMARY KEY (idPosition), CONSTRAINT FK_idParentPosition ĀRĒJĀ ATSLĒGA (idParentPosition) REFERENCESPosition)

Kā redzat, ārējā atslēga vienkārši atsaucas uz to pašu tabulu, kuru mēs veidojam. Kompaktdiskā, Chapter1 direktorijā, var redzēt failā Foreign_keys_to_self.sql piemēru šīs tabulas izveidei, aizpildīšanai ar datiem un pozīciju attēlošanai, ņemot vērā to pakļautību. Nākamajā nodaļā sīkāk aplūkosim iespēju strādāt ar šādām tabulām.

Attiecības viens pret vienu

Līdz šim esam aplūkojuši klasisko attiecību, kad viena galvenās datu tabulas rinda atbilst vienai rindai no saistītās tabulas. Šīs attiecības sauc viens pret daudziem. Bet ir arī citas sakarības, un tagad mēs apskatīsim vēl vienu - viens pret vienu, kad viens ieraksts galvenajā tabulā ir savienots ar vienu cita ierakstu. Lai to īstenotu, pietiek saistīt abu tabulu primārās atslēgas. Tā kā primārās atslēgas nevar atkārtot, abās tabulās var būt saistīta tikai viena rinda.

Šajā piemērā tiek izveidotas divas tabulas, kurām ir primārās atslēgas attiecības:

CREATE TABLE Nosaukumi (idName unikāls identifikators DEFAULT NEWID(), vcName varchar(50), CONSTRAINT PK_guid PRIMARY KEY (idName)) CREATE TABLE Tālruņi (idPhone unikālais identifikators DEFAULT NEWID(), vcPhone varchar(10), CONSTRAINTIDP (PRIMARYIDPhone) IEROBEŽOJUMS FK_idPhone ĀRĒJĀ ATSLĒGA (idPhone) ATSAUCES Vārdi (idName))

Tikai vienai no tabulām ir nepieciešama ārējā atslēga. Tā kā attiecības ir viens pret vienu, nav nozīmes, kurā tabulā tās izveidot.

daudzi pret daudziem

Sarežģītākā attiecība ir daudzi pret daudziem, kur daudzi ieraksti no vienas tabulas sakrīt ar daudziem ierakstiem no citas tabulas. Lai to īstenotu, nepietiek ar trim tabulām.

Vispirms mums ir jāsaprot, kad var izmantot attiecības "daudzi pret daudziem"? Pieņemsim, ka jums ir divas tabulas: mājas iedzīvotāju saraksts un tālruņu numuru saraksts. Vienam dzīvoklim var būt vairāki numuri, kas nozīmē, ka vienam uzvārdam var būt divi tālruņa numuri. Izrādās, ka pastāv attiecības viens pret daudziem. Savukārt vienā dzīvoklī (komunālajā dzīvoklī vai vienkārši īrnieks, kurš lieto saimnieka telefonu) var būt divas ģimenes, kas nozīmē, ka saikne starp telefonu un iedzīvotāju arī ir viens pret daudziem. Un grūtākais variants ir divi telefoni komunālajā dzīvoklī. Šajā gadījumā abus numurus izmanto vairāki dzīvokļa iedzīvotāji. Tātad izrādās, ka “daudzas” ģimenes var izmantot “daudzus” tālruņus (saziņa no daudziem pret daudziem).

Kā īstenot attiecības "daudzi pret daudziem"? No pirmā acu uzmetiena relāciju modelī tas nav iespējams. Apmēram pirms 10 gadiem es ilgu laiku meklēju dažādas iespējas, un rezultātā es vienkārši izveidoju vienu tabulu, kas tika aizpildīta ar liekiem datiem. Bet kādu dienu man tika dots viens uzdevums, pateicoties kuram no nosacījumiem radās lielisks risinājums - vajadzēja izveidot divas dzīvokļu iedzīvotāju un telefona numuru tabulas un tajās ieviest tikai primāro atslēgu. Šajā tabulā svešās atslēgas nav vajadzīgas. Bet savienojumam starp galdiem jābūt caur trešo, savienojošo galdu. No pirmā acu uzmetiena tas ir sarežģīti un neskaidri, taču, kad jūs sapratīsit šo metodi, jūs redzēsit visas šī risinājuma iespējas.

1.6. un 1.7. tabulā parādīti attiecīgi uzvārdu un tālruņu tabulu piemēri. Un 1.8. tabulā ir parādīta saistīšanas tabula.

1.6. tabula. Uzvārdu tabula

1.7. tabula. Tālruņa galds

1.8. tabula. Tālruņa galds

Tagad redzēsim, kāda būs datu meklēšanas loģika attiecībās daudzi pret daudziem. Teiksim, jāatrod visi telefoni, kas pieder Ivanovam. Ivanova primārā atslēga ir vienāda ar 1. Saistīšanas tabulā atrodam visus ierakstus, kuriem lauks “Saistība ar vārdu” ir vienāds ar 1. Tie būs 1. un 2. ieraksti. Šajos ierakstos laukā “Saistība ar telefonu” ir ir attiecīgi identifikatori 1 un 2, un Tas nozīmē, ka Ivanovam pieder numuri no tālruņu tabulas, kas atrodas 1. un 2. rindā.

Tagad atrisināsim apgriezto problēmu - noskaidrosim, kam ir piekļuve tālruņa numuram 567575677. Šim numuram tālruņu tabulā ir atslēga 3. Mēs meklējam visus ierakstus saistīšanas tabulā, kur laukā “Tālruņa savienojums” ir vienāds ar 3. Tie ir ieraksti ar cipariem 4 un 5, kas laukā "Nosaite" satur attiecīgi vērtības 2 un 3. Ja tagad paskatās uz uzvārdu tabulu, tad pie 2. un 3. numura redzēsit Petrovs un Sidorovs. Tas nozīmē, ka šie divi iedzīvotāji izmanto tālruņa numuru 567575677.

Pārskatiet visas trīs tabulas un pārliecinieties, ka saprotat, kuri tālruņu numuri pieder kuriem iedzīvotājiem un otrādi. Ja redzat šo sakarību, sapratīsiet, ka tas ir tik vienkārši kā trīs santīmi un varat ātri to īstenot savos projektos.

CREATE TABLE Name CREATE TABLE LinkTable (idLinkTable unikālais identifikators DEFAULT NEWID(), idName unikāls identifikators, idPhone unikālais identifikators, CONSTRAINT PK_idLinkTable PRIMARY KEY (idLinkTable), CONSTRAINT FK_idPhone FOREIGN KEY REĢISTRĀCIJAS NEWID( idName idPhone) N KEY (idName REF) ERENCES Vārdi (idName ) )

Saistīšanas tabulai ir divas ārējās atslēgas, kas ir saistītas ar nosaukumiem un tālruņu tabulām, un viena primārā atslēga, kas nodrošina ierakstu unikālo raksturu.

Es izvēlējos GUID lauku kā primāro atslēgu, jo tas ir ērtāk šīs problēmas risināšanai. Fakts ir tāds, ka mums ir jāievieto ieraksti divās tabulās, un abos gadījumos mums ir jānorāda viena un tā pati atslēga. GUID vērtību var ģenerēt un pēc tam izmantot, ievietojot datus abās tabulās.

Kā atslēgu var izmantot arī automātiski pieaugošu lauku, taču šajā gadījumā problēmu ir nedaudz grūtāk atrisināt, pareizāk sakot, problēmu atrisināt ir neērti. Piemēram, pievienojot tālruņa numuru, vispirms tabulā jāievieto atbilstošā rinda, pēc tam tā jāatrod, jānosaka rindai piešķirtā atslēga un pēc tam jāizveido savienojums.

Šajā posmā mēs aprobežojamies ar tabulu izveidi, bet 2.8. sadaļā mēs atgriezīsimies pie šīs tēmas un uzzināsim, kā strādāt ar saistītām tabulām. Darbs ar attiecībām viens pret vienu un viens pret daudziem īpaši neatšķiras, jo šajā shēmā ir iesaistītas tikai divas tabulas. Attiecības daudzi pret daudziem ir nedaudz sarežģītākas saistīšanas tabulas dēļ, tāpēc mēs to aplūkosim atsevišķi 2.27. sadaļā.