Normalizacja jest procesem minimalizacji nadmierność z relacji lub zestawu relacji. Nadmiarowość w relacji może powodować anomalie wstawiania, usuwania i aktualizacji. Pomaga więc zminimalizować nadmiarowość w relacjach. Normalne formy służą do eliminacji lub ograniczenia redundancji w tabelach bazy danych.

Normalizacja DBMS przez Ranjana Hero

W systemach zarządzania bazami danych (DBMS) normalne formularze to szereg wytycznych, które pomagają zapewnić, że projekt bazy danych jest wydajny, zorganizowany i wolny od anomalii danych. Istnieje kilka poziomów normalizacji, każdy z własnym zestawem wytycznych, zwanych formami normalnymi.

Ważne punkty dotyczące form normalnych w systemie DBMS

• Pierwsza postać normalna (1NF): Jest to najbardziej podstawowy poziom normalizacji. W 1NF każda komórka tabeli powinna zawierać tylko jedną wartość, a każda kolumna powinna mieć unikalną nazwę. Pierwsza postać normalna pomaga wyeliminować duplikaty danych i uprościć zapytania.
• Druga postać normalna (2NF): 2NF eliminuje zbędne dane, wymagając, aby każdy atrybut niekluczowy był zależny od klucza podstawowego. Oznacza to, że każda kolumna powinna być bezpośrednio powiązana z kluczem podstawowym, a nie z innymi kolumnami.
• Trzecia postać normalna (3NF): 3NF opiera się na 2NF, wymagając, aby wszystkie niekluczowe atrybuty były od siebie niezależne. Oznacza to, że każda kolumna powinna być bezpośrednio powiązana z kluczem podstawowym, a nie z jakąkolwiek inną kolumną w tej samej tabeli.
• Postać normalna Boyce'a-Codda (BCNF): BCNF jest bardziej rygorystyczną formą 3NF, która zapewnia, że ​​każdy wyznacznik w tabeli jest kluczem kandydującym. Innymi słowy, BCNF zapewnia, że ​​każdy atrybut niekluczowy jest zależny tylko od klucza kandydującego.
• Czwarta postać normalna (4NF): 4NF to dalsze udoskonalenie BCNF, które zapewnia, że ​​tabela nie zawiera żadnych zależności wielowartościowych.
• Piąta postać normalna (5NF): 5NF to najwyższy poziom normalizacji i polega na rozłożeniu tabeli na mniejsze tabele w celu usunięcia nadmiarowości danych i poprawy integralności danych.

Zwykłe formularze pomagają zmniejszyć nadmiarowość danych, zwiększyć spójność danych i poprawić wydajność bazy danych. Jednak wyższy poziom normalizacji może prowadzić do bardziej złożonych projektów baz danych i zapytań. Podczas projektowania bazy danych ważne jest zachowanie równowagi pomiędzy normalizacją a praktycznością.

przekreślenie przeceny

Zalety postaci normalnej

• Zmniejszona redundancja danych: Normalizacja pomaga wyeliminować duplikaty danych w tabelach, zmniejszając ilość potrzebnej przestrzeni dyskowej i poprawiając wydajność bazy danych.
• Poprawiona spójność danych: Normalizacja zapewnia przechowywanie danych w spójny i zorganizowany sposób, zmniejszając ryzyko niespójności i błędów w danych.
• Uproszczony projekt bazy danych: Normalizacja zapewnia wytyczne dotyczące organizowania tabel i relacji między danymi, ułatwiając projektowanie i utrzymywanie bazy danych.
• Poprawiona wydajność zapytań: Znormalizowane tabele są zazwyczaj łatwiejsze do wyszukiwania i pobierania danych, co skutkuje większą wydajnością zapytań.
• Łatwiejsze utrzymanie bazy danych: Normalizacja zmniejsza złożoność bazy danych, dzieląc ją na mniejsze, łatwiejsze w zarządzaniu tabele, co ułatwia dodawanie, modyfikowanie i usuwanie danych.

Ogólnie rzecz biorąc, używanie normalnych formularzy w systemie DBMS pomaga poprawić jakość danych, zwiększyć wydajność bazy danych oraz uprościć projektowanie i konserwację baz danych.

Pierwsza postać normalna

Jeśli relacja zawiera atrybut złożony lub wielowartościowy, to narusza pierwszą postać normalną lub relacja jest w pierwszej postaci normalnej, jeśli nie zawiera żadnego atrybutu złożonego lub wielowartościowego. Relacja jest w pierwszej postaci normalnej, jeśli każdy atrybut w tej relacji jest w pierwszej postaci normalnej atrybut o pojedynczej wartości .

