Anotácia: Táto a ďalšie dve prednášky sú venované teórii relačných databáz. Keďže celý relačný prístup k organizácii databáz je čisto praktický, táto teória je hlavne pragmatická. Hlavným problémom, ktorý sa teória relačných databáz snaží vyriešiť, je objavenie užitočných vlastností určitých databázových schém a vývoj spôsobov konštrukcie takýchto schém. Tento problém sa bežne stručne označuje ako problém návrhu relačnej databázy.

Úvod

Napriek svojmu praktickému zameraniu teória relačných databáz je samostatný vedný odbor, v ktorom pôsobilo (a pôsobí) mnoho známych výskumníkov, ktorých mená sa objavia na našich prednáškach. V tomto kurze sme nemali v pláne podrobne popisovať hlavné výsledky v teréne. Naším cieľom je poskytnúť iba definície a vyhlásenia potrebné na všeobecné pochopenie procesu návrh relačnej databázy na základe normalizácie.

Keďže najdôležitejšie vlastnosti relačných databáz z praktického hľadiska vychádzajú z konceptu funkčná závislosť, stručnú diskusiu o relevantných teoretických otázkach sme zaradili do samostatnej prednášky. Medzi tieto otázky patria uzávery a pokrývajúce množiny funkčných závislostí, Armstrongove axiómy a Heathova veta o dostatočnej podmienke bezstratový rozklad vzťahu. Pojmy a tvrdenia z tejto prednášky sú skutočne potrebné na zvládnutie látky v 7. prednáške, no zároveň sme sa snažili čitateľom na jednoduchých príkladoch ukázať, čo to je teória relačných databáz, aká je jeho úroveň zložitosti a aká je intuitívna.

Všimnite si, že sme neoddeľovali teoretický materiál týkajúci sa viachodnotové závislosti A závislosti pripojenia. Stalo sa tak z dvoch dôvodov. Po prvé, tieto typy závislostí sú v modelovaní menej bežné predmetná oblasť pomocou databáz. Preto sme považovali za dostatočné prezentovať v rámci 8. prednášky len základy príslušného teoretického materiálu. Po druhé, aj keď teória viachodnotové závislosti A závislosti pripojenia v skutočnosti nie je oveľa zložitejšia ako teória funkčné závislosti, jeho definície a vyhlásenia sú pre tento kurz príliš ťažkopádne.

Funkčné závislosti

Najdôležitejšie z praktického hľadiska normálne formy vzťahov sú založené na základných teórie relačných databáz koncepcie funkčná závislosť. Pre ďalšiu prezentáciu budeme potrebovať niekoľko definícií a tvrdení (vysvetlíme a znázorníme ich, ako budeme postupovať).

Všeobecné definície

Nech je to dané vzťahová premenná r a X a Y sú ľubovoľné podmnožiny hlavičky r ("zložené" atribúty).

Vo význame vzťahová premenná r atribút Y je funkčne závislý od atribútu X vtedy a len vtedy, ak každá hodnota X zodpovedá práve jednej hodnote Y. V tomto prípade sa tiež hovorí, že atribút X funkčne definuje atribút Y (X je determinant ( determinant) pre Y a Y je závislé od X). Označíme to ako r.X->r.Y .

Napríklad použijeme vzťah EMPLOYEE_PROJECTS (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(obr. 6.1). Samozrejme, ak je SLU_NOM primárny kľúč vzťahu ZAMESTNANCI, tak pre tento vzťah je to fér funkčná závislosť (FD) SLN_NAME->SERV_NAME .

Vlastne pre telo vzťahu EMPLOYEES_PROJECTS v podobe, v akej je znázornená na obr. 6.1 sa vykonávajú aj tieto FD (1):

Ryža. 6.1.

SLUN_NOM->SLUN_NAME SLUN_NOM->SLUN_ZARP SLU_NOM->PRO_NOM SLUN_NOM->PROJECT_RUK (SLUN_NAME, SLU_NAME)->SLUN_ZARP (SLUN_NAME, SLUN_NAME)->PRO_NOM (SLUN_NAME)_NAME)->PRO_SLUN_NAME, PROJECT_SLUNNOM-…PROJECT_RUK K a atď.

Keďže mená všetkých zamestnancov sú odlišné, sú splnené aj tieto FD (2):

SERV_NAME->SERV_NAME SERV_NAME->SLU_ZARP SER_NAME->PRO_NAME atď.

Navyše pre príklad na obr. 6.1 je splnený a FD (3):

SLU_ZARP->PRO_NOM

Všimnite si však, že povaha FD skupiny (1) sa líši od povahy FD skupín (2) a (3). Je logické predpokladať, že identifikačné čísla zamestnancov by mali byť vždy iné a každý projekt má iba jedného manažéra. Preto FD skupiny (1) musia byť pravdivé pre akúkoľvek platnú hodnotu vzťahová premenná EMPLOYEES_PROJECTS a možno ho považovať za invarianty, alebo integritné obmedzenia toto vzťahová premenná.

Skupinové FD (2) sú založené na menej prirodzenom predpoklade, že všetci zamestnanci majú rôzne mená. To platí pre príklad na obr. 6.1, ale je možné, že v priebehu času nebudú skupiny FD (2) splnené pre žiadnu hodnotu vzťahová premenná EMPLOYEES_PROJECTS.

Napokon, RR skupiny (3) je založené na veľmi neprirodzenom predpoklade, že žiadni dvaja zamestnanci zapojení do rôznych projektov nedostávajú rovnakú mzdu. Tento predpoklad opäť platí pre príklad na obr. 6.1, ale s najväčšou pravdepodobnosťou ide o náhodu.

V budúcnosti nás budú zaujímať len tie funkčné závislosti, ktorá musí byť splnená pre všetky možné hodnoty vzťahové premenné.

