Relacyjne Bazy Danych

Europejska Wyższa Szkoła Informatyczno-
Ekonomiczna
Mgr inż. Piotr Greniewski

Wykład 9: - Normalizacja

Spis treści



Bazy danych wstęp



Geneza relacyjnych baz danych



Podstawy relacyjnych baz danych



Podstawy-SQL-1



Podstawy-SQL-2



Podstawy-SQL-3



Operacje na danych



Transakcje i blokady



Normalizacja

Powtórka z terminologii



Relacja

– jest podzbiorem iloczynu

kartezjańskiego reprezentowanego przez zbiór
krotek. Reprezentacją relacji w relacyjnych
bazach danych jest tablica.



Krotka

– oznacza wiersz w tablicy.



Atrybut

– oznacza kolumnę tablicy (dokładnie

różne wystąpienia tego samego atrybutu)



Stopień relacji

– liczba atrybutów w relacji.



Liczność relacji

– liczba krotek w relacji

Powtórka z terminologii



Klucz główny (PK)

– kolumna lub kombinacja

kolumn, których wartości jednoznacznie
identyfikują wiersze w tablicy.



Klucz obcy (FK)

– kolumna lub kombinacja

kolumn, których wartości określają klucz
główny innej tablicy.



Dziedzina (atrybutu)

– lista dostępnych

wartości atrybutu.

Powtórka z terminologii



W relacyjnych bazach danych powiązania
pomiędzy krotkami w tabeli i pomiędzy
tabelami są zrealizowane za pomocą kluczy
głównych i kluczy obcych.



Istnieją cztery rodzaje kluczy:



Kandydaci na klucze



Klucze alternatywne



Klucze obce



Sztuczne klucze

Powtórka z terminologii



Klucze kandydujące

– jest to dowolna kolumna

lub kombinacja kolumn, których zawartość
może być użyta dla identyfikacji wierszy w
tablicy



Kluczami kandydującymi na PK są id_pracownika, pesel
i nazwisko.



Wybieramy id_pracownika na PK.



Pesel i nazwisko są kluczami alternatywnymi



kod_wydziału jest FK

pracownicy

id_pracownika
kod_wydzialu (FK)

pesel
nazwisko
adres

wydzial

kod_wydzialu

nazwa_wydzialu

Powtórka z terminologii



Jeśli klucze kandydujące istnieją, projektant
wybiera jeden z nich na klucz główny. Powinien
on spełniać dodatkowe warunki:



unikalność



być minimalnym (tzn. bez nadmiarowych pól)



Klucz alternatywny

– może być używany jako

alternatywny dostęp do danych.



Klucz obcy

– jest kolumną i kombinacją kolumn,

którego wartości są kluczami głównymi innej
tablicy.



Oba klucze FK i PK powinny mieć tę samą
dziedzinę.

Powtórka z terminologii



Sztuczne klucze główne

– jeżeli w tabeli nie

istnieje naturalny klucz główny to należy
utworzyć sztuczny.



Zalety stosowania sztucznych kluczy:



klucze sztuczne prowadzą do prostych rozwiązań w
przypadku nie istnienia kluczy naturalnych



złożony klucz główny, występujący jako klucz obcy w
innej tabeli wprowadza redundancję pól, której
unikniemy wprowadzając klucz obcy.



operacje wyszukiwania SELECT będzie krótsza w
przypadku klucza sztucznego.

Zależności atrybutów



Normalizacja

jest oparta na idei funkcjonalnej

zależności niektórych atrybutów. Istnieją dwa rodzaje

zależności atrybutów, zależność

funkcjonalna

zależność

związana z wielowartościowością.



Zależność funkcjonalna

: w relacji zawierającej

atrybuty A i B, B jest funkcjonalnie zależny od A

wtedy i tylko wtedy, gdy za każdym razem, kiedy

atrybut A ma tę samą wartość a

, atrybut B musi mieć

tę samą wartość b



uwagi do definicji:



A i B mogą być złożone



jeśli B jest funkcjonalnie zależne od A to mówimy że A jest

wyznacznikiem B



wszystkie pola są funkcjonalnie zależne od klucza głównego.

