[e-mail]

1

Bazy danych

Projektowanie bazy danych

Etapy projektowania:

1. Określenie projektowanego zagadnienia, założenia wstępne.

2. Określenie tabel (relacji) opisujących obiekty projektowanej

rzeczywistości (encje).

3. Określenie zestawu pól w tabelach opisujących encję.

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

5. Usuwanie anomalii – normalizacja bazy danych.

6. Implementacja bazy danych w systemie bazodanowym.

[e-mail]

2

Bazy danych

Projektowanie bazy danych

1. Określenie projektowanego zagadnienia, założenia wstępne.

Celem naszego projektu będzie zrealizowanie modelu bazy danych dla biblioteki.

Baza danych powinna przechowywać informacje o:

-

Zarejestrowanych czytelnikach

-

Dostępnych w księgozbiorze pozycjach (książkach)

-

Wypożyczeniach książek przez czytelników

-

Historii wypożyczeń

[e-mail]

3

Bazy danych

Projektowanie bazy danych

2. Określenie tabel (relacji) opisujących obiekty projektowanej rzeczywistości (encje).

Na podstawie wstępnych założeń, możemy określić tabele, z których będzie się
składać nasza baza danych. Ponieważ potrzebujemy informacji o zarejestrowanych
czytelnikach, zdefiniujemy tabelę Czytelnicy, księgozbiór umieścimy w tabeli Ksiazki,
informacje o aktualnych wypożyczeniach będziemy przechowywać w tabeli
RejestrWypozyczen, a historię w tabeli HistoriaWypozyczen.

Wstępny projekt zakłada istnienie czterech tabel (Czytelnicy, Ksiazki,
RejestrWypozyczen, HistoriaWypozyczen). Najprawdopodobniej nie jest to ich
ostateczna ilość i z dużym prawdopodobieństwem możemy założyć, że będzie
ich jeszcze więcej, gdyż dodatkowe tabele pojawią się w procesie normalizacji bazy
danych, a więc usuwania anomalii i zbędnej nadmiarowości danych (redundancji).

[e-mail]

4

Bazy danych

Projektowanie bazy danych

3. Określenie zestawu pól w tabelach opisujących encję.

Stawiamy pytanie, jakich atrybutów potrzebujemy aby w pełni opisać dany obiekt
rzeczywistości (encję), jakiego typu mają to być atrybuty i określamy klucz główny
jednoznacznie identyfikujący wiersz w tabeli.

Tabela: Czytelnicy

Atrybuty:
-

ID_Czytelnika

(typ UID)

PK – Primary Key (Klucz główny)

-

Imie

(typ Tekst)

-

Nazwisko

(typ Tekst)

-

DataUrodzenia

(typ Data/Godzina)

-

PESEL

(typ Tekst)

-

AdresZamieszkania

(typ Tekst)

-

Telefon

(typ Tekst)

-

Email

(typ Tekst)

[e-mail]

5

Bazy danych

Projektowanie bazy danych

3. Określenie zestawu pól w tabelach opisujących encję.

Stawiamy pytanie, jakich atrybutów potrzebujemy aby w pełni opisać dany obiekt
rzeczywistości (encję), jakiego typu mają to być atrybuty i określamy klucz główny
jednoznacznie identyfikujący wiersz w tabeli.

Tabela: Ksiazki

Atrybuty:
-

ISBN

(typ Tekst)

PK – Primary Key (Klucz główny)

-

Tytul

(typ Tekst)

-

Autor

(typ Tekst)

-

RokWydania

(typ Liczba)

-

RodzajGatunku

(typ Tekst)

-

OpisGatunku

(typ Nota)

[e-mail]

6

Bazy danych

Projektowanie bazy danych

3. Określenie zestawu pól w tabelach opisujących encję.

Stawiamy pytanie, jakich atrybutów potrzebujemy aby w pełni opisać dany obiekt
rzeczywistości (encję), jakiego typu mają to być atrybuty i określamy klucz główny
jednoznacznie identyfikujący wiersz w tabeli.

Tabela: RejestrWypozyczen