Všimnite si, že ak atribút A vzťahu r je možný kľúč, potom pre akýkoľvek atribút B tohto vzťahu vždy platí

PROGRAMOVANIE V PROSTREDÍ DELPHI 6

Databáza. Vytvorte zostavu pomocou programu Word.

Schválené redakčnou a vydavateľskou radou

univerzitu ako laboratórnu dielňu

Voronež 2004

MDT 681,3

Vorobyov E.I., Korotkevich D.E.. Programovanie v prostredí Delphi 6: Laboratórny workshop: Časť 2: Databázy. Vytvorte zostavu pomocou programu Word. Prúdy. Voronež: Voronež. štát tech. Univ., 2004. 107 s.

Druhá časť laboratórneho workshopu rozoberá teoretické a praktické informácie pre písanie programov v prostredí Delphi 6 na tému: „Navrhovanie databáz, vytváranie zostáv vo Worde a používanie vlákien pri vytváraní vysokovýkonných aplikácií.“

Publikácia spĺňa požiadavky Štátneho vzdelávacieho štandardu vyššieho odborného vzdelávania v smere 230100 „Informatika a informatika“, odbor 230104 „Systémy počítačom podporovaného projektovania“, odbor „Programovanie vo vyšších jazykoch“.

Tabuľka 3. Il. 19. Bibliografia: 7 titulov.

Vedecký redaktor: Dr. Tech. vedy, prof. Ya.E. Ľvovič

Recenzenti: Katedra informatiky Voronežskej lesníckej akadémie (vedúci katedry, doktor technických vied, prof. V.E. Mezhov);

Dr. Tech. vedy, prof. O.Yu.Makarov

© Vorobyov E.I., Korotkevich D.E., 2004

© Dizajn. Voronežský štát

Technická univerzita, 2004

Úvod

Koncept databázy

Za hlavnú výhodu Delphi sa považujú databázy. Dokonca aj špecializované jazyky na prácu s databázami (napríklad MS Visual FoxPro) sú jednoznačne horšie v jednoduchosti a sile programovania tohto typu aplikácií. Delphi skrýva všetku zložitosť a zároveň dáva najväčšiu silu. Nikdy neexistovala úloha, ktorá by sa nedala implementovať v Delphi v krátkom čase. A hlavná vec je, že to všetko je implementované veľmi pohodlne a ľahko pochopiteľné. V Delphi môžete vytvárať jednoduché aplikácie, dokonca aj so zložitými databázami, bez jediného riadku kódu. Tento tutoriál obsahuje laboratórne úlohy na zvládnutie techník práce s lokálnymi databázami.

Teória relačných databáz

Pred desiatimi rokmi bolo programovanie databáz veľmi náročnou úlohou. V súčasnosti je to ťažké si predstaviť, pretože vďaka Delphi sa zjednodušil proces písania programov a počet druhov databáz je už v desiatkach.

Databázy sa delia na lokálne (inštalované na klientskom počítači, kde sa program spúšťa) a vzdialené (inštalované na server, vzdialený počítač). Serverové databázy sú umiestnené na vzdialenom počítači a bežia pod kontrolou serverového softvéru. Medzi ich hlavné výhody patrí možnosť pracovať s jednou databázou súčasne viacerými používateľmi a zároveň je minimálne zaťaženie siete. Existujú aj sieťové databázy, ktoré vytvárajú príliš veľké zaťaženie siete a sú nepohodlné na používanie pre programátora aj koncového používateľa. Keď sa program pripojí k sieťovej databáze, stiahne si takmer kompletnú kópiu zo servera. Ak ste vykonali zmeny, vaša kópia sa úplne stiahne späť. To je veľmi nepohodlné, pretože to vytvára veľké zaťaženie siete kvôli nadmernému prenosu dát. V technológii klient-server odošle klientsky program serveru jednoduchú textovú požiadavku na prijatie niektorých údajov. Server ich spracuje a vráti len požadovanú časť údajov. Keď potrebujete zmeniť niektoré údaje, na server sa opäť odošle požiadavka na ich zmenu a server zmení údaje vo svojej databáze. Cez sieť sa tak prenášajú najmä textové požiadavky, ktoré vo všeobecnosti zaberajú menej ako kilobajt. Všetky dáta spracováva server, čo znamená, že stroj klienta je zaťažený oveľa menej a nie je tak náročný na zdroje. Server posiela klientovi len tie najnutnejšie dáta, takže nedochádza k zbytočnému sťahovaniu kópie celej databázy. Vďaka tomu všetkému sú už sieťové databázy zastarané a prakticky sa nepoužívajú. Sú takmer úplne nahradené technológiou klient-server. Ale lokálne databázy budú vždy žiť. Môže sa zmeniť formát ich úložiska alebo pribudnúť nejaké nové funkcie, ale samotné databázy budú existovať. Pre ďalšie zváženie musíme definovať nový pojem - tabuľky. Doteraz sa hovorilo len o všeobecných princípoch, takže sa použil všeobecný koncept databázy. Databázová tabuľka je ako dvojrozmerné pole, v ktorom sú údaje usporiadané do stĺpca (hlavným príkladom tabuľky je Excel). Databáza je, zhruba povedané, len súbor, ktorý môže uchovávať jednu až niekoľko tabuliek. Väčšina lokálnych databáz môže uchovávať iba jednu tabuľku (dBase, Paradox, XML). Existujú však zástupcovia lokálnych databáz, kde je v jednom súbore obsiahnutých niekoľko tabuliek (napríklad Access).

Lokálne databázy