Funkcjonalna zależność atrybutów



NAZWA_WYDZ jest

funkcjonalnie zależna

od NR_WYDZ



NR_WYDZ

jest wyznacznikiem

NAZWA_WYDZ

NAZWISKO

NR_WYDZ NAZWA_WYD

Kowalski

Badania

Bogdanowicz

Księgowość

Jonasz

Badania

Król

Badania

Milewski

Marketing

Zależności atrybutów



Wielowartościowa zależność – w relacji
zawierającej atrybuty A i B, B jest
wielowartościowo zależne od A wtedy i tylko
wtedy, gdy jednej wartości atrybutu A
odpowiada wiele wartości atrybutu B

Wielowartościowa zależność atrybutów



Atrybuty software i hardware są

wielowartościowo

zależne

od atrybutu nazwisko.

nazwisk
o

software

hardwar
e

Bielecki

SQL*Form
s

IBM

Bielecki

SQL*Form
s

VAX

Bielecki

SQL*QMX

IBM

Bielecki

SQL*QMX

VAX

Bielecki

SQL*Plus

IBM

Bielecki

SQL*Plus

VAX

nazwisk
o

hardwar
e

Bielecki

IBM

Bielecki

VAX

nazwisk
o

software

Bielecki

SQL*Form
s

Bielecki

SQL*QMX

Bielecki

SQL*Plus

Związki pomiędzy tabelami (relacjami) A i B



jeden

zero, jeden lub wiele



jeden

jeden lub wiele

Tabela-A

Tabela-B

Tabela-A

Tabela-B

Związki pomiędzy tabelami (relacjami) A i B



jeden

zero, lub jeden



jeden

Tabela-A

Tabela-B

Tabela-A

Tabela-B

Opis normalizacji



Normalizacja

to proces organizacji danych w bazie

danych. Polega on na tworzeniu tabel i ustanawianiu

pomiędzy nimi powiązań według reguł obowiązujących

zarówno przy ochronie danych, jak i uelastycznianiu

bazy danych przez eliminowanie

powtarzających się

niespójnych zależności



Powtarzające się

dane niepotrzebnie zajmują miejsce

na dysku i są przyczyną powstawania problemów z

obsługą. Jeśli konieczna jest zmiana danych

istniejących w więcej niż jednej lokalizacji, musi być

ona przeprowadzona we wszystkich lokalizacjach w

ten sam sposób.



Implementacja zmiany adresu klienta jest o wiele

łatwiejsza, jeśli dane są przechowywane tylko w tabeli

Klienci i w żadnym innym miejscu bazy danych.

Opis normalizacji



Co to jest „

niespójna zależność

” ? O ile

przeglądanie tabeli Klienci w poszukiwaniu
adresu konkretnego klienta można nazwać
zachowaniem intuicyjnym, to poszukiwanie w tej
tabeli pensji, której wypłaty wymaga pracownik
od klienta, nie ma żadnego sensu.



Pensja pracownika jest związana z pracownikiem
lub zależy od pracownika i dlatego powinna być
przeniesiona do tabeli Pracownicy.



Niespójne zależności mogą utrudniać dostęp do
danych, ponieważ ścieżka ich odnajdywania
może zostać utracona lub uszkodzona

Opis normalizacji



Istnieje kilka reguł normalizacji baz danych.



Każda reguła nosi nazwę „

postać normalna

”.



Jeśli przestrzegana jest pierwsza reguła, o
postaci bazy danych mówi się, że jest „pierwszą
postacią normalną”.



Jeśli przestrzegane są pierwsze trzy reguły,
postać bazy danych przyjmuje się za „trzecią
postać normalną”.



Chociaż możliwe są inne poziomy normalizacji,
trzecia postać normalna uważana jest za
najwyższy poziom wymagany przez większość
aplikacji

Opis normalizacji



Jak to bywa z wieloma formalnymi regułami i
specyfikacjami, rzeczywistość nie zawsze
pozwala na ich dokładne odwzorowanie.



Ogólnie, do odnalezienia niedogodności
normalizacja wymaga dodatkowych tabel i dla
niektórych osób jest to uciążliwe.



