Anotace: Tato a další dvě přednášky jsou věnovány teorii relačních databází. Vzhledem k tomu, že celý relační přístup k organizaci databáze je čistě praktický, je tato teorie především pragmatická. Hlavním problémem, který se teorie relačních databází snaží vyřešit, je objevování užitečných vlastností určitých databázových schémat a vývoj způsobů, jak taková schémata konstruovat. Tento problém je běžně stručně označován jako problém návrhu relační databáze.

Úvod

Navzdory svému praktickému zaměření teorie relačních databází je samostatný vědecký obor, ve kterém působilo (a působí) mnoho slavných badatelů, jejichž jména se objeví v našich přednáškách. V tomto kurzu jsme neměli v plánu podrobně popisovat hlavní výsledky v oboru. Naším cílem je poskytnout pouze definice a prohlášení nezbytná pro obecné pochopení procesu návrh relační databáze na základě normalizace.

Protože nejdůležitější vlastnosti relačních databází z praktického hlediska jsou založeny na konceptu funkční závislost, stručné pojednání o relevantních teoretických otázkách jsme zařadili do samostatné přednášky. Mezi tyto otázky patří uzávěry a pokrývající sady funkčních závislostí, Armstrongovy axiomy a Heathova věta o dostatečné podmínce bezztrátový rozklad vztahu. Pojmy a výroky této přednášky jsou skutečně nezbytné pro zvládnutí látky v přednášce 7, ale také jsme se snažili čtenářům na jednoduchých příkladech demonstrovat, co to je teorie relačních databází, jakou má úroveň složitosti a jak je intuitivní.

Všimněte si, že jsme neoddělovali teoretický materiál týkající se vícehodnotové závislosti A závislosti připojení. To bylo provedeno ze dvou důvodů. Za prvé, tyto typy závislostí jsou v modelování méně běžné předmětová oblast pomocí databází. Považovali jsme proto za dostatečné předložit v rámci přednášky 8 pouze základy příslušného teoretického materiálu. Za druhé, i když teorie vícehodnotové závislosti A závislosti připojení ve skutečnosti není o moc složitější než teorie funkčních závislostí, jeho definice a prohlášení jsou pro tento kurz příliš těžkopádné.

Funkční závislosti

Nejdůležitější z praktického hlediska normální formy vztahů jsou založeny na zákl teorie relačních databází pojem funkční závislost. Pro další prezentaci budeme potřebovat několik definic a tvrzení (vysvětlíme a ilustrujeme je v průběhu).

Obecné definice

Ať je dáno vztahová proměnná r a X a Y jsou libovolné podmnožiny hlavičky r ("složené" atributy).

Ve smyslu vztahová proměnná r atribut Y je funkčně závislý na atributu X právě tehdy, když každá hodnota X odpovídá právě jedné hodnotě Y. V tomto případě se také říká, že atribut X funkčně definuje atribut Y (X je determinant ( determinant) pro Y a Y je závislé na X). Označíme to jako r.X->r.Y .

Například použijeme vztah EMPLOYEE_PROJECTS (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(obr. 6.1). Samozřejmě, pokud je SLU_NOM primární klíč vztahu ZAMĚSTNANCI, tak pro tento vztah je to fér funkční závislost (FD) SLN_NAME->SERV_NAME .

Vlastně pro tělo vztahu PROJEKTY ZAMĚSTNANCŮ ve formě, ve které je znázorněn na obr. 6.1 se také provádějí následující FD (1):

Rýže. 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_NOM)_NAME)-> PRO_SLUN_NAME, PROJECT_PROM, PROJECT_RUK K a atd.

Vzhledem k tomu, že jména všech zaměstnanců jsou různá, jsou splněna také následující FD (2):

SERV_NAME->SERV_NAME SERV_NAME->SLU_ZARP SER_NAME->PRO_NAME atd.

Navíc pro příklad na Obr. 6.1 je splněno a FD (3):

SLU_ZARP->PRO_NOM

Všimněte si však, že povaha skupiny FD (1) se liší od povahy skupin FD (2) a (3). Je logické předpokládat, že identifikační čísla zaměstnanců by měla být vždy jiná a každý projekt má pouze jednoho manažera. Proto FD skupiny (1) musí být pravdivé pro jakoukoli platnou hodnotu vztahová proměnná PROJEKTY ZAMĚSTNANCŮ a lze je považovat za invarianty nebo integritní omezení tento vztahová proměnná.

Skupinové FD (2) jsou založeny na méně přirozeném předpokladu, že všichni zaměstnanci mají různá jména. To platí pro příklad na obr. 6.1, ale je možné, že časem skupiny FD (2) nebudou uspokojeny pro žádnou hodnotu vztahová proměnná PROJEKTY ZAMĚSTNANCŮ.

Konečně, FD skupiny (3) je založeno na velmi nepřirozeném předpokladu, že žádní dva zaměstnanci zapojení do různých projektů nedostávají stejnou mzdu. Tento předpoklad opět platí pro příklad na obr. 6.1, ale s největší pravděpodobností se jedná o náhodu.

V budoucnu nás budou zajímat pouze ty funkčních závislostí, která musí být splněna pro všechny možné hodnoty vztahové proměnné.

