Domov › Služby › Návrh relačních databází. Návrh relačních databází založených na principech normalizace: první kroky normalizace. Každý student studuje daný předmět u jednoho učitele

Návrh relačních databází. Návrh relačních databází založených na principech normalizace: první kroky normalizace. Každý student studuje daný předmět u jednoho učitele

Vláda Ruská Federace

Národní výzkumná univerzita

STŘEDNÍ ŠKOLA EKONOMICKÁ

POBOČKA PERMU

oddělení informační technologie v byznysu

Informační technologie v kancelářská práce

Rozvoj informační systém podniky používající systém správy databází Přístupová data 2007

Vzdělávací a metodická příručka

Perm 2011

Informační technologie v kancelářské práci. Vývoj podnikového informačního systému s využitím systému pro správu databází Access 2007 Výukový manuál. NRU HSE PF, 2011, 40 s.

Sestavili: Vikentyeva Olga Leonidovna, Lebedev Valery Viktorovich.

Vzdělávací příručka je zpracována v souladu se Státním vzdělávacím standardem, osnovy a koncepce oboru „Informační technologie v ekonomii“. Příručka je určena studentům a učitelům Penzijní fakulty Státní univerzity vyšší ekonomické školy a obsahuje řadu praktické třídy, odhalující možnosti moderních informačních technologií vytvářet systémy pro ukládání, získávání a prezentaci dat.

Recenzent: docent katedry informatiky Permského krajského ústavu pedagogických informačních technologií, kandidát pedagogických věd, člen korespondent Akademie informatizace školství Kushev V.O.

Lekce 1. Design vztahová základna data

V obvyklém smyslu je databáze soubor nebo sada souborů, které mají určitou organizaci. Při práci s konvenční systémy zpracování souborů vzniká řada problémů, zejména s redundancí a závislostí dat v nich uložených. Při návrhu databáze jsou tyto problémy vyřešeny.

Uživatel se musí zúčastnit procesu návrhu databáze, protože pouze on může určit, jaká data jsou pro práci potřebná, uvést souvislosti, které mezi těmito daty existují, a věnovat pozornost jemnosti jejich zpracování.

Informační potřeby jednotlivého uživatele se obvykle dotýkají pouze části dat uložených v informačním systému a popis těchto potřeb se nemusí shodovat s popisy potřeb ostatních uživatelů. Představa o tom, jaké informace jsou potřebné pro práci, se bude lišit různé skupiny uživatelé, specialisté v různých oborech - záleží na povinnostech, které vykonávají (personalisté a účetní pracovníci, vedoucí oddělení apod. potřebují k výkonu svých funkcí různá data). Tyto potřeby jsou popsány v vnější úroveň prezentace dat (pohledy A, B a C na obr. 1).

Externí popisy V důsledku toho může být v databázi uloženo velké množství dat. Je třeba je dát dohromady koncepční pohled, popisující data na úrovni celého informačního systému jako celku. Prezentace těchto dat na interní úrovni je dána způsobem, jakým jsou uložena externí paměť.

Uvažujme příklad databáze informačního systému firmy, která dodává zboží do městských prodejen, přičemž zohledníme pouze informační potřeby dvou zaměstnanců firmy (ve zjednodušené podobě – jinak by byl příklad příliš těžkopádný ).

Obrázek 1. Tvorba reprezentace dat

Zaměstnanec pro styk se zákazníky potřebuje informace uvedené na obrázku 2, aby mohl plnit své povinnosti.

Zaměstnanec, který pracuje s platebními formuláři, potřebuje další informace o klientech (obr. 3).

Data využívaná jednotlivými specialisty jsou umístěna v jednotném informačním systému podniku, v pro ně společné databázi. Vnější pohledy jednotlivých uživatelů je proto nutné integrovat do konceptuálního pohledu, cílem popisu dat na konceptuální úrovni je vytvořit takový formální pohled na data, aby jakýkoli externí pohled byl jeho podmnožinou. Proces integrace externích reprezentací eliminuje nejasnosti a rozpory v informačních potřebách jednotlivých uživatelů. Koncepční popis reprezentující celou databázi musí být jedinečný.

Obrázek 2. Údaje pro prvního zaměstnance

Obrázek 3. Údaje pro druhého zaměstnance

V tomto příkladu musí koncepční pohled zahrnovat všechny informace potřebné pro všechny zaměstnance. Rozpory mohou vznikat v důsledku toho, že zaměstnanci, kteří používají obecná informace, může si to představit různě (např.: lze napsat telefonní číslo různé formáty). Všechny tyto rozpory musí být odstraněny, data a forma jejich prezentace musí být konzistentní.

Potom je pojmový popis určen následujícími informacemi

Data popsaná koncepčním diagramem musí být zaznamenána v externí paměti, na VRAM, určené k ukládání informací umístěných v databázi. Vnitřní popis data charakterizují způsob ukládání dat do externí paměti.

Pravidla pro popis dat jsou určena vybraným datový model(PROTI v tomto případě uvažuje se pouze o relačním modelu – v současnosti nejběžnější).