Spomedzi lokálnych databáz považujme za najrozšírenejšie relačné. Čo je to relačná databáza? Ide o tabuľku, v ktorej sú v stĺpcoch názvy údajov v nej uložených a v každom riadku sú uložené údaje samotné. Databázová tabuľka je podobná excelovej tabuľke (presnejšie povedané, Excel ukladá svoje údaje v proprietárnom formáte postavenom na databázovej technológii). Lokálne databázové tabuľky môžu byť uložené na lokálnom pevnom disku alebo centrálne uložené na sieťovom disku na súborovom serveri. Tieto súbory je možné kopírovať pomocou štandardných nástrojov ako každý iný súbor, pretože samotné databázové tabuľky nie sú viazané na konkrétne miesto. Hlavná vec je, že program môže nájsť tabuľku. Každá tabuľka musí mať jedno jedinečné pole, ktoré bude jednoznačne identifikovať riadok. Toto pole sa nazýva kľúčové pole. Tieto polia sa veľmi často používajú na prepojenie viacerých tabuliek. Ale aj keď tabuľka nesúvisí, kľúčové pole je stále povinné. Ako kľúč je vhodné použiť číselný typ a ak to databáza umožňuje, bude lepšie, ak bude typu „autoincrement“ (automaticky sa zvyšuje/znižuje číslo alebo počítadlo). Názvy stĺpcov v databázovej tabuľke musia byť tiež jedinečné, ale v tomto prípade nie nevyhnutne číselné. Môžu sa nazývať akokoľvek chcete, pokiaľ je to jedinečné a zrozumiteľné. Každý stĺpec (pole databázy) musí mať špecifický typ. Počet typov a ich variet závisí od typu databázy, napríklad formát dBASE (súbory s príponou DBF) podporuje iba 6 typov a Paradox už podporuje až 15. Databázu je možné uložiť do jedného súboru (Prístup ) alebo vo viacerých (Paradox, dBase). Presnejšie, údaje tabuľky sú vždy uložené v jednom súbore, ale ďalšie informácie môžu byť umiestnené v samostatných súboroch. Ďalšie informácie môžu zahŕňať indexy, obmedzenia alebo zoznam predvolených hodnôt pre konkrétne polia. Ak sa poškodí alebo odstráni aspoň jeden zo súborov, údaje nemusia byť dostupné na úpravu.

Čo sa stalo indexy? Údaje z tabuliek veľmi často prechádzajú určitými zmenami, takže pred úpravou akéhokoľvek riadku ho musíte nájsť. Dokonca aj statické tabuľky používané ako referenčné knihy podliehajú pred zobrazením požadovaných údajov operáciám vyhľadávania. Vyhľadávanie je pomerne časovo náročná operácia, najmä ak tabuľka obsahuje veľa riadkov. Indexy sú zamerané na urýchlenie tohto postupu a môžu sa použiť aj ako východiskový bod pri triedení. V tejto fáze stačí vedieť, že neindexované pole nemožno objednať.

Ak potrebujete nejaký stôl objednať podľa poľa " Priezvisko“, potom musí byť toto pole najprv indexované. Potom už len stačí naznačiť, že tabuľka má teraz pracovať s takým a takým indexom a automaticky sa zoradí.

V dobre navrhnutej databáze sa eliminuje redundancia údajov a minimalizuje sa pravdepodobnosť uloženia nekonzistentných údajov. Vytváranie databáz má teda dva hlavné ciele: znížiť redundanciu údajov a zvýšiť ich spoľahlivosť.

Životný cyklus akéhokoľvek softvérového produktu, vrátane systému správy databáz, pozostáva (z veľkej časti) z fáz návrhu, implementácie a prevádzky.

Prirodzene, najdôležitejším faktorom v životnom cykle databázovej aplikácie je fáza návrhu. Výkon systému a jeho informačná bohatosť, a teda aj jeho životnosť, závisia od toho, ako starostlivo je premyslená štruktúra databázy a ako jasne sú definované prepojenia medzi jej prvkami.

Požiadavky na databázu

Takže dobre navrhnutá databáza:

1. Spĺňa všetky požiadavky používateľov na obsah databázy. Pred návrhom databázy je potrebné vykonať rozsiahly prieskum požiadaviek používateľov na funkčnosť databázy.

2. Zabezpečuje konzistenciu a integritu údajov. Pri navrhovaní tabuliek je potrebné definovať ich atribúty a niektoré pravidlá, ktoré obmedzujú možnosť používateľa zadať nesprávne hodnoty. Na overenie údajov pred ich priamym zápisom do tabuľky musí databáza zavolať pravidlá dátového modelu a tým zabezpečiť zachovanie integrity informácií.

3. Poskytuje prirodzené, ľahko zrozumiteľné štruktúrovanie informácií. Vysokokvalitná konštrukcia databázy vám umožňuje urobiť dopyty do databázy „transparentnejšie“ a ľahšie pochopiteľné; V dôsledku toho sa znižuje pravdepodobnosť zadávania nesprávnych údajov a zlepšuje sa kvalita údržby databázy.

4. Spĺňa požiadavky užívateľov na výkon databázy. S veľkými objemami informácií problémy s udržaním produktivity

začnú hrať hlavnú úlohu a okamžite „zvýraznia“ všetky nedostatky fázy návrhu.

Nasledujúce body predstavujú základné kroky návrhu databázy:

1. Určiť informačné potreby databázy.

2. Analyzujte objekty reálneho sveta, ktoré je potrebné modelovať v databáze. Z týchto objektov vytvorte entity a charakteristiky týchto entít (napríklad pre entitu „diel“ môžu byť charakteristiky „názov“, „farba“, „váha“ atď.) a vytvorte ich zoznam.

3. Priraďte entity a charakteristiky - tabuľky a stĺpce (polia) v zápise Vami zvoleného DBMS (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle atď.).

4. Definujte atribúty, ktoré jedinečne identifikujú každý objekt.

5. Vytvorte pravidlá, ktoré zavedú a udržia integritu údajov.

6. Vytvorte spojenia medzi objektmi (tabuľkami a stĺpcami), normalizujte tabuľky.

7. Plánovať otázky spoľahlivosti údajov a v prípade potreby zachovávať tajnosť informácií.

Súvisiace informácie.