Przed podjęciem decyzji o złamaniu jednej z
pierwszych trzech reguł normalizacji należy
upewnić się, że projekt aplikacji przewiduje
występowanie problemów, takich jak
powtarzające się dane lub niespójne zależności.

Pierwsza postać normalna - 1NF



Pierwsza postać normalna

: brak

powtarzających się grup



W poszczególnych tabelach wyeliminuj
powtarzające się grupy.



Dla każdego zestawu danych pokrewnych
utwórz oddzielną tabelę.



Dla każdego zestawu danych pokrewnych
określ klucz podstawowy.

Pierwsza postać normalna - 1NF



Do przechowywania podobnych danych w
jednej tabeli nie należy używać wielu pól.



Na przykład rekord służący do śledzenia
pozycji inwentarzowej, która może pochodzić
z dwóch różnych źródeł, może zawierać pola
Kod sprzedawcy 1 oraz Kod sprzedawcy 2.



Co się zdarzy po dodaniu trzeciego
sprzedawcy? Dodawanie pola nie dostarcza
odpowiedzi.

Pierwsza postać normalna - 1NF



Wymaga to modyfikacji programu i tabel oraz
nie umożliwia obsługi zmieniającej się
dynamicznie liczby sprzedawców.



Zamiast tego należy umieścić wszystkie
informacje o sprzedawcach w oddzielnej tabeli
o nazwie Sprzedawcy, a następnie połączyć
magazyn ze sprzedawcami za pomocą klucza z
numerem pozycji, albo sprzedawców z
magazynem za pomocą klucza z kodem
sprzedawcy

Nieznormalizowana tabela opisująca studenta



Co zrobić jeśli zmienią się przedmioty?



Jak zapisać powtarzanie semestru?



itd.

index

nazwisk
o

imie

przedmio
t-1

ocena-1

przedmio
t-2

ocena-2

32567

Kowals

Jan

A100

3.0

A1001

4.5

przedmio
t-3

ocena-3 przedmio

t-4

...

przedmio
t-n

ocena-n

A103

5.0

A1004

A10n

5.0

Nieznormalizowana tabela opisująca studenta

SREDNIA= (SELECT ocena1+ocena2+...+ocenan)/n

studenci

index

nazwisko
imie
semestr
przedmiot1
ocena1
przedmiot2
ocena2
przedmiot3
ocena3
przedmiot4
ocena4
------------
przedmiotn
ocenan

Pierwsza postać normalna



Tabele wpis i studenci spełniają pierwszą postać
normalną



Znikają niedogodności związane np. z wyliczaniem
średniej ocen ze studiów.



Student może być wpisany na semestr dowolną ilość
razy.

wpis

nr_wpisu
semestr
przedmiot
ocena

studenci

index
nazwisko
imie

Pierwsza postać normalna

wpis

nr_wpisu
index (FK)

semestr
przedmiot
ocena

studenci

index

nazwisko
imie



Dla każdej tabeli musi istnieć klucz główny
(PK)



Połączenie za pomocą klucza obcego (FK)

Tabela nieznormalizowana (zerowa postać

normalna)

nazwis
ko

nr_w

nazwa_w

nr_k

kierowni
k

nr_p

projekt

data_ro
z

wynag

902

Kowals
ki

sprzedaż

988

Janowski

ocena

10-07-
96

1000

testowani
e

29-07-
96

1000

przekazan
ie

20-
08096

1500

988

Janows
ki

marketin
g

699

Walasik

ocena

15-07-
96

2000

analiza

14-07-
96

2500

przekazan
ie

20-08-
96

2000

562

Kowals
ki

sprzedaż

099

Filipowic
z

analiza

20-05-
96

1500

Tabela nieznormalizowana (zerowa postać

normalna)



Tabela pracownicy zawiera powtarzające się grupy

wartości atrybutów (i dlatego nie jest relacją).