Vezmeme-li popis údajů o klientech společnosti zabývající se dodávkou zboží do městských prodejen z příkladu výše uvedeného na obr. 4, pak údaje popsané touto tabulkou nelze v této podobě prezentovat v relační databázi, neboť všechny hodnoty jsou atomické (složky řádků „Vlastník“ a „Adresa“ se skládají z několika hodnot, tj. hodnoty těchto atributů jsou nahrazeny jinými vztahy, jimi dešifrované ve vztahu popisujícím vlastníka, pole „ Adresa“ a „Pas“ také nejsou atomické, proto je vytvořena hierarchie.

Při návrhu databáze je lze vzít různá řešení, ale existují základní požadavky, které je třeba vzít v úvahu během pracovního procesu: soubor vztahů musí zajistit minimální redundanci při prezentaci informací; manipulace s daty, úprava vztahů by neměla vést k narušení integrity dat, nejednoznačnosti a ztrátě informací; restrukturalizace množiny vztahů při přidávání nových atributů do databáze by měla být minimální.

Obrázek 4. Obecná prezentace dat

Popis skutečných objektů a vztahů mezi nimi je do značné míry subjektivní, ale jisté existují hlavní pravidla, zejména, normalizační pravidla. Normalizace chrání integritu dat odstraněním duplikace dat. Výsledkem je, že reprezentace dat o jediném objektu může být rozdělena do několika menších souvisejících tabulek (bezeztrátový rozklad). Omezení, která je třeba dodržovat při návrhu relační databáze, je poměrně mnoho. S implementací je spojeno dodržování omezení při definování konkrétních vztahů v databázi normální formy. Normální formuláře jsou číslovány postupně, počínaje prvním. Čím větší číslo normální formy databáze vyhovuje, tím více omezení na data uložená v databázi je třeba dodržet. Je možné typické pro relační DBMS zavést omezení doplňková sada omezení, což povede ke zvýšení počtu normálních forem.

Špatně navržená databáze může ukládat všechny informace do jedné tabulky. Pro příklad popsaný výše by taková tabulka mohla obsahovat následující sloupce:

Komponenty Ulice a Adresa domu byly přejmenovány, aby vyhovovaly požadavku, že názvy sloupců musí být jedinečné (pravidla pro pojmenování se liší podle DBMS).

Jaké jsou nevýhody tohoto nápadu?

První normální forma vyžaduje, aby na každém průsečíku řádku a sloupce byla jedna hodnota, která musí být nedělitelná (požadavek atomicity). Kromě toho v relační tabulka Neměly by existovat žádné duplicitní řádky nebo skupiny dat.

Požadavek atomicity je splněn - složené sloupce „Adresa“ a „Vlastník“ (a pro vlastníka „Adresa“ a „Pas“) jsou rozděleny na komponenty, které jsou zahrnuty v celkové tabulce. Ale jeden obchod může mít několik vlastníků a jedna osoba může vlastnit několik obchodů. To znamená, že tabulka bude muset obsahovat všechny řádky představující „kombinace“ prodejen a jejich vlastníků, tzn. PROTI různé linie skupiny dat se budou opakovat (údaje o obchodě se budou opakovat několikrát - pro každého jeho vlastníka a údaje vlastníka se budou opakovat pro každý jeho obchod). Taková reprezentace dat vede k obrovské redundanci a k tomu, že paměť na VRAM bude využívána neefektivně. Duplikace informací může navíc vést k problémům při jejich zpracování: abyste mohli provést změny informací o obchodě (například pokud se změní jeho bankovní účet), musíte tyto údaje změnit v několika záznamech odpovídajících různým vlastníkům.

Při určování, které tabulky by měly být zahrnuty do databáze a jaké informace by v nich měly být uloženy, je třeba vzít v úvahu následující pravidlo: každá tabulka popisuje objekt, existující samostatně, mající své vlastní vlastnosti. Konstrukce databáze by měla začít vytvořením reprezentace každého objektu ve formě řádků obsahujících jeho atributy v odpovídající tabulce; definování modelů objektových vztahů. V uvažovaném příkladu by databáze měla ve skutečnosti uchovávat informace o objektech dvou typů: o obchodech ao jejich vlastníkech. Tyto informace by měly být umístěny ve dvou různých tabulkách (Obchody a Vlastníci) s následujícími sloupci:

"Obchody"

"vlastníci"

Každý řádek tabulky "Store" bude popisovat instanci odpovídajícího objektu (jeden obchod). A každý řádek tabulky „Vlastníci“ bude obsahovat informace o jednom majiteli obchodu.

Při práci s informacemi uloženými v databázi musí být DBMS schopny od sebe odlišit řádky. Atribut nebo sada atributů, které jednoznačně identifikují řádek, je jeho primárním klíčem.

Co lze zvolit jako primární klíč pro výše popsané tabulky?

Klíč relace je taková sada atributů, že každá kombinace jejich hodnot se vyskytuje pouze v jednom řádku vztahu a žádná podmnožina těchto atributů tuto vlastnost nemá. Klíč tedy jednoznačně identifikuje řádek a umožňuje jeho výběr z celé sady řádků ve vztahu.

Definujme klíč pro tabulku "Obchody".

Pokud jako klíč vyberete atribut Store Name, bude splňovat zadaný požadavek? Ne, pokud v jednom městě může být několik obchodů se stejnými názvy různé části města. Pro zajištění jednoznačnosti byste měli název prodejny doplnit o její adresu (podle názvu prodejny a její adresy lze jednoznačně vybrat požadovaný řádek v tabulce), pak bude klíč vztahu složený.

S jednoduchým klíčem, identifikace správný obchod, může být číslo bankovního účtu (pokud má každá prodejna jedno číslo běžného účtu a každý běžný účet patří jedné prodejně). Klíčem může být i daňové identifikační číslo ( identifikační číslo) obchod.

Jako primární klíč vybereme atribut „TIN“. Dále bude tento atribut použit k uspořádání spojení mezi tabulkami „Obchody“ a „Vlastníci“ (tato propojení by měla odrážet skutečné vztahy mezi obchody a jejich vlastníky).

Pojďme se rozhodnout o klíčích pro tabulku „Vlastníci“.

Pokud bychom mohli předpokládat, že mezi majiteli obchodů nejsou žádní jmenovci, pak bychom mohli jako klíč vybrat atribut „Last Name“ daného vztahu. Majitelé obchodů ale bohužel mohou být nejen jmenovci, ale i úplní nohsledi (nepravděpodobné, ale docela možné). Jako klíč tedy můžete vybrat údaje z pasu majitele, tzn. k identifikaci použijte složený klíč, včetně atributů „Série“ a „Číslo“. Tento klíč budeme považovat za primární klíč. S jeho pomocí navážeme spojení mezi majitelem a jeho prodejnami.

Primární klíče zajistí nejen jednoznačnost při vyhledávání informací (jsou jedinečné), ale umožní také propojit data umístěná ve dvou tabulkách.

Pojďme definovat typ vztahu mezi tabulkami "Obchody" a "Vlastníci".

Pokud předpokládáme, že jedna osoba může vlastnit několik obchodů, ale každý obchod má jednoho vlastníka, pak bychom mezi těmito tabulkami vytvořili vztah jedna k mnoha. Pro uspořádání takového spojení v databázi by bylo možné zahrnout do řádku tabulky „Obchody“ obsahující informace o obchodě externí klíč, identifikující vlastníka prodejny, tzn. údaje o jeho pasu – atributy „Série“ a „Číslo“. V tomto případě není možné zorganizovat spojení zahrnutím klíče „TIN“, který identifikuje obchody, jako cizího klíče v tabulce „Owners“, protože v tomto případě by musely být informace o vlastníkovi duplikovány pro každý obchod. .

Pokud vycházíme z předpokladu, že jedna osoba může vlastnit pouze jeden obchod, ale každý obchod může mít více vlastníků, dostaneme vztah jeden k mnoha, ale v tomto případě externí klíč(obchodní daňové identifikační číslo) by muselo být zahrnuto do tabulky obsahující informace o vlastníkech.

Ve skutečnosti může být každá osoba vlastníkem několika obchodů a každá prodejna může mít několik vlastníků, takže mezi tabulkami „Obchody“ a „Vlastníci“ musí být vytvořen vztah „mnoho k mnoha“, pro jehož uspořádání musí být vytvořena speciální tabulka. je vytvořen, který popisuje vztahy mezi obchody a majiteli:

"Majitelé obchodů"

CÍN

Série

Číslo

Tato tabulka vám umožní najít všechny její vlastníky pomocí atributu „TIN“ obchodu (prostřednictvím údajů v jejich pasech) a pomocí složeného atributu, který zahrnuje atributy „Series“ a „Number“ vlastníkova pasu do najít v databázi všechny obchody, které vlastní.

Chcete-li to provést, po vytvoření tabulky „Vlastníci prodejen“ vytvořte vzájemné vztahy mezi tabulkou „Obchody“ a tabulkou „Vlastníci prodejen“ a také mezi „Vlastníky“ a „Vlastníci prodejen“. tabulky:

CÍN Série Číslo

"Majitelé obchodů"

Navázaná spojení pomáhají DBMS udržovat integritu a konzistenci informací. Můžete například nastavit pravidla pro aktualizaci informací v související tabulky při aktualizaci informací v hlavní tabulce (při likvidaci obchodu je např. nutné smazat informace o něm z databáze a přenést do archivu nejen řádek z tabulky „Obchody“, ale i všechny informace v přidruženém tabulky vztahující se k tomuto obchodu).

Pro pohodlí uživatelů a pro urychlení vyhledávání podporují DBMS možnost vyhledávání nejen podle unikátní klíče. V tabulce můžete například najít všechny obchody se stejnými názvy nebo všechny obchody vlastněné stejným vlastníkem.

Normalizace dat vedla k rozdělení tabulek a rozdělení vztahů primárního klíče a cizího klíče do menších tabulek. Výsledkem normalizace je snížení redundance dat – odpadá nutnost duplikovat data o každém majiteli pro každý obchod.

Druhá normální forma vyžaduje, aby každý neklíčový sloupec závisel na svém primárním klíči (a na celém klíči, nikoli na jeho jednotlivých komponentách). Relace je v druhé normální formě, pokud odpovídá první normální formě a neobsahuje neúplné funkční závislosti. Neúplná funkční závislost je definována dvěma podmínkami: klíč vztahu funkčně definuje nějaký neklíčový atribut a část klíče funkčně definuje stejný neklíčový atribut.

Vztah, který neodpovídá druhé normální formě, je charakterizován redundancí uložených dat.

V uvažovaném příkladu je sada atributů vztahu a výběr klíčů proveden tak, že tabulky odpovídají druhé normální formě. Pokud by tato korespondence neexistovala, bylo by pro redukci tabulek na druhou normální formu nutné rozdělit opakující se informace (část klíče a neklíčové atributy, které definuje) na samostatný stůl.

Například: v databázi je nutné uchovávat informace o zboží, které je dodáváno do prodejen. Tyto informace zahrnují atributy „Název“, „Kód“ a „Cena“ produktu a také „Množství“ dodaného produktu. Pokud tyto informace zahrnete do tabulky "Dodávky" v další představení:

"Dodávky"

(zde „DIČ“ identifikuje obchod, do kterého byla dodávka doručena (jedná se o cizí klíč používaný k vytvoření vztahu jedna ku mnoha mezi tabulkou „Obchody“ a touto tabulkou), „Název“ je název produktu , „Kód“ je jeho unikátní kód(produkty s různé vlastnosti a proto různé ceny mohou mít stejný název, ale kódy se budou lišit), „Cena“ je prodejní cena produktu, „Množství“ je množství dodaného produktu), pak může nastat redundance.

Chcete-li definovat řádek představující dodávku zboží do konkrétního obchodu, můžete zadat složený klíč, který obsahuje atributy „TIN“ a „Code“. Tyto informace umožňují určit cenu produktu a jeho dodané množství tento obchod a také vypočítat Celkové náklady zboží. Pokud předpokládáme, že produkt je dodáván do všech obchodů za stejnou cenu a cena se v čase nemění, pak neklíčový atribut „Cena“ je určen nejen složeným klíčem „DIČ“ + „Kód“, ale i jeho část – atribut „Kód“ “ Ve všech řádcích tabulky, které obsahují informace o dodávce stejného produktu, se tedy opakuje stejná cena. To vede k nadbytečnosti. Název produktu je také určen jeho kódem. Proto lze informace, které se týkají pouze produktu a nezávisí na obchodě, umístit do samostatné tabulky:

Zde vám klíčové pole „Kód“ umožní propojit údaje v tabulce „Dodávky“ s údaji z tabulky „Produkty“.

Redukce na druhou normální formu tak odstranila nadbytečnost oddělením nových tabulek: tabulka „Zásoby“ je rozdělena na dvě tabulky „Zásoby“ a „Zboží“, mezi nimiž je vytvořen vztah.

Třetí normální forma dále zvyšuje požadavky: vztah odpovídá druhé normální formě a mezi jeho atributy nejsou žádné tranzitivní funkční závislosti (žádný neklíčový sloupec by neměl záviset na jiném neklíčovém sloupci, může záviset pouze na primárním klíči).

V uvažovaném příkladu by se objevil nesoulad s třetí normální formou, pokud by byla splněna následující podmínka: všechno zboží se stejným názvem má stejnou cenu (název by byl určen kódem a cena názvem produkt). V tomto případě by se objevila redundance, protože cena za daný název produktu by se opakovala tolikrát, kolikrát by byly použity různé kódy pro tento produkt.

Redundance by bylo možné zbavit rozdělením tabulky „Produkty“ na dvě tabulky (jedna by obsahovala atributy „Kód“ a „Název“ a druhá „Název“ a „Cena“).

V uvažovaném příkladu je však situace jiná: zboží má různé kódy, pokud jsou jeho vlastnosti odlišné, proto by se měly lišit i ceny.

Čtvrtá normální forma zakazuje nezávislý vztah typ one-to-many mezi klíčovými a neklíčovými sloupci. Jednoduše řečeno, do jedné tabulky nelze umístit heterogenní informace, tzn. data, mezi nimiž není přímé spojení.

Toto pravidlo je vidět na následujícím příkladu. Pracovník pro styk se zákazníky plánuje využívat informace o rodinných příslušnících majitelů obchodů k plnění svých povinností. Tyto informace by neměly být zahrnuty do tabulky Owners, protože je obtížné určit, kolik místa by mělo být vyhrazeno v řádcích tabulky pro konkrétní osoby k uložení jejich informací. stav, – jeden může být svobodný a druhý může být otcem mnoha dětí. Informace o členech rodiny musí být umístěny v samostatné tabulce, jejíž každý řádek bude obsahovat informace o jednom členu rodiny, včetně cizího klíče identifikujícího vlastníka obchodu pro uspořádání spojení s tabulkou „Owners“.

Pátá normální forma obvykle dokončí proces normalizace. V této fázi jsou všechny tabulky rozděleny na minimální části, aby se v nich eliminovala redundance. Každá část neklíčových dat v tabulkách by se měla objevit pouze jednou. To eliminuje problémy s aktualizací informací v databázi: všechny změny neklíčových informací musí být provedeny pouze jednou, což poskytuje možnost spravovat integritu dat.

Proces návrhu databáze je velmi důležitá etapa ve vývoji informačních systémů. Právě kvalita návrhu do značné míry určuje efektivitu využití databáze.

V současné době široce používané speciální prostředky, usnadňující proces vývoje informačních systémů (CASE nástroje - Computer-Aided Software/System Engineering).

Otázky pro sebeovládání:

1. Co je to databáze?

2. Co je externí reprezentace dat?

3. Co je podstatou konceptuální reprezentace dat?

4. Co je to datový model?

5. Co je normalizace?

6. Co je to vztahový klíč?

7. Který klíč se nazývá cizí klíč?

8. Jaká spojení lze organizovat v databázi?

9. Co je podstatou každé z pěti normálních forem?

Zadání pro samostatná práce:

Navrhněte databáze společnosti poskytující služby zákazníkům. Databázi potřebují tři zaměstnanci společnosti. První z nich se zabývá účtováním služeb poskytovaných společností a potřebuje následující informace:

Druhý zaměstnanec shromažďuje informace o účinkujících a zajímá se o:

Třetí zaměstnanec pracuje s klienty a je pro něj důležité vědět.

Návrh databází informačního systému je poměrně pracný úkol. Provádí se na základě formalizace struktury a procesů předmětová oblast, informace o kterých se předpokládá uložení v databázi. Existují koncepční a schematicko-konstrukční návrhy.

Koncepční návrh databáze IS je do značné míry heuristický proces. Přiměřenost informačního modelu předmětného území budovaného v jeho rámci je ověřována experimentálně za fungování IS.

Pojďme si vyjmenovat fáze koncepční design :

· studovat předmět, abyste si o něm vytvořili obecnou představu;

· identifikace a analýza funkcí a úkolů vyvíjeného IS;

· stanovení hlavních objektů-entit předmětné oblasti a vztahů mezi nimi;

· formalizovaná reprezentace předmětné oblasti.

Při návrhu schématu relační databáze lze rozlišit následující postupy:

· definování seznamu tabulek a vztahů mezi nimi;

· stanovení seznamu polí, typů polí, klíčových polí každé tabulky (schéma tabulky), navazování spojení mezi tabulkami pomocí cizích klíčů;

· zavedení indexování polí v tabulkách;

· vývoj seznamů (slovníků) pro obory s výčtovými údaji;

· stanovení omezení integrity pro tabulky a vztahy;

· normalizace tabulek, úprava seznamu tabulek a vztahů.

Návrh databáze se provádí na fyzické a logické úrovni. Design zapnutý fyzické úrovni implementovány pomocí DBMS a často automatizované.

Logický návrh spočívá v určení počtu a struktury tabulek, vypracování databázových dotazů, vykazování dokumentů, vytváření formulářů pro zadávání a editaci dat v databázi atp.

Jeden z nejdůležitější úkoly logický design DB je strukturování dat. Rozlišují se následující: přístupy k navrhování datových struktur:

· kombinování informací o objektech entit v rámci jedné tabulky (jeden vztah) s následným rozkladem do několika vzájemně souvisejících tabulek na základě procedury normalizace vztahů;

· formulování znalostí o systému (určení typů zdrojových dat a vztahů) a požadavků na zpracování dat, získávání pomocí systému CASE hotové schéma DB nebo i hotový aplikační informační systém;

· implementace systémové analýzy a vývoj strukturálních modelů.

První přístup je klasický.

Proces návrhu začíná identifikací objektů entit, informace o nich budou uloženy v databázi, a definováním jejich atributů. Vybrané atributy jsou sloučeny do jedné tabulky (vztahu).

Kompletní informace o podstatě (tabulce) dává redundanci (opakování), Þ je nutná transformace, tzn. rozklad, tzn. rozdělení do několika tabulek, tzn. normalizace.

Þ Výsledný poměr podléhá normalizaci. Normalizační postup je iterativní a spočívá v postupném přenosu vztahů z první normální formy do normálních forem vyššího řádu.

Rozlišuje se následující sekvence normálních forem:

· první normální forma (1NF);

· druhá normální forma (2NF=1NF+něco);

· třetí normální forma (ZNF=2NF+něco);

· zvýšená třetí normální forma nebo Boyce-Coddova normální forma (BCNF);

· čtvrtá normální forma (4NF);

· pátá normální forma (5NF).

(Požadavky na 2NF)

se týká pouze primární klíč. Þ Každý údaj je v databázi uložen pouze na jednom místě. Þ Duplicitní data se přesunou do jiné tabulky a místo toho se použijí cizí klíče.

(Požadavky na 3NF)

Každé neklíčové pole by nemělo záviset na jiném neklíčovém poli (například vztah učitel – katedra nebo vztah předmět – katedra). Abyste tomu zabránili, musíte podrobně znát předmět. Þ Odstraníme „fakultu“ z „Rozvrhu“, pokud tam je „Speciality“.

3NF poskytuje deklarativní referencialitu (data z adresářů).

(Požadavky na 4NF)

Normalizace umožňuje eliminovat informační redundanci, která vede k anomáliím zpracování dat.

Zároveň je třeba rozlišovat mezi neredundantní a redundantní duplikací dat. Přítomnost prvního z nich v databázích je povolena. Zde jsou příklady obou možností duplikace.

Příkladem neredundantní duplikace dat je vztah „PHONES“ (obr. 5.6). Předpokládejme, že v jedné místnosti je instalován pouze jeden telefon, pak jsou telefonní čísla zaměstnanců umístěných ve stejné místnosti stejná. Telefonní číslo 24212 se objeví několikrát. Toto je duplikace. Číslo je však pro každého zaměstnance jedinečné a pokud se jedno z čísel smaže, dojde ke ztrátě informace o tom, kterým číslem lze konkrétního zaměstnance zastihnout. To je podstata neredundance.

Rýže. 5.6. Neredundantní duplikace dat

K nadměrné duplicitě dat dochází v relaci „ROOMS“, ke které je přidán atribut „Room Number“ (obr. 5.7).

Rýže. 5.7. Nadměrná duplikace dat

Zaměstnanci Belkin, Sinitsyn a Medveděv jsou ve stejné místnosti, a proto mají stejná čísla. To znamená, že telefonní číslo Sinitsyna a Medveděva lze zjistit z průvodu s informacemi o Belkinovi. To je redundance duplikace dat.

Nadměrná duplikace dat vede k problémům při zpracování relačních n-tic, které E. Codd nazývá „anomálie aktualizace vztahů“.

Anomálie- takové situace v databázových tabulkách, které vedou k rozporům v databázi nebo výrazně komplikují zpracování dat.

Existují tři hlavní typy anomálií:

· modifikační (editační) anomálie;

· odstranění anomálií;

· anomálie sčítání.

Anomálie modifikace se projevují tím, že změna hodnoty atributu může mít za následek revizi celé tabulky s odpovídající změnou hodnot tohoto atributu v jiných záznamech tabulky.

Změna telefonního čísla v místnosti 325 (obr. 5.7) tedy bude vyžadovat revizi celé tabulky „ROOMS“ a změnu hodnot atributu „Phone Number“ v záznamech, ve kterých se toto číslo vyskytuje.

Anomálie mazání se projevují tak, že při smazání libovolné hodnoty atributu zmizí i další informace, které s vymazanou hodnotou přímo nesouvisejí.

Smazání záznamu o zaměstnanci Volkovovi (např. z důvodu propuštění) tedy vede ke zmizení informace o telefonním čísle instalovaném v místnosti 320 (viz obr. 5.7).

Anomálie sčítání se projevují tím, že není možné přidat záznam do tabulky, dokud nejsou známy hodnoty všech jejích atributů, a také tím, že vkládání nový záznam bude vyžadovat revizi celé tabulky.

Například v tabulce „POKOJE“ (viz obr. 5.7) nelze zobrazit informace o místnosti s nainstalovaným telefonem, dokud v ní není umístěn žádný zaměstnanec (za předpokladu, že pole „Jméno“ je klíčové) .

Při přidávání informací o novém zaměstnanci do tabulky byste navíc měli v tabulce zkontrolovat nesrovnalosti, které mohou nastat, pokud omylem zadáte telefonní číslo nebo číslo pokoje. Příklad rozporu: zaměstnanci jsou ve stejné místnosti, ale mají různá telefonní čísla.

Způsob, jak eliminovat nadměrnou duplicitu a neutralizovat anomálie, je dekompozice, tedy rozštěpení původního vztahu (tabulky). Rozklad musí být reverzibilní, to znamená provádět bez ztráty informace

Návrh databází informačního systému je poměrně pracný úkol. Provádí se na základě formalizace struktury a procesů předmětové oblasti, o níž se předpokládá, že informace bude uložena v databázi. Rozlišovat pojmový A obvod-strukturální design.

Koncepční návrh databáze informačního systému je do značné míry heuristickým procesem Vhodnost informačního modelu předmětného území budovaného v jejím rámci je ověřována experimentálně za provozu informačního systému.

Uvádíme fáze koncepčního návrhu:

* studovat předmět, abyste si o něm vytvořili obecnou představu;

* identifikace a analýza funkcí a úkolů vyvíjeného IS;

* určení hlavních objektů-entit předmětné oblasti a vztahů mezi nimi;

* formalizovaná reprezentace předmětné oblasti.

Při návrhu schématu relační databáze lze rozlišit následující postupy:

*definování seznamu tabulek a vztahů mezi nimi;

*definování seznamu polí, typů polí, klíčových polí každé tabulky (schéma tabulky), vytváření vztahů mezi tabulkami pomocí cizích klíčů;

*zavedení indexování pro pole v tabulkách;

* vývoj seznamů (slovníků) pro obory s výčtovými údaji;

* stanovení omezení integrity pro tabulky a vztahy;

* normalizace tabulek, úprava seznamu tabulek a vztahů. Návrh databáze se provádí na fyzické a logické úrovni. Návrh na fyzické úrovni je realizován pomocí DBMS a je často automatizovaný.

Jedním z nejdůležitějších úkolů návrhu logické databáze je strukturování dat. Rozlišují se následující přístupy k navrhování datových struktur:

*kombinování informací o objektech entit v rámci jedné tabulky (jeden vztah) s následným rozkladem do několika vzájemně souvisejících tabulek na základě procedury normalizace vztahů;

* formulování znalostí o systému (určení typů zdrojových dat a vztahů) a požadavků na zpracování dat, získání hotového databázového schématu nebo i hotového aplikačního informačního systému pomocí systému CA5E;

* implementace systémové analýzy a vývoj struktur

Informační systémy

Lidstvo dnes zažívá informační explozi. Objem informací, které se k člověku dostávají prostřednictvím všech informačních médií, neustále roste. Pro každého člověka žijícího v informační společnosti je proto velmi důležité osvojit si prostředky k optimálnímu řešení problému akumulace, uspořádání a racionální použití informace.

Schopnosti lidského zpracování informací se s používáním počítačů dramaticky zvýšily. Při používání počítačů k řešení problémů informačních služeb lze rozlišit dvě období:

 počáteční období, kdy se úzký okruh lidí - systémových programátorů - zabýval řešením problémů zpracování informací a organizace dat. Toto období je charakteristické tím, že byly vytvořeny softwarové nástroje k řešení konkrétní úkol zpracování dat. Zároveň pro vyřešení dalšího problému, ve kterém byla použita stejná data, bylo nutné vytvořit nové programy;

 období systémového využívání počítačů. K vyřešení sady problémů na počítači jsou vytvořeny softwarové nástroje, které pracují se stejnými daty pomocí jediného informační model objekt. Tyto nástroje nejsou závislé na povaze objektu nebo jeho modelu, lze je využít pro informační služby pro různé úkoly. Lidstvo začalo organizovat informace v informačních systémech.

Informační systémy (IS) představují velké množství dat spolu se softwarem a hardwarem pro jejich zpracování. Existují tyto typy informačních systémů: věcné, dokumentační a expertní systémy.

Faktická IP - toto je pole faktů - konkrétní datové hodnoty o objektech skutečného světa.

Informace ve věcném IS jsou uloženy v přehledně strukturované podobě, takže jsou schopny dát jednoznačné odpovědi na položené otázky, např.: „Kdo je vítězem Mistrovství Ruska v gymnastice v roce 1999?“, „Kdo vlastní AUDI 80 auto s registrační značkou PA899P77?“, „Jaké je telefonní číslo v účetním oddělení Moskevské státní univerzity?“, „Kdo se stal prezidentem Ruska ve volbách v březnu 2002?“ atd. Věcné informační systémy nacházejí uplatnění doslova ve všech sférách lidské činnosti – ve vědě, hmotné výrobě, dopravě, medicíně, státní správě a veřejném životě, obchodu, kriminalistice, umění, sportu.

Dokumentační informační systémy sloužit zásadně jiné třídě úkolů, které nevyžadují jasnou odpověď na položenou otázku. Databáze takových systémů je tvořena souborem nestrukturovaných textových dokumentů (články, knihy, abstrakta, texty zákonů) a grafických objektů, vybavených tím či oním formalizovaným vyhledávacím aparátem. Účelem systému je zpravidla poskytnout na žádost uživatele seznam dokumentů nebo předmětů, které do určité míry splňují podmínky formulované v žádosti. Například: zobrazte seznam všech článků, ve kterých se vyskytuje slovo „Pushkin“. Základním rysem dokumentárního systému je jeho schopnost na jedné straně vytvářet pro uživatele nepotřebné dokumenty (například tam, kde je slovo „Puškin“ použito v jiném významu, než je zamýšleno), a na straně druhé ne vyrobit potřebné (např. pokud autor použil nějaké synonymum nebo špatně napsané). Dokumentační systém musí být schopen určit význam konkrétního termínu na základě kontextu, například rozlišovat mezi „sedmikráska“ (rostlina), „sedmikráska“ (typ tiskové hlavy tiskárny).

Expertní systémy (ES) - inteligentní systémy, navržené tak, aby hrály roli „poradce“, jsou postaveny na základě formalizovaných zkušeností a znalostí odborníka. Jádrem ES jsou znalostní báze, které obsahují znalosti odborníků (specialistů) v určité oblasti, na jejichž základě ES umožňuje modelovat úvahy specialistů z dané tematické oblasti.

Stanovená klasifikace a přiřazení informačních systémů k jednomu či druhému typu jsou zastaralé, neboť moderní věcné systémy často pracují s nestrukturovanými bloky informací (texty, grafika, zvuk, video) vybavenými strukturovanými deskriptory.

POZNÁMKY Z PŘEDNÁŠKY

Pro speciální studenty
T1002 „Software pro informační technologie“

(L.V. Rudíková, Ph.D., docentka)

Otázka 31. ARCHITEKTURA DBMS. RELAČNÍ DATOVÝ MODEL

1. Pojem databáze.

2. Třívrstvá databázová architektura.

3. Životní cyklus Databáze.

4. Architektura DBMS.

5. Relační datový model.

6. Návrh relačních databází.

7. Normální formy vztahů.

8. Relační algebra.

1. Pojem databáze.

Databázový systém je jakýkoli počítačový informační systém, ve kterém lze sdílet data mezi mnoha aplikacemi.

Informační systém – automatický systém, který organizuje data a poskytuje informace.

Informační a řídící systém – systém, který poskytuje informační podporařízení.

Data – rozptýlená fakta.

Informace – organizovaná a zpracovávaná data.

Pod databáze označuje soubor vzájemně propojených elementárních skupin dat (informací), které mohou být zpracovány jedním nebo více aplikačními systémy. Databázový systém sestává z databáze; tzv. univerzální software systém pro správu databází (DBMS) a slouží ke správě databáze; vhodné vybavení a lidi.

Každý DBMS musí splňovat následující požadavky:

· poskytují uživateli možnost vytvářet nové databáze a definovat je schéma (logická datová struktura) používáním speciální jazyk - jazyk pro definici dat; podporovat více pohledů na stejná data;

· nech" žádost» data a měnit je pomocí dotazovací jazyk nebo jazyk pro manipulaci s daty; umožňují integraci a sdílení data z různých aplikací;

· podporovat ukládání velmi velkého množství dat, měřených v gigabajtech nebo více, po dlouhou dobu, chránit je před náhodným poškozením a neoprávněným použitím a také poskytovat úpravu databáze a přístup k datům prostřednictvím dotazů, tzn. zaručit bezpečnost a integritu dat;

· řídit přístup k datům pro mnoho uživatelů současně; vyloučit vliv požadavku jednoho uživatele na požadavek jiného a zabránit současnému přístupu, který by mohl poškodit data, tzn. zajistit souběžnou kontrolu přístupu k datům.

Databázový systém se skládá z následujících komponent:

· Uživatelé, tzn. lidé, kteří data používají.

· Aplikace, tzn. uživatelské programy, které vyžadují data ze systému.

· DBMS je software, který řídí přístup k datům a poskytuje specifikované funkce databázového systému.

· Data, tzn. řetězce uložené v souborech.

· Hostitelský systém je počítačový systém, na kterém jsou uloženy soubory. K datovým řádkům přistupuje hostitelský systém. Úlohou DBMS je generovat dotazy, které umožňují využití funkcí správy souborů hostitelského systému pro obsluhu různých aplikací. DBMS je další vrstva softwaru postavená na softwaru hostitelského systému.

Systém s databází lze tedy reprezentovat jako následující posloupnost úrovní:

Vlastně nižší úroveň jsou data uložena ve fyzických souborech (fyzická databázová paměť). Na vyšší úroveň– aplikace s vlastní reprezentací stejných fyzických dat. Každý databázový pohled má své specifické logická struktura vytvořené ze základních fyzických dat. Poskytnout rozhraní mezi fyzická paměť Databáze a její různé logické verze (mnoho podporovaných pohledů) DBMS se zase musí skládat z několika úrovní.

2. Tříúrovňová databázová architektura.

Rozdíl mezi logickou a fyzickou reprezentací dat byl formálně uznán v roce 1978, kdy výbor ANSI/SPARC navrhl zobecněnou strukturu databázových systémů. Tato struktura se nazývá třívrstvá architektura. Tři úrovně architektury jsou: vnitřní, konceptuální a externí.

Vnitřní úroveň - toto je úroveň, která určuje fyzický vzhled databáze, která je nejblíže fyzickému úložišti a je spojena s metodami ukládání informací na fyzických úložných zařízeních. Diskové jednotky spojené s touto úrovní jsou fyzické adresy, indexy, ukazatele atd. Tato úroveň je v kompetenci fyzických návrhářů databází, kteří rozhodují o čem fyzická zařízení bude data ukládat, jaké přístupové metody budou použity k načtení a aktualizaci dat a jaká opatření by měla být přijata pro udržení nebo zlepšení výkonu systému správy databází. Uživatelé se této úrovně nedotýkají.

Koncepční úroveň – strukturální úroveň, definování logický obvod Databáze. Na této úrovni se provádí koncepční návrh databáze, který zahrnuje analýzu informačních potřeb uživatelů a identifikaci datových prvků, které potřebují. Výsledkem konceptuálního návrhu je konceptuální diagram, logický popis všech datových prvků a vztahů mezi nimi.

Vnější úroveň – strukturální úroveň databáze, která definuje uživatelské pohledy na data. Každý uživatelská skupina získává vlastní reprezentaci dat v databázi. Každý takový datový náhled poskytuje uživatelsky zaměřený popis datových prvků, které tvoří datový náhled, a vztahů mezi nimi. Lze jej přímo odvodit z koncepčního rámce. Sběr takových pohledů na uživatelská data poskytuje externí úroveň.

Uživatelské a aplikační pohledy	Vnější úroveň

Displeje

Koncepční schéma	Koncepční úroveň

Zobrazit	Vnitřní úroveň

Hostitelský systém

Uložená data

Rýže. Úrovně DBMS

3. Životní cyklus databáze.

Proces návrhu, implementace a údržby databázového systému se nazývá životního cyklu databáze (LDC). Postup pro vytvoření systému se nazývá životní cyklus systému (SLC).

Pochopení a správný přístup k LCBD je velmi důležité a vyžaduje podrobné zvážení, protože je založen na přístupu data-centrické. Datové prvky jsou stabilnější než vykonávané systémové funkce. Stvoření správná struktura data vyžadují komplexní analýzu tříd datových jednotek a vztahů mezi nimi. Pokud vytvoříte schéma logické databáze, pak v budoucnu můžete vytvořit libovolný počet funkčních systémů, které toto schéma využívají. Funkčně orientovaný přístup lze použít pouze k vytvoření dočasných systémů, které jsou navrženy pro krátkou dobu provozu.

LCBD se skládá z následujících fází:

1. Předběžné plánování – plánování databáze prováděné během procesu vývoje strategický plán DB. Během procesu plánování se shromažďují následující informace:

· jaké aplikační programy se používají a jaké funkce plní;

· jaké soubory jsou spojeny s každou z těchto aplikací;

· jaké nové aplikace a soubory jsou v práci.

Tyto informace pomáhají určit, jak se informace o aplikaci používají, a určit budoucí požadavky na databázový systém.

Informace z této fáze jsou dokumentovány ve formě zobecněného datového modelu.

2. Kontrola proveditelnosti . Zde se určuje technologická, provozní a ekonomická proveditelnost plánu vytvoření databáze, tj.

· technologická proveditelnost – je dostupná technologie pro implementaci plánované databáze?

· provozní proveditelnost – jsou k dispozici finanční prostředky a odborníci potřební k úspěšné implementaci plánu databáze?

· ekonomická proveditelnost – lze určit závěry? Zaplatí se plánovaný systém? Je možné odhadnout náklady a přínosy?

3. Definování požadavků zahrnuje výběr databázových cílů, vyjasnění informačních požadavků na systémové a hardwarové požadavky a software. Tedy na v tomto stádiu je vytvořen sběr dat a definování požadavků obecný informační model, vyjádřené v následujících úkolech:

· Cíle systému jsou určeny analýzou informačních potřeb. Nezbytně také naznačuje, jaký druh databáze by měl být vytvořen (distribuovaná, holistická) a jaké komunikační nástroje jsou potřeba. Výstupním dokumentem je komentář popisující cíle systému.

· Stanovení požadavků uživatelů: dokumentace ve formě zobecněných informací (komentáře, zprávy, průzkumy, dotazníky atd.); oprava funkcí systému a definice aplikační systémy který bude splňovat tyto požadavky. Údaje jsou prezentovány ve formě příslušných dokumentů.

· Stanovení obecných hardwarových a softwarových požadavků souvisejících s udržením požadované úrovně výkonu. (Zjistit počet uživatelů systému, počet vstupních zpráv za den, počet tiskových výstupů). Tyto informace se používají k výběru typů počítačů a DBMS, kapacitě disku a počtu tiskáren. Data z této fáze jsou prezentována ve zprávě obsahující ukázkové konfigurace hardwaru a softwaru.

· Vypracování plánu postupné tvorby systému včetně výběru prvotních aplikací.

4. Koncepční design – vytvoření konceptuálního databázového diagramu. Specifikace jsou vypracovány v rozsahu nezbytném pro přechod k implementaci.

Hlavní výstupní dokument je jeden informační model(nebo databázové schéma na koncepční úrovni). Při vývoji tohoto modelu se využívají informace a funkce, které musí systém plnit, stanovené ve fázi sběru a určování systémových požadavků. V této fázi je také žádoucí definovat: 1) pravidla pro data; 2) pravidla pro procesy; 3) pravidla pro rozhraní.

