Aká je tretia normálna forma? (Databázy)

Ten Tretí normálny formulár (databázy) Je to technika navrhovania relačnej databázy, kde rôzne tabuľky, ktoré ju tvoria nielenže spĺňajú druhý normálny formulár, ale všetky ich atribúty alebo polia závisia priamo od hlavného kľúča.

Ak je navrhnutá databáza, hlavným cieľom je vytvoriť presnú reprezentáciu údajov, vzťahov medzi nimi a obmedzeniami, ktoré sú relevantné.

Zdroj: Pixabay.com

Na dosiahnutie tohto cieľa je možné použiť niektoré techniky navrhovania databáz, medzi ktorými je štandardizácia.

Toto je proces organizácie údajov v databáze, aby sa predišlo prepúšťaniu a možným anomáliám pri vkladaní, aktualizácii alebo likvidácii údajov, pričom generuje jednoduchý a stabilný návrh koncepčného modelu.

Začína skúmaním funkčného vzťahu alebo závislosti medzi atribútmi. Tieto opisujú určitú vlastnosť údajov alebo vzťah medzi nimi.

[TOC]

Normálne formy

Štandardizácia používa sériu testov, nazývaných normálne formy, na identifikáciu optimálneho zoskupenia týchto atribútov a nakoniec stanovenie súboru primeraných vzťahov, ktoré podporujú požiadavky na údaje spoločnosti

To znamená, že technika normalizácie je skonštruovaná okolo konceptu normálneho spôsobu, ktorý definuje systém obmedzení. Ak vzťah spĺňa obmedzenia osobitným normálnym spôsobom, hovorí sa, že vzťah je týmto normálnym spôsobom.

Prvá normálna forma (1FN)

Hovorí sa, že tabuľka je v 1FN, ak všetky atribúty alebo polia v ňom obsahujú iba jedinečné hodnoty. To znamená, že všetka hodnota pre každý atribút musí byť nedeliteľná.

Podľa definície bude relačná databáza vždy normalizovaná na prvú normálnu formu, pretože hodnoty atribútov sú vždy atómové. Všetky vzťahy v databáze sú v 1FN.

Môže vám slúžiť: konštantné (programovanie): koncept, typy, príklady

Opustenie databázy však jednoducho stimuluje sériu problémov, ako je redundancia a možné aktualizácie anomálií. Na korekciu týchto problémov boli vyvinuté najvyššie normálne formy.

Druhá normálna forma (2FN)

Zaoberá sa odstránením z tabuľky kruhové jednotky. Hovorí sa, že pomer je v 2FN, ak je v 1FN a tiež každé pole alebo atribút nezávisí úplne od primárneho kľúč.

Atribút, nie kľúč, je žiadny atribút, ktorý nie je súčasťou primárneho kľúča pre vzťah.

Tretia normálna forma (3fn)

Vydáva sa eliminovaním tranzitívnych závislostí zo tabuľky. To znamená, že eliminujte atribúty nekbela, ktoré nezávisia od primárneho kľúča, ale od iného atribútu.

Transitívna závislosť je typ funkčnej závislosti, v ktorej sa hodnota atribútu alebo poľa nestanoví hodnotou iného poľa, ktoré nie je ani kľúčom.

Opakované hodnoty by sa mali hľadať v atribútoch, ktoré nie sú kľúčom, aby sa zabezpečilo, že tieto atribúty, ktoré nie sú kľúčom, nezávisia iba od primárneho kľúča.

Hovorí sa, že atribúty sú vzájomne nezávislé, ak žiadny z nich funkčne závisí od kombinácie ostatných. Táto vzájomná nezávislosť zaručuje, že atribúty sa dajú aktualizovať individuálne, bez nebezpečenstva ovplyvnenia iného atribútu.

Preto, aby bol pomer databázy v tretej normálnej forme, musí dodržiavať:

- Všetky požiadavky 2FN.

Môže vám slúžiť: IKT v dome

- Ak existujú atribúty, ktoré nesúvisia s primárnym kľúčom, musia sa eliminovať a umiestniť do samostatnej tabuľky, pričom obidve tabuľky sa vzťahujú na obidve tabuľky cez externý kľúč. To znamená, že by nemala existovať žiadna tranzitívna závislosť.

