Wymagania funkcjonalne bazy danych

Sklep z produktami pszczelimi rodziców Tomka działa coraz prężniej. Do tej pory do rejestrowania sprzedaży wystarczył prosty arkusz z następującą zawartością:

W związku z rozwojem działalności produkcyjno‑sprzedażowej pojawiły się większe wymagania co do funkcjonalności bazy:

• asortyment jest coraz bardziej zróżnicowany zarówno jeśli chodzi o rodzaje miodu, jak i oferowane pojemności,

• coraz większa liczba zamówień wymaga posiadania aktualnej informacji o bieżącym stanie magazynowym oferowanych produktów (pozwala mieć rozeznanie w kwestii, ile czego jest, czego zaczyna brakować oraz co już nie jest dostępne),

• ze względu na coraz większą liczbę klientów identyfikowanie ich tylko po imieniu już nie wystarcza,

• niektórzy klienci zamawiają produkty telefonicznie lub internetowo i proszą o przesłanie zamówienia na wskazany adres, stąd potrzeba gromadzenia danych teleadresowych klientów,

• aby zachęcić do częstszych zakupów, właściciele sklepu chcą wprowadzić system lojalnościowy nagradzania klientów za pierwsze i kolejne zakupy:
  - po pierwszych oraz po co piątych kolejnych zakupach wysyłany byłby losowy prezent,
  - w zależności od liczby zdobytych punktów, które będą naliczane proporcjonalnie do ilości zakupionego miodu (liczonego w litrach), klient będzie mógł sam wybrać dla siebie prezent z przygotowanego katalogu,

• prezenty będą stanowiły specjalną kategorię produktów niedostępnych w zwykłej sprzedaży i będą to np. woskowe świece o różnych kształtach, pyłek pszczeli, pierzga, propolis, mleczko pszczele.

Analiza wymagań w odniesieniu do istniejącej bazy

Gdyby uwzględnić przedstawione wymagania poprzez poszerzenie aktualnej bazy w arkuszu o kolumnę z adresem klienta oraz uzupełnić imię o nazwisko, mogłaby ona wyglądać następująco:

Analizując praktyczne wykorzystanie tak zaprojektowanej bazy, Tomek zauważył następujące niedogodności:

1. W wierszach dotyczących zakupów dokonywanych przez tego samego klienta powtarzane są dane związane z adresem oraz imieniem i nazwiskiem, co prowadzi do zużycia dodatkowych zasobów pamięci. Na zdjęciu poniżej przedstawiającym fragment bazy zaznaczono trzy wystąpienia dla tego samego klienta:

2. W razie konieczności aktualizacji danych klienta (np. zmiany nazwiska lub adresu), trzeba dokonać zmian we wszystkich miejscach, w których te dane występują.

3. W kolumnie ADRES KLIENTA cały adres zapisany jest w jednej komórce, co może utrudnić porządkowanie listy zamówień ze względu na miasto czy kod pocztowy (może to mieć znaczenie podczas przygotowywania zamówionych produktów do wysyłki):

4. W przypadku usunięcia zamówienia (na przykład w razie rezygnacji z zakupu) tracimy informację nie tylko o samym zamówieniu, ale również o kliencie. Może wystąpić wówczas zjawisko tzw. anomalii przy usuwaniu danych.

Żeby spełnić wszystkie wymagania określone na początku, potrzebne byłoby jeszcze stworzenie miejsca na przechowanie katalogu prezentów, a także uwzględnienie liczby dokonanych zakupów przez klienta oraz liczby naliczonych punktów za zakupy. Wydaje się to dość trudnym zadaniem, gdyby chcieć umieścić wszystkie te dane w strukturze jednej tabeli w arkuszu.

Skoro więc jedna tabela nie wystarczy do stworzenia odpowiedniej struktury bazy, Tomek uznał, że właściwym rozwiązaniem będzie zaprojektowanie relacyjnej bazy danychrelacyjna baza danychrelacyjnej bazy danych.

Projektowanie relacyjnej bazy danych

Krok 1

W przedstawionym opisie wymagań Tomek rozpoczął od podkreślenia następujących wyrazów:

• klienci,

• produkty,

• zamówienia,

• prezenty.

Postępując w ten sposób, zastosował jedną z zasad obowiązujących w procesie projektowania relacyjnej bazy danych. Zgodnie z tą zasadą w opisie funkcjonalnym projektowanej bazy wyróżnił tzw. encjeencjaencje, czyli dające się wyodrębnić obiekty lub zdarzenia, które mogą być opisane za pomocą zestawu cech zwanych atrybutamiatrybutatrybutami.

Trzy pierwsze tabele Tomek opracował na podstawie istniejącej bazy:

Ponieważ czwartej tabeli o nazwie Prezenty Tomek nie mógł uzyskać z jakichkolwiek kolumn istniejącej bazy, opisał ją następująco:

W ten sposób przedstawił strukturę tabeli jako zestaw atrybutów (kolumn), którym przypisał określone typy danych.

Krok 2

Kolejna zasada projektowania relacyjnych baz danych nakazuje podzielić tabele na kolumny na takim poziomie szczegółowości, który gwarantuje swobodę przeprowadzania podsumowań oraz wyszukiwania danych według potrzebnych kryteriów.

Postępując zgodnie z tą zasadą, Tomek wydzielił w tabeli Klienci następujące kolumny: Imię, Nazwisko, UlicaNr, KodPocztowy oraz Miejscowość. Oprócz tego dodał kolumny:

• LiczbaPunktów oraz LiczbaZakupów, aby gromadzić dane niezbędne do przyznawania prezentów,

• Telefon oraz Email w celu poprawienia komunikacji z klientami (przynajmniej z tymi, którzy na taką formę kontaktu wyrażą zgodę),

• KodKlienta, który posłuży do oznaczenia klienta na konkretnym zamówieniu (zamiast dotychczasowej identyfikacji poprzez imię, nazwisko i adres).

Tabela Klienci uzyskała więc następującą postać:

Struktura tabeli Klienci:

Tabela Produkty:

Struktura tabeli Produkty:

Tabela Zamówienia:

Struktura tabeli Zamówienia:

Krok 3

W kroku tym należy przemyśleć, czy w którejkolwiek z tabel występują kolumny zawierające wartości, które można wyliczyć na podstawie danych przechowywanych w innych kolumnach. Krok ten nie jest obligatoryjny. Należy przeanalizować, czy korzystne jest rezygnowanie z dających się odtworzyć w razie potrzeby kolumn, co z jednej strony oszczędza zasoby pamięci, ale z drugiej – może spowolnić działanie bazy. Przykładem takiej kolumny jest Należność w tabeli Zamówienia, ponieważ wartość ta może być obliczona na podstawie danych z kolumn CenaZaSztukę z tabeli Produkty oraz LiczbaSztuk z tabeli Zamówienia.

Tomek zdecydował, że kolumna Należność w tabeli Zamówienia pozostanie na swoim miejscu ze względu na możliwość łatwiejszego przeprowadzania podsumowań ze sprzedaży, które będą potrzebne do bieżącego monitorowania sprzedaży. Poza tym, ceny produktów mogą się zmieniać i lepiej, gdy pozostanie informacja o faktycznej kwocie transakcji odnotowanej dla obowiązujących cen produktów.

Po wykonaniu projektu bazy według postawionych na początku wymagań Tomek przyjrzał się jeszcze raz opracowanej strukturze relacyjnej bazy danych i doszedł do wniosku, że… przeoczył pewien szczegół dotyczący odnotowywania sprzedaży, który może znacząco poprawić efektywność niektórych operacji w bazie. Wstrzymał się jednak z naniesieniem poprawki w projekcie bazy, bowiem postanowił najpierw skonsultować to ze zleceniodawcą oraz przyszłymi użytkownikami bazy.

A czy ty domyślasz się, o jaki „szczegół” mogło chodzić Tomkowi?

Słownik