5. Implementace – transformační proces konceptuální model do funkční databáze. Zahrnuje následující kroky.

1) Výběr a nákup potřebných DBMS.

2) Převod konceptuálního (infologického) databázového modelu na logický a fyzický datový model:

· Na základě infologického datového modelu je sestaveno datové schéma pro konkrétní DBMS, v případě potřeby je databáze denormalizována, aby se urychlilo zpracování dotazů ve všech časově kritických aplikacích;

· je určeno, které aplikační procesy je třeba implementovat do datového schématu jako uložené procedury;

· implementovat omezení navržená k zajištění integrity dat a prosazování datových pravidel;

· navrhovat a generovat spouštěče pro implementaci všech centrálně definovaných datových pravidel a pravidel integrity dat, která nelze specifikovat jako omezení;

· vyvinout strategii indexování a shlukování; odhadnout velikosti všech tabulek, shluků a indexů;

· určit úrovně přístupu uživatelů, vyvinout a implementovat pravidla zabezpečení a auditu. Vytvářejte role a synonyma pro poskytování přístupu více uživatelům s konzistentními úrovněmi přístupových oprávnění.

· vyvinout síťovou topologii databáze a mechanismus pro bezproblémový přístup ke vzdáleným datům (replikované nebo distribuované databáze).

