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] 1
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] 2
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] 3
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] 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: 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] 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: 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] 6
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] 7
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] 8
Bazy danych
Projektowanie bazy danych
Utworzenie tabeli Ksiazki :
[e-mail] 9
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] 10
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] 11
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] 12
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] 13
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] 14
Bazy danych
Projektowanie bazy danych
Tabela Ksiazki:
Atrybut ISBN (10 cyfr obowiązkowo + dodatkowo 3 cyfry)
Atrybut RokWydania (4 cyfry),
[e-mail] 15
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] 16
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] 17
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] 18
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] 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  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] 20
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] 21
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] 22
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] 23
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] 24
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] 25
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] 26
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] 27
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] 28
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] 29
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] 30
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] 31
Bazy danych
Projektowanie bazy danych
5. Usuwanie anomalii  normalizacja bazy danych.
Dodajemy nowe rekordy do tabeli Ksiazki.
[e-mail] 32
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] 33
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] 34
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] 35
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] 36
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] 37
Bazy danych
Projektowanie bazy danych
5. Usuwanie anomalii  normalizacja bazy danych.
Druga postać normalna 2NF.
Atrybut Ulica (maksymalny rozmiar to 30 znaków, rozpoczyna się z du\
ej litery)
Atrybut KodPocztowy (obowiązkowo 5 cyfr oddzielonych pauzą)
Atrybut Miejscowosc (maksymalny rozmiar to 30 znaków, rozpoczyna się z du\
ej litery)
[e-mail] 38
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] 39
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] 40
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] 41
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] 42
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] 43
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] 44
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] 45
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] 46
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ę znalez
ć 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] 47
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] 48
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] 49
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] 50
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] 51
Bazy danych
Projektowanie bazy danych
5. Usuwanie anomalii  normalizacja bazy danych.
Trzecia postać normalna 3NF.
Uaktualniamy relacje, dodając do nich tabelę Autorzy:
[e-mail] 52
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] 53
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] 54
Bazy danych
Projektowanie bazy danych
5. Usuwanie anomalii  normalizacja bazy danych.
Trzecia postać normalna 3NF.
Uaktualniamy relacje, dodając do nich tabelę KodyPocztowe:
[e-mail] 55