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.