3) Konstrukce datového slovníku, který definuje ukládání definic databázových datových struktur. Datový slovník také obsahuje informace o přístupových oprávněních, pravidlech ochrany dat a kontrole dat.

4) Naplnění databáze.

5) Tvorba aplikační programy, manažerská kontrola.

6) Školení uživatelů.

6. Vyhodnocení a vylepšení databázového schématu. Zahrnuje průzkumné uživatele k identifikaci funkčních nesplněných potřeb. Změny se provádějí podle potřeby, přidávají se nové programy a datové prvky, jak se potřeby mění a rozšiřují.

LCBD tedy zahrnuje:

· Prostudujte si předmět a poskytněte příslušnou dokumentaci (1-3).

· Konstrukce informačního modelu (4).

· Realizace (5).

· Hodnocení výkonu a podpora databáze (6).

4. Architektura DBMS.

Rýže. Hlavní součásti DBMS

Data, metadata - obsahují nejen data, ale i informace o struktuře dat ( metadata). V relačním DBMS zahrnují metadata systémové tabulky (vztahy), názvy vztahů, názvy atributů těchto vztahů a datové typy těchto atributů.

Často DBMS podporuje indexy data. Index je datová struktura, která pomáhá rychle najít datové prvky dané části jejich hodnoty (například index, který najde n-tice určitého vztahu, které mají nastavená hodnota jeden z atributů). Indexy jsou součástí uložených dat a popisy udávající, které atributy indexy mají, jsou součástí metadat.

