Przeczytaj
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.
Zwróć uwagę na wyróżnione w opisie wyrazy. Będą one punktem wyjścia w procesie przebudowy bazy.
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:
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:
Wniosek 1
Gdyby udało się zredukować powtarzające się (redundantneredundantne) dane do pojedynczego wystąpienia, można byłoby zaoszczędzić sporo miejsca i uczynić strukturę bazy danych bardziej czytelną.
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ą.
Wniosek 2
Ograniczenie zapisu tych samych danych do tylko jednego miejsca pomogłoby zminimalizować ryzyko wystąpienia tzw. anomalii przy aktualizacji danych, a więc uniknięcia błędu polegającego na pominięciu niektórych wystąpień podczas dokonywania zmian.
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):
Wniosek 3
Rozdzielenie danych adresowych na mniejsze porcje ułatwiłoby wprowadzanie nowych danych do bazy oraz przyspieszyłoby generowanie niektórych zestawień.
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.
Wniosek 4
Gdyby można było usunąć konkretne zamówienie bez usuwania danych o kliencie, zachowalibyśmy dane, dzięki którym moglibyśmy utrzymać kontakt z klientem.
Ż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 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. encjeencje, czyli dające się wyodrębnić obiekty lub zdarzenia, które mogą być opisane za pomocą zestawu cech zwanych atrybutamiatrybutami.
Każda z wyodrębnionych encji stanowi punkt wyjścia do stworzenia tabeli – podstawowej jednostki budującej relacyjną bazę danych.
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:
Prezenty | |
---|---|
nazwa kolumny | opis |
KodPrezentu | unikalny numer, pod którym figuruje w bazie dany prezent |
NazwaPrezentu | krótka nazwa prezentu, np. Świeca woskowa - choinka |
Zdjęcie | plik graficzny lub link do zasobu |
LiczbaPunktów | liczba punktów, które klient może wymienić na dany prezent |
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:
Klienci | |
---|---|
nazwa kolumny | opis |
KodKlienta | unikalny numer, pod którym figuruje w bazie dany klient |
Imię | imię klienta |
Nazwisko | nazwisko klienta |
UlicaNr | ulica i numer w adresie kontaktowym podanym przez klienta, np. Akacjowa 23/2 |
KodPocztowy | kod pocztowy w formacie 00‑000 |
Miejscowość | miejscowość w adresie zapisywana obok kodu pocztowego |
LiczbaPunktów | liczba punktów zgromadzonych przez klienta za dotychczasowe zakupy |
LiczbaZakupów | liczba dokonanych zakupów w sklepie przez klienta |
Telefon | numer telefonu kontaktowego do klienta |
podany przez klienta kontaktowy adres e‑mail |
Tabela Produkty:
Struktura tabeli Produkty:
Produkty | |
---|---|
nazwa kolumny | opis |
KodProduktu | unikalny numer, pod którym figuruje w bazie dany produkt |
NazwaProduktu | krótka nazwa produktu, np. Miód rzepakowy |
Pojemność | liczba oznaczająca pojemność produktu wyrażona w litrach |
CenaZaSztukę | cena za jedną sztukę produktu wyrażona w PLN |
LiczbaSztukDoSprzedania | ile sztuk danego produktu jest aktualnie dostępnych w sprzedaży |
Tabela Zamówienia:
Struktura tabeli Zamówienia:
Zamówienia | |
---|---|
nazwa kolumny | opis |
KodZamówienia | unikalny numer, pod którym figuruje w bazie określone zamówienie |
KodKlienta | unikalny numer, pod którym figuruje w bazie dany klient |
KodProduktu | unikalny numer, pod którym figuruje w bazie określony produkt |
LiczbaSztuk | liczba sztuk zamówionego przez klienta produktu |
Należność | cena, jaką klient musi zapłacić za zamówione produkty |
DataZamówienia | data złożenia zamówienia |
Zwróć uwagę, że dzięki uwzględnieniu w projektach tabeli Klienci pola KodKlienta oraz w tabeli Produkty pola Kod Produktu w pojedynczym wierszu tabeli Zamówienia zamiast pełnej informacji o kliencie i o produkcie wystąpią dwie liczby, które jednoznacznie określają, kto i jakiego zakupu dokonał. To ogromny zysk, ponieważ nie musimy powielać danych raz wpisanych do bazy. Minimalizujemy również ryzyko popełnienia błędu podczas aktualizacji danych, ponieważ zmiana dokonana w jednym miejscu zostaje uwzględniona we wszystkich wystąpieniach tej danej w całej bazie.
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.
Przeprowadzony proces wyodrębnienia encji i doprowadzenia bazy do postaci powiązanych ze sobą tabel nazywamy normalizacjąnormalizacją.
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
nadmiarowość, czyli wielokrotne występowanie tych samych danych
baza danych, w której dane przechowywane są w postaci wzajemnie powiązanych ze sobą tabel
wyodrębnione obiekty, które można opisać za pomocą pewnych cech (atrybutów), np. klient, zamówienie, produkt
jednostkowa cecha opisująca encję (inaczej: kolumna tabeli), np. atrybutami tabeli Klienci mogą być: Imię, Nazwisko, Telefon itd.
doprowadzenie do takiej organizacji danych w bazie, która wyeliminuje powtórzenia danych, a w konsekwencji pozwoli uniknąć tzw. anomalii podczas użytkowania bazy danych