Všimněte si, že pokud je atribut A vztahu r možným klíčem, pak pro jakýkoli atribut B tohoto vztahu vždy platí

PROGRAMOVÁNÍ V PROSTŘEDÍ DELPHI 6

Databáze. Vytvořte sestavu pomocí aplikace Word.

Schváleno redakční a vydavatelskou radou

univerzitě jako laboratorní dílna

Voroněž 2004

MDT 681,3

Vorobyov E.I., Korotkevich D.E.. Programování v prostředí Delphi 6: Laboratorní workshop: 2. část: Databáze. Vytvořte sestavu pomocí aplikace Word. Proudy. Voroněž: Voroněž. Stát tech. Univ., 2004. 107 s.

Druhá část laboratorního workshopu pojednává o teoretických a praktických informacích pro psaní programů v prostředí Delphi 6 na téma: „Návrh databází, vytváření sestav ve Wordu a využití vláken při tvorbě vysoce výkonných aplikací.“

Publikace splňuje požadavky Státního vzdělávacího standardu vyššího odborného vzdělávání ve směru 230100 „Informatika a informatika“, obor 230104 „Systémy počítačově podporovaného navrhování“, obor „Programování ve vyšších jazycích“.

Stůl 3. Il. 19. Bibliografie: 7 titulů.

Vědecký redaktor: Dr. Tech. věd, prof. Ya.E. Lvovič

Recenzenti: Katedra informatiky Voroněžské lesnické akademie (vedoucí katedry, doktor technických věd, prof. V.E. Mezhov);

Dr. Tech. věd, prof. O.Yu.Makarov

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

© Design. Voroněžský stát

Technická univerzita, 2004

Úvod

Koncept databáze

Databáze jsou považovány za hlavní výhodu Delphi. I specializované jazyky pro práci s databázemi (jako je MS Visual FoxPro) jsou z hlediska jednoduchosti a programátorské síly pro tento typ aplikací jednoznačně horší. Delphi skrývá veškerou složitost a zároveň dává největší výkon. Nikdy neexistoval úkol, který by nebylo možné v Delphi implementovat během krátké doby. A hlavní věc je, že to vše je implementováno velmi pohodlně a snadno pochopitelné. V Delphi můžete vytvářet jednoduché aplikace i se složitými databázemi bez jediného řádku kódu. Tento tutoriál pokrývá laboratorní úlohy pro zvládnutí technik pro práci s lokálními databázemi.

Teorie relačních databází

Před deseti lety bylo programování databází velmi obtížným úkolem. V dnešní době si to lze jen těžko představit, protože díky Delphi se zjednodušil proces psaní programů a počet variant databází je již v desítkách.

Databáze se dělí na lokální (instalované na klientském počítači, kde program běží) a vzdálené (instalované na server, vzdálený počítač). Serverové databáze jsou umístěny na vzdáleném počítači a běží pod kontrolou serverového softwaru. Mezi jejich hlavní výhody patří možnost pracovat s jednou databází současně více uživateli a zároveň minimální zatížení sítě. Existují také síťové databáze, které příliš zatěžují síť a jejich použití je nepohodlné jak pro programátora, tak pro koncového uživatele. Když se program připojí k síťové databázi, stáhne si téměř kompletní její kopii ze serveru. Pokud jste provedli změny, vaše kopie bude kompletně stažena zpět. To je velmi nepohodlné, protože to vytváří velké zatížení sítě kvůli nadměrnému přenosu dat. V technologii klient-server odešle klientský program serveru jednoduchý textový požadavek na přijetí některých dat. Server je zpracuje a vrátí pouze požadovanou část dat. Když potřebujete změnit některá data, je na server znovu odeslán požadavek na jejich změnu a server změní data ve své databázi. Po síti se tak přenášejí převážně pouze textové požadavky, které obecně zabírají méně než kilobajt. Všechna data zpracovává server, což znamená, že klientský stroj je zatěžován mnohem méně a není tak náročný na zdroje. Server posílá klientovi pouze nejnutnější data, takže nedochází ke zbytečnému stahování kopie celé databáze. Díky tomu všemu jsou síťové databáze již zastaralé a prakticky se nepoužívají. Jsou téměř zcela nahrazeny technologií klient-server. Ale místní databáze budou vždy žít. Může se změnit formát jejich úložiště nebo přidat nějaké nové funkce, ale samotné databáze budou existovat. Pro další zvážení musíme definovat nový koncept - stůl. Dosud byly diskutovány pouze obecné principy, takže byl použit obecný koncept databází. Databázová tabulka je jako dvourozměrné pole, ve kterém jsou data uspořádána do sloupce (ukázkovým příkladem tabulky je Excel). Databáze je, zhruba řečeno, pouze soubor, do kterého lze uložit jednu až několik tabulek. Většina lokálních databází může ukládat pouze jednu tabulku (dBase, Paradox, XML). Existují však zástupci lokálních databází, kde je v jednom souboru obsaženo několik tabulek (například Access).

Lokální databáze