• Przykład 1 - Relacja STUDENT w tabeli 1 nie znajduje się w 1NF ze względu na wielowartościowy atrybut STUD_PHONE. Jego rozkład na 1NF przedstawiono w tabeli 2.

Przykład

• Przykład 2 –

ID Name Courses ------------------ 1 A c1, c2 2 E c3 3 M C2, c3>

• W powyższej tabeli Kurs jest atrybutem wielowartościowym, więc nie występuje w 1NF. Poniższa tabela jest w 1NF, ponieważ nie ma atrybutu wielowartościowego

ID Name Course ------------------ 1 A c1 1 A c2 2 E c3 3 M c2 3 M c3>

Druga postać normalna

Aby mieć drugą postać normalną, relacja musi być w pierwszej postaci normalnej i relacja nie może zawierać żadnej częściowej zależności. Relacja jest w 2NF, jeśli tak jest Brak częściowej zależności, tj. , żaden atrybut inny niż pierwszy (atrybuty, które nie są częścią żadnego klucza kandydującego) nie jest zależny od żadnego odpowiedniego podzbioru dowolnego klucza kandydującego w tabeli. Częściowa zależność – Jeśli właściwy podzbiór klucza kandydującego określa atrybut inny niż pierwszy, nazywa się to zależnością częściową.

• Przykład 1 - Rozważ tabelę 3 w sposób następujący poniżej.

STUD_NO COURSE_NO COURSE_FEE 1 C1 1000 2 C2 1500 1 C4 2000 4 C3 1000 4 C1 1000 2 C5 2000>

• {Zauważ, że istnieje wiele kursów mających tę samą opłatę za kurs} W tym przypadku COURSE_FEE nie może samodzielnie decydować o wartości COURSE_NO lub STUD_NO; COURSE_FEE razem ze STUD_NO nie może decydować o wartości COURSE_NO; COURSE_FEE razem z COURSE_NO nie mogą decydować o wartości STUD_NO; Zatem COURSE_FEE nie byłby atrybutem głównym, ponieważ nie należy do jedynego klucza kandydującego {STUD_NO, COURSE_NO}; Ale COURSE_NO -> COURSE_FEE, tj. COURSE_FEE zależy od COURSE_NO, który jest właściwym podzbiorem klucza kandydującego. Atrybut inny niż podstawowy COURSE_FEE jest zależny od odpowiedniego podzbioru klucza kandydującego, co jest zależnością częściową, a zatem relacja ta nie występuje w 2NF. Aby przekonwertować powyższą relację na 2NF należy podzielić tabelę na dwie tabele takie jak: Tabela 1: STUD_NO, COURSE_NO Tabela 2: COURSE_NO, COURSE_FEE

   Table 1     Table 2  STUD_NO COURSE_NO COURSE_NO COURSE_FEE  1 C1 C1 1000 2 C2 C2 1500 1 C4 C3 1000 4 C3 C4 2000 4 C1 C5 2000>

• NOTATKA: 2NF próbuje zredukować ilość zbędnych danych przechowywanych w pamięci. Na przykład, jeśli na kurs C1 uczęszcza 100 uczniów, nie musimy przechowywać jego opłaty jako 1000 dla wszystkich 100 rekordów, zamiast tego, gdy możemy zapisać ją w drugiej tabeli, ponieważ opłata za kurs dla C1 wynosi 1000.
• Przykład 2 – Rozważ następujące zależności funkcyjne w relacji R (A, B, C, D)

AB ->C [A i B wspólnie określają C] BC -> D [B i C wspólnie określają D]>

W powyższej relacji AB jest jedynym kluczem kandydującym i nie ma tu żadnej zależności częściowej, tj. żaden właściwy podzbiór AB nie wyznacza żadnego atrybutu innego niż pierwszy.

X is a super key. Y is a prime attribute (each element of Y is part of some candidate key).>

Przykład 1: W relacji STUDENT podanej w tabeli 4 zestaw FD: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}

Klucz kandydata: {STUD_NO}

Dla tej relacji w tabeli 4, STUD_NO -> STUD_STATE i STUD_STATE -> STUD_COUNTRY są prawdziwe.

Zatem STUD_COUNTRY jest przejściowo zależne od STUD_NO. Narusza to trzecią formę normalną.

Aby przekonwertować to do trzeciej postaci normalnej, rozłożymy relację STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) jako: STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE) STATE_COUNTRY (STATE, COUNTRY)