Správce paměti -přijímá požadované informace z místa úložiště dat a na žádost vyšších úrovní systému informace v něm mění.

V jednoduchých databázových systémech může být správcem paměti souborový systém operačního systému. Pro zlepšení efektivity však DBMS obvykle provádí přímou kontrolu paměti. Správce paměti se skládá ze dvou částí:

· Správce souborů sleduje umístění souborů na disku a přijímá blok nebo bloky obsahující soubory na vyžádání správcem vyrovnávací paměti (disk in obecný případ děleno diskové bloky- sousední paměťové oblasti obsahující od 4000 do 16000 bajtů).

· Správce vyrovnávací paměti spravuje hlavní paměť. Přijímá bloky dat z disku prostřednictvím správce souborů a vybírá stránku hlavní paměti pro uložení konkrétního bloku. Může dočasně uložit blok disku do hlavní paměti, ale vrátí ho na disk, když je potřeba stránka hlavní paměti pro jiný blok. Stránky jsou také vráceny na disk na žádost správce transakcí.

"Požadavek" procesor - zpracovává požadavky a požaduje změny údajů nebo metadat. Navrhuje nejlepší způsob provedení požadované operace a dává odpovídající příkazy správce paměti.

Procesor dotazů (správce) otočí dotaz nebo akci databáze, kterou lze dokončit velmi rychle vysoká úroveň(například formou žádosti SQL ), do sekvence požadavků na uložená data, jako jsou jednotlivé n-tice vztahu nebo části indexu vztahu. Často nejnáročnější část zpracování žádost je jeho organizace, tedy vybrat si dobrý plán dotazů nebo posloupnost požadavků na paměťový systém reagující na požadavek.