Mezi lokálními databázemi považujme za nejběžnější ty relační. Co je to relační databáze? Jedná se o tabulku, ve které jsou ve sloupcích názvy dat v ní uložených a každý řádek ukládá data sama. Databázová tabulka je podobná excelové tabulce (přesněji Excel ukládá svá data v proprietárním formátu postaveném na databázové technologii). Lokální databázové tabulky mohou být uloženy na lokálním pevném disku nebo centrálně uloženy na síťovém disku na souborovém serveru. Tyto soubory lze kopírovat pomocí standardních nástrojů jako jakýkoli jiný soubor, protože samotné databázové tabulky nejsou svázány s konkrétním umístěním. Hlavní věc je, že program umí najít tabulku. Každá tabulka musí mít jedno jedinečné pole, které bude jednoznačně identifikovat řádek. Toto pole se nazývá klíčové pole. Tato pole se velmi často používají k propojení několika tabulek dohromady. Ale i když tabulka nesouvisí, pole klíče je stále povinné. Jako klíč je vhodné použít číselný typ a pokud to databáze umožňuje, bude lepší, když bude typu „autoincrement“ (automaticky se zvyšuje/snižuje číslo nebo počítadlo). Názvy sloupců v databázové tabulce musí být také jedinečné, ale v tomto případě nemusí být nutně číselné. Mohou se jmenovat jak chcete, pokud je to jedinečné a srozumitelné. Každý sloupec (databázové pole) musí mít specifický typ. Počet typů a jejich variet závisí na typu databáze, například formát dBASE (soubory s příponou DBF) podporuje pouze 6 typů a Paradox již podporuje až 15. Databáze může být uložena v jednom souboru (Přístup ) nebo v několika (Paradox, dBase). Přesněji řečeno, data tabulky jsou vždy uložena v jednom souboru, ale další informace mohou být umístěny v samostatných souborech. Další informace mohou zahrnovat indexy, omezení nebo seznam výchozích hodnot pro konkrétní pole. Pokud dojde k poškození nebo odstranění alespoň jednoho ze souborů, data nemusí být dostupná pro úpravy.

Co se stalo indexy? Data z tabulek velmi často procházejí určitými změnami, takže než upravíte jakýkoli řádek, musíte jej najít. Dokonce i statické tabulky používané jako referenční knihy jsou před zobrazením požadovaných dat také předmětem vyhledávacích operací. Vyhledávání je poměrně časově náročná operace, zvláště pokud tabulka obsahuje mnoho řádků. Indexy jsou zaměřeny na urychlení tohoto postupu a mohou být také použity jako výchozí bod pro třídění. V této fázi stačí vědět, že neindexované pole nelze objednat.

Pokud potřebujete nějaký stůl objednat podle pole " Příjmení“, pak musí být toto pole nejprve indexováno. Pak už jen stačí naznačit, že tabulka má nyní pracovat s takovým a takovým indexem a automaticky se seřadí.

V dobře navržené databázi je eliminována redundance dat a minimalizována pravděpodobnost ukládání nekonzistentních dat. Vytváření databází má tedy dva hlavní cíle: snížit redundanci dat a zvýšit jejich spolehlivost.

Životní cyklus jakéhokoli softwarového produktu, včetně systému správy databází, se skládá (z velké části) z fází návrhu, implementace a provozu.

Nejvýznamnějším faktorem v životním cyklu databázové aplikace je přirozeně fáze návrhu. Výkon systému a jeho informační bohatost a tím i životnost závisí na tom, jak pečlivě je promyšlena struktura databáze a jak jasně jsou definovány vazby mezi jejími prvky.

Požadavky na databázi

Takže dobře navržená databáze:

1. Splňuje všechny požadavky uživatelů na obsah databáze. Před návrhem databáze je nutné provést rozsáhlý průzkum požadavků uživatelů na funkčnost databáze.

2. Zajišťuje konzistenci a integritu dat. Při návrhu tabulek je potřeba definovat jejich atributy a některá pravidla, která omezují možnost uživatele zadávat nesprávné hodnoty. Aby bylo možné ověřit data před jejich přímým zápisem do tabulky, musí databáze zavolat pravidla datového modelu a tím zajistit zachování integrity informací.

3. Poskytuje přirozené, snadno pochopitelné strukturování informací. Vysoce kvalitní konstrukce databáze umožňuje učinit dotazy do databáze „transparentnějšími“ a srozumitelnějšími; V důsledku toho se snižuje pravděpodobnost zadání nesprávných údajů a zlepšuje se kvalita údržby databáze.

4. Splňuje požadavky uživatelů na výkon databáze. S velkými objemy informací, problémy s udržením produktivity

začnou hrát hlavní roli a okamžitě „zvýrazní“ všechny nedostatky ve fázi návrhu.

Následující body představují základní kroky návrhu databáze:

1. Určete informační potřeby databáze.

2. Analyzujte objekty reálného světa, které je třeba modelovat v databázi. Z těchto objektů vytvořte entity a charakteristiky těchto entit (např. pro entitu „díl“ mohou být charakteristiky „název“, „barva“, „váha“ atd.) a vytvořte jejich seznam.

3. Spojte entity a charakteristiky - tabulky a sloupce (pole) v notaci vámi zvoleného DBMS (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle atd.).

4. Definujte atributy, které jednoznačně identifikují každý objekt.

5. Vytvořte pravidla, která vytvoří a udrží integritu dat.

6. Navazovat spojení mezi objekty (tabulkami a sloupci), normalizovat tabulky.

7. Plánujte otázky spolehlivosti dat a v případě potřeby zachování tajnosti informací.

