04/10/21

1

MS Access 2000

Normalizacja

04/10/21

2

Wstęp

Podstawowym celem procesu normalizacji jest

usunięcie redundancji (powtarzania się)

danych. Dzięki temu operacje związane z

dodawaniem, modyfikacją lub usuwaniem

danych będą ograniczone do minimum.

04/10/21

3

Faktura



Numer faktury



Nazwa odbiorcy



NIP odbiorcy



Adres odbiorcy



Data sprzedaży



Sposób płatności



Nazwa towaru



Ilość



Cena netto



Wartość netto



Stawka VAT

Proces normalizacji
przeprowadzimy dla
przykładu na tabeli
Faktura, która jest
modelem
rzeczywistej faktury.

04/10/21

4

Definicja: Pierwsza postać normalna

Tabela jest w pierwszej postaci normalnej,

jeśli wartości pól są elementarne.

O wartości elementarnej możemy myśleć
jak o najmniejszej informacji, którą możemy
uzyskać z bazy danych. Nie można uzyskać
z bazy danych części wartości elementarnej.
Na przykład jeśli w tabeli chcemy
przechowywać imiona i nazwiska osób, i
będziemy chcieli wybierać z niej osoby tylko
po nazwisku, to znaczy, że musimy mieć w
tabeli pole ‘Nazwisko’ i pole ‘Imię’
oddzielnie, a nie tylko jedno pole ‘Nazwisko
i imię’.

04/10/21

5

Pola elementarne 1



Numer faktury



Nazwa odbiorcy



NIP odbiorcy



Adres odbiorcy



Data sprzedaży



Sposób płatności



Nazwa towaru



Ilość



Cena netto



Wartość netto



Stawka VAT

•

Miejscowość
odbiorcy

•

Ulica odbiorcy

•

Kod odbiorcy

Nie można uzyskać z bazy
danych części wartości
pola. W tym przykładzie,
po rozbiciu adresu na pola
miejscowość, ulicę i kod,
będzie można uzyskać na
przykład spis miejscowości
odbiorców, ale nie będzie
można uzyskać numerów
ulic odbiorców, bo na
numer ulicy nie jest
przewidziane oddzielne
pole.

04/10/21

6

Pola elementarne 2



Numer faktury



Nazwa odbiorcy



NIP odbiorcy



Adres odbiorcy



Data sprzedaży



Sposób płatności



Nazwa towaru



Ilość



Cena netto



Wartość netto



Stawka VAT



Nie warto trzymać w tabeli
pola, których wartość
można wyliczyć z innych
pól na przykład wartość
całej faktury można
wyliczyć jako sumę cen
wszystkich pozycji faktury.

04/10/21

7

Pierwsza postać normalna tabeli

Faktura

04/10/21

8

Pierwsza postać normalna tabeli

Faktura

Kliknij, by
zobaczyć tabelkę w
Excel

NumerFaktury

NazwaOdbiorcy

NIPOdbiorcy

MiejscowoscOdbiorcy

FK/00001/2001

Henio Sp. z o.o.

526-21-78-150 Warszawa

FK/00001/2001

Henio Sp. z o.o.

526-21-78-150 Warszawa

FK/00002/2001

GAZBUD S.A.

526-21-78-541 Łódź

FK/00003/2001

Henio Sp. z o.o.

526-21-78-150 Warszawa

UlicaOdbiorcy

KodOdbiorcy

DataSprzedaży

SposobPlatnosci

ul. Modelowa 10

02-589

2001-11-10 Gotówka

ul. Modelowa 10

02-589

2001-11-10 Gotówka

Al. Testowa 2

05-202

2001-11-12 Przelew

ul. Modelowa 10

02-589

2001-11-13 Gotówka

NazwaTowaru

Ilosc CenaNetto

StawkaVat

Papier toal. Różowy op.

10

6,50

7%

Mydło szt.

20

1,30

7%

Mydło szt.

1000

1,21

7%

Papier toal. Różowy op.

10

6,50

7%

04/10/21

9

Klucze



Kluczem nazywamy minimalny zbiór pól, które

jednoznacznie identyfikują wszystkie rekordy w

tabeli.



Kluczem prostym nazywamy klucz składający

się z jednego pola.



Kluczem złożonym nazywamy klucz

składający się z więcej niż jednego pola.

04/10/21

10

Przykłady kluczy



Imię, nazwisko, imię ojca, imię matki, nazwisko rodowe matki,

data urodzenia, miejsce urodzenia – klucz złożony