Rozważ relację R(A, B, C, D, E) A -> BC, CD -> E, B -> D, E -> A Wszystkie możliwe klucze kandydujące w powyższej relacji to {A, E, CD, BC} Wszystkie atrybuty znajdują się po prawej stronie, wszystkie zależności funkcjonalne są liczbami pierwszymi.

Przykład 2: Znajdź najwyższą postać normalną relacji R(A,B,C,D,E) z FD ustawionym jako {BC->D, AC->BE, B->E}

Krok 1: Jak widzimy, (AC)+ ={A,C,B,E,D}, ale żaden z jego podzbiorów nie może określić wszystkich atrybutów relacji, więc AC będzie kluczem kandydującym. A lub C nie można wyprowadzić z żadnego innego atrybutu relacji, zatem będzie tylko 1 klucz kandydujący {AC}.

Krok 2: Atrybuty pierwsze to te atrybuty, które w tym przykładzie są częścią klucza kandydującego {A, C}, a inne w tym przykładzie nie będą pierwszymi {B, D, E}.

Krok 3: Relacja R jest w pierwszej postaci normalnej, ponieważ relacyjny system DBMS nie pozwala na atrybuty wielowartościowe ani złożone. Relacja jest w 2. postaci normalnej, ponieważ BC->D jest w 2. postaci normalnej (BC nie jest właściwym podzbiorem klucza kandydującego AC), a AC->BE jest w 2. postaci normalnej (AC jest kluczem kandydującym) i B->E jest w drugiej postaci normalnej (B nie jest podzbiorem właściwym klucza kandydującego AC).

Relacja nie jest w trzeciej postaci normalnej, ponieważ w BC->D (ani BC nie jest superkluczem, ani D nie jest atrybutem pierwszym) i w B->E (ani B nie jest superkluczem, ani E nie jest atrybutem pierwszym), ale do spełniają trzecią normalną, albo LHS FD powinno być superkluczem, albo RHS powinno być atrybutem głównym. Zatem najwyższą normalną formą relacji będzie druga forma normalna.

Rozważmy na przykład relację R(A, B, C) A -> BC, B -> A i B, oba są super kluczami, więc powyższa relacja jest w BCNF.

Trzecia postać normalna

Mówi się, że relacja jest w trzeciej postaci normalnej, jeśli nie mamy żadnej zależności przechodniej dla atrybutów innych niż pierwsze. Podstawowym warunkiem trzeciej postaci normalnej jest to, że relacja musi być w drugiej postaci normalnej.

Poniżej podano podstawowy warunek, który musi być spełniony w nietrywialnej zależności funkcyjnej X -> Y:

• X to super klucz.
• Y jest atrybutem pierwszym (oznacza to, że element Y jest częścią klucza kandydującego).

Więcej informacji znajdziesz w Trzecia postać normalna w DBMS.

BCNF

BCNF (Boyce-Codd Normal Form) to zaawansowana wersja trzeciej postaci normalnej. Tutaj mamy kilka dodatkowych zasad niż trzecia postać normalna. Podstawowym warunkiem, aby jakakolwiek relacja była w BCNF, jest to, że musi ona być w trzeciej postaci normalnej.

Musimy skupić się na kilku podstawowych zasadach obowiązujących BCNF:

1. Table must be in Third Normal Form. 2. In relation X->Y, X muszą być superkluczem w relacji.>

Więcej informacji znajdziesz w BCNF w DBMS.

Czwarta postać normalna

Czwarta postać normalna nie zawiera żadnej nietrywialnej zależności wielowartościowej z wyjątkiem klucza kandydującego. Podstawowym warunkiem czwartej postaci normalnej jest to, że relacja musi być w BCNF.

Podstawowe zasady opisano poniżej.

1. It must be in BCNF. 2. It does not have any multi-valued dependency.>

Więcej informacji znajdziesz w Czwarta postać normalna w systemie DBMS.

przekonwertuj ciąg na jsonobject Java

Piąta postać normalna

Piąta postać normalna jest również nazywana rzutowaną formą normalną. Podstawowe warunki piątej postaci normalnej są wymienione poniżej.

Relation must be in Fourth Normal Form. The relation must not be further non loss decomposed.>

Więcej informacji znajdziesz w Piąta postać normalna w systemie DBMS.

Zastosowania form normalnych w systemie DBMS