Atrybuty:
-

ID_Czytelnika

(typ UID)

FK – Foreign Key (Klucz obcy)

-

ISBN

(typ Tekst)

FK – Foreign Key (Klucz obcy)

-

DataWypozyczenia

(typ Data/Godzina)

-

DataZwrotu

(typ Data/Godzina)

W powyższej tabeli klucz główny PK (Primary Key) będzie złożony z dwóch
kluczy obcych FK (Foreign Key), będących kluczami głównymi w tabelach
Czytelnicy oraz Ksiazki.

[e-mail]

7

Bazy danych

Projektowanie bazy danych

3. Określenie zestawu pól w tabelach opisujących encję.

Tabela HistoriaWypozyczen będzie analogiczna do tabeli RejestrWypozyczen,
w chwili oddania książki rekord z tabeli RejestrWypozyczen będzie automatycznie
przenoszony do tabeli HistoriaWypozyczen.

Tabela: HistoriaWypozyczen

Atrybuty:
-

ID_Czytelnika

(typ UID)

FK – Foreign Key (Klucz obcy)

-

ISBN

(typ Tekst)

FK – Foreign Key (Klucz obcy)

-

DataWypozyczenia

(typ Data/Godzina)

-

DataZwrotu

(typ Data/Godzina)

W powyższej tabeli klucz główny PK (Primary Key) będzie złożony z dwóch
kluczy obcych FK (Foreign Key), będących kluczami głównymi w tabelach
Czytelnicy oraz Ksiazki.

[e-mail]

8

Bazy danych

Projektowanie bazy danych

Utwórzmy teraz w programie MS Access, pustą bazę danych, nazwijmy ją
Biblioteka i dodajmy do niej w widoku projektu cztery tabele, które opisaliśmy
na poprzednich slajdach.

Utworzenie tabeli Czytelnicy:

1 – Nie zapominamy o ustawieniu klucza głównego (podstawowego).

[e-mail]

9

Bazy danych

Projektowanie bazy danych

Utworzenie tabeli Ksiazki :

[e-mail]

10

Bazy danych

Projektowanie bazy danych

Utworzenie tabeli RejestrWypozyczen:

1 – Klucz główny będzie się składał z dwóch atrybutów będących kluczami
obcymi, są to klucze główne z tabel Czytelnicy oraz Ksiazki.

[e-mail]

11

Bazy danych

Projektowanie bazy danych

Utworzenie tabeli HistoriaWypozyczen:

Możemy tą tabelę utworzyć analogicznie jak RejestrWypozyczen, możemy
ją również skopiować na jej wzór.

[e-mail]

12

Bazy danych

Projektowanie bazy danych

Ćwiczenie:
Do utworzonych przez Nas tabel, dodajmy maski wprowadzania danych
oraz reguły sprawdzające poprawność wprowadzonych danych.

W tabeli Czytelnicy dodajmy maskę wprowadzania dla następujących atrybutów:

-

Imie (maksymalny rozmiar to 20 znaków, rozpoczyna się z dużej litery),

-

Nazwisko (maksymalny rozmiar to 30 znaków, rozpoczyna się z dużej litery),

-

DataUrodzenia (format DD-MM-RRRR),

-

PESEL (11 cyfr, skrót od nazwy Powszechny Elektroniczny System Ewidencji

Ludności),

Dla atrybutu Email dodajmy regułę poprawności, sprawdzającą czy w nazwie
adresu podaliśmy znak „@”.

[e-mail]

13

Bazy danych

Projektowanie bazy danych

Tabela Czytelnicy:

Atrybut Imie (maksymalny rozmiar to 20 znaków, rozpoczyna się z dużej litery)

Atrybut Nazwisko (maksymalny rozmiar to 30 znaków, rozpoczyna się z dużej litery)

Atrybut DataUrodzenia (format DD-MM-RRRR)

Atrybut PESEL (11 cyfr)

Atrybut Email reguła poprawności, sprawdzająca czy w nazwie adresu jest znak „@”.

[e-mail]

14

Bazy danych

