Při reprezentaci konceptuálního diagramu jako relačního modelu jsou možné různé možnosti výběru schémat vztahů. Některé možnosti výběru byly zvažovány v předchozích částech (část 6.2.3), jiné se získávají kombinací (nebo rozdělením) některých schémat vztahů. Správný výběr vztahových diagramů, které představují konceptuální schéma, do značné míry určí efektivitu databáze.

Podívejme se jako příklad na konkrétní vztahové schéma a analyzujme jeho nedostatky. Předpokládejme, že údaje o studentech, fakultách, specializacích jsou zahrnuty v tabulce s následujícím vztahovým schématem: STUDENT (Kód studenta, Příjmení, Název fakulty, Název oboru).

Toto schéma vztahů způsobuje následující nevýhody odpovídající databáze:

• Duplikace informací (redundance). U studentů studujících na stejném oddělení se bude název katedry opakovat. Speciality se budou opakovat pro různé fakulty.
• Potenciální nekonzistence ( aktualizovat anomálie). Pokud se např. změní název odbornosti, tak změnou v jedné n-tice (pro jednoho studenta) je nutné jej změnit i ve všech ostatních n-ticích, kde se vyskytuje.
• Možná ztráta informací ( anomálie mazání). Když smažeme informace o všech studentech vstupujících do určité specializace, ztratíme všechny informace o této specializaci.
• Možnost, že informace nebudou zahrnuty do databáze ( spínací anomálie). Databáze nebude obsahovat informace o specializaci, pokud v ní nestudují žádní studenti.

V teorie relačních databází existují formální metody pro konstrukci relačního databázového modelu, ve kterém není redundance a aktualizovat anomálie, odstranění a zařazení.

Normalizace. První normální forma.

Konstrukce racionální verze vztahových schémat (která má lepší vlastnosti pro operace vkládání, modifikace a mazání dat než všechny ostatní sady schémat) se provádí pomocí tzv. normalizace vztahové vzorce. Normalizace se provádí v několika fázích. V počáteční fázi by měl být vztahový diagram první normální forma(1NF).

Vztah je na prvním místě normální forma, pokud všechny atributy vztahu nabývají jednoduchých hodnot (atomických nebo nedělitelných), které nejsou množinou nebo n-ticí více elementárních komponent.

Zvažte následující příklad.

Tabulka představuje entitu ZPRÁVA O VYŠETŘENÍ

Kód studenta	Příjmení	Kód zkoušky	Předmět a datum	Školní známka
1	Sergejev	1	Matematika 5.06.08	4
2	Ivanov	1	Matematika 5.06.08	5
1	Sergejev	2	Fyzika 9.06.08	5
2	Ivanov	2	Fyzika 9.06.08	5

Nyní na průsečíku libovolného řádku a libovolného sloupce je jedna hodnota, a proto je tato tabulka v první normální forma.

Dále vztah uvedený v prvním normální forma, se postupně transformuje na druhý a třetí normální formy. Proces konstrukce druhé a třetí normální formy bude popsán v následujících podkapitolách. Podle některých předpokladů o datech třetí normální forma je požadovaná nejlepší možnost.

Pokud tyto předpoklady nejsou splněny, pak proces normalizace pokračuje a poměr se převede na čtvrtý a pátý normální formy. Konstrukce odpovídajících forem je popsána v literatuře a není v této knize diskutována.

Než přejdeme ke konstrukci druhého normální tvar, je nutné definovat řadu formálních pojmů.

8.2. Funkční závislosti (závislosti mezi atributy vztahu)

Nechť R(A 1, A 2, ..., A n) je relační schéma a X a Y jsou podmnožiny (A 1, A 2, ..., An).

