Úvod

Začiatok 21. storočia odborníci nazývajú storočím výpočtovej techniky. Ľudstvo vstupuje do zásadne novej informačnej éry. Všetky zložky životného štýlu ľudí sa menia. Informovanosť sa stáva jednou z charakteristík úrovne rozvoja štátu.

Mnohé rozvojové krajiny si na správnej úrovni uvedomili výhody, ktoré so sebou neprináša šírenie a rozvoj informačných a komunikačných technológií. A nikto nepochybuje o tom, že smerovanie k informačnej spoločnosti je akousi cestou, ktorá smeruje k budúcnosti ľudskej civilizácie.

Na základe relačného modelu je databáza špecifická zbierka tabuliek, na ktorých sa vykonávajú operácie, ktoré sú formulované z hľadiska relačnej algebry a relačného počtu.

V relačnom modeli majú operácie týkajúce sa databázových objektov teoretickú povahu množín a sú jadrom akejkoľvek databázy. Model predstavuje rôzne dátové štruktúry, obmedzenia integrity a operácie manipulácie s dátami.

Základné pojmy relačného dátového modelu

Hlavné pojmy charakteristické pre relačné údaje sú dátový typ, doména, atribút, n-tica, vzťah primárneho kľúča. Najprv si všimnime význam týchto pojmov na príklade vzťahu „ZAMESTNANCI“, ktorý obsahuje informácie o zamestnancoch určitej organizácie.

Pojem dátového typu je v relačnom dátovom modeli porovnateľný s konceptom dátového typu v programovacích jazykoch. V moderných relačných databázach sa ukladajú symbolické číselné údaje, bitové reťazce, ako aj špeciálne „časové“ údaje, ktoré sa pomerne aktívne vyvíjajú v procese približovania sa k rozširovaniu možností relačných systémov.

Pojem domény má určité špecifiká pre databázy, aj keď majú určitú antológiu s podtypmi vo vzťahu k niektorým programovacím jazykom. Vo všeobecnosti je doména definovaná špecifikovaním určitého základného typu, s ktorým súvisí element domény, a ľubovoľného logického výrazu, ktorý našiel uplatnenie v elemente dátového typu. Keď vyhodnotenie tohto boolovského výrazu poskytne pravdivý výsledok, prvok je prvkom domény.

Správnejšou interpretáciou pojmu domény je chápanie samotnej domény ako jednej z prípustných potenciálnych množín hodnôt daného typu.

Napríklad doména „Názvy“ je v našom prípade definovaná na základnom type znakového výrazu, ale počet jej hodnôt bude zahŕňať iba výrazy, ktoré sú schopné reprezentovať meno (takéto výrazy nemôžu začínať mäkkým znakom ). Je tiež potrebné poznamenať sémantické zaťaženie konceptu domény: iba v takom prípade budú údaje porovnateľné, keď sa budú vzťahovať na doménu, ale iba jeden

V našom prípade nemožno porovnávať hodnoty domén „Čísla medzier“ a „Čísla skupín“, ktoré súvisia s typom celé číslo. Všimnite si, že v niektorých prípadoch v relačných DBMS samotný pojem „doména“ nenájde uplatnenie, pretože už podporované v Oracle V.7.

Schéma vzťahov je nominálna množina párov: ktorá zahŕňa: názov atribútu, typ, ale iba v prípade, že koncept domény nie je podporovaný. Stupeň „šikovnosti“ predstavuje relačné schémy – to je určitá sila tohto súboru.

V tomto prípade sa vzťah „Zamestnanci“ bude rovnať štyrom a bude považovaný za štvorčlenný. A ak sú všetky atribúty jedného vzťahu definované na relatívne odlišných doménach, je rozumné použiť na pomenovanie atribútov názvy zodpovedajúcich domén, pričom netreba zabúdať, že sa to považuje len za jednu z vhodných metód pomenovania a neposkytuje príležitosť. eliminovať rozdiely týkajúce sa pojmu domény a atribútu. Databázová schéma je špecifický súbor relačných schém.

N-tica, ktorá zodpovedá danej schéme vzťahu, je množina párov, ktorá sa odráža vo výskyte každého názvu atribútu patriaceho do schémy vzťahu.

"Hodnota" sa považuje za platnú hodnotu domény pre daný atribút v prípade, že koncept domény nie je podporovaný. Výsledkom je, že stupeň tuple, t.j. počet definovaných prvkov sa zhoduje so stupňom zodpovedajúcej schémy vzťahov

N-tica je zbierka pomenovaných hodnôt daného typu.

Relácia je veľký počet n-tic, ktoré zodpovedajú jednej relačnej schéme. V skutočnosti je koncept schémy vzťahov bližšie ku konceptu štrukturálneho dátového typu v programovacích jazykoch bola hlava a vzťah ako množina ničiek bol telom vzťahu. Preto by bolo logické umožniť definovanie relačnej schémy oddelene a následne jedného alebo viacerých vzťahov touto schémou, čo však nie je akceptované v relačných databázach.

Názov schémy vzťahu vo vzťahu k takýmto databázam je vo väčšine prípadov 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 zmenené. Zároveň však v mnohých implementáciách dochádza k zmene databázovej schémy: k definovaniu nových a zmene existujúcich relačných schém, čo sa zvyčajne nazýva evolúcia databázovej schémy.

Obvyklou reprezentáciou vzťahu je tabuľka, ktorej hlavičkou je schéma vzťahu a riadky sú n-tice vzťahu inštancie, v tomto prípade sa názvy atribútov nazývajú stĺpce tejto tabuľky. V tejto súvislosti sa niekedy hovorí „stĺpec tabuľky“, čo znamená „atribút vzťahu“. 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.

Týmto článkom začíname novú sériu venovanú databázam, moderným technológiám na prístup a spracovanie údajov. Počas tohto cyklu plánujeme zvážiť najpopulárnejšie desktopové a serverové databázové systémy (DBMS), mechanizmy prístupu k údajom (OLD DB, ADO, BDE atď.) a nástroje pre prácu s databázami (administračné nástroje, generátory reportov, grafické nástroje prezentácia údajov). Okrem toho plánujeme venovať pozornosť metódam zverejňovania údajov na internete, ako aj tak populárnym metódam spracovania a uchovávania údajov, akými sú OLAP (On-Line Analytical Processing) a vytváranie dátových skladov (Data Warehousing).

V tomto článku sa pozrieme na základné pojmy a princípy, ktoré sú základom systémov správy databáz. Preberieme relačný dátový model, koncept referenčnej integrity a princípy normalizácie dát, ako aj nástroje na návrh dát. Potom vysvetlíme, čo sú to DBMS, aké objekty môžu byť obsiahnuté v databázach a ako sa na tieto objekty robia dopyty.

Základné koncepty relačnej databázy

Začnime základnými pojmami DBMS a krátkym úvodom do teórie relačných databáz – dnes najpopulárnejšej metódy ukladania dát.

Relačný dátový model

Relačný dátový model navrhol Dr. E.F. Codd, renomovaný databázový výskumník, v roku 1969, keď bol zamestnancom IBM. Základné koncepty tohto modelu boli prvýkrát publikované v roku 1970. „A Relational Model of Data for Large Shared Data Banks“, CACM, 1970, 13 N 6).

Relačná databáza je dátový sklad obsahujúci množinu dvojrozmerných tabuliek. Súbor nástrojov na správu takéhoto úložiska je tzv systém správy relačných databáz (RDBMS). RDBMS môže obsahovať pomocné programy, aplikácie, služby, knižnice, nástroje na vytváranie aplikácií a ďalšie komponenty.

Každá tabuľka relačnej databázy pozostáva z linky(tiež nazývaný záznamy) A stĺpci(tiež nazývaný poliach). V tejto sérii budeme používať obe dvojice výrazov.

Riadky tabuľky obsahujú informácie o skutočnostiach v nej uvedených (alebo dokumentoch alebo ľuďoch, jedným slovom - o objektoch rovnakého typu). Na priesečníku stĺpca a riadka sú konkrétne hodnoty údajov obsiahnutých v tabuľke.

Údaje v tabuľkách spĺňajú nasledujúce zásady:

1. Každá hodnota obsiahnutá v priesečníku riadka a stĺpca musí byť atómový(teda nerozdelené na viacero hodnôt).
2. Hodnoty údajov v rovnakom stĺpci musia patriť do rovnakého typu, ktorý je k dispozícii na použitie v danom DBMS.
3. Každý záznam v tabuľke je jedinečný, to znamená, že v tabuľke nie sú dva záznamy s úplne zhodnou množinou hodnôt pre jeho polia.
4. Každé pole má jedinečný názov.
5. Poradie polí v tabuľke nie je dôležité.
6. Poradie záznamov je tiež nepodstatné.

Napriek skutočnosti, že riadky tabuľky sa považujú za neusporiadané, každý systém správy databáz vám umožňuje triediť riadky a stĺpce vo výberoch podľa potreby používateľa.

Keďže poradie stĺpcov v tabuľke nie je dôležité, odkazuje sa na ne podľa názvu a tieto názvy sú jedinečné pre danú tabuľku (ale nemusia byť jedinečné pre celú databázu).

Takže teraz vieme, že relačné databázy sa skladajú z tabuliek. Na ilustráciu niektorých teoretických bodov a na vytvorenie príkladov musíme vybrať nejaký druh databázy. Aby sme „neobjavili koleso“, budeme používať databázu NorthWind, ktorá je súčasťou Microsoft SQL Server a Microsoft Access.

Teraz sa pozrime na vzťahy medzi tabuľkami.

Kľúče a pripojenia

Pozrime sa na úryvok tabuľky Zákazníci z databázy NorthWind (odstránili sme polia, ktoré nie sú nevyhnutné na znázornenie vzťahov medzi tabuľkami).

Keďže riadky v tabuľke nie sú zoradené, potrebujeme stĺpec (alebo množinu stĺpcov) na jedinečnú identifikáciu každého riadka. Takýto stĺpec (alebo množina stĺpcov) sa nazýva primárny kľúč (primárny kľúč). Primárny kľúč každej tabuľky musí obsahovať jedinečné neprázdne hodnoty pre každý riadok.

Ak má primárny kľúč viac ako jeden stĺpec, volá sa zložený primárny kľúč (zložený primárny kľúč).

Typická databáza zvyčajne pozostáva z niekoľkých súvisiacich tabuliek. Fragment tabuľky Objednávky.

Pole CustomerID tejto tabuľky obsahuje ID zákazníka, ktorý zadal objednávku. Ak chceme poznať názov spoločnosti, ktorá zadala objednávku, musíme vyhľadať rovnakú hodnotu ID zákazníka v poli CustomerID tabuľky Customers a prečítať hodnotu poľa CompanyName v nájdenom riadku. Inými slovami, potrebujeme prepojiť dve tabuľky, Zákazníci a Objednávky, pomocou poľa CustomerID. Zavolá sa stĺpec, ktorý ukazuje na záznam v inej tabuľke, ktorá súvisí s daným záznamom cudzí kľúč (cudzí kľúč). Ako vidíte, v prípade tabuľky Objednávky je cudzím kľúčom stĺpec CustomerID (obr. 1).

Inými slovami, cudzí kľúč je stĺpec alebo množina stĺpcov, ktorých hodnoty sa zhodujú s existujúcimi hodnotami primárneho kľúča inej tabuľky.

Tento vzťah medzi tabuľkami sa nazýva komunikácia (vzťah). Vzťah medzi dvoma tabuľkami sa vytvorí priradením hodnôt cudzieho kľúča jednej tabuľky k hodnotám primárneho kľúča druhej tabuľky.

Ak každý zákazník v tabuľke Zákazníci môže zadať iba jednu objednávku, hovorí sa, že tieto dve tabuľky súvisia jeden na jedného (vzťah jeden k jednému). Ak každý zákazník v tabuľke Zákazníci môže zadať nulu, jednu alebo veľa objednávok, hovorí sa, že tieto dve tabuľky súvisia jeden k mnohým (vzťah jeden k mnohým) alebo pomer master-detail. Najčastejšie sa používajú podobné vzťahy medzi tabuľkami. V tomto prípade sa volá tabuľka obsahujúca cudzí kľúč podrobná tabuľka a volá sa tabuľka obsahujúca primárny kľúč, ktorý definuje možné hodnoty cudzieho kľúča majstrovský stôl.

Nazýva sa skupina súvisiacich tabuliek schémy Databáza ( databázová schéma). Informácie o tabuľkách, ich stĺpcoch (názvy, typ údajov, dĺžka poľa), primárnych a cudzích kľúčoch, ako aj iných databázových objektoch sú tzv. metaúdaje (metaúdaje).

Akákoľvek manipulácia s údajmi v databázach, ako je výber, vkladanie, mazanie, aktualizácia údajov, zmena alebo výber metadát, sa nazýva žiadosť do databázy ( dopyt). Dotazy sú zvyčajne formulované v nejakom jazyku, ktorý môže byť štandardný pre rôzne DBMS alebo môže závisieť od konkrétneho DBMS.

Referenčná integrita

Už sme povedali vyššie, že primárny kľúč akejkoľvek tabuľky musí obsahovať jedinečné neprázdne hodnoty pre danú tabuľku. Toto vyhlásenie je jedným z pravidiel referenčná integrita (referenčná integrita). Niektoré (ale nie všetky) DBMS môžu kontrolovať jedinečnosť primárnych kľúčov. Ak DBMS kontroluje jedinečnosť primárnych kľúčov, potom ak sa pokúsite priradiť hodnotu primárnemu kľúču, ktorý už existuje v inom zázname, DBMS vygeneruje diagnostickú správu, ktorá zvyčajne obsahuje frázu porušenie primárneho kľúča. Túto správu je možné neskôr preniesť do aplikácie, prostredníctvom ktorej koncový používateľ s údajmi manipuluje.

Ak sú dve tabuľky spojené vzťahom master-detail, externý kľúč detail- tabuľka by mala obsahovať iba tie hodnoty, ktoré už existujú medzi hodnotami primárneho kľúča majster- tabuľky. Ak správnosť hodnôt cudzieho kľúča nie je kontrolovaná DBMS, môžeme hovoriť o porušení referenčnej integrity. V tomto prípade, ak vymažeme záznam z tabuľky Zákazníci, ku ktorému je priradený aspoň jeden detail- v tabuľke Objednávky, to povedie k tabuľke Objednávky, ktorá obsahuje záznamy o objednávkach zadaných niekým neznámym. Ak DBMS kontroluje správnosť hodnôt cudzích kľúčov, potom keď sa pokúsite priradiť hodnotu cudziemu kľúču, ktorý nie je medzi hodnotami primárnych kľúčov hlavnej tabuľky, alebo keď odstránite alebo upravíte záznamov v hlavnej tabuľke, čo vedie k narušeniu referenčnej integrity, DBMS vygeneruje diagnostickú správu, ktorá zvyčajne obsahuje frázu porušenie cudzieho kľúča, ktoré možno neskôr odovzdať používateľskej aplikácii.