identyfikujący osobę.



NIP – klucz prosty identyfikujący podatnika.



Numer albumu – klucz prosty identyfikujący studenta.

Numer PESEL niestety nie jest
unikalny, co okazało się podczas
wprowadzania reformy
emerytalnej.

04/10/21

11

Klucz

główny



Zdarza się, że w tabeli istnieje wiele kluczy.

Nazywamy je kluczami potencjalnymi.



Kluczem głównym (primary key) nazywamy

wybrany klucz potencjalny, którym będziemy

posługiwać się do identyfikacji rekordów.



Kluczami drugorzędnymi (secondary key)

nazywamy pozostałe klucze potencjalne.

04/10/21

12

Które pole(-a) są kluczem?

Numer faktury Nazwa odbiorcy Data sprzedaży Sposób płatności Nazwa towaru Ilość Cena netto Stawka VAT
1/2000

Bultek Sp. Z o. O.

2000-11-09 gotówka

ziemniaki

10

2

22%

1/2000

Bultek Sp. Z o. O.

2000-11-09 gotówka

kapusta

10

2

22%

1/2000

Bultek Sp. Z o. O.

2000-11-09 gotówka

ogórki

10

2

22%

1/2002

Bultek Sp. Z o. O.

2000-11-09 gotówka

ziemniaki

10

2

22%

1/2002

Bultek Sp. Z o. O.

2000-11-09 gotówka

kapusta

10

2

22%



Kluczem jest(są) te pole(-a), które są unikalne

w podanej tabeli, czyli w żadnym innym

wierszu nie ma takiego(-ich) samego(-ych)



Numer faktury, Ilość?



Cena netto?



Numer faktury, sposób płatności?



Stawka VAT, nazwa towaru?



Nazwa towaru, numer faktury?



Ilość, cena netto



Data sprzedaży, nazwa towaru?

04/10/21

13

Klucz główny w tabeli Faktura

Pole ‘Numer faktury’ i ‘Nazwa
towaru’ jednoznacznie identyfikują
każdy rekord w tabeli faktura.
Zakładamy przy tym, że na jednej
fakturze nie można umieścić dwóch
pozycji z tym samym towarem.

04/10/21

14

Zależność funkcjonalna

Pole B tabeli jest funkcjonalnie zależne od

pola A, jeśli dowolnej wartości pola A

odpowiada nie więcej niż jedna wartość pola B.

Mówimy, że A identyfikuje B.

A

B

Wyobraźmy sobie tabele z
polami ‘Numer albumu’,
‘Nazwisko’ i ‘Ocena’. Pole
‘Nazwisko’ jest funkcjonalnie
zależne od pola ‘Numer albumu’
– wielu studentów nie może
posiadać albumu o tym samym
numerze. Ale pole ‘Ocena’ nie
jest już funkcjonalnie zależne od
pola ‘Numer albumu’ – jeden
student ma zazwyczaj więcej niż
jedną ocenę.

04/10/21

15

Zależność funkcjonalna pól tabeli

Faktura

04/10/21

16

Zależność funkcjonalna pól tabeli

Faktura



NumerFaktury identyfikuje:



DataSprzedazy



SposobPlatnosci



NIPOdbiorcy



NIPOdbiorcy identyfikuje:



NazwaOdbiorcy



MiejscowoscOdbiorcy



UlicaOdbiorcy



KodOdbiorcy



NazwaTowaru identyfikuje:



StawkaVAT



NumerFaktury i NazwaTowaru identyfikują:



Ilosc



CenaNetto

04/10/21

17

Definicja: Druga postać normalna

Tabela jest w drugiej postaci normalnej, jeżeli

każde pole tabeli nie wchodzące w skład klucza

jest funkcjonalnie zależne od wszystkich pól

klucza, a nie ich części.

Z definicji wynika, że jeśli tabela w
pierwszej postaci normalnej ma
klucz prosty, to tabela jest od razu
w drugiej postaci normalnej.

Jeśli pole tabeli jest zależne od
części pól klucza tabeli, to pole to
wraz z częścią klucza staje się
odrębna tabelą.

04/10/21

18

Druga postać normalna tabeli

Faktura

04/10/21

19

Definicja: Trzecia postać normalna

Tabela jest w trzeciej postaci normalnej jeśli

każde pole nie wchodzące w skład klucza nie

jest funkcjonalnie zależne od innego pola nie

wchodzącego w skład klucza.

A

B

C

A

B

B

C

04/10/21

20

Normalizacja tabeli Faktura do

