piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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ń

piotr_druciak@poczta.onet.pl

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).

piotr_druciak@poczta.onet.pl

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)

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

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

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)

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

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

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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).

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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 „@”.

piotr_druciak@poczta.onet.pl

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 „@”.

piotr_druciak@poczta.onet.pl

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),

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

Tabela Ksiazki:

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

Atrybut RokWydania (4 cyfry),

piotr_druciak@poczta.onet.pl

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),

piotr_druciak@poczta.onet.pl

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),

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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…

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Dodajemy nowe rekordy do tabeli Ksiazki.

piotr_druciak@poczta.onet.pl

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?

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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)

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

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

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

5. Usuwanie anomalii – normalizacja bazy danych.

Druga postać normalna 2NF.

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

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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:

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

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

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.

piotr_druciak@poczta.onet.pl

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!

piotr_druciak@poczta.onet.pl

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.

piotr_druciak@poczta.onet.pl

Bazy danych

Projektowanie bazy danych

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

5. Usuwanie anomalii – normalizacja bazy danych.

Trzecia postać normalna 3NF.