Projektowanie bazy danych

Transkrypt

1 Projektowanie bazy danych Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeo wstępnych i określenie podstawowych funkcji aplikacji. Każda baza danych jest projektowana w jakimś celu w oparciu o pewne założenia. Na początku projektu bardzo ważne również jest określenie podstawowych funkcji systemu bazy danych. Oprócz definicji celu należy również sformułowad założenia wstępne. Są to wymagania jakie powinny spełniad dane przechowywane w bazie danych. Definicja Celu Celem jakiemu ma służyd projektowana baza danych jest magazynów wstępne planowanie zapotrzebowania w magazynie, zamówieo. rejestracja pracowników i sprawdzanie cen, realizacja Założenia wstępne Poniżej podano następujące założenia wstępne do systemu obsługi magazynu: Magazyn ma wiele pracowników stałych Pracownicy mogą pracowad w kilku magazynach Klienci zamawiając wyroby składają zamówienia Pojedyncze zamówienie może dotyczyd wielu elementów Elementy są segregowane w magazynie według swoich kategorii Na podstawie zamówienia z uwzględnieniem stanu magazynu elementów tworzy się stan zamówienia W przypadku braku elementów uzupełnia się plan własnymi zamówieniami do magazynu Po zbilansowaniu stanu elementów w magazynie szacuje się czas wyczerpania zapasów Następnie po szacowaniu czasu generuje się odpowiednie powiadomienia o stanie ilości elementów Definiowanie Funkcji systemu baz danych Już na etapie projektowania bazy danych należy określid podstawowe funkcje systemu baz danych. W naszym systemie zarządzania magazynem są to następujące funkcje: Wprowadzenie danych ogólnych (o elementach magazynu, pracownikach itp.) Wprowadzenie danych o klientach Wprowadzenie danych o zamówieniach Wspomaganie tworzenia zamówieo Wyszukiwanie wszystkich zamówieo klienta (pokazywanie obecnego stanu zamówienia) Kontrola pracowników

2 Budowanie diagramu związków między relacjami Metoda przedstawiania związków między relacjami (tabelami) za pomocą diagramu jest bardzo wygodna i znacznie usprawnia proces tworzenia bazy danych. Na diagramie (schemacie) widad od razu wszystkie tabele i powiązania między nimi. Zadanie to najlepiej wykonad w kilki następujących krokach: Identyfikacja zbioru obiektów występujących w danym problemie Identyfikacja powiązao bezpośrednich między obiektami i przekształcenie w pojęciowy model danych (ustalenie typu relacji) Określenie atrybutów kluczowych i pozostałych atrybutów dla wszystkich obiektów. Normalizacja do pierwszej(rozbicie wielowartościowych na jednowartościowe) i drugiej postaci normalnej (rozbicie tabel na dwie lub więcej w celu uniknięcia redundacji danych w tabeli) Normalizacja do trzeciej postaci normalnej, przekształcając relacji typu m:n na powiązania typu 1:n Sprawdzenie poprawności struktury bazy danych poprzez porównanie jej struktury z wymaganiami względem systemu bazy danych. Identyfikacja bezpośrednich zależności między obiektami Po wyróżnieniu obiektów w systemie należy zidentyfikowad wszystkie powiązania występujące między nimi. Pojęciowy model danych Na podstawie identyfikacji bezpośrednich zależności między obiektami możemy utworzyd diagram zależności między obiektami przyszłej bazy danych. Rodzaj relacji należy ustalid na podstawie założeni wstępnych i funkcji aplikacji. Rozważmy kolejno przykłady relacji: Relacja między klientami a złożonymi zamówieniami jest typu jeden do wielu (1:n) ponieważ każdy klient może złożyd wiele zamówieni, natomiast każde zamówienie należy tylko do jednego klienta, Relacja między elementami a zamówieniami jest typu wiele do wielu (m:n) ponieważ na zamówieniu może byd wiele elementów i na każdy element magazynu może byd wiele zamówieo, Relacja między magazynami a elementami magazynów jest typu (m:n) ponieważ każdy element może byd w każdym magazynie i każdy magazyn może mied każdy element Relacja między pracownikami a magazynami jest typu (m:n) ponieważ magazyn może mied wiele pracowników i pracownik może pracowad w kilku magazynach