Príklady tretej normálnej formy

Príklad 1

Buďte študentskou tabuľkou, ktorej primárnym kľúčom je identifikácia študenta (id_estudiant) a je zložená z týchto atribútov: meno študentov, ulica, mesto a_postal, splnenie podmienok, ktoré majú byť 2FN.

V tomto prípade ulica a mesto nemajú priamy vzťah s kľúčom primárnej identity, pretože nesúvisia priamo so študentom, ale úplne závisia od PSČ.

Keďže študent sa nachádza na stránkach určenom Code_postal, Street a City, súvisia s týmto atribútom. Vzhľadom na tento druhý stupeň závislosti nie je potrebné ukladať tieto atribúty do tabuľky študentov.

Vytvorte novú tabuľku

Predpokladajme, že v rovnakom poštovom kóde sa nachádza viac študentov, pričom študentská tabuľka má obrovské množstvo záznamov a je potrebné zmeniť názov ulice alebo mesta, potom by sa táto ulica alebo mesto malo prehľadávať a aktualizovať počas celého študent.

Napríklad, ak je potrebné zmeniť ulicu „El Limón“ pre „El Limón II“, bude musieť hľadať „El Limón“ v celom stole študentov a potom ju aktualizovať na „El Limón II“.

Nájdite v obrovskej tabuľke a aktualizovať jedinečné alebo viac záznamov, ktoré si budú vyžadovať veľa času, a preto ovplyvní výkon databázy.

Namiesto toho sa tieto podrobnosti môžu zaoberať v samostatnej (pohľadšej karte) tabuľke, ktorá súvisí s tabuľkou študentov pomocou atribútu Code_postal.

Poštová tabuľka bude mať pomerne menšie množstvo záznamov a bude musieť aktualizovať iba po tejto poštovej tabuľke. To sa automaticky odrazí v tabuľke študentov, čo zjednoduší databázy a konzultácie. Tabuľky teda budú v 3FN:

Môže vám slúžiť: Metabustery: Charakteristiky, typy a príklady

Príklad 2

Byť nasledujúcou tabuľkou s poľom Num_project ako hlavným kľúčom a s opakovanými hodnotami v atribútoch, ktoré nie sú kľúčové.

Telefónna hodnota sa opakuje zakaždým, keď sa opakuje názov manažéra. Dôvodom je, že telefónne číslo má iba druhú závislosť od 7. s číslom projektu. Skutočne to záleží na manažérovi, a to zase závisí od čísla projektu, ktoré vytvára prechodnú závislosť.

Atribút Manager_project nemôže byť možným kľúčom v projektoch tabuľky, pretože ten istý manažér spracováva viac ako jeden projekt. Riešením je eliminovať atribút opakovanými údajmi (telefón) a vytvorenie samostatnej tabuľky.

Zodpovedajúce atribúty musia byť zoskupené, čím sa vytvorí nový tabuľka na ich uloženie. Dáta sa zadávajú a overuje sa, že opakované hodnoty nie sú súčasťou primárneho kľúča. Primárny kľúč pre každú tabuľku je stanovený av prípade potreby sa pridajú externé kľúče.

Na splnenie tretej normálnej formy sa vytvorí nová tabuľka (manažéri) na vyriešenie problému. Obe tabuľky sú spojené prostredníctvom poľa Manager_Project:

Odkazy

1. Teradata (2019). Po prvé, druhé a tretie normálne formy. Prevzaté z: Dokumenty.Teradata.com.
2. Výukový program Cup (2019). Normálna tretia forma (3NF). Zobraté z: TutorialCup.com.
3. Databáza Dev (2015). Normálny tretí formulár (3NF) - normalizácia databázy. Zobraté z: Databasedev.co.Uk.
4. Relačný dizajn DB (2019). Úvod do tretej normálnej formy. Prevzaté z: relationalDBDesign.com.
5. Dummies (2019). SQL prvé, druhé a tretie normálne formy. Prevzaté z: figuríny.com.