Hlavní datová struktura v relačním modelu (RMD) je přístup, Proto se model nazývá relační.

V RMD data uspořádaná v tabulkách, která musí splňovat určitá omezení a lze ji považovat za vztah.

Tabulkovou reprezentaci navrhl americký matematik E.F. Codd na počátku 70. let a implementovaný IBM na počátku 80. let. Dvourozměrná tabulka je jednou z nejvíce jednoduchými způsoby prezentace dat uživateli nebo programátorovi.

Tabulkové znázornění vztahu "Zaměstnanci". je uveden v tabulce 1.

Stůl 1. Vztah "Zaměstnanci" - tabulka "Zaměstnanci"

RMD používá formální vztahové termíny, které mohou být nahrazeny neformálními. Shoda mezi formálními a neformálními podmínkami je uvedena v tabulce 2.

Tabulka 2 Korespondence mezi neformálními a formálními podmínkami RMD

Model má vážný teoretický základ – teorii množin a matematickou logiku.

Základní pojmy relačního modelu:

- datový typ, hodnota;

- doména;

- atribut;

- kolona;

- klíč;

- přístup.

Pojem datový typ je ekvivalentní konceptu datového typu v algoritmických jazycích. Atomová hodnota data jsou nejmenší nedělitelnou jednotkou dat v RMD.

Doména je potenciální sada platných atomárních hodnot stejného typu. Údaje jsou považovány za srovnatelné pouze tehdy, pokud se týkají stejné domény. Například číslo skupiny a ID studenta mají stejný typ – celé číslo, ale patří do různých domén, takže jejich srovnávání nedává smysl.

Atribut je pojmenovaný relační sloupec, hodnoty prvků sloupce musí být ze stejné domény.

Nechť je dána množina domén D 1 , D 2 ,…,D N (nemusí se nutně lišit).

Průvod vztahy jsou množinou N hodnot uspořádaných v přesně definovaném pořadí (d 1, d 2,..., d N), takže d 1 patří D 1, d 2 patří D 2 a d N patří do D N. Počet prvků v n-tice se nazývá arita.

Kompletní kartézský produkt domény D 1 x D 2 x…x D N je množina všech možných různých n-tic arity N, kde každý prvek n-tice je převzat ze své vlastní domény (příklad: D1(Nogr), D2(Fam_stud), D3(Type )).

Poměr, definovaný na těchto N doménách, je podmnožinou plného kartézského součinu původních domén.

Vztahový diagram name seznam názvů atributů vztahu označujících domény nebo typy atributů. Když je počet atributů roven N, říkají N-ární vztah. Relační schéma – řádek záhlaví tabulky.

N-tice odpovídající danému relačnímu schématu je množina párů (název atributu, hodnota), která obsahuje jeden výskyt každého názvu atributu patřícího do relačního schématu.

Primárním klíčem vztahu je je atribut nebo sada atributů, která jednoznačně identifikuje každou n-tici ve vztahu a zajišťuje, že řádky jsou jedinečné. Klíč může být jednoduchý (z jednoho atributu) nebo komplexní (složený z několika atributů).

Vlastnosti klíče jsou jedinečnost a minimalita. Pro každý vztah má alespoň úplný soubor jeho atributů vlastnost jedinečnosti. Klíč by měl být minimální, tzn. žádná pole nejsou nadbytečná pro jednoznačnou identifikaci řádku v tabulce odstraněním libovolného pole z klíče dojde k porušení identifikace.

Mnoho objektů má identifikátory, pak můžeme mluvit o přirozeném klíči obsahujícím informace o objektu, například údaje o osobním pasu. Umělý nebo náhradní klíč je generován systémem a většinou neobsahuje podstatné informace, jako je číslo školy žáka, tzn. mimo systém to nedává smysl.

Omezení relačního modelu(vlastnosti tabulky):

1. Každá tabulka je jednoznačně pojmenována, představuje jeden skutečný objekt nebo definuje vztah mezi objekty a skládá se z řádků stejného typu odpovídajících n-ticím relace a sloupců odpovídajících atributům relace.

2. Každý prvek tabulky musí být atomový, tj. nedělitelný.

3. Všechny řádky mají stejnou strukturu s pevným počtem polí a hodnot. V tabulce nemohou být dva stejné řádky (vyplývá z definice vztahu). Řádky se od sebe liší alespoň v jedné hodnotě.

4. Každý sloupec má jedinečný název. Prvky stejného sloupce musí být homogenní, extrahováno z jedné domény.

5. V operacích s tabulkami lze řádky a sloupce zobrazit v libovolném pořadí. Neexistuje žádné řazení n-tic, ale domény jsou uspořádány v rámci vztahu. Ale pořadí, ve kterém se přistupuje k pojmenovaným sloupcům, se také stává irelevantním.

6. Každý stůl musí mít primární klíč. Klíč umožňuje najít jeden řádek v tabulce. N-tice jsou indexovány podle klíče, což urychluje zpracování dat. Klíče se používají k logickému propojení tabulek.

Kratší forma záznamu tabulky „Zaměstnanci“ resp vztahový diagram„Zaměstnanci“ (primární klíč vztahu je podtržen):

Zaměstnanci ( Číslo_tabulátoru, Příjmení, Oddělení, Datum narození, Pozice, Plat)

V obecný pohled relační diagram je zapsán jako

R(a 1 , a 2 , ..., a N), kde a i je název i-tého atributu vztahu R.

RBD je souborem vzájemně propojených vztahů. obvod RDB odkazují na sadu pojmenovaných schémat vztahů používaných k reprezentaci informací a aktuálních hodnot vztahů jako databáze. Ve fyzické reprezentaci každý vztah odpovídá databázovému souboru, instance vztahu odpovídá záznamu databázového souboru a atributy vztahu odpovídají polím záznamu databázového souboru.

Podschéma, které je projekcí databázového schématu, obsahuje pouze ty vztahy a pouze ty atributy těchto vztahů, které používá programátor aplikace k řešení konkrétní úlohy (dotazu).

Při popisu databázového subschématu lze specifikovat všechna potřebná omezení, například: přístupové heslo k relaci nebo jejím atributům, režim zpracování pro relaci nebo její atributy – „pouze pro čtení“ nebo „čtení a zápis“ a další.

Podschéma databáze může také obsahovat virtuální atributy - nejedná se o atributy vztahů uložené v databázi, ale vypočítané algoritmicky pro konkrétní úlohu (dotaz). Také v databázovém subschématu lze měnit způsoby řazení dat (tzn. jsou přiřazeny další klíče), datové typy (digitální - nahrazovány symbolickými a naopak). Zároveň DBMS poskytuje automatické provedení všechny tyto procesy.

Zvláštností RMD je, že oba objekty a vztahy mezi nimi jsou prezentovány v jediné formě, ve formě tabulek.

Na rozdíl od hierarchických a síťových modelů komunikace mezi vztahy jsou zachovány implicitně. RMD podporuje binární spojení jako „1:1“, „1:M“, „M:1“. V každém spojení působí jeden vztah jako hlavní (ze strany 1) a druhý jako podřízený (ze strany M). To znamená, že jedna n-tice hlavní relace může být spojena s několika n-ticemi podřízené relace.

