Projektowanie internetowej bazy danych część 1 Znając podstawy PHP możemy przystąpić do łączenia skryptów z bazą danych. Jak pamiętamy, w rozdziale 2. pt. "Przechowywanie i wyszukiwanie danych" przedstawiono korzyści wynikające z używania systemów zarządzania relacyjnymi bazami danych (RDBMS) zamiast plików jednorodnych: RDBMS pozwalają na szybszy dostęp do danych niż pliki jednorodne. RDBMS można zadawać zapytania o dane spełniające konkretne kryteria. RDBMS posiadaj ą wbudowany mechanizm zapewniania równoległego dostępu. RDBMS pozwalaj ą na swobodny dostęp do danych. RDBMS mają wbudowany system przywilejów. Ujmując rzecz bardziej konkretnie, korzystanie z relacyjnych baz danych pozwala na szybkie i łatwe uzyskiwanie odpowiedzi na pytania dotyczące miejsca zamieszkania klientów, najlepiej sprzedającego się produktu czy typu klientów wydających najwięcej pieniędzy. Informacje te pomogą ulepszyć stronę WWW tak, aby przyciągnąć i zatrzymać większą liczbę użytkowników. Bazą danych, z której będziemy korzystać w tym rozdziale, jest MySQL. Zanim jednak zajmiemy się konkretnymi zagadnieniami dotyczącymi bazy danych, powinniśmy rozważyć następujące kwestie: koncepcję i terminologię relacyjnych baz danych, projektowanie internetowych baz danych, architekturę internetowych baz danych. Koncepcje relacyjnych baz danych Relacyjne bazy danych są obecnie najczęściej wykorzystywanym typem baz danych. Opierają się one na teoretycznych podstawach algebry relacyjnej. Zrozumienie teorii relacji nie jest niezbędne do używania relacyjnych baz danych, konieczne jest natomiast zrozumienie jej podstawowych koncepcji. Tabele Relacyjne bazy danych składają się z relacji, zwanych zazwyczaj tabelami. Tabela jest dokładnie tym, co oznacza - tabelą danych. Jeśli używałeś arkusza kalkulacyjnego, używałeś również tabeli. Rozważmy następujący przykład: Rysunek 7.1 przedstawia pojedynczą tabelę. Zawiera ona nazwiska i adresy klientów księgami "Książkorama". Rysunek 7.1 KlientID Nazwisko Adres Miejscowość 1 Julia Kowalska Wierzbowa 25 Warszawa 2 Adam Pawlak Szeroka 1/47 Szczecin 3 Michalina Nowak Zachodnia 357 Gliwice Tabela posiada nazwę (Klienci), kilka kolumn, z których każda zawiera inny rodzaj danych, oraz wiersze odpowiadające poszczególnym klientom. Kolumny Każda kolumna tabeli posiada wyróżniającą ją nazwę i zawiera inny rodzaj danych. Każdej kolumnie przypisany jest typ danych. Na przykład z tabeli Klienci na rysunku 7.1 można wywnioskować, iż KlientID jest typu całkowitoliczbowego, natomiast pozostałe trzy kolumny zawierają ciągi znaków. Kolumny są czasem nazywane polami lub atrybutami. Wiersze Każdy wiersz tabeli odpowiada innemu klientowi. Format tabelaryczny powoduje, że każdy wiersz ma te same atrybuty. Wiersze są również nazywane rekordami lub krotkami.
Wartości Każdy wiersz zawiera zbiór pojedynczych wartości odpowiadających kolumnom. Każda z tych wartości musi być tego samego typu, jaki przypisano kolumnie, w której się znajduje. Konieczne jest znalezienie sposobu jednoznacznej identyfikacji każdego klienta. Nazwiska nie na wiele się tu zdadzą - łatwo zgadnąć dlaczego, szczególnie w przypadku popularnych. Rozpatrzmy przykład Julii Kowalskiej z tabeli Klienci: w książce telefonicznej figuruje mnóstwo osób o tym nazwisku. Moglibyśmy wyróżnić Julię na kilka sposobów. Zapewne jest ona jedyną osobą o tym nazwisku mieszkającą pod przypisanym jej adresem, jednak mówienie o "Julii Kowalskiej z ulicy Wierzbowej 25 w Warszawie" jest dosyć niewygodne i brzmi chyba za bardzo urzędowo. Ponadto metoda ta wymaga korzystania z więcej niż jednej kolumny tabeli. Metoda, którą posłużyliśmy się w tym przykładzie i którą zapewne większość czytelników będzie wykorzystywać w swoich aplikacjach, polega na dodaniu unikalnego pola KlientID. Na tej samej zasadzie jest nadawany numer konta w banku czy numer członkostwa w klubie. Dzięki temu przechowywanie szczegółowych danych w bazie staje się znacznie prostsze. Sztucznie nadawany numer identyfikacyjny gwarantuje unikalność poszczególnych rekordów, co rzadko zapewniają nam prawdziwe dane, a nawet ich kombinacje. Pole identyfikujące poszczególne rekordy nazywane jest kluczem bądź też kluczem podstawowym. Klucz może się też składać z kilku pól. Jeśli na przykład zdecydowalibyśmy się wyróżniać Julię jako "Julia Kowalska z ulicy Wierzbowej 25 w Warszawie", to klucz składałby się z pól Nazwisko, Adres i Miejscowość, co jednak nie gwarantowałoby unikalności. Bazy danych składają się najczęściej z więcej niż jednej tabeli i wykorzystują klucze do uwidocznienia odwołań między dwiema oddzielnymi tabelami. Rysunek 7.2 przedstawia drugą tabelę, którą dołączyliśmy do naszej bazy danych. W nowej tabeli przechowywane są informacje dotyczące zamówień złożonych przez klientów księgami. Każdy wiersz tabeli Zamówienia odpowiada jednemu zamówieniu dokonanemu przez jednego klienta. Tabela ta zawiera również kolumnę K11entID, dzięki czemu wiemy, kim jest klient, który złożył dane zamówienie. Przeanalizujmy zamówienie, dla którego ZamówienieID jest równe 2: widzimy, iż zostało ono złożone przez klienta, którego KlientID wynosi l. Z tabeli Klienci wynika, iż tym klientem jest Julia Kowalska. Rysunek 7.2 KLIENCI KlientID Nazwisko Adres Miejscowość 1 Julia Kowalska Wierzbowa 25 Warszawa 2 Adam Pawlak Szeroka 1/47 Szczecin 3 Michalina Nowak Zachodnia 357 Gliwice ZamowienieID KlientlD Wartość Data 1 3 27.50 2000-04- 2 1 12.99 2000-04- 3 4 2 4 74.00 6.99 2000-04- 2000-05- 01 Relację tego typu określa się mianem klucza obcego. KlientID jest kluczem podstawowym w tabeli Klienci, lecz jeśli pole to pojawi się również w innej tabeli, na przykład Zamówieni a, to nosi nazwę klucza obcego. Można by zadać pytanie, dlaczego zostały utworzone dwie oddzielne tabele, zamiast zapamiętywać adres Julii w tabeli Zamówienia? Odpowiedzi na to pytanie udzielimy w następnym podrozdziale.
Schematy Zbiór projektów wszystkich tabel wchodzących w skład bazy danych nazywamy schematem bazy danych -jest to całościowy projekt bazy. Schemat powinien zawierać projekty tabel wraz z oznaczeniem kolumn, typów danych przypisanych poszczególnym kolumnom oraz wskazywać klucze podstawowe i klucze obce. Generalnie schemat nie powinien zawierać żadnych danych, można jednak przedstawić przykładowe dane w celu lepszego objaśnienia projektu. Schematy baz danych mogą mieć formę diagramów, takich jak na rysunkach 7.1 i 7.2, diagramów encji i relacji (tym rodzajem diagramów nie będziemy się zajmować) bądź też formę tekstową, np.: Klienci(KlientID, Nazwisko, Adres, Miasto) Zamówienia (ZamowienieID, KlientID, Wartość, Data) Podkreślenie nazwy kolumny linią ciągłą oznacza, iż będą w niej zapamiętywane klucze podstawowe tabeli, w której ta kolumna się znajduje. Natomiast linią przerywaną podkreślone są te kolumny, w których zapamiętywane będą klucze obce. Relacje Klucze obce ukazują relacje pomiędzy danymi z dwóch różnych tabel. Na przykład połączenie tabeli Zamówienia z tabelą Klienci odzwierciedla relację między konkretnym wierszem tabeli Zamówienia i określonym wierszem tabeli Klienci. Teoria relacyjnych baz danych uwzględnia istnienie trzech typów relacji. Są one klasyfikowane zależnie od liczby wartości, które mogą wystąpić po każdej stronie relacji. Wyróżnia się więc relacje jeden-dojednego, jeden-do-wielu i wiele-do-wielu. Relacja jeden-do-jednego oznacza, iż po każdej stronie może występować tylko jedna wartość. Na przykład gdybyśmy wydzielili z tabeli Klienci odrębną tabelę zawierającą adresy, wówczas byłyby one powiązane relacją jeden-do-jednego. Tabela Klienci mogłaby więc posiadać klucz obcy z tabeli Adresy lub odwrotnie. W relacji jeden-do-wielu jeden wiersz tabeli jest połączony z jednym wierszem lub wieloma wierszami drugiej. W naszym przykładzie jeden klient może złożyć kilka zamówień. W przypadku tego typu relacji tabela z wieloma wierszami będzie zawierać kolumnę z kluczem obcym pochodzącym z tabeli z jednym wierszem. Dlatego też w tabeli Zamówienia umieściliśmy kolumnę KlientID w celu zastosowania tej relacji. W przypadku relacji wiele-do-wielu wiele wierszy jednej tabeli jest połączonych z wieloma wierszami innej. Gdybyśmy na przykład mieli dwie tabele: Książki i Autorzy, mogłaby zaistnieć sytuacja, w której jedna z książek miałaby dwóch współautorów, przy czym każdy z nich mógłby być również autorem lub współautorem innych książek. Tego typu relacje są zazwyczaj upraszczane poprzez utworzenie dodatkowej, trzeciej tabeli. Mielibyśmy więc tabele Ksiazki, Autorzy oraz Autorzy_Ksiazki. Ta ostatnia zawierałaby tylko pary kluczy obcych pochodzących z dwóch pozostałych tabel i określałaby, jaki autor napisał (samodzielnie lub z innym autorem) daną książkę. Jak zaprojektować internetową bazę danych Projektowanie nowych tabel i wyznaczanie ich kluczy jest swego rodzaju sztuką. Można oczywiście próbować przebrnąć przez mnogość publikacji dotyczących diagramów encji i relacji i procesu normalizacji baz danych, które to zagadnienia wykraczają poza ramy tej książki. Większość etapów tworzenia schematu bazy danych opiera się jednak na podstawowych zasadach projektowania. Rozważymy je w kontekście przykładowej księgami "Książkorama". Określ obiekty świata realnego, których model chcesz wykonać Projektując bazę danych tworzy się najczęściej model obiektów świata rzeczywistego oraz relacji zachodzących między nimi oraz gromadzi się informacje na temat tych obiektów i relacji. Ogólnie można przyjąć, iż każda klasa modelowanych obiektów świata realnego powinna mieć odpowiadającą jej tabelę. Chcemy na przykład przechowywać informacje o wszystkich klientach naszej księgarni. Jeśli istnieje zbiór danych mający tę samą strukturę, można utworzyć tabelę odpowiadającą tym danym.
W naszym przykładzie chcemy przechowywać informacje na temat klientów, sprzedawanych książek oraz szczegółowe informacje dotyczące złożonych zamówień. Każdy z klientów ma nazwisko i adres. Każde zamówienie jest oznaczone datą, ma wartość całkowitą i opiewa na jedną lub więcej książek. Każda książka posiada numer ISBN, autora, tytuł i cenę. Łatwo zatem zauważyć, iż w projektowanej bazie są potrzebne co najmniej trzy tabele: Klienci, Zamowienia oraz Książki. Początkowy schemat tej bazy danych jest przedstawiony na rysunku 7.3. Rysunek 7.3. - Schemat początkowy zawiera tabele Klienci, Zamówienia i Książki KLIENCI KlientID Nazwisko Adres Miejscowość 1 Julia Kowalska Wierzbowa 25 Warszawa 2 Adam Pawlak Szeroka 1/47 Szczecin 3 Michalina Nowak Zachodnia 357 Gliwice ZamowienieID KlientID Wartość Data 1 3 27.50 2000-04-02 2 1 12.99 2000-04-15 3 2 74.00 2000-04-19 4 4 6.99 2000-05-01 KSIĄŻKI ISBN Autor Tytuł Cena 0-672-31687-8 Michael Morgan Java 2 dla Profesjonalistów 34.99 0-672-31745-1 Thomas Down Instalacja Oebian GNU/Linux 24.99 0-672-31509-2 Lucas PruitI Poznaj GIMP w 24 godziny 24.99 Na tym etapie nie jesteśmy w stanie określić na podstawie modelu, które książki zostaj zamówione i w jakim zamówieniu. Zajmiemy się tym w następnym podrozdziale. Unikaj przechowywania redundantnych danych W jednym z poprzednich podrozdziałów padło pytanie: "Czy nie można by przechowywać adresu Julii Kowalskiej w tabeli Zamówienia?". Jeśli Julia często będzie zamawiać książki w księgarni "Książkorama", na co oczywiście liczymy, wówczas jej dane zostaną zapisane wiele razy. Tabela Zamówienia wyglądałaby więc tak jak na rysunku 7.4. Z ujęciem takim związane są dwa podstawowe problemy. Pierwszym z nich jest marnotrawstwo pamięci. Po co mamy zapisywać dane Julii czterokrotnie, jeśli wystarczy, że zapiszemy je tylko raz? Rysunek 7.4. Baza danych przechowująca dane redundantne zajmuje znacznie więcej pamięci i może powodować przekłamania danych. ZamowienieID Wartość Data KlientlD Nazwisko Adres Miejscowość 12 199.50 2000-04-25 1 Julia Kowalska Wierzbowa 25 Warszawa 13 43.00 2000-04-29 1 Julia Kowalska Wierzbowa 25 Warszawa 14 15 15.99 23.75 2000-04-30 1 2000-05-01 1 Julia Kowalska Wierzbowa 25 Warszawa Julia Kowalska Wierzbowa 25 Warszawa Innym problemem jest możliwość powstania tzw. anomalii uaktualniania, czyli sytuacji, w której zmiana danych zawartych w bazie prowadzi do utraty ich spójności. Naruszona zostaje integralność danych i nie mamy pewności, które dane są poprawne, a które nie. Skutkuje to zazwyczaj utratą informacji. Należy unikać trzech rodzajów anomalii uaktualniania bazy danych: modyfikacji, wstawiania i usuwania.
Jeśli Julia zmieni miejsce zamieszkania po złożeniu zamówienia, a przed jego realizacją wówczas należy uaktualnić jej adres w czterech miejscach bazy zamiast w jednym, co wymaga czterokrotnie więcej pracy. Nietrudno jest przeoczyć ten fakt i dokonać uaktualnienia tylko w jednym miejscu, a w konsekwencji doprowadzić do utraty spójności danych (niedopuszczalne!). Zagrożenia tego typu nazywane są anomaliami modyfikacji, gdyż pojawiają się przy próbie dokonania zmian w bazie danych. Mając tak zaprojektowaną bazę danych konieczne będzie wstawianie danych Julii, ilekroć złoży ona zamówienie. Za każdym razem trzeba będzie również sprawdzić spójność tych danych z wcześniej zapisanymi do bazy. Niedopełnienie tego obowiązku może prowadzić do sytuacji, w której dane dotyczące adresu Julii, zawarte w dwóch różnych wierszach, są ze sobą sprzeczne. W jednym wierszu na przykład może zna- leźć się informacja, iż Julia mieszka w Warszawie, inny natomiast wskazywałby, że jej miejscem zamieszkania jest np. Wrocław. Sytuacja taka jest nazywana anomalią wstawiania, gdyż pojawia się przy zapisywaniu nowych danych do bazy. Trzecim typem zakłóceń jest anomalia usuwania występująca w raz (niespodzianka!) usuwania wierszy z bazy danych. Jeśli wszystkie złożone przez Julię zamówienia zostaną zrealizowane, nastąpi ich usunięcie z tabeli Zamówienia. Oznacza to, że już nie będziemy mieli żadnego rekordu zawierającego adres Julii. Nie będzie można wysłać jej specjalnej oferty, a gdy następnym razem zapragnie zamówić jakąś książkę w naszej księgami, trzeba będzie znowu uzyskać i zapisać dane dotyczące jej adresu. Powinniśmy zatem projektować bazy danych w taki sposób, aby nie wystąpiła żadna z powyższych anomalii. Zapisuj atomowe wartości kolumn Oznacza to, że w każdym polu każdego wiersza zapisujemy tylko jedną wartość. Na przykład musimy przechowywać informacje o tym, jakie książki wchodziły w skład danego zamówienia. Istnieje kilka sposobów, aby to zrobić. Można dodać kolumnę do tabeli Zamówienia, w której zapisywane będą wszystkie zamówione książki. Rozwiązanie takie jest przedstawione na rysunku 7.5. Rysunek 7.5. - W tym przypadku pole Ksiazki _zamowione zawiera wartości wielokrotne ZamowienieID KlientlD Wartość Data Książki zamówione 1 3 27.50 2000-04-02 0-672-31697-8 2 1 12.99 2000-04-15 0-672-31745-1. 0-672-31509-2 3 2 74.00 2000-04-19 0-672-31697-8 4 3 6.99 2000-05-01 0-672-31745-1, 0-672-31509-2, 0-672-31697-8 Ten pomysł jest wadliwy z kilku powodów. Prowadzi on bowiem do zagnieżdżania w jednej kolumnie całej tabeli wiążącej zamówienia z książkami. Zastosowanie tej metody znacznie utrudni znalezienie odpowiedzi na pytanie typu: Ile egzemplarzy książki Java 2 dla profesjonalistów zostało zamówionych?". System nie może po prostu zliczyć odpowiednich pól, lecz musi przeanalizować "wartość każdego atrybutu, aby sprawdzić, czy zawiera on szukane wartości. Zatem tak naprawdę tworzymy tabelę w tabeli. Zamiast tego powinniśmy utworzyć nową tabelę o nazwie Pozycje_zamowione, pokazaną na rysunku 7.6. Rysunek 7.6. - Tak zaprojektowana tabela ułatwia szukanie zamówionych książek POZYCJE_ZAMÓWIONE ZamowienieID ISBN Ilość 1 0-672-31697-8 1 2 0-672-31745-1 2 2 0-672-31509-2 1 3 0-672-31697-8 1 4 0-672-31745-1 1 4 0-672-31509-2 2 4 0-672-31697-6 1
Nowa tabela jest łącznikiem między tabelami Zamówienia i Książki. Tabela tego typu jest wykorzystywana najczęściej w przypadku istnienia pomiędzy dwoma obiektami relacji wiele-do-wielu w rozważanym przypadku jedno zamówienie może opiewać na kilka książek, a każda książka może być zamówiona przez wielu klientów. Dobierz właściwe klucze Należy się upewnić, że wyznaczone klucze zagwarantuj ą unikalność rekordów. W naszym przykładzie utworzone zostały specjalne klucze dla klientów (KlientID) i dla zamówień (ZamowienieID), ponieważ te obiekty świata rzeczywistego nie mają naturalnego identyfikatora zapewniającego ich unikalność. Zbędne jest natomiast definiowanie kluczy dla książek posiadają one przecież własny numer ISBN. Tabelę Pozycje_zamowione można rozszerzyć o specjalnie wyznaczony klucz, zauważmy jednak, że kombinacja dwóch atrybutów: ZamowienieID i ISBN zapewnia unikalność każdego rekordu, jeśli tylko zamówiona książka będzie zapisywana w jednym wierszu niezależnie od tego, ile jej egzemplarzy zamówiono. Z tego właśnie powodu tabela Pozycje_zamowione posiada kolumnę Ilość. Pomyśl o zapytaniach, które zadasz bazie Projektując bazę danych należy cały czas mieć na względzie informacje, jakie będziemy z niej uzyskiwać. W tym celu powróćmy na chwilę do pytań postawionych na początku tego rozdziału. Chcemy na przykład wiedzieć, które książki z naszej księgami najlepiej się sprzedają. Należy się upewnić, iż baza będzie zawierać wszystkie niezbędne dane oraz że połączenia ustanowione pomiędzy tabelami umożliwią znalezienie odpowiedzi na pytania użytkownika. Unikaj tworzenia tabel z wieloma pustymi polami Zamysł dodania do bazy danych recenzji książek można zrealizować na co najmniej dwa sposoby (rysunek 7.7). Rysunek 7.7. - W celu przechowywania recenzji możemy dodać kolumnę Recenzja do tabeli Książki lub utworzyć dodatkową tabelę Recenzje_ksiazek KSIĄŻKI ISBN Autor Tytuł Cena Recenzja 0472-31687-8 Michael Morgan Java 2 dla Profesjonalistów 34.99 0-672-31745-1 Thomas Down 0-672-31509-2 Lucas Pruitt Instalacja Oeblan GNU/LiniK 24.99 Poznaj GIMP w 24 godziny 24.99 RECENZJE_KSIĄŻEK ISBN Recenzja Pierwszy sposób polega na dodaniu kolumny Recenzja do tabeli Ksiazki. Każda książka będzie więc miała dodatkowe pole Recenzja. Jeśli baza danych przechowuje dane wielu książek, a recenzent ocenia tylko niektóre z nich, wówczas w znacznej liczbie wierszy atrybut ten nie ma żadnej wartości. Pola mają wtenczas wartość NULL. Występowanie wielu pustych pól w bazie danych jest niewskazane. Prowadzi to do marnotrawstwa pamięci oraz może być przyczyną błędnych wyników zwracanych przez funkcje sumujące wartości pól lub inne funkcje obliczeniowe. Użytkownik, widząc puste pole, nie jest pewien, czy sytuacja ta jest spowodowana nieprawidłowością atrybutu, błędem w bazie danych czy też po prostu brakiem danych w bazie. Można uniknąć problemów związanych z występowaniem wielu pustych pól, stosując drugi ze sposobów pokazanych na rysunku 7.7. W tym przypadku tabela Recenzje_książek zawiera tylko te pozycje, które zostały już ocenione, oraz samą recenzję. Zauważmy, iż założeniem tego projektu jest istnienie pracującego dla naszej księgami recenzenta. W równie prosty sposób można by jednak umożliwić przechowywanie recenzji przesłanych przez klientów. Wystarczyłoby tylko dodać kolumnę KlientID do tabeli Recenzje_ksiazek.
Typy tabel podsumowanie Bez trudu można zauważyć, iż projekty baz danych zawierają najczęściej tabele dwojakiego rodzaju: Proste tabele opisujące obiekty świata rzeczywistego. W przypadku istnienia relacji jeden-do-jednego lub jeden-do-wielu mogą one również zawierać klucze do innych obiektów. Dla przykładu: jeden klient może złożyć wiele zamówień, ale jedno zamówienie może być złożone tylko przez jednego klienta. W zamówieniu umieszczamy więc odwołanie do klienta. Tabele łączące, które opisuj ą relacje wiele-do-wielu występujące między dwoma obiektami, jak w przypadku zamówień i książek. Tabele te są często związane z pewnymi typami transakcji występujących w świecie rzeczywistym.