Väčšina moderných DBMS, ako napríklad Microsoft Access 97, Microsoft Access 2000 a Microsoft SQL Server 7.0, je schopná monitorovať súlad s pravidlami referenčnej integrity, ak sú nejaké v databáze popísané. Na tento účel takéto DBMS využívajú rôzne databázové objekty (rozoberieme si ich trochu neskôr). V tomto prípade budú všetky pokusy o porušenie pravidiel referenčnej integrity potlačené súčasným generovaním diagnostických správ alebo výnimiek ( databázové výnimky).

Úvod do normalizácie údajov

Proces návrhu dát je definovanie metadát v súlade s cieľmi informačného systému, v ktorom bude budúca databáza použitá. Podrobnosti o tom, ako analyzovať oblasť predmetu a vytvárať diagramy vzťahov medzi entitami ( ERD - entitno-relačné diagramy) a dátové modely sú nad rámec tohto cyklu. Záujemcovia o túto problematiku môžu odkázať napríklad na knihu K. J. Date „Úvod do databázových systémov“ (Dialectics, Kyiv, 1998).

V tomto článku rozoberieme len jeden zo základných princípov návrhu dát – princíp normalizácie.

Normalizácia je proces reorganizácie údajov odstránením opakujúcich sa skupín a iných rozporov v ukladaní údajov, aby sa tabuľky dostali do formy, ktorá umožňuje konzistentnú a správnu úpravu údajov.

Teória normalizácie je založená na koncepte normálnych foriem. O tabuľke sa hovorí, že je v danej normálnej forme, ak spĺňa určitý súbor požiadaviek. Teoreticky existuje päť normálnych foriem, ale v praxi sa zvyčajne používajú iba prvé tri. Navyše, prvé dve normálne formy sú v podstate medzikrokmi na uvedenie databázy do tretej normálnej formy.

Prvá normálna forma

Ilustrujme proces normalizácie na príklade s použitím údajov z databázy NorthWind. Predpokladajme, že všetky objednané produkty zaznamenáme do nasledujúcej tabuľky. Štruktúra tejto tabuľky je nasledovná (obr. 2).

Aby tabuľka vyhovovala prvej normálnej forme, všetky jej hodnoty polí musia byť atómové a

všetky záznamy sú jedinečné. Preto je každá relačná tabuľka, vrátane tabuľky OrderedProducts, podľa definície už v prvej normálnej forme.

Táto tabuľka však obsahuje nadbytočné údaje, napríklad rovnaké informácie o zákazníkovi sa opakujú v zázname pre každý objednaný produkt. Redundancia údajov má za následok anomálie úpravy údajov – problémy, ktoré sa vyskytujú pri pridávaní, zmene alebo odstraňovaní záznamov. Napríklad pri úprave údajov v tabuľke OrderedProducts sa môžu vyskytnúť nasledujúce problémy:

• Konkrétna adresa zákazníka môže byť obsiahnutá v databáze len vtedy, keď si zákazník objednal aspoň jeden produkt.
• Keď vymažete záznam o objednanom produkte, súčasne sa vymažú informácie o samotnej objednávke a o zákazníkovi, ktorý ju zadal.
• Ak, nedajbože, zákazník zmení adresu, všetky záznamy o produktoch, ktoré si objednal, bude musieť aktualizovať.

Niektoré z týchto problémov možno vyriešiť zarovnaním databázy druhá normálna forma.

Druhá normálna forma

Hovorí sa, že existuje relačná tabuľka druhá normálna forma, ak je v prvej normálnej forme a jej nekľúčové polia úplne závislý z celého primárneho kľúča.

Tabuľka OrderedProducts je v prvej normálnej forme, ale nie v druhej normálnej forme, pretože polia CustomerID, Address a OrderDate závisia iba od poľa OrderID, ktoré je súčasťou zloženého primárneho kľúča (OrderID, ProductID).

Ak chcete prejsť z prvej normálnej formy do druhej normálnej formy, musíte postupovať podľa týchto krokov:

1. Určte, na ktoré časti možno primárny kľúč rozdeliť, aby niektoré nekľúčové polia záviseli od jednej z týchto častí ( tieto časti nemusia pozostávať z jedného stĺpca!).
2. Vytvorte novú tabuľku pre každú takúto časť kľúča a skupinu polí, ktoré od nej závisia a presuňte ich do tejto tabuľky. Časť pôvodného primárneho kľúča sa stane primárnym kľúčom novej tabuľky.
3. Odstráňte polia zo zdrojovej tabuľky, ktoré boli presunuté do iných tabuliek, okrem tých, ktoré sa stanú cudzími kľúčmi.

Napríklad, ak chcete preniesť tabuľku OrderedProducts do druhej normálnej formy, musíte presunúť polia CustomerID, Address a OrderDate do novej tabuľky (nazvime to OrdersInfo) a pole OrderID sa stane primárnym kľúčom novej tabuľky (obr. 3).

Vo výsledku budú nové tabuľky vyzerať takto. Avšak tabuľky, ktoré sú v druhej normálnej forme, ale nie v tretej normálnej forme, stále obsahujú anomálie modifikácie údajov. Tu sú napríklad pre tabuľku OrdersInfo:

• Konkrétna adresa zákazníka môže byť stále obsiahnutá v databáze len vtedy, keď si zákazník objednal aspoň jeden produkt.
• Odstránenie položky objednávky v tabuľke OrdersInfo bude mať za následok vymazanie položky pre samotného zákazníka.
• Ak zákazník zmenil adresu, bude potrebné aktualizovať viacero záznamov (aj keď ich je spravidla menej ako v predchádzajúcom prípade).

Tieto anomálie je možné eliminovať presťahovaním sa do tretia normálna forma.

Tretia normálna forma

Hovorí sa, že existuje relačná tabuľka tretia normálna forma, ak je v druhej normálnej forme a všetky jeho nekľúčové polia závisia len od primárneho kľúča.

Tabuľka OrderDetails je už v tretej normálnej forme. Nekľúčové pole Množstvo je úplne závislé od zloženého primárneho kľúča (ID objednávky, ID produktu). Tabuľka OrdersInfo však nie je v tretej normálnej forme, pretože obsahuje závislosť medzi nekľúčovými poľami (tzv. tranzitívna závislosť- tranzitívna závislosť) - pole Adresa závisí od poľa CustomerID.

Ak chcete prejsť z druhej normálnej formy do tretej normálnej formy, musíte postupovať podľa týchto krokov:

• Definujte všetky polia (alebo skupiny polí), od ktorých závisia ostatné polia.
• Pre každé takéto pole (alebo skupinu polí) a skupinu polí, ktoré sú na ňom závislé, vytvorte novú tabuľku a presuňte ich do tejto tabuľky. Pole (alebo skupina polí), od ktorých závisia všetky ostatné presunuté polia, sa stane primárnym kľúčom novej tabuľky.
• Odstráňte presunuté polia z pôvodnej tabuľky a ponechajte iba tie, ktoré sa stanú cudzími kľúčmi.

Ak chcete preniesť tabuľku OrdersInfo do tretej normálnej formy, vytvorte novú tabuľku Customers a presuňte do nej polia CustomerID a Address. Zo zdrojovej tabuľky odstránime pole Adresa, pole CustomerID ponecháme – teraz je to cudzí kľúč (obr. 4).