Relačná algebra je založená na teórii množín a je základom databázovej logiky.
Keď som ešte len študoval štruktúru databáz a SQL, predbežné oboznámenie sa s relačná algebrou mi veľmi pomohlo, aby sa mi ďalšie poznatky správne zmestili do hlavy a pokúsim sa, aby tento článok mal podobný efekt.

Ak sa teda chystáte začať študovať v tejto oblasti alebo máte len záujem, kliknite na mačku.

Relačná databáza

Najprv si predstavme koncept relačnej databázy, v ktorej budeme vykonávať všetky akcie.

Relačná databáza je kolekcia vzťahov, ktorá obsahuje všetky informácie, ktoré musia byť uložené v databáze. V tejto definícii nás zaujíma pojem vzťah, no nateraz ho necháme bez striktnej definície.
Poďme si lepšie predstaviť tabuľku produktov.

Tabuľka PRODUKTY

ID	NÁZOV	SPOLOČNOSŤ	CENA
123	Cookies	Dark Side LLC	190
156	Čaj	Dark Side LLC	60
235	Ananás	OJSC "Frukty"	100
623	Paradajky	OOO "Zelenina"	130

Tabuľka pozostáva zo 4 riadkov, riadok v tabuľke je v relačnej teórii n-tica. Množina usporiadaných n-tic sa nazýva relácia.
Pred definovaním vzťahu si predstavme ďalší pojem – doménu. Domény vo vzťahu k tabuľke sú stĺpce.

Pre prehľadnosť teraz zavedieme striktnú definíciu vzťahu.

Nech je daných N množín D1,D2, …. Dn (domény), relácia R nad týmito množinami je množina usporiadaných N-tic tvaru , kde d1 patrí k D1 atď. Množiny D1,D2,..Dn sa nazývajú oblasti vzťahu R.
Každý prvok n-tice predstavuje hodnotu jedného z atribútov zodpovedajúcich jednej z domén.

Kľúče vo vzťahoch

Vo vzťahu je požiadavka, že všetky n-tice musia byť odlišné. Na jedinečnú identifikáciu n-tice existuje primárny kľúč. Primárny kľúč je atribút alebo súbor minimálneho počtu atribútov, ktorý jedinečne identifikuje konkrétnu n-tku a neobsahuje žiadne ďalšie atribúty.
Z toho vyplýva, že všetky atribúty v primárnom kľúči musia byť potrebné a postačujúce na identifikáciu konkrétnej n-tice a vynechanie ktoréhokoľvek z atribútov v kľúči spôsobí, že nebude stačiť na identifikáciu.
Napríklad v takejto tabuľke bude kľúčom kombinácia atribútov z prvého a druhého stĺpca.

Tabuľka VODIČOV

Je zrejmé, že organizácia môže mať niekoľko vodičov a na jedinečnú identifikáciu vodiča je potrebná hodnota zo stĺpca „Názov organizácie“ aj zo stĺpca „Meno vodiča“. Takýto kľúč sa nazýva zložený kľúč.

V relačnej databáze sú tabuľky prepojené a navzájom súvisiace ako hlavné a podriadené tabuľky. Spojenie medzi hlavnou a podriadenou tabuľkou sa uskutočňuje prostredníctvom primárneho kľúča hlavnej tabuľky a cudzieho kľúča podriadenej tabuľky.
Cudzí kľúč je atribút alebo súbor atribútov, ktorý je primárnym kľúčom v hlavnej tabuľke.

Táto prípravná teória bude postačovať na oboznámenie sa so základnými operáciami relačnej algebry.

Operácie relačnej algebry

Základných osem operácií relačnej algebry navrhol E. Codd.

• Združenie
• Križovatka
• Odčítanie
• karteziánsky súčin
• Ukážka
• Projekcia
• Zlúčenina
• divízie

Prvá polovica operácií je podobná rovnakým operáciám na množinách. Niektoré operácie možno vyjadriť ako iné operácie. Pozrime sa na väčšinu operácií s príkladmi.

Pre pochopenie je dôležité si uvedomiť, že výsledkom akejkoľvek algebrickej operácie na vzťahoch je ďalší vzťah, ktorý potom možno použiť v ďalších operáciách.
Vytvorme si ďalšiu tabuľku, ktorá sa nám bude hodiť v príkladoch.

Tabuľka PREDAJCOV

ID	PREDAJCA
123	OOO "Šípka"
156	OJSC "Vedro"
235	CJSC „Zelenina baza“
623	JSC "Firma"

Dohodnime sa, že v tejto tabuľke je ID cudzí kľúč spojený s primárnym kľúčom tabuľky PRODUCTS.

Najprv sa pozrime na najjednoduchšiu operáciu – názov vzťahu. Jeho výsledkom bude rovnaká relácia, čiže vykonaním operácie PRODUKTY získame kópiu vzťahu PRODUKT.

Projekcia

Projekcia je operácia, pri ktorej sa atribúty zo vzťahu extrahujú iba zo špecifikovaných domén, to znamená, že sa z tabuľky vyberú len potrebné stĺpce, a ak sa získa niekoľko rovnakých n-tic, potom zostane iba jedna inštancia takejto n-tice výsledný vzťah.
Urobme napríklad projekciu na tabuľku PRODUKTY tak, že z nej vyberieme ID a CENU.

Syntax operácie:
π (ID, CENA) PRODUKTY

Vo vzorovej podmienke môžeme použiť ľubovoľný booleovský výraz. Urobme ďalší výber s cenou vyššou ako 90 a ID produktu menším ako 300:

σ(CENA>90^ID<300) PRODUCTS

Násobenie

Násobenie alebo karteziánsky súčin je operácia vykonaná na dvoch vzťahoch, v dôsledku čoho z dvoch počiatočných vzťahov získame vzťah so všetkými doménami. N-tice v týchto doménach budú všetky možné kombinácie n-tic z počiatočných vzťahov. Na príklade to bude jasnejšie.