3 Rysunek 1 Początkowy diagram zależności między obiektami Przekształcenie powiązao typu wiele do wiele. Każde z powiązao typu m:n, ze względu na późniejszą implementację, powinno zostad rozdzielone na dwa powiązania typu jeden do wielu 1:n. Operację tę przeprowadza się wg schematu z ilustrowanego na diagramie poniżej. Rysunek 2 Schemat zastępowania relacji m:n przez dwa powiązania typu 1:n Po zastąpieniu wszystkich powiązao typu m:n z diagramu na rys.1 otrzymujemy diagram docelowy z dodatkowymi obiektami. Jak można zauważyd, na diagramie tym występują tylko relacje 1:n. Taka struktura zależności w bazie danych jest prawidłowa i nadaje się do dalszej analizy tj. ustalenia atrybutów i kluczy co będzie wykonane w następnym punkcie. Rysunek 3 Docelowy diagram zależności między obiektami

4 Określenie atrybutów Biorąc pod uwagę założenia wstępne i funkcje jakie ma pełnid przyszły system baz danych można określid atrybuty dla wszystkich relacji (obiektów) z diagramu docelowego. Oprócz nazw atrybutów zostaną określone ich domeny, czyli praktycznie cała struktura tabel bazy danych. Tabela 1 Klienci Id_Klienta Klucz Identyfikator klienta Integer Adres Atrybut Adres klienta Char(100) wielowartościowy Nazwa_Klienta Nazwa Klienta Char(80) Tabela 2 Zamówienia Id_Zamowienia Klucz Nr zamówienia Integer Id_Klienta Klucz obcy Identyfikator klienta Integer Data_Zamowienia Data zamówienia Data Data_Dostawy Data dostawy Data Transport Rodzaj transportu Char(20) Tabela 3 Zamówienia_Pozycje Id_Zamowienia Składnik klucza, klucz Nr zamówienia Integer obcy Pozycja Składnik klucza Nr pozycji na Integer zamówieniu Id_Elementu Klucz obcy Identyfikator wyroby Integer Ilosc Ilośd zamówiona Decimal(12,3) towaru Cena Cena netto towaru Decimal(12,2) VAT Podatek VAT Decimal(12,2)

5 Tabela 4 Magazyn Id_Magazynu Klucz Identyfikator klienta Integer Adres Atrybut Adres klienta Char(100) wielowartościowy Nazwa_Magazynu Nazwa Magazynu Char(80) Firma Nazwa skrócona firmy Char(20) NIP Numer identyfikacji podatkowej Char(13) Tabela 5 Pracownicy Id_Pracownika Klucz Identyfikator klienta Integer Adres Atrybut Adres klienta Char(100) wielowartościowy Nazwa_Pracownika Nazwa Pracownika Char(80) Tabela 6 Praca Id_Pracownika Składnik klucza, klucz Nr zamówienia Integer obcy Pozycja Składnik klucza Praca wykonywana Char(50) przez pracownika Id_Magazynu Klucz obcy Identyfikator wyroby Integer Etat Czas pracy? Tabela 7 Elementy Id_Elementu Klucz Identyfikator klienta Integer Nazwa_Elementu Nazwa elementu Char(32) Ilośd Telefon do klienta Integer Kategoria Typ produktu Kategoria produktu Char(80)

6 Tabela 8 specyfikacja Id_Magazynu Składnik klucza, klucz Nr zamówienia Integer obcy Id_Elementu Klucz obcy Identyfikator wyroby Integer Ilosc Ilośd towaru w magazynie Decimal(12,3) Sprawdzenie kryteriów normalności tabel Na zakooczenie procesu projektowania należy jeszcze sprawdzid, czy tabele, których strukturę podano w powyższych tabelach są co najmniej w trzeciej postaci normalnej. Przeglądając tabele można zauważyd, że warunki tego nie spełnia tabela Klienci, ponieważ zawiera atrybut wielowartościowy adres. Wobec tego należy przeprowadzid normalizację tych tabel. Po normalizacji, czyli zastąpieniu atrybutu adres przez trzy atrybuty elementarne tj, kod, miasto i ulicę tabela ta otrzymuje postad: Id_Klienta Klucz Identyfikator klienta Integer Nazwa_Klienta Nazwa Klienta Char(80) Kod Kod pocztowy Char(6) Miasto Miejscowośd Char(40) Ulica Ulica Char(30)