Takže po prevedení pôvodnej tabuľky do tretej normálnej formy boli tri tabuľky - Zákazníci, Objednávky a Podrobnosti objednávky.

Výhody normalizácie

Normalizácia eliminuje redundanciu údajov, čo umožňuje znížiť množstvo uložených údajov a zbaviť sa anomálií zmien údajov popísaných vyššie. Napríklad po redukcii databázy diskutovanej vyššie na tretiu normálnu formu sú zrejmé nasledujúce zlepšenia:

• Údaje o adrese zákazníka môžu byť uložené v databáze, aj keď ide len o potenciálneho zákazníka, ktorý ešte nezadal objednávku.
• Informácie o objednanom produkte môžete vymazať bez obáv z vymazania informácií o zákazníkovi a objednávke.

Zmena adresy zákazníka alebo dátumu registrácie objednávky teraz vyžaduje iba zmenu jedného záznamu.

Ako sú navrhnuté databázy

Moderné DBMS zvyčajne obsahujú nástroje, ktoré vám umožňujú vytvárať tabuľky a kľúče. Existujú aj pomocné programy dodávané oddelene od DBMS (a dokonca obsluhujúce niekoľko rôznych DBMS súčasne), ktoré vám umožňujú vytvárať tabuľky, kľúče a vzťahy.

Ďalším spôsobom vytvárania tabuliek, kľúčov a vzťahov v databáze je napísanie takzvaného DDL skriptu (DDL – Data Definition Language; povieme si o ňom trochu neskôr).