Funkční závislost na postoji R je výrok ve tvaru „Pokud dvě n-tice R odpovídat atributům sady(tj. tyto n-tice mají stejné hodnoty ve svých odpovídajících komponentách pro každý atribut množiny X ), pak se musí shodovat v atributech sady . Formálně je tato závislost zapsána výrazem X -> Y, a říká se to X funkčně definuje Y. Další často používaný výrok je: X funkčně definuje Y nebo Y funkčně závisí na X ( označený X -> Y) právě tehdy, když každá hodnota množiny X vztah R spojené s jednou hodnotou množiny Y vztah R. Jinými slovy, pokud dvě n-tice R se významově shodují X, významově jsou stejné Y.

Komentář. Obecně řečeno, pojem „vztah“ může znamenat dva pojmy:

• vztah jako proměnná, která může nabývat různých hodnot (tabulka, jejíž řádky a sloupce mohou obsahovat různé hodnoty);
• vztah jako soubor konkrétních hodnot (tabulka s vyplněnými prvky).

Funkční závislosti charakterizujte všechny vztahy, které mohou být v zásadě hodnotami relačního schématu R. Proto jediný způsob, jak určit funkčních závislostí– pečlivě analyzovat sémantiku (význam) atributů.

Funkční závislosti jsou zejména integritní omezení, proto je vhodné je kontrolovat při každé aktualizaci databáze.

Příklad funkčních závislostí pro vztah ZPRÁVA O VYŠETŘENÍ

Kód studenta -> Příjmení Kód studenta, Kód zkoušky -> Známka

Příklad funkčních závislostí pro vztah STUDENT uvedený na začátku této přednášky

Kód studenta -> Příjmení, Kód studenta -> Fakulta

Upozorňujeme, že poslední závislost existuje za podmínky, že jeden student nemůže studovat na více fakultách.

Kompletní sada funkčních závislostí

Pro každý vztah existuje dobře definovaný soubor funkčních závislostí mezi atributy tohoto vztahu. Navíc z jedné nebo více funkčních závislostí obsažených v uvažovaném vztahu lze odvodit další funkčních závislostí, také neodmyslitelnou součástí tohoto vztahu.

Daná množina funkčních závislostí pro vztah R označme F kompletní sadu funkčních závislostí, které lze logicky získat F tzv. uzavření F a je určeno F+.

Pokud se množina funkčních závislostí shoduje s uzavřením této množiny, pak se taková množina funkčních závislostí nazývá úplná.

Zavedené pojmy nám umožňují formálně definovat pojem klíč.

Nechť je nějaké schéma R s atributy A 1 A 2 ...A n , F – nějakou sadu funkčních závislostí a X - nějakou podmnožinu R. Pak X se nazývá klíč, pokud za prvé, in F+ existuje závislost X -> A 1 A 2 ...A n a za druhé, pro žádnou podmnožinu Y obsažen v X, závislost Y -> A 1 A 2 ...A n nepatří F+.

Úplná funkční závislost je závislost neklíčového atributu na celém složeném klíči..

Částečná funkční závislost je závislost neklíčového atributu na části složeného klíče..

Vypočítat uzavření více funkčních závislostí používají se následující pravidla vyvozování (

Informace měly vždy adekvátní dynamický zájem. Rozvoj programovacích jazyků, relačních databází a informačních technologií radikálně změnil obsah a strukturu zájmu. Vyvinul se určitý přísný systém idejí. Formalizace, exaktní matematika a binární vztahy se staly úspěšnou a rychle se rozvíjející oblastí znalostí a zkušeností.

Přirozený svět informací nezměnil svou dynamiku a rozvíjející se obsah a strukturu povznesl do nových výšin. Má hladké tvary a v přírodě není nic "obdélníkový". Informace se samozřejmě hodí k formalizaci, ale mají dynamiku, mění se nejen data a algoritmy pro jejich zpracování, ale mění se i samotné úkoly a oblasti jejich použití.

Informace > formalizace >> data

Informace se mění v informační strukturu, databázi...) tak, jak je vidí programátor. Neexistuje žádná záruka, že tato vize je správná, ale pokud jeho program problém vyřeší, pak byla data prezentována co nejvhodněji.

Otázka, jak správně byly informace formalizovány, je otázkou času. Až dosud je koncept dynamiky (sebepřizpůsobení se měnícím se podmínkám použití) pouze programátorským snem.