Související informace.

Relační algebra je založena na teorii množin a je základem databázové logiky.
Když jsem teprve studoval strukturu databází a SQL, tak předběžné seznámení s relační algebrou velmi pomohlo k tomu, aby se mi další poznatky správně vešly do hlavy a pokusím se, aby tento článek měl podobný efekt.

Takže pokud se chystáte začít studovat v této oblasti nebo vás to jen zajímá, klikněte prosím na kočku.

Relační databáze

Nejprve si představíme koncept relační databáze, ve které budeme provádět všechny akce.

Relační databáze je kolekce vztahů, které obsahují všechny informace, které musí být v databázi uloženy. V této definici nás zajímá pojem relace, ale zatím jej ponecháme bez striktní definice.
Pojďme si lépe představit tabulku produktů.

Tabulka PRODUKTY

ID	NÁZEV	SPOLEČNOST	CENA
123	Soubory cookie	Dark Side LLC	190
156	Čaj	Dark Side LLC	60
235	Ananas	OJSC "Frukty"	100
623	Rajčata	OOO "Zelenina"	130

Tabulka se skládá ze 4 řádků, řádek v tabulce je v relační teorii n-tice. Množina uspořádaných n-tic se nazývá relace.
Před definováním vztahu si uveďme další pojem – doménu. Domény ve vztahu k tabulce jsou sloupce.

Pro přehlednost nyní zavedeme striktní definici vztahu.

Nechť je dáno N množin D1,D2, …. Dn (domény), relace R nad těmito množinami je množina uspořádaných N-tic tvaru , kde d1 patří k D1 atd. Množiny D1,D2,..Dn nazýváme definičními obory relace R.
Každý prvek n-tice představuje hodnotu jednoho z atributů odpovídajících jedné z domén.

Klíče ve vztazích

Ve vztahu je požadavkem, že všechny n-tice musí být odlišné. Pro jednoznačnou identifikaci n-tice existuje primární klíč. Primární klíč je atribut nebo sada minimálního počtu atributů, která jednoznačně identifikuje konkrétní n-tici a neobsahuje žádné další atributy.
Z toho vyplývá, že všechny atributy v primárním klíči musí být nezbytné a dostatečné k identifikaci konkrétní n-tice a vynechání kteréhokoli z atributů v klíči způsobí, že nebude pro identifikaci stačit.
Například v takové tabulce bude klíčem kombinace atributů z prvního a druhého sloupce.

tabulka ŘIDIČE

Je vidět, že organizace může mít několik řidičů, a aby bylo možné řidiče jednoznačně identifikovat, je vyžadována jak hodnota ze sloupce „Název organizace“, tak ze sloupce „Jméno řidiče“. Takový klíč se nazývá složený klíč.

V relační databázi jsou tabulky vzájemně propojeny a vztaženy k sobě jako hlavní a podřízené tabulky. Spojení mezi hlavní a podřízenou tabulkou se provádí prostřednictvím primárního klíče hlavní tabulky a cizího klíče podřízené tabulky.
Cizí klíč je atribut nebo sada atributů, které jsou primárním klíčem v hlavní tabulce.

Tato přípravná teorie postačí k seznámení se základními operacemi relační algebry.

Operace relační algebry

Základních osm operací relační algebry navrhl E. Codd.

• Sdružení
• Průsečík
• Odčítání
• kartézský součin
• Vzorek
• Projekce
• Sloučenina
• Divize

První polovina operací je podobná stejným operacím na množinách. Některé operace lze vyjádřit jako jiné operace. Podívejme se na většinu operací s příklady.

Pro pochopení je důležité si uvědomit, že výsledkem jakékoli algebrické operace na relacích je další vztah, který pak lze použít v dalších operacích.
Vytvořme si další tabulku, která se nám bude hodit v příkladech.

Tabulka SELLERS

ID	PRODEJCE
123	OOO "Šipka"
156	OJSC "Vedro"
235	CJSC “Zelenina baza”
623	JSC "Firma"

Shodneme se, že v této tabulce je ID cizí klíč spojený s primárním klíčem tabulky PRODUKTY.

Nejprve se podívejme na nejjednodušší operaci – název vztahu. Jeho výsledkem bude stejná relace, tedy provedením operace PRODUKTY obdržíme kopii vztahu PRODUKTY.

Projekce

Projekce je operace, při které se atributy z relace extrahují pouze ze zadaných domén, to znamená, že se z tabulky vyberou pouze nezbytné sloupce, a pokud se získá několik stejných n-tic, zůstane v výsledný vztah.
Udělejme například projekci na tabulku PRODUKTY tak, že z ní vybereme ID a CENU.

Syntaxe operace:
π (ID, CENA) PRODUKTY

Ve vzorové podmínce můžeme použít libovolný booleovský výraz. Udělejme další výběr s cenou větší než 90 a ID produktu menším než 300:

σ(CENA>90^ID<300) PRODUCTS

Násobení

Násobení neboli kartézský součin je operace prováděná na dvou relacích, v důsledku čehož ze dvou počátečních relací získáme relaci se všemi definičními obory. N-tice v těchto doménách budou všechny možné kombinace n-tic z počátečních vztahů. Na příkladu to bude jasnější.