Napokon je tu ešte jeden spôsob, ktorý sa stáva čoraz obľúbenejším – používanie špeciálnych nástrojov nazývaných CASE tools (CASE je skratka pre Computer-Aided System Engineering). Existuje niekoľko typov nástrojov CASE, ale najčastejšie používanými nástrojmi na vytváranie databáz sú diagramy entít a vzťahov (E/R diagramy). Pomocou týchto nástrojov, tzv logické dátový model, ktorý popisuje skutočnosti a objekty, ktoré sa v ňom majú evidovať (v takýchto modeloch sa prototypy tabuliek nazývajú entity a polia sa nazývajú ich atribúty po vytvorení vzťahov medzi entitami, definovaní atribútov a vykonaní normalizácie, tzv fyzické dátový model pre konkrétny DBMS, v ktorom sú definované všetky tabuľky, polia a iné databázové objekty. Potom môžete vygenerovať buď samotnú databázu alebo skript DDL na jej vytvorenie.

Zoznam momentálne najpopulárnejších nástrojov CASE.

Tabuľky a polia

Tabuľky sú podporované všetkými relačnými DBMS a ich polia môžu ukladať údaje rôznych typov. Najbežnejšie typy údajov.

Indexy

O niečo vyššie sme hovorili o úlohe primárneho a cudzieho kľúča. Vo väčšine relačných DBMS sú kľúče implementované pomocou objektov nazývaných indexy, ktoré možno definovať ako zoznam čísiel záznamov označujúcich, v akom poradí sa majú poskytnúť.

Už vieme, že záznamy v relačných tabuľkách nie sú usporiadané. Každý záznam v určitom časovom bode má však veľmi špecifické fyzické umiestnenie v databázovom súbore, hoci sa to môže zmeniť počas procesu úpravy údajov alebo v dôsledku „interných aktivít“ samotného DBMS.

Predpokladajme, že v určitom okamihu boli záznamy v tabuľke Zákazníci uložené v tomto poradí.

Povedzme, že potrebujeme získať tieto údaje zoradené podľa poľa CustomerID. Ak vynecháme technické detaily, môžeme povedať, že index v tomto poli je postupnosť čísel záznamov, podľa ktorých je potrebné ich zobraziť, to znamená:

1,6,4,2,5,3

Ak chceme záznamy zoradiť podľa poľa Adresa, poradie čísel záznamov bude iné:

5,4,1,6,2,3

Ukladanie indexov vyžaduje podstatne menej miesta ako ukladanie inak zoradených verzií samotnej tabuľky.

Ak potrebujeme nájsť údaje o zákazníkoch, ktorých CustomerID začína znakmi „BO“, môžeme pomocou indexu nájsť umiestnenie týchto záznamov (v tomto prípade 2 a 5 (samozrejme, v indexe čísla týchto záznamov idú za sebou ), a potom presne prečítať druhý a piaty záznam namiesto skenovania celej tabuľky. Použitie indexov teda skracuje čas získavania údajov.

Už sme povedali, že fyzické umiestnenie záznamov sa môže zmeniť počas procesu úpravy údajov používateľmi, ako aj v dôsledku manipulácií s databázovými súbormi, ktoré vykonáva samotný DBMS (napríklad kompresia údajov, zber odpadu atď.). ). Ak sa v indexe vyskytnú zodpovedajúce zmeny, zavolá sa podporované a takéto indexy sa používajú vo väčšine moderných DBMS. Implementácia takýchto indexov vedie k tomu, že akákoľvek zmena v údajoch v tabuľke znamená zmenu v indexoch, ktoré sú s ňou spojené, a to zvyšuje čas, ktorý DBMS potrebuje na vykonanie takýchto operácií. Preto by ste pri používaní takýchto DBMS mali vytvárať iba tie indexy, ktoré sú skutočne potrebné, a riadiť sa tým, s ktorými dotazmi sa budete stretávať najčastejšie.

Obmedzenia a pravidlá

Väčšina moderných serverových DBMS obsahuje špeciálne objekty tzv obmedzenia(obmedzenia), príp pravidlá(pravidlá). Tieto objekty obsahujú informácie o obmedzeniach na možné hodnoty polí. Napríklad pomocou takéhoto objektu môžete nastaviť maximálnu alebo minimálnu hodnotu pre dané pole a potom vám DBMS nedovolí uložiť záznam do databázy, ktorý túto podmienku nespĺňa.

Okrem obmedzení spojených s nastavením rozsahu zmien údajov existujú aj referenčné obmedzenia (napríklad vzťah master-detail medzi tabuľkami Customers a Orders môže byť implementovaný ako obmedzenie vyžadujúce, aby hodnota poľa CustomerId (cudzie) kľúč) v tabuľke Objednávky sa rovnajú jednej z existujúcich hodnôt poľa CustomerId tabuľky Zákazníci.

Upozorňujeme, že nie všetky DBMS podporujú obmedzenia. V tomto prípade môžete buď použiť iné objekty (napríklad spúšťače) na implementáciu podobných funkcií pravidiel, alebo uložiť tieto pravidlá v klientskych aplikáciách, ktoré pracujú s touto databázou.

zastupovanie

Takmer všetky relačné DBMS podporujú pohľady. Tento objekt je virtuálna tabuľka, ktorá poskytuje údaje z jednej alebo viacerých reálnych tabuliek. V skutočnosti neobsahuje žiadne údaje, len popisuje ich zdroj.

Takéto objekty sa často vytvárajú na ukladanie zložitých dopytov v databázach. Zobrazenie je v skutočnosti uložený dotaz.

Vytváranie pohľadov vo väčšine moderných DBMS sa vykonáva pomocou špeciálnych vizuálnych nástrojov, ktoré vám umožňujú zobraziť potrebné tabuľky na obrazovke, nadviazať medzi nimi spojenia, vybrať zobrazené polia, zaviesť obmedzenia na záznamy atď.

Tieto objekty sa často používajú na zabezpečenie údajov, napríklad tým, že umožňujú prezeranie údajov cez ne bez priameho prístupu k tabuľkám. Niektoré objekty zobrazenia môžu navyše vracať rôzne údaje v závislosti napríklad od používateľského mena, čo mu umožňuje prijímať iba údaje, ktoré ho zaujímajú.

Spúšťače a uložené procedúry

Spúšťače a uložené procedúry, podporované vo väčšine moderných serverových DBMS, sa používajú na ukladanie spustiteľného kódu.

Uložená procedúra je špeciálny typ procedúry, ktorú vykonáva databázový server. Uložené procedúry sú napísané v procedurálnom jazyku, ktorý závisí od konkrétneho DBMS. Môžu sa navzájom volať, čítať a upravovať údaje v tabuľkách a môžu byť volané z klientskej aplikácie, na ktorej je spustená databáza.

Uložené procedúry sa zvyčajne používajú na vykonávanie často sa vyskytujúcich úloh (napríklad zosúladenie súvahy). Môžu mať argumenty, návratové hodnoty, chybové kódy a niekedy aj množiny riadkov a stĺpcov (táto množina údajov sa niekedy nazýva množina údajov). Posledný typ procedúr však nie je podporovaný všetkými DBMS.

Spúšťače obsahujú aj spustiteľný kód, ale na rozdiel od procedúr ich nemožno volať z klientskej aplikácie alebo uloženej procedúry. Spúšťač je vždy priradený ku konkrétnej tabuľke a je spustený, keď sa počas úpravy tabuľky vyskytne udalosť, ku ktorej je priradený (napríklad vloženie, vymazanie alebo aktualizácia záznamu).

Vo väčšine DBMS, ktoré podporujú spúšťače, môžete definovať viacero spúšťačov, ktoré sa vykonajú, keď nastane rovnaká udalosť, a určiť poradie vykonávania.

Objekty na generovanie primárnych kľúčov

Primárne kľúče veľmi často generuje samotný DBMS. Je to pohodlnejšie ako ich generovanie v klientskej aplikácii, pretože pri práci s viacerými používateľmi je generovanie kľúčov pomocou DBMS jediným spôsobom, ako sa vyhnúť duplikácii kľúčov a získať ich sekvenčné hodnoty.

Rôzne DBMS používajú na generovanie kľúčov rôzne objekty. Niektoré z týchto objektov ukladajú celé číslo a pravidlá, podľa ktorých sa generuje ďalšia hodnota, zvyčajne pomocou spúšťačov. Takéto objekty sú podporované napríklad v Oracle (v tomto prípade sa nazývajú sekvencie) a v IB Database (v tomto prípade sa nazývajú generátory).

Niektoré DBMS podporujú špeciálne typy polí pre primárne kľúče. Pri pridávaní záznamov sa tieto polia automaticky vyplnia postupnými hodnotami (zvyčajne celými číslami). V prípade Microsoft Access a Microsoft SQL Server sa takéto polia nazývajú polia identity a v prípade Corel Paradox sa nazývajú polia automatického prírastku.

Používatelia a roly

Zabránenie neoprávnenému prístupu k údajom je vážny problém, ktorý možno riešiť rôznymi spôsobmi. Najjednoduchšia je ochrana heslom buď celej tabuľky, alebo niektorých jej polí (tento mechanizmus podporuje napr. Corel Paradox).

V súčasnosti je populárnejší iný spôsob ochrany údajov – vytváranie zoznamu používateľov s používateľskými menami a heslami. V tomto prípade je akýkoľvek databázový objekt vo vlastníctve konkrétneho používateľa a tento používateľ udeľuje ostatným používateľom povolenie na čítanie alebo úpravu údajov z tohto objektu alebo na úpravu samotného objektu. Táto metóda sa používa na všetkých serveroch a niektorých desktopových DBMS (napríklad Microsoft Access).

Niektoré DBMS, hlavne serverové, podporujú nielen zoznam užívateľov, ale aj roly. Rola je súbor privilégií. Ak konkrétny užívateľ získa jednu alebo viac rolí a s nimi aj všetky privilégiá definované pre túto rolu.

Databázové dotazy

Modifikácia a výber údajov, zmena metadát a niektoré ďalšie operácie sa vykonávajú pomocou dopytov. Väčšina moderných DBMS (a niektoré nástroje na vývoj aplikácií) obsahuje nástroje na generovanie takýchto dopytov.

Jeden spôsob manipulácie s údajmi sa nazýva „dotazy podľa príkladu“ (QBE). QBE je nástroj na vizuálne prepojenie tabuliek a výber polí, ktoré sa majú zobraziť vo výsledku dotazu.

Vo väčšine DBMS (s výnimkou niektorých desktopových) vedie vizuálna konštrukcia dotazu pomocou QBE ku generovaniu textu dotazu pomocou špeciálneho dotazovacieho jazyka SQL (Structured Query Language). Dotaz môžete napísať aj priamo v SQL.

Kurzory

Výsledkom dotazu je často množina riadkov a stĺpcov (množina údajov). Na rozdiel od relačnej tabuľky sú riadky v takejto množine usporiadané a ich poradie je určené pôvodným dotazom (a niekedy aj prítomnosťou indexov). Preto môžeme v takejto množine definovať aktuálny riadok a ukazovateľ naň, ktorý sa nazýva kurzor.

Väčšina moderných DBMS podporuje takzvané obojsmerné kurzory, ktoré vám umožňujú prechádzať výsledným súborom údajov dopredu aj dozadu. Niektoré DBMS však podporujú iba jednosmerné kurzory, ktoré umožňujú iba navigáciu dopredu cez množinu údajov.

jazyk SQL

Structured Query Language (SQL) je neprocedurálny jazyk používaný na formulovanie databázových dotazov vo väčšine moderných DBMS a v súčasnosti je priemyselným štandardom.

Neprocedurálny charakter jazyka znamená, že môže indikovať, čo je potrebné urobiť s databázou, ale nemôže opísať algoritmus tohto procesu. Všetky algoritmy na spracovanie SQL dotazov sú generované samotným DBMS a nezávisia od používateľa. Jazyk SQL pozostáva zo sady príkazov, ktoré možno rozdeliť do niekoľkých kategórií:

• Data Definition Language (DDL) – jazyk definície údajov, ktorý umožňuje vytvárať, mazať a meniť objekty v databázach
• Data Manipulation Language (DML) – jazyk správy údajov, ktorý vám umožňuje upravovať, pridávať a odstraňovať údaje v existujúcich databázových objektoch
• Data Control Languages ​​​​(DCL) - jazyk používaný na kontrolu používateľských práv
• Transaction Control Language (TCL) – jazyk pre správu zmien vykonaných skupinami operátorov
• Cursor Control Language (CCL) - príkazy na definovanie kurzora, prípravu SQL príkazov na vykonanie a niektoré ďalšie operácie.

Viac o jazyku SQL vám povieme v jednom z nasledujúcich článkov tejto série.

Používateľom definované funkcie

Niektoré DBMS umožňujú používanie užívateľom definovaných funkcií (UDF-User-Defined Functions). Tieto funkcie sú zvyčajne uložené v externých knižniciach a pred ich použitím v dotazoch, spúšťačoch a uložených procedúrach musia byť zaregistrované v databáze.

Pretože užívateľom definované funkcie sú obsiahnuté v knižniciach, môžu byť vytvorené pomocou akéhokoľvek vývojového nástroja, ktorý vám umožňuje vytvárať knižnice pre platformu, na ktorej beží DBMS.

Transakcie

Transakcia je skupina operácií s údajmi, ktoré sa buď vykonajú spoločne, alebo sa spolu zrušia.

Potvrdenie transakcie znamená, že všetky operácie zahrnuté v transakcii boli úspešne dokončené a výsledok ich práce bol uložený do databázy.

Vrátenie transakcie znamená, že všetky už dokončené operácie, ktoré boli súčasťou transakcie, sa zrušia a všetky databázové objekty ovplyvnené týmito operáciami sa vrátia do pôvodného stavu. Na implementáciu schopnosti vrátiť transakcie mnohé DBMS podporujú zapisovanie do protokolových súborov, ktoré vám umožňujú obnoviť pôvodné údaje počas návratu.

Transakcia môže pozostávať z niekoľkých vnorených transakcií.

Niektoré DBMS podporujú dvojfázové odovzdanie, proces, ktorý umožňuje vykonávať transakcie vo viacerých databázach patriacich do rovnakého DBMS.

Na podporu distribuovaných transakcií (t. j. transakcií nad databázami spravovanými rôznymi DBMS) existujú špeciálne nástroje nazývané transakčné monitory.

Záver

V tomto článku sme rozobrali základné koncepty budovania relačných DBMS, základné princípy návrhu dát a hovorili sme aj o tom, aké objekty je možné vytvárať v databázach.

V nasledujúcom článku predstavíme našim čitateľom najpopulárnejšie desktopové DBMS: dBase, Paradox, Access, Visual FoxPro, Works a rozoberieme ich hlavné možnosti.

ComputerPress 3"2000

Základné pojmy relačných databáz sú dátový typ, doména, atribút, n-tica, primárny kľúč a relácia. 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). Prístup k rozširovaniu možností relačných systémov s abstraktnými dátovými typmi sa pomerne aktívne rozvíja (napríklad systémy rodiny Ingres/Postgres majú zodpovedajúce schopnosti). 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 podtypovaním 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 vyhodnotenie tohto booleovského výrazu vráti hodnotu true, potom je dátový prvok element domény. Najsprávnejšia intuitívna interpretácia pojmu domény je chápať doménu ako prípustnú potenciálnu množinu hodnôt daného typu. Napríklad doména „Názvy“ v našom príklade je definovaná na základe typu reťazca základných znakov, ale jej hodnoty môžu zahŕňať iba reťazce, ktoré môžu reprezentovať názov (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 vtedy, ak patria do rovnakej domény. V našom príklade sú hodnoty domény „Čísla medzier“ a „Čísla skupín“ typu celé číslo, ale nie sú porovnateľné. Všimnite si, že väčšina relačných DBMS nepoužíva koncept domény, hoci Oracle V.7 ho už podporuje.

3. Schéma vzťahov, schéma databázy

Schéma vzťahov je pomenovaná množina párov (názov atribútu, názov domény (alebo typ, ak koncept domény nie je podporovaný)). Stupeň alebo „arita“ schémy vzťahov je mohutnosťou tejto množiny. Stupeň vzťahu ZAMESTNANCI je štyri, čiže je 4-árny. Ak sú všetky atribúty jedného vzťahu definované na rôznych doménach, má zmysel používať na pomenovanie atribútov názvy zodpovedajúcich domén (samozrejme treba pamätať na to, že ide len o pohodlný spôsob pomenovania a neodstraňuje rozdiel medzi pojmy doména a atribút). Databázová schéma (v štrukturálnom zmysle) je množina pomenovaných schém vzťahov.

4. Tuple, vzťah

N-tica zodpovedajúca danej relačnej schéme je množina párov (názov atribútu, hodnota), ktorá obsahuje jeden výskyt každého názvu atribútu patriaceho do relačnej schémy. "Hodnota" je platná hodnota domény pre atribút (alebo typ údajov, ak koncept domény nie je podporovaný). Teda stupeň alebo „arita“ n-tice, t.j. počet prvkov v ňom sa zhoduje s „aritou“ zodpovedajúcej schémy vzťahov. Jednoducho povedané, n-tica je zbierka pomenovaných hodnôt daného typu.
Relácia je množina n-tic zodpovedajúcich jednej relačnej schéme. Niekedy, aby sa predišlo zmätku, hovoria „schéma vzťahu“ a „inštancia vzťahu“ niekedy sa schéma vzťahu nazýva hlavná časť vzťahu a vzťah ako množina n-tic sa nazýva telo vzťahu. V skutočnosti je koncept relačnej schémy najbližší konceptu štrukturálneho dátového typu v programovacích jazykoch. Bolo by celkom logické povoliť samostatne definovať schému vzťahov a potom jeden alebo viac vzťahov s touto schémou.
Obvyklou každodennou reprezentáciou vzťahu je tabuľka, ktorej hlavička je schéma vzťahu a riadky sú n-tice vzťahu inštancie; v tomto prípade názvy atribútov pomenúvajú stĺpce tejto tabuľky. To je dôvod, prečo ľudia niekedy hovoria „stĺpec tabuľky“, keď majú na mysli „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. Absencia duplicitných n-tic

Vlastnosť, že vzťahy neobsahujú 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. Z tejto vlastnosti vyplýva, že každý vzťah má takzvaný primárny kľúč – súbor atribútov, ktorých hodnoty jedinečne definujú vzťah n-tice. Pre každý vzťah má túto vlastnosť aspoň úplný súbor jeho atribútov. Pri formálnom definovaní primárneho kľúča je však potrebné zabezpečiť jeho „minimalitu“, t.j. množina atribútov primárneho kľúča by nemala obsahovať atribúty, ktoré je možné zahodiť bez poškodenia hlavnej vlastnosti – jedinečnej identifikácie n-tice. koncepcia primárny kľúč je mimoriadne dôležité v súvislosti s konceptom integrity databázy.

2.Nedostatok objednávania n-tic

Vlastnosť absencie usporiadania n-tic vzťahu je tiež dôsledkom definície inštančného vzťahu ako množiny n-tic. Absencia požiadavky na udržiavanie poriadku na množine n-tic vzťahu dáva dodatočnú flexibilitu DBMS pri ukladaní databáz do externej pamäte a pri vykonávaní dotazov na databázu. To nie je v rozpore s tým, že pri formulovaní databázového dotazu, napríklad v SQL, môžete požadovať, aby bola výsledná tabuľka zoradená 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ťahu nie sú usporiadané, pretože podľa definície je schéma vzťahu množinou párov (názov atribútu, názov domény). Na odkazovanie na hodnotu atribútu v relačnej n-tice sa vždy používa názov atribútu. 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. Väčšina existujúcich systémov však túto možnosť neumožňuje, a hoci sa zoradenie množiny atribútov vzťahu výslovne nevyžaduje, usporiadanie atribútov v lineárnej forme definície schémy vzťahu sa často používa ako implicitné usporiadanie atribútov. .

4.Atomicita hodnôt atribútov.

Hodnoty všetkých 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ť viacero hodnôt (vzťahov). Bežne sa hovorí, ž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é opisujú rôzne aspekty relačného prístupu: štrukturálna časť, manipulačná časť a holistická časť. Štrukturálna časť modelu uvádza, že jediná dátová štruktúra používaná v relačných databázach je normalizovaná n-árna relácia. Manipulačná časť modelu potvrdzuje dva základné mechanizmy manipulácie 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ý je založený na klasickom logickom aparáte predikátového počtu prvého rádu.

Integrita entity a referencie. Nakoniec integrálna časť relačného dátového modelu stanovuje 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 v systéme nie sú porušené základné vlastnosti vzťahov. Druhá požiadavka je tzv Požiadavka referenčnej integrity 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, v ktorých používateľ špecifikuje, aké údaje je potrebné získať, bez toho, aby špecifikoval postup ich získania. Jediným dotazom v ktoromkoľvek z týchto jazykov môžete spojiť niekoľko tabuliek do dočasnej tabuľky a vystrihnúť z nej požadované riadky a stĺpce (výber a zobrazenie).

Základné pojmy relačných databáz

Hlavné koncepty relačných databáz sú:

Dátový typ

• primárny kľúč a

  postoj.

Na začiatok si ukážme význam týchto pojmov na príklade vzťahu ZAMESTNANEC,

Obrázok 4.1. Hierarchia pojmov v databáze ZAMESTNANCI

Dátový typ

Pojem dátového typu 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 peňazí), ako aj špeciálnych časových údajov (dátum, čas, časový interval).

doména

Koncept domény je špecifickejší 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 vyhodnotenie tohto booleovského výrazu vráti hodnotu true, potom je dátový prvok element domény. Najsprávnejšia intuitívna interpretácia pojmu domény je chápať doménu ako prípustnú potenciálnu množinu hodnôt daného typu. Napríklad doména Names v našom príklade je definovaná na základnom type reťazcov znakov, ale jej hodnoty môžu zahŕňať iba 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 vtedy, ak patria do rovnakej domény. V našom príklade sú hodnoty domén Skip Numbers a Group Numbers typu celé číslo, ale nie sú porovnateľné.

Schéma vzťahov, schéma databázy

Relačná schéma je pomenovaná množina párov názov atribútu, doménové meno(alebo zadajte, ak koncept domény nie je podporovaný). Stupeň alebo arita schémy vzťahov je silou tejto množiny. Stupeň vzťahu ZAMESTNANCI je štyri, čiže je 4-árny. Ak sú všetky atribúty jedného vzťahu definované na rôznych doménach, má zmysel používať na pomenovanie atribútov názvy zodpovedajúcich domén (samozrejme treba pamätať na to, že ide len o pohodlný spôsob pomenovania a neodstraňuje rozdiel medzi pojmy doména a atribút). Databázová schéma (v štrukturálnom zmysle) je množina pomenovaných schém vzťahov.