Funkční závislost: „správné řešení = program (programátor)“ a podmínka: „průběžné plnění úkolu“ platí ve většině případů, ale pouze společně. Ale to není matematický základ, který se používá k vytváření databází.

Přímé prohlášení: přirozená a nepřetržitá dynamika informací a algoritmy řešení problémů jsou vždy skutečné. A to jsou binární relace + přísná matematika + přesné formální konstrukce, + ...

a databáze

Jak jsou data ukládána, bylo dlouho nedůležité: ať už je to RAM nebo externí zařízení. Hardwarová komponenta dosáhla stabilního tempa vývoje a poskytuje dobrou kvalitu ve velkých objemech.

Hlavní možnosti úložiště, které se liší možnostmi využití dat:

• soubory;
• Databáze.

První je ponecháno na programátorovi (co si zapsat, v jakém formátu, jak to udělat, jak číst...), druhé hned přináší nutnost pochopit jednoduchou funkční závislost.

Rychlost načítání a zápisu informací při práci se soubory (rozumné velikosti, nikoli astronomická) je velmi rychlá, ale rychlost podobných operací s databází může být někdy znatelně pomalá.

Osobní zkušenost a kolektivní moudrost

V průběhu historie existovaly pokusy překročit tyto limity, ale dodnes vládnou relační databáze. Nashromáždil se velký teoretický potenciál, aplikační praxe je rozsáhlá a vývojáři jsou vysoce kvalifikovaní.

Vývojáři databází vnucují programátorovi koncept funkční závislosti, i když nehodlá využít bohaté matematické a logické zkušenosti s budováním složitých informačních struktur, procesů práce s nimi, získávání a zaznamenávání informací.

I v tom nejjednodušším případě je programátor závislý na databázové logice, se kterou se rozhodne pracovat. Není touha řídit se kánony, můžete používat soubory, získáte spoustu souborů a spoustu osobních zkušeností. Bude vynaloženo mnoho osobního času a problém bude vyřešen po dlouhou dobu.

Bez ohledu na to, jak složité příklady funkční závislosti se mohou zdát, není vůbec nutné nořit se do hlubin smyslu a logiky. Často je třeba uznat, že kolektivní mysli se podařilo vytvořit vynikající databáze různých velikostí a funkcí:

• pevný Oracle;
• náročný MS SQL Server;
• populární MySQL.

Vynikající relační databáze s dobrou pověstí, snadno použitelné, rychlé ve správných rukou. Jejich použití šetří čas a eliminuje potřebu psát další listy pomocného kódu.

Programování a datové funkce

Programování má už dlouhou dobu nemoc neustále něco přepisovat, opakovat práci předchůdců, aby se něco nějak přizpůsobilo změněné informaci, úkolu nebo podmínkám jeho použití.

Věc o funkční závislosti je, že stejně jako v programování může být chyba velmi drahá. Úkol je zřídka jednoduchý. Obvykle se při formalizaci informací získá komplexní reprezentace dat. Obvykle jsou jejich prvky izolovány, pak jsou propojeny klíči do určitých vztahů, poté jsou upraveny algoritmy pro vytváření tabulek, dotazy a algoritmy pro získávání informací.

Často je velmi důležitá vazba na kódování. Ne všechny databáze nabízejí mobilní řešení, často se můžete setkat s tím, jak perfektně a stabilně fungující MySQL, na kterém je postavena desítka databází, nutí vývojáře udělat jedenáctou databázi podobnou těm, které již existují.

Jsou chvíle, kdy sdílený hosting omezuje funkčnost PHP a to ovlivňuje programování přístupu k databázi.

V moderním programování je odpovědnost za algoritmus programu ekvivalentní odpovědnosti za vytvoření datového modelu. Všechno by mělo fungovat, ale neměli byste se vždy ponořit do džungle teorie.

DB: jednoduchá závislost na datech