Získáváme kartézský součin tabulek PRODUCTS a SELLERS.
Syntaxe operace:

PRODUKTY × PRODEJCI
Všimnete si, že tyto dvě tabulky mají stejnou doménu ID. V této situaci mají domény se stejným názvem předponu s názvem odpovídajícího vztahu, jak je znázorněno níže.
Pro stručnost nenásobme úplné poměry, ale vzorky s ID podmínky<235

(stejné n-tice jsou barevně zvýrazněny)

PRODUCTS.ID	NÁZEV	SPOLEČNOST	CENA	SELLERS.ID	PRODEJCE
123	Soubory cookie	Dark Side LLC	190	123	OOO "Šipka"
156	Čaj	Dark Side LLC	60	156	OJSC "Vedro"
123	Soubory cookie	Dark Side LLC	190	156	OJSC "Vedro"
156	Čaj	Dark Side LLC	60	123	OOO "Šipka"

Pro příklad použití této operace si představte potřebu vybrat prodejce s cenami nižšími než 90. Bez produktu by bylo nutné nejprve získat ID produktů z první tabulky, poté pomocí těchto ID z druhé tabulky získat potřebné Jména SELLER a pomocí produktu by následující dotaz byl:

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

V důsledku této operace získáme vztah:

PRODEJCE

OJSC "Vedro"

Spojení a přirozené spojení

Operace spojení je inverzní operace promítání a vytváří nový vztah ze dvou existujících. Nový vztah se získá zřetězením n-tic prvního a druhého vztahu, zatímco vztahy, ve kterých se hodnoty zadaných atributů shodují, podléhají zřetězení. Konkrétně, pokud propojíte vztahy PRODUKTY a PRODEJCI, jsou tyto atributy atributy domén ID.

Také si pro názornost můžete představit spojení jako výsledek dvou operací. Nejprve se vezme součin zdrojových tabulek a poté z výsledného vztahu provedeme výběr s podmínkou rovnosti atributů ze stejných domén. V tomto případě je podmínkou rovnost PRODUCTS.ID a SELLERS.ID.

Zkusme propojit vztahy PRODUKTY a PRODEJCI a získat vztah.

PRODUCTS.ID	NÁZEV	SPOLEČNOST	CENA	SELLERS.ID	PRODEJCE
123	Soubory cookie	Dark Side LLC	190	123	OOO "Šipka"
156	Čaj	Dark Side LLC	60	156	OJSC "Vedro"
235	Ananas	OJSC "Frukty"	100	235	CJSC “Zelenina baza”
623	Rajčata	OOO "Zelenina"	130	623	JSC "Firma"

Přirozené spojení obdrží podobnou relaci, ale pokud máme v databázi správně nakonfigurované schéma (v tomto případě je primární klíč tabulky PRODUCTS ID propojen s cizím klíčem tabulky SELLERS ID), pak výsledná relace obsahuje pouze jedna ID doména.

Syntaxe operace:
PRODUKTY ⋈ PRODEJCI;

Dostanete tento vztah:

PRODUCTS.ID	NÁZEV	SPOLEČNOST	CENA	PRODEJCE
123	Soubory cookie	Dark Side LLC	190	OOO "Šipka"
156	Čaj	Dark Side LLC	60	OJSC "Vedro"
235	Ananas	OJSC "Frukty"	100	CJSC “Zelenina baza”
623	Rajčata	OOO "Zelenina"	130	JSC "Firma"

Průnik a odčítání.

Výsledkem operace průniku bude relace sestávající z n-tic, které jsou zcela zahrnuty v obou relacích.
Výsledkem odečítání bude relace skládající se z n-tic, které jsou n-ticemi první relace a nikoli n-ticemi druhé relace.
Tyto operace jsou podobné stejným operacím na množinách, takže si myslím, že není třeba je podrobně popisovat.

Informační zdroje

• Základy používání a navrhování databází - V. M. Iljushechkin
• kurz přednášek Úvod do databází - Jennifer Widom, Stanford University

Byl bych vděčný za rozumné komentáře

Krátce o důležitých věcech.

Normalizace databáze

První normální forma (1NF)

• žádné duplicitní datové skupiny
• atomicita dat je zaručena (všechna data jsou autonomní a nezávislá).

Na nejvyšší úrovni je toho dosaženo vytvořením primárního klíče, následným přesunem opakujících se skupin dat do nových tabulek, vytvořením primárních klíčů pro tyto tabulky a tak dále. Kromě toho musíte rozdělit všechny záznamy, jejichž sloupce obsahují složené informace, do samostatných řádků pro každou část dat sloupce.

Druhá normální forma (2NF)

• tabulka splňuje podmínky 1NF
• každý sloupec závisí na celém klíči, nikoli na jeho části.

Třetí normální forma (3NF)

• tabulka splňuje podmínky 2NF
• žádný sloupec nezávisí na sloupci, který není součástí primárního klíče
• neobsahuje odvozená data

Další normální formy, které nemají velkou praktickou hodnotu:

Boyce-Codd normální forma

Možnost 3NF. Navrženo pro řešení situace, kdy existuje mnoho překrývajících se kandidátských klíčů. Mimo akademickou obec vlastně neexistuje žádné logické zdůvodnění.

Čtvrtá normální forma