Získavame karteziánsky súčin tabuliek PRODUKTY a PREDAJCOVIA.
Syntax operácie:

PRODUKTY × PREDAJCOVIA
Všimnete si, že tieto dve tabuľky majú rovnakú ID doménu. V tejto situácii majú domény s rovnakým názvom predponu s názvom zodpovedajúceho vzťahu, ako je uvedené nižšie.
Pre stručnosť nevynásobme úplné pomery, ale vzorky s ID podmienky<235

(rovnaké n-tice sú farebne zvýraznené)

PRODUCTS.ID	NÁZOV	SPOLOČNOSŤ	CENA	SELLERS.ID	PREDAJCA
123	Cookies	Dark Side LLC	190	123	OOO "Šípka"
156	Čaj	Dark Side LLC	60	156	OJSC "Vedro"
123	Cookies	Dark Side LLC	190	156	OJSC "Vedro"
156	Čaj	Dark Side LLC	60	123	OOO "Šípka"

Ako príklad použitia tejto operácie si predstavte potrebu vybrať predajcov s cenami nižšími ako 90. Bez produktu by bolo potrebné najskôr získať ID produktov z prvej tabuľky a potom pomocou týchto ID z druhej tabuľky získať potrebné Názvy SELLER a pri použití produktu by nasledujúci dotaz bol:

π (SELLER) σ (RODUCTS.ID=SELLERS.ID ^ CENA<90) PRODUCTS × SELLERS

V dôsledku tejto operácie dostaneme vzťah:

PREDAJCA

OJSC "Vedro"

Spojenie a prirodzené spojenie

Operácia spojenia je inverzná k operácii projekcie a vytvára nový vzťah z dvoch existujúcich vzťahov. Nový vzťah sa získa zreťazením n-tic prvého a druhého vzťahu, zatiaľ čo vzťahy, v ktorých sa hodnoty špecifikovaných atribútov zhodujú, podliehajú zreťazeniu. Konkrétne, ak prepojíte vzťahy PRODUKTY a PREDAJCOVIA, tieto atribúty sú atribútmi domén ID.

Tiež si pre názornosť môžete predstaviť spojenie ako výsledok dvoch operácií. Najprv sa vezme súčin zdrojových tabuliek a potom z výsledného vzťahu urobíme výber s podmienkou rovnosti atribútov z rovnakých domén. V tomto prípade je podmienkou rovnosť PRODUCTS.ID a SELLERS.ID.

Skúsme prepojiť vzťahy PRODUKTY a PREDAJCOVIA a získajme vzťah.

PRODUCTS.ID	NÁZOV	SPOLOČNOSŤ	CENA	SELLERS.ID	PREDAJCA
123	Cookies	Dark Side LLC	190	123	OOO "Šípka"
156	Čaj	Dark Side LLC	60	156	OJSC "Vedro"
235	Ananás	OJSC "Frukty"	100	235	CJSC „Zelenina baza“
623	Paradajky	OOO "Zelenina"	130	623	JSC "Firma"

Prirodzené spojenie dostane podobnú reláciu, ale ak máme v databáze správne nakonfigurovanú schému (v tomto prípade je primárny kľúč tabuľky PRODUCTS ID prepojený s cudzím kľúčom tabuľky SELLERS ID), potom výsledná relácia obsahuje iba jedna ID doména.

Syntax operácie:
PRODUKTY ⋈ PREDAJCOVIA;

Dostanete tento vzťah:

PRODUCTS.ID	NÁZOV	SPOLOČNOSŤ	CENA	PREDAJCA
123	Cookies	Dark Side LLC	190	OOO "Šípka"
156	Čaj	Dark Side LLC	60	OJSC "Vedro"
235	Ananás	OJSC "Frukty"	100	CJSC „Zelenina baza“
623	Paradajky	OOO "Zelenina"	130	JSC "Firma"

Priesečník a odčítanie.

Výsledkom operácie prieniku bude vzťah pozostávajúci z n-tic, ktoré sú úplne zahrnuté v oboch vzťahoch.
Výsledkom odčítania bude relácia pozostávajúca z n-tic, ktoré sú n-ticami prvého vzťahu a nie n-ticami druhého vzťahu.
Tieto operácie sú podobné tým istým operáciám na množinách, preto si myslím, že ich netreba podrobne popisovať.

Informačné zdroje

• Základy používania a navrhovania databáz - V. M. Iljushechkin
• kurz prednášok Úvod do databáz - Jennifer Widom, Stanford University

Bol by som vďačný za odôvodnené komentáre

Stručne o dôležitých veciach.

Normalizácia databázy

Prvá normálna forma (1NF)

• žiadne duplicitné skupiny údajov
• atomicita dát je zaručená (všetky dáta sú autonómne a nezávislé).

Na najvyššej úrovni sa to dosiahne vytvorením primárneho kľúča, následným presunom opakujúcich sa skupín údajov do nových tabuliek, vytvorením primárnych kľúčov pre tieto tabuľky atď. Okrem toho musíte rozdeliť všetky záznamy, ktorých stĺpce obsahujú zložené informácie, do samostatných riadkov pre každú časť údajov stĺpca.

Druhá normálna forma (2NF)

• tabuľka spĺňa podmienky 1NF
• každý stĺpec závisí od celého kľúča, nie od jeho časti.

Tretia normálna forma (3NF)

• tabuľka spĺňa podmienky 2NF
• žiadny stĺpec nezávisí od stĺpca, ktorý nie je súčasťou primárneho kľúča
• neobsahuje odvodené údaje

Iné normálne formy, ktoré nemajú veľkú praktickú hodnotu:

Normálna forma Boyce-Codd

Možnosť 3NF. Navrhnuté na riešenie situácie, keď existuje veľa prekrývajúcich sa kandidátskych kľúčov. V skutočnosti neexistuje žiadne logické opodstatnenie mimo akademickej obce.

