WAŻNE WSKAZÓWKI PRZYDATNE W PROCESIE TWORZENIA BAZY DANYCH

Etapy projektowania bazy danych, to:

1. zdefiniowanie BD, w tym określenie:

1. celu, któremu ma służyć baza danych i zadań które ma realizować,

b) danych WE, funkcji przetwarzania danych i danych WY.

2. budowa struktury BD:

1. określenie tabel, które są potrzebne w bazie danych.

b) określenie pól, które są potrzebne w tabelach.

c) przypisanie polom typu i innych właściwości.

4. określenie relacji między tabelami.

3. fizyczne utworzenie struktury w Accessie

4. utworzenie pozostałych obiektów bazy danych, tj. kwerend, formularzy, raportów, makr i modułów.

W praktyce punktem wyjścia do utworzenia jakiegokolwiek obiektu BD jest potrzeba użytkownika - czyli funkcja jaką ma pełnić aplikacja. Następnie należy określić, czy funkcję tą lepiej jest zrealizować przy pomocy formularza czy też raportu. Gdy znana jest już odpowiedź na to pytanie, pozostaje już tylko praktyczna realizacja tych ustaleń. W tym celu należy utworzyć potrzebne kwerendy, makra i moduły, a następnie na nich zbudować zaplanowany formularz lub raport.

ETAP 1 - definiowanie celu i założeń funkcjonalnych

Etap ten służy określeniu celu BD i sposobu jej używania. Trzeba określić, jakich informacji ma dostarczyć baza danych, jakie przechowywać i przetwarzać.

Oto dobrze określona definicja BD:

Celem BD jest obsługa danych potrzebnych do ewidencji transakcji handlowych w przedsiębiorstwie X.

Przykład zbyt szczegółowej i niejasnej definicji celu BD może być następujący:

Celem BD jest przechowywanie, przetwarzanie i udostępnianie danych na temat pozycji nabywanych, wielkości i terminu poszczególnych dostaw, adresów dostawców, itd.

Kolejnym krokiem po ustaleniu celu BD jest sformułowanie założeń wstępnych, dotyczących naszej bazy. Należy przy tym unikać zbędnych szczegółów. Oto przykład dobrze określonych założeń wstępnych:

Chcemy przechowywać dane naszych kontrahentów.

Chcemy przechowywać informacje o transakcjach kupna-sprzedaży.

Przykład niejasno sformułowanego założenia może być następujący:

Chcemy przechowywać informacje o wielkości i terminie poszczególnej dostawy, o adresie dostawcy oraz o rozmieszczeniu produktów w magazynie.

Np. możemy chcieć, aby nasza baza danych generowała następujące zestawienia (raporty):

• miesięcznej wartości sprzedaży w rozbiciu na wartość netto, brutto i Vat

• Miesiąc,

• Wartość sprzedaży netto,

• Wartość sprzedaży brutto

• Wartość sprzedaży Vat

• miesięcznej wartości sprzedaży uzyskanej w dowolnym przedziale czasu w podziale na poszczególnych kontrahentów (uszeregowanych malejąco od kontrahentów kupujących najwięcej), co oznacza w szczególności:

• Wybrany miesiąc,

• Nazwa kontrahenta,

• Wartość sprzedaży netto,

• Wartość sprzedaży brutto,

• Wartość sprzedaży Vat,

• miesięcznej wartości sprzedaży w dowolnym zakresie czasu w rozbiciu na poszczególne produkty i ich kategorie , co oznacza w szczególności:

• Wybrany miesiąc,

• Kategoria produktu,

• Nazwa produktu,

• Wartość sprzedaży netto,

• Wartość sprzedaży brutto,

• Wartość sprzedaży Vat,

• miesięcznej wartości sprzedaży zrealizowanej przez pracownika w podziale na kategorie produktów w dowolnym przedziale czasu, co oznacza w szczególności:

• Imię i nazwisko pracownika,

• Wybrany miesiąc,

• Kategoria produktu,

• Wartość sprzedaży netto,

• Wartość sprzedaży brutto,

• Wartość sprzedaży Vat,

• kontrahentów zalegających z płatnościami w wybranej chwili czasu, co oznacza w szczególności:

• Data,

• Nazwa kontrahenta,

• Sumaryczna kwota zaległości,

• Szczegóły (numery niezapłaconych transakcji sprzedaży),...

Itd...

Ponadto chcemy mieć możliwość drukowania, poza powyżej wymienionymi zestawieniami:

- faktur do poszczególnych transakcji sprzedaży.

Po zdefiniowaniu tych założeń należy określić jakie dane są potrzebne do realizacji poszczególnych zadań, czyli jakie dane powinny być gromadzone i w jaki sposób przetwarzane. W analizie tej pomocny jest przegląd dokumentacji, systemów wykorzystywanych w przedsiębiorstwie oraz rozmowy z samymi pracownikami.

Należy zatem określić, jakie informacje są potrzebne do realizacji założeń. Np. chcemy przechowywać dane:

• naszych pracowników, co oznacza w szczególności:

• Nazwisko,

• Imię ,

• Stanowisko,

• Adres,

• Kod pocztowy,

• Miasto,

• Telefon domowy,

• Telefon wew.,

• Data urodzenia,

• Data zatrudnienia,

• NIP,

• PESEL,

• Fotografia,

• naszych zleceniodawców, co oznacza w szczególności:

• Nazwa firmy,

• Adres,

• Kod pocztowy,

• Miasto,

• NIP,

• Regon,

• Telefon,

• Fax,

• Uwagi,

• o naszych produktach, co oznacza w szczególności:

• Nazwa produktu,

• Kategoria produktu,

• Jednostka miary (itd. sztuki, litry, kilogramy, itd.),

• Cena netto,

• Stawka podatku Vat,

• Wycofany (czy produkt został wycofany ze sprzedaży),

• o realizowanych transakcjach sprzedaży, co oznacza w szczególności:

• Nr. Faktury,

• Nabywca,

• Sprzedawca,

• Data sprzedaży,

• Data wystawienia faktury,

• Okres odroczenia płatności,

• Data wpłynięcia środków,

• Produkty (wyszczególnienie produktów sprzedanych w ramach danej transakcji),

• Ilość (ilość ww. produktów),

• Cena netto produktów,

• Stawki podatku Vat produktów,

• Ceny brutto produktów,

• Rabat,

• Wartość netto faktury,

• Wartość brutto faktury,

• Wartość podatku Vat faktury,

Na etapie definiowania założeń BD, przydatne jest również wstępne zaprojektowanie formularzy i raportów, przy pomocy których przyszły użytkownik będzie realizował zdefiniowane wcześniej zadania.

Przykładowo pod założeniem, że „Chcemy przechowywać dane wszystkich zleceniodawców biura geodezyjno-kartograficznego”, jest najczęściej rozumiane, że użytkownik chce mieć możliwość wprowadzenia i przechowywania w bazie danych takich informacji o każdym zleceniodawcy jak: imię, nazwisko, miasto, ulica, kod pocztowy, NIP, REGON, itp. Do wprowadzania danych do BD służą formularze. Przykładowy formularz do wprowadzania danych zleceniodawcy mógłby mieć następującą formę:

Rys.1. Przykładowy formularz do wprowadzania danych zleceniodawcy biura geodezyjno-kartograficznego

Dobre zdefiniowanie celu BD, założeń wstępnych i danych potrzebnych do ich realizacji są podstawowymi wytycznymi do zaprojektowania struktury BD.

Po ustaleniu jakie zadania ma realizować projektowana aplikacja oraz jakie dane i informacje chcemy przechowywać, przetwarzać i udostępniać w BD, możemy przejść do zaprojektowania struktury BD.

ETAP 2 - struktura bazy danych, tabele, relacje

Na tym etapie należy zidentyfikowane dane zorganizować w układ tabel i relacji, które powinny wejść w skład tworzonej BD. Aby utworzyć prawidłową i efektywną strukturę BD należy przestrzegać pewnych zasad.

Podstawowe zasady projektowania BD

Projektując BD należy mieć na uwadze:

1. Należy unikać redundancji danych

Wymóg ten oznacza, że należy unikać przechowywania powtarzających się danych. Innymi słowy każda informacja powinna być przechowywana w BD tylko w jednym miejscu.

2. Należy zapewnić integralność danych - oznacza to, że dane przechowywane w BD powinny być poprawne, spójne i dokładne.

• Integralność na poziomie tabel gwarantuje, że pole klucza podstawowego identyfikuje każdy rekord w danej tabeli i ma zawsze unikalną wartość.

• Integralność na poziomie pól gwarantuje, że struktura każdego pola jest poprawna, a zawarte w nim wartości są sensowne, oraz że wszystkie pola tego samego typu (np. „nazwa miasta”) są zdefiniowane w identyczne sposób w całej bazie danych.

• Integralność na poziomie relacji gwarantuje, że wszystkie relacje są poprawnie zdefiniowane i że dane w powiązanych tabelach są ze sobą zsynchronizowane.

Na strukturę BD składają się tabele i zachodzące między nimi relacje. Tabele służą do przechowywania danych. Pojedyncza tabela zawiera informacje o wszystkich obiektach tego samego typu, np. o dostawcach, produktach. Każda kolumna tabeli przechowuje informacje na temat innej cechy obiektu, np. jedna kolumna może zawierać imiona pracowników, kolejna nazwiska, daty urodzenia, itd. Kolumna tabeli to tzw. pole.

Bardzo ważne jest, aby baza danych zgodna była z tzw. regułami normalizacji. Pod pojęciem normalizacja kryje się zbiór reguł i zasad, którymi należy się kierować podczas projektowania relacyjnej BD.

Reguła 1:

Każde pole w tabeli powinno zawierać unikatowe informacje.

Konsekwencją zastosowania tej zasady jest przede wszystkim wydzielenie z tabeli powtarzających się pól. Pola takie należy umieścić w osobnej tabeli i połączyć relacją z tabelą wyjściową.

Drugim ważnym skutkiem jest rozbicie pól złożonych (takich jak np. adres) na kilka bardziej szczegółowych pól (np. miasto, ulica, nr domu).Np.:

Absolutnie nie może zaistnieć sytuacja, w której mamy następujące pola w tabeli Klienci:

Przede wszystkim nie może znajdować się w tabeli kilku pól określających ten sam rodzaj informacji- w tym przypadku jest to data transakcji z klientem. Jest to bezsensowne rozwiązanie między innymi z uwagi na fakt, że z powodu sztywnej ilości pól baza danych niepotrzebnie się rozrasta, a po drugie: gdy klient zechce przeprowadzić np. czwartą i piątą transakcję - to nie będzie już wolnego pola do wprowadzenia danych.

Dlatego właściwym rozwiązaniem jest rozbicie tej jednej tabeli na dwie następujące:

Takie dwie tabele należy połączyć relacją.

Reguła 2:

W każdej tabeli musi istnieć unikatowy identyfikator (klucz podstawowy) składający się z jednego lub kilku pól.

Reguła 3:

Dla każdej wartości klucza podstawowego wartości w pozostałych kolumnach muszą być z nim związane i muszą dokładnie opisywać obiekty tabeli.

Innymi słowy, wszystkie pola w tabeli muszą odnosić się i opisywać jeden typ obiektu. Przykładowo, pomimo że w tabeli Faktura występują pola opisujące sprzedawcę (Imię i Nazwisko pracownika), to tak naprawdę sprzedawca stanowi osobny obiekt i powinien mieć swoją osobną tabelę.

Reguła 4:

Zmiana danych w dowolnym polu (z wyjątkiem klucza podstawowego - reguła 3) nie może pociągać za sobą zmiany w innych polach tabeli.

Powyższe stwierdzenie oznacza, że wartości w poszczególnych polach tabeli nie mogą być wzajemnie od siebie zależne (za wyjątkiem zależności od klucza podstawowego).

Np. w tabeli Klienci są następujące pola. Jest to niewłaściwe rozwiązanie - ponieważ pole typ połączenia zależy od numeru telefonu.

:

Właściwym rozwiązaniem byłoby utworzenie dwóch tabel:

Projektując aplikację bazodanową należy zawsze mieć na uwadze przyszłe zadania jakie będzie ona realizowała.

Zadania do wykonania - WYKONAJ TE POLECENIA W PODANEJ KOLEJNOŚCI

1. Zarysuj ogólnie obszar (dziedzinę, przedsiębiorstwo) dla którego będziesz tworzył aplikację bazodanową.

2. Uzasadnij dlaczego aplikacja taka jest potrzebna właśnie w tym obszarze.

3. Zdefiniuj cel swojej bazy danych.

4. Określ założenia aplikacji.

5. Sprecyzuj bliżej te założenia po przez ustalenie jakie dane będą potrzebne do ich realizacji.

6. Utwórz strukturę bazy danych - tzn, określ jakie tabele będą występowały w twojej bazie danych i jakie będą w poszczególnych tabelach przechowywane dane.

7. Określ relacje pomiędzy tymi tabelami.

Innymi słowy: zidentyfikowane dane, które będą przechowywane w twojej bazie danych zorganizuj w układ tabel i relacji.

8. Utwórz plik twojej bazy danych w wersji ACCESS 97 - AŻEBY BEZ PROBLEMÓW BYŁO MOŻNA OTWORZYĆ JĄ NA ZAJĘCIACH I PRACOWAĆ NA NIEJ NA ZAJĘCIACH LABORATORYJNYCH SIZ.

9. Utwórz w pliku swojej bazy danych tabele i relacje pomiędzy nimi zgodnie z przemyślaną koncepcją.

1

---