Navrženo pro řešení problémů s vícehodnotovými závislostmi. Takové situace nastanou, pokud v tabulce redukované na 3NF závisí jeden sloupec složeného primárního klíče na jiném sloupci primárního klíče.

Pátá normální forma

Používá se při práci s rozkladem vztahů se ztrátami a bez nich. Vzniká v situaci, kdy je možné rozdělit jeden vztah na více různých vztahů, ale poté jej již nebudeme schopni logicky vrátit do původní podoby.

Šestá normální forma (normální forma klíče domény)

Zajišťuje, že v databázi nejsou žádné anomálie úprav. V reálných podmínkách je prakticky nedosažitelná.

Vztah.

Kdysi jsem od žen slyšel, že muži
okamžitě se pokuste opustit místnost, ve které
Bylo slyšet slovo „vztah“.<...>klíčem k úspěchu
vztahy je vědomí každého o své roli
v tomto ohledu, jakož i pravidla a omezení,
vynucené tímto vztahem.
(C) Robert Viera, „Profesionální programování SQL Server 2000“

Typy vztahů

• One-to-one (má smysl, když je třeba ukládat odpovídající data do různých databází nebo když je překročena maximální velikost dat řádku)
• Nula nebo jedna ku jedné
• Jeden k mnoha
• Jedna až -nula, -jedna nebo -mnoho
• Many-to-many (spojovací tabulky)

Asociace

VNITŘNÍ SPOJENÍ

Exkluzivní spojení. Výsledek výběru zahrnuje pouze ty záznamy tabulky, které mají v párové tabulce shody pro danou podmínku.

PŘIPOJTE SE VLEVO|VPRAVO

Inkluzivní připojení. Výsledek výběru zahrnuje záznamy z tabulky vlevo/vpravo PŘIPOJIT respektive. V tomto případě se doplní údaje z chybějícího „spárovaného“ záznamu NULA.
FROM left_table LEFT JOIN right_table– všechny záznamy z levé tabulky jsou zahrnuty left_table
FROM left_table RIGHT JOIN right_table– jsou zahrnuty všechny záznamy z pravé tabulky right_table

PLNÉ PŘIPOJENÍ

Inkluzivní připojení. Výsledek výběru zahrnuje nejen záznamy, které mají shodu v druhé tabulce, ale také záznamy z obou tabulek, pro které nebyla nalezena shoda v druhé tabulce. V tomto případě budou data z chybějícího „spárovaného“ záznamu vyplněna hodnotou NULL.

KŘÍŽOVÉ PŘIPOJENÍ

Křížové spojení (kartézský součin). Každý záznam z jedné tabulky je spárován s každým záznamem z jiné tabulky. Počet výsledných záznamů je roven součinu počtu záznamů v obou tabulkách.

Zásady pro uspořádání několika PŘIPOJIT's

Pokud potřebujete spojit několik stolů, musíte si zapamatovat dvě zásady:

1. Všechny odbory doleva PŘIPOJIT zacházet jako s jednou tabulkou k zahrnutí nebo vyloučení z dotazu.
2. Všechny odbory jsou napravo PŘIPOJIT TAKÉ zacházeno jako s jednou tabulkou pro zahrnutí nebo vyloučení z dotazu.

Důsledkem těchto zásad je následující doporučení pro vytváření komplexních sdružení:

• Kdykoli je to možné, měli byste použít INNER JOIN.
• Pokud je potřeba použít OUTER JOINy, měly by být umístěny jako poslední a INNER JOINy ​​by měly být umístěny na začátku spojení.

P.S. Vše výše uvedené jsou obecné „postuláty“ teorie relačních databází, které nejsou vázány na vlastnosti určitých DBMS.

Datový model je soubor datových struktur a operací pro jejich zpracování. Pomocí datového modelu můžete vizuálně reprezentovat strukturu objektů a vztahy mezi nimi vytvořené. Terminologii datového modelu charakterizují pojmy „datový prvek“ a „závazná pravidla“. Datový prvek popisuje jakoukoli sadu dat a asociační pravidla definují algoritmy pro propojení datových prvků. K dnešnímu dni bylo vyvinuto mnoho různých datových modelů, ale v praxi se používají tři hlavní. Existují hierarchické, síťové a relační datové modely. V souladu s tím hovoří o hierarchických, síťových a relačních DBMS.

O Hierarchický datový model. Hierarchicky uspořádaná data jsou v každodenním životě velmi běžná. Například struktura vysoké školy je víceúrovňová hierarchická struktura. Hierarchická (stromová) databáze se skládá z uspořádané množiny prvků. V tomto modelu počáteční prvky dávají vzniknout dalším prvkům a tyto prvky zase dávají vzniknout dalším prvkům. Každý podřízený prvek má pouze jeden nadřazený prvek.

Organizační struktury, seznamy materiálů, obsahy v knihách, plány projektů a mnoho dalších souborů dat lze prezentovat v hierarchické formě. Integrita vazeb mezi předky a potomky je automaticky zachována. Základní pravidlo: žádné dítě nemůže existovat bez svého rodiče.

Hlavní nevýhodou tohoto modelu je nutnost použití hierarchie, která byla základem databáze při návrhu. Nutnost neustálé reorganizace dat (a často i nemožnost této reorganizace) vedla k vytvoření obecnějšího modelu – síťového modelu.