Štvrtá normálna forma

Navrhnuté na riešenie problémov s viachodnotovými závislosťami. Takéto situácie nastanú, ak v tabuľke zredukovanej na 3NF závisí jeden stĺpec zloženého primárneho kľúča od iného stĺpca primárneho kľúča.

Piata normálna forma

Používa sa pri práci s rozkladom vzťahov so stratami a bez nich. Vzniká v situácii, keď je možné jeden vzťah rozdeliť na viacero rôznych vzťahov, no potom ho už nebudeme môcť logicky vrátiť do pôvodnej podoby.

Šiesta normálna forma (normálna forma kľúča domény)

Zabezpečuje, že v databáze nie sú žiadne anomálie modifikácií. V reálnych podmienkach je to prakticky nedosiahnuteľné.

Vzťah.

Raz som od žien počul, že muži
okamžite sa pokúste opustiť miestnosť, v ktorej
Zaznelo slovo „vzťah“.<...>kľúčom k úspechu
vzťahy je uvedomenie si svojej úlohy každého
v tejto súvislosti, ako aj pravidlá a obmedzenia,
uložené týmto vzťahom.
(C) Robert Viera, „Profesionálne programovanie SQL Server 2000“

Typy vzťahov

• One-to-one (má zmysel, keď je potrebné uložiť zhodné údaje v rôznych databázach alebo keď je prekročená maximálna veľkosť údajov v riadku)
• Nula alebo jedna ku jednej
• Jeden k mnohým
• Jeden až -nula, -jeden alebo -veľa
• Many-to-many (spojovacie tabuľky)

združenia

VNÚTORNÉ SPOJENIE

Exkluzívne pripojenie. Výsledok výberu zahŕňa len tie záznamy tabuľky, ktoré majú v párovej tabuľke zhody pre danú podmienku.

VĽAVO|VPRAVO PRIPOJTE SA

Inkluzívne pripojenie. Výsledok výberu zahŕňa záznamy z tabuľky vľavo/vpravo PRIPOJTE SA resp. V tomto prípade sa doplnia údaje z chýbajúceho „spárovaného“ záznamu NULOVÝ.
FROM left_table LEFT JOIN right_table– všetky záznamy z ľavej tabuľky sú zahrnuté left_table
FROM left_table RIGHT JOIN right_table– všetky záznamy z pravej tabuľky right_table sú zahrnuté

ÚPLNÉ PRIPOJENIE

Inkluzívne pripojenie. Výsledok výberu zahŕňa nielen záznamy, ktoré majú zhodu v druhej tabuľke, ale aj záznamy z oboch tabuliek, pre ktoré nebola nájdená zhoda v druhej tabuľke. V tomto prípade sa údaje z chýbajúceho „spárovaného“ záznamu doplnia hodnotou NULL.

KRÍŽOVÉ PRIPOJENIE

Krížové spojenie (karteziánsky súčin). Každý záznam z jednej tabuľky sa priradí ku každému záznamu z inej tabuľky. Počet výsledných záznamov sa rovná súčinu počtu záznamov v oboch tabuľkách.

Zásady pre usporiadanie niekoľkých PRIPOJTE SA's

Ak potrebujete spojiť niekoľko stolov, musíte si zapamätať dve zásady:

1. Všetky odbory vľavo PRIPOJTE SA spracovávať ako jednu tabuľku na zahrnutie alebo vylúčenie z dotazu.
2. Všetky odbory sú napravo PRIPOJTE SA TIEŽ zaobchádzané ako s jednou tabuľkou na zahrnutie alebo vylúčenie z dotazu.

Dôsledkom týchto zásad je nasledujúce odporúčanie pre vytváranie zložitých asociácií:

• Kedykoľvek je to možné, mali by ste použiť INNER JOIN.
• Ak je potrebné použiť OUTER JOINy, mali by byť umiestnené ako posledné a INNER JOINy ​​by mali byť umiestnené na začiatku spojenia.

P.S. Všetky vyššie uvedené sú všeobecné „postuláty“ teórie relačných databáz, ktoré nie sú spojené s vlastnosťami určitých DBMS.

Dátový model je súbor dátových štruktúr a operácií na ich spracovanie. Pomocou dátového modelu môžete vizuálne znázorniť štruktúru objektov a vzťahy vytvorené medzi nimi. Terminológiu dátového modelu charakterizujú pojmy „údajový prvok“ a „záväzné pravidlá“. Dátový prvok popisuje akúkoľvek množinu údajov a asociačné pravidlá definujú algoritmy na prepojenie dátových prvkov. K dnešnému dňu bolo vyvinutých veľa rôznych dátových modelov, ale v praxi sa používajú tri hlavné. Existujú hierarchické, sieťové a relačné dátové modely. V súlade s tým hovoria o hierarchických, sieťových a relačných DBMS.

O Hierarchický dátový model. Hierarchicky usporiadané údaje sú v každodennom živote veľmi bežné. Napríklad štruktúra vysokej školy je viacúrovňová hierarchická štruktúra. Hierarchická (stromová) databáza pozostáva z usporiadanej množiny prvkov. V tomto modeli počiatočné prvky vedú k ďalším prvkom a tieto prvky zase vedú k ďalším prvkom. Každý podradený prvok má iba jeden nadradený prvok.

Organizačné štruktúry, zoznamy materiálov, obsahy v knihách, plány projektov a mnohé ďalšie súbory údajov môžu byť prezentované v hierarchickej forme. Integrita väzieb medzi predkami a potomkami je automaticky zachovaná. Základné pravidlo: žiadne dieťa nemôže existovať bez svojho rodiča.

Hlavnou nevýhodou tohto modelu je nutnosť použiť pri návrhu hierarchiu, ktorá bola základom databázy. Potreba neustálej reorganizácie dát (a často aj nemožnosť tejto reorganizácie) viedla k vytvoreniu všeobecnejšieho modelu – sieťového modelu.