Projektowanie bazy danych

Ćwiczenie:
Do utworzonych przez Nas tabel, dodajmy maski wprowadzania danych
oraz reguły sprawdzające poprawność wprowadzonych danych.

W tabeli Ksiazki dodajmy maskę wprowadzania dla następujących atrybutów:

-

ISBN ( ang. International Standard Book Number,

10 cyfr obowiązkowo + dodatkowo 3 cyfry, które wprowadzono od 2007 r.),

-

RokWydania (4 cyfry),

[e-mail]

15

Bazy danych

Projektowanie bazy danych

Tabela Ksiazki:

Atrybut ISBN (10 cyfr obowiązkowo + dodatkowo 3 cyfry)

Atrybut RokWydania (4 cyfry),

[e-mail]

16

Bazy danych

Projektowanie bazy danych

Ćwiczenie:
Do utworzonych przez Nas tabel, dodajmy maski wprowadzania danych
oraz reguły sprawdzające poprawność wprowadzonych danych.

W tabeli RejestrWypozyczen i HistoriaWypozyczen dodajmy maskę wprowadzania
dla następujących atrybutów:

-

ISBN ( ang. International Standard Book Number,

10 cyfr obowiązkowo + dodatkowo 3 cyfry, które wprowadzono od 2007 r.),

-

DataWypozyczenia (format DD-MM-RRRR),

-

DataZwrotu (format DD-MM-RRRR),

[e-mail]

17

Bazy danych

Projektowanie bazy danych

Tabele RejestrWypozyczen i HistoriaWypozyczen:

Atrybut ISBN (10 cyfr obowiązkowo + dodatkowo 3 cyfry)

Atrybut DataWypozyczenia (format DD-MM-RRRR),

Atrybut DataZwrotu (format DD-MM-RRRR),

[e-mail]

18

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Rozróżniamy następujące rodzaje połączeń między tablicami:

Złączenie „jeden do jeden”

Jednemu wierszowi z tabeli pierwszej odpowiada dokładnie jeden wiersz
z tabeli drugiej. W praktyce występuje wtedy, gdy rekord z jednej tabeli
jest rozszerzeniem drugiej, np. tabela katalogowa produktów zawiera ogólne
informacje takie jak cena, dostępna ilość, a druga tabela zawiera szczegółowe
informacje na temat poszczególnych produktów.

[e-mail]

19

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Złączenie „jeden do wielu”

Jednemu wierszowi z tabeli pierwszej może odpowiadać wiele wierszy
z tabeli drugiej. W relacyjnych bazach danych takie połączenie występuje
najczęściej, np. jeden czytelnik może wypożyczyć wiele książek.

[e-mail]

20

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Złączenie „wiele do wielu”

Wielu wierszom z tabeli pierwszej może odpowiadać wiele wierszy z tabeli drugiej,
np. wielu klientów może kupić wiele produktów.
Połączenie „wiele do wielu” zamienia się na dwa połączenie typu „jeden do wielu”,
poprzez wprowadzenie dodatkowej tabeli pośredniej.

[e-mail]

21

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Rozbicie złączenia „wiele do wielu” na dwa złączenia typu „jeden do wielu”,
poprzez wprowadzenie dodatkowej tabeli pośredniej.

[e-mail]

22

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Diagram ERD naszego modelu bazy danych biblioteki, będzie wyglądał następująco:

[e-mail]

23

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Diagramu ERD naszego modelu bazy danych biblioteki, czytamy następująco:

Jeden czytelnik może wypożyczyć kilka książek (połączenie „jeden do wielu” tabeli
Czytelnicy z tabelą RejestrWypozyczen).

Każda książka jest unikalna (ze względu na ISBN), wobec czego jedna książka
może być w danym momencie wypożyczona tylko przez jednego czytelnika
(połączenie „jeden do jeden” tabeli Ksiazki z tabelą RejestrWypozyczen).