O Síťový datový model. Síťový přístup k organizaci dat je rozšířením hierarchického přístupu. Tento model se od hierarchického liší tím, že každý generovaný prvek může mít více než jeden generující prvek. ■

Protože síťová databáze může přímo reprezentovat všechny druhy vztahů obsažených v datech odpovídající organizace, lze tato data procházet, zkoumat a dotazovat se různými způsoby, to znamená, že síťový model není vázán pouze jednou hierarchií. Abychom však mohli vytvořit požadavek na síťovou databázi, je nutné ponořit se hluboko do její struktury (mít schéma této databáze po ruce) a vyvinout mechanismus pro navigaci v databázi, což je významnou nevýhodou tohoto databázového modelu. .

O Relační datový model. Základní myšlenkou relačního datového modelu je reprezentovat jakoukoli sadu dat jako dvourozměrnou tabulku. Ve své nejjednodušší formě relační model popisuje jednu dvourozměrnou tabulku, ale častěji než ne, model popisuje strukturu a vztahy mezi několika různými tabulkami.

Relační datový model

Účelem informačního systému je tedy zpracování data o objektů reálný svět, s přihlédnutím spojení mezi objekty. V teorii databází se často nazývají data atributy a předměty - entity. Objekt, atribut a spojení jsou základními pojmy I.S.

Objekt(nebo esence) je něco, co existuje a rozlišitelný, to znamená, že objekt může být nazýván tím „něco“, pro co existuje jméno a způsob, jak rozlišit jeden podobný objekt od druhého. Například každá škola je objekt. Předměty jsou také člověk, třída ve škole, firma, slitina, chemická sloučenina atd. Předměty mohou být nejen hmotné předměty, ale i abstraktnější pojmy, které odrážejí skutečný svět. Například události, regiony, umělecká díla; knihy (ne jako tištěné produkty, ale jako díla), divadelní představení, filmy; právní normy, filozofické teorie atd.

Atribut(nebo daný)- jedná se o určitý ukazatel, který charakterizuje určitý objekt a nabývá určité číselné, textové nebo jiné hodnoty pro konkrétní instanci objektu. Informační systém pracuje s množinami objektů navržených ve vztahu k dané tematické oblasti, s využitím specifických hodnoty atributů(data) určitých objektů. Vezměme například třídy ve škole jako soubor objektů. Počet studentů ve třídě je údaj, který nabývá číselné hodnoty (jedna třída má 28, druhá 32). Název třídy je daný, který nabývá textové hodnoty (jedna má 10A, druhá 9B atd.).

Vývoj relačních databází začal koncem 60. let, kdy se objevily první práce, které pojednávaly; možnost využití známých a přirozených způsobů prezentace dat - tzv. tabulkových datalogických modelů - při návrhu databází.

Za zakladatele teorie relačních databází je považován zaměstnanec IBM Dr. E. Codd, který publikoval článek 6. června 1970 Relační model dat pro velké sdílené datové banky(Relační datový model pro velké kolektivní databanky). Tento článek jako první použil termín „relační datový model“. Teorie relačních databází, vyvinutá v 70. letech v USA Dr. E. Coddem, má silný matematický základ, který popisuje pravidla pro efektivní organizaci dat. Teoretický rámec vyvinutý E. Coddem se stal základem pro rozvoj teorie návrhu databází.

E. Codd, vystudovaný matematik, navrhl pro zpracování dat použít aparát teorie množin (sjednocení, průnik, rozdíl, kartézský součin). Dokázal, že jakákoliv sada dat může být reprezentována ve formě dvourozměrných tabulek zvláštního druhu, v matematice známých jako „relace“.

Relační Za databázi je považována taková, ve které jsou veškerá data uživateli prezentována ve formě obdélníkových tabulek hodnot dat a veškeré operace s databází jsou redukovány na manipulaci s tabulkami.

Stůl se skládá z sloupce (pole) A linky (záznamy); má jméno, které je v rámci databáze jedinečné. Stůl odráží Typ objektu reálný svět (subjekt), a každý z ní řetězec je specifický objekt. Každý sloupec tabulky je sbírka hodnot pro konkrétní atribut objektu. Hodnoty se vybírají ze sady všech možných hodnot pro atribut objektu, který se nazývá doména.

Ve své nejobecnější podobě je doména definována určením nějakého základního datového typu, ke kterému prvky domény patří, a libovolným booleovským výrazem aplikovaným na datové prvky. Pokud vyhodnotíte booleovskou podmínku na datové položce a výsledek je pravdivý, pak tato položka patří do domény. V nejjednodušším případě je doména definována jako platná potenciální sada hodnot stejného typu. Například sběr dat narození všech zaměstnanců tvoří „doménu narození“ a jména všech zaměstnanců tvoří „doménu jména zaměstnance“. Doména data narození musí mít datový typ k určitému okamžiku a doména jména zaměstnance musí mít znakový datový typ.

Pokud dvě hodnoty pocházejí ze stejné domény, lze tyto dvě hodnoty porovnat. Pokud jsou například dvě hodnoty převzaty z domény data narození, můžete je porovnat a určit, který zaměstnanec je starší. Pokud jsou hodnoty převzaty z různých domén, pak jejich srovnání není povoleno, protože to se vší pravděpodobností nedává smysl. Například z porovnání jména a data narození zaměstnance nevzejde nic určitého.