• Spójność danych: Zwykłe formularze zapewniają spójność danych i brak zbędnych informacji. Pomaga to zapobiegać niespójnościom i błędom w bazie danych.
• Nadmiarowość danych: Zwykłe formularze minimalizują nadmiarowość danych, organizując je w tabele zawierające tylko unikalne dane. Zmniejsza to ilość miejsca potrzebnego do przechowywania bazy danych i ułatwia zarządzanie.
• Czas odpowiedzi: Zwykłe formularze mogą poprawić wydajność zapytań, zmniejszając liczbę złączeń wymaganych do pobrania danych. Pomaga to przyspieszyć przetwarzanie zapytań i poprawić ogólną wydajność systemu.
• Konserwacja bazy danych: Zwykłe formularze ułatwiają utrzymanie bazy danych, zmniejszając ilość zbędnych danych, które wymagają aktualizacji, usunięcia lub modyfikacji. Pomaga to usprawnić zarządzanie bazami danych i zmniejszyć ryzyko błędów lub niespójności.
• Projekt bazy danych: Zwykłe formularze zawierają wytyczne dotyczące projektowania baz danych, które są wydajne, elastyczne i skalowalne. Pomaga to zapewnić, że bazę danych można łatwo modyfikować, aktualizować i rozszerzać w razie potrzeby.

Kilka ważnych punktów na temat form normalnych

• BCNF jest wolny od redundancji spowodowanej zależnościami funkcjonalnymi.
• Jeśli relacja jest w BCNF, to 3NF również jest spełnione.
• Jeśli wszystkie atrybuty relacji są atrybutami pierwszymi, to relacja jest zawsze w 3NF.
• Relacja w relacyjnej bazie danych ma zawsze postać co najmniej 1NF.
• Każda relacja binarna (relacja mająca tylko 2 atrybuty) jest zawsze w BCNF.
• Jeśli Relacja ma tylko pojedyncze klucze kandydujące (tj. każdy klucz kandydujący składa się tylko z 1 atrybutu), wówczas Relacja jest zawsze w 2NF (ponieważ nie jest możliwa częściowa zależność funkcjonalna).
• Czasami wybranie formy BCNF może nie zachować zależności funkcjonalnej. W takim przypadku wybierz BCNF tylko wtedy, gdy utracone FD nie są wymagane, w przeciwnym razie normalizuj tylko do 3NF.
• Po BCNF istnieje wiele innych form normalnych, takich jak 4NF i inne. Jednak w rzeczywistych systemach baz danych generalnie nie jest wymagane wykraczanie poza BCNF.

Wniosek

Podsumowując, relacyjne bazy danych można uporządkować według zestawu reguł zwanych formularzami normalnymi Baza danych administracyjne (1NF, 2NF, 3NF, BCNF, 4NF i 5NF), które redukują redundancję danych i zachowują integralność danych. Rozwiązując różnego rodzaju anomalie i zależności danych, każda kolejna normalna forma rozszerza się na tę, która była wcześniejsza. Szczególne wymagania i właściwości przechowywanych danych określają, która forma normalna powinna zostać użyta; wyższe formy normalne zapewniają bardziej rygorystyczną integralność danych, ale mogą również skutkować bardziej skomplikowanymi strukturami baz danych.

Linki do pytań z poprzedniego roku

• GATE CS 2012, Pytanie 2
• GATE CS 2013, pytanie 54
• GATE CS 2013, Pytanie 55
• GATE CS 2005, pytanie 29
• GATE CS 2002, pytanie 23
• GATE CS 2002, pytanie 50
• GATE CS 2001, pytanie 48
• GATE CS 1999, pytanie 32
• GATE IT 2005, pytanie 22
• GATE IT 2008, pytanie 60
• GATE CS 2016 (zestaw 1), pytanie 31

Często zadawane pytania w formularzu normalnym

P.1: Dlaczego normalizacja jest ważna w systemie DBMS?

Odpowiedź:

Normalizacja pomaga zapobiegać anomaliom w bazie danych, co ostatecznie zapewnia spójność bazy danych i pomaga w łatwym utrzymaniu bazy danych.

P.2: Czy możliwa jest nadmierna normalizacja bazy danych?

Odpowiedź:

Tak, nadmierna normalizacja doprowadzi do złożonych zapytań, a także zmniejszy wydajność. Zapewnia równowagę pomiędzy normalizacją a praktycznością.

P.3: Czy konieczna jest normalizacja bazy danych do najwyższej postaci normalnej, takiej jak (BCNF lub 4NF)?

Odpowiedź:

Nie ma określonego warunku koniecznego dla jakiejkolwiek normalizacji bazy danych. W wielu przypadkach niższa forma może być wystarczająca dla określonej wydajności i prostoty.