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