trzeciej postaci

Pola ‘NazwaOdbiorcy’,’MiejscowoscOdbiorcy’, ‘UlicaOdbiorcy’ i

‘KodOdbiorcy’ są funkcjonalnie zależne od pola ‘NIPOdbiorcy’, które nie

wchodzi w skład klucza.

04/10/21

21

Trzecia postać normalna tabeli

Faktura

Tabela Faktura w wyniku
normalizacji została
podzielona na cztery
tabele, które spełniają
definicję pierwszej, drugiej
i trzeciej postaci
normalnej.

04/10/21

22

Relacja



Relacją nazywamy związek tych samych pól w tabelach na

przykład pola Faktura.NIPOdbiorcy z Odbiorcy.NIPOdbiorcy



Relacja typu 1 do  (nieskończoności) oznacza, że dla 1 rekordu

w tabeli Odbiorcy o określonej wartości w polu

Odbiorcy.NIPObiorcy, może wystąpić nieskończenie wiele

rekordów w tabeli Faktura o takiej samej wartości w polu

Faktura.NIPObiorcy



Tabelę Odbiorcy nazywamy tabelą główną (ang. master,

parent), a tabelę Faktura tabelą szczegółową (ang. detail,

child)



Pole w tabeli szczegółowej, które łączy się z kluczem w tabeli

głównej, nazywamy kluczem obcym (foreign key)

04/10/21

23

Diagram relacji

04/10/21

24

Dane w tabeli Faktura

04/10/21

25

Wielowartościowa zależność

funkcjonalna

Pole B jest wielowartościowo funkcjonalnie

zależne od pola A w tej samej tabeli, jeśli

dowolne dwa rekordy, w których wartości w

polu A są równe, po zamianie wartości w polu B

będą również należeć do tabeli.

Wielowartościowa zależność funkcjonalna
występuje w tabeli z co najmniej trzema polami
A, B, C, gdzie dla każdej wartości A istnieje
dobrze zdefiniowany zestaw wartości B i
oddzielnie istnieje dobrze zdefiniowany zestaw
wartości C, jednak zestaw wartości B jest
niezależny od zestawu wartości C.

04/10/21

26

Przykład wielowartościowej

zależności funkcjonalnej

Nazwisko

Telefon Mail

Kowalski

5462289 [e-mail]

Kowalski

5462290 [e-mail]

Kowalski

5462291 [e-mail]

Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]
Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]

Nazwisko

Telefon Mail

Kowalski

5462289 [e-mail]

Kowalski

5462290 [e-mail]

Kowalski

5462291 [e-mail]

Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]
Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]

W tabeli zapisane są osoby w polu
‘Nazwisko’, każda osoba może mieć kilka
telefonów w polu ‘Telefon’ i adresów
poczty w polu ‘Mail’. Widać, że dwa
wybrane rekordy pana Miauczyńskiego po
zamianie numeru telefonu także znajdują
się w tabeli. Zestawy wartości w polach
‘Telefon’ i ‘Mail’ są dobrze określone dla
wartości w polu ‘Nazwisko’, ale są
niezależne od siebie.

04/10/21

27

Trywialna wielowartościowa

zależność funkcjonalna

Dla tabel składających się z dwóch pól A i B,

jeśli pole A jest wielowartościowo

funkcjonalnie zależne od pola B, to pole B

jest wielowartościowo funkcjonalnie zależne

od pola A. Zależność taką nazywamy

trywialną wielowartościową zależnością

funkcjonalną.

04/10/21

28

Definicja: Czwarta postać normalna

Tabela jest w czwartej postaci normalnej jeśli

zawiera co najwyżej jedną trywialną

wielowartościową zależność funkcjonalną.

Z definicji wynika, że tabele,
które mają więcej niż jedną
wielowartościową zależność
funkcjonalną, muszą ulec
podzieleniu w ten sposób, by
zawierały tylko zależności
trywialne.

04/10/21

29

Przykład normalizacji tabeli do

czwartej postaci

Nazwisko

Telefon Mail

Kowalski

5462289 [e-mail]

Kowalski

5462290 [e-mail]

Kowalski

5462291 [e-mail]

Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]
Miauczyński 3568750 [e-mail]
Miauczyński 3568751 [e-mail]

Nazwisko

Telefon

Kowalski

5462289

Kowalski

5462290

Kowalski

5462291

Miauczyński 3568750
Miauczyński 3568751

Nazwisko

Mail

Kowalski

[e-mail]

Miauczyński [e-mail]
Miauczyński [e-mail]