Historycznie jeden czytelnik mógł wypożyczyć wiele książek, a jedna książka
mogła być wypożyczona przez wielu czytelników (wielu czytelników mogło
wypożyczyć wiele książek). Mamy tu relację „wiele do wielu”, którą rozbija
wprowadzenie tabeli pośredniej HistoriaWypozyczen.

[e-mail]

24

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Na podstawie diagramu ERD utwórzmy teraz relacje pomiędzy naszymi tabelami
w programie MS Access.

1 – Uruchamiamy kreator
relacji z paska
narzędziowego lub z menu
Narzędzia\Relacje…

[e-mail]

25

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Dodajemy kolejno wszystkie tabele:

[e-mail]

26

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Klikając i przytrzymując lewy przycisk myszy na ID_Czytelnika w tabeli Czytelnicy
przesuwamy kursor na ID_Czytelnika w tabeli RejestrWypozyczen. Zostanie
wyświetlony poniższy dialog „Edytowanie relacji”.

1 – Zaznaczamy opcje „Wymuszaj więzy
integralności” oraz kaskadowe
aktualizowanie i usuwanie rekordów.
W ten sposób zapewnimy, że rekordy
pojawiające się w tabeli
RejestrWypozyczen będą miały
odpowiadający im rekord w tabeli
Czytelnicy, a usunięcie jakiegoś rekordu
z tabeli Czytelnicy spowoduje usunięcie
wszystkich powiązanych rekordów
z tabeli RejestrWypozyczen.

[e-mail]

27

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Analogiczne złączenia (jeden do wielu) wykonujemy pomiędzy tabelami:
Czytelnicy–HistoriaWypozyczen po kluczu ID_Czytelnika,
Ksiazki–HistoriaWypozyczen po kluczu ISBN.

Złączenie pomiędzy tabelami Ksiazki–RejestrWypozyczen po kluczu ISBN,
będzie złączeniem typu „jeden do jeden”. Aby wymusić taki typ złączenia,
otwórzmy tabelę RejestrWypozyczen w widoku projektu i ustawmy następujące
właściwości dla pola ISBN:

[e-mail]

28

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Teraz tworząc złączenie pomiędzy tabelami Ksiazki–RejestrWypozyczen
po kluczu ISBN zostanie wyświetlony następujący dialog:

Zaznaczamy opcje „Wymuszaj więzy integralności” oraz kaskadowe aktualizowanie
i usuwanie rekordów.

[e-mail]

29

Bazy danych

Projektowanie bazy danych

4. Wykonanie diagramu ERD (ang. Entity Relationship Diagram), określającego

zależności między encjami.

Po utworzeniu wszystkich relacji, otrzymamy:

[e-mail]

30

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Anomalie, czyli niespójności i błędy w danych, powodujące często nie uzasadniony
rozrost i błędne działanie systemu bazodanowego, powstają gdy umieszczamy
w jednej tabeli zbyt dużo danych, często nadmiarowych. Zjawisko to nosi nazwę
redundancji – nadmiarowości danych.

W celu przeciwdziałania anomaliom, stosujemy normalizację bazy danych, mającą
na celu pozbycie się nadmiarowych danych. Normalizacja nie usuwa danych, tylko
zmienia schemat bazy danych. Proces normalizacji polega na sprowadzaniu bazy
danych do kolejnych postaci normalnych (ang. normal forms NF).
Twórcą normalizacji jest Edgar Frank Codd, który początkowo wymyślił trzy postacie
normalne: 1NF, 2NF, 3NF. Obecnie istnieją jeszcze trzy kolejne, ale przyjmuje się,
że trzecia postać normalna (3NF) jest już wystarczająca dla większości projektów.

[e-mail]

31

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Omówienie procesu normalizacji i kolejnych postaci normalnych zrealizujemy
na przykładzie naszej bazy danych dla biblioteki.
W tym celu dodajmy do naszej bazy kilka nowych rekordów, zarówno do tabeli
Czytelnicy jak i Ksiazki.

[e-mail]

32

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Dodajemy nowe rekordy do tabeli Ksiazki.

[e-mail]

33

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Pierwsza postać normalna 1NF.