Každý sloupec (pole) má svůj název, který se obvykle píše v horní části tabulky. Při návrhu tabulek v rámci konkrétního DBMS je možné vybrat pro každé pole jeho typ, tedy definovat sadu pravidel pro jeho zobrazení a také určit operace, které lze s daty uloženými v tomto poli provádět. Sady typů se mohou mezi různými DBMS lišit.

Název pole musí být v tabulce jedinečný, ale různé tabulky mohou mít pole se stejným názvem. Každá tabulka musí mít alespoň jedno pole; Pole jsou v tabulce umístěna v souladu s pořadím, v jakém se jejich názvy objevily při jejím vytvoření. Na rozdíl od polí nemají řetězce názvy; jejich pořadí v tabulce není definováno a jejich počet je logicky neomezený.

Vzhledem k tomu, že řádky v tabulce nejsou seřazeny, není možné vybrat řádek podle jeho pozice - není mezi nimi žádný „první“, „druhý“ nebo „poslední“. Každá tabulka má jeden nebo více sloupců, jejichž hodnoty jednoznačně identifikují každý z jejích řádků. Takový sloupec (nebo kombinace sloupců) se nazývá primární klíč. Umělé pole je často zavedeno do číselných záznamů v tabulce. Takovým polem může být například jeho ordinální pole, které může zajistit jedinečnost každého záznamu v tabulce. Klíč musí mít následující vlastnosti.

Jedinečnost. V žádném okamžiku nemají žádné dvě různé relační n-tice stejnou hodnotu pro kombinaci atributů obsažených v klíči. To znamená, že v tabulce nemohou být dva řádky, které mají stejné identifikační číslo nebo číslo pasu.

Minimalismus.Žádný z atributů obsažených v klíči nelze z klíče vyloučit, aniž by došlo k porušení jedinečnosti. To znamená, že byste neměli vytvářet klíč, který obsahuje jak číslo pasu, tak identifikační číslo. K jednoznačné identifikaci n-tice stačí použít kterýkoli z těchto atributů. Do klíče byste také neměli zahrnout nejedinečný atribut, to znamená, že použití kombinace identifikačního čísla a jména zaměstnance jako klíče je zakázáno. Vyloučením jména zaměstnance z klíče lze stále jednoznačně identifikovat každý řádek.

Každý vztah má alespoň jeden možný klíč, protože souhrn všech jeho atributů splňuje podmínku jedinečnosti - to vyplývá ze samotné definice vztahu.

Jeden z možných klíčů je náhodně vybrán jako primární klíč. Zbývající možné klíče, pokud existují, jsou brány jako alternativní klíče. Pokud například jako primární klíč vyberete identifikační číslo, bude alternativním klíčem číslo pasu.

Vztah tabulek je nejdůležitějším prvkem relačního datového modelu. Je podporováno cizí klíče.

Při popisu modelu relační databáze se často pro stejný koncept používají různé termíny v závislosti na úrovni popisu (teorie nebo praxe) a systému (Access, SQL Server, dBase). V tabulce 2.3 poskytuje souhrn použitých pojmů.

Tabulka 2.3. Databázová terminologie

Teorie databází____________ Relační databáze_________ SQL Server __________

Tabulka relačních tabulek

Řádek Tuple Record

AttributeField________________Sloupec

Relační databáze

Relační databáze je sada vztahů obsahující všechny informace, které musí být uloženy v databázi. To znamená, že databáze představuje sadu tabulek nezbytných k uložení všech dat. Tabulky relační databáze na sebe logicky navazují, požadavky na návrh relační databáze lze obecně zredukovat na několik pravidel.

О Každá tabulka má v databázi jedinečný název a skládá se z řádků stejného typu.

O Každá tabulka se skládá z pevného počtu sloupců a hodnot. V jednom sloupci řádku nelze uložit více než jednu hodnotu. Pokud například existuje tabulka s informacemi o autorovi, datu vydání, nákladu atd., pak sloupec se jménem autora nemůže uložit více než jedno příjmení. Pokud knihu napsali dva nebo více autorů, budete muset použít další tabulky.

O V žádném okamžiku nebudou v tabulce dva řádky, které by se navzájem duplikovaly. Řádky se musí lišit alespoň v jedné hodnotě, aby bylo možné jednoznačně identifikovat libovolný řádek v tabulce.

О Každý sloupec má v tabulce přiřazen jedinečný název; je pro něj nastaven specifický datový typ tak, aby byly v tomto sloupci umístěny homogenní hodnoty (data, příjmení, telefonní čísla, peněžní částky atd.).

O Kompletní informační obsah databáze je reprezentován jako explicitní hodnoty samotných dat a toto je jediný způsob reprezentace. Například vztahy mezi tabulkami jsou založeny na datech uložených v odpovídajících sloupcích, a nikoli na základě jakýchkoli ukazatelů, které uměle definují vztahy.

О Při zpracování dat máte volný přístup k libovolnému řádku nebo sloupci tabulky. Hodnoty uložené v tabulce nekladou žádná omezení na pořadí, ve kterém se k datům přistupuje. Popis sloupců,