Projektowanie baz danych

Autor: Jacek Włodarski

Opublikowano: 2011-04-08

Niniejsza publikacja porusza temat projektowania baz danych. Zacznijmy zatem tak prosto, jak to tylko możliwe. Kluczowym pytaniem, które należy sobie zadać przed rozpoczęciem projektowania, jest – czym właściwie jest baza danych? Jeśli odpowiedź miałaby zostać zawarta w jednym zdaniu, brzmiałoby ono mniej więcej tak: „baza danych jest zbiorem informacji powiązanych ze sobą tematycznie”. Baza danych ma za zadanie przechowywać informacje dotyczące poszczególnych przedmiotów lub osób.

OK, ale czemu właściwie nie użyć do tego celu prostego dokumentu tekstowego? Oczywiście możemy otworzyć notatnik i zacząć wypisywać dane, np. naszych kolejnych klientów, w postaci długich łańcuchów znaków. Przypuszczam, że dla kilku, a nawet kilkudziesięciu klientów jest to całkiem proste i możliwe do wykonania. Jednak w momencie, gdy będziemy chcieli wyszukać nazwisko interesującego nas klienta spośród wszystkich zapisanych, napotkamy już pewien problem. Dla większej liczby klientów będziemy musieli niestety przeskrolować już cały dokument w celu znalezienia interesującego elementu, co nie będzie już takie łatwe, a na pewno niezbyt wygodne. Może zatem zeszyt programu Excel? Jest to na pewno lepszy pomysł niż zwykły dokument tekstowy, ma jednak również wiele wad – bo co zrobić w przypadku, gdybyśmy chcieli wyświetlić np. dziesięciu najlepszych klientów z bazy kilku tysięcy osób? Masz rację, na pewno jest to możliwe, jednak nie takie proste. Zarządzanie dużą ilością danych w dokumencie programu Excel będzie na pewno skomplikowane. A co w sytuacji, gdybyśmy chcieli podzielić się tymi danymi z innymi osobami w naszej organizacji? Może zapisać je na pulpicie i wysłać mailem? Odpowiedź jest prosta –  potrzebujemy narzędzia, które ułatwi nam zarządzanie dużą ilością informacji. Wbrew początkowym zarzutom co do funkcjonalności w pewnym sensie nawet dokument tekstowy, przy spełnieniu pewnych założeń, możemy nazwać bazą danych. Jednak dopiero wtedy, gdy zarządzanie tymi danymi będzie względnie łatwe, taki dokument będziemy mogli nazwać bazą danych – a nie śmietnikiem, w którym znajduje się wszystko, ale nic nie można znaleźć.

Baza danych może zawierać: tabele, kwerendy, formularze, raporty, makra, moduły i skróty do stron dostępu do danych, które znacząco ułatwiają zarządzanie nawet olbrzymią ilością informacji. Podstawową funkcją każdej aplikacji bazodanowej jest przechowywanie pewnych informacji o wybranych przedmiotach oraz określenie sposobu, w jaki dane powinny być przechowywane i zarządzane.

W trosce o to, aby tworzona przez nas baza danych spełniała wspomniany wcześniej szereg użyteczności niezwykle ważne jest, aby cały ten cykl wytwarzania rozpocząć od etapu projektowania. „Ale ja tworzę niewielką bazę danych dla mojej małej firmy, więc po co mi te wszystkie projekty?”. Otóż często, gdy tworzony jest prosty projekt informatyczny, pomija się etap jego projektowania. Rozważmy przez chwilę, czy słusznie. Niezależnie od stopnia złożoności projektu po pewnym czasie stajemy przed koniecznością dokonania w nim zmian. Zmiany, lub może poprawki, mogą wynikać na przykład z rozszerzenia funkcjonalności bazy danych. W przypadku gdy owa baza danych nie opierała się na projekcie z podstawowymi założeniami, jest niestety wysoce prawdopodobne, że w momencie jej rozszerzania lub modyfikacji natkniemy się na błędy spójności. Wtedy często łatwiej będzie zbudować nową bazę danych od podstaw, pomimo że zmiany miały być niewielkie. Przed rozpoczęciem budowania bazy danych należy zatem koniecznie poświęcić nieco czasu na jej zaprojektowanie. „Stracony” w ten sposób czas odzyskamy w kilkakrotnie większym wymiarze podczas dalszych etapów wytwarzania bazy danych. Projektowanie bazy danych wymaga umiejętności spojrzenia na informację jako na zbiór danych opisujących poszczególne przedmioty, oraz związki (relacje) zachodzące pomiędzy poszczególnymi obiektami. Dobry projekt jest podstawą utworzenia bazy danych, która pozwoli na szybkie, dokładne i skuteczne wykonywanie zamierzonych celów.

Przed przystąpieniem do opisywania kolejnych etapów projektowania bazy danych warto zdefiniować co jest czym w bazie danych. Każdy wiersz zwany jest często rekordem, a kolumna – polem. Rekord jest spójnym i znaczącym sposobem scalania informacji na dany temat. Pole stanowi typ elementu występujący w każdym rekordzie.

Pierwszym krokiem, jaki musimy postawić w momencie zabierania się za projektowanie bazy danych, a raczej systemu zarządzania bazą danych, jest określenie celu, któremu ma ona służyć, oraz sposobu jej używania. Musimy przecież wiedzieć, jakich informacji ma nam dostarczać i jak z tych informacji właściwie skorzystać. Na tej podstawie określimy, jakie zagadnienia będą przez nią analizowane oraz jakich informacji użyjemy do opisu tych zagadnień. Na pewno warto porozmawiać z przyszłymi użytkownikami bazy danych o tym, na jakie pytania ma im ona odpowiadać – bo do tego w końcu ją stosujemy. Przed przystąpieniem do budowy tabel, kwerend, formularzy i innych obiektów warto pokusić się o naszkicowanie projektu na kartce papieru i jego dokładne przeanalizowanie. Wstępne zarysy wzorów raportów i formularzy pozwolą lepiej zobrazować nam funkcje, jakie będzie pełniła baza danych. Dla jeszcze lepszego efektu warto zapoznać się z działaniem już istniejących, dobrze zaprojektowanych baz danych, podobnych do tej, która ma być utworzona.

Aby uniknąć rozczarowań ze strony przyszłych użytkowników, warto już na początku zapytać ich o wizję projektowanej aplikacji bazodanowej. Powinniśmy zebrać informacje na temat tego, jak każdy z nich wyobraża sobie tą bazę danych oraz jakie ma wymagania co do jej działania. Jak powinna ona funkcjonować oraz na jakie pytania mu odpowiadać. Innymi słowy, powinniśmy określić oczekiwania wobec aplikacji z punktu widzenia osób, które będą z niej korzystały. Na tym etapie zbierania wymagań ważne jest, aby pod uwagę wziąć perspektywę każdego z użytkowników – da nam to pewność, że zbudowana przez nas baza danych będzie odzwierciedleniem ich wizji, a jeśli ta jest nierealna, to informacja o tym dotrze do nich natychmiast, co da im czas na przeredagowanie ich oczekiwań. Podczas zbierania wymagań mogą pojawić się pomysły przyszłych użytkowników co do jej działania. Nie każdy pomysł będzie oczywiście właściwy i logiczny, ale w tym już nasza głowa, żeby to odpowiednio zrealizować i dopasować do naszej wizji, a w końcu przetłumaczyć na projekt bazodanowy. Na tym etapie potrzebować będziemy przede wszystkim opisów wykorzystywanych i tworzonych danych, szczegółów dotyczących sposobów wykorzystania lub tworzenia bazy danych. Najlepiej, gdyby początkowa ilość informacji nie prowadziła jednak do paraliżu analitycznego z powodu danych, których przetworzenie, uwzględnienie i opisanie w dokumentach zajęłoby mnóstwo czasu. Z wiadomych przyczyn nie powinniśmy również traktować tego etapu zbyt pobieżnie. Zarządzanie wymaganiami użytkowników polegać więc będzie na analizie ich perspektyw, znalezienie cech wspólnych i tych, które je różnią. Jeśli wymagania użytkowników zmierzają w jednym kierunku i w znacznym stopniu się pokrywają, a model aplikacji bazy danych nie wygląda na zbyt skomplikowany, możemy zabierać się za modelowanie związków encji. Jeśli natomiast wymagania użytkowników rozmijają się na różnych płaszczyznach, nasza rola polegać będzie na zorganizowaniu wizji poszczególnych użytkowników w odrębne związki encji, które w końcowej fazie zostaną ze sobą powiązane. Na tym etapie możemy mówić o projektowaniu konceptualnym, czyli konstrukcji modelu całkowicie niezależnego od takich szczegółów implementacyjnych, jak oprogramowanie docelowe, programy użytkowe, języki programowania czy platforma sprzętowa. Kontroli podlega jedynie zgodność z wymaganiami użytkowników. Po skończeniu zbierania wymagań można zabrać się już za pierwsze elementy wchodzące w skład projektu.

Ale czy każdy projekt jest dobry? Co muszę wiedzieć, żeby stworzyć dobry projekt bazy danych? Termin „Model bazy danych (inaczej Projekt bazy danych)” kryje w sobie zbiór zasad, którymi należy się posługiwać podczas tworzenia bazy danych. A zatem jedną z najważniejszych rzeczy podczas planowana projektu jest zrozumienie, że całym procesem jego realizacji kierują pewne niezmienne zasady. Główne zasady przedstawimy w kolejnych podpunktach.

Pierwszą wspomnianą zasadą jest nawyk minimalizacji rozmiaru danych przechowywanych w bazie danych. Zrealizowanie tego punktu polega, najprościej mówiąc, na redukowaniu zbędnych danych oraz zapewnieniu ich integralności. Przechowywanie tych samych danych w jednym miejscu, w jednym rekordzie minimalizuje szanse, że jakaś wersja tej danej będzie niepoprawna. A jeśli nawet w trakcie jej użytkowania dojdzie do tego, że któraś wartość zostanie niepoprawnie wprowadzona, zostanie ona wyświetlona we wszystkich miejscach w ten sam sposób, przez co łatwiejsze będzie wychwycenie błędu.

Drugim aspektem, na który warto zwrócić uwagę, jest rozłożenie większych zbiorów danych na mniejsze, powiązane ze sobą elementy. Podział na mniejsze tabele, a następnie relacyjne ich połączenie sprawi, że nie usuniemy przez przypadek danej, którą uważaliśmy za niepotrzebną, a która – jak się okazuje – ma powiązania z innym elementem. Jeśli cała baza danych podzielona jest na mniejsze części, to jeśli zajdzie potrzeba przywrócenia jakiegoś jej elementu, nie trzeba będzie przywracać całej bazy danych, a wystarczy kawałek, w którym znajduje się ten element.  Dodatkowo, aby zapewnić lepszą integralność danych niezbędne jest zdefiniowanie, jaki typ danych chcemy przechowywać w danej kolumnie. Chodzi o to, żeby uniemożliwić wpisanie litery tam, gdzie jakaś wartość przyjmuje tylko liczbową postać, co uczyni już na starcie bazę danych bardziej poprawną, a to z kolei podniesie jej integralność.

Wiemy już, jakie cechy powinien posiadać dobry projekt, a więc zajmijmy się przez chwilę tabelami i określaniem pól, z których się ona składa. Zacznijmy od tego, że tabela jest zbiorem informacji na jeden określony temat. Dzięki tej cesze jesteśmy w stanie przetwarzać jedno zagadnienie niezależnie od danych dotyczących innych zagadnień. Na przykład, jeśli wyobrazimy sobie bazę danych sklepu, to adresy klientów przechowywalibyśmy w innej tabeli, niż informacje na temat zamówień. W ten sposób możliwe jest usunięcie konkretnego zamówienia, zachowując dane o kliencie nie zmienione. Jeśli właśnie w taki sposób określimy tabele, to w następnym kroku możemy zabrać się za określanie pól w tabeli. Pole zawiera więc jedną daną dotyczącą tego zagadnienia, któremu poświęcona jest tabela. Dobrym nawykiem podczas definiowania pól jest pamiętanie o tym, aby:

• przechowywać informacje w możliwie najmniejszych jednostkach logicznych (np. imię i nazwisko jako osobne pola, a nie jako jedno pole – nazwa użytkownika),
• nie należy tworzyć pól zawierających dane pośrednie lub obliczone (dane, które są wynikiem wyrażenia, uzyskuje się za pomocą kwerend, ale nie przechowuje się bezpośrednio w bazie danych – jest to zły nawyk),
• każde pole powinno być powiązane bezpośrednio z zagadnieniem, którego dotyczy tabela.

Po zakończeniu określania zawartości kolumn w każdej tabeli możemy przystąpić do wyboru klucza podstawowego.

Ale czym jest i do czego nam posłuży klucz podstawowy? Służy on do unikatowej identyfikacji poszczególnych wierszy danej tabeli. Działa na podobnej zasadzie, jak np. numer seryjny przedmiotu czy numer identyfikacyjny pracownika. Konkretnie – może nim być na przykład identyfikator produktu lub identyfikator zamówienia. Klucz podstawowy służy do powiązania informacji przechowywanych w różnych tabelach. Na przykład, aby powiązać klienta ze wszystkimi jego zamówieniami, każda tabela w bazie danych musi zawierać pole lub zbiór pól, które jednoznacznie określają każdy wiersz w tej tabeli (po to, żeby np. określić jednoznacznie danego klienta lub konkretne zamówienie). Kluczem podstawowym nie mogą być duplikujące się wartości, takie jak imiona czy nazwiska, ponieważ takie dane mogą się powtórzyć. Unikatowym natomiast może być numer produktu czy zamówienia. Zazwyczaj rolę klucza podstawowego odgrywa dowolny unikatowy numer, a służy on wyłącznie do identyfikowania danego produktu czy zamówienia. Numer ten zostaje określony raz i nigdy się nie zmienia dla danego produktu, co sprawia, że jednoznacznie go określa. Warto zauważyć, że niekiedy może być wymagane użycie dwóch lub większej liczby pól, które razem będą stanowiły klucz podstawowy tabeli (zostanie to dokładniej przybliżone w dalszej części).

Dopiero po tak określonej i przygotowanej strukturze tabel możemy zacząć wprowadzać do nich wszystkie potrzebne dane, a na ich podstawie tworzyć następnie dowolne kwerendy, formularze, raporty, makra czy moduły.

Zastanówmy się zatem, jak stworzyć odpowiednią strukturę do przechowywania danych oraz jak podzielić cały stos informacji na konkretne tabele. Jednym z rozwiązań jest zastosowanie metody kolejnych podziałów, najpierw na główne jednostki, następnie każdą jednostkę na mniejsze części czy może tematy. Dla uproszczenia skupimy się teraz na dosyć oczywistej sytuacji – sprzedaży produktów. Utworzymy wstępną wersję listy, za pomocą której spróbujemy zorganizować w pewien sposób posiadane informacje.

Nazwy tabel zostały określone przez słowa odpowiadające na główne pytania naszego małego biznesu, czyli: kto kupuje, co kupuje, jak kupuje? Konsekwentnie odpowiedzi to: Klient, Produkt, Zamówienie. A zatem intuicyjnie rysowane są w naszej wyobraźni trzy tabele: jedna zawierająca informacje dotyczące klientów, jedna dotycząca produktów oraz jedna z produktami zamawianymi przez klientów. Tak zdefiniowana lista jest dla nas  bardzo dobrym punktem startu, do którego możemy następnie dodawać kolejne elementy.

Rys.1. Wstępne określenie nazw i zawartości tabel.

Być może ktoś zapyta, po co tak komplikować sprawę? Czemu nie wrzucić wszystkiego do jednej tabeli – przecież w rezultacie wszystko dotyczy mniej więcej jednego tematu – sprzedaży produktów. A zatem spróbujmy zrealizować to w postaci jednej tabeli, poprzez połączenie ze sobą tabeli Produkty oraz tabeli Zamówienia. W rezultacie w jednym wierszu otrzymamy wszystkie dane dotyczące produktu oraz wszystkie dane dotyczące tego zamówienia. Każdorazowo, przy nowym zamówieniu dane produktu są przepisywane do kolejnych wierszy. W ten sposób niepotrzebnie zaśmiecamy bazę danych. Ok, być może się czepiam, ale co w przypadku, gdy chcielibyśmy zmienić nazwę produktu lub jego ilość – pokaż mi, w którym miejscu mam to zmienić? Może najlepiej poprawić wszystkie zamówienia? Istnieje duże ryzyko, że przeoczymy niektóre miejsca, a to z kolei będzie skutkowało błędami podczas tworzenia raportów czy kwerend. Zapisanie nazwy produktu tylko w jednym miejscu rozwiązuje ten problem. A zatem najbardziej rozsądnym podejściem jest rejestrowanie każdej informacji, o ile to możliwe, tylko jeden raz. Pójdźmy jeszcze krok do przodu i załóżmy, że w naszej bazie mamy tylko jeden produkt, a trzeba usunąć ten produkt przy jednoczesnym zachowaniu informacji na temat zamówień, które do tej pory były realizowane. Chwileczkę, ale jak usunąć tylko informacje dotyczące produktu bez utraty informacji o zamówieniach? Niestety, to niemożliwe, ponieważ każdy rekord zawiera informacje dotyczące produktu i zamówień i nie można usunąć tylko informacji dotyczących produktu. A zatem jak rozwiązać ten problem? Należy rozbić tę tabelę na dwie osobne. W ten sposób pozbędziemy się opisanego wyżej problemu. Rozbijanie na jak najmniejsze elementy składowe dodatkowo ułatwia wyszukiwanie, filtrowanie oraz sortowanie.

Warto pomyśleć o tym, aby nasza baza danych była uniwersalna dla danych, które będziemy tam przechowywać, tzn. czy np. w bazie danych będą przechowywane jedynie informacje krajowe, czy również międzynarodowe, bo o ile w pole województwo jesteśmy w stanie wpisać któreś polskie województwo, to już np. za zachodnią granicą są to landy. Z zagranicznym adresem będzie problem i wystąpi nieścisłość określeń. Wtedy frazę województwo lepiej zastąpić nazwą np. region.

Jeśli mamy już zdefiniowane tabele, rekordy oraz klucze podstawowe, nie pozostaje nam nic innego, jak poprawnie połączyć powiązane dane w logiczną całość. Takie właśnie połączenie pomiędzy tabelami nazywamy relacjami.

Ażeby zabrać się za tę operację, należy przejrzeć wszystkie tabele i zdecydować, jaka jest relacja danych z jednej tabeli do danych w innych tabelach. Aby jasno określić relacje, niekiedy trzeba dodać nowe tabele. W relacyjnej bazie danych informacje są rozdzielane do osobnych, tematycznych tabel. Dla poszczególnych sytuacji, z którymi mamy do czynienia, możemy zdefiniować kilka typów relacji: „jeden do wielu”, „jeden do jednego” oraz „wielu do wielu”. Zastanówmy się przez chwilę, co na pierwszy rzut oka, jakie tabele oraz jakie elementy mogłyby stanowić podwaliny bazy danych, np. sklepu. Proponuję na początek: [Produkty] [Klienci] [Zamówienia]

Jeśli chcielibyśmy określić relację w naszej bazie danych pomiędzy tabelami Produkty oraz Klienci, to łatwo zauważyć, że jednemu klientowi może być przyporządkowanych kilka produktów, dlatego relację należy określić „jeden do wielu”. No to teraz bardziej konkretnie, aby zrealizować praktycznie relację „jeden do wielu”, należy klucz podstawowy z tabeli Klienci („jeden”) dodać jako kolumnę do tabeli Produkty („Wiele”). W tabeli Produkty kolumna ta jest kluczem obcym. Klucz obcy to, jak łatwo zauważyć, klucz podstawowy innej tabeli. Sprzęganie tabel polega zatem na ustanawianiu takich par kluczy podstawowych i obcych. Teraz trochę przyśpieszymy. Co w przypadku, kiedy każdemu produktowi może odpowiadać wiele zamówień, a każdemu zamówieniu może odpowiadać wiele produktów? Samo się nasuwa, żeby zastosować relację „wiele do wielu”. Należy zauważyć, że aby wykryć relację „wiele do wielu” pomiędzy tabelami, trzeba się przyjrzeć obu stronom relacji. Tym razem niestety nie możemy postąpić podobnie, jak w przykładzie powyżej. Jeśli dodamy klucz podstawowy tabeli Produkty (identyfikator tabeli Produkty) do tabeli Zamówienia, to o ile dla zamówienia zawierającego jeden produkt byłoby możliwa do zrealizowania relacja „jeden do wielu”, to przy zamówieniu zawierającym wiele produktów należałoby dla każdego produktu tworzyć nowe zamówienie. Podobnie dla sytuacji odwrotnej – kiedy identyfikator tabeli Zamówienia dodamy do tabeli Produkty. Tym razem dla każdego produktu w tabeli Produkty pojawi się więcej niż jeden rekord. Wyjściem z tej sytuacji jest utworzenie trzeciej tabeli, która rozłoży relację „wiele do wielu” na dwie relacje „jeden do wielu”, znaną już z wcześniejszego przykładu. Zastosowanie trzeciej tabeli sprawi, że między tabelami Produkty i Zamówienia nie wystąpi relacja bezpośrednia, tylko pośrednia z użyciem dodatkowej tabeli. Zawiera ona klucze podstawowe z obydwu tabel, a jej zadaniem jest zarejestrowanie wystąpienia każdej relacji, jaka zachodzi pomiędzy tymi tabelami.  Nazwijmy nową tabelę „Realizacja zamówień”. Tabela ta również będzie posiadać swój klucz podstawowy. Tym razem nie wystarczy użycie np. klucza podstawowego tabeli Zamówienia do jednoznacznego określenia rekordu, ponieważ jedno zamówienie może mieć kilka pozycji, a ten powtarza się w każdej z pozycji zamówienia, więc to pole powtarza się, a jak wcześniej zaznaczyliśmy – wymagane jest, żeby klucz podstawowy zawierał unikatowe wartości. Użycie samego pola „identyfikator produktu” również się nie sprawdzi, ponieważ jeden produkt również może występować w wielu zamówieniach. Ale te dwa pola razem stanowią już wartość unikatową dla każdego wiersza. A zatem wynikowo otrzymaliśmy dwie relacje „jeden do wielu”. Taka relacja występuje pomiędzy tabelą Zamówienia a tabelą Realizacja zamówień, ponieważ każde zamówienie może zawierać więcej niż jedną pozycję, ale każda pozycja jest powiązana tylko z jednym zamówieniem. Natomiast pomiędzy tabelą Produkty a tabelą Realizacja zamówień – z każdym produktem może być skojarzonych wiele pozycji, ale każda pozycja odwołuje się tylko do jednego produktu.

Ostatnim typem relacji, z jakim możemy mieć do czynienia, to relacja „jeden do jednego”. Jeśli chodzi o ten typ relacji, to w praktyce najczęściej jest on wykorzystywany podczas tworzenia tabel uzupełniających inne tabele, np. o dodatkowe albo promocyjne produkty, które na przykład są tymczasowe. Nie zapisano ich w tabeli Produkty, ponieważ są np. bardzo rzadko używane. A więc jedynie by przeszkadzały, pozostawiając puste rekordy w wielu miejscach. Taka uzupełniająca tabela oczywiście również posiada klucz podstawowy. Tym razem przy relacji „jeden do jednego” dla każdego rekordu w tabeli Produkty istnieje jeden pasujący rekord w tabeli uzupełniającej. A zatem, podsumowując typy relacji – jeśli istnieje relacja „jeden do jednego” lub „jeden do wielu”, to tabele uczestniczące w tych relacjach muszą używać co najmniej jednej wspólnej kolumny, natomiast w przypadku relacji „wiele do wielu” relację tę przedstawia trzecia, osobna tabela.

Dla właściwego odwzorowania i przedstawienia abstrakcyjnej struktury projektu bazy danych stosuje się diagramy ERD (Entity Relational Diagram). Innymi słowy jest to modelowanie związków encji, które obejmuje dane oraz powiązania między nimi. Jest to graficznie, poprzez diagram, przedstawienie związków encji. Gotowy model związków encji nietrudno przekształcić już w relacyjny model danych. Encja to rzecz, obiekt (abstrakcyjny). Zbiór encji to natomiast kolekcja podobnych encji. Atrybuty to właściwości encji tych zbiorów. Relacja/związek to połączenie dwóch lub więcej zbiorów encji. Przykład prostego diagramu związków encji znajduje się na rysunku 2.

**Rys.2. Diagram związków encji.

Każdy klient może złożyć jedno lub wiele zamówień, natomiast każde zamówienie musi być zlecone przez jednego i tylko jednego klienta.

Kiedy wszystko wydaje się już praktycznie gotowe, oznacza to, że przyszedł czas na udoskonalanie projektu. W tym kroku będziemy sprawdzać, jak sprawują się jego poszczególne elementy. Uzupełniamy tabele o przykładowe dane, a na ich podstawie wykonujemy próbne operacje, tworzymy kwerendy, dodajemy nowe rekordy itp. Dzięki temu będziemy w stanie zlokalizować potencjalne problemy. Może okazać się, że w tabelach występują zduplikowane dane, że istnieje niepotrzebna tabela lub zastosowaliśmy złą relację do ich połączenia. Przed nami dokładne sprawdzenie projektu pod kątem wszelkich błędów. Warto stworzyć robocze wersje raportów czy formularzy i sprawdzić, czy generują one odpowiednie dane. Wychodząc z założenia, że nie myli się jedynie ten kto nic nie robi, prawdopodobnie w naszym projekcie nie unikniemy początkowych błędów. Ażeby zmaksymalizować funkcjonalność bazy danych, warto odpowiedzieć sobie na szereg pytań, które mogą wydać się trywialne, ale kto wie, czy nie zaoszczędzą nam wiele czasu przy wyszukiwaniu usterki, kiedy po wdrożeniu aplikacji okaże się, że jednak coś nie działa. Warto również wrócić do początkowego szkicu z kartki papieru i sprawdzić, na ile odpowiada on obecnemu projektowi. Przykładowe pytania mogą wyglądać np. tak:

• Czy nie zapomniałem jakiejś kolumny? Jeśli tak, to czy jestem w stanie ją wrzucić do już istniejącej tabeli? Jeśli tak, to świetnie, a jeśli nie – to trzeba będzie dodać nową tabelę i na nowo przeanalizować jej powiązania z innymi tabelami.
• A może któraś kolumna jest zbędna? Jeśli tak, to po jej usunięciu zaoszczędzimy trochę cennego miejsca.
• Czy przypadkiem informacji zawartych w tej kolumnie nie mogę obliczyć na podstawie innych tabel? Jeśli tak, po co je duplikować? Zazwyczaj lepiej jest obliczać te wartości, stosując np. kwerendy (jeśli to tylko możliwe), niż tworzyć nową kolumnę.
• Czy wszystkie informacje rozbiłem na najmniejsze, użyteczne części? Wiadomo przecież, że nie ma sensu rozbijać np. nazwy produktu „Wąż od pralki” na trzy kolumny: „Wąż” „od” „pralki” albo na węża i pralkę, bo to jedynie skomplikuje naszą bazę danych. Jeśli ten aspekt jest dopracowany, możemy śmiało tworzyć raporty, sortować i wyszukiwać.
• Czy wszystkie kolumny danej tabeli rzeczywiście zawierają informacje dotyczące dokładnie tematu tej tabeli? Jeśli nie, to dla porządku oraz uniknięcia problemów w przyszłości należy taką kolumnę przenieść do innej tabeli.

Ostatnim etapem weryfikacji poprawności projektu bazy danych jest sprawdzenie, czy umożliwia ona wszystkie podstawowe funkcje:

• projektowanie rekordów:
  - nazwa pola,
  - długość pola,
  - rodzaj pola (tekstowe, liczbowe, logiczne),
• edycja (dopisywanie, usuwanie, poprawianie rekordów),
• sortowanie,
• wyszukiwanie i selekcja danych,
• tworzenie zapytań,
• tworzenie raportów,
• drukowanie.

Bezcelowy byłby nasz cały wywód bez etapu, jakim jest implementacja projektu. Innymi słowy, jest to fizyczna realizacja projektów bazy danych. Wykonywana jest za pomocą języka definicji danych wybranego systemu zarządzania bazą danych lub za pomocą graficznego interfejsu.

Podsumowanie

W tym artykule pokazano, jak właściwie zrealizować projekt bazy danych.