Przeanalizujmy teraz nasze tabele pod kątem pierwszej postaci normalnej 1NF, która
mówi, że wszystkie atrybuty (kolumny) powinny zawierać wartości atomowe
(niepodzielne) oraz nie powinny się pojawiać grupy kolumn dotyczące tego samego
atrybutu, np. Adres1, Adres2, Adres3.
Jeżeli założymy, że atrybut Autor w tabeli Ksiazki jest niepodzielny i zawsze
będziemy się posługiwać jednocześnie imieniem i nazwiskiem autora, to nie musimy
rozbijać tego pola na ImieAutora i NazwiskoAutora. Tabela Ksiazki jest w pierwszej
postaci normalnej.

Czy to samo możemy powiedzieć o tabeli Czytelnicy?

[e-mail]

34

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Pierwsza postać normalna 1NF.

Widzimy, że o ile atrybuty takie jak Imie, Nazwisko, DataUrodzenia, Pesel, Telefon,
Email spełniają kryteria pierwszej postaci normalnej, o tyle atrybut AdresZamieszkania
już niekoniecznie. Choć podobnie jak w przypadku Autora z tabeli Ksiazki, również
w tym przypadku moglibyśmy założyć, że zawsze będziemy się posługiwać tylko
całym adresem, nigdy samą ulicą, czy miejscowością i potraktować to pole jako
atomowe. My jednak rozbijemy je na mniejsze i podzielimy atrybut AdresZamieszkania
na następujące atrybuty: Ulica, NumerDomu, NumerMieszkania, KodPocztowy,
Miejscowosc.
Ze względów dydaktycznych zrobimy to w następnym kroku, po poznaniu drugiej
postaci normalnej 2NF, w tym momencie potraktujmy atrybut AdresZamieszkania
jako niepodzielny.

[e-mail]

35

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Przejście do kolejnej postaci normalnej wymaga, aby tabela spełniała kryteria
poprzedniej postaci normalnej, czyli aby przejść do 2NF tabela musi być w 1NF, etc.

Druga postać normalna 2NF wymaga, aby każda kolumna była w pełni zależna od
klucza głównego, co oznacza że kolumny nie wchodzące w skład klucza są
jednoznacznie identyfikowane przez klucz główny.

Przyjrzyjmy się tabeli Czytelnicy:

[e-mail]

36

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Widzimy, że atrybut AdresZamieszkania nie jest w pełni zależny od klucza i powtarza
się dla osób mieszkających w tym samym domu. Zróbmy więc dodatkową tabelę
zawierającą adresy zamieszkania.

[e-mail]

37

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Tworzymy nową tabelę w widoku projektu, jak przedstawiono poniżej:

Dodajmy jeszcze maski wprowadzania.

[e-mail]

38

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Atrybut KodPocztowy (obowiązkowo 5 cyfr oddzielonych pauzą)

Atrybut Ulica (maksymalny rozmiar to 30 znaków, rozpoczyna się z dużej litery)

Atrybut Miejscowosc (maksymalny rozmiar to 30 znaków, rozpoczyna się z dużej litery)

[e-mail]

39

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Przepisujemy do tabeli AdresyZamieszkania adresy z tabeli Czytelnicy:

Zmieniamy nazwę atrybutu AdresZamieszkania w tabeli Czytelnicy na
ID_AdresZamieszkania i wpisujemy wartości klucza obcego.

[e-mail]

40

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

W widoku projektu zmieniamy typ atrybutu ID_AdresZamieszkania w tabeli Czytelnicy
na typ Liczba.

[e-mail]

41

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Uaktualniamy relacje, dodając do nich tabelę AdresyZamieszkania:

[e-mail]

42

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Przyjrzyjmy się teraz tabeli Ksiazki:

Widzimy, że dwa zależne od siebie atrybuty RodzajGatunku, OpisGatunku są
niezależne od klucza głównego, a więc tabela ta nie jest w drugiej postaci normalnej.

Przenieśmy je do osobnej tabeli tak jak zrobiliśmy to z adresami zamieszkania,
nazwijmy ją GatunekKsiazki.

[e-mail]