O Sieťový dátový model. Sieťový prístup k organizácii údajov je rozšírením hierarchického prístupu. Tento model sa líši od hierarchického v tom, že každý generovaný prvok môže mať viac ako jeden generujúci prvok. ■

Pretože sieťová databáza môže priamo reprezentovať všetky druhy vzťahov, ktoré sú vlastné údajom príslušnej organizácie, tieto údaje možno navigovať, skúmať a vyhľadávať rôznymi spôsobmi, to znamená, že sieťový model nie je viazaný len jednou hierarchiou. Na zadanie požiadavky na sieťovú databázu je však potrebné ponoriť sa hlboko do jej štruktúry (mať po ruke schému tejto databázy) a vyvinúť mechanizmus na navigáciu v databáze, čo je významnou nevýhodou tohto databázového modelu. .

O Relačný dátový model. Základnou myšlienkou relačného dátového modelu je reprezentovať akúkoľvek množinu dát ako dvojrozmernú tabuľku. Vo svojej najjednoduchšej forme relačný model popisuje jednu dvojrozmernú tabuľku, ale častejšie model opisuje štruktúru a vzťahy medzi niekoľkými rôznymi tabuľkami.

Relačný dátový model

Čiže účelom informačného systému je spracovávať údajov o predmety skutočný svet, berúc do úvahy spojenia medzi objektmi. V teórii databáz sa dáta často nazývajú atribúty a predmety - subjektov. Objekt, atribút a spojenie sú základnými pojmami I.S.

Objekt(alebo podstata) je niečo, čo existuje a rozlíšiteľné, to znamená, že objekt možno nazvať tým „niečím“, pre ktoré existuje názov a spôsob, ako odlíšiť jeden podobný objekt od druhého. Napríklad každá škola je objekt. Predmety sú tiež osoba, trieda v škole, firma, zliatina, chemická zlúčenina atď. Predmetmi môžu byť nielen hmotné predmety, ale aj abstraktnejšie pojmy, ktoré odrážajú skutočný svet. Napríklad udalosti, regióny, umelecké diela; knihy (nie ako tlačené produkty, ale ako diela), divadelné predstavenia, filmy; právne normy, filozofické teórie a pod.

Atribút(alebo daný)- ide o určitý ukazovateľ, ktorý charakterizuje určitý objekt a nadobúda určitú číselnú, textovú alebo inú hodnotu pre konkrétnu inštanciu objektu. Informačný systém pracuje so súbormi objektov navrhnutých vo vzťahu k danej tematickej oblasti, s využitím špecifických hodnoty atribútov(údaje) určitých objektov. Vezmime si napríklad hodiny v škole ako súbor predmetov. Počet žiakov v triede je údaj, ktorý nadobúda číselnú hodnotu (jedna trieda má 28, druhá 32). Názov triedy je daný, ktorý má textovú hodnotu (jedna má 10A, druhá 9B atď.).

Vývoj relačných databáz sa začal koncom 60. rokov, keď sa objavili prvé práce, ktoré diskutovali; možnosť využitia známych a prirodzených spôsobov prezentácie údajov – takzvané tabuľkové datalogické modely – pri navrhovaní databáz.

Za zakladateľa teórie relačných databáz je považovaný zamestnanec IBM Dr.E.Codd, ktorý publikoval článok 6.6.1970 Relačný model dát pre veľké zdieľané dátové banky(Relačný dátový model pre veľké kolektívne databanky). Tento článok bol prvým, ktorý použil výraz „relačný dátový model“. Teória relačných databáz, vyvinutá v 70. rokoch v USA Dr. E. Coddom, má silný matematický základ, ktorý popisuje pravidlá efektívneho usporiadania údajov. Teoretický rámec vypracovaný E. Coddom sa stal základom pre rozvoj teórie návrhu databáz.

E. Codd, vyštudovaný matematik, navrhol použiť na spracovanie údajov aparát teórie množín (zjednotenie, prienik, rozdiel, karteziánsky súčin). 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 „relácie“.

Relačný Za databázu sa považuje taká, v ktorej sú všetky údaje používateľovi prezentované vo forme pravouhlých tabuliek údajových hodnôt a všetky operácie s databázou sú redukované na manipuláciu s tabuľkami.

Stôl sa skladá z stĺpce (polia) A linky (záznamy); má názov, ktorý je v rámci databázy jedinečný. Tabuľka odráža Typ objektu reálny svet (subjekt), a každý z nej reťazec je špecifický objekt. Každý stĺpec tabuľky je zbierka hodnôt pre konkrétny atribút objektu. Hodnoty sa vyberajú z množiny všetkých možných hodnôt pre atribút objektu, ktorý sa nazýva 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ým booleovským výrazom aplikovaným na dátové prvky. Ak vyhodnotíte boolovskú podmienku na dátovej položke a výsledok je pravdivý, potom táto položka patrí do domény. V najjednoduchšom prípade je doména definovaná ako platný potenciálny súbor hodnôt rovnakého typu. Napríklad zber dátumov narodenia všetkých zamestnancov predstavuje „doménu dátumu narodenia“ a mená všetkých zamestnancov tvoria „doménu mena zamestnanca“. Doména dátumu narodenia musí mať typ údajov v určitom čase a doména mena zamestnanca musí mať typ údajov znak.

Ak dve hodnoty pochádzajú z rovnakej domény, potom je možné tieto dve hodnoty porovnať. Napríklad, ak sú dve hodnoty prevzaté z domény dátumov narodenia, môžete ich porovnať a určiť, ktorý zamestnanec je starší. Ak sú hodnoty prevzaté z rôznych domén, ich porovnanie nie je povolené, pretože to s najväčšou pravdepodobnosťou nedáva zmysel. Napríklad z porovnania mena a dátumu narodenia zamestnanca nebude nič isté.