Vztah je udržován propojovací sadou atributů, v hlavním vztahu je to primární klíč (primární klíč), který musí být v podřízeném vztahu přítomen jako sekundární klíč. Tato sada atributů v podřízeném vztahu se nazývá cizí klíč (cizí klíč).

Cizí klíče se používají k navázání logických spojení mezi vztahy. Primární klíč identifikuje jednu n-tici v primární relaci a sekundární klíč identifikuje sadu n-tic v podřízené relaci, které souvisejí s jedinou n-ticí v primární relaci.

Uvažujme příklad udržování spojení typu „1:M“ mezi vztahy „Skupina“ a „Studenti“. Hlavní relací je relace „Group“, primárním klíčem relace je atribut „Číslo_skupiny“. Podřízený vztah je vztah „Studenti“, primární klíč vztahu je „Číslo_zápočtové_knihy“. Vztah „Students“ musí mít atribut „Číslo_skupiny“ jako cizí klíč pro propojení s hlavním vztahem. Právě tento atribut umožňuje určit informace o skupině, ve které student studuje.

Schéma hlavního vztahu „Skupina“:

Skupina ( Skupina č., Specialita)

Schéma podřízeného vztahu „Studenti“:

studenti ( č._známka, Příjmení, Datum narození, Skupina č.)

(V diagramech vztahů jsou primární klíče podtržené a sekundární klíče kurzívou).

Příklady RMD DBMS: DBase, FoxPro, Clipper, Paradox, MS Access, Informix, Oracle atd.

Libovolnou datovou strukturu lze redukovat na dvourozměrné tabulky. Uvažujme příklad převodu hierarchického MD, znázorněného na obr., na relační databázi, tzn. do souboru vzájemně propojených vztahů.

Pro každý uzel stromové struktury je vytvořen samostatný vztah, tzn. vznikají vztahy „Oddělení“, „Zaměstnanci“, „Pracovní_činnosti“, „Děti“, „Práce“. Ke každému vztahu odpovídajícímu podřízenému uzlu je připojen identifikátor zdrojového uzlu. Výsledkem je, že získáme relační databázi skládající se z následujících vztahů:

oddělení ( Číslo_oddělení, Název)

Zaměstnanci ( Číslo_tabulátoru, příjmení, plat, Číslo_oddělení)

Labor_activity ( Číslo objednávky, Obsah_objednávky, Číslo_tabulátoru)

děti ( Child_name, Číslo_tabulátoru , Datum narození)

Práce ( Job_code, Jméno, Datum dokončení, Číslo_oddělení)

Výhody relační model:

– jednoduchost a přehlednost modelu;

– homogenita struktur pro reprezentaci objektů a spojení;

– schopnost manipulovat s daty bez nutnosti znát konkrétní fyzickou organizaci databáze v externí paměť;

– možnost používat neprocedurální dotazovací jazyky pro netrénované uživatele databáze.

Uvažované modely datové logiky se liší ve způsobu, jakým umožňují uživateli reprezentovat a zpracovávat vztahy.

V hierarchickém a síťovém komunikačním modelu jsou fyzická data propojena fyzickými ukazateli. To je výhoda i nevýhoda. Zamýšlená fyzická spojení jsou dobře realizována, ale jiné vztahy se těžko extrahují. V relačním modelu jsou spojení logická.

V relačním přístupu jsou spojení mezi objekty reprezentována stejným způsobem jako objekty samotné, n-ticemi v relacích. Jednotnost prezentace dat zjednodušuje softwarové a jazykové nástroje DBMS.

V matematických disciplínách pojem „tabulka“ odpovídá pojmu „vztah“. Stůl odráží objekt reálného světa – podstata, a každý řádek odráží konkrétní instanci entity. Každý sloupec má pro tabulku jedinečný název.

Řádky nemají názvy, jejich pořadí není definováno a jejich počet je logicky neomezený. Jednou z hlavních výhod RMD je jednotnost (každý řádek tabulky má stejný formát). O tom, zda mají odpovídající entity homogenitu, rozhoduje sám uživatel. Tím je problém vhodnosti modelu vyřešen. Hlavní prvky RMD jsou znázorněny na Obr. 17.

Relace je dvourozměrná tabulka obsahující nějaká data.

Podstata– předmět jakékoli povahy, o kterém jsou údaje uloženy v databázi.

Atributy– vlastnosti charakterizující entitu (sloupce). Stupeň vztahu je počet sloupců.

Vztahový diagram– seznam názvů atributů, např. ZAMĚSTNANEC (č., celé jméno, rok narození, pozice, oddělení).

Doména– sada hodnot atributů vztahu (datový typ). Přesněji řečeno, doména Tady je potenciální soubor hodnot.

Vlastnosti domény: Doména je množina, i když obecně její hodnoty nelze jednoduše vyčíslit. Následující vlastnosti jsou tedy zděděny ze sady:

Omezení: doména má hranici, data se dělí na možná a nemožná. Stejně jako u množiny to neznamená, že počet prvků je konečný.

Jedinečnost: můžete porovnat některé prvky s jinými a vyhnout se duplicitám. Pro jednu jedinou doménu je to samozřejmé.

Správně pomáhá koncept domény simulovat předmětová oblast

Doména a atributy. A atributy musí být specifické pro doménu nebo „definované v doméně“. Na jedné doméně lze nastavit více atributů.

Atomicita hodnot: hodnoty atributů musí být jednoduché, atomový, ne kompozitní.

Přirozenost domén. D Znamení musí nést sémantickou zátěž. Je užitečnější považovat doménu za určitou skupinu parametrů popisu předmětová oblast, k nějakému sémantickému pojmu.

Je pravidlem, že mnoho oborů je již zcela formalizováno a má hotové koncepty a referenční knihy.

Omezte zbytečná srovnávání mezi atributy – hlavní účel domén.

Průvod– řádek tabulky.

Kardinalita (síla)– počet řádků v tabulce.

	Celé jméno	Rok narození	Pracovní pozice	Kód oddělení
	Ivanov I.I.
	Petrov P.P.		Profesor
	Sidorov S.S.
	Vasiliev V.V.
	Vovkin V.V.		učitel
	Štěpánov S.S.		Profesor

Obrázek 17. Prvky relačního modelu

Pojem databáze úzce souvisí s takovými pojmy strukturních prvků, jako je pole, záznam, soubor (tabulka),

pole , - elementární jednotka logické organizace dat, která odpovídá nedělitelné jednotce informace - detailu. K popisu pole se používá následující: vlastnosti :

název , Například. Příjmení, jméno, patronymie, datum narození;

typ , například symbolický, číselný, kalendářní;

délka , například 15 bajtů a bude určeno maximálním možným počtem znaků

přesnost , pro číselná data, jako jsou dvě desetinná místa pro zobrazení zlomkové části čísla.

Záznam- soubor logicky souvisejících polí. Instance záznamu je samostatná implementace záznamu obsahující specifické hodnoty pro jeho pole.

Soubor(tabulka) - kolekce instancí záznamů stejné struktury.

Tabulku v relačním datovém modelu lze považovat za třídu objektů stejného typu .

Pro objekty stejné třídy tedy bude sada vlastností stejná, i když hodnoty těchto vlastností pro každý objekt se samozřejmě mohou lišit.

Datové typy povolené v relačním datovém modelu.

Hlavní datové typy používané v datových modelech:

Krátké celé číslo – krátké celé číslo;

Dlouhé celé číslo – dlouhé celé číslo;

Plovák – reálné číslo (číslo s pohyblivou řádovou čárkou);

Dvojnásobek – reálné číslo (číslo s pohyblivou řádovou čárkou) s dvojnásobnou přesností;

Text – textový datový typ;

Logický - logické (ano/ne);

Data - dočasné. Hodnota je definována jako datum s oddělovači v zadaném formátu;

Kapka – velké binární objekty (binary large object - BLOB), které mohou ukládat data neomezené velikosti. Pole tohoto typu umožňují ukládat bezrozměrné libovolné binární informace.

Klíčový prvek (primární klíč) dat je prvek, ze kterého lze určit hodnoty dalších datových prvků. Objekt lze jednoznačně identifikovat dvěma nebo více datovými hodnotami.

Primární klíč– Toto je atribut, který jednoznačně identifikuje řádky vztahu. Primární klíč složený z více atributů se nazývá složený klíč. Primární klíč nemůže být zcela nebo částečně prázdný (má hodnotu null).

Praktický význam Primární klíč je zřejmý: doménový objekt je jednoznačně popsán sadou atributů tabulky. Primární klíč zachycuje to nejdůležitější o předmětu, jeho jedinečnou podstatu. Zbývající pole lze nazvat „jen atributy“.

Volají se klíče, které lze použít jako primární klíče potenciál nebo alternativníklíče.

Externí klíč - slouží k propojení tabulek. Jedná se o hodnoty z jedné tabulky, které lze jednoznačně propojit s jinou. Přesněji řečeno, pro vztah je cizí klíč sada předdefinovaných atributů

Externí klíč - je atribut(y) jedné tabulky, který může sloužit jako primární klíč jiné tabulky. Jde o odkaz na primární klíč jiné tabulky (obr. 18).

Obr 18. Vztahové spojení

Vztah STUDENT (jméno, skupina, specializace) A POLOŽKA (Jméno Pr, Hodiny) spojeno vztahem STUDENT_SUBJECT (jméno, jméno pr., ročník), ve kterém cizí klíče Celé jméno A Jméno_Pr tvoří složený klíč.

databáze, pokud jsou založeny na tomto modelu. Datový model vám umožňuje porovnávat konkrétní implementace pomocí jednoho společného jazyka.

Přestože je pojem datového modelu obecný a lze hovořit o hierarchických, síťových, sémantických a dalších datových modelech, je třeba poznamenat, že v oblasti databází tento pojem zavedl Edgar Codd ve vztahu k relačním systémům a je nejvíce v této souvislosti efektivně využít. Ukazují to pokusy přímo aplikovat podobné modely na předrelační organizace relační model příliš „velký“ a pro postrelační organizace se ukazuje jako „malý“.

obecné charakteristiky

I když koncept relační datový model zakladatel jako první představil vztahový přístup Edgar Codd, nejběžnější výklad relační datový model, patrně patří slavnému popularizátorovi Coddových myšlenek, Christopheru Dateovi, který je reprodukuje (s různými upřesněními) téměř ve všech svých knihách (viz například K. Date. Introduction to Database Systems. 6th ed., M. Petrohrad: Williams – 2000). Podle datového výkladu relační model sestává ze tří částí popisujících různé aspekty vztahový přístup: konstrukční část, manipulační část a integrální část.

Ve strukturální části modelu je stanoveno, že jedinou generickou strukturou je 7 Toto je podruhé v této přednášce, kdy je normalizovaná n -ární relace jedinou generickou datovou strukturou používanou v relačních databázích. Je na čase si ujasnit, co si pod pojmem představujeme obecná struktura. Programovací jazyky s rozsáhlými typovými systémy mají obvykle konstrukty tzv generické typy, parametrizovatelné typy, typové konstruktéry, generátory typu atd., umožňující generování konkrétního datového typu na základě jeho abstraktní (obvykle předdefinované) specifikace. Zvláštností takových typů je, že hlavní operace konkrétního typu jsou definovány na úrovni této abstraktní specifikace. Jedním z nejznámějších příkladů je typ sady, například v jazyce Pascal. Když relační datový model Neříkáme explicitně, že relace je generický typ, ale v podstatě to tak je. Operace relační algebry jsou definovány na úrovni abstraktního vztahu a vztahují se na jakékoli hodnoty vztahu s konkrétními záhlavími. Data používaná v relačních databázích jsou normalizované n-ární relace. Koncepty domén, atributů, n-tic, hlavičky, těla a vztahová proměnná. Ve skutečnosti jsme ve dvou předchozích částech této přednášky uvažovali přesně o konceptech a vlastnostech konstrukčního prvku relační model.

V manipulační části modelu jsou definovány dva základní mechanismy pro manipulaci s relačními databázemi - relační algebra a vztahový kalkul. První mechanismus je založen především na klasické teorii množin (s určitými upřesněními a doplňky) a druhý je založen na klasickém logickém aparátu predikátového počtu prvního řádu. Těmito mechanismy se budeme podrobněji zabývat v následujících přednáškách, ale zatím pouze poznamenáme, že hlavní funkcí manipulační části relační model je poskytnout míru relativnosti jakéhokoli specifického jazyka relační databáze: jazyk se nazývá relační, pokud nemá o nic menší expresivitu a sílu než relační algebra nebo vztahový kalkul.

Integrita entity a reference

Konečně v nedílné části relační datový model jsou stanoveny dva základní požadavky na integritu, které musí být podporovány v jakémkoli relačním DBMS. První požadavek je tzv požadavek integrity entity. Objekt nebo entita reálného světa v relačních databázích odpovídá n-ticím vztahů. Konkrétně se jedná o požadavek, aby jakákoliv n-tice jakéhokoli hodnotového vztahu jakékoli vztahová proměnná musí být odlišitelné od jakékoli jiné n-tice tohoto poměrové hodnoty složenými hodnotami předem určené sady atributů vztahová proměnná, tedy jinými slovy jakýkoli vztahová proměnná musí mít primární klíč. Jak jsme viděli v předchozí části, tento požadavek je automaticky splněn, pokud systém neporušuje základní vlastnosti relací.

Ve skutečnosti požadavek integritu entityúplně zní takto: jakýkoli vztahová proměnná musí existovat primární klíč a žádná hodnota primární klíč v nicích jsou hodnoty vztahy vztahová proměnná nesmí obsahovat nedefinované hodnoty. Aby byla tato formulace plně srozumitelná, musíme koncept alespoň krátce probrat nedefinováno(NULA).

Samozřejmě, teoreticky by každá n-tice vložená do trvalého vztahu měla obsahovat všechny charakteristiky entity reálného světa, kterou modeluje a kterou chceme uložit do databáze. V praxi však nemusí být všechny tyto charakteristiky známy v době, kdy je třeba účetní jednotku zaznamenat do databáze. Jednoduchý příklad může existovat postup pro přijetí osoby, jejíž mzda dosud nebyla stanovena. V tomto případě zaměstnanec personálního oddělení, který do vztahu ZAMĚSTNANCI zadá n-tici popisující nového zaměstnance, prostě nemůže poskytnout hodnotu atributu SLU_ZARP (jakákoli hodnota v doméně VELIKOST_PLATBA bude chybně charakterizovat mzdu nového zaměstnance).

Edgar Codd navrhl použití v takových případech nedefinované hodnoty. Nedefinovaná hodnota nepatří k žádnému datovému typu a může být přítomen mezi hodnotami libovolného atributu definovaného na jakémkoli datovém typu (pokud to není výslovně zakázáno, když je atribut definován). Pokud a je hodnota nějakého datového typu nebo NULL , op je jakákoli dvoumístná "aritmetická" operace tohoto datového typu (například + ) a prokreslit je operace porovnávání hodnot tohoto typu (například = ), pak podle definice:

a op NULL = NULL NULL op a = NULL a lop NULL = neznámý NULL lop a = neznámý

Zde neznámá je třetí booleovská hodnota, popř Boolean, zadejte, který má následující vlastnosti:

NE neznámý = neznámý pravdivý A neznámý = neznámý pravdivý NEBO neznámý = pravdivý nepravdivý A neznámý = nepravdivý nepravdivý NEBO neznámý = neznámý

(pamatujte, že operace AND a OR jsou komutativní) 8 Jak ukazuje zkušenost autora, ne všichni žáci si pamatují základní logické operace. Abychom to zaručili, uvádíme pravdivostní tabulky pro operace AND (& – konjunkce), OR ( – disjunkce) a NOT ( – negace):

A	skutečný	Nepravdivé		NEBO	skutečný	Nepravdivé		NE	skutečný	Nepravdivé
skutečný	skutečný	Nepravdivé		skutečný	skutečný	skutečný			Nepravdivé	skutečný
Nepravdivé	Nepravdivé	Nepravdivé		Nepravdivé	skutečný	Nepravdivé

. V této přednášce následuje stručný úvod k nedefinované hodnoty, ale v následujících přednáškách se k tomuto tématu ještě několikrát vrátíme.

Prvním z požadavků je tedy požadavek integritu entity- znamená, že primární klíč musí plně identifikovat každou entitu, a tedy jako součást jakékoli hodnoty primární klíč přítomnost není povolena nedefinované hodnoty. (V klasice relační model tento požadavek platí i pro případné klíče; jak bude ukázáno v následujících přednáškách, v SQL-orientovaných DBMS takový požadavek na možné klíče není podporováno.)

Druhý požadavek, který je tzv požadavek na referenční integritu, je složitější. Je zřejmé, že pokud jsou vztahy normalizovány, komplexní entity reálného světa jsou reprezentovány v relační databázi ve formě několika n-tic několika vztahů. Představte si například, že chcete zastupovat relační databáze Entita ODDĚLENÍ s atributy ČÍSLO_ODDĚLENÍ (číslo oddělení), VELIKOST ODDĚLENÍ (počet zaměstnanců) a ODDĚLENÍ_SLU (množina zaměstnanců oddělení). Pro každého zaměstnance musíte uložit SLU_NUMBER (číslo zaměstnance), SLU_NAME (jméno zaměstnance) a SLU_SARP (plat zaměstnance). Jak uvidíme v kapitole 7, pokud je vhodná databáze správně navržena, objeví se v ní dva vztahy: ODDĚLENÍ (DEPARTMENT_NUMBER, DEPARTMENT_SIZE)(primární klíč – (DOT_NUMBER)) a ZAMĚSTNANCI (SERV_NUMBER, SLU_NAME, SLU_ZARP, SLU_DEPARTMENT_NOM)(primární klíč – (SLN_NUMBER) ).

Jak vidíte, atribut SLU_DEPARTMENT_NOM je zaveden do vztahu ZAMĚSTNANCI ne proto, že číslo oddělení je vlastnictvím zaměstnance, ale pouze proto, aby bylo možné v případě potřeby obnovit celou entitu ODDĚLENÍ. Hodnota atributu SLU_DEPARTMENT_NOM v libovolné n-tice vztahu ZAMĚSTNANCI musí odpovídat hodnotě atributu DEPARTMENT_NOM v některé n-tice vztahu ODDĚLENÍ. Atribut tohoto druhu (případně složený) se nazývá cizí klíč, protože jeho hodnoty jedinečně charakterizují entity reprezentované n-ticemi nějakého jiného vztahu (tj. určují hodnoty jejich primární klíč). Cizí klíč může být samozřejmě složený, to znamená, že se může skládat z několika atributů. O relaci, ve které je definován cizí klíč, se říká, že odkazuje na odpovídající vztah, ve kterém je stejný atribut primární klíč.

Požadavek referenční integrita, nebo požadavek na integritu cizího klíče, je to, že pro každou hodnotu cizího klíče, která se objeví v n-tici hodnoty odkazovaného vztahu vztahová proměnná nebo ve významovém vztahu vztahová proměnná, na který odkaz ukazuje, musí existovat n-tice se stejnou hodnotou primární klíč nebo hodnota cizího klíče musí být zcela nedefinovaná (tj. neukazovat na nic) Jazyk SQL umožňuje několik možností definice cizího klíče, z nichž pouze jedna plně odpovídá klasickému přístupu. Tomu se budeme podrobněji věnovat v příštích přednáškách.. V našem příkladu to znamená, že pokud je pro zaměstnance zadáno číslo oddělení, pak toto oddělení musí existovat.

Všimněte si, že stejně jako primární klíč

Naprostá většina moderních informačních systémů je založena na datech prezentovaných ve formě relačního modelu. Hlavní koncepty relačního datového modelu jsou:

Předmětná oblast- jedná se o část reálného světa (třídu nebo soubor tříd reálných objektů), uvažovanou z určitého úhlu pohledu, podléhající reflexi modelu za účelem její automatizace. Oblast předmětu je nekonečná a obsahuje jak pojmy a data, která jsou pro vývoj informačního systému nezbytná, tak data nevýznamná či nevýznamná. Obecně popisuje doménový model informační procesy, vyskytující se v doméně a údaje používané těmito procesy. Předmětná oblast je zastoupena mnoha strukturálními jednotkami (např. podnik - dílny, administrativa, účetnictví atd.). Každá strukturální jednotka domény je charakterizována množstvím objektů a procesů, které objekty využívají, a také množstvím uživatelů, které se vyznačují různými pohledy na doménu. Výsledek vývoje aplikace a úspěšnost informačního systému závisí na tom, jak správně je daná oblast modelována.

Například jako předmět si můžete vybrat účetní oddělení podniku, oddělení lidských zdrojů, banku, obchod atd. Pokud si tedy jako předmětnou oblast zvolíte účtování zboží na skladě, pak jsou pojmy „faktura“ a „faktura“ v podstatě důležité pojmy a to, že zaměstnanec přebírající faktury má dvě děti, není pro účtování zboží důležité. Z pohledu HR oddělení jsou však zásadní údaje o přítomnosti dětí. Důležitost dat tedy závisí na volbě domény.

Datový model – jedná se o soubor datových struktur a operací jejich zpracování.

Relační model– model reprezentace dat pro danou oblast, postavený na relačních vztazích. Podle K. J. Date popisuje relační datový model tři aspekty: strukturální, holistická manipulace:

· Strukturální - data v modelu jsou množinou vztahů.

· Celostní – vztahy splňují určité podmínky integrity. (deklarativní omezení integrity na úrovni domény (datového typu), na úrovni vztahu a na úrovni databáze).

· Manipulace (zpracování) - model podporuje relační manipulační operátory (relační algebra, relační kalkul).

přístup– soubor objektů předmětné oblasti, které jsou popsány společnými (obecnými) charakteristikami a vlastnostmi. Vztah je základní koncept v relačním datovém modelu. Relace je abstraktní pojem, tabulka může sloužit jako vizuální znázornění vztahu v teorii relací na papíře nebo na obrazovce.

Atribut– informační zobrazení (charakteristika, vlastnost) objektu předmětné oblasti, používané k jeho popisu, přičemž se bere konkrétní hodnota ze sady platných hodnot. Každý atribut má název, který se používá k odkazování na data. Názvy atributů jsou v rámci vztahu jedinečné. Že. vztah představuje soubor atributů. Na praktické úrovni je atributem pole tabulky.

Vztahový diagram -úplný seznam názvů atributů vztahu.

Tuple – je relační prvek obsahující jednoznačnou reprezentaci objektu reálného světa, v souladu s zvýrazněno atributy. Na praktické úrovni je n-tice záznam v tabulce.

Klíč vztahu– atribut nebo sada atributů vztahu, které jednoznačně identifikují každý kolona. Pokud relační klíč splňuje podmínky jedinečnosti a minimalizace, pak se takový klíč nazývá hlavní. Zavolá se atribut vztahu používaný k uložení hodnot primárního klíče jiného vztahu za účelem vytvoření vztahu mezi těmito vztahy externí .

V relačním modelu věcné oblasti jsou data potřebná pro provoz informačního systému zpravidla prezentována ve tvaru soubor vzájemně propojených vztahů . Cizí klíče se používají k navázání logických spojení mezi vztahy. Takže data v informační systém byly jednoznačné a konzistentní, v relačním modelu musí být stanoveny omezující podmínky - integritní omezení , které umožňují minimalizovat chyby při provozu systému. Nejdůležitější omezení integrity jsou: kategorická a referenční integrita.

Při navazování logických vazeb mezi vztahy používáme čtyři typy připojení :

· Jedna ku jedné– vytvořené mezi primárními klíči vztahů. V tomto případě bude každá n-tice jedné relace odpovídat pouze jedné n-tice jiné relace.

· Jeden k mnoha- vytvořený mezi primárním klíčem jednoho vztahu a cizím klíčem jiného vztahu. V tomto případě bude jedna n-tice jedné relace odpovídat několika n-ticím jiné relace.

· Mnoho k jednomu- vytvořený mezi cizím klíčem jednoho vztahu a primárním klíčem jiného vztahu. V tomto případě bude několik n-tic jedné relace odpovídat pouze jedné n-tice jiné relace.

· Mnoho k mnoha – vytvořeno mezi vztahy cizího klíče. Navíc libovolné n-tice jedné relace mohou odpovídat několika n-ticím jiné relace.

Přednáška 12

Relační datový model.

Normalizace. Normální formy.

Technologie mapující konceptuální databázový model na relační datový model

1. Základní pojmy relačního datového modelu

Jak bylo ukázáno v předchozí přednášce, pro definování relačního datového modelu je nutné deklarovat strukturu dat, způsob manipulace s nimi a integritní omezení (snímek 2).

1.1. Strukturální složka relačního modelu

Z hlediska struktury dat je relační model pohodlnou a nejběžnější formou prezentace dat ve formě tabulky. Pojem „tabulka“ odpovídá pojmu „vztah“. Odtud pochází i název modelu – vztahový. To znamená, že ve vztahu k databázím jsou pojmy „relační databáze“ a „tabulková databáze“ v podstatě synonyma. Na rozdíl od hierarchického a síťového modelu tento způsob reprezentace

1) srozumitelné pro uživatele, kteří nejsou programátory;

2) umožňuje snadnou změnu schématu - připojení nových datových prvků a záznamů beze změny odpovídajících podschémat;

3) poskytuje potřebnou flexibilitu při vyřizování neočekávaných požadavků.

Kromě toho může být jakákoli síť nebo hierarchický diagram reprezentován dvourozměrnými vztahy.

Jednou z hlavních výhod relačního modelu je jeho homogenita. Všechna data jsou považována za uložená v tabulkách, ve kterých má každý řádek stejný formát. Každý řádek v tabulce představuje nějaký reálný objekt nebo vztah mezi objekty. Uživatel modelu se musí sám rozhodnout, zda jsou odpovídající entity reálného světa homogenní. Tím je vyřešen problém vhodnosti modelu pro zamýšlenou aplikaci.

Hlavní pojmy, kterými je relační model definován, jsou následující: doména, relace, n-tice, mohutnost, atributy, stupeň, primární klíč. Vztah mezi pojmy je znázorněn na snímku (snímek 3).

Doménaje soubor hodnot, ze kterých se přebírají hodnoty odpovídajících atributů určitého vztahu. Z hlediska programování je doména systémově definovaný (standardní) nebo uživatelem definovaný datový typ.

Primární klíčje sloupec nebo nějaká podmnožina sloupců, která je jedinečná, tzn. jedinečně definuje řádky Primární klíč, který obsahuje více než jeden sloupec, se nazývá vícenásobný klíč nebo primární klíč, primární klíč nebo primární klíč. Pravidlo integrity objektu říká, že primární klíč nemůže být zcela nebo částečně prázdný, tj. být nulový.

Zbývající klíče, které lze použít i jako primární klíče, se nazývají potenciální resp alternativní klíče.

Pojďme formulovat pravidla pro přidělování primárních klíčů entitám:

1). Primární klíč musí jednoznačně identifikovat jakákoli instance entity.

2).Pokud je to možné, měl by být primární klíč nejkompaktnější zze všech potenciálních klíčů je nejlepší datový typ pro primární klíč celé číslo.

3). Primární klíč může být složený, ale zvyšuje se početsloupy v něm obsažené odporují požadavku kompaktnosti. Požadavek na kompaktnost také nemůže být splněn, pokud například v avyberte atribut řetězce jako primární klíčdlouhý datový typ.

4). Hodnoty primárního klíče by neměly podléhat častým úpravám. V ideálním případě je obchodní logika domény taková, že se tyto hodnoty nemají vůbec měnit.

5). Pravidla modifikace primárního klíče musí být řízena vnitřní obchodní logika předmět, a ne řešení, žejsou převzaty nad ní. Například v databázi vyvinuté propotřeby děkanátu, pro subjekt STUDENTJako primární klíč byste neměli zvolit číslo série a pasustudent. I když tyto údaje mají v zásadě vlastnosti závazkuráznost a jedinečnost, ale jejich změnu mohou iniciovat studentiom, a nikoli ze strany vedení fakulty.

5). Pokud mezi shromážděnými informacemi o subjektu nelze identifikovat údaje, které splňují výše uvedené požadavky, pak doporučujemedoporučuje se zvážit možnost tvorby náhradní primář klíč,která, aniž by nesla nějakou sémantickou zátěž, prostě slouží identifikátor konkrétní instance entity. Typicky se jako náhradní primární klíč vybírají nejrůznější možnosti.nal kódy nebo identifikátory. Náhradní klíč se nejčastěji skrývá na externí úroveň modelování relačních databází.

Externí klíčje sloupec nebo podmnožina jedné tabulky, která může sloužit jako primární klíč pro jinou tabulku. Externí klíč tabulka je odkaz na primární klíč jiné tabulky. Pravidlo referenční integrity uvádí, že cizí klíč může být prázdný nebo může odpovídat hodnotě primárního klíče, na který odkazuje. Cizí klíče jsou nedílnou součástí relačního modelu, protože implementují vztahy mezi databázovými tabulkami.

Cizí klíč, stejně jako primární klíč, může být také kombinací sloupců. V praxi bude cizí klíč vždy složený (skládající se z více sloupců), pokud odkazuje na složený primární klíč v jiné tabulce. Je zřejmé, že počet sloupců a jejich datové typy v primárním a cizím klíči jsou stejné.

Pokud tabulka souvisí s několika dalšími tabulkami, může mít více cizích klíčů.

Pojmy relačního modelu představují speciální terminologii zavedenou autory teoretické základy mají však také známější analogy (ale ne ekvivalentní ve všech ohledech!), jejichž korespondence je uvedena v následující tabulce ( snímek 4 ).

12.1.2. Řídicí složka relačního modelu

Množina přípustných operací s daty prezentovanými jako množina relací je specifikována relační algebrou. Kromě operací manipulace s relačními daty musí ovládací komponenta obsahovat definici dat; definice názorů; podmínky integrity; identifikace přístupových práv; hranice transakce (zahájení, dokončení a zrušení).

12.1.3. Integrita dat ( snímek 5)

Integrita na úrovni domény

V teorii vztahů se obecně uznává, že všechny hodnoty atributů vztahu jsou atomické. Vyplývá to z výkladu pojmu doména. Doménu lze považovat za podmnožinu hodnot nějakého datového typu, které mají specifický význam. Relační model vyžaduje, aby použité datové typy byly jednoduché (skalární), tedy bez vnitřní struktury.

Doména má v rámci databáze jedinečný název definovaný na jednoduchém datovém typu nebo na jiné doméně. Ve skutečnosti pro relační datový model není důležitý typ použitých dat. Požadavek, aby byl datový typ jednoduchý, tomu se musí rozumět Relační operace by neměly brát v úvahu vnitřní datovou strukturu.

Hlavním účelem domén je, že oni limitní srovnání. Je logicky nesprávné porovnávat hodnoty z různých domén, i když jsou stejného typu. Koncept domény tedy pomáhá správně simulovat předmětová oblast.

Integrita na úrovni vztahů

Potenciální klíče slouží jako jediné prostředky adresování na úrovni n-tice ve vztahu. Pouze znalost hodnoty kandidátního klíče n-tice umožňuje přesně specifikovat tuto n-tice.

Z hlediska modelování sémantických dat slouží potenciální klíče identifikační prostředky doménové objekty – instance entit, o kterých jsou data uložena v relaci. Protože tyto instance musí být rozlišitelné podle definice, jejich identifikátory nemohou obsahovat neznámé hodnoty.

Typicky se pro situaci neznámých nebo neúplných dat používají datové typy doplněné o tzvNULA- péče.

NULA -value je nějaký druh indikátoru, že hodnota je neznámá. Problém s používáním NULA -hodnoty v teorii relačních databází nebyly zcela vyřešeny. Téměř všechny implementace moderních relačních DBMS umožňují použití NULA -hodnoty i přes jejich nedostatečné teoretické zdůvodnění.

Pravidlo integrity vztahu zní: každý vztah musí mít alespoň jeden kandidátský klíč, jehož základní atributy nemohou akceptovat nula - hodnoty. Tento kandidátský klíč je nejlépe deklarovat jako primární klíč tabulky odpovídající vztahu.

Je třeba poznamenat, že většina DBMS umožňuje vytvářet tabulky bez primárních klíčů. Porušení pravidla integrity vztahů se však v praxi okamžitě projeví. Například pro DBMS SLEČNA Pro SQL server bude nemožné přistupovat k datům pomocí technologie Poskytovatel OLE DB.

Integrita cizího klíče (integrita na úrovni databáze)

Různé doménové objekty, o kterých jsou informace uloženy v databázi, jsou vždy vzájemně propojeny. Nejtypičtější způsob komunikace tohoto typu vztahu mezi vztahy je popsán omezením cizího klíče ( FK, cizí klíč).

Cizí klíč je obvykle nemá vlastnost jedinečnosti. Tak by to mělo být, protože podřízený vztah může mít několik n-tic odkazujících na stejnou n-tici v nadřazeném vztahu, což ve skutečnosti dává typ vztahu mezi vztahy „jedna k mnoha“ . Toto je standardní typ odkazu, který zachovává referenční integritu. Pokud má cizí klíč stále vlastnost jedinečnosti, pak je vztah mezi vztahy typu „one-to-one“. .

Ačkoli každá hodnota cizího klíče musí odpovídat hodnotám kandidátského klíče v nějaké n-tici nadřazeného vztahu, opak obecně neplatí. V poli vztahu nadřazené tabulky mohou být hodnoty, na které neodkazuje žádná z hodnot cizího klíče.

NULA -hodnoty pro atributy cizího klíče jsou platné pouze v případě, že atributy cizího klíče nejsou součástí žádného kandidátského klíče.

Protože cizí klíče ve skutečnosti slouží jako odkazy na n-tice v jiném (nebo stejném) vztahu, neměly by tyto odkazy ukazovat na neexistující objekty.

Výše formulované úvahy určují pravidlo integrity cizího klíče nebo referenční integrita relační databáze: cizí klíče nesmí být nekonzistentní, tj. pro každou hodnotu cizího klíče musí existovat odpovídající hodnota v poli vztahu v nadřazeném vztahu.

12.1.4. Coddova pravidla

Obecně je koncept relačního modelu definován následujícími dvanácti Coddovými pravidly ( snímek 6 ):

1.Informační pravidlo. Veškeré informace v databázi musí být poskytovány výhradně na logické úrovni a pouze jedním způsobem – ve formě hodnot obsažených v tabulkách.

2.Pravidlo zaručeného přístupu. Logický přístup ke každému datovému prvku (atomické hodnotě) v relační databázi musí být zajištěn pomocí kombinace názvu tabulky, primárního klíče a názvu sloupce.

3.Neplatné pravidlo podpory hodnoty. Relační databáze musí podporovat neplatné hodnoty, které se liší od řetězce znaků nulové délky, řetězce mezer, nuly nebo jakéhokoli jiného čísla a používají se k reprezentaci chybějících dat bez ohledu na typ těchto dat.

4.Dynamické adresářové pravidlo založené na relačním modelu. Popis databáze na logické úrovni musí být prezentován ve stejné podobě jako kmenová data, aby s nimi uživatelé s příslušnými právy mohli pracovat pomocí stejného relačního jazyka, který používají pro práci s kmenovými daty.

5.Vyčerpávající datové podjazykové pravidlo . Relační systém může podporovat různé jazyky a režimy interakce s uživatelem (například režim otázek a odpovědí). Musí však existovat alespoň jeden jazyk, jehož příkazy mohou být reprezentovány jako znakové řetězce podle nějaké dobře definované syntaxe a který plně podporuje definici dat; definice názorů; zpracování dat (interaktivní a programové); podmínky integrity; identifikace přístupových práv; hranice transakce (zahájení, dokončení a zrušení).

6. Zobrazit pravidlo aktualizace. Všechny pohledy, které lze teoreticky aktualizovat, by měly být k dispozici pro aktualizaci.

7. Pravidlo pro přidávání, aktualizaci a mazání. Schopnost pracovat s relací jako s jedním operandem musí existovat nejen při čtení dat, ale také při přidávání, aktualizaci a mazání dat.

8. Pravidlo fyzické nezávislosti dat. Aplikační programy a obslužné programy pro práci s daty musí zůstat nedotčené na logické úrovni bez ohledu na jakékoli změny ve způsobu ukládání dat nebo přístupu k nim.

9. Logické pravidlo nezávislosti dat. Aplikační programy a datové obslužné programy musí zůstat logicky nedotčené, když jsou v podkladových tabulkách provedeny jakékoli změny, které teoreticky zachovají data obsažená v těchto tabulkách nedotčená.

10. Pravidlo nezávislosti podmínek integrity. Mělo by být možné definovat podmínky integrity specifické pro konkrétní relační databázi v podjazyku relační databáze a uložit je do adresáře spíše než do aplikačního programu.

11. Nezávislost pravidla šíření. Relační DBMS by neměly záviset na potřebách konkrétního klienta.

12. Pravidlo jedinečnosti. Pokud má relační systém nízkoúrovňový jazyk (zpracovává jeden záznam najednou), pak nesmí být možné jej použít k obcházení pravidel integrity a podmínek vyjádřených v relačním jazyce na vysoké úrovni (zpracování více záznamů najednou). ).

Pravidlo 2 označuje roli primárních klíčů při vyhledávání informací v databázi. Název tabulky vám umožní najít požadovanou tabulku, název sloupce vám umožní najít požadovaný sloupec a primární klíč vám umožní najít řádek obsahující datovou položku, kterou hledáte.

Pravidlo 3 vyžaduje, aby chybějící data mohla být reprezentována pomocí neplatných hodnot ( NULA) .

Pravidlo 4 uvádí, že relační databáze se musí popisovat sama. Jinými slovy, databáze musí obsahovat množinu systémové tabulky, popisující strukturu samotné databáze.

Pravidlo 5 vyžaduje, aby DBMS používal jazyk relační databáze, např. SQL . Takový jazyk musí podporovat všechny hlavní funkce DBMS – vytváření databáze, čtení a zadávání dat, implementace zabezpečení databáze atd.

Pravidlo 6 obav nápady, které jsou virtuální stoly, což umožňuje různým uživatelům vidět různé části struktury databáze. Jde o jedno z nejobtížněji proveditelných pravidel v praxi.

Pravidlo 7 zdůrazňuje, že databáze jsou svou povahou orientované na množiny. Vyžaduje, aby operace přidání, odstranění a aktualizace bylo možné provádět na sadách řádků. Toto pravidlo má zakázat implementace, které podporují pouze operace s jedním řetězcem.

Pravidla 8 a 9 znamenají oddělení uživatele a aplikačního programu od nízkoúrovňové implementace databáze. Tvrdí, že konkrétní implementace úložiště nebo přístupu používané v DBMS, a dokonce i změny ve struktuře databázových tabulek, by neměly ovlivnit schopnost uživatele pracovat s daty.

Pravidlo 10 uvádí, že jazyk databáze musí podporovat omezující podmínky kladené na zadávaná data a akce, které lze s daty provádět.

Pravidlo 11 uvádí, že databázový jazyk musí být schopen pracovat s distribuovanými daty umístěnými na jiných počítačových systémech.

Pravidlo 12 zabraňuje použití jiných funkcí databáze, než je jazyk databáze, což by mohlo ohrozit integritu databáze.

12.2. Normalizace.

Při práci se vztahy, které obsahují redundantní data, problémy, které se nazývají aktualizovat anomálie a dělí se na anomálie inzerce, anomálie delece a anomálie modifikace. Zvažte například vztah uvedený na snímku ( snímek 7 ).

Anomálie vkládání. Do relační tabulky nelze přidat například informace o oboru, který ještě žádný student neprovedl. Na druhou stranu přidání nového oboru pro studenta bude vyžadovat duplikaci informací o studentovi, což vede k potenciální nekompatibilitě dat (v případě chyb ve vstupu).

Anomálie mazání. Při mazání informací z relační tabulky o studentech, kteří složili zkoušku nebo test v určitém oboru, dojde k úplnému vymazání informací o samotném oboru.

Anomálie modifikace. Způsobit potenciální nekonzistenci dat, ke které dochází při zadávání duplicitních dat (v případě chybného zadání jedné nebo více hodnot), stejně jako při úpravách duplicitních dat.

Výše uvedeným anomáliím se lze vyhnout normalizací počátečního poměru.

Proces normalizace je rozklad tabulky na dvě nebo více, aby se eliminovala duplicita dat a potenciální nekonzistence. Konečným cílem normalizace je dosáhnout návrhu databáze, ve kterém se „každá skutečnost objeví pouze na jednom místě“.

12.2.1. Funkční závislosti

Proces normalizace je založen na konceptu funkční závislosti. Funkční závislost popisuje vztah mezi atributy vztahu: jestliže ve vztahu R obsahujícím atributy A a B atribut B funkčně závisí na atributu A, pak každá jednotlivá hodnota atributu A je spojena pouze s jednou hodnotou atributu B (a skupinami atributů může fungovat jako A a B). Atribut nebo skupina atributů A se nazývá determinant funkční závislost ( snímek 8 ).

V případě funkční závislosti A →B se tedy n-tice (řádky), které mají stejnou hodnotu atributu A, také shodují s hodnotou atributu B. Opak však neplatí: stejná hodnota atributu B může odpovídat různým hodnotám atributu A. Například z funkčního vztahu Zaměstnanec → Pozice vyplývá, že kdekoli bude uveden zaměstnanec „Eremeev V.K.“ bude mu odpovídat pozice „Profesor“, ale pozici „Profesor“ mohou mít i ostatní zaměstnanci.

Funkční závislost A →B je plný funkční závislost, pokud odstranění jakéhokoli atributu ze skupiny atributů A povede ke ztrátě této závislosti. Funkční závislost A →B je částečný funkční závislost, pokud skupina atributů A obsahuje jeden nebo více atributů, které si po odstranění zachovají závislost.

Pokud pro atributy A, B a C nějaké relace existují funkční závislosti A →B, B →C, říká se, že atribut C souvisí tranzitivní závislost s atributem A až atributem B (v tomto případě by atribut A neměl funkčně záviset na atributu B ani atributu C).

Vícehodnotová závislost. O jednom atributu tabulky se říká, že vícehodnotově definuje jiný atribut téže tabulky, pokud pro každou hodnotu prvního atributu existuje dobře definovaná sada odpovídajících hodnot druhého atributu ( snímek 9 ).

Jako příklad zvažte fragment tabulky „Přijímání zkoušek (testů)“. Tabulka odráží vztah mezi disciplínou a formulářem hlášení se jménem učitele. V této tabulce existuje vícehodnotový vztah „Disciplína – učitel“: disciplínu „Matematická analýza“ vyučuje několik učitelů (Rakov I. I., Rybin K. K., Karpov K. Yu.), a proto se všichni mohou zúčastnit skládání zkoušek (testů). Dalším vícehodnotovým vztahem je „Disciplína – Formulář hlášení“: ve stejné disciplíně lze provádět zkoušku i test. Zároveň nejsou Formulář hlášení a Učitel propojeny funkční závislostí, což vede k redundanci (pro přidání jména dalšího učitele budete muset do tabulky zadat dva nové řádky).

12.2.2. Normální formy

V každé fázi normalizace je každý ze vztahů v některém z tzv normální formy. Normální formy (od nejnižší po nejvyšší) souvisí operací inkluze, tzn. starší normální forma má vlastnosti všech předchozích a navíc má své vlastní charakteristické rysy.

Normalizace je formální metoda pro analýzu vztahů identifikací primárního klíče a existujících funkčních závislostí. Postupné odstraňování dílčích funkčních závislostí a tranzitivních závislostí se provádí rozkladem vztahů a jejich převedením do další (vyšší) normální formy.

Relační tabulka je v první normální formě (1NF), Pokud ( snímek 10 )

Každá hodnota jakéhokoli atributu je atomická;

V tabulce nejsou žádné identické řádky;

Každý sloupec je jednoznačně pojmenován názvem atributu a obsahuje aktuální hodnotu tohoto atributu;

Každý atribut je spojen s určitou doménou (datovým typem).

Relační tabulka v 1NF má primární klíč - atribut nebo sbírka atributů, jejichž hodnoty jedinečně charakterizují každý záznam.

Relační tabulka je ve druhé normální formě (2NF), pokud splňuje definici 1NF a všechny jeho atributy, které nejsou obsaženy v primárním klíči, jsou plně funkčně závislé na primárním klíči.

Relační tabulka je ve třetí normální formě (3NF)(snímek 11 ), pokud splňuje definici 2NF a žádný z jeho neklíčových atributů nemá tranzitivní funkční závislost na primárním klíči (to znamená, že žádný z neklíčových atributů nemá funkční závislost na žádném jiném neklíčovém atributu).

Stůl je v Boyce-Codd třetí normální forma (BCNF)(silná třetí normální forma) tehdy a jen tehdy, když se jakákoli funkční závislost mezi jejími atributy redukuje na úplnou funkční závislost na možný primární klíč (to znamená, že všechny determinanty vztahu jsou potenciální primární klíče).

Obvykle se v praxi spokojí s převodem relační databáze na 3NF nebo BCNF, takže zde nebudeme uvažovat vyšší normální formy.

Následující normální formy (4NF a 5NF) zohledňují nejen funkční, ale i vícehodnotové závislosti mezi atributy. Abychom mohli poskytnout definice těchto normálních forem, zavedeme koncept úplného rozkladu tabulky ( snímek 12 ).

Úplný rozklad tabulky nazývat takovou sbírku libovolného počtu jejích projekcí, jejichž spojení se zcela shoduje s obsahem tabulky.

Stůl je v pátá normální forma (5NF) právě tehdy, když v každém z jeho úplných rozkladů všechny projekce obsahují možný klíč. Tabulka, která nemá žádný úplný rozklad, je také v 5NF.

Čtvrtá normální forma (4NF) je speciální případ 5NF, kdy úplný rozklad musí být spojením právě dvou projekcí. V praxi není snadné najít skutečnou tabulku, která by byla v 4NF, ale ne v 5NF.

12.3. Postup normalizace ( snímek 14)

Postup převodu tabulek do 3NF je založen na skutečnosti, že jediné funkční závislosti v jakékoli tabulce by měly být závislosti formuláře A→K, Kde K je primární klíč a A- nějaký atribut. Účelem normalizace je odstranit další funkční závislosti.

Existují dva možné případy:

1. Tabulka má složený primární klíč, například ( K1, K2), a také obsahuje atribut A, který funkčně závisí na části tohoto klíče (například na K2), ale ne z úplného klíče. V tomto případě se doporučuje vytvořit další tabulku obsahující atributy K2 A A(primární klíč - K2) a odeberte atribut A z původní tabulky ( snímek 15 ).

2. Tabulka má primární (možný) klíč NA, atribut A1, což není možný klíč, ale funkčně závisí na NA a další neklíčový atribut A2, na kterém funkčně závisí A1. Řešení je zde v podstatě stejné jako dříve – vytvoří se další tabulka obsahující atributy A1 A A2, s primárním klíčem A1 a atribut A2 je odstraněn z původní tabulky (snímek 16).

Opakováním aplikace dvou diskutovaných pravidel pro jakoukoli danou tabulku v téměř všech reálných praktických situacích lze tedy nakonec získat sadu tabulek, které jsou v 3NF nebo BCNF a neobsahují žádné funkční závislosti formy jiné než A→NA.

12.4. Odvození relačního schématu z ER diagramu ( snímek 17)

1. Každá jednoduchá entita se promění v tabulku (vztah). Název entity se stane názvem tabulky.

2. Vztah many-to-many je považován za vztah entity a mění se v tabulku (vztah). Vztah mnoho k mnoha se tak transformuje na dva vztahy mnoho k jednomu.

3. Každý atribut se stane možným sloupcem se stejným názvem. Sloupce odpovídající volitelným atributům mohou obsahovat hodnoty null; sloupce odpovídající požadovaným atributům nemohou. Pokud je atribut vícenásobný, je pro něj vytvořen samostatný vztah.

4. Komponenty jedinečného identifikátoru entity se změní na primární klíč. Pokud existuje více možných jedinečných identifikátorů, vybere se ten nejpoužívanější. Pokud jedinečný identifikátor zahrnuje vztahy, pak se k počtu sloupců primárního klíče přidá kopie jedinečného identifikátoru entity na vzdáleném konci vztahu (tento proces může pokračovat rekurzivně). Tyto sloupce jsou pojmenovány pomocí názvů konce vztahů a/nebo názvů entit.

5. Vztahy many-to-one a one-to-one se stávají cizími klíči. Tito. Vytvoří se kopie jedinečného identifikátoru z "jednoho" konce vztahu a odpovídající sloupce tvoří cizí klíč.

6. Indexy jsou vytvářeny na primárním klíči (unikátní index), stejně jako cizí klíče a ty atributy, které budou často používány v dotazech.

7. Pokud jsou v koncepčním schématu podtypy, jsou možné dvě možnosti.

Všechny podtypy jsou uloženy v jedné tabulce, která je vytvořena pro nejvzdálenější nadtyp, a pro podtypy jsou vytvořeny pohledy. Do tabulky je přidán alespoň jeden sloupec obsahující kód TYPE a stává se součástí primárního klíče.

Ve druhém případě se pro každý podtyp vytvoří samostatná tabulka a pro každý podtyp první úrovně (u nižších - pohledů) se nadtyp znovu vytvoří pomocí pohledu UNION (běžné sloupce - sloupce nadtypu - se vybírají ze všech tabulek podtypů) .

8. Pokud zbývající cizí klíče patří všechny do stejné domény, tzn. mají společný formát, jsou vytvořeny dva sloupce: identifikátor vztahu a identifikátor entity. Sloupec ID vztahu se používá k rozlišení vztahů. Sloupec identifikátoru entity se používá k uložení hodnot jedinečných identifikátorů entity na vzdáleném konci odpovídajícího vztahu.

Pokud výsledné cizí klíče nepatří do stejné domény, pak se pro každý vztah pokrytý obloukem vyloučení vytvoří explicitní sloupce cizího klíče.