1300739488

tychże, kserokopii, czy skanow). Jeśli wszyscy dacie mi dowody osobiste, to nie ma żadnego problemu, co jednak kiedy znajdzie się kilka praw jazdy, jakiś paszport i ze dwie legitymacje? Mimo, że na każdym z tych dokumentów sama struktura danych jest inna, nie stanowi to problemu ponieważ są one opisane - w konkretnych miejscach jest zaznaczone, co jest imieniem, a co nazwiskiem (mogę sobie jednak wyobrazić, że gdybym dostał np. chiński dowód osobisty - o ile tam dane są opisane tylko po chińsku - to nie zorientowałbym się, czym są które dane!) W ten sposób jednak sama lista dokumentów też jest specyficzną bazą danych, która ma wprawdzie pewne zalety (chociażby prawne, ale też wynikające z przechowywania dodatkowych danych, które potencjalnie mogą być przydatne), ma też wady (trudniejsze przetwarzanie danych - nad każdym dokumentem trzeba się zatrzymać o wiele dłużej, niż gdyby były to rekordy na liście).

W dalszej części zajmować się będziemy jedynie wycinkiem tematu - tzw. relacyjnymi bazami danych, które opierają się właśnie na tabelach z danymi (o konkretnej, sztywnej strukturze), oraz informacjach zawartych w relacjach między nimi.

3 Relacyjna baza danych - jak to ugryźć?

Jak wspomniano na końcu poprzedniego rozdziału, relacyjna baza danych składa się z danych zawartych w tabelach, oraz informacji wynikających z relacji między nimi. Formalnie należałoby przedstawić ją jako bazę w której dane przedstawione są w postaci relacyjnej, która definiowana jest za pomocą teorii mnogości, w szczególności samym pojęciu relacji. Jakkolwiek podejście takie jest ważne i słuszne w przypadku naukowych rozważań nad np. wymiarem tego, co daje się w takim modelu zapisać, o tyle w naszych rozważaniach wchodzenie w matematykę będzie zbyteczne i w najmniejszym nawet stopniu nie przyczyni się do praktycznego zrozumienia tematu, a co najwyżej odstraszy. Z tego powodu tego wątku nie będę kontynuował.

Jak więc opisać model relacyjny w sposób prosty i zrozumiały, a jednocześnie bez nadmiernej trywializacji? Sądzę, że najlepiej zrobić to na znanym z życia przykładzie.

Wyobraźmy sobie wspomnianą już bibliotekę. Zakładam, że każdy z czytelników przynajmniej raz w życiu tam zawędrował. W tej chwili wprawdzie w większości bibliotek są już bazy w postaci cyfrowej, jednak jeszcze kilka lat temu były dwa rodzaje kart (pomijam katalog, którym na razie nie będziemy się zajmować):

•    karty czytelników na których zapisane były personalia czytelnika, oraz informacje o wypożyczeniach; w chwili wypożyczenia dołączano do nich karty wypożyczanych książek

•    karty książek które zawierały informacje o książce; były w książkach na półce, a w chwili wypożyczenia dołączane do karty czytelnika (a po oddaniu odkładane z powrotem do książki)

Mając w jednym miejscu kartotekę czytelników bibliotekarz mógł bardzo szybko określić np. którzy czytelnicy mają wypożyczone książki (do których kart coś jest dopięte), czy określić książki wypożyczone przez konkretną osobę (karty czytelników były posortowane, więc łatwo było znaleźć konkretną).

Jakkolwiek do użytku „ręcznego” metoda była bardzo dobra, o tyle miało to szereg wad, np. ograniczona liczba miejsc na wypożyczenia (kiedy karta czytelnika się „skończyła”, dokładano na stałe drugi kartonik, potem trzeci itd...), trudności z określeniem co się dzieje z konkretną książką (cała baza była zorganizowana w oparciu o czytelników, zatem poszukiwanie konkretnej wypożyczonej książki polegało na przeglądaniu wszystkich kart czytelniczych w poszukiwaniu odpowiedniej sygnatury).

Spróbujmy zaprojektować bazę danych (na razie dość abstrakcyjnie) w której będziemy mogli przechowywać opisane wyżej informacje, zatem informacje o książkach, o czytelnikach i o relacjach pomiędzy nimi, czyli o faktach wypożyczeń.