Prednáška DB Kapitola 2 VZŤAHOVÉ DATABÁZY 2.1. Pojmy a definície Vývoj relačných databáz sa začal koncom 60. rokov 20. storočia, keď sa objavili prvé práce, v ktorých sa diskutovalo o možnostiach využitia metód formalizovanej reprezentácie údajov vo forme tabuliek, ktoré poznal odborník. Niektorí odborníci nazývali tento spôsob prezentácie informácií ako rozhodovacie tabuľky, iní - tabuľkové algoritmy. Teoretici relačných databáz nazvali tabuľkový spôsob reprezentácie informácií ako datalogické modely. Za zakladateľa teórie relačných databáz je považovaný zamestnanec IBM Dr.EF Codd, ktorý 6. júna 1970 publikoval článok „A Relational Model of Data for Large Shared Data Banks“ „A Relational Model of Data for Veľké zdieľané dátové banky“. V tomto článku bol po prvýkrát použitý pojem „relačný dátový model“, ktorý položil základ pre relačné databázy. Teória relačných databáz sa vyvinula v 70. rokoch 20. storočia. v USA doktorom E. F. Coddom, opieral sa o matematický aparát teórie množín. Dokázal, že každý súbor údajov MÔŽE byť reprezentovaný vo forme dvojrozmerných tabuliek špeciálneho druhu, v matematike známych ako vzťahy. Z anglického slova „relation“ „relation“ a vznikol názov „relational data model“. V súčasnosti je teoretickým základom pre návrh databáz (DB) matematický aparát relačnej algebry (pozri časť 1.2). Relačnou databázou sú teda informácie (údaje) o objektoch prezentované vo forme dvojrozmerných polí - tabuliek, spojených určitými väzbami. Databáza môže pozostávať aj z jednej tabuľky. Predtým, ako pristúpime k ďalšiemu štúdiu relačných databáz, pouvažujme o pojmoch a definíciách používaných v teórii a praxi. Databázová tabuľka- dvojrozmerné pole obsahujúce informácie o jednej triede objektov. V teórii relačnej algebry sa nazýva dvojrozmerné pole (tabuľka). postoj. Tabuľka pozostáva z týchto prvkov: pole, bunka, záznam (obr. 2.1). Lúka obsahuje hodnoty jedného z atribútov, ktoré charakterizujú databázové objekty. Počet polí v tabuľke zodpovedá počtu znakov, ktoré charakterizujú databázové objekty. 22 Bunka obsahuje konkrétnu hodnotu zodpovedajúceho poľa (atribút jedného objektu). Nahrávanie- riadok tabuľky. Obsahuje hodnoty všetkých znakov, ktoré charakterizujú jeden objekt. Počet záznamov (riadkov) zodpovedá počtu objektov, o ktorých sa v tabuľke nachádzajú údaje. V teórii databázy termín nahrávanie zodpovedá koncepcii cor-tezh- postupnosť atribútov súvisiacich navzájom vzťahom AND (AND). V teórii grafov sprievod znamená jednoduchú vetvu orientovaného grafu - stromu. Tabuľka 2.1 ukazuje pojmy používané v teórii a praxi vývoja relačných databáz. Jedným z dôležitých konceptov potrebných na vybudovanie optimálnej štruktúry pre relačné databázy je koncept kľúča alebo kľúčového poľa. kľúč uvažuje sa pole, ktorého hodnoty jednoznačne určujú hodnoty všetkých ostatných polí v tabuľke. Napríklad pole „Číslo pasu“ alebo „Identifikačné číslo daňového poplatníka (DIČ)“ jednoznačne definuje charakteristiky každého jednotlivca (pri zostavovaní príslušných databázových tabuliek PRE HR oddelenia alebo účtovné oddelenie podniku). 
23
Kľúčom tabuľky nemôže byť jedno, ale niekoľko polí. V tomto prípade môže byť množina polí možným kľúčom pre tabuľku len vtedy, keď sú splnené dve časovo nezávislé podmienky: jedinečnosť a minimalizácia. Každé pole, ktoré nie je súčasťou primárneho kľúča, sa v tabuľke nazýva nekľúčové pole.
Jedinečnosť kľúč znamená, že v žiadnom danom čase nemôže tabuľka databázy obsahovať žiadne dva rôzne záznamy, ktoré majú rovnaké hodnoty poľa kľúča. Splnenie podmienky jedinečnosti je povinné. Podmienka minimalizmus kľúčové polia znamená, že iba kombinácia hodnôt vybraných polí spĺňa požiadavky na jedinečnosť záznamov databázovej tabuľky. To tiež znamená, že žiadne z polí zahrnutých v kľúči z neho nemožno vylúčiť bez narušenia jedinečnosti. Pri vytváraní kľúča databázovej tabuľky pozostávajúcej z niekoľkých polí je potrebné riadiť sa nasledujúcimi ustanoveniami: do kľúča by ste nemali zahrnúť polia tabuľky, ktorých hodnoty samy osebe jednoznačne identifikujú záznamy v tabuľke. . Nemali by ste napríklad vytvárať kľúč obsahujúci súčasne polia „číslo pasu“ a „identifikačné číslo daňového poplatníka“, pretože každý z týchto atribútov môže jednoznačne identifikovať záznamy v tabuľke; do kľúča nemôžete zahrnúť nejedinečné pole, teda pole, ktorého hodnoty sa môžu v tabuľke opakovať. Každá tabuľka musí mať aspoň jeden možný kľúč, ktorý je vybraný ako primárny kľúč. Ak sú v tabuľke polia, z ktorých hodnoty každého jednoznačne definujú záznamy, potom tieto polia možno považovať za alternatívne kľúče. Ak napríklad vyberiete identifikačné číslo daňovníka ako primárny kľúč, číslo pasu bude alternatívnym kľúčom. 2.2. Normalizácia tabuliek relačných databáz Relačná databáza je súbor tabuliek, ktoré spolu súvisia. Počet tabuliek v jednom súbore alebo v jednej databáze závisí od mnohých faktorov, z ktorých hlavné sú: zloženie používateľov databázy, zabezpečenie integrity informácií (dôležité najmä v informačných systémoch s viacerými používateľmi), zabezpečenie minimálneho množstva požadovanej pamäte a minimálny čas spracovania údajov. 24Zohľadnenie týchto faktorov pri návrhu relačných databáz sa uskutočňuje metódami normalizácie tabuliek a vytváraním spojení medzi nimi.
Normalizácia tabuliek je spôsob rozdelenia jednej databázovej tabuľky do niekoľkých tabuliek, ktoré vo všeobecnosti spĺňajú vyššie uvedené požiadavky. Normalizácia tabuľky je postupná zmena štruktúry tabuľky, kým nespĺňa požiadavky poslednej formy normalizácie. Celkovo existuje šesť foriem normalizácie:- prvá normálna forma (First Normal Form - 1NF); druhá normálna forma (Second Normal Form - 2NF); tretia normálna forma (Third Normal Form - ЗNF); normálna forma Boyes - Codd (Brice - Codd Normal Form -BCNF); štvrtá normálna forma (Štvrté Normálna forma - 4NF); piata normálna forma, alebo normálna projekčná forma - spojenia (Fifth Normal Form - 5NF, alebo PJ / NF ).
26 
Pole "Celkové rozmery (dĺžka x šírka x výška), mm", rozdelené do troch polí: "Dĺžka, mm", "Šírka, mm", "Výška, mm". Kľúčovým poľom tejto tabuľky môže byť pole „Model stroja“ alebo „Č. 2.3. Uveďme si ďalší príklad. Na obr. 2.2 je znázornený fragment výsledkového hárku testu, ktorý rovnako ako v predchádzajúcom príklade nebol pôvodne určený na počítačové spracovanie. Predpokladajme, že chceme vytvoriť databázu pre automatizované spracovanie výsledkov test-skúšky v súlade s 
27
s obsahom testovacieho a skúšobného hárku. Za týmto účelom transformujeme obsah formulára do databázových tabuliek. Vychádzajúc z potreby dodržania podmienok funkčnej závislosti medzi poľami je potrebné zostaviť aspoň dve tabuľky (obr. 2.3) (kľúčové polia v každej tabuľke sú vyznačené tučným písmom). Prvá tabuľka obsahuje výsledky úspešného absolvovania testu (skúšky) každého študenta z konkrétneho predmetu. Druhá tabuľka obsahuje konečné výsledky absolvovania testu (skúšky) konkrétnej skupiny žiakov z konkrétneho predmetu. V prvej tabuľke je kľúčové pole „Celé meno študenta“ a v druhej tabuľke pole „Disciplína“. Tabuľky musia byť prepojené poliami "Disciplína" A "Kód skupiny".
Prezentované štruktúry tabuliek plne spĺňajú požiadavky prvej normálnej formy, ale vyznačujú sa nasledujúcimi nevýhodami: pridávanie nových údajov do tabuliek vyžaduje zadanie hodnôt pre všetky polia; v každom riadku každej tabuľky je potrebné zadať opakované hodnoty polí "Disciplína", "Celé meno učiteľa", "Kód skupiny". Následne pri takomto zložení tabuliek a ich štruktúre je zreteľná nadbytočnosť informácií, čo si samozrejme vyžiada dodatočnú pamäť. Aby sa predišlo uvedeným nevýhodám, je potrebné uviesť tabuľky do druhej alebo tretej normálnej formy. Druhá normálna forma. Tabuľka je v druhej normálnej forme, ak spĺňa požiadavky prvej normálnej formy a všetky jej polia, ktoré nie sú zahrnuté v primárnom kľúči, sú plne funkčné v závislosti od primárneho kľúča. 28
Ak má tabuľka jednoduchý primárny kľúč pozostávajúci iba z jedného poľa, potom je automaticky v druhej normálnej forme.
Ak je primárny kľúč zložený, tabuľka je voliteľne v druhej normálnej forme. Potom sa musí rozdeliť do dvoch alebo viacerých tabuliek tak, aby primárny kľúč jednoznačne identifikoval hodnotu v ľubovoľnom poli. Ak tabuľka obsahuje aspoň jedno pole, ktoré nezávisí od primárneho kľúča, potom musia byť v primárnom kľúči zahrnuté ďalšie stĺpce. Ak takéto stĺpce neexistujú, musíte pridať nový stĺpec. Na základe týchto podmienok, ktoré určujú druhú normálnu formu, možno vyvodiť nasledujúce závery o charakteristikách zostavených tabuliek (pozri obr. 2.3). V prvej tabuľke neexistuje žiadny priamy vzťah medzi kľúčovým poľom a poľom „Celé meno učiteľa“, keďže skúšku alebo skúšku z toho istého predmetu môžu absolvovať rôzni učitelia. V tabuľke je úplná funkčná závislosť len medzi všetkými ostatnými poľami a kľúčovým poľom „Disciplína“. Podobne v druhej tabuľke neexistuje priamy vzťah medzi kľúčovým poľom a poľom „Celé meno učiteľa“. Pre optimalizáciu databázy, najmä zníženie potrebného množstva pamäte z dôvodu potreby opakovania hodnôt polí "Disciplína" a "Meno učiteľa" v každom zázname, je potrebné zmeniť štruktúru databázy - transformovať pôvodné tabuľky do druhej normálnej podoby. Zloženie tabuliek upravenej štruktúry databázy je znázornené na obr. 2.4. Konvertovaná štruktúra databázy pozostáva zo šiestich tabuliek, z ktorých dve sú vzájomne prepojené (kľúčové polia v každej tabuľke sú vyznačené tučným písmom). Všetky tabuľky spĺňajú požiadavky druhej normálnej formy. Piata a šiesta tabuľka majú duplicitné hodnoty v poliach, ale vzhľadom na to, že tieto hodnoty sú celé čísla namiesto textových údajov, celkové množstvo pamäte potrebnej na uloženie informácií je oveľa menšie ako v pôvodných tabuľkách (pozri obr. 2.1 ). Nová štruktúra databázy navyše poskytne možnosť naplniť tabuľky rôznymi špecialistami (oddelenie manažérskych služieb). Ďalšia optimalizácia databázových tabuliek je zredukovaná na ich uvedenie do tretej normálnej formy. Tretia normálna forma. Tabuľka je v tretej normálnej forme, ak spĺňa definíciu druhej normálnej formy a žiadne z jej nekľúčových polí funkčne nezávisí od akéhokoľvek iného nekľúčového poľa. 29
Môžete tiež povedať, že tabuľka je v tretej normálnej forme, ak je v druhej normálnej forme a každé nekľúčové pole prechodne nezávisí od primárneho kľúča. Treťou požiadavkou normálneho formulára je, že všetky nekľúčové polia závisia iba od primárneho kľúča a nezávisia od seba. V súlade s týmito požiadavkami patrí prvá, druhá, tretia a štvrtá tabuľka ako súčasť databázových tabuliek (pozri obr. 2.3) do tretej normálnej formy. Aby sme piatu a šiestu tabuľku dostali do tretej normálnej formy, vytvoríme novú tabuľku obsahujúcu informácie o zložení predmetov, z ktorých sa v skupinách študentov robia skúšky alebo testy. Ako kľúč vytvoríme pole „Počítadlo“, ktoré nastavuje číslo záznamu v tabuľke, keďže každý záznam musí byť jedinečný. tridsať
Výsledkom je nová štruktúra databázy, ktorá je znázornená na obr. 2.5 (kľúčové polia v každej tabuľke sú vyznačené tučným písmom). Táto štruktúra obsahuje sedem tabuliek, ktoré spĺňajú požiadavky tretej normálnej formy.
Boyceova normálna forma je Codd. Tabuľka je v normálnej Boyce-Coddovej forme iba vtedy, ak je akákoľvek funkčná závislosť medzi jej poľami zredukovaná na úplnú funkčnú závislosť od možného kľúča. Podľa tejto definície v štruktúre databázy (pozri obr. 2.4) všetky tabuľky spĺňajú požiadavky normálnej formy Boyes - Codd. Ďalšia optimalizácia databázových tabuliek by sa mala zredukovať na úplný rozklad tabuliek. Úplný rozklad tabuľky sa nazýva taká zbierka ľubovoľného počtu jej projekcií, ktorých spojenie sa úplne zhoduje s obsahom tabuľky. Projekcia je kópia tabuľky, ktorá neobsahuje jeden alebo viac stĺpcov novej tabuľky. Štvrtá normálna forma.Štvrtá normálna forma je špeciálnym prípadom piatej normálnej formy, keď úplný rozklad musí byť spojením dvoch projekcií.
31 Je veľmi ťažké nájsť tabuľku, ktorá je v štvrtej normálnej forme, ale nespĺňa definíciu piatej normálnej formy.
Piata normálna forma. Tabuľka je v piatej normálnej forme vtedy a len vtedy, ak všetky projekcie obsahujú možný kľúč v každej z jej úplných dekopozícií. Tabuľka, ktorá nemá úplný rozklad, je tiež v piatej normálnej forme. V praxi optimalizácia databázových tabuliek končí v tretej normálnej forme. Redukcia tabuliek na štvrtý a piaty normálny tvar je podľa nášho názoru čisto teoretická. V praxi sa tento problém rieši vývojom dotazov na vytvorenie novej tabuľky. 2.3. Navrhovanie vzťahov medzi tabuľkami Proces normalizácie počiatočných databázových tabuliek umožňuje vytvoriť optimálnu štruktúru informačného systému - vyvinúť databázu, ktorá vyžaduje najmenej pamäťových prostriedkov a v dôsledku toho poskytuje najkratší čas prístupu k informáciám. Rozdelenie jednej zdrojovej tabuľky na viacero si zároveň vyžaduje splnenie jednej z najdôležitejších podmienok pre návrh informačných systémov – zabezpečenie integrity informácií pri prevádzke databázy. Vo vyššie uvedenom príklade normalizácie pôvodných tabuliek (pozri obr. 2.3) sme z dvoch tabuliek nakoniec dostali sedem tabuliek zredukovaných na tretiu a štvrtú normálnu formu. Ako ukazuje prax, v reálnej výrobe a podnikaní sú databázy viacužívateľské systémy. To platí tak pre vytváranie a udržiavanie údajov v samostatných tabuľkách, ako aj pre používanie informácií na rozhodovanie. V uvedenom príklade v skutočne fungujúcom systéme riadenia vzdelávacieho procesu na univerzite alebo vysokej škole prvotné zostavenie študijných skupín vykonávajú prijímacie komisie pri zápise uchádzačov na základe výsledkov prijímacích skúšok. Ďalšie udržiavanie informácií o zložení študentov v skupinách na univerzitách je pridelené dekanátom a na vysokých školách - vzdelávacím oddeleniam alebo príslušným štruktúram. Zloženie akademických disciplín v skupinách určujú iné služby alebo špecialisti. Informácie o pedagogickom zbore sa tvoria na personálnych útvaroch. Výsledky skúšobných a skúšobných zasadnutí sú potrebné pre vedúcich dekanátu a katedier, a to aj na rozhodovanie o udelení štipendia 32 úspešným študentom alebo „odňatí štipendia“ neúspešným študentom. Akákoľvek zmena v ktorejkoľvek z tabuliek v databáze musí nájsť adekvátnu zmenu vo všetkých ostatných tabuľkách. Toto je podstata zabezpečenia integrity databázy. V praxi sa táto úloha vykonáva vytvorením väzieb medzi databázovými tabuľkami. Sformulujme základné pravidlá pre nadväzovanie vzťahov medzi tabuľkami. 1. Vyberte master a slave z dvoch prepojených tabuliek. 2. V každej tabuľke vyberte kľúčové pole. Volá sa kľúčové pole hlavnej tabuľky primárny kľúč. Volá sa kľúčové pole podriadenej tabuľky cudzí kľúč. 3. Polia viazanej tabuľky musia byť rovnakého typu údajov. 4. Medzi tabuľkami sú vytvorené tieto typy väzieb: „jedna k jednej“; Jeden k mnohým; Many-to-many: vzťah typu one-to-one sa vytvorí, keď je konkrétny riadok hlavnej tabuľky prepojený iba s jedným riadkom podriadenej tabuľky v akomkoľvek danom čase; vzťah typu one-to-many sa vytvorí v prípadoch, keď je v ktoromkoľvek danom čase konkrétny riadok hlavnej tabuľky
33 je spojená s viacerými riadkami podriadenej tabuľky; v tomto prípade je ľubovoľný riadok podriadenej tabuľky spojený iba s jedným riadkom hlavnej tabuľky; vzťah many-to-many vzniká v prípadoch, keď je určitý riadok hlavnej tabuľky kedykoľvek priradený k niekoľkým riadkom podriadenej tabuľky a súčasne jeden riadok podriadenej tabuľky je priradený k niekoľkým riadkom hlavnej tabuľky. tabuľky. Pri zmene hodnoty primárneho kľúča v hlavnej tabuľke sú možné nasledujúce správanie závislej tabuľky. Kaskádové. Keď sa zmenia údaje primárneho kľúča v hlavnej tabuľke, zmenia sa zodpovedajúce údaje cudzieho kľúča v závislej tabuľke. Všetky existujúce spojenia sú zachované. Obmedziť. Ak sa pokúsite zmeniť hodnotu primárneho kľúča priradeného k riadkom v závislej tabuľke, zmeny sa zahodia. Je povolené meniť iba tie hodnoty primárneho kľúča, pre ktoré nebolo vytvorené žiadne spojenie so závislou tabuľkou. Zriadenie (vzťah). Keď sa zmenia údaje primárneho kľúča, cudzí kľúč sa nastaví na nulovú hodnotu (NULL). Informácie o vlastníctve riadka pre závislú tabuľku sa stratia. Ak zmeníte niekoľko hodnôt primárneho kľúča, v závislej tabuľke sa vytvorí niekoľko skupín riadkov, ktoré boli predtým spojené so zmenenými kľúčmi. Potom nie je možné určiť, ktorý riadok bol priradený ku ktorému primárnemu kľúču. Na obr. 2.6 sú znázornené schémy prepojení medzi tabuľkami databázy znázornenej na obr. 2.5. Kontrolné otázky 1. Definujte nasledujúce prvky databázovej tabuľky: pole, bunka, záznam. 2. Čo znamenajú pojmy „kľúč“, „kľúčové pole“? 3. Ktoré pole kľúča sa nazýva primárny kľúč a ktoré cudzí kľúč? 4. Aký je proces normalizácie databázových tabuliek? 5. Akých päť normálnych foriem databázových tabuliek poznáte? 6. Definujte nasledujúce typy vzťahov medzi tabuľkami databázy: "one to one"; Jeden k mnohým; Mnoho-k-mnohým. Základné pojmy relačných databáz sú dátový typ, doména, atribút, n-tica, primárny kľúč a vzťah. Ukážme si význam týchto pojmov na príklade vzťahu ZAMESTNANCI, ktorý obsahuje informácie o zamestnancoch určitej organizácie:
1. Typ údajov
koncepcia Dátový typ v relačnom dátovom modeli je plne adekvátny konceptu dátového typu v programovacích jazykoch. Moderné relačné databázy zvyčajne umožňujú ukladanie znakov, číselných údajov, bitových reťazcov, špecializovaných číselných údajov (napríklad „peniaze“), ako aj špeciálnych „časových“ údajov (dátum, čas, časový interval). Aktívne sa rozvíja prístup k rozširovaniu možností relačných systémov s abstraktnými dátovými typmi (takéto možnosti majú napríklad systémy rodiny Ingres / Postgres). V našom príklade máme do činenia s tromi typmi údajov: znakové reťazce, celé čísla a peniaze.
2. Doména
koncepcia doménašpecifickejšie pre databázy, aj keď má určité analógie s podtypmi v niektorých programovacích jazykoch. Vo svojej najvšeobecnejšej forme je doména definovaná špecifikovaním nejakého základného dátového typu, ku ktorému patria prvky domény, a ľubovoľného logického výrazu aplikovaného na prvok dátového typu. Ak sa tento boolovský výraz vyhodnotí ako pravdivý, potom údajová položka je položkou domény. Najsprávnejšia intuitívna interpretácia pojmu doména je chápanie domény ako prípustného potenciálneho súboru hodnôt daného typu. Napríklad doména "Názvy" v našom príklade je definovaná na základnom type reťazcov znakov, ale jej hodnoty môžu zahŕňať iba tie reťazce, ktoré môžu reprezentovať meno (najmä takéto reťazce nemôžu začínať mäkkým znakom). Treba tiež poznamenať sémantické zaťaženie konceptu domény: údaje sa považujú za porovnateľné, iba ak patria do rovnakej domény. V našom príklade sú hodnoty pre domény „Čísla medzier“ a „Čísla skupín“ celočíselného typu, ale nie sú porovnateľné. Všimnite si, že väčšina relačných DBMS nepoužíva doménový koncept, hoci Oracle V.7 ho už podporuje.
3. Schéma vzťahov, schéma databázy
Schéma vzťahu je pomenovaná množina párov (názov atribútu, názov domény (alebo typ, ak pojem domény nie je podporovaný)). Stupeň alebo „arita“ schémy vzťahov je mohutnosťou tohto súboru. Stupeň vzťahu ZAMESTNANCI je štyri, čiže je 4-ročný. Ak sú všetky atribúty jedného vzťahu definované na rôznych doménach, má zmysel použiť na pomenovanie atribútov názvy zodpovedajúcich domén (samozrejme, nezabúdajme, že ide len o pohodlnú metódu pomenovania a neodstraňuje rozdiel medzi pojem domény a atribútu). DB schéma (v štrukturálnom zmysle) je množina pomenovaných schém vzťahov.
4. Tuple, vzťah
N-tica zodpovedajúca danej schéme vzťahu je množina párov (názov atribútu, hodnota), ktorá obsahuje jeden výskyt každého názvu atribútu patriaceho do schémy vzťahu. "Hodnota" je platná hodnota domény pre daný atribút (alebo typ údajov, ak pojem domény nie je podporovaný). Teda stupeň alebo „arita“ tuple, t.j. počet prvkov v ňom sa zhoduje s "aritou" zodpovedajúcej schémy vzťahov. Zjednodušene povedané, n-tica je zbierka pomenovaných hodnôt daného typu.
Vzťah je množina n-tic, ktoré zodpovedajú rovnakej schéme vzťahu. Niekedy, aby nedošlo k zámene, hovoria „relačná schéma“ a „vzťahová inštancia“, niekedy sa schéma vzťahu nazýva názvom vzťahu a vzťah ako množina n-tic sa nazýva telo vzťah. V skutočnosti sa koncept schémy vzťahov najviac približuje konceptu štruktúrovaného dátového typu v programovacích jazykoch. Bolo by celkom logické umožniť oddelené definovanie schémy vzťahov a potom jedného alebo viacerých vzťahov s touto schémou.
Obvyklou každodennou reprezentáciou vzťahu je tabuľka, ktorej názov je diagram vzťahu a riadky sú n-tice vzťahu inštancie; v tomto prípade názvy atribútov pomenúvajú stĺpce v tejto tabuľke. Preto sa niekedy hovorí „stĺpec tabuľky“, čo znamená „atribút vzťahu“. Relačná databáza je množina vzťahov, ktorých názvy sú rovnaké ako názvy schém vzťahov v schéme databázy.
Základné vlastnosti vzťahov
1. Žiadne duplicitné n-tice
Vlastnosť, že vzťah neobsahuje duplicitné n-tice, vyplýva z definície vzťahu ako množiny n-tic. V klasickej teórii množín sa podľa definície každá množina skladá z rôznych prvkov. Táto vlastnosť znamená, že každý vzťah má takzvaný primárny kľúč - súbor atribútov, ktorých hodnoty jednoznačne určujú n-ticu vzťahu. Pre každý vzťah má túto vlastnosť aspoň úplný súbor jeho atribútov. Pri formálnej definícii primárneho kľúča je však potrebné zabezpečiť, aby bol „minimálny“; súbor atribútov primárneho kľúča by nemal obsahovať také atribúty, ktoré možno zahodiť bez toho, aby bola dotknutá hlavná vlastnosť – jednoznačne identifikovať n-ticu. koncepcia primárny kľúč je mimoriadne dôležité v súvislosti s konceptom integrity databázy.
2.Nedostatok objednávania n-tic
Vlastnosť, že n-tice vzťahu nie sú usporiadané, je tiež dôsledkom definovania inštancie vzťahu ako množiny n-tic. Absencia požiadavky udržiavať poriadok na množine n-tic vzťahu dáva DBMS dodatočnú flexibilitu pri ukladaní databáz do externej pamäte a pri vykonávaní dotazov do databázy. To nie je v rozpore s tým, že pri formulovaní dotazu do databázy, napríklad v jazyku SQL, môžete požadovať triedenie výslednej tabuľky podľa hodnôt niektorých stĺpcov. Takýto výsledok vo všeobecnosti nie je relácia, ale nejaký usporiadaný zoznam n-tic.
3.Nedostatok zoradenia atribútov
Atribúty vzťahov nie sú usporiadané, pretože schéma vzťahov má podľa definície veľa párov (názov atribútu, názov domény). Názov atribútu sa vždy používa na označenie hodnoty atribútu v n-tici vzťahu. Táto vlastnosť teoreticky umožňuje napríklad upravovať schémy existujúcich vzťahov nielen pridávaním nových atribútov, ale aj odstraňovaním existujúcich atribútov. Vo väčšine existujúcich systémov však takáto možnosť nie je povolená, a hoci sa zoradenie množiny atribútov vzťahu výslovne nevyžaduje, často sa ich zoradenie v lineárnej forme definovania schémy vzťahu používa ako implicitné poradie vzťahu. atribúty.
4.Atomicita hodnôt atribútov.
Všetky hodnoty atribútov sú atómové. Vyplýva to z definície domény ako potenciálnej množiny hodnôt jednoduchého dátového typu, t.j. hodnoty domény nemôžu obsahovať množiny hodnôt (relácie). Je zvykom hovoriť, že v relačných databázach sú povolené iba normalizované vzťahy alebo vzťahy reprezentované v prvej normálnej forme.
Relačný dátový model. Podľa Date sa relačný model skladá z troch častí, ktoré popisujú rôzne aspekty relačného prístupu: štrukturálna časť, manipulačná časť a integrálna časť. V štrukturálnej časti modelu je zafixované, že jediná dátová štruktúra používaná v relačných databázach je normalizovaná n-árna relácia. Manipulačná časť modelu presadzuje dva základné mechanizmy na manipuláciu s relačnými databázami – relačná algebra a relačný kalkul. Prvý mechanizmus je založený hlavne na klasickej teórii množín (s určitými vylepšeniami) a druhý - na klasickom logickom aparáte predikátového počtu prvého rádu.
Integrita entity a odkazov. Napokon, v integrálnej časti relačného dátového modelu sú pevne stanovené dve základné požiadavky na integritu, ktoré musia byť podporované v akomkoľvek relačnej DBMS. Prvá požiadavka je tzv požiadavka integrity entity... Objekt alebo entita reálneho sveta v relačných databázach zodpovedá n-ticám vzťahov. Špecificky je požiadavka, aby akákoľvek n-tica akéhokoľvek vzťahu bola odlíšiteľná od akejkoľvek inej n-tice tohto vzťahu, t.j. inými slovami, každý vzťah musí mať primárny kľúč. Ako sme videli v predchádzajúcej časti, táto požiadavka je automaticky splnená, ak nie sú v systéme porušené základné vlastnosti vzťahu. Druhá požiadavka je tzv Požiadavka integrity podľa referencie a je o niečo zložitejšia. Je zrejmé, že ak sú vzťahy normalizované, komplexné entity reálneho sveta sú reprezentované v relačnej databáze vo forme niekoľkých n-tic niekoľkých vzťahov.
Relačné operácie a číslovanie.
Po návrhu relačného dátového modelu vytvoril E.F. Codd aj nástroj na pohodlnú prácu so vzťahmi – relačná algebra. Každá operácia tejto algebry používa jednu alebo viac tabuliek (relácií) ako svoje operandy a vo výsledku vytvára novú tabuľku, t.j. umožňuje "rezať" alebo "lepiť" tabuľky (obr. 3.3). 
Ryža. 3.3. Niektoré operácie relačnej algebry
Boli vytvorené jazyky na manipuláciu s údajmi, ktoré umožňujú implementovať všetky operácie relačnej algebry a takmer akúkoľvek ich kombináciu. Medzi nimi sú najbežnejšie SQL (Structured Query Language) a QBE (Quere-By-Example) [,]. Oba sú jazyky na veľmi vysokej úrovni, pomocou ktorých používateľ špecifikuje, aké údaje má získať, bez toho, aby špecifikoval postup ich získania. Jediným dotazom v ktoromkoľvek z týchto jazykov môžete spojiť viacero tabuliek do dočasnej tabuľky a vystrihnúť z nej požadované riadky a stĺpce (výber a projekcia).
Jazyková podpora databázy
Na prácu s databázou sa používajú špeciálne jazyky, všeobecne označované ako databázové jazyky.
V prvých databázach boli 2 jazyky:
1. Definičný jazyk pre schému databázy SDL.
2. jazyk na manipuláciu s údajmi DML.
Prvý z nich slúžil na definovanie logickej štruktúry databázy a druhý obsahoval sadu operátorov, ktoré umožňovali manipuláciu s údajmi, teda vstup do databázy a jej vymazanie. V moderných DBMS je väčšinou podporovaný jeden jazyk, obsahujúci všetky potrebné nástroje pre prácu s databázou. Tento jazyk umožňuje vytvoriť databázu a poskytnúť užívateľovi databázu.
Zďaleka najrozšírenejším jazykom je
Sštruktúrované
L jazyk
Tento jazyk podporuje a vytvára databázovú schému a umožňuje manipuláciu s týmito údajmi. Obsahuje všetky nástroje, ktoré potrebujete na zabezpečenie integrity vašej databázy. Tieto obmedzenia integrity sú obsiahnuté v špeciálnych adresároch, ktoré vám umožňujú riadiť integritu databázy na jazykovej úrovni. Špeciálne operátory jazyka SQL definujú takzvané pohľady na databázu. View - ϶ᴛᴏ dotazy, ktoré sú uložené v databáze. Pre používateľa je pohľad tabuľkou ϶ᴛᴏ, pomocou ktorej môžete obmedziť alebo rozšíriť viditeľnosť databázy pre konkrétneho používateľa údajov. Jazyk SQL obsahuje špeciálne operandy, ktoré poskytujú autorizáciu prístupu k databázovým objektom. Keďže rôzni používatelia majú rôzne oprávnenia na prácu s údajmi, sú tieto oprávnenia popísané v špeciálnych tabuľkách – katalógoch, ktoré sú podporované na jazykovej úrovni.
Základné pojmy relačných databáz sú: dátový typ, doména, atribút, n-tica, primárny kľúč, vzťah.
Dátový typ v relačnom modeli sa zvyčajne chápe ako rovnaký ako dátový typ v programovacích jazykoch, to znamená, že dátami môžu byť znakové, číselné, bitové reťazce, špeciálne číselné dáta (peniaze), ako aj špeciálne časové dáta (čas, dátum, časový interval).
Vo svojej najvšeobecnejšej podobe je doména určená špecifikovaním určitého základného dátového typu, do ktorého patria prvky tejto domény, pojem domény je jej chápanie ako prípustnej množnej hodnoty databázy. Doména má sémantické zaťaženie. Údaje sa považujú za porovnateľné, iba ak patria do rovnakej domény.
Je zvykom chápať n-ticu ako množinu párov databázových prvkov, ktoré obsahujú jeden výskyt každého semena atribútu v schéme vzťahu.
Schéma vzťahov - ϶ᴛᴏ pomenovaná množina párov prvkov. A v
tuple = atribút name͵ hodnota, to znamená, že tuple je kolekcia pomenovaných hodnôt daného typu.
Vzťah – ϶ᴛᴏ množina n-tic zodpovedajúcich nejakej schéme, teda relačnej databáze – ϶ᴛᴏ množina vzťahov, ktorých názvy sa zhodujú s názvami schém vzťahov v štruktúre databázy.
Relačné databázy sú v súčasnosti najrozšírenejšie, aj keď so všeobecne uznávanými výhodami majú aj množstvo nevýhod. Medzi výhody relačného prístupu patria:
Prítomnosť malého súboru abstrakcií, ktoré uľahčujú modelovanie väčšiny spoločných tematických oblastí a umožňujú presné formálne definície, pričom zostávajú intuitívne;
Prítomnosť jednoduchého a zároveň výkonného matematického aparátu, založeného najmä na teórii množín a matematickej logike a poskytujúceho teoretický základ pre relačný prístup k organizácii databáz;
Možnosť nenavigačnej manipulácie s dátami bez nutnosti poznať špecifickú fyzickú organizáciu databáz v externej pamäti.
Relačným systémom trvalo dlho, kým sa rozšírili. Zatiaľ čo hlavné teoretické výsledky v tejto oblasti boli dosiahnuté už v 70. rokoch a zároveň sa objavili prvé prototypy relačných DBMS, dlho sa považovalo za nemožné dosiahnuť efektívnu implementáciu takýchto systémov. Vyššie uvedené výhody a postupná akumulácia metód a algoritmov na organizáciu a správu relačných databáz však viedli k tomu, že v polovici 80. rokov relačné systémy prakticky vytlačili skoré DBMS zo svetového trhu.
V súčasnosti nie je hlavným predmetom kritiky relačných DBMS ich neefektívnosť, ale určité obmedzenia spojené s týmito systémami (priamy dôsledok jednoduchosti) pri použití v takzvaných netradičných oblastiach (najčastejšími príkladmi sú automatizácia návrhu systémy), ktoré si vyžadujú mimoriadne zložité dátové štruktúry. Ďalšou často uvádzanou nevýhodou relačných databáz je neschopnosť adekvátne odrážať sémantiku domény. Inými slovami, možnosti reprezentácie poznatkov o sémantických špecifikách domény v relačných systémoch sú veľmi obmedzené. Moderný výskum v oblasti postrelačných systémov sa venuje najmä precíznemu odstraňovaniu týchto nedostatkov.
Základné pojmy relačných databáz sú dátový typ, doména, atribút, n-tica, primárny kľúč a vzťah.
koncepcia Dátový typ v relačnom dátovom modeli je plne adekvátny konceptu dátového typu v programovacích jazykoch. Moderné relačné databázy zvyčajne umožňujú ukladanie znakov, číselných údajov, bitových reťazcov, špecializovaných číselných údajov (napríklad „peniaze“), ako aj špeciálnych „časových“ údajov (dátum, čas, časový interval). Aktívne sa rozvíja prístup k rozširovaniu možností relačných systémov s abstraktnými dátovými typmi (takéto možnosti majú napríklad systémy rodiny Ingres / Postgres).
Dátové štruktúry relačného modelu. Relačný dátový model organizuje a prezentuje dáta vo forme tabuliek alebo vzťahov. Relačný Je termín, ktorý pochádza z matematiky a označuje jednoduchú dvojrozmernú tabuľku. Relačný prístup k budovaniu databáz využíva terminológiu teórie vzťahov. Najjednoduchšia dvojrozmerná tabuľka je definovaná ako postoj.
tabuľky je hlavným typom dátovej štruktúry (objektu) relačného modelu. Štruktúra tabuľky je určená počtom obyvateľov stĺpci. Každý riadok tabuľky obsahuje jednu zodpovedajúcu hodnotu stĺpec. V tabuľke nemôžu byť dva rovnaké riadky. Celkový počet riadkov nie je obmedzený.
Stĺpec zhoduje sa s nejakou položkou údajov - atribút, čo je najjednoduchšia dátová štruktúra. Viaceré položky, skupinu alebo opakujúcu sa skupinu nemožno definovať v tabuľke, ako je to v sieťových a hierarchických modeloch diskutovaných vyššie. Každý stĺpec tabuľky musí mať názov zodpovedajúci dátový prvok (atribút).
Zavolá sa stĺpec tabuľky s hodnotami zodpovedajúceho atribútu doména, a reťazce s hodnotami rôznych atribútov - tuple.
Relačná tabuľka-vzťah. Na obr. 9 je znázornenie vzťahu relačnej tabuľky R... Formálna definícia vzťah R (relačná tabuľka) sa spolieha na svoju myšlienku domén D ja (stĺpce) a tuples K j (čiary). Vzťah R definovaný na množinách domén (D i) je podmnožinou Kartézsky (priamy) súčin domén D 1 * D 2 *… .. * D n
Tabuľka-vzťah(viď obr. 1) obsahuje stĺpce s názvami dátových prvkov - atribútov (A 1, A 2, ...). Hodnoty atribútov d sú v obsahovej časti tabuľky a tvoria riadky a stĺpce. Mnoho hodnôt atribútov v jednom stĺpci tvorí jeden doména D i... Mnoho hodnôt atribútov v jednom riadku tvorí jeden sprievod K j. Postoj R je tvorené množinou usporiadaných tuples.
R = (Кj), J = 1- m Кj = (d 1j, d 2 j,… d nj),
kde n je počet domén vzťahu; definuje rozmer vzťahu;
j je číslo n-tice;
m je celkový počet n-tic vo vzťahu spolučíslo vzťah.
Obr. 9. Relačná tabuľka-ilustrácia vzťahu
doména. Vo svojej najvšeobecnejšej forme je doména definovaná špecifikovaním nejakého základného dátového typu, ku ktorému patria prvky domény, a ľubovoľného logického výrazu aplikovaného na prvok dátového typu. Ak sa tento boolovský výraz vyhodnotí ako pravdivý, potom údajová položka je položkou domény.
Najsprávnejšia intuitívna interpretácia pojmu doména je chápanie domény ako prípustného potenciálneho súboru hodnôt daného typu. Napríklad doména "Názvy" v našom príklade je definovaná na základnom type reťazcov znakov, ale jej hodnoty môžu zahŕňať iba tie reťazce, ktoré môžu reprezentovať meno (najmä takéto reťazce nemôžu začínať mäkkým znakom).
Treba tiež poznamenať sémantické zaťaženie konceptu domény: údaje sa považujú za porovnateľné, iba ak patria do rovnakej domény. V našom príklade sú hodnoty pre domény „Čísla medzier“ a „Čísla skupín“ celočíselného typu, ale nie sú porovnateľné. Všimnite si, že väčšina relačných DBMS nepoužíva koncept domény, hoci Google V.7 ho už podporuje.
Schéma vzťahov, schéma databázy. Schéma vzťahu je pomenovaná množina párov (názov atribútu, názov domény (alebo typ, ak pojem domény nie je podporovaný)). Stupeň alebo „arita“ schémy vzťahov je mohutnosťou tohto súboru. Stupeň pomeru PRÍKLAD je SIX, to znamená, že je 6-árny. Ak sú všetky atribúty jedného vzťahu definované na rôznych doménach, má zmysel použiť na pomenovanie atribútov názvy zodpovedajúcich domén (samozrejme, nezabúdajme, že ide len o pohodlnú metódu pomenovania a neodstraňuje rozdiel medzi pojem domény a atribútu). DB schéma (v štrukturálnom zmysle) je množina pomenovaných schém vzťahov.
Zoznam, ktorý udáva názvy relačných tabuliek, zoznam ich atribútov (podčiarknuté kľúče) a definície cudzích kľúčov sa nazýva schéma relačnej databázy. Ide o predbežné zhrnutie tvorby štádia životného cyklu relačnej databázy. Príklad:
PRACOVNÍK [ ID PRACOVNÍKA, MENO, HODINOVÁ SADZBA, TYP ZRUČNOSTI, SVPV-ID]
Cudzie kľúče: SKILL-TYPE, na ktoré odkazuje SKILL
SVPV-ID s odkazom na PRACOVNÍK
ÚLOHA [ ID PRACOVNÍKA, BLDG-ID, ZAČIATOK, POČET DNÍ]
Cudzie kľúče: WORKER-ID s odkazom na WORKER
BLDG-ID, na ktoré odkazuje BVILDING
BVILDING [ BLDG-ID, ADRESS, TYPE, QLTY-LEVEL, STATVS]
ZRUČNOSŤ [ ZRUČNOSŤ- TYP, BONUSOVÁ SADZBA, HODINY ZA TÝŽDEŇ]
Tuple, vzťah. N-tica zodpovedajúca danej schéme vzťahu je množina párov (názov atribútu, hodnota, ktorá obsahuje jeden výskyt názvu každého atribútu patriaceho do schémy vzťahu. „Hodnota“ je platná hodnota domény pre daný atribút (alebo typ údajov, ak pojem domény nie je podporovaný). Stupeň alebo „arita“ n-tice, teda počet prvkov v nej, sa teda zhoduje s „aritou“ zodpovedajúcej schémy vzťahov.
Postoj Je množina n-tic zodpovedajúcich rovnakej schéme vzťahu. Niekedy, aby nedošlo k zámene, hovoria „relačná schéma“ a „vzťahová inštancia“, niekedy sa schéma vzťahu nazýva názvom vzťahu a vzťah ako množina n-tic sa nazýva telo vzťah. V skutočnosti sa koncept schémy vzťahov najviac približuje konceptu štruktúrovaného dátového typu v programovacích jazykoch. Bolo by celkom logické umožniť oddelené definovanie schémy vzťahov a potom jedného alebo viacerých vzťahov s touto schémou.
To však nie je prípad relačných databáz. Názov schémy vzťahu v takýchto databázach je vždy rovnaký ako názov zodpovedajúceho vzťahu inštancie. V klasických relačných databázach sa po definovaní databázovej schémy zmenia iba vzťahy inštancií. Môžu sa v nich objaviť nové n-tice a existujúce n-tice môžu byť odstránené alebo upravené. Mnohé implementácie však umožňujú aj zmenu schémy databázy: definovanie nových a úpravu existujúcich schém vzťahov. Toto sa zvyčajne nazýva vývoj databázovej schémy.
Obvyklou každodennou reprezentáciou vzťahu je tabuľka, ktorej názov je diagram vzťahu a riadky sú n-tice vzťahu inštancie; v tomto prípade názvy atribútov pomenúvajú stĺpce v tejto tabuľke. Preto sa niekedy hovorí „stĺpec tabuľky“, čo znamená „atribút vzťahu“. Keď sa dostaneme k praktickým otázkam organizácie a nástrojov správy relačných databáz, použijeme túto bežnú terminológiu. Túto terminológiu používa väčšina komerčných relačných DBMS.
Relačná databáza je množina vzťahov, ktorých názvy sú rovnaké ako názvy schém vzťahov v schéme databázy.
Ako vidíte, základné štrukturálne koncepty relačného dátového modelu (okrem konceptu domény) majú veľmi jednoduchú intuitívnu interpretáciu, hoci v teórii relačných databáz sú všetky definované absolútne formálne a presne.
Kľúč tabuľky vzťahov. Tuple sa vo vnútri nesmú opakovať tabuľky vzťahov a preto musia mať jedinečný identifikátor - primárny kľúč. Jeden alebo viac atribútov, ktorých hodnoty jedinečne identifikujú riadok tabuľky, sú kľúč tabuľky.
Primárny kľúč je tzv jednoduché , keď pozostáva z jedného atribútu, príp zložený, keď pozostáva z viacerých atribútov. Okrem primárneho kľúča môže vzťah obsahovať aj sekundárne kľúče.
Sekundárny kľúč – je to kľúč, ktorého hodnoty sa môžu opakovať v rôznych n-ticových reťazcoch. Môžu sa použiť na vyhľadávanie skupiny riadkov s rovnakou hodnotou sekundárneho kľúča.
Externý kľúč - je to množina atribútov z jednej tabuľky, ktorá je kľúčom inej (alebo tej istej) tabuľky. Cudzie kľúče poskytujú dôležité vzťahy medzi tabuľkami. Používajú sa na prepojenie údajov z jednej tabuľky s údajmi v inej tabuľke. Atribúty cudzieho kľúča nemusia mať rovnaké názvy ako atribúty kľúčov, ktorým zodpovedajú.
Podobné informácie.
RELAČNÁ DATABÁZA A JEJ VLASTNOSTI. TYPY VZŤAHOV MEDZI VZŤAHOVÝMI TABUĽKAMI
Relačná databáza je kolekcia vzájomne prepojených tabuliek, z ktorých každá obsahuje informácie o objektoch určitého typu. Riadok tabuľky obsahuje údaje o jednom objekte (napríklad produkt, zákazník) a stĺpce tabuľky popisujú rôzne charakteristiky týchto objektov - atribúty (napríklad názov, kód produktu, informácie o zákazníkovi). Záznamy, teda riadky tabuľky, majú rovnakú štruktúru – pozostávajú z polí, v ktorých sú uložené atribúty objektu. Každé pole, teda stĺpec, popisuje iba jednu charakteristiku objektu a má presne definovaný dátový typ. Všetky záznamy majú rovnaké polia, len zobrazujú iné informačné vlastnosti objektu.
V relačnej databáze musí mať každá tabuľka primárny kľúč – pole alebo kombináciu polí, ktoré jedinečne identifikujú každý riadok v tabuľke. Ak kľúč pozostáva z viacerých polí, nazýva sa zložený kľúč. Kľúč musí byť jedinečný a musí jednoznačne identifikovať položku. Hodnota kľúča sa môže použiť na nájdenie jedného záznamu. Kľúče sa tiež používajú na organizáciu informácií v databáze.
Tabuľky relačnej databázy musia spĺňať požiadavky na normalizáciu vzťahov. Normalizácia vzťahov je formálnym aparátom obmedzení tvorby tabuliek, ktorý eliminuje duplicitu, zabezpečuje konzistenciu tých, ktoré sú uložené v databáze, a znižuje mzdové náklady na údržbu databázy.
Nechajte si vytvoriť tabuľku Študent, ktorá obsahuje polia: číslo skupiny, celé meno, číslo študenta, dátum narodenia, prehadzovanie odborov, názov fakulty. Takáto organizácia ukladania informácií bude mať niekoľko nevýhod:
- duplikácia informácií (názov odboru a fakulty sa opakuje pre každého študenta), preto sa objem databázy zvýši;
- postup aktualizácie informácií v tabuľke je náročný, pretože je potrebné každú z nich upraviť tabuľkové záznamy.
Normalizácia tabuľky má tieto nedostatky vyriešiť. existuje tri normálne formy vzťahu.
Prvá normálna forma. Relačná tabuľka sa zredukuje na prvú normálnu formu vtedy a len vtedy, ak žiadny z jej riadkov neobsahuje viac ako jednu hodnotu v žiadnom z jej polí a žiadne z jej kľúčových polí nie je prázdne. Ak je teda potrebné z tabuľky Študent získať informácie o mene študenta, pole s úplným menom by sa malo rozdeliť na časti Priezvisko, Meno, Patronymum.
Druhá normálna forma... Relačná tabuľka je špecifikovaná v druhej normálnej forme, ak spĺňa požiadavky prvej normálnej formy a všetky jej polia, ktoré nie sú zahrnuté v primárnom kľúči, plne funkčne súvisia s primárnym kľúčom. Aby sa tabuľka dostala do druhej normálnej formy, je potrebné určiť funkčnú závislosť polí. Funkčná závislosť polí je závislosť, kedy v prípade informačného objektu iba jedna hodnota deskriptívneho atribútu zodpovedá určitej hodnote kľúčového atribútu.
Tretia normálna forma. Tabuľka je v tretej normálnej forme, ak spĺňa požiadavky druhej normálnej formy, žiadne z jej nekľúčových polí nie je funkčne závislé od žiadneho iného nekľúčového poľa. Napríklad v tabuľke Študent (číslo skupiny, celé meno, číslo ročníka, dátum narodenia, starosta) sú v prechodnom vzťahu tri polia - číslo ročníka, číslo skupiny, starosta. Číslo skupiny závisí od čísla ročníka a riaditeľ závisí od čísla skupiny. Na odstránenie tranzitívnej závislosti je potrebné preniesť časť polí tabuľky Študent do inej tabuľky Skupina. Tabuľky budú mať tento tvar: Žiak (číslo skupiny, celé meno, číslo ročníka, dátum narodenia), skupina (číslo skupiny, riaditeľ).
Na relačných tabuľkách sú možné nasledujúce operácie:
- Reťazenie tabuliek s rovnakou štruktúrou. Výsledkom je spoločná tabuľka: najprv prvá, potom druhá (reťazenie).
- Priesečník tabuliek s rovnakou štruktúrou. Výsledok - vyberú sa tie záznamy, ktoré sú v oboch tabuľkách.
- Odčítanie tabuliek s rovnakou štruktúrou. Výsledok - vyberú sa tie záznamy, ktoré nie sú v odčítaných.
- Vzorka (horizontálna podmnožina). Výsledok – vyberú sa záznamy, ktoré spĺňajú určité podmienky.
- Projekcia (vertikálna podmnožina). Výsledkom je relácia, ktorá obsahuje niektoré polia z pôvodných tabuliek.
- Kartézsky súčin dvoch tabuliek Záznamy výslednej tabuľky sa získajú spojením každého záznamu prvej tabuľky s každým záznamom druhej tabuľky.
Relačné tabuľky môžu byť navzájom prepojené, preto je možné údaje získavať z viacerých tabuliek súčasne. Tabuľky sú navzájom prepojené, aby sa v konečnom dôsledku zmenšila veľkosť databázy. Vzťah každej dvojice tabuliek je zabezpečený, ak majú rovnaké stĺpce.
Existujú nasledujúce typy informačných odkazov:
- jeden na jedného;
- jeden k mnohým;
- mnoho-k-mnohým.
Komunikácia jeden na jedného predpokladá, že jeden atribút prvej tabuľky sa zhoduje iba s jedným atribútom druhej tabuľky a naopak.
Vzťah jeden k mnohým predpokladá, že jeden atribút v prvej tabuľke zodpovedá niekoľkým atribútom v druhej tabuľke.
Vzťah medzi mnohými predpokladá, že jeden atribút prvej tabuľky zodpovedá niekoľkým atribútom druhej tabuľky a naopak.
