Nr książki Nr czytelnika Dostępność książki Autor Tytuł Temat

Zajęcia 1.
Przykład 1: biblioteka.
Aby zaprojektować bazę danych trzeba dobrze przyjrzeć się potrzebom jej przyszłej użytkowników,
odwiedzić, oglądnąć, przemyśleć. W bazie będą gromadzone dane. Wiele z tych danych ma charakter
oczywisty, niektóre zaś bardzo abstrakcyjny i trudno je zauważyć, choć biorą udział w procesach
podejmowania decyzji. Niektóre dane odnoszą się do konkretnych obiektów, inne zaś do zdarzeń,
które z natury rzeczy są mniej uświadamiane. Czasami trzeba przewidzieć również istnienie danych,
które w danym momencie nie są używane albo nawet potrzebne, ale które mogą być przydatne w
przyszłości. Jeśli baza danych jest tworzona na własne potrzeby proces budowy jest łatwiejszy. Jeśli
zaś użytkownikiem jest ktoś inny, powstaje problem odwzorowania jego wiedzy i potrzeb na projekt
wykonywany przez osobę drugą. W tym drugim przypadku duże znaczenie ma odpowiednio
działający problem komunikacji między tymi osobami.
W następnej tabeli zebrane są dane używane w bibliotece, które są przetwarzane przez bibliotekarza w
różnych fazach obsługi czytelnika.
Nr książki
Nr czytelnika
Dostępność książki
Autor
Tytuł
Temat
Wydawnictwo
Liczba egzemplarzy
Data wypożyczenia
Data zwrotu
Kara
Faktyczna data
zwrotu
UKD
Fizyczne miejsce w
bibliotece
Data wydania
Ilość stron
Typ oprawy
Liczba
wypożyczonych
przez czytelnika
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
Data zapisania
czytelnika do
biblioteki
Imię i nazwisko
czytelnika
adres
Data urodzenia
Kontakt do
czytelnika
Nr dowodu
tożsamości
Typ dowodu
tożsamości
Jak widać lista jest długa a dane mają niejednorodny charakter. Spróbujmy wyobrazić sobie sytuację,
w której bibliotekarz w przypadku wypożyczania za każdym razem, w przypadku każdej nowo
wypożyczanej książki wypełniałby taką tabelę.
W przypadku pierwszej książki tabela wyglądałaby tak:
Nr książki
Nr czytelnika
Dostępność książki
Autor
2303032
12345
tak
Sienkiewicz
Henryk
Tytuł
Potop
Temat
historyczna
Wydawnictwo
Prószyński
Liczba egzemplarzy 4
Data wypożyczenia 07.05.2009
Data zwrotu
07.06.2009
Kara
0
Faktyczna data
zwrotu
UKD
301.78
Fizyczne miejsce w 4 półki za filarem
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
bibliotece
Data wydania
Ilość stron
Typ oprawy
Liczba
wypożyczonych
przez czytelnika
Data zapisania
czytelnika do
biblioteki
Imię i nazwisko
czytelnika
adres
Data urodzenia
Kontakt do
czytelnika
Nr dowodu
tożsamości
Typ dowodu
tożsamości
2006
876
miękka
4
05.04.2000
Jan Kowalski
Ul. Rakowicka 27
31510 Kraków
01.02.1960
Email:
[email protected]
ABC678654
Dowód osobisty
wydany przez
prezydenta miasta
Krakowa
W przypadku następnej zaś tak:
Nr książki
Nr czytelnika
Dostępność książki
Autor
Tytuł
2303032
12345
tak
Sienkiewicz
Henryk
Potop
Temat
historyczna
345902
12345
tak
Sienkiewicz
Henryk
Ogniem i
mieczem
historyczna
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
Wydawnictwo
Liczba egzemplarzy
Data wypożyczenia
Data zwrotu
Kara
Faktyczna data
zwrotu
UKD
Fizyczne miejsce w
bibliotece
Data wydania
Ilość stron
Typ oprawy
Liczba
wypożyczonych
przez czytelnika
Data zapisania
czytelnika do
biblioteki
Imię i nazwisko
czytelnika
adres
Data urodzenia
Kontakt do
czytelnika
Nr dowodu
tożsamości
Typ dowodu
tożsamości
Prószyński
4
07.05.2009
07.06.2009
0
Iskry
3
07.05.2009
07.06.2009
0
301.78
301.78
4 półki za filarem 4 półki za filarem
2006
876
miękka
4
2005
643
miękka
5
05.04.2000
05.04.2000
Jan Kowalski
Jan Kowalski
Ul. Rakowicka 27
31510 Kraków
01.02.1960
Email:
[email protected]
ABC678654
Ul. Rakowicka 27
31510 Kraków
01.02.1960
Email:
[email protected]
ABC678654
Dowód osobisty
wydany przez
prezydenta miasta
Krakowa
Dowód osobisty
wydany przez
prezydenta miasta
Krakowa
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
Widać wiele patologii takiej metody obsługi danych. Dlatego po pierwsze należy rozdzielić dane na
tabele, z których każda zawiera wspólne problemowo dane. W ten sposób opisuje się obiekty.
W naszym przypadku takimi obiektami są: czytelnicy, egzemplarze książki, tytuły i wypożyczenia. O
ile dwa pierwsze obiekty są dosyć oczywiste, to już konieczność wydzielenia tytułów i wypożyczeń
budzi pewne zastrzeżenia.. Wydzielenie tytułów od egzemplarzy wynika z tego, że często w bibliotece
występuje więcej niż jeden egzemplarz danego tytułu. Tytuł ma więc charakter abstrakcyjny, a
egzemplarz – konkretny. Jeszcze ciekawsze jest wydzielenie tabeli wypożyczenia. Opisuje ona nie
obiekty (jak wcześniej - egzemplarze) albo nawet abstrakcyjne cechy obiektów (tytuły) ale czynność –
wypożyczenie.
ISBN
Autor
Tytuł
Temat
Wydawnictwo
Liczba
egzemplarzy
UKD
Fizyczne miejsce
w bibliotece
Data wydania
Ilość stron
Typ oprawy
Nr książki
Dostępność książki
Data wypożyczenia
Data zwrotu
Faktyczna data zwrotu
Data wypożyczenia
Nr książki
Nr czytelnika
Kara
Liczba
wypożyczonych przez
czytelnika
Data zapisania
czytelnika do
biblioteki
Imię
Nazwisko
ulica
Nr domu
miasto
Kod pocztowy
kraj
Data urodzenia
Kontakt do czytelnika
Nr dowodu tożsamości
Typ dowodu
tożsamości
Podzielenie danych na logicznie spójne tabele jest pierwszym krokiem. W kolejnym trzeba zadbać aby
każda tabela posiadała pole, które zapewni, że każdy kolejny wpis do niej będzie niepowtarzalny. Tego
typu pole nazywane jest kluczem własnym (podstawowym) tabeli. Czasem zdarza się, że nie jedno
pole ale dwa albo nawet kilka zapewnia niepowtarzalność rekordu w tabeli. Bywa jednak dosyć często
że trzeba je wymyślić. Tego typu pola już w niektórych powyższych tabelach istnieją. W innych
trzeba je dopiero dodać. Na przykład każde nowe wydanie książki opatrzone jest nowym numerem
ISBN (są książki nie posiadające ISBN...). W przypadku czytelnika takim kandydatem na klucz
podstawowy może być np. numer PESEL, ale co z obcokrajowami? Dlatego dobrym rozwiązaniem
będzie wymyślenie pola nowego – sztucznego i nazwanie go np. „numer czytelnika”, albo może
„ID_czytelnika”. Dla egzemplarza książki takim „sztucznym” polem może być „numer książki” albo
„ID_ksiazki”. Podobnie dla wypożyczenia „numer wypożyczenia” albo „ID_wypożyczenia”.
Kolejna tabela prezentuje rozwiązanie z zaznaczonymi na szaro polami – kluczami własnymi.
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
ISBN
Autor
Tytuł
Temat
Wydawnictwo
Liczba
egzemplarzy
UKD
Fizyczne miejsce
w bibliotece
Data wydania
Ilość stron
Typ oprawy
ID_ksiazki
Dostępność książki
ID_wypozyczenia
Data wypożyczenia
Data zwrotu
Faktyczna data zwrotu
Data wypożyczenia
Nr książki
ID_czytelnika
Kara
Liczba
wypożyczonych przez
czytelnika
Data zapisania
czytelnika do
biblioteki
Imię
Nazwisko
ulica
Nr domu
miasto
Kod pocztowy
kraj
Data urodzenia
Kontakt do czytelnika
Nr dowodu tożsamości
Typ dowodu
tożsamości
Kolejnym krokiem jest ustalenia typu relacji między tabelami. Istnieją teoretycznie następujące
sytuacje:
1) brak jest relacji (brak relacji)
2) jeden obiekt z pierwszej tabeli odpowiada wielu obiektom z drugiej tabeli ale konkretnemu
obiektowi z drugiej tabeli odpowiada jeden obiekt z pierwszej tabeli (relacja jeden do wielu)
3) jeden obiekt z pierwszej tabeli odpowiada wielu obiektom z drugiej tabeli ale konkretnemu
obiektowi z drugiej tabeli odpowiada wiele obiektów z pierwszej tabeli (relacja wiele do
wielu)
4) jednemu obiektowi z pierwszej tabeli odpowiada dokładnie jeden obiekt z drugiej tabeli i
każdemu obiektowi z drugiej tabeli odpowiada jeden obiekt z pierwszej tabeli (relacja jeden do
jednego).
W naszym przykładzie sytuacja pierwsza (brak relacji) istnieje np. między tabelami „egzemplarze” a
czytelnik. Nie ma żadnego bezpośredniego związku między nimi. Związek taki pojawia się jedynie za
pośrednictwem tabeli wypożyczenie.
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
Sytuacja druga (jeden do wielu) istnieje w przypadku związku tabeli „tytuły” i „egzemplarze”.
Jednemu tytułowi może odpowiadać kilka egzemplarzy tego tytułu (kilka, to znaczy, że jeden też, ale
możliwe, że więcej niż jeden). Ale dany egzemplarz książki nie może mieć więcej niż jeden tytuł –
zawsze jeden i tylko jeden. Relacja jest więc typu: jeden do wielu (gdzie jeden jest po stronie tabeli
„tytuły” a wiele po stronie tabeli „egzemplarze”). Podobna relacja istnieje między tabelami
„egzemplarze” i „wypożyczenia”, ponieważ jeden konkretny egzemplarz może być wypożyczany
dowolnie wiele razy, ale w konkretnym wypożyczeniu wystąpić może tylko raz. I identycznie w relacji
między „czytelnikami” a „wypożyczeniami”, bo dany czytelnik może przeprowadzać dowolnie wiele
wypożyczeń ale każde z wypożyczeń może być dokonane tylko przez jednego – konkretnego
czytelnika.
W powyższym układzie nie ma przykładów relacji wiele do wiele (jest w kolejnym przykładzie). Jeśli
jednak taka relacja istniałaby, to należałoby ją rozbić na dwie relacje typu jeden do wielu, wstawiając
dodatkową tabelę. Relacyjne bazy danych, a taką jest Access, nie pozwalają na istnienie tego typu
relacji.
Przykładem relacji jeden do jeden byłaby sytuacja w której pewne dane na temat czytelników
ukrylibyśmy w osobnej tabeli. Mogłyby być to na przykład jakieś szczegółowe dane na temat
czytelnika, które z pewnych powodów chcielibyśmy ukryć przed niektórymi użytkownikami. Jest to
jednak sytuacja rzadka.
Kolejny rysunek pokazuje typ relacji między tabelami. Znakiem „∞” oznaczono stronę „wiele” relacji
a „1” stronę jeden.
1
ISBN
Autor
Tytuł
Temat
Wydawnictwo
Liczba
egzemplarzy
UKD
Fizyczne miejsce
w bibliotece
Data wydania
Ilość stron
Typ oprawy
1
∞
∞
1
ID_ksiazki
Dostępność książki
∞
ID_wypozyczenia
Data wypożyczenia
Data zwrotu
Faktyczna data zwrotu
Data wypożyczenia
Nr książki
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
ID_czytelnika
Kara
Liczba
wypożyczonych przez
czytelnika
Data zapisania
czytelnika do
biblioteki
Imię
Nazwisko
ulica
Nr domu
miasto
Kod pocztowy
kraj
Data urodzenia
Kontakt do czytelnika
Nr dowodu tożsamości
Typ dowodu
tożsamości
Został do rozwiązania jeszcze jeden problem: w jaki sposób tabele łączą się ze sobą. Rozwiązaniem
jest umieszczenie klucza podstawowego ze strony „jeden” relacji w tabeli ze strony „wiele” relacji. W
przypadku relacji „jeden do jednego” są to dokładnie takie same pola. W przypadku tabeli rozbijającej
niedopuszczalną relację wiele do wiele umieszcza się w niej klucze podstawowe z tabel istniejących
odtąd z nią w relacji „jeden do wiele” (patrz przykład numer 2). Kolejny rysunek pokazuje
rozwiązanie. Klucze obce oznaczono kolorem żółtym
1
ISBN
Autor
Tytuł
Temat
Wydawnictwo
Liczba
egzemplarzy
UKD
Fizyczne miejsce
w bibliotece
Data wydania
Ilość stron
Typ oprawy
1
∞
∞
1
ID_ksiazki
Dostępność książki
ISBN
∞
ID_wypozyczenia
Data wypożyczenia
Data zwrotu
Faktyczna data zwrotu
Data wypożyczenia
Nr książki
ID_ksiazki
ID_czytelnika
Przykład 2: baza zamówień małego sklepu.
Pomijamy początkowe rozważania, zatrzymując się na problemie relacji
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
ID_czytelnika
Kara
Liczba
wypożyczonych przez
czytelnika
Data zapisania
czytelnika do
biblioteki
Imię
Nazwisko
ulica
Nr domu
miasto
Kod pocztowy
kraj
Data urodzenia
Kontakt do czytelnika
Nr dowodu tożsamości
Typ dowodu
tożsamości
ID_klienta
Nazwa
Adres
Miasto
Region
Kod pocztowy
Kraj
telefon
fax
E_mail
uwagi
∞
1
ID_produktu
nazwa
Ilość jednostkowa
Cena jednostkowa
Stan magazynu
Ilość zamówiona
Stan minimum
Wycofany
∞
∞
ID_zamowienia
Data zamowienia
Data wymagana
Data wysyłki
Problemem powyższego projektu jest to, że istnieje relacja wiele do wiele między tabelą zamówienia a
tabelą produkty. Jest tak dlatego, że rzeczywiście, w jakimś zamówieniu klient może zamówić więcej
niż jeden produkt (wiele) i każdy z produktów potencjalnie może pojawić się w dowolnej liczbie
zamówień (wiele). Rozwiązaniem jest wstawieniem dodatkowej tabeli rozbijającej relacje wiele do
wiele na dwie wiele do jeden.
ID_klienta
Nazwa
Adres
Miasto
Region
Kod pocztowy
Kraj
telefon
fax
E_mail
uwagi
1
1
∞
∞
∞
Ilość
rabat
1
ID_zamowienia
Data zamowienia
Data wymagana
Data wysyłki
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
ID_produktu
nazwa
Ilość jednostkowa
Cena jednostkowa
Stan magazynu
Ilość zamówiona
Stan minimum
Wycofany
Ponieważ nowa tabela „szczegóły zamówień” jest powołana w celu złamania relacji wiele do wielu, jej
kluczem wsłanym będą dwa klucze podstawowe z tabel, które teraz rozdziela: „id_zamowienia” i
„id_produktu”. Dodano również klucz obcy do tabeli zamówienia.
ID_klienta
Nazwa
Adres
Miasto
Region
Kod pocztowy
Kraj
telefon
fax
E_mail
uwagi
.
1
1
∞
∞
∞
ID_produktu
ID_zamowienia
Ilość
rabat
1
ID_zamowienia
Data zamowienia
Data wymagana
Data wysyłki
ID_klienta
PDF stworzony przez wersję demonstracyjną pdfFactory www.pdffactory.pl
ID_produktu
nazwa
Ilość jednostkowa
Cena jednostkowa
Stan magazynu
Ilość zamówiona
Stan minimum
Wycofany