Wstęp

Internet przez większość czasu był siecią budowaną, finansowaną i użytkowaną głównie przez środowiska akademickie. Dopiero w ciągu kilku ostatnich lat rewolucja w sposobie dostępu do informacji, jakiej dokonał system World Wide Web, spowodowała, iż jego zasięg na świecie zaczął lawinowo się rozszerzać. Dzisiejszy Internet stał się praktycznie siecią powszechną. To już nie tylko, jak za "dawnych czasów", narzędzie pracy naukowej oraz intelektualna rozrywka studentów. W błyskawicznym tempie pojawiły się w sieci firmy handlowe i produkcyjne, redakcje gazet i czasopism, instytucje rządowe, a przede wszystkim - rzesza użytkowników prywatnych, podłączających się do sieci ze swoich domowych komputerów za pośrednictwem licznie powstałych tzw. providerów - firm usługowych, oferujących za niewysoką cenę możliwość połączenia z Internetem przez linię telefoniczną i modem. Coraz liczniejsi producenci oprogramowania do pracy w systemie WWW prowadzą intensywną promocję swoich programów w świecie biznesu, co owocuje szybkim przybywaniem w Internecie serwerów WWW większych i mniejszych komercyjnych firm, oferujących coraz częściej ściśle komercyjne usługi (nierzadko jest to możliwość zamówienia konkretnych towarów z dostawą do domu). Serwery instytucji rządowych udostępniają teksty oficjalnych dokumentów, aktów prawnych i różne inne informacje, np. statystyczne, gromadzone przez rozmaite agendy rządowe w ramach ich działalności. Wytwórnie filmowe i płytowe oferują w systemie WWW próbki swoich najnowszych produkcji. Czasopisma umieszczają w sieci swoje elektroniczne wydania - jedne dostępne bezpłatnie, inne po opłaceniu prenumeraty. Nie można też zapominać o gigantycznych - i wciąż rosnących - zasobach informacji z różnych dziedzin, udostępnianych tradycyjnie w Internecie przez obecne w nim od dawna uczelnie i inne instytucje "non-profit". Coraz większej liczbie osób pracujących "niematerialnie" - dziennikarzy, uczonych, menedżerów, ekonomistów, prawników - Internet umożliwia wykonywanie swojej pracy na odległość, bez konieczności fizycznego udawania się do miejsca pracy - w domu lub nawet na wyjeździe. Dostęp do sieci staje się otwarciem na świat dla osób niepełnosprawnych, przykutych do wózków inwalidzkich, głuchych, a nawet niewidomych. Świat zmierza coraz większymi krokami w stronę tzw. społeczeństwa informacyjnego, a Internet staje się prowadzącą ku niemu drogą.

Wraz z rosnącą ilością informacji, szybki dostęp do niej jest rzeczą niezbędną i obecną w naszym życiu na każdym kroku. Począwszy od takich dziedzin życia jak hurtownie, banki, sklepy internetowe, zastosowania biznesowe a na celach militarnych skończywszy, czyli wszędzie tam gdzie przetwarzane są bardzo duże ilości danych w niewielkim czasie. Szkoły nie stanowią wyjątku od tego tematu. Tworzone są bazy danych uczniów, nauczycieli danej szkoły. Rodzice za pośrednictwem Internetu mają wgląd w wyniki nauki swoich dzieci. Ogranicza to częstotliwość pojawiania się rodzica w szkole, daje możliwość śledzenia na bieżąco ocen, zachowania danego dziecka.

Wraz ze wzrostem ilości komputerów w szkole z dostępem do Internetu, istnieje możliwość, że w każdej pracowni szkolnej będzie stanowisko komputerowe dla nauczyciela. Informacje (oceny) będą wprowadzane na bieżąco przez nauczyciela bez konieczności zatrudniania kogokolwiek do uzupełniania bazy danych. Projekt „Gimnazjalnej bazy danych - GSI” umożliwia właśnie takie rozwiązanie.

W rozdziale pierwszym niniejszego projektu zostały przedstawione ogólne pojęcia związane z bazą danych: czym jest, typy baz danych, zasady projektowania internetowej bazy danych, co to jest język zapytań, system zarządzania bazą danych (DBMS).

Rozdział drugi został poświęcony narzędziom które zostały wybrane do tego projektu a mianowicie MySQL i PHP. Przedstawione zostały zalety i wady tych narzędzi.

Rozdział trzeci zawiera opis projektu „Gimnazjalnej Bazy Danych - GSI”. Opis podstawowej instalacji programów, opis poszczególnych tabel w bazie i relacji między nimi jak również hierarchii skryptów PHP, który wywołuje który. Kod SQL tworzący tabele został przedstawiony w załączniku nr 1.

Rozdział czwarty zawiera opis systemu uwierzytelnienia i nadawania uprawnień odpowiednim użytkownikom logującym się do bazy GSI.

W rozdziale piątym pracy zostały przedstawione opisy skryptów PHP. Ze względu na ich obszerność zostały wybrane i opisane tylko kluczowe fragmenty kodu poszczególnych skryptów odpowiedzialne za prawidłowe działanie bazy. Szczegółowy wydruk wszystkich skryptów w odpowiedniej kolejności został zamieszczony w załączniku nr 2.

1. Baza danych

1.1 Wprowadzenie

Niemal wszystkie przydatne aplikacje muszą dysponować możliwością zapisywania i pobierania danych. Jedną z metod zarządzania danymi są pliki. Chociaż system plików może zostać z powodzeniem wykorzystany niemal we wszystkich aplikacjach, to jednak narzuca poważne ograniczenia związane z projektem, efektywnością działania oraz skalowalnością aplikacji. Innym rozwiązaniem jest wykorzystanie baz danych.

Jedną z pierwszych decyzji, jaką należy podjąć przy tworzeniu nawet najprostszej aplikacji, będzie wybór odpowiedniego modelu przechowywania danych - innymi słowy sposobu, w jaki aplikacja będzie zapisywać i pobierać dane.

Wybór konkretnego modelu przechowywania danych spośród wielu dostępnych zależy od wymagań tworzonej aplikacji. Jeśli wykorzystuje ona niewielkie ilości danych, to przechowywanie ich w prostym pliku tekstowym może w zupełności wystarczyć. Jednak, wraz ze wzrostem ilości informacji, szybko okaże się, że będzie trzeba poszukać bardziej efektywnego sposobu ich przechowywania.

System plików to bardzo prymitywny sposób przechowywania danych, gdyż są one zapisywane w niestrukturalnych fragmentach, na przykład, gdy użytkownik żąda dostępu do fragmentu witryny chronionego hasłem, serwer WWW przeprowadzi jego autoryzację, korzystając ze zwyczajnego pliku tekstowego zawierającego listę identyfikatorów użytkowników oraz ich haseł (o ile serwer nie zostanie skonfigurowany w inny sposób). W sytuacji, gdy ilość użytkowników jest nieduża, nie stanowi to żadnego problemu. Jednak w przypadku konieczności sprawdzania tożsamości setek użytkowników jednocześnie, serwer musi przeanalizować plik tekstowy linia po linii, aż do momentu odnalezienia poszukiwanego użytkownika. Przy dużej liczbie użytkowników taki sposób przeszukiwania staje się nieefektywny i czasochłonny. Technika płaskiego pliku została ogromnie rozwinięta, w związku z czym teraz mamy do dyspozycji o wiele bardziej skomplikowane sposoby przechowywania i odczytywania informacji. W rezultacie pojawiło się rozwiązanie, z którego dziś najczęściej korzystamy. Są nimi bazy danych.

Baza danych jest zbiorem informacji zorganizowanych w taki sposób, aby dostęp i manipulowanie jego zawartością było jak najprostsze. Ta organizacja sprawia, iż bazy danych wciąż są najbardziej efektywną i praktyczną metodą przechowywania i manipulowania dużymi ilościami informacji.

System zarządzania bazą danych

System zarządzania bazą danych (DBMS; od angielskich słów: DataBase Management System, czasami nazywany także mechanizmem bazy danych) to najczęściej zestaw bibliotek, aplikacji i narzędzi pozwalających programiście zapomnieć szczegóły przechowywania i zarządzania danymi. Baza danych zapewnia również narzędzia pozwalające przeszukiwać i aktualizować dane.

Zadaniami DBMS są:

• Tworzenie bazy danych. Niektóre systemy korzystają z jednego, dużego pliku i w nim przechowują co najmniej jedną bazę danych, inne korzystają z wielu plików systemu operacyjnego lub operują bezpośrednio na „surowej" partycji dysku.

• Umożliwienie uaktualniania i selekcji danych. DBMS powinien zawierać metody wyszukiwania danych spełniających określone kryteria, na przykład dotyczących wszystkich jeszcze nie dostarczonych zamówień jakiegoś klienta. Przed upowszechnieniem się standardu SQL zapytania takie bardzo różniły się w zależności od systemu.

• Wielozadaniowość. Jeżeli baza danych jest wykorzystywana jednocześnie przez kilka aplikacji lub korzysta z niej jednocześnie kilku użytkowników, DBMS musi zapewniać taką separację wywołań użytkowników, że jedno wywołanie nie będzie wpływało na inne. Oznacza to, że użytkownicy muszą czekać na dostęp do danych jedynie w sytuacji, gdy ktoś zapisuje oczekiwane przez nas dane. Możliwy jest natomiast jednoczesny odczyt tych samych danych. W praktyce różne systemy baz danych w różnym stopniu zapewniają wielozadaniowość, a niektóre mogą mieć nawet konfigurowalne jej poziomy. Więcej na ten temat można przeczytać w rozdziale 9, zatytułowanym „Transakcje i blokowanie".

• Utrzymywanie dziennika operacji. DBMS może pamiętać przez jakiś czas wszystkie zmiany wprowadzone do danych. Może być to przydatne do szukania przyczyny błędu, ale prawdopodobnie ważniejsze jest to, że na podstawie dziennika operacji można odtworzyć stan danych w chwili awarii systemu (spowodowanej na przykład niespodziewanym zanikiem napięcia). Do odtworzenia stanu systemu sprzed awarii potrzebne są: kopia bezpieczeństwa oraz dziennik operacji.

• Zarządzanie bezpieczeństwem bazy danych. System bazy danych zapewnia mechanizmy kontroli dostępu, dzięki którym tylko uprawnieni użytkownicy mogą manipulować danymi zapisanymi w bazie i samą strukturą bazy danych (atrybuty, tabele i indeksy). Zwykle tworzy się hierarchię użytkowników bazy danych, od superużytkownika, który może zmieniać wszystko, poprzez użytkowników mogących dodawać i usuwać dane, aż do użytkowników, którzy mogą jedynie czytać dane z niektórych tabel. DBMS powinien posiadać mechanizmy pozwalające na dodawanie i usuwanie użytkowników oraz określanie dostępu do poszczególnych części bazy danych.

• Zapewnianie integralności odwołań. Wiele systemów baz danych zapewnia mechanizmy pomagające utrzymywać integralność odwołań, czyli wspomnianą wcześniej „poprawność danych". Zwykle mechanizmy te nie pozwalają zmienić danych i zwracają komunikat o błędzie w przypadku, gdy wstawienie lub zmiana danych powoduje naruszenie zasad modelu relacyjnego.

1.3 Typy baz danych

W latach sześćdziesiątych i siedemdziesiątych ubiegłego stulecia powstało kilka rodzajów baz danych, które w różny sposób rozwiązywały problemy powtarzających się grup danych. Wynikiem prowadzonych w tym czasie prac są różne modele systemów baz danych. Badania przeprowadzone w firmie IBM dostarczyły podstaw dla większości dziś używanych systemów.

Jednym z głównych celów wczesnych projektów baz danych była efektywność działania. Dużo łatwiej obsługuje się rekordy bazy danych o stałej długości lub co najmniej o stałej liczbie elementów (kolumn) w rekordzie. Pozwala to zwykle na uniknięcie problemu powtarzających się grup danych. Jeżeli programista zna co najmniej jeden język proceduralny programowania, bardzo szybko zauważy, że można wczytać jeden rekord danych do jednego rekordu (struktury) w tym języku. Rzeczywiste problemy bardzo rzadko dają się tak ograniczyć. Bardzo często musimy operować na danych mających niestandardową strukturę.

Trzema podstawowymi modelami systemów baz danych są:

• Hierarchiczny model baz danych,

• Sieciowy model baz danych,

• Relacyjny model baz danych.

1.3.1 Model hierarchiczny

System baz danych, wprowadzony w latach sześćdziesiątych przez IBM był pierwszym, w którym zastosowano model hierarchiczny. W modelu tym zakłada się, że rekordy danych składają się z kolekcji innych rekordów. Pozwala to rozwiązać problem powtarzających się grup danych.

W modelu tym zastosowano rozszerzoną strukturę dziecko - rodzic. Na przykład, samochód składa się (załóżmy) z głównych elementów: konstrukcji, nadwozia i układu napędowego. Każdy z tych komponentów może być podzielony na kolejne fragmenty. Na przykład układ napędowy składa się z silnika, skrzyni biegów, przekładni. Komponenty te mogą być dalej dzielone, aż dotrzemy do śrub, blach i innych elementów, z których składa się każdy samochód.

Hierarchiczny model bazy danych jest wykorzystywany do dziś. Oparte na tym modelu systemy baz danych pozwalają na takie zoptymalizowanie przechowywania danych, które umożliwia bardzo efektywne znajdowanie odpowiedzi na określone pytania (w języku baz danych nazywane są one zapytaniami bądź kwerendami).

1.3.2 Model sieciowy

Sieciowy model danych pozwala uniknąć niektórych problemów występujących w modelu hierarchicznym, na przykład relacji wiele - do - wielu.

Model ten wprowadza pojęcie wskaźników w bazie danych. Rekordy mogą zawierać bezpośrednie odwołania do innych rekordów. Załóżmy na przykład, że mamy rekordy klientów, z którymi współpracujemy. Każdy klient składa wiele zamówień (powtarzająca się grupa danych). Dane są zorganizowane w ten sposób, że rekord klienta zawiera wskaźnik do pierwszego rekordu zamówienia. Każdy rekord zamówienia zawiera zarówno dane zamówienia, jak i wskaźnik do kolejnego rekordu zamówienia. Wskaźnik ostatniego zamówienia wskazuje na rekord klienta, co oznacza koniec grupy.

Sieciowy model bazy danych posiada kilka bardzo istotnych zalet. Jeżeli chcemy odszukać wszystkie rekordy jednego typu związane z określonym rekordem innego typu, możemy to zrobić niezwykle szybko, korzystając ze wskaźników.

Główną wadą modelu sieciowego jest kłopotliwe wprowadzanie zmian po zaprojektowaniu bazy danych i wypełnieniu jej danymi. Dla baz danych ogólnego przeznaczenia model ten jest za mało elastyczny. Pisanie aplikacji wykorzystujących model sieciowy jest bardzo żmudne, ponieważ aplikacja taka musi odpowiadać za uaktualnianie wskaźników po usunięciu i uaktualnieniu rekordów.

1.3.3 Model relacyjny

Teoria systemów zarządzania bazami danych znacznie się rozwinęła od roku 1970, dzięki publikacji E. F. Codda „A Relational Model of Data for Large Shared Data Banks” (Relacyjny model danych dla dużych współdzielonych banków danych). Ta rewolucyjna publikacja wprowadziła pojęcie relacji i pokazała, w jaki sposób tabele mogą być wykorzystywane do reprezentowania obiektów z „realnego świata” i przechowywania danych o tych obiektach. Relacyjny model danych kładzie o wiele większy nacisk na strukturę danych i relacje pomiędzy elementami niż każdy z wcześniej powstałych modeli.

Istnieje kilka ważnych zasad definiujących relacyjny system zarządzania baza danych (RDBMS)

• Rekordy w tabelach są nazwane krotkami,

• Atrybuty w kolumnach musza być atomowe,

• Odwołania powinny być spójne.

1.4 Języki zapytań

System zarządzania relacyjna bazą danych posiada mechanizmy pozwalające na dodawanie i aktualizację danych. Jednak siła tych systemów tkwi w możliwości zadawania przez użytkowników pytań dotyczących zapisanych danych. Relacyjne bazy danych są o wiele bardziej elastyczne niż wczesne projekty baz danych, w których struktura była ukierunkowana na najczęściej wykonywane zapytania. Pozwalają na przykład na uzyskiwanie odpowiedzi na pytania, które nie były przewidziane w czasie projektowania struktury danych.

Propozycje Codda dotyczące modelu relacyjnego wykorzystują fakt, że relacje definiują zbiory, a zbiorami możemy manipulować przy pomocy operacji matematycznych. Zasugerował on, że zapytania mogą korzystać z gałęzi logiki nazywanej rachunkiem predykatów i że może ona stanowić podstawę języków zapytań. Oparcie języków zapytań na rachunku predykatów pozwoliło na skonstruowanie bardzo wydajnego mechanizmu przeszukiwania i wyodrębniania zbiorów danych.

Jedna z pierwszych implementacji języka zapytań był QUEL, który został wykorzystany w bazie danych Ingres, wyprodukowanej w końcu lat 70. Innym językiem zapytań, korzystającym jednak z nieco innych rozwiązań, jest QBE (Query By Example). W tym samym czasie w centrum badawczym firmy IBM powstał SQL (Structured Query Language, ang. strukturalny język zapytań).

SQL jest językiem, który doczekał się standardu. Najczęściej używaną definicją jest ISO/IEC 9075:1992 `Information technology---Database Languages---SQL'. Zwykle norma ta nazywana jest SQL92.

Istnieja trzy poziomy zgodności ze standardem SQL92: Entry SQL, Intermediate SQL i Full SQL. Do tej pory najczęściej spotyka się rozwiązania zgodne z poziomem Entry. MySQL zawiera wiele cech wymaganych dla spełnienia tego poziomu, ale niestety wciąż nie posiada kilku ważnych funkcji. Pomimo tych braków MySQL może być użytecznym systemem bazy danych; w wielu przypadkach można osiągnąć wymagane wyniki korzystając z innych metod.

Koncepcja 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.

1.5.1 Tabele

Relacyjne bazy danych składają się z relacji, zwanych zazwyczaj tabelami. Tabela jest dokładnie tym, co oznacza — tabelą danych.

1.5.2 Kolumny

Każda kolumna tabeli posiada wyróżniającą ją nazwę i zawiera inny rodzaj danych. Każdej kolumnie przypisany jest typ danych. Kolumny są czasem nazywane polami lub atrybutami.

1.5.3 Wiersze

Każdy wiersz tabeli odpowiada innemu np. uczniowi. Format tabelaryczny powoduje, że każdy wiersz ma te same atrybuty. Wiersze są również nazywane rekordami lub krotkami.

1.5.4 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.

1.5.5 Klucze

Konieczne jest znalezienie sposobu jednoznacznej identyfikacji każdego ucznia. Nazwiska nie na wiele się tu zdadzą, szczególnie w przypad­ku popularnych.

Metoda, która jest wykorzystywana w większości przypadków, polega na dodaniu unikalnego pola ID. 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.

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.

1.5.6 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ła­dowe dane w celu lepszego objaśnienia projektu. Schematy baz danych mogą mieć formę diagramów, diagramów encji i relacji bądź też formę tekstową.

1.5.7 Relacje

Klucze obce ukazują relacje pomiędzy danymi z dwóch różnych tabel. Np. połączenie tabeli Uczniowie z tabelą Oceny odzwierciedla relację między konkretnym wierszem tabeli Uczniowie i określonym wierszem tabeli Oceny.

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 rela­cji. Wyróżnia się więc relacje jeden - do - jednego, 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 każdy uczeń z tabeli Uczniowie jest powiązany relacją jeden-do-jednego z odpowiednim rekordem z tabeli Rodzice. Tabela Rodzice posiadać klucz obcy z tabeli Uczniowie.

W relacji jeden - do - wielu jeden wiersz tabeli jest połączony z jednym wierszem lub wieloma wierszami drugiej. Jeden uczeń może mieć kilka ocen. W przypadku tego typu relacji tabela z wieloma wierszami będzie zawie­rać kolumnę z kluczem obcym pochodzącym z tabeli z jednym wierszem. Dlatego też w tabeli Oceny jest umieszczona kolumn id_ucznia w celu zastosowania tej relacji.

W przypadku relacji wiele - do - wielu wiele wierszy jednej tabeli jest połączonych z wielo­ma wierszami innej. Tego typu relacje są zazwyczaj upraszczane poprzez utworzenie dodatkowej, trzeciej tabeli. Tabela ta zawierałaby tylko pary kluczy obcych pochodzących z dwóch pozostałych tabel. Relację tego typu określa się mianem klucza obcego.

1.6 Internetowa baza danych

1.6.1 Architektura internetowej bazy danych

MySQL jest serwerem bazy danych. Po skonfigurowaniu przyjmuje żądania pochodzące od wielu klientów, którzy są z nim połączeni poprzez sieć. Oczywiście program - klient może być również zainstalowany na komputerze z serwerem bazy, ale w środowisku sieciowym nie jest to zbyt częsty przypadek. Dla użytkowników Microsoft Windows przygotowano sterownik ODBC (Open Database Connectivity), dzięki czemu do serwera z danymi można się dostać poprzez sieć z dowolnej aplikacji Windows obsługującej ten standard.

Dzięki możliwości połączenia się z bazą danych poprzez sieć można uzyskać jednoczesny dostęp do tych samych danych z wielu komputerów. Możemy zatem mieć tylko jedną kopię danych, umieszczoną na centralnym serwerze, do której klienci dostają się poprzez sieć z wielu komputerów z różnymi systemami operacyjnymi. MySQL, podobnie jak inne relacyjne bazy danych, automatycznie obsługuje konflikty przy zapisie do bazy danych. Wszystkim użytkownikom wydaje się, że mają nieograniczony dostęp do wszystkich danych; dzieje się tak dzięki serwerowi MySQL, monitorującemu zmiany danych i przeciwdziałającemu konfliktom.

Możliwość uzyskania przez wielu użytkowników jednoczesnego dostępu do danych i zapewnianie spójności tych danych to bardzo ważne funkcje relacyjnej bazy danych. Jeżeli jakiś
użytkownik zmienia kolumnę, którą chcesz obejrzeć, zobaczysz jej zawartość przed zmianami
lub po nich, ale nigdy w trakcie ich trwania.

Podstawowa operacja wykonywana przez serwer WWW jest ukazana na rysunku 1. Przedstawiony system składa się z dwóch obiektów: przeglądarki internetowej oraz serwera WWW, pomiędzy którymi wymagane jest istnienie połączenia umożliwiają­cego komunikację. Przeglądarka wysyła żądanie do serwera, serwer natomiast prze­syła odpowiedź. Taka architektura sprawdza się w przypadku przesyłania przez ser­wer stron statycznych. System dostarczający przeglądarce strony WWW oparte na bazie danych ma bardziej złożoną konstrukcję.

Rys.1. Relacja klient-serwer między przeglądarką i serwerem WWW wymaga komunikacji.

Rys. 2. Klasyczna architektura internetowej bazy danych zawiera przeglądarkę internetową, serwer WWW, interpreter skryptów oraz serwer bazy danych.

Typowa transakcja bazodanowa przeprowadzana w Internecie składa się z etapów wymienionych na rysunku 2.

1. Przeglądarka internetowa użytkownika wysyła żądanie udostępnienia określonej strony WWW. Wykorzystując odpowiedni formularz HTML, może ona na przykład zażądać wyświetlenia wszystkich uczniów w danej klasie. Strona z wynikami nosi nazwę np. rezultaty.php.

2. Serwer WWW przyjmuje żądanie wyświetlenia strony rezultaty.php, odnajduje właściwy plik i przekazuje go do interpretera PHP.

3. Interpreter PHP rozpoczyna przetwarzanie skryptu. Wewnątrz skryptu zawarte jest polecenie połączenia z bazą danych i wykonania zapytania. Następuje otwarcie połączenia z serwerem MySQL i przesłanie zapytania.

4. Serwer MySQL przyjmuje zapytanie i je przetwarza, po czym rezultat — listę uczniów — odsyła do interpretera PHP.

5. Interpreter kończy wykonywanie skryptu, który zazwyczaj formatuje otrzymane wyniki zgodnie ze standardami HTML, po czym przesyła wynikowy kod HTML do serwera WWW.

6. Serwer WWW przesyła kod HTML do przeglądarki, która wyświetla listę uczniów spełniających kryteria zadane przez użytkownika.

Proces ten przebiega zawsze tak samo, niezależnie od typu interpretera skryptów czy używanego serwera bazy danych. Najczęściej serwer WWW, interpreter PHP oraz serwer bazy danych pracują na tym samym komputerze, nierzadko jednak spotyka się rozwiązania, w których serwer bazy danych działa na oddzielnej maszynie. Metodę tę stosuje się najczęściej do celów bezpieczeństwa lub dla zmniejszenia obciążenia komputerów. Z punktu widzenia projektanta fakt ten nie zmieni sposobu pracy, może jednak przyczynić się do istotnego wzrostu wydajności całego systemu.

1.6.2 Projektowanie internetowej bazy danych

Większość etapów tworzenia schematu bazy danych opiera się na podstawowych zasadach projektowania.

1.6.2.1 Obiekty świata realnego

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 po­winna mieć odpowiadającą jej tabelę. Chcemy na przykład przechowywać informacje o wszystkich uczniach. Jeśli istnieje zbiór danych mający tę samą strukturę, można utworzyć tabelę odpowiadającą tym danym.

1.6.2.2 Przechowywania redundantnych danych

Należy unikać przechowywania w bazie tych samych rekordów.

Tabela 1. Przykład redundantnych danych

User

Id_ucznia	Imię	Nazwisko	Adres	Miejscowość
1 15	Jan Jan	Kowalski Kowalski	Wierzbowa 2 Wierzbowa 2	Warszawa Warszawa

Z ujęciem takim związane są dwa podstawowe problemy.

Pierwszym z nich jest marnotrawstwo pamięci. Po co mamy zapisywać dane Jana dwukrotnie, jeśli wystarczy, że zapiszemy je tylko raz?

Drugim problemem jest możliwość powstania tzw. anomalii uaktualniania, czyli sytu­acji, w której zmiana danych zawartych w bazie prowadzi do utraty ich spójności. Na­ruszona 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 Jan zmieni miejsce zamieszkania, wówczas należy uaktualnić Jego adres w dwóch miejscach bazy zamiast w jednym, co wymaga dwukrotnie 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 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 Jana, zawarte w dwóch różnych wierszach, są ze sobą sprzeczne. W jednym wierszu na przykład może zna­leźć się informacja, iż Jan mieszka w Warszawie, inny natomiast wskazywałby, że jego 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 podczas usuwania wierszy z bazy danych. Usuwając dane Jana z tabeli User może istnieć odwołanie do tego rekordu w innej tabeli w bazie.

Powinniśmy zatem projektować bazy danych w taki sposób, aby nie wystąpiła żadna z powyższych anomalii.

1.6.2.3 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 danych ucznia.

Można dodać kolumnę do tabeli User, w której zapisywane będą wszystkie oceny. Rozwiązanie takie jest przedstawione w tabeli 2.

Tabela 2. Przykład zastosowania nie atomowych wartości kolumn

User

Id_ucznia	Imię	Nazwisko	Adres	Miejscowość	Oceny
1	Jan	Kowalski	Wierzbowa 2	Warszawa	2-, 4, 5

Ten pomysł jest wadliwy z kilku powodów. Prowadzi on bowiem do zagnieżdżania.
w jednej kolumnie wszystkich ocen. Zastosowanie tej metody znacznie utrudni znalezienie odpowiedzi na pytanie typu: „Ile piątek ma dany uczeń?".

System nie może po pro­stu 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 Oceny, pokazaną w tabeli 3.

Tabela 3. Przykład zastosowania atomowych wartości kolumn

Oceny

Id_ucznia	Oceny
1 1 1 2	2- 4 5 3

1.6.2.4 Właściwe klucze

Należy się upewnić, że wyznaczone klucze zagwarantują unikalność rekordów. Dla jednoznacznej identyfikacji ucznia dodane zostało pole id_ucznia, ponieważ te obiekty świata rzeczywistego nie mają natu­ralnego identyfikatora zapewniającego ich unikalność.

1.6.2.5 Puste pola

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, wi­dzą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.

1.6.2.6 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,

• 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.

1.6.2.7 Zapytania do bazy

Projektując bazę danych należy cały czas mieć na względzie informacje, jakie bę­dziemy z niej uzyskiwać. Należy się upewnić, iż baza będzie zawierać wszystkie niezbędne dane oraz że połączenia ustanowione pomiędzy tabelami umożliwią znale­zienie odpowiedzi na pytania użytkownika.

L. Welling, L. Thomson „PHP i MySQL - tworzenie stron internetowych”.

---