AKÁ JE TRETIA NORMÁLNA FORMA? (DATABÁZ) - TECHNOLÓGIE - 2025

Tretia normálne forma (databázy) je relačnej databázy navrhnú postup, kedy sa rôzne tabuľky, ktoré tvoria nielen v súlade s druhým normálnej forme, ale všetky jeho atribúty alebo polia sú priamo závislé na primárnom kľúči.

Pri navrhovaní databázy je hlavným cieľom vytvorenie presnej reprezentácie údajov, vzťahov medzi nimi a obmedzení relevantných údajov.

Zdroj: pixabay.com

Na dosiahnutie tohto cieľa sa môžu použiť niektoré techniky návrhu databázy, medzi ktoré patrí aj normalizácia.

Je to proces organizácie údajov v databáze, aby sa zabránilo nadbytočnosti a možným anomáliám pri vkladaní, aktualizácii alebo eliminácii údajov, čím sa vytvorí jednoduchý a stabilný návrh koncepčného modelu.

Začína sa preskúmaním funkčného vzťahu alebo závislosti medzi atribútmi. Opisujú niektoré vlastnosti údajov alebo vzťahy medzi nimi.

Normálne tvary

Normalizácia používa sériu testov, ktoré sa nazývajú normálne formy, aby pomohla určiť optimálne zoskupenie týchto atribútov a nakoniec vytvoriť vhodný súbor vzťahov, ktoré podporujú požiadavky na údaje spoločnosti.

To znamená, že normalizačná technika je postavená na koncepte normálnej formy, ktorá definuje systém obmedzení. Ak vzťah spĺňa obmedzenia konkrétnej normálnej formy, hovorí sa, že vzťah je v tejto normálnej forme.

Prvá normálna forma (1FN)

Tabuľka je označená ako 1FN, ak všetky atribúty alebo polia v nej obsahujú iba jedinečné hodnoty. To znamená, že každá hodnota každého atribútu musí byť neoddeliteľná.

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

Jednoduché opustenie databázy, ako je táto, však podnecuje celý rad problémov, ako napríklad nadbytočnosť a možné zlyhania aktualizácie. Na nápravu týchto problémov boli vyvinuté vyššie normálne formy.

Druhá normálna forma (2FN)

Zaoberá sa odstránením kruhových závislostí z tabuľky. O vzťahu sa hovorí, že je v 2FN, ak je v 1FN a okrem toho každé nekľúčové pole alebo atribút úplne závisí od primárneho kľúča, alebo presnejšie, zaisťuje, že tabuľka má jediný účel.

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

Tretia normálna forma (3FN)

Zaoberá sa elimináciou prechodných závislostí z tabuľky. To znamená, že odstránite nekľúčové atribúty, ktoré nezávisia od primárneho kľúča, ale od iného atribútu.

Tranzitívna závislosť je typ funkčnej závislosti, pri ktorej je hodnota nekľúčového poľa alebo atribútu určená hodnotou iného poľa, ktoré tiež nie je kľúčové.

Mali by ste hľadať opakujúce sa hodnoty v atribútoch, ktoré nie sú kľúčmi, aby ste sa uistili, že tieto nekľúčové atribúty nezávisia od iného zdroja ako primárneho kľúča.

Atribúty sa považujú za vzájomne nezávislé, ak žiadny z nich nie je funkčne závislý od kombinácie iných. Táto vzájomná nezávislosť zabezpečuje, že atribúty sa môžu aktualizovať jednotlivo, bez nebezpečenstva ovplyvnenia iného atribútu.

Preto, aby vzťah v databáze bol v tretej normálnej forme, musí spĺňať:

- Všetky požiadavky 2FN.

- Ak existujú atribúty, ktoré sa netýkajú primárneho kľúča, musia sa odstrániť a umiestniť do samostatnej tabuľky, ktorá sa týka oboch tabuliek pomocou cudzieho kľúča. To znamená, že by nemali existovať žiadne prechodné závislosti.

Príklady tretej normálnej formy

Príklad 1

Nech tabuľka je STUDENT, ktorej primárnym kľúčom je identifikácia študenta (STUDENT_ID) a skladá sa z nasledujúcich atribútov: STUDENT_NAME, STREET, CITY a POST_CODE, ktoré spĺňajú podmienky 2FN.

V tomto prípade STREET a CITY nemajú priamy vzťah s primárnym kľúčom STUDENT_ID, pretože nesúvisia priamo so študentom, ale úplne závisia od poštového smerovacieho čísla.

Keďže sa študent nachádza na webe určenom doménou CODE_POSTAL, súvisí s týmto atribútom STREET a CITY. Vzhľadom na tento druhý stupeň závislosti nie je potrebné tieto atribúty ukladať do tabuľky ŠTUDENT.

Vytvorte novú tabuľku

Predpokladajme, že v tom istom PSČ je viac študentov, pričom tabuľka STUDENT má obrovské množstvo záznamov a je potrebné zmeniť názov ulice alebo mesta, potom je potrebné túto ulicu alebo mesto nájsť a aktualizovať v celej tabuľke. STUDENT.

Napríklad, ak potrebujete zmeniť ulicu „El Limón“ na „El Limón II“, budete musieť vyhľadať „El Limón“ v celej tabuľke STUDENT a potom ju aktualizovať na „El Limón II“.

Vyhľadávanie v obrovskej tabuľke a aktualizácia jednotlivých alebo viacerých záznamov bude trvať dlho, a preto ovplyvní výkon databázy.

Namiesto toho sa tieto údaje môžu uchovávať v samostatnej tabuľke (POSTCARD), ktorá súvisí s tabuľkou STUDENT pomocou atribútu POST_CODE.

Tabuľka POST bude mať porovnateľne menej záznamov a táto tabuľka POST bude potrebné aktualizovať iba raz. To sa automaticky prejaví v tabuľke ŠTUDENT, čo zjednoduší databázu a dotazy. Tabuľky teda budú v 3FN:

Príklad 2

Nechajte nasledujúcu tabuľku použiť s poľom Project_Num ako primárny kľúč as opakovanými hodnotami v atribútoch, ktoré nie sú kľúčmi.

Telefónna hodnota sa opakuje vždy, keď sa opakuje meno manažéra. Dôvodom je, že telefónne číslo závisí iba od druhého čísla projektu. Naozaj záleží najprv na manažérovi, a to zase na základe čísla projektu, čo spôsobuje prechodnú závislosť.

Atribút Project_Manager nemôže byť možným kľúčom v tabuľke Projekty, pretože ten istý manažér riadi viac ako jeden projekt. Riešením je odstránenie atribútu s opakovanými údajmi (Telefón) a vytvorenie samostatnej tabuľky.

Zodpovedajúce atribúty musia byť zoskupené dohromady, čím sa vytvorí nová tabuľka, ktorá ich uloží. Údaje sa zadávajú a overuje sa, či opakované hodnoty nie sú súčasťou primárneho kľúča. Primárny kľúč sa nastavuje pre každú tabuľku a podľa potreby sa pridávajú cudzie kľúče.

Aby sa dosiahol súlad s treťou normálnou formou, vytvorí sa nová tabuľka (Manažéri) na vyriešenie problému. Obe tabuľky sú prepojené cez pole Project_Manager:

Referencie

1. Teradata (2019). Prvá, druhá a tretia normálna forma. Prevzaté z: docs.teradata.com.
2. Tutorial Cup (2019). Tretia normálna forma (3NF). Prevzaté z: tutorialcup.com.
3. Databáza Dev (2015). Tretia normálna forma (3NF) - normalizácia databázy. Prevzaté z: databasedev.co.uk.
4. Návrh relačnej DB (2019). Úvod do tretieho normálneho formulára. Prevzaté z: relationshipaldbdesign.com.
5. Dummies (2019). Prvý, druhý a tretí normálny formulár SQL. Prevzaté z: dummies.com.