Správce transakcí - odpovídá za integritu systému a musí zajistit souběžné zpracování mnoha požadavků, absenci rušení požadavků (doplnění, min, max ) a ochranu dat v případě selhání systému. Spolupracuje se správcem dotazů, protože potřebuje vědět, jaká data jsou ovlivněna aktuálními dotazy (aby se předešlo konfliktům), a může odložit některé dotazy a operace, aby se předešlo konfliktům. Správce transakcí také spolupracuje se správcem paměti, protože schémata ochrany dat obvykle zahrnují ukládání protokolu změn dat. Na ve správném pořadí provést operaci se souborem Registrace bude obsahovat záznam změn, takže můžete znovu provést i ty změny, které se na disk nedostaly kvůli selhání systému.

Typické DBMS umožňují uživateli seskupit více dotazů a/nebo změn do jediné transakce. Transakce je skupina operací, které je nutné provádět postupně jako jeden celek.

Databázový systém obvykle podporuje více transakcí současně. Správné provedení všech takových transakcí zajišťuje transakční manažer. Je zajištěno správné provádění transakcíKYSELINA -vlastnosti (atomicita, konzistence, izolace, trvanlivost):

· atomicita- provedení buď všech transakcí, nebo žádné z nich (například výběr peněz z bankomatu a odpovídající inkaso z účtu klienta musí být jedinou atomickou transakcí; každou z těchto operací není dovoleno provádět samostatně);

· konzistence - stav, kdy údaje splňují všechna možná očekávání (např. podmínkou konzistence pro databázi leteckých společností je, že žádné sedadlo v letadle není rezervováno pro dva cestující);

· izolace- na paralelní provedení dvě nebo více transakcí, jejich výsledky musí být od sebe izolovány. Současné provedení dvou transakcí ve stejnou dobu by nemělo vést k výsledku, který by nenastal, pokud by byly provedeny postupně (například při prodeji letenek na stejný let v případě bezplatné poslední místo při současném požadavku dvou agentů musí být splněn požadavek jednoho, požadavek druhého nikoli);

· dlouhověkost - po dokončení transakce by neměl být výsledek ztracen v případě selhání systému, i když k tomuto selhání dojde bezprostředně po dokončení transakce.

Podívejme se také na 3 typy přístupu k DBMS:

1. Žádosti - Dotazy na data lze generovat dvěma způsoby:

A)používáním společné dotazovací rozhraní(například relační DBMS umožňuje dotazy SQL , které jsou přenášeny do procesoru požadavků a také na ně přijímá odpovědi);

b) s pomocí rozhraní aplikačních programů- požadavky jsou přenášeny přes speciální rozhraní(přes toto rozhraní nelze odesílat libovolné požadavky);

2. Modifikace - Jedná se o operace pro změnu dat. Mohou být také spouštěny buď prostřednictvím společného rozhraní, nebo prostřednictvím rozhraní aplikačního programu;

3. Úpravy obvodů - Jedná se o týmy administrátorů databáze, které mají právo změnit schéma databáze nebo vytvořit novou databázi.

Architektura klient/server. Mnoho verzí moderního softwaru implementuje architekturu klient-server: Jeden proces (klient) odešle požadavek jinému procesu (serveru) k provedení. Obvykle je databáze často rozdělena na serverový proces a několik klientských procesů.

V nejjednodušší architektuře klient/server je celý DBMS server, kromě dotazovacích rozhraní, která interagují s uživatelem a odesílají dotazy nebo jiné příkazy na server. Například relační DBMS často používá jazyk SQL reprezentovat požadavky od klienta k serveru. Databázový server pak poskytne klientovi odpověď ve formě tabulky (vztahu). Existuje tendence ke zvýšení zatížení klienta, protože pokud existuje mnoho současně pracujících uživatelů databáze, mohou nastat problémy se serverem.

5. Relační datový model.

RMD určité předmětové oblasti je soubor vztahů, které se v čase mění. Sada vztahů umožňuje při vytváření informačního systému ukládat data o objektech předmětné oblasti a modelovat vazby mezi nimi.

přístup je dvourozměrná tabulka obsahující některá data. Matematicky podN -ary vztah R porozumět kartézské sadě součinů D 1 D 2 … D n sady ( domény) D 1, D 2, …, D n (), volitelně různé:

R D 1 D 2 … D n,

kde D 1 D 2 … D n – kompletní kartézský součin, tzn. soubor všech možných kombinací n každý prvek, kde každý prvek je převzat ze své vlastní domény.

Doména je sémantický pojem. Doménu lze považovat za podmnožinu hodnot nějakého datového typu, které mají specifický význam. Doména se vyznačuje následujícími vlastnostmi:

· Doména má jedinečné jméno(v rámci databáze).

· Doména je definována u některých jednoduchý datový typ nebo na jiné doméně.

· Doména může mít nějaké logická podmínka, který umožňuje popsat podmnožinu dat, která je platná pro danou doménu.

· Doména nese určité sémantické zatížení.

Atribut vztahu existuje pár takových<Имя_атрибута: Имя_домена>. Názvy atributů musí být v rámci vztahu jedinečné. Názvy atributů vztahu jsou často stejné jako názvy odpovídajících domén.

Poměr , definovaný na více doménách, obsahuje dvě části: hlavičku a tělo.

Hlavička vztahu je pevný počet atributů vztahu:

Hlava relace popisuje kartézský součin domén, na kterých je relace definována. Hlavička je statická, při práci s databází se nemění. Pokud jsou atributy změněny, přidány nebo odstraněny ve vztahu, výsledek bude jiný vztah (i se stejným jménem).

Tělo vztahu obsahuje mnoho n-tice vztah. Každý n-ticový vztah představuje množinu dvojic formuláře<Имя_атрибута: Значение_атрибута>:

tak, že hodnota atributu patří do domény . Tělem vztahu je množina n-tic, tzn. podmnožina kartézského součinu domén. Tělo vztahu je tedy vlastně relací v matematickém smyslu slova. Tělo vztahu se může při práci s databází měnit – n-tice lze měnit, přidávat a mazat.

Vztah se obvykle píše takto:

nebo kratší

nebo jednoduše

Počet atributů ve vztahu se nazývá stupeň (nebo -arity ) vztah. Mohutnost množiny n-tic vztahu se nazývá Napájení vztah.

Vztahový diagram je seznam názvů atributů daného vztahu s uvedením domény, do které patří:

Pokud atributy nabývají hodnot ze stejné domény, pak se nazývají -comparable, kde je sada platných porovnávacích operací specifikovaných pro danou doménu. Pokud například doména obsahuje číselná data, jsou pro ni platné všechny porovnávací operace, pak . Pro domény obsahující znaková data však nelze zadat pouze porovnávací operace pro rovnost a nerovnost hodnot. Pokud má daná doména lexikografické uspořádání, pak má také celou škálu porovnávacích operací.

Schémata dvou vztahů se nazývají ekvivalent , pokud mají stejný stupeň a je možné seřadit názvy atributů ve schématech tak, že srovnatelné atributy, tedy atributy, které nabývají hodnot ze stejné domény, budou na stejných místech:

Nechat – vztahový diagram. – schéma vztahu po seřazení názvů atributů. Pak

Pro ekvivalentní vztahy jsou tedy splněny následující podmínky:

· Tabulky mají stejný počet sloupců.

· Tabulky obsahují sloupce se stejnými názvy.

· Sloupce se stejnými názvy obsahují data ze stejných domén.

· Tabulky mají stejné řádky, ale pořadí sloupců se může lišit.

Všechny tyto tabulky jsou jiné snímky stejný vztah.

Vlastnosti vztahů. Vlastnosti relací vyplývají přímo z výše uvedené definice relace. Tyto vlastnosti jsou hlavní rozdíly mezi relacemi a tabulkami.

· Ve vztahu nejsou žádné identické n-tice .

· N-tice nejsou objednány (shora dolů) .

· Atributy nejsou seřazeny (zleva doprava) .

· Všechny hodnoty atributů jsou atomické .

Rýže. Schematické znázornění vztahu

Relační model je databáze ve formě množiny vzájemně propojených vztahů. V každém spojení může jeden vztah působit jako hlavní a jiný vztah jako podřízený. Jedna n-tice hlavní relace tedy může být spojena s několika n-ticemi podřízené relace. Aby byly tyto vztahy podporovány, musí oba vztahy obsahovat sady atributů, kterými spolu souvisí. V podstatě to tak je primární klíč vztahu , který jednoznačně definuje n-tici hlavní relace. Aby bylo možné modelovat vztah, musí mít dílčí vztah sadu atributů, které odpovídají primárnímu klíči hlavního vztahu. Zde však tato sada atributů již je sekundární klíč nebo cizí klíč , tj. definuje množinu relačních n-tic, které jsou spojeny s jedinou n-ticí hlavní relace.

