Zajęcia. Przykład : 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. Nr Dostępność książki Wydawnictwo egzemplarzy Data zwrotu Kara Faktyczna data zwrotu UKD Fizyczne miejsce w bibliotece Data wydania Ilość stron wypożyczonych przez
Data zapisania do Imię i nazwisko adres Data urodzenia Kontakt do Nr dowodu 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: 2303032 Nr 2345 Dostępność książki tak Sienkiewicz Henryk Potop historyczna Wydawnictwo Prószyński egzemplarzy 4 07.05.2009 Data zwrotu 07.06.2009 Kara 0 Faktyczna data zwrotu UKD 30.78 Fizyczne miejsce w 4 półki za filarem
bibliotece Data wydania 2006 Ilość stron 876 wypożyczonych przez Data zapisania do miękka 4 05.04.2000 Imię i nazwisko Jan Kowalski adres Ul. Rakowicka 27 350 Kraków Data urodzenia 0.02.960 Kontakt do Nr dowodu Email: kowalski@onet.pl ABC678654 Dowód osobisty wydany przez prezydenta miasta Krakowa W przypadku następnej zaś tak: 2303032 345902 Nr 2345 2345 Dostępność książki tak tak Sienkiewicz Henryk Sienkiewicz Henryk Potop Ogniem i mieczem historyczna historyczna
Wydawnictwo Prószyński Iskry egzemplarzy 4 3 07.05.2009 07.05.2009 Data zwrotu 07.06.2009 07.06.2009 Kara 0 0 Faktyczna data zwrotu UKD 30.78 30.78 Fizyczne miejsce w 4 półki za filarem 4 półki za filarem bibliotece Data wydania 2006 2005 Ilość stron 876 643 miękka miękka 4 5 wypożyczonych przez Data zapisania 05.04.2000 05.04.2000 do Imię i nazwisko Jan Kowalski Jan Kowalski adres Ul. Rakowicka 27 Ul. Rakowicka 27 350 Kraków 350 Kraków Data urodzenia 0.02.960 0.02.960 Kontakt do Email: Email: kowalski@onet.pl kowalski@onet.pl Nr dowodu ABC678654 ABC678654 Dowód osobisty wydany przez prezydenta miasta Krakowa Dowód osobisty wydany przez prezydenta miasta Krakowa
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. 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 Wydawnictwo egzemplarzy UKD Fizyczne miejsce w bibliotece Data wydania Ilość stron Dostępność książki Data zwrotu Faktyczna data zwrotu Nr Kara wypożyczonych przez Data zapisania do Imię Nazwisko ulica Nr domu miasto kraj Data urodzenia Kontakt do Nr dowodu 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 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, albo może ID_. 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.
ISBN Wydawnictwo egzemplarzy UKD Fizyczne miejsce w bibliotece Data wydania Ilość stron ID_ksiazki Dostępność książki ID_wypozyczenia Data zwrotu Faktyczna data zwrotu ID_ Kara wypożyczonych przez Data zapisania do Imię Nazwisko ulica Nr domu miasto kraj Data urodzenia Kontakt do Nr dowodu Kolejnym krokiem jest ustalenia typu relacji między tabelami. Istnieją teoretycznie następujące sytuacje: ) 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.
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 mi 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. 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, 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 stronę jeden. ISBN Wydawnictwo egzemplarzy UKD Fizyczne miejsce w bibliotece Data wydania Ilość stron ID_ksiazki Dostępność książki ID_wypozyczenia Data zwrotu Faktyczna data zwrotu ID_ Kara wypożyczonych przez Data zapisania do Imię Nazwisko ulica Nr domu miasto kraj Data urodzenia Kontakt do Nr dowodu tożsamośc
ISBN Wydawnictwo egzemplarzy UKD Fizyczne miejsce w bibliotece Data wydania Ilość stron 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 ID_ksiazki Dostępność książki ISBN ID_wypozyczenia Data zwrotu Faktyczna data zwrotu ID_ksiazki ID_ ID_ Kara wypożyczonych przez Data zapisania do Imię Nazwisko ulica Nr domu miasto kraj Data urodzenia Kontakt do Nr dowodu Przykład 2: baza zamówień małego sklepu. Pomijamy początkowe rozważania, zatrzymując się na problemie relacji
ID_klienta Nazwa Adres Miasto Region Kraj telefon fax E_mail uwagi ID_zamowienia Data zamowienia Data wymagana Data wysyłki ID_produktu nazwa Ilość jednostkowa Cena jednostkowa Stan magazynu Ilość zamówiona Stan minimum Wycofany 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 Kraj telefon fax E_mail uwagi Ilość rabat ID_produktu nazwa Ilość jednostkowa Cena jednostkowa Stan magazynu Ilość zamówiona Stan minimum Wycofany ID_zamowienia Data zamowienia Data wymagana Data wysyłki
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 Kraj telefon fax E_mail uwagi. ID_zamowienia Data zamowienia Data wymagana Data wysyłki ID_klienta ID_produktu ID_zamowienia Ilość rabat ID_produktu nazwa Ilość jednostkowa Cena jednostkowa Stan magazynu Ilość zamówiona Stan minimum Wycofany