Tuple, vzťah

N-tica zodpovedajúca danej relačnej schéme 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ťahov. Hodnota je platnou hodnotou pre doménu atribútu (alebo typ údajov, ak koncept 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. Jednoducho povedané, n-tica je zbierka pomenovaných hodnôt daného typu. Relácia je množina n-tic zodpovedajúcich jednej relačnej schéme. Niekedy, aby nedošlo k zámene, hovoria vzťah schémy a vzťah inštancie, niekedy sa schéma vzťahu nazýva hlavička vzťahu a vzťah ako množina n-tic sa nazýva telo vzťahu. V skutočnosti je koncept relačnej schémy najbližší konceptu štrukturálneho dátového typu v programovacích jazykoch. Bolo by celkom logické povoliť samostatne definovať schému vzťahov a potom jeden alebo viac vzťahov s touto schémou. V relačných databázach to však nie je bežná prax. 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 upravia 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é. V mnohých implementáciách je však tiež možné zmeniť databázovú schému: definovanie nových a zmena existujúcich schém vzťahov. Toto sa bežne nazýva vývoj databázovej schémy. Obvyklou každodennou reprezentáciou vzťahu je tabuľka, ktorej hlavička je schéma vzťahu a riadky sú n-tice vzťahu inštancie; v tomto prípade názvy atribútov pomenúvajú stĺpce tejto tabuľky. Preto sa niekedy hovorí stĺpec tabuľky, čo znamená relačný atribút. Keď prejdeme k praktickým otázkam organizácie relačných databáz a nástrojov na správu, použijeme túto každodennú terminológiu. Táto terminológia sa používa vo väčšine 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.

Základné vlastnosti vzťahov

Zastavme sa teraz pri niektorých dôležitých vlastnostiach vzťahov, ktoré vyplývajú z vyššie uvedených definícií.

Žiadne duplicitné n-tice

Vlastnosť, že vzťahy neobsahujú 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. Z tejto vlastnosti vyplýva, že každý vzťah má takzvaný primárny kľúč – súbor atribútov, ktorých hodnoty jedinečne definujú vzťah n-tice. Pre každý vzťah má túto vlastnosť aspoň úplný súbor jeho atribútov. Pri formálnom definovaní primárneho kľúča je však potrebné zabezpečiť jeho minimalizáciu, t.j. množina atribútov primárneho kľúča by nemala obsahovať atribúty, ktoré možno zahodiť bez ovplyvnenia hlavnej vlastnosti – jedinečnej identifikácie n-tice. Koncept primárneho kľúča je mimoriadne dôležitý v súvislosti s konceptom integrity databázy. Pri pohľade do budúcnosti si všimneme, že mnohé praktické implementácie RDBMS umožňujú porušenie vlastnosti jedinečnosti n-tic pre medziľahlé vzťahy generované implicitne pri vykonávaní dotazov. Takéto vzťahy nie sú množiny, ale multimnožiny, čo v niektorých prípadoch umožňuje dosiahnuť určité výhody, ale niekedy vedie k vážnym problémom.

Nedostatok objednávania n-tic

Vlastnosť absencie usporiadania n-tic vzťahu je tiež dôsledkom definície inštančného vzťahu ako množiny n-tic. Absencia požiadavky na udržiavanie poriadku na množine n-tic vzťahu dáva dodatočnú flexibilitu DBMS pri ukladaní databáz do externej pamäte a pri vykonávaní dotazov na databázu. To nie je v rozpore s tým, že pri formulovaní databázového dotazu, napríklad v SQL, môžete požadovať, aby bola výsledná tabuľka zoradená 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.

Nedostatok zoradenia atribútov

Atribúty vzťahov nie sú usporiadané, pretože podľa definície je schéma vzťahov množinou párov názov atribútu, doménové meno. Na odkazovanie na hodnotu atribútu v relačnej n-tice sa vždy používa názov atribútu. 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. Väčšina existujúcich systémov však túto možnosť neumožňuje, a hoci sa zoradenie množiny atribútov vzťahu výslovne nevyžaduje, usporiadanie atribútov v lineárnej forme definície schémy vzťahu sa často používa ako implicitné usporiadanie atribútov. .

Atomicita hodnôt atribútov

Hodnoty všetkých 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ť viacero hodnôt (vzťahov). Bežne sa hovorí, že v relačných databázach sú povolené iba normalizované vzťahy alebo vzťahy reprezentované v prvej normálnej forme. Potenciálny príklad nenormalizovaného pomeru je znázornený na obr. 4.2.1.

Obrázok 4.2.1. ODDELENIA vzťah v nenormalizovanej podobe

Obrázok 4.2.2. Normalizovaný prístup ZAMESTNANCI

Dá sa povedať, že tu máme binárny vzťah, hodnoty atribútu ODDELENIA sú vzťahy. Všimnite si, že pôvodný vzťah ZAMESTNANCI je normalizovanou verziou vzťahu ODDELENIA (pozri obr. 4.2.2). Normalizované vzťahy tvoria základ klasického relačného prístupu k organizácii databázy. Majú určité obmedzenia (nie je vhodné uvádzať všetky informácie vo forme plochých tabuliek), ale výrazne zjednodušujú manipuláciu s údajmi. Zvážte napríklad dva identické operátory vkladania n-tice:

Zapíšte zamestnanca Kuznecova (číslo preukazu 3000, plat 115 000) do oddelenia číslo 320 a zamestnanca Kuznecova (číslo preukazu 3000, plat 115 000) do oddelenia číslo 310. Ak sú informácie o zamestnancovi reprezentované ako vzťah ZAMESTNANCI, oba výpisy sa vykonajú identicky (vložte tuple vo vzťahu k ZAMESTNANCOM). Ak pracujete s nenormalizovaným vzťahom ODDELENIA, potom prvý operátor povedie k pridaniu n-tice a druhý operátor pridá informácie o Kuznecovovi k násobnej hodnote atribútu ODDELENIE n-tice s primárnym kľúčom 310.

Relačný dátový model

Keď sme v predchádzajúcich častiach hovorili o základných konceptoch relačných databáz, nespoliehali sme sa na žiadnu konkrétnu implementáciu. Tieto úvahy platili rovnako pre každý systém, pri konštrukcii ktorého bol použitý relačný prístup. Inými slovami, použili sme koncepty takzvaného relačného dátového modelu. Dátový model popisuje určitý súbor všeobecných konceptov a charakteristík, ktoré musia mať všetky špecifické DBMS a databázy, ktoré spravujú, ak sú založené na tomto modeli. Údajový model vám umožňuje porovnávať konkrétne implementácie pomocou jedného spoločného jazyka. Hoci pojem dátový model je všeobecný a môžeme hovoriť o hierarchickom, sieťovom, nejakom sémantickom atď. dátových modelov, treba poznamenať, že tento pojem bol zavedený vo vzťahu k relačným systémom a v tomto kontexte sa najefektívnejšie využíva. Pokusy priamo aplikovať podobné modely na prerelačné organizácie ukazujú, že relačný model je pre ne príliš veľký a pre postrelačné organizácie sa ukazuje ako malý.

všeobecné charakteristiky

Zdá sa, že najbežnejšou interpretáciou relačného dátového modelu je Dat, ktorý ho reprodukuje (s rôznymi vylepšeniami) takmer vo všetkých svojich knihách. Podľa Date sa relačný model skladá z troch častí, ktoré opisujú rôzne aspekty relačného prístupu: štrukturálna časť, manipulačná časť a holistická časť. Štrukturálna časť modelu uvádza, že jediná dátová štruktúra používaná v relačných databázach je normalizovaná n-árna relácia. V skutočnosti sme v predchádzajúcich dvoch častiach tejto prednášky presne skúmali pojmy a vlastnosti štrukturálnej zložky relačného modelu. Manipulačná časť modelu potvrdzuje dva základné mechanizmy manipulácie 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ý je založený na klasickom logickom aparáte predikátového počtu prvého rádu. Ďalej sa na tieto mechanizmy pozrieme podrobnejšie, ale zatiaľ si všimneme len to, že hlavnou funkciou manipulačnej časti relačného modelu je poskytnúť mieru relatívnosti akéhokoľvek špecifického relačného databázového jazyka: jazyk sa nazýva relačný ak nemá o nič menšiu výraznosť a silu ako relačná algebra alebo relačný kalkul.

Integrita entity a referencie

Nakoniec integrálna časť relačného dátového modelu stanovuje dve základné požiadavky na integritu, ktoré musia byť podporované v akomkoľvek relačnej DBMS. Prvá požiadavka sa nazýva 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, že každá n-tica akéhokoľvek vzťahu musí byť 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 v systéme nie sú porušené základné vlastnosti vzťahov. Druhá požiadavka sa nazýva požiadavka referenčnej integrity 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. Predstavme si napríklad, že potrebujeme reprezentovať entitu ODDELENIE v relačnej databáze s atribútmi DTD_NUMBER (číslo oddelenia), DTD_COL (počet zamestnancov) a DTD_COTR (množina zamestnancov oddelenia). Pre každého zamestnanca musíte uložiť COTR_NUMBER (číslo zamestnanca), COTR_NAME (meno zamestnanca) a COTR_SARP (plat zamestnanca). Ako čoskoro uvidíme, pri správnom návrhu zodpovedajúcej databázy sa v nej objavia dva vzťahy: DEPARTMENTS (DEPARTMENT_NUMBER, DEPARTMENT_COUNTY) (primárny kľúč - DEPARTMENT_NUMBER) a ZAMESTNANCI (COTR_NUMBER, COTR_NAME, COTR_SARP, COTR_DEPARTMENT_NUM) (primárny kľúč - COTR_NUMBER ). Ako vidíte, atribút SOTR_ODDELENIE_NOM sa objavuje vo vzťahu ZAMESTNANCI nie preto, že číslo oddelenia je vlastným majetkom zamestnanca, ale len preto, aby bolo možné v prípade potreby obnoviť celú entitu ODDELENIA. Hodnota atribútu STR_DEPARTMENT_NOM v ľubovoľnej n-tici vzťahu EMPLOYEES musí zodpovedať hodnote atribútu DEPARTMENT_NOM v niektorej n-tici vzťahu DEPARTMENTS. Atribút tohto druhu sa nazýva cudzí kľúč, pretože jeho hodnoty jedinečne charakterizujú entity reprezentované n-ticami nejakého iného vzťahu (t. j. špecifikujú hodnoty ich primárneho kľúča). Hovorí sa, že vzťah, v ktorom je definovaný cudzí kľúč, odkazuje na zodpovedajúci vzťah, v ktorom je rovnaký atribút primárnym kľúčom. Požiadavka referenčnej integrity alebo požiadavka cudzieho kľúča je taká, že pre každú hodnotu cudzieho kľúča, ktorá sa objaví v referenčnom vzťahu, musí existovať n-tica v referenčnom vzťahu s rovnakou hodnotou primárneho kľúča, alebo musí byť hodnota cudzieho kľúča úplne neistá (t. j. nič nenaznačovať). Pre náš príklad to znamená, že ak je pre zamestnanca zadané číslo oddelenia, toto oddelenie musí existovať. Obmedzenia entitnej a referenčnej integrity musia byť podporované DBMS. Na zachovanie integrity entity stačí zabezpečiť, aby v žiadnom vzťahu neboli žiadne n-tice s rovnakou hodnotou primárneho kľúča. S referenčnou integritou sú veci trochu komplikovanejšie. Je zrejmé, že pri aktualizácii referenčného vzťahu (vkladaní nových n-tic alebo úprave hodnoty cudzieho kľúča v existujúcich niciach) stačí zabezpečiť, aby sa nezobrazili nesprávne hodnoty cudzieho kľúča. Ale čo tak odstrániť n-ticu z odkazovaného vzťahu? Existujú tri prístupy, z ktorých každý podporuje referenčnú integritu. Prvým prístupom je zakázať vymazanie odkazovanej n-tice (t. j. najprv musíte odstrániť referenčné n-tice alebo podľa toho zmeniť ich hodnoty cudzieho kľúča). V druhom prístupe, keď sa vymaže odkazovaná n-tice, hodnota cudzieho kľúča vo všetkých odkazujúcich niciach sa automaticky stane nedefinovanou. Nakoniec, tretí prístup (kaskádové vymazanie) spočíva v tom, že keď sa n-tica vymaže z referenčného vzťahu, všetky referenčné n-tice sa automaticky vymažú z referenčného vzťahu. Vo vyspelých relačných DBMS je zvyčajne možné zvoliť, ako zachovať referenčnú integritu pre každú jednotlivú situáciu definície cudzieho kľúča. Samozrejme, na takéto rozhodnutie je potrebné analyzovať požiadavky konkrétnej aplikačnej oblasti.