Každý stĺpec (pole) má svoj názov, ktorý sa zvyčajne píše v hornej časti tabuľky. Pri návrhu tabuliek v rámci konkrétneho DBMS je možné vybrať pre každé pole jeho typ, teda definovať súbor pravidiel pre jeho zobrazovanie, ako aj určiť operácie, ktoré možno vykonávať s údajmi uloženými v tomto poli. Súbory typov sa môžu medzi rôznymi DBMS líšiť.

Názov poľa musí byť v tabuľke jedinečný, ale rôzne tabuľky môžu mať polia s rovnakým názvom. Každá tabuľka musí mať aspoň jedno pole; Polia sú v tabuľke umiestnené v súlade s poradím, v akom sa ich názvy objavili pri jej vytvorení. Na rozdiel od polí reťazce nemajú názvy; ich poradie v tabuľke nie je definované a ich počet je logicky neobmedzený.

Keďže riadky v tabuľke nie sú zoradené, nie je možné vybrať riadok podľa jeho polohy - medzi nimi nie je „prvý“, „druhý“ alebo „posledný“. Každá tabuľka má jeden alebo viac stĺpcov, ktorých hodnoty jednoznačne identifikujú každý z jej riadkov. Takýto stĺpec (alebo kombinácia stĺpcov) sa nazýva primárny kľúč. Umelé pole sa často zavádza do číselných záznamov v tabuľke. Takýmto poľom môže byť napríklad jeho radové pole, ktoré dokáže zabezpečiť jedinečnosť každého záznamu v tabuľke. Kľúč musí mať nasledujúce vlastnosti.

Jedinečnosť. V žiadnom danom čase žiadne dve rôzne relačné n-tice nemajú rovnakú hodnotu pre kombináciu atribútov zahrnutých v kľúči. To znamená, že v tabuľke nemôžu byť dva riadky, ktoré majú rovnaké identifikačné číslo alebo číslo pasu.

Minimalizmus.Žiadny z atribútov zahrnutých v kľúči nemožno vylúčiť z kľúča bez porušenia jedinečnosti. To znamená, že by ste nemali vytvárať kľúč, ktorý obsahuje číslo pasu aj identifikačné číslo. Na jednoznačnú identifikáciu n-tice stačí použiť ktorýkoľvek z týchto atribútov. Do kľúča by ste tiež nemali zahrnúť nejedinečný atribút, to znamená, že používanie kombinácie identifikačného čísla a mena zamestnanca ako kľúča je zakázané. Vylúčením mena zamestnanca z kľúča je možné stále jednoznačne identifikovať každý riadok.

Každý vzťah má aspoň jeden možný kľúč, keďže súhrn všetkých jeho atribútov spĺňa podmienku jedinečnosti – vyplýva to zo samotnej definície vzťahu.

Jeden z možných kľúčov je náhodne vybraný ako primárny kľúč. Zostávajúce možné kľúče, ak existujú, sa berú ako alternatívne kľúče. Ak napríklad vyberiete identifikačné číslo ako primárny kľúč, číslo pasu bude alternatívnym kľúčom.

Vzťah tabuliek je najdôležitejším prvkom relačného dátového modelu. Je podporovaný cudzie kľúče.

Pri popise modelu relačnej databázy sa často pre ten istý koncept používajú rôzne výrazy v závislosti od úrovne popisu (teória alebo prax) a systému (Access, SQL Server, dBase). V tabuľke 2.3 poskytuje súhrn použitých výrazov.

Tabuľka 2.3. Terminológia databázy

Teória databáz____________ Relačné databázy_________ SQL Server __________

Tabuľka vzťahov Tabuľka Tabuľka

Tuple Record Row

AttributeField________________Stĺpec

Relačné databázy

Relačná databáza je množina vzťahov obsahujúcich všetky informácie, ktoré musia byť uložené v databáze. To znamená, že databáza predstavuje súbor tabuliek potrebných na uloženie všetkých údajov. Tabuľky relačnej databázy spolu logicky súvisia Požiadavky na návrh relačnej databázy vo všeobecnosti možno zredukovať na niekoľko pravidiel.

О Každá tabuľka má v databáze jedinečný názov a skladá sa z riadkov rovnakého typu.

O Každá tabuľka pozostáva z pevného počtu stĺpcov a hodnôt. Do jedného riadkového stĺpca nemožno uložiť viac ako jednu hodnotu. Napríklad, ak existuje tabuľka s informáciami o autorovi, dátume vydania, náklade atď., potom stĺpec s menom autora nemôže uložiť viac ako jedno priezvisko. Ak knihu napísali dvaja alebo viacerí autori, budete musieť použiť ďalšie tabuľky.

O V tabuľke sa v žiadnom okamihu nenachádzajú dva riadky, ktoré sa navzájom duplikujú. Riadky sa musia líšiť aspoň v jednej hodnote, aby bolo možné jednoznačne identifikovať ktorýkoľvek riadok v tabuľke.

О Každý stĺpec má v tabuľke priradený jedinečný názov; je preň nastavený špecifický dátový typ tak, že v tomto stĺpci sú umiestnené homogénne hodnoty (dátumy, priezviská, telefónne čísla, peňažné sumy atď.).

O Kompletný informačný obsah databázy je reprezentovaný ako explicitné hodnoty samotných údajov a toto je jediný spôsob reprezentácie. Napríklad vzťahy medzi tabuľkami sú založené na údajoch uložených v zodpovedajúcich stĺpcoch a nie na základe ukazovateľov, ktoré umelo definujú vzťahy.

О Pri spracovaní údajov máte voľný prístup k akémukoľvek riadku alebo stĺpcu tabuľky. Hodnoty uložené v tabuľke neobmedzujú poradie, v ktorom sa k údajom pristupuje. Popis stĺpcov,