Jaka jest trzecia normalna forma? (Bazy danych)

Trzecia normalna forma (bazy danych) Jest to relacyjna technika projektowania bazy danych, w której różne tabele, które komponują ją nie tylko, spełniają drugą normalną formę, ale wszystkie ich atrybuty lub pola zależą bezpośrednio od klucza głównego.

Po zaprojektowaniu bazy danych głównym celem jest stworzenie precyzyjnej reprezentacji danych, relacji między nimi a ograniczeniami dotyczącymi istotnych danych.

Źródło: Pixabay.com

Aby osiągnąć ten cel, można zastosować niektóre techniki projektowania bazy danych, wśród których standaryzacja.

Jest to proces organizowania danych w bazie danych w celu uniknięcia nadmiarów i możliwych anomalii w wprowadzaniu, aktualizacji lub usuwaniu danych, generując to prosty i stabilny projekt modelu pojęciowego.

Zaczyna się od zbadania relacji funkcjonalnej lub zależności między atrybutami. Opisują one pewną właściwość danych lub związek między nimi.

[TOC]

Normalne formy

Standaryzacja wykorzystuje serię testów, zwanych normalnymi formami, aby zidentyfikować optymalne grupowanie tych atrybutów i ostatecznie ustalić zestaw odpowiednich relacji, które wspierają wymagania danych firmy

Oznacza to, że technika normalizacji jest skonstruowana wokół koncepcji normalnego sposobu, która określa system ograniczeń. Jeśli związek spełnia ograniczenia w określony normalny sposób, mówi się, że związek jest w ten normalny sposób.

Pierwsza forma normalna (1FN)

Mówi się, że tabela jest w 1fn, jeśli wszystkie atrybuty lub pola w niej zawierają tylko unikalne wartości. To znaczy, cała wartość dla każdego atrybutu musi być niepodzielna.

Z definicji relacyjna baza danych będzie zawsze znormalizowana do pierwszej formy normalnej, ponieważ wartości atrybuty są zawsze atomowe. Wszystkie relacje w bazie danych są w 1fn.

Może ci służyć: stałe (programowanie): koncepcja, typy, przykłady

Jednak opuszczenie bazy danych po prostu stymuluje szereg problemów, takich jak nadmiarowość i możliwe anomalie aktualizacji. Najwyższe normalne formy zostały opracowane w celu rozwiązania tych problemów.

Druga forma normalna (2FN)

Zajmuje się wyeliminowaniem ze stołu okrągłe jednostki. Mówi się, że stosunek jest w 2FN, jeśli jest w 1FN, a także każde pole lub atrybut nie zależy całkowicie od klucza podstawowego, a dokładniej, zapewnia, że ​​tabela ma jeden cel.

Atrybutem, który nie jest kluczem.

Trzecia forma normalna (3FN)

Dotyczy eliminowania zależności przechodniej z tabeli. To znaczy eliminuj atrybuty nie -klawisze, które nie zależą od klucza podstawowego, ale od innego atrybutu.

Zależność przechodnia jest rodzajem funkcjonalnej zależności, w której wartość atrybutu lub pola nie jest określana przez wartość innego pola, które nie jest również kluczowe.

Powtarzane wartości należy szukać w atrybutach innych niż klawisz, aby upewnić się, że te atrybuty, które nie są kluczowe, nie zależą wyłącznie od klucza podstawowego.

Mówi się, że atrybuty są wzajemnie niezależne, jeśli żadne z nich nie zależą funkcjonalnie od kombinacji innych. Ta wzajemna niezależność gwarantuje, że atrybuty mogą być aktualizowane indywidualnie, bez niebezpieczeństwa wpływu na inny atrybut.

Dlatego, aby współczynnik bazy danych był w trzeciej normalnej formie, musi być zgodny z:

- Wszystkie wymagania 2FN.

Może ci służyć: ICT w domu

- Jeśli istnieją atrybuty, które nie są powiązane z kluczem podstawowym, muszą zostać wyeliminowane i umieszczone w osobnej tabeli, powiązane obie tabele za pomocą klucza zewnętrznego. Oznacza to, że nie powinno być zależności przechodniej.

Przykłady trzeciej normalnej formy

Przykład 1

Bądź tabelą studencką, której kluczowym kluczem jest identyfikacja ucznia (id_estudiant) i składa się z następujących atrybutów: nazwa studenta, ulica, miasto i kodeks postowy, spełniając warunki na 2fn.

W tym przypadku Street i City nie mają bezpośredniego związku z głównym kluczem tożsamości, ponieważ nie są one bezpośrednio powiązane z uczniem, ale zależą całkowicie od kodu pocztowego.

Ponieważ uczeń znajduje się według strony określonej przez Code_Postal, Street i City są powiązane z tym atrybutem. Z powodu tego drugiego stopnia zależności nie jest konieczne przechowywanie tych atrybutów w tabeli studenckiej.

Utwórz nową tabelę

Załóżmy, że w tym samym kodeksie pocztowym znajduje się wielu studentów, przy czym tabela studencka ma ogromną liczbę zapisów, i konieczne jest zmiana nazwy ulicy lub miasta, wówczas ta ulica lub miasto powinno być przeszukiwane i aktualizowane w całym Student tabeli.

Na przykład, jeśli konieczne jest zmiana ulicy „El Limón” dla „El Limón II”, będzie musiała szukać „el Limón” w stole studenckim, a następnie zaktualizować ją do „El Limón II”.

Znajdź w ogromnej tabeli i aktualizacja Unikalna lub wiele rekordów będzie wymagała dużo czasu, a zatem wpłynie na wydajność bazy danych.

Zamiast tego szczegóły te można mieć w osobnej tabeli (pocztówka) powiązanej z tabelą ucznia przy użyciu atrybutu Code_Postal.

Tabela pocztowa będzie miała stosunkowo mniejszą liczbę rekordów i będzie musiał zaktualizować tylko po tej tabeli pocztowej. Zostanie to automatycznie odzwierciedlone w tabeli studenckiej, upraszczając bazy danych i konsultacje. Zatem tabele będą w 3fn:

Może ci służyć: metaborem: cechy, typy i przykłady

Przykład 2

Być następującą tabelą z polem NUM_Project jako głównym kluczem i z powtarzanymi wartościami w atrybutach, które nie są kluczem.

Wartość telefonu jest powtarzana za każdym razem, gdy nazwa menedżera jest powtarzana. Wynika to z faktu, że numer telefonu ma tylko drugą zależność od numeru projektu. To naprawdę zależy od menedżera, a to z kolei zależy od numeru projektu, co stanowi zależność przechodnie.

Atrybut Manager_Project nie może być możliwym kluczem w projektach tabeli, ponieważ ten sam menedżer obsługuje więcej niż jeden projekt. Rozwiązaniem jest wyeliminowanie atrybutu z powtarzanymi danymi (telefonem), tworzenie oddzielnej tabeli.

Odpowiednie atrybuty muszą być pogrupowane, tworząc nową tabelę, aby je zapisać. Dane są wprowadzane i weryfikuje się, że powtarzane wartości nie są częścią klucza podstawowego. Klucz podstawowy dla każdej tabeli jest ustalany i, jeśli to konieczne, dodaje się klawisze zewnętrzne.

Aby spełnić trzecią normalną formę, powstaje nowa tabela (menedżerowie), aby rozwiązać problem. Obie tabele są powiązane za pośrednictwem pola menedżera_projektowego:

Bibliografia

1. Teradata (2019). Pierwsze, drugie i trzecie normalne formy. Zaczerpnięte z: Docs.Teradata.com.
2. Samouczek Pucharu (2019). Normalna trzecia forma (3NF). Zaczerpnięte z: samouczka.com.
3. Baza danych Dev (2015). Normalna trzecia forma (3NF) - Normalizowanie bazy danych. Zaczerpnięte z: Databedev.współ.Wielka Brytania.
4. Relational DB Design (2019). Wprowadzenie do trzeciej normalnej formy. Zaczerpnięte z: relacyjnaDBDesign.com.
5. Dummy (2019). SQL First, drugie i trzecie normalne formy. Zaczerpnięte z: manekinów.com.