Projektowanie bazy danych – przyk³ad

Projektowanie bazy danych - przykład
Projektowanie bazy danych – przykład
Pierwszą fazą tworzenia projektu bazy danych jest postawienie definicji celu, założeń 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łować
założenia wstępne. Są to wymagania jakie powinny spełniać dane przechowywane w bazie danych.
Definicja celu
Celem jakiemu ma służyć projektowana baza danych może być rejestracja zamówień klientów,
wstępne planowanie produkcji, bilansowanie mocy produkcyjnych i obliczanie zapotrzebowania na
materiały do produkcji wyrobów.
Założenia wstępne
Poniżej podano następujące założenia wstępne do systemu planowania produkcji seryjnej wyrobów
prostych:
• producent ma wielu klientów stałych i okazyjnych,
• klienci zamawiając wyroby składają zamówienia,
• pojedyncze zamówienie może dotyczyć wielu wyrobów,
• wyroby wykonuje się w centrach roboczych (np. wtryskarka do tworzyw, maszyna do szycia,
mieszalnik do artykułów spożywczych itp.),
• dla każdego wyrobu jest określony czas przygotowawczo-zakończeniowy, czas jednostkowy
wykonania i centrum robocze w jakim należy wykonać daną operację technologiczną,
• gotowe wyroby przekazuje się do magazynu wyrobów,
• na podstawie zamówień z uwzględnieniem stanu magazynu wyrobów tworzy się wstępny plan
okresowy (np. miesięczny),
• następnie bilansuje się obciążenie centrów (stanowisk) roboczych,
• w przypadku wolnych mocy produkcyjnych uzupełnia się plan własnymi zamówieniami,
• po zbilansowaniu planu produkcji określa się terminy dostaw poszczególnych materiałów i
surowców potrzebnych do realizacji planu, czyli wytworzenia zaplanowanych ilości
określonych wyrobów,
• następnie po zbilansowaniu stanów magazynowych materiałów wysyła się zapotrzebowanie na
materiały do dostawców,
• każdy dostawca dostarcza określoną grupę materiałów,
• materiały przechowuje się w magazynie materiałów.
Definiowanie funkcji systemu baz danych
Już na etapie projektowania bazy danych należy określić podstawowe funkcje systemu baz danych.
W przykładowym systemie planowania produkcji mogą to być następujące funkcje:
• wprowadzanie danych ogólnych (o wyrobach i materiałach z jakich są wytworzone, czasach
technologicznych wykonania wyrobów itp.),
• wprowadzanie danych o klientach,
• wprowadzanie danych o zamówieniach,
• wspomaganie tworzenia wstępnego planu,
• wyszukiwanie wszystkich zamówień klienta,
• wyszukanie wszystkich klientów, którzy zamówili dany towar,
• bilansowanie mocy produkcyjnych,
• obliczanie dziennego zapotrzebowania na materiały i surowce do produkcji,
• generowanie zapotrzebowania na materiały z podziałem na dostawców.
1
Projektowanie bazy danych - przykład
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) widać od
razu wszystkie tabele i powiązania między nimi. Zadanie to najlepiej wykonać w kilku
następujących krokach:
• Identyfikacja zbioru obiektów występujących w danym problemie.
• Identyfikacja powiązań 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 atrybutów wielowartościowych na jednowartościowe) i
drugiej postaci normalnej (rozbicie tabel na dwie lub więcej w celu uniknięcia redundancji
danych w tabeli).
• Normalizacja do trzeciej postaci normalnej, przekształcenie 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 zidentyfikować 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 utworzyć diagram
zależności między obiektami przyszłej bazy danych. Rodzaj relacji należy ustalić na podstawie
założeń 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żyć wiele zamówień, natomiast każde zamówienie należy tylko do
jednego klienta,
• relacja między wyrobami, a zamówieniami jest typu wiele do wielu (m : n), ponieważ na
zamówieniu może być wiele wyrobów i na każdy wyrób może być wiele zamówień,
• relacja między wyrobami, a planami jest typu m : n, ponieważ do każdego planu należy wiele
wyrobów i każdy wyrób może wystąpić w wielu planach,
• relacja między centrami, a wyrobami jest typu m : n, ponieważ każdy wyrób może być
wykonywany na kilku centrach (maszynach) i na każdej maszynie można wykonać wiele
różnych wyrobów,
• relacja między wyrobami, a materiałami jest typu m : n, ponieważ na każdy wyrób może się
składać kilka materiałów oraz ten sam materiał może wchodzić w skład kilku wyrobów,
• relacja między dostawcami, a materiałami jest typu 1 : n, ponieważ każdy dostawca dostarcza
określone materiały, a każdy materiał jest dostarczany tylko przez jednego dostawcę.
Rysunek 1. Początkowy diagram zależności między obiektami
2
Projektowanie bazy danych - przykład
Przekształcenie powiązań typu wiele do wiele.
Każde z powiązań typu m : n, ze względu na późniejszą implementację, powinno zostać rozdzielone
na dwa powiązania typu jeden do wielu 1 : n. Operację tę przeprowadza się wg schematu
zilustrowanego na diagramie poniżej.
Rysunek 2. Schemat zastępowania relacji m : n przez dwa powiązania typu 1: n
Po zastąpieniu wszystkich powiązań typu m : n z diagramu na rys.1 otrzymujemy diagram
docelowy (rys.2), z dodatkowymi obiektami. Jak można zauważyć, 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
Określenie atrybutów
Biorąc pod uwagę założenia wstępne i funkcje jakie ma pełnić przyszły system baz danych można
określić atrybuty dla wszystkich relacji (obiektów) z diagramu docelowego ( poniższe tabele).
Oprócz nazw atrybutów zostaną określone ich domeny, czyli praktycznie cała struktura tabel bazy
danych.
Tabela Materiały
Nazwa atrybutu
Id_Materialu
Nazwa_Materialu
Jednostka
Ilosc_Min
Ilosc_Min_Mag
Rodzaj atrybutu
Klucz
Znaczenie
Identyfikator materiału
Nazwa materiału
Jednostka miary materiału
Min ilość dostawy
Min ilość w magazynie
3
Domena
Integer
Char(32)
Char(5)
Integer
Integer
Projektowanie bazy danych - przykład
Tabela Dostawcy
Nazwa atrybutu
Rodzaj atrybutu
Id_Dostawcy
Klucz
Firma
NIP
Adres
Atrybut wielowartościowy
Telefon
Bank
Konto
Nazwa_Dostawcy
Znaczenie
Identyfikator dostawcy
Nazwa skrócona klienta
Nr identyfikacji podatkowej
Adres klienta
Telefon do klienta
Nazwa banku
Konto bankowe
Nazwa dostawcy
Domena
Integer
Char(20)
Char(13)
Char( 100)
Char(15)
Char(40)
Char(40)
Char(80)
Tabela Specyfikacja
Nazwa atrybutu
Rodzaj atrybutu
Id_Wyrobu
Klucz
Id_Materialu
Klucz
Ilosc
Znaczenie
Identyfikator towaru
Identyfikator materiału
Ilość materiału na wyrób
Domena
Integer
Integer
Decimal(9,3)
Tabela Wyroby
Nazwa atrybutu
Id_Wyrobu
Nazwa_Wyrobu
Jednostka
Ilość_Min
Ilość_ Min_Mag
Znaczenie
Identyfikator towaru
Nazwa wyrobu
Jednostka miary wyrobu
Min ilość wyrobów w produkcji
Min ilość w magazynie
Domena
Integer
Char(32)
Char(5)
Integer
Integer
Tabela Zamówienia
Nazwa atrybutu
Rodzaj atrybutu
Id_Zamowienia
Klucz
Id_Klienta
Klucz obcy
Data_Zamowienia
Data_Dostawy
Transport
Znaczenie
Nr zamówienia
Identyfikator klienta
Data zamówienia
Data dostawy
Rodzaj transportu
Domena
Integer
Integer
Data
Data
Char(20)
Tabela Zamowienia_Pozycje
Nazwa atrybutu Rodzaj atrybutu
Id_Zamowienia Składnik klucza, klucz obcy
Pozycja
Składnik klucza
Id_Wyrobu
Klucz obcy
Ilosc
Cena
VAT
Znaczenie
Nr zamówienia
Nr pozycji na zamówieniu
Identyfikator wyrobu
Ilość zamówiona towaru
Cena netto towaru
Podatek VAT
Domena
Integer
Integer
Integer
Decimal(12,3)
Decimal(12,2)
Decimal(12,2)
Tabela Klienci
Nazwa atrybutu
Id_Klienta
Firma
NIP
Adres
Telefon
Znaczenie
Identyfikator klienta
Nazwa skrócona klienta
Nr identyfikacji podatkowej
Adres klienta
Telefon do klienta
Domena
Integer
Char(20)
Char(13)
Char(100)
Char(15)
Rodzaj atrybutu
Klucz
Rodzaj atrybutu
Klucz
Atrybut wielowartościowy
4
Projektowanie bazy danych - przykład
Bank
Konto
Nazwa_Klienta
Nazwa banku
Konto bankowe
Nazwa klienta
Tabela Centra
Nazwa atrybutu Rodzaj atrybutu
Id_Centrum
Klucz
Nazwa_Centrum
Tabela Plany
Nazwa atrybutu
Id_Planu
Nazwa_Planu
Data_Od
Data_Do
Znaczenie
Domena
Identyfikator centrum wykonawczego Integer
Nazwa centrum wykonawczego
Char(32)
Rodzaj atrybutu
Klucz
Tabela Specyfikacja_Planu
Nazwa atrybutu Rodzaj atrybutu
Id_Planu
Klucz
Id_Partii
Klucz
Id_Wyrobu
Klucz
Ilosc_Partii
Termin
Tabela Technologia
Nazwa atrybutu Rodzaj atrybutu
Id_Wyrobu
Klucz, Klucz obcy
Id_Operacji
Klucz
Nazwa_Operacji
Id_Centrum
Klucz obcy
Nazwa_Techn
Czas_Techn
Czas Jedn
Char(40)
Char(40)
Char(80)
Znaczenie
Identyfikator planu
Nazwa planu
Data początku planu
Data końca planu
Domena
Integer
Char(32)
Date
Date
Znaczenie
Identyfikator planu
Identyfikator partii produkcyjnej wyrobów
Identyfikator wyrobu
Ilość wyrobów w partii
Termin wykonania partii
Domena
Integer
Integer
Integer
Integer
Date
Znaczenie
Identyfikator wyrobu
Identyfikator operacji technologicznej
Nazwa operacji technologicznej
Identyfikator centrum wykonawczego
Nazwa technologii
Czas techniczny [min]
Czas jednostkowy [min]
Domena
Integer
Integer
Char(32)
Integer
Char(32)
Integer
Integer
Sprawdzenie kryteriów normalności tabel
Na zakończenie procesu projektowania należy jeszcze sprawdzić, czy tabele, których strukturę
podano w powyższych tabelach są co najmniej w trzeciej postaci normalnej. Przeglądając tabele
można zauważyć, że warunku tego nie spełniają tabele Klienci i Dostawcy, ponieważ zawierają
atrybut wielowartościowy adres. Wobec tego należy przeprowadzić normalizację tych tabel. Po
normalizacji, czyli zastąpieniu atrybutu adres przez trzy atrybuty elementarne tj. kod, miasto i ulicę
tabele te otrzymują postać:
Tabela Klienci
Nazwa atrybutu
Id_Klient
Id_Rejonu
Firma
NIP
Kod
Miasto
Rodzaj atrybutu
Klucz
Klucz obcy
Znaczenie
Identyfikator klienta
Identyfikator rejonu
Nazwa skrócona klienta
Nr identyfikacji podatkowej
Kod pocztowy
Miejscowość
5
Domena
Integer
Integer
Char(20)
Char(13)
Char(6)
Char(40)
Projektowanie bazy danych - przykład
Ulica
Telefon
Bank
Konto
Nazwa_Klienta
Ulica
Telefon do klienta
Nazwa banku
Konto bankowe
Nazwa klienta
Char(30)
Char(15)
Char(40)
Char(40)
Char(80)
Tabela Dostawcy
Nazwa atrybutu Rodzaj atrybutu
Id_Dostawcy
Klucz
Firma
NIP
Kod
Miasto
Ulica
Telefon
Bank
Konto
Nazwa_Klienta
Znaczenie
Identyfikator klienta
Nazwa skrócona klienta
Nr identyfikacji podatkowej
Kod pocztowy
Miejscowość
Ulica
Telefon do klienta
Nazwa banku
Konto bankowe
Nazwa klienta
Domena
Integer
Char(20)
Char(13)
Char(6)
Char(40)
Char(30)
Char(15)
Char(40)
Char(40)
Char(80)
6