Za prvé, koncept databáze je jak databáze, tak systém správy (například MySQL) a určitá informační struktura, která odráží data úloh a vazby mezi nimi. Jedna databáze MySQL „uchová“ tolik informačních struktur, kolik chcete pro různé oblasti použití. Jedna databáze Oracle může podporovat informační procesy velké společnosti nebo banky, řídit bezpečnostní problémy a integritu dat na nejvyšší úrovni, umístěná na mnoha počítačích umístěných na různé vzdálenosti, v různých instrumentálních prostředích.

Obecně se uznává, že vztah je v relačním modelu zásadní. Elementární relace je množina sloupců s názvy a řádků s hodnotami. Klasický "obdélník"(tabulka) - jednoduché a efektivní dosažení pokroku. Složitost a funkční závislosti databáze začínají, když "obdélníky" začít vstupovat do vzájemných vztahů.

Název každého sloupce v každé tabulce musí být jedinečný v kontextu úlohy. Stejná data nemohou být ve dvou tabulkách. Znát význam pojmů:

• „definovat entity“;
• „eliminovat nadbytečnost“;
• „upravit vztahy“;
• "pro zajištění pravosti."

Elementární nutnost použití databáze a sestavení datového modelu pro konkrétní úlohu.

Porušení některého z těchto konceptů znamená nízkou efektivitu algoritmu, pomalé vzorkování dat, ztrátu dat a další potíže.

Funkční závislost: logika a význam

Nemusíte číst o n-ticích relací, o tom, že funkce je korespondence mezi množinou argumentů a množinou hodnot a funkce není jen vzorec nebo graf, ale může být specifikována pomocí sada hodnot - tabulka.

Není to nutné, ale neuškodí uvažovat o funkční závislosti jako:

F(x1, x2, …, xN) = (y1, y2, …, yN).

Je však nutné pochopit, že vstupem je tabulka a výstupem je také tabulka nebo konkrétní řešení. Funkční závislost obvykle vytváří logiku vztahů mezi tabulkami, dotazy, oprávněními, spouštěči, uloženými procedurami a dalšími aspekty (součástmi) databáze.

Obvykle jsou tabulky převedeny na sebe a poté na výsledek. Ale použití funkční závislosti není omezeno pouze na tuto myšlenku. Programátor si sám staví vlastní reprezentaci datového obrázku, informační struktury... je jedno, jak tomu říkáte, ale pokud to funguje na konkrétní databázi, musí být postavena podle její logiky, brát v úvahu její význam a dialekt používaného jazyka, obvykle SQL.

Lze tvrdit, že vlastnosti funkčních závislostí databáze jsou přístupné prostřednictvím dialektu používaného jazyka SQL. Mnohem důležitější je však pochopit: po všech peripetiích vývoje nepřežilo mnoho databází, ale i v databázích je mnoho dialektů tohoto jazyka a rysů vnitřních struktur.

O starém dobrém Excelu

Když se počítač ukázal na pozitivní stránce, svět se okamžitě rozdělil na programátory a uživatele. První z nich zpravidla používají:

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• Slovo.
• Vynikat.

Někteří uživatelé zvládají vytvářet databáze ve Wordu sami (bez pomoci programátorů) – to je skutečný nesmysl.

Uživatelská zkušenost s Excelem při vytváření databází je praktická a zajímavá. Důležité je, že samotný Excel je funkční, barevný a praktický.

Tabulková myšlenka definovala koncept funkční závislosti jasným a přístupným způsobem, ale každá databáze má nuance. Každý má svou vlastní „tvář“, ale každý od Excelu po Oracle manipuluje s jednoduchými čtverci, tedy tabulkami.

Pokud uvážíte, že Excel vůbec není databáze, ale mnoho uživatelů (nikoli programátorů) ji tak používá a Oracle je nejkomplexnější a nejvýkonnější výdobytek velkého týmu vývojářů v oblasti databází, pak je přirozené připustit, že databáze je reprezentace konkrétního programátora (týmu) o konkrétním problému a jeho řešení.

Co je funkční závislost, s čím, kde, proč... je zřejmé pouze autorovi nebo týmu z nich.

O tom, kam směřují vztahové vztahy

Vědeckotechnický pokrok je velmi bolestivý a někdy krutý postup. Pokud si pamatujete, jak začaly databáze, co je *.dbf, jak stigmatizovali kybernetiku, pak se zamilovali do informatiky a začali vytvářet překážky pro pohyb špičkových technologií na úrovni země, je jasné, proč jsou relační databáze tak houževnatý a dobrý. Proč klasický styl programování dodnes žije a objektově orientované programování je prostě oceňováno, ale zatím nevládne.

Bez ohledu na to, jak krásné funkční závislost v kontextu matematiky:

Nejedná se o binární vztah, nebo spíše, je to důvod k přehodnocení myšlenky vytvoření vztahů mezi mnoha atributy, zkoumáním „jeden k mnoha“, „mnoho k jednomu“, „mnoho k -mnoho“ nebo „mnoho obecně a některé konkrétní“ vztahy.

Můžete přijít s velkým množstvím možností vztahu. Je to matematika s logikou a je to přísné! Informace jsou svou vlastní matematikou, speciální. O formálnosti se v něm dá mluvit jen s hodně velkým mínusem.

Můžete formalizovat práci HR oddělení, napsat automatizovaný řídicí systém pro výrobu ropy nebo výrobu mléka, chleba, provést výběr v obrovské databázi Google, Yandex nebo Rambler, ale výsledek bude vždy statický a stejný v každém okamžiku!

Jestliže funkční závislost = přísná logika a matematika = základ pro databáze, tak o jaké dynamice můžeme mluvit? Jakékoli řešení bude formální, jakýkoli formální datový model + striktní algoritmus = přesné a jednoznačné řešení. Informace a rozsah jakéhokoli programu se neustále mění.

Výběr vyhledávače pro stejnou hledanou frázi nemůže být stejný po hodině nebo dvou a rozhodně každý druhý den – pokud hledaná fráze patří do oblasti informací, ve které je počet webů, zdrojů, znalostí a dalších prvky se neustále mění.

I když je program čistě matematický a jeho databáze ani nemyslí na dynamiku, všechno jsou vždy řádky. A provázek má délku. A nemůže být nekonečný. Nemůže to být ani proměnná, pouze podmíněná proměnná. Mimo jiné každá databáze se svým matematickým a binárním byrokratickým aparátem klade spoustu formalit a to znamená rychlost + kvalitu vzorkování a zpracování informací.

A pokud jsou některá pole v databázi čísla, zejména skutečná, pak budou přidána následující omezení: kapacita číslic, přítomnost písmene „e“, formát zobrazení - zkrátka všude a vždy máme důležité vlastnosti funkční závislosti databáze:řetězce podmíněně proměnné délky se spoustou binárních formalit a přísnými matematickými omezeními.

Pokud změníte tón a zaposloucháte se do pulsu dynamiky, pak lze vše nakreslit do objektů. Pro první přiblížení je název sloupce v tabulce objekt, seznam jmen je také objekt, stručně řečeno, tabulka je objekt záhlaví a v něm názvy sloupců v záhlaví. A nemusí tam být vůbec žádný klobouk...

Ale v tabulce mohou být řádky. A v řetězci mohou být hodnoty. A proč by jich měl být pořád stejný počet? Kompletní čtvercový stůl- to je specifická věc a ve většině případů soukromá.

Pokud reprezentujete všechny konstrukty v databázi jako objekty, pak možná nebudete muset budovat striktní binární vztahy. To má přirozený a skutečný význam, už jen proto, že podle objektivní (rozhodně ne matematické) logiky odráží dynamiku informací a prostředí, ve kterém problémy existují.

Přednášky č. 8-9.

Funkční závislost. Normální formy.

Účel lekce: seznámit studenty s definicí funkční závislosti atributů, s pojmem normalizace původního vztahu, pohovořit o důvodech vedoucích k nutnosti normalizace souborů záznamů, představit způsoby, jak zajistit požadovanou úroveň normality tabulky, definovat normální formy pomocí konkrétního příkladu.

Funkční závislosti

Teorie normalizace, stejně jako teorie databází obecně, je založena na matematickém aparátu, jehož základem je teorie množin a prvky algebry.

Stejná data lze seskupovat do tabulek (vztahů) různými způsoby. Seskupování atributů ve vztazích by mělo být racionální (tj. duplikace dat by měla být minimální) a zjednodušovat postupy pro jejich zpracování a aktualizaci. Odstranění redundance dat je jedním z nejdůležitějších úkolů při návrhu databáze a je zajištěno normalizací.

Normalizace tabulek (relací)- jedná se o formální aparát omezení tvorby tabulek (vztahů), který eliminuje duplicitu, zajišťuje konzistenci dat uložených v databázi a snižuje mzdové náklady na údržbu (vstup, úpravu) databáze. Proces normalizace spočívá v rozkladu (dekompozici) původních databázových vztahů na jednodušší vztahy. Každá fáze tohoto procesu převádí vzorec vztahů do následných normálních forem. Pro každou fázi normalizace existují sady omezení, které musí databázové vztahy splňovat. Normalizace umožňuje odstranit nadbytečné neklíčové informace z databázových tabulek.

Nejprve si připomeňme některé pojmy:

Jednoduchý atribut je atribut, jehož hodnoty jsou nedělitelné. Jinými slovy, tabulka nemá pole jako Celé jméno nebo Adresa - jsou rozdělena na pole Příjmení, Jméno, Patronymické jméno v prvním případě a na pole Index, Město atd. v druhém případě.

Komplexní (složený) atribut se získává kombinací několika atomárních atributů, jinak se nazývá vektor nebo souhrn dat.

Definice funkční závislosti: Nechat X a Y jsou atributy nějakého vztahu. Pokud kdykoliv libovolná hodnota X odpovídá jediné hodnotě Y, pak je Y funkčně závislé od X (X→Y)

Pokud je klíč složený, pak jakýkoli atribut musí záviset na klíči jako celku, ale nemůže být funkčně závislý na žádné části složeného klíče, tzn. funkční závislost má tvar (X 1, X 2, ..., X)→Y.

Funkční závislost může být úplná nebo neúplná.

Neúplná závislost nazývá se závislost neklíčového atributu na části složeného klíče .

Plná funkční závislost se nazývá závislost neklíčového atributu na celém složeném klíči a ne na jeho částech.

Definice tranzitivní funkční závislosti: Nechat X, Y, Z- tři atributy nějakého vztahu. Na thistom X→Y a Y→Z, ale neexistuje žádná inverzní korespondence, to znamená, že Y nezávisí na Z a X nezávisí na Y. Pak to říkají Z závisí přechodně na X.

Definice vícehodnotové závislosti: Nechť X a Y jsou atributy nějaké relace. Atribut Y hodně záleží z atributu X, pokud. Každá hodnota X odpovídá sadě hodnot Y, které nejsou spojeny s jinými atributy ze vztahu. Vícehodnotové závislosti mohou mít povahu „jeden k mnoha“ (1:M), „mnoho ku jednomu“ (M:1) nebo „mnoho ku mnoha“ (M:M), odpovídajícím způsobem se označují: X =>Y, Y<=X и X<=>Y. Například učitel vyučuje několik předmětů a každý předmět může vyučovat několik učitelů, pak existuje závislost celého jména <=> Položka.

Uvažujme následující příklad: Předpokládejme, že pro vzdělávací část fakulty je vytvořena databáze učitelů, která obsahuje následující atributy:

Celé jméno - příjmení a iniciály učitele (shodující se příjmení a iniciály jsou vyloučeny).

Pozice je pozice, kterou zastává učitel.

Plat – plat učitele.

Zkušenosti – pedagogická praxe. D_Experience - bonus za délku služby.

Katedra - číslo katedry, ve které je vyučující registrován.

Předmět - název předmětu (disciplíny), který vyučující vyučuje.

Skupina - číslo skupiny, ve které učitel vede výuku.

Typ vyučovací hodiny - typ vyučovací hodiny vedené učitelem ve studijní skupině.

Počáteční postoj UČITEL

Relační databáze obsahuje jak strukturální, tak sémantické informace. Struktura databáze je určena počtem a typem vztahů, které obsahuje, a vztahy jedna k mnoha, které existují mezi n-ticemi těchto vztahů. Sémantická část popisuje množinu funkčních závislostí, které existují mezi atributy těchto vztahů. Definujme funkční závislost.

Definice: Jsou-li dány dva atributy X a Y nějakého vztahu, pak se říká, že Y funkčně závisí na X, pokud v kterémkoli okamžiku každá hodnota X odpovídá právě jedné hodnotě Y. Funkční závislost se označí X -> Y. Všimněte si, že X a Y mohou představovat nejen jednotlivé atributy, ale také skupiny složené z několika atributů jednoho vztahu. Můžeme říci, že funkční závislosti jsou vztahy jedna k mnoha, které existují v rámci vztahu.

Vztah 2. normální formy (2NF). Stanovení kompletní funkční závislosti a 2NF. Charakteristika vztahů v 2NF. Algoritmus pro redukci na 2NF. Heathova věta. Příklady.

Pojemúplná funkční závislost.

Definice: neklíčový atribut plně funkčně závislý ze složeného klíče, pokud je funkčně závislý na celém klíči jako celku, ale není funkčně závislý na žádném z jeho základních atributů.

Definice: nadměrná funkční závislost- závislost, která obsahuje informace, které lze získat na základě jiných závislostí dostupných v databázi.

2NF - druhá normální forma.

Definice druhé normální formy: relace je v 2NF, pokud je v 1NF a každý neklíčový atribut je funkčně plně závislý na klíči.

Databázové schéma, které nemá redundantní funkční závislosti, je považováno za správné. V opačném případě se musíte uchýlit k postupu dekompozice (dekompozice) existující množiny vztahů. V tomto případě vygenerovaná množina obsahuje větší počet relací, které jsou projekcí relací původní množiny. (Operace projekce je popsána v části o relační algebře.) Reverzibilní postupný proces nahrazování dané sady vztahů jiným schématem, eliminující nadbytečné funkční závislosti, se nazývá normalizace.

Podmínka vratnosti vyžaduje, aby rozklad zachoval ekvivalenci obvodů při výměně jednoho obvodu za jiný, tzn. ve výsledných vztazích:

1) dříve chybějící n-tice by se neměly objevit;

2) vztahy nového schématu musí splňovat původní sadu funkčních závislostí.

Heathova věta

Vztah budiž dán.

Li r splňuje funkční závislost, pak se rovná sjednocení její projekce a

Vztah 3. normální formy (3NF). Definice tranzitivní závislosti a 3NF.Algoritmus pro redukci na 3NF.Boyce-Codd Normal Form (BCNF) Definice a algoritmus pro redukci na BCNF. Charakteristika vztahů v 3NF a v NFBC. Příklady.

Funkční závislosti

Funkční závislost popisuje vztah mezi atributy a je jedním ze základních pojmů normalizace. Předpokládejme, že relační schéma má atributy (A, B, C,..., Z) a celou bázi lze reprezentovat jako jeden univerzální vztah R=(A, B, C,..., Z). Proto má každý atribut v databázi jedinečný název.

Pokud jsou A a B atributy nějaké relace R a každá hodnota A je spojena s jednou a pouze jednou hodnotou B (a každý z atributů se může skládat z jednoho nebo více atributů), pak atribut B funkčně závislý z atributu A (ВАА).

Volá se funkční závislost platná za jakýchkoliv podmínek triviální. Netriviální závislosti definují omezení integrity vztahů.

Tranzitivní závislost pro atributy A, B a C nějaké relace znamená následující: pokud AàB a BàC, pak C tranzitivně závisí na atributu A přes atribut B (za předpokladu, že A je funkčně nezávislý na B nebo C).

Aby se předešlo redundanci dat, která může vést ke ztrátě integrity, je nutné použít minimální dostatečnou sadu závislostí.

Návrh databáze pomocí normalizace začíná definováním funkčních závislostí, které jsou sémanticky zřejmé, tzn. redukce do první normální formy.

Tabulka v první normální podobě musí splňovat následující požadavky:

1) tabulka by neměla mít duplicitní záznamy;

2) tabulka by neměla obsahovat duplicitní skupiny polí;

3) každé pole musí být sémanticky nedělitelné.

Tabulka v druhé normální formě musí splňovat všechny požadavky 1NF; každé neklíčové pole je jednoznačně identifikováno úplnou sadou klíčových polí, to znamená, že každý atribut vztahu je plně nebo částečně funkčně závislý na jiném atributu.

Funkční závislost AàB je plný funkční závislost, pokud odstranění některého atributu z A vede ke ztrátě této závislosti. Funkční závislost AàB se nazývá částečný, je-li v A určitý atribut, po odstranění tato závislost zůstává.

Tabulka, která je ve třetí normální formě, musí splňovat všechny požadavky 2NF; žádné neklíčové pole není identifikováno jiným neklíčovým polem, tj. vztahem, který je v první a druhé normální formě a nemá žádné atributy, které nejsou v primárním klíči atributů , který by byl v tranzitivní funkční závislosti na tomto primárním klíči.

Boyce Code Normal Form (BCNF) je založen na funkčních závislostech, které berou v úvahu všechny potenciální klíče vztahu, ale s přísnějšími omezeními.

Determinant funkční závislosti je atribut (nebo skupina atributů), na kterém plně funkčně závisí nějaký jiný atribut.

Pro kontrolu, zda vztah patří do BCNF, je nutné najít všechny jeho determinanty a ujistit se, že se jedná o potenciální klíče.

Rozdíl mezi 3NF a BCNF je v tom, že funkční závislost AàB je povolena ve vztahu 3NF, pokud atribut B je primární klíč a atribut A není nezbytně kandidátský klíč. Pro BNF je tato závislost povolena pouze v případě, že atribut A je kandidátním klíčem. Proto je BCNF přísnější verzí 3NF, protože každý vztah BCNF je 3NF, ale ne každý vztah 3NF je BCNF.

Vztah je v BCNF pouze tehdy, je-li každý z jeho determinantů potenciálním klíčem.

Čtvrtá normální forma (4NF) je vztah v BCNF, který neobsahuje netriviální vícehodnotové závislosti.

Vícehodnotová závislost představuje vztah mezi atributy vztahu (například A, B a C), takže každá hodnota A představuje množinu hodnot pro B a množinu hodnot pro C. Nicméně množiny hodnot protože B a C jsou na sobě nezávislé.

Vícehodnotová závislost může být dále definována jako triviální nebo netriviální. Vícehodnotová závislost AàB nějaké relace R je definována jako triviální, pokud je atribut B podmnožinou atributu A nebo . Naopak vícehodnotová závislost je definována jako netriviální, pokud není splněna ani jedna podmínka. Triviální vícehodnotová závislost neklade tomuto vztahu žádná omezení, ale netriviální ano.

Při rozdělení vztahu pomocí operace promítání je přesně určena použitá metoda rozkladu. Je nutné, aby při opětovném propojení výsledných vztahů bylo možné obnovit původní vztah. Tento rozklad se nazývá bezztrátový rozklad spojení(nebo oboustranně výhodné nebo neaditivní spojení), protože zachovává všechna data v původní relaci a eliminuje vytváření dalších fiktivních řádků.

Pátá normální forma (5NF), také nazývaná projektivní spojovací normální forma, znamená, že vztah v této formě nemá žádné spojité závislosti. Relace R s podmnožinou atributů A,B,...,Z splňuje závislost spojení, jestliže každá přípustná hodnota R je rovna spojení jeho průmětů na podmnožiny A,B,...,Z.