Rozwiązaniem jest dekompozycja (nie powodująca utraty

danych na dwie tabele pracownicy i przypisania.

Dekompozycja usunie powtarzające się grupy.

pracownicy

nazwisko
nr_wydzialu
nazwa_wydzialu
nr_kierownika
nazwa_kierownika
nr_projektu
nazwa_projektu
data_rozp
wynagrodzenie

Pierwsza postać normalna

nazwis
ko

nr_w

nazwa_w

nr_k

kierowni
k

nr_p

projekt

data_ro
z

wynag

902

Kowals
ki

sprzedaż

988

Janowski

ocena

10-07-
96

1000

902

Kowals
ki

sprzedaż

988

Janowski

testowani
e

29-07-
96

1000

902

Kowals
ki

sprzedaż

988

Janowski

przekazan
ie

20-
08096

1500

988

Janows
ki

marketin
g

699

Walasik

ocena

15-07-
96

2000

988

Janows
ki

marketin
g

699

Walasik

analiza

14-07-
96

2500

988

Janows
ki

marketin
g

699

Walasik

przekazan
ie

20-08-
96

2000

562

Kowals
ki

sprzedaż

099

Filipowic
z

analiza

20-05-
96

1500

nazwis
ko

nr_w

nazwa_w

nr_k

kierowni
k

902

Kowals
ki

sprzedaż

988

Janowski

988

Janows
ki

marketin
g

699

Walasik

562

Kowals
ki

sprzedaż

099

Filipowic
z

nr_p

projekt

data_ro
z

wynag

902

ocena

10-07-
96

1000

902

testowani
e

29-07-
96

1000

902

przekazan
ie

20-
08096

1500

988

ocena

15-07-
96

2000

988

analiza

14-07-
96

2500

988

przekazan
ie

20-08-
96

2000

562

analiza

20-05-
96

1500



pracownicy - 1NF



przypisania - 1NF

Pierwsza postać normalna

pracownicy

nazwisko
nr_wydzialu
nazwa_wydzialu
nr_kierownika
nazwa_kierownika
nr_projektu
nazwa_projektu
data_rozp
wynagrodzenie



zerowa postać normalna



1 NF



1 NF

pracownicy

nazwisko
nr_wydzialu
nazwa_wydzialu
nr_kierownika
nazwa_kierownika

przypisania

nr
nr_projektu

nazwa_projektu
data_rozp
wynagrodzenie

Druga postać normalna – 2NF



Druga postać normalna

: zależność wszystkich

atrybutów od jednoznacznego identyfikatora.



Druga postać normalna stosuje się do kluczy
złożonych.



Utwórz oddzielne tabele dla zestawów
wartości, odnoszących się do wielu rekordów.



Ustal powiązania tabel za pomocą klucza
obcego

Druga postać normalna – 2NF



Rekordy nie powinny zależeć od niczego innego
niż klucz podstawowy tabeli (w razie potrzeby
może to być klucz złożony).



Na następnym slajdzie kluczem głównym w
tablicy przypisania jest nr i nr_projektu.
Jednakże kolumna projekt jest funkcjonalnie
zależna od nr_projektu to znaczy od części
klucza głównego.



Rozwiązaniem jest dekompozycja, polegająca na:



usunięciu atrybutu funkcjonalnego związanego
(projekt) do osobnej tabeli (projekty)



zabranie wraz z nim wyznacznika (nr_projektu)

Druga postać normalna – 2NF

nazwis
ko

nr_w

nazwa_w

nr_k

kierowni
k

902

Kowals
ki

sprzedaż

988

Janowski

988

Janows
ki

marketin
g

699

Walasik

562

Kowals
ki

sprzedaż

099

Filipowic
z

nr_p

projekt

data_ro
z

wynag

902

ocena

10-07-
96

1000

902

testowani
e

29-07-
96

1000

902

przekazan
ie

20-
08096

1500

988

ocena

15-07-
96

2000

988

analiza

14-07-
96

2500

988

przekazan
ie

20-08-
96

2000

562

analiza

20-05-
96

1500



pracownicy - 2NF



przypisania - 1NF

nr_p

data_ro
z

wynag

902

10-07-
96

1000

902

29-07-
96

1000

902

20-
08096

1500

988

15-07-
96

2000

988

14-07-
96

2500

988

20-08-
96

2000

562

20-05-
96

1500

nr_p

projekt

ocena

testowani
e

przekazan
ie

analiza



przypisania - 2NF



projekt - 2NF

Druga postać normalna – 2NF

pracownicy

nazwisko
nr_wydzialu
nazwa_wydzialu
nr_kierownika
nazwa_kierownika

przypisania

nr
nr_projektu (FK)

data_rozp
wynagrodzenie

projekty

nr_projektu

nazwa_projektu



2 NF



2 NF



2 NF

Trzecia postać normalna – 3NF



Trzecia postać normalna

: żaden atrybut nie

będący częścią klucza nie zależy od innego
atrybutu nie będącego częścią klucza.



Wyeliminuj pola, które nie zależą od klucza.



Wartości rekordu, które nie są częścią jego
klucza, nie należą do tabeli. Zazwyczaj, jeśli
zawartość grupy pól odnosi się do więcej niż
jednego rekordu tabeli, należy rozważyć
umieszczenie tych pól w oddzielnej tabeli.

Trzecia postać normalna – 3NF



W tablicy pracownicy nr_wydziału jest
funkcjonalnie zależny od pola
nazwa_wydziału, który nie jest kluczem
głównym.



Z atrybutów tych tworzy się nową tabelę
wydziały. Atrybut nazwa_wydziału zostaje
usunięty z tabeli pracownicy, natomiast nr_w
pozostaje w niej jako klucz obcy.

Trzecia postać normalna – 3NF

nr_p

data_ro
z

wynag

902

10-07-
96

1000

902

29-07-
96

1000

902

20-
08096

1500

988

15-07-
96

2000

988

14-07-
96

2500

988

20-08-
96

2000

562

20-05-
96

1500

nr_p

projekt

ocena

testowani
e

przekazan
ie

analiza



przypisania - 3NF

nazwis
ko

nr_w

nazwa_w

nr_k

kierowni
k

902

Kowals
ki

sprzedaż

988

Janowski

988

Janows
ki

marketin
g

699

Walasik

562

Kowals
ki

sprzedaż

099

Filipowic
z



pracownicy - 2NF



projekt - 3NF

nazwis
ko

nr_w

nr_k

902

Kowals
ki

988

Janows
ki

699

562

Kowals
ki

099

nr_w

nazwa_w

sprzedaż

marketin
g

sprzedaż



pracownicy - 3NF



wydziały - 3NF

Trzecia postać normalna – 3NF

pracownicy

nr
nr_wydzialu (FK)
nr_kierownika (FK)

nazwisko

przypisania

nr (FK)
nr_projektu (FK)
nr_wydzialu (FK)
nr_kierownika (FK)

data_rozp
wynagrodzenie

projekty

nr_projektu

nazwa_projektu

wydzialy

nr_wydzialu
nr_kierownika (FK)

nazwa_wydzialu

kierownicy

nr_kierownika

nazwa_kierownika

Trzecia postać normalna – 3NF



Wyjątek

: Stosowanie reguł trzeciej postaci

normalnej, chociaż teoretycznie wskazane, nie

zawsze jest praktyczne.



Chcąc wyeliminować wszystkie możliwe wewnętrzne

zależności pomiędzy polami tabeli Klienci, należy

utworzyć oddzielne tabele dla miast, kodów

pocztowych, przedstawicieli handlowych, klas klienta

i innych czynników, które mogą być zduplikowane w

wielu rekordach.



Normalizacja oznacza teoretycznie poprawę

wydajności. Jednak wiele mniejszych tabel może

spowodować spadek wydajności lub brak możliwości

otwarcia pliku i przekroczenie pojemności pamięci.

Trzecia postać normalna – 3NF



Bardziej realne może okazać się zastosowanie
trzeciej postaci normalnej tylko do często
zmienianych danych.



Pozostawiając niektóre pola zależne, zmień
projekt aplikacji tak, aby po zmianie
dowolnego pola wymagała od użytkownika
sprawdzenia wszystkich pól pokrewnych.

Inne postacie normalne



Istnieje czwarta postać normalna, zwana
również postacią normalną Boyce'a-Codda
(BCNF) oraz piąta postać normalna, ale są one
rzadko wykorzystywane w praktyce.



Zlekceważenie tych reguł może skutkować
mniej doskonałym projektem bazy danych, ale
nie powinno ono wpływać na funkcjonalność.

Postać normalna Boyce-Codda



Postać normalna Boyce-Codda (BCNF)

- Ta

postać normalna jest uzupełniająca w
stosunku do trzeciej postaci normalnej. Jest
ona niezbędna w przypadku, gdy atrybuty
będące kandydatami na klucze są:



wielokrotne



złożone



nakładające się na siebie

Postać normalna Boyce-Codda



Weźmy pod uwagę dwóch nakładających się
kandydatów na klucze w tablicy regiony a mianowicie
(region, gmina) oraz (kod_regionu,gmina).



Region jest związany funkcjonalnie tylko z częścią
klucza (kod_regionu, gmina). Nie jest to naruszeniem
3NF ani 2NF ponieważ region sam jest częścią klucza.



Relacja jest w BCNF wtedy i tylko wtedy gdy każdy
wyznacznik jest kandydatem na klucz.

kod_regio

region

gmina

województw

Północny

szczecińskie

Północny

słupskie

Północny

gdańskie

Centralny 4

warszawskie

Wschodni 2

lubelskie



Regiony – 3NF

Postać normalna Boyce-Codda

kod_regio

region

gmina

województw

Północny

szczecińskie

Północny

słupskie

Północny

gdańskie

Centralny 4

warszawskie

Wschodni 2

lubelskie



regiony – 3NF

kod_regio

region

Północny

Centralny

Wschodni

kod_regio

gmina

województw

szczecińskie

słupskie

gdańskie

warszawskie

lubelskie



województwa – BCNF



regiony – BCNF

Czwarta postać normalna – 4NF



Czwarta postać normalna

: odnosi się do

wielowartościowej zależności atrybutów i jest

naruszona wtedy gdy taka zależność występuje w

tej samej tabeli.



Relacja (tabela) jest w 4NF wtedy i tylko wtedy

gdy jest w 3NF i nie zawiera wielowartościowej

zależności atrybutów.



Tabela umiejętności (następny slajd) nie zawiera

żadnych funkcjonalnie zależnych atrybutów i

dlatego nie narusza 3NF.



Aby sprowadzić ją do 4NF należy wyłączyć

niezależne wielowartościowe zależności do tabel:

umiejętności_software i umiejętności_hardware

Czwarta postać normalna – 4NF

nazwisk
o

software

hardwar
e

Bielecki

SQL*Form
s

IBM

Bielecki

SQL*Form
s

VAX

Bielecki

SQL*QMX

IBM

Bielecki

SQL*QMX

VAX

Bielecki

SQL*Plus

IBM

Bielecki

SQL*Plus

VAX

nazwisk
o

hardwar
e

Bielecki

IBM

Bielecki

VAX

nazwisk
o

software

Bielecki

SQL*Form
s

Bielecki

SQL*QMX

Bielecki

SQL*Plus



3NF



4NF



4NF

Piąta postać normalna – 5NF



Piąta postać normalna

: tabela jest w 5NF

wtedy, gdy jest w 4NF, a jej dekompozycja i
ponowne połączenie (join) nie są operacjami
symetrycznymi (tzn. nie prowadzą do
rekonstrukcji tablicy wyjściowej)



Zagadnienie zilustrowano na następnym
slajdzie.

Piąta postać normalna – 5NF



podział pierwotnej tabeli a
następnie jej złączenie
produkuje fałszywy wniosek



pierwotna tabela jest w 5NF

osoba

gra

kraj

Natasza

poker

Rosja

Natasza

szachy

USA

Borys

szachy

Rosja

gra

kraj

poker

Rosja

szachy

USA

szachy

Rosja

osoba

kraj

Natasza

Rosja

Natasza

USA

Borys

Rosja

osoba

gra

Natasza

poker

Natasza

szachy

Borys

szachy

osoba

gra

kraj

Natasza

poker

Rosja

Natasza

szachy

USA

Borys

szachy

Rosja

Natasza

szachy

Rosja

Normalizowanie tabeli przykładowej



W poniższych krokach przedstawiono proces

normalizacji fikcyjnej tabeli student.



Mamy tabelę student w postaci

nieznormalizowanej

Tabela student

Nr_Stude

nta

Opieku

Pokój

Klasa_1

Klasa_2

Klasa_3

1022

Nowak

412

101-07

143-01

159-02

4123

Kowals

216

201-01

211-02

214-01

Normalizowanie tabeli przykładowej



Pierwsza postać normalna:
brak powtarzających się grup



Tabele powinny mieć tylko dwa wymiary.



Ponieważ jeden student ma kilka klas, klasy
powinny znajdować się w oddzielnej tabeli.



Występowanie pól Klasa_1, Klasa_2 i Klasa_3
w powyższych rekordach jest oznaką
problemów podczas projektowania

Normalizowanie tabeli przykładowej



Arkusze kalkulacyjne często wykorzystują
trzeci wymiar, ale tabele nie powinny.



Innym podejściem do problemu jest związek
(relationship) jeden-do-wielu, w którym nie
należy strony jeden i strony wielu umieszczać
w tej samej tabeli.



Zamiast tego, należy utworzyć inną tabelę w
pierwszej postaci normalnej, eliminując
powtarzające się grupy (Nr_Klasy), tak jak to
przedstawiono poniżej:

Normalizowanie tabeli przykładowej



Tabela student w 1NF

Tabela student

Nr_Studenta

(PK)

Opiekun Pokój

Nr_Klas

1022

Nowak

412

101-07

1022

Nowak

412

143-01

1022

Nowak

412

159-02

4123

Kowalsk
i

216

201-01

4123

Kowalsk
i

216

211-02

4123

Kowalsk

216

214-01

Normalizowanie tabeli przykładowej



Druga postać normalna:
eliminowanie powtarzających się danych



W powyższej tabeli dla każdego pola
Nr_Studenta istnieje wiele wartości w polach
Nr_Klasy.



Pole Nr_Klasy nie jest czynnościowo zależne od
pola Nr_Studenta (klucz podstawowy), dlatego
ta relacja nie znajduje się w drugiej postaci
normalnej.



Drugą postać normalną przedstawiono na
następujących dwóch tabelach: studenci i
rejestracja

Normalizowanie tabeli przykładowej



Tabele student i rejestracja w 2NF

Tabela student

Nr_Studenta

(PK)

Opiekun Pokój

1022

Nowak

412

4123

Kowalski 216

Tabela rejestracja

Nr_Student

Nr_Klasy

(PK)

1022

101-07

1022

143-01

1022

159-02

4123

201-01

4123

211-02

4123

214-01

Normalizowanie tabeli przykładowej



Trzecia postać normalna:
eliminowanie danych, które nie zależą od
klucza



W ostatnim przykładzie pole Pokój (numer
pokoju opiekuna) jest czynnościowo zależne
od atrybutu Opiekun.



Rozwiązaniem jest przeniesienie tego atrybutu
z tabeli Studenci do tabeli Wydział, tak jak to
przedstawiono poniżej:

Normalizowanie tabeli przykładowej



Tabele student, rejestracja i wydział w 3NF

Tabela wydział

Opiekun Pokój

Wydział

(PK)

Nowak

412

Kowalsk
i

216

Tabela student

Nr_Studenta

(PK)

Wydział

(FK)

1022

4123

Tabela rejestracja

Nr_Studenta

(FK)

Nr_Klasy(P

1022

101-07

1022

143-01

1022

159-02

4123

201-01

4123

211-02

4123

214-01

Document Outline

Slide 1
Slide 2
Slide 3
Slide 4
Slide 5
Slide 6
Slide 7
Slide 8
Slide 9
Slide 10
Slide 11
Slide 12
Slide 13
Slide 14
Slide 15
Slide 16
Slide 17
Slide 18
Slide 19
Slide 20
Slide 21
Slide 22
Slide 23
Slide 24
Slide 25
Slide 26
Slide 27
Slide 28
Slide 29
Slide 30
Slide 31
Slide 32
Slide 33
Slide 34
Slide 35
Slide 36
Slide 37
Slide 38
Slide 39
Slide 40
Slide 41
Slide 42
Slide 43
Slide 44
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
Slide 52
Slide 53
Slide 54
Slide 55