43

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Tworzymy nową tabelę w widoku projektu, jak przedstawiono poniżej:

[e-mail]

44

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Kopiujemy do tabeli GatunekKsiazki interesujące Nas wartości z tabeli Ksiazki:

Zmieniamy nazwę atrybutu RodzajGatunku w tabeli Ksiazki na ID_GatunekKsiazki,
kasujemy atrybut OpisGatunku i wpisujemy wartości klucza obcego.

[e-mail]

45

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

W widoku projektu zmieniamy typ atrybutu ID_GatunekKsiazki w tabeli Ksiazki
na typ Liczba.

[e-mail]

46

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Uaktualniamy relacje, dodając do nich tabelę GatunekKsiazki:

[e-mail]

47

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

Idąc dalej kryteriami drugiej postaci normalnej, powinniśmy:

- przenieść atrybuty KodPocztowy oraz Miejscowosc z tabeli AdresZamieszkania

do tabeli KodyPocztowe

- przenieść atrybut Autor z tabeli Ksiazki do tabeli Autorzy

Wydaje się także, że wszystkie inne atrybuty zawierające powtarzające się wartości
takie jak Imie, Nazwisko, Ulica, etc. powinny się znaleźć w osobnych tabelach.
Nie powinniśmy jednak popadać w skrajność, gdyż doprowadziłoby to do sytuacji,
gdzie mielibyśmy bardzo dużo tabel, zawierających klucz główny i tylko jeden atrybut
niekluczowy. Sytuacja taka mogłaby być dla Nas niekorzystna ze względu na duże
rozproszenie bazy (wiele małych tabel), oraz spadek wydajności podczas tworzenia
kwerend i zapytań SQL-owych.

[e-mail]

48

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

Jeżeli wszystkie tabele mielibyśmy sprowadzone do drugiej postaci normalnej (2NF),
moglibyśmy przejść do trzeciej postaci normalnej (3NF).

Trzecia postać normalna 3NF wymaga, aby każda kolumna była w pełni zależna od
klucza głównego i niezależna od innych kolumn. Co oznacza że zmiana wartości
w jakiejś kolumnie niekluczowej, nie pociąga za sobą zmian w innych kolumnach.

Przyjrzyjmy się tabeli Ksiazki:

[e-mail]

49

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

Zmiana tytułu książki, często będzie powodowała również zmianę jej autora.
Przenieśmy wobec czego atrybut Autor z tabeli Ksiazki do tabeli Autorzy.

Tworzymy nową tabelę w widoku projektu, jak przedstawiono poniżej:

[e-mail]

50

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

Kopiujemy do tabeli Autorzy autorów z tabeli Ksiazki:

Zmieniamy nazwę atrybutu Autor w tabeli Ksiazki na ID_Autora i wpisujemy wartości
klucza obcego.

[e-mail]

51

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

W widoku projektu zmieniamy typ atrybutu ID_Autora w tabeli Ksiazki na typ Liczba.

[e-mail]

52

Bazy danych

Projektowanie bazy danych

Uaktualniamy relacje, dodając do nich tabelę Autorzy:

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

[e-mail]

53

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

Na zakończenie przenieśmy atrybuty KodPocztowy oraz Miejscowosc z tabeli
AdresZamieszkania do tabeli KodyPocztowe.

Tworzymy nową tabelę w widoku projektu, jak przedstawiono poniżej:

Nie zapomnijmy o skopiowaniu rozmiaru pól i masek wprowadzania!

[e-mail]

54

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

Kopiujemy do tabeli KodyPocztowe kody pocztowe z tabeli AdresZamieszkania :

Zmieniamy nazwę atrybutu KodPocztowy w tabeli AdresZamieszkania na
ID_KoduPocztowego, zmieniamy jego typ na liczbę, usuwamy maskę wprowadzania,
kasujemy atrybut Miejscowosc i wpisujemy wartości klucza obcego.

[e-mail]

55

Bazy danych

Projektowanie bazy danych

Uaktualniamy relacje, dodając do nich tabelę KodyPocztowe:

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.