6. Návrh relačních databází.

Při návrhu relační databáze je třeba vyřešit následující problémy:

1) S přihlédnutím k sémantice předmětové oblasti je nutné co nejlépe reprezentovat objekty předmětné oblasti formou abstraktního datového modelu (data design). Tito. - rozhodnout o schématu databáze: z jakých vztahů by se měla databáze skládat, jaké atributy by tyto vztahy měly mít, jaké jsou vazby mezi vztahy.

2) Zajistit efektivitu provádění databázových dotazů (fyzický návrh databáze).

Po fázi datalogického návrhu by měly být získány následující výsledné dokumenty:

· Vytvoření správného datového schématu založeného na relačním datovém modelu.

· Popis schématu databáze z hlediska zvoleného DBMS.

· Popis externí modely z hlediska zvoleného DBMS.

· Popis deklarativních pravidel pro zachování integrity databáze.

· Vývoj postupů pro zachování sémantické integrity databáze.

Úkolem návrhu relační databáze je tedy vybrat databázové schéma z mnoha alternativních možností.

Opravit je databázové schéma, ve kterém nejsou žádné nežádoucí závislosti mezi relačními atributy. Proces vývoje správného databázového schématu se nazývá logický design .

Návrh databázového schématu lze provést dvěma způsoby:

· Dekompoziční (partiční) metoda – původní množina relací obsažená v databázovém schématu je nahrazena jinou množinou relací, které jsou projekcemi původních relací! Zároveň se zvyšuje počet vztahů.

· Metoda syntézy – rozložení databázového schématu z daných počátečních elementárních závislostí mezi objekty předmětné oblasti.

Klasický návrh databáze je spojen s teorií normalizace , která je založena na analýze funkčních závislostí mezi vztahovými atributy. Funkční závislosti definují stabilní vztahy mezi objekty a jejich vlastnostmi v uvažované oblasti.

Dekompoziční metoda je proces sekvenční normalizace relačních schémat: každá nová iterace odpovídá normální formě vyššího řádu a má lepší vlastnosti ve srovnání s předchozí. Nejprve se tedy předpokládá existence univerzálního vztahu obsahujícího všechny atributy databáze, poté se na základě rozboru souvislostí mezi atributy provede (nebo se pokusí) dekompozice univerzálního vztahu, tzn. přechod do několika vztahů nižší dimenze a původní vztah musí být obnoven pomocí operace přirozeného spojení.

Každá normální forma tedy odpovídá určité množině omezení a relace je v určité normální formě, pokud splňuje její vlastní sadu omezení.

V teorii relačních databází se obvykle rozlišují následující normální formy:

první normální forma (1 NF);

· druhá normální forma (2 NF);

· třetí normální forma (3 NF);

· Bays-Codd normální forma ( BCNF);

· čtvrtá normální forma (4 NF);

· pátá normální forma nebo projekční forma - sloučeniny (5 NF nebo PYNF).

Základní vlastnosti normálních forem:

· každá následující normální forma je v určitém smyslu lepší než ta předchozí;

· při přechodu na další normální formu se zachovají vlastnosti předchozích normálních vlastností.

Databázová schémata se nazývají ekvivalent, pokud lze obsah zdrojové databáze získat přirozeným propojením vztahů obsažených ve výsledném schématu a ve zdrojové databázi se neobjeví žádné nové n-tice.

7. Normální formy vztahů.

Proces normalizace je založen na adekvátní reflexi předmětné oblasti ve formě tabulek obsahujících data o modelovaném objektu a schopnosti měnit stav databáze v čase. Zpravidla se kvůli nesouladu mezi doménovým datovým modelem mohou objevit anomálie, které se objeví při provádění odpovídajících operací:

· Anomálie vkládání (INSERT) – ukládání heterogenních informací v jednom ohledu.

· Aktualizovat anomálie (UPDATE) –Redundance dat o vztazích kvůli heterogennímu ukládání.

· Anomálie mazání (DELETE) – ukládání heterogenních informací v jedné relaci.

Je třeba počítat i se vznikajícími nedefinováno ( NULA) hodnoty. V různých DBMS, při provádění různých operací (porovnávání, slučování, třídění, seskupování atd.) NULA -hodnoty se mohou, ale nemusí navzájem rovnat, mají různé vlivy na výsledek provádění operací k určení průměrných hodnot a zjištění počtu hodnot. Pro odstranění chyb v mnoha DBMS je možné nahradit NULA -hodnoty jsou nulové při provádění výpočtů, deklarují všechny NULA -hodnoty si navzájem rovné atd.

Normalizace – rozdělení tabulky na více, které mají lepší vlastnosti při aktualizaci, vkládání a mazání dat. Tito. normalizace je proces postupného nahrazování tabulky jejími úplnými rozklady, dokud nejsou všechny v 5NF, v praxi však stačí převést tabulky na BCNF;

Postup normalizace 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 , kde je primární klíč a je nějaké jiné pole. Během procesu normalizace byste se proto měli zbavit všech „ostatních“ funkčních závislostí, tzn. od těch, které mají jiný vzhled než .

Pokud během normalizace nahradíme kódy primárních (cizí) klíčů, měli bychom zvážit 2 případy:

1. Tabulka má složený primární klíč např. a pole, které funkčně závisí na části tohoto klíče, např. z (od plný klíč nezávisí). Doporučuje se vytvořit další tabulku obsahující a ( – primární klíč) a odstranit z původní tabulky:

Nahradit, primární klíč, federální zákon

zapnuto , primární klíč

a primární klíč.

2. Tabulka má primární (možný) klíč, pole, které není možným klíčem, ale funkčně závisí na, a další neklíčové pole, které funkčně závisí na:. Doporučuje se vytvořit tabulku obsahující jak ( - primární klíč), tak - odstranit z původní tabulky: Je třeba poznamenat, že k provádění takových operací by člověk měl mít zpočátku nějaké „velké“ (univerzální) vztahy jako vstupní data.

Def.1. Vztah je in první normální forma (1NF) právě tehdy, když žádný z jeho řádků neobsahuje jedinou hodnotu v žádném z jeho polí a žádné z klíčových polí vztahu není prázdné.

Podle definice 1 bude jakýkoli vztah v 1NF, tzn. relace, která splňuje vlastnosti relací: v relaci nejsou identické n-tice; n-tice nejsou objednány; atributy nejsou seřazeny a liší se jménem; všechny hodnoty atributů jsou atomické.

Def.2. Vztah je in druhá normální forma (2NF) tehdy a jen tehdy, když je vztah v 1NF a neexistují žádné neklíčové atributy, které závisí na součásti složitý klíč(tj. všechna pole, která nejsou zahrnuta v primárním klíči, mají plnou funkční závislost na primárním klíči).

Pokud je kandidátský klíč prvočíslo, pak je vztah automaticky v 2NF.

Pro odstranění závislosti atributů na části komplexního klíče je nutné provést rozklad multivztahové vztahy. Atributy, které závisí na části komplexního klíče, jsou umístěny v samostatném vztahu.

Atributy vztahu se nazývají vzájemně nezávislé , pokud ani jeden z nich není funkčně závislý na druhém.

Def.3. Vztah je in třetí normální forma (3NF) tehdy a jen tehdy, když je relace v 2NF a všechny neklíčové atributy jsou vzájemně nezávislé (to znamená, že žádné z neklíčových polí relace nezávisí funkčně na žádném jiném neklíčovém poli).

Chcete-li eliminovat závislost neklíčových atributů, musíte vztah rozložit na několik vztahů. V tomto případě jsou ty neklíčové atributy, které jsou závislé, umístěny do samostatného vztahu.

Při redukci vztahů pomocí normalizačního algoritmu na vztahy v 3NF se předpokládá, že všechny vztahy obsahují jeden kandidátský klíč. To není vždy pravda. Jsou chvíle, kdy vztah může obsahovat více klíčů.

Def.4. Vztah je in Bays-Codd normální forma (NFBK) tehdy a jen tehdy, jsou-li determinanty všech funkčních závislostí potenciálními klíči (nebo je-li jakákoli funkční závislost mezi jeho kamarády redukována na úplnou funkční závislost na možném klíči).

Pokud je vztah v BCNF, pak je automaticky v 3NF, jak vyplývá z Definice 4. K odstranění závislosti na determinantech, které nejsou potenciálními klíči, by měl být proveden rozklad, umístěním těchto determinantů a částí, které na nich závisí, do samostatný vztah.

Jsou chvíle, kdy relace neobsahuje žádné funkční závislosti. Tito. postoj je zcela klíčový, tzn. klíčem vztahu je celý soubor atributů. Máme tedy mnohohodnotovou závislost, protože Mezi atributy stále existuje vztah.

Def.5. Vztah je in čtvrtá normální forma (4NF) tehdy a jen tehdy, pokud je relace v BCNF a neobsahuje netriviální vícehodnotové závislosti.

Vztahy s netriviálními vícehodnotovými závislostmi vznikají zpravidla v důsledku přirozeného propojení dvou vztahů nad společným polem, které není v žádném ze vztahů klíčové. Ve skutečnosti to vede k ukládání informací o dvou nezávislých entitách v jednom vztahu.

Chcete-li odstranit netriviální vícehodnotové závislosti, můžete původní vztah rozložit na několik nových.

Def.6. Vztah je in pátá normální forma (5NF) tehdy a jen tehdy, je-li jakákoli přítomná závislost na připojení triviální.

Def.6. shodně také následuje definice.

Def.7. Relace není v 5NF, pokud má relace netriviální závislost spojení.

Že. Pokud v každém úplném rozkladu všechny projekce původní relace obsahují možný klíč, můžeme usoudit, že relace je v 5NF. Relace, která nemá úplný rozklad, je také v 5NF.

Bez znalosti toho, jaké jsou potenciální klíče ve vztahu a jak spolu atributy spolu souvisí, to nelze říci tento postoj je v 5NF nebo jiných normálních formách.

Možný klíč Relace je soubor atributů vztahu, které zcela a jednoznačně (funkčně zcela) určují hodnoty všech ostatních atributů vztahu. Obecně může mít vztah více možných klíčů. Ze všech možných klíčů vztahu je obvykle vybrán jeden, který je považován za hlavní a který se nazývá primární klíč vztahu.

Vzájemně nezávislé atributy – To jsou atributy, které na sobě nezávisí. Pokud ve vztahu existuje několik fyzikálních zákonů, pak každý atribut nebo soubor atributů, na kterých závisí jiný atribut, se nazývá determinant vztahu.

9. Relační algebra.

Relační algebra poskytuje rámec pro přístup k relačním datům. Hlavním účelem algebry je poskytovat výrazy, které lze zapsat. Výrazy lze použít pro:

· definice oblastí Vzorky, tj. definování dat pro výběr jako výsledek operace vzorkování;

· definice oblastí aktualizace, tj. definování dat, která mají být vložena, změněna nebo vymazána v důsledku operace aktualizace;

· definice (pojmenovaný) virtuální vztahy , tj. prezentace dat pro vizualizaci prostřednictvím pohledů;

· definice snímku, tzn. definování dat, která mají být uložena jako „snímek“ vztahu;

· definování bezpečnostních pravidel, tzn. určení údajů, pro které se provádí kontrola přístupu;

· stanovení požadavků udržitelnosti, tzn. určení údajů, které jsou zahrnuty do rozsahu určitých operací kontroly souběžnosti;

· definování pravidel integrity, tzn. nějaký zvláštní pravidla které musí databáze splňovat, spolu s obecnými pravidly, která jsou součástí relační model a aplikuje se na každou databázi.

Implementace konkrétních relačních DBMS se v současnosti nepoužívají čistá forma ani relační algebra ani relační kalkul. De facto standardem pro přístup k relačním datům se stal jazyk SQL(Strukturovaný dotazovací jazyk).

Relační algebra, definovaná Coddem, se skládá z 8 operátorů zahrnujících 2 skupiny:

tradiční množinové operace (sjednocení, průnik, odčítání, kartézský součin);
speciální relační operace (výběr, projekce, spojení, rozdělení).

Algebra dále obsahuje operaci přiřazení, která umožňuje uložit výsledky výpočtu algebraických výrazů do databáze, a operaci přejmenování atributů, která umožňuje správně sestavit hlavičku (schéma) výsledného vztahu.

Stručný přehled operátorů relační algebry.

Vzorek– vrací relaci, která obsahuje všechny n-tice určitého vztahu, které splňují nějaké podmínky. Operace vzorkování se také nazývá omezující operace ( omezit - omezení, nyní je odběr vzorků přijímán častěji - VYBRAT).

Projekce– vrací relaci obsahující všechny n-tice (tj. - pod-tice) konkrétního vztahu po vyloučení některých atributů z něj.

Práce– vrací relaci obsahující všechny možné n-tice, které jsou kombinací dvou n-tic patřících do dvou určité vztahy.

Sdružení– vrací relaci obsahující všechny n-tice, které patří k jedné nebo oběma ze dvou zadaných relací.

Křižovatka –vrací relaci obsahující všechny n-tice, které patří současně do dvou definovaných relací.

Odečítání –vrací relaci obsahující všechny n-tice, které patří do první ze dvou definovaných relací a ne do druhé.

Připojení (přirozené) – vrátí relaci, jejíž n-tice jsou kombinací dvou n-tic (patřících do dvou definovaných relací), které mají společný význam pro jednu nebo více společné atributy těchto dvou vztahů (a takové společné hodnoty se ve výsledné n-tice objeví pouze jednou, nikoli dvakrát).

divize –pro dvě relace, binární a unární, vrací relaci obsahující všechny hodnoty jednoho atributu binární relace, které odpovídají (v druhém atributu) všem hodnotám v unární relaci.

LITERATURA

1. Datum K.J. Úvod do databázových systémů, 6. vydání: Trans. z angličtiny - TO.; M.; Petrohrad: Williams Publishing House, 2000. – 848 s.

2. Connolly T., Begg K., Strachan A. Databáze: návrh, implementace a údržba. Teorie a praxe, 2. vyd.: Přel. z angličtiny – M.: Williams Publishing House, 2000. – 1120 s.

3. Karpová T.S. Databáze: modely, vývoj, implementace. – Petrohrad: Petr, 2001. – 304 s.

4. Faronov V.V., Shumakov P.V. Delphi 4. Příručka pro vývojáře databáze. – M.: „Znalosti“, 1999. – 560 s.

5. J. Groff, P. Weinberg. SQL: Kompletní průvodce: Per. z angličtiny – K.: BHV Publishing Group, 2001. – 816 s.

6. Ken Goetz, Paul Litwin, Mike Gilbert. Access 2000. Příručka pro vývojáře. T.1, 2. Per. z angličtiny – K.: BHV Publishing Group, 2000. – 1264 s., 912 s.

7. Maklakov S.V BPwin a EPwin. CASE-nástroje pro vývoj informačních systémů. – M.: DIALOG-MEPhI, 2001. – 304 s.

8. Ullman D., Widom D. Úvod do databázových systémů / Přel. z angličtiny – M.: “Lori”, 2000. – 374 s.

9. Khomonenko A.D., Tsygankov V.M., Maltsev M.G. Databáze: Učebnice pro vysoké školy vzdělávací instituce/ Ed. Prof. A.D. Chomoněnko. – Petrohrad: CORONA print, 2000. – 416 s.

Anotace: Tato přednáška zahajuje sérii čtyř přednášek o návrhu relačních databází. V této přednášce budeme hovořit o normalizaci vztahových diagramů, přičemž bereme v úvahu pouze funkční závislosti mezi vztahovými atributy. Tyto „první kroky“ normalizace vytvářejí návrh databáze, ve kterém jsou všechny proměnné vztahu v Boyce-Coddově normální formě, která je obecně považována za vyhovující pro většinu aplikací.

Úvod

Při návrhu databáze se řeší dva hlavní problémy.

Jak namapovat doménové objekty na abstraktní objekty datového modelu tak, aby toto mapování neodporovalo sémantice domény a bylo pokud možno co nejlepší (efektivní, pohodlné atd.)? Tento problém se často nazývá problém logický design databází.
Jak zajistit efektivitu provádění dotazů do databáze, tedy jak s přihlédnutím k vlastnostem konkrétní DBMS uspořádat data v externí paměti, jaké další struktury (například indexy) vytvořit atd.? Tento problém se obvykle nazývá problém fyzický design databází.

V případě relačních databází je obtížné nabídnout nějaké obecné recepty na fyzický návrh. Zde příliš záleží na použitém DBMS. Proto se omezíme na otázky logické návrh relační databáze, které jsou nezbytné při použití jakéhokoli relačního DBMS.

Navíc se moc nedotkneme důležitý aspekt design - definování integritních omezení obecný pohled(s výjimkou omezení stanovených funkčními a vícehodnotové závislosti, stejně jako závislosti projekce/spojení). Faktem je, že při použití DBMS s vyvinutými mechanismy omezení integrity (například systémy orientované na SQL) je obtížné nabídnout univerzální přístup k definici integritních omezení. Tato omezení mohou být libovolná složitý tvar a jejich formulace se zatím týká spíše oblasti umění než inženýrských dovedností. V literatuře se v tomto ohledu navrhuje nejvíce automatická kontrola konzistence sady omezení integrity.

V této a následující přednášce tedy budeme předpokládat, že problémem návrhu relační databáze je informovaná rozhodnutí o tom, z jakých vztahů by se databáze měla skládat a jaké atributy by tyto vztahy měly mít.

V této a dalších přednáškách se budeme zabývat klasickým přístupem, kdy celý proces návrhu databáze probíhá z hlediska relačního datového modelu pomocí metody postupné aproximace k uspokojivému souboru vztahových vzorců. Výchozím bodem je reprezentace předmětová oblast ve formě jedné nebo více vztahů a v každém kroku návrhu je vytvořena určitá sada schémat vztahů, která mají „vylepšené“ vlastnosti. Proces návrhu je normalizační proces vztahová schémata, s každým dalším normální forma má vlastnosti v jistém smyslu lepší než předchozí.

Každá normální forma je spojena s určitou sadou omezení a vztah je v určité normální formě, pokud splňuje její vlastní sadu omezení. Příkladem může být omezení první normální forma– hodnoty všech atributů vztahu jsou atomická 1 Připomeňte si z přednášky 2, že atomicita hodnota je interpretována v tom smyslu, že hodnota je zadaná a tato hodnota může být manipulována pouze pomocí operací odpovídajícího datového typu.. Od požadavku první normální forma je základním požadavkem klasického relačního datového modelu, budeme předpokládat, že výchozí soubor relací již tento požadavek splňuje.

V teorie relačních databází Obvykle se rozlišuje následující sekvence normálních forem: