Twoim problemem jest to, że powszechną NICOŚĆ mylisz z osobistą PUSTKĄ
II Relacyjny model danych-baza danych stanowi zbiór tabel powiązanych ze sobą za pomocą tzw. Atrybutów kluczowych. Powiązana występujące pomiędzy poszczególnymi wierszami nazywane są też relacjami, nie te relacje przesądziły o nazwie „Relacyjne bazy danych”. Nazwa ta pochodzi od podstawowej struktury danych jakimi są tabele o strukturze relacji. Nazwa Relacyjne bazy danych wywodzi się właśnie z pojęcia relacji w teorii mnogości przedstawionego poniżej, a nie z faktu relacji między poszczególnymi tabelami w bazie danych. Jak widać podstawową strukturą bazy danych jest relacja. Relację nazywa się też tabelą, podobnie jak wiersz nazywa się rekordem.
Podstawowe cechy relacji· Relacja musi składać się przynajmniej z jednej kolumny i może zawierać zero, jeden lub więcej wierszy danych.
· Każdy wiersz w tabeli stanowi abstrakcyjny opis pewnego obiektu określonego przez podane wartości atrybutów.
· Każdy wiersz relacji musi mieć wartości unikalne, czyli musi się różnić przynajmniej wartością w jednej kolumnie od innych wierszy.
· Wartości atrybutów musza być określonego typu zwanego dziedzina lub domeną. Niektóre (nie należące do klucza) domeny powinny uwzględniać wartość pusta NULL.
· Kolejność wierszy i kolumn w tabeli jest dowolna.
· Jeżeli baza danych jest przynajmniej w pierwszej postaci normalnej to w każdym wierszu tabeli pojedyncza kolumna zawiera tylko jedną wartość. Mówimy że nie istnieją atrybuty wielowartościowe.
· Dane umieszczone w kolumnie należa do domeny tej kolumny, czyli do zbioru jej dopuszczalnych wartości. Każda relacja w relacyjnej bazie danych posiada klucz podstawowy, który składa się jednej lub większej liczby kolumn o wartościach jednoznacznie identyfikujących każdy jej wiersz.
Atrybuty charakteryzują cechy abstrakcyjnych obiektów umieszczonych w poszczególnych wierszach relacji ( tabeli). Inaczej jest to opis poszczególnych kolumn relacji. Zakres wartości jakie mogą przyjmować atrybuty (kolumny) nazywa się ich typem domeną lub dziedziną. We współczesnych bazach danych (32-bitowych) zaimplementowane są co najmniej typy danych przedstawione poniżej:CHAR(n) – dowolny tekst, o stałej długości n-znaków
VARCHAR(n) – ciąg znaków zmiennej długości, max n znaków
BLOB – pole binarne o zmiennej długości, służy do pamiętania grafiki i danych multimedialnych
INTERGER – liczba całkowita, zakres wartości +- 2147483648
SMALL INT – liczba całkowita zakres wartości +- 32768
DATA – data
DATATIME – data i czas
DECIMAL (p,s) – liczby dziesiętne, p oznacza liczbę cyfr (razem z kropką i znakiem), s <6 oznacza liczbę cyfr po kropce dziesiętnej
NUMERIC (p,c) – liczby dziesiętne, p oznacza liczbę cyfr (razem z kropką i znakiem) ,s oznacza liczbę cyfr po kropce dziesiętnej
FLOAT – liczba zmiennoprzecinkowa siedem cyfr znaczących
DOUBLE PRECISION liczba zmiennoprzecinkowa podwójnej precyzji
Więzy nałożone na atrybuty
NOT NULL – wartość atrybutu nie może być pusta, UNIQUE – wartość atrybutów w danej kolumnie muszą być unikalne, PRIMARY KEY – dany atrybut jest kluczem podstawowym określonej relacji, co również oznacza, że musi być unikalny, FOREIGN KEY – dany atrybut jest kluczem obcym.
Rodzaje kluczy atrybuty relacji dzielimy na 2 grupy:
Atrybuty podstawowe należące do któregokolwiek z kluczy, atrybuty opisowe nie należące do żadnego z kluczy.
Klucze dzielimy na proste i złożone: Klucz prosty to klucz, którego zbiór identyfikujący jest jednoelementowy, Klucz złożony to klucz którego zbiór identyfikujący jest kilkuelementowy.
Kluczem jest kolumna lub zestaw kolumn, który jednoznacznie identyfikuje resztę danych w dowolnie zadanym wierszu. Np. w tabeli studenci, nr_albumu jest kluczem ponieważ jednoznacznie określa dany wiersz. Oznacza to dwie rzeczy: nie może być dwóch wierszy w tej tabeli które będą miały taki sam nr_albumu, a nawet jeśli dwóch studentów będzie miało te same nazwiska i imiona, kolumna nr_albumu zapewnia, że tych dwóch studentów nikt nie pomyli ze sobą, ponieważ system bazy danych będzie raczej używać pola nr_albumu do znalezienia studenta niż ich nazwisk i imion. Obcy klucz jest atrybutem (kolumną) z obcej tabeli, gdzie ten atrybut jest podstawowym kluczem. Oznacza to, że dowolne dane w kolumnie obcego klucza muszą mieć odpowiedniki w odpowiadającej tabeli, w której ten klucz jest kluczem podstawowym. W języku relacyjnych baz danych, ta odpowiedzialność określana jest jako integralność referencyjna.
Relacje między tabelami – relacyjna baza danych jest kolekcją dwuwymiarowych tabel ( relacji) złożonych z kolumn (atrybutów) oraz wierszy (krotek). Struktura poszczególnych tabel jest przechowywane w słowniku danych(często okreslanego mianem tabel systemowych) który zawiera szczegółowe informacje o bazie danych. W relacyjnej bazie danych relacje między tabelami wyraża się przez umieszczenie identycznych kolumn w dwóch lub większej liczbie tabel. Jeśli któraś z tabel zawiera kolumnę lub kombinację kolumn odpowiadającą kluczowi podstawowemu innej tabeli, wówczas między tymi tabelami istnieje relacja logiczna. O tabeli zawierającej kopię klucza podstawowego innej tabeli mówimy, że zawiera klucz obce. Każda różna od NULL wartość klucza obcego musi odpowiadać jednej z istniejących wartości klucza podstawowego, którego klucz ten jest kopią. Określa się to mianem integralności referencyjnej. Powiązanie pomiędzy parą tabel nosi nazwę relacji. Relacja między tabelami istnieje wtedy, gdy dwie tabele są połączone przez klucz podstawowy i klucz obcy lub gdy istnieje dodatkowa, łącząca je tabela zwana tabelą łączącą. Relacje są ważne dla integracji bazy ponieważ umożliwiają eliminowanie powtarzających się danych. Każda relacja jest opisywana przez typ powiązania istniejącego między dwoma tabelami i typ uczestnictwa jaki obie tabele mają w tej relacji. Każdej relacji między pewnymi dwoma tabelami możemy przypisać konkretny typ. Istnieją trzy typy relacji określające typ powiązania między wierszami tabel: Jeden do jednego(1:1), jeden do wielu(1:n) wiele do wielu(m.:n)
Typ uczestnictwa wierszy w relacji – wiersze tabel mogą uczestniczyć obowiązkowo lub opcjonalnie w relacji między tabelami. Np. między tabelami Pracownicy i Narzędzia ustalamy relację narzędzie zostało wypożyczone. Relacja ta została określona przez wpisanie do kolumny Id_pracownika tabeli Narzędzia odpowiedniego Id_pracownika z tabeli Pracownicy. Ponieważ nie wszystkie narzędzia muszą być wypożyczone niektóre wiersze tabeli Narzędzia mają pustą kolumnę Id_pracownika (mówimy wtedy wartość NULL). Powiązanie to nazywamy opcjonalnym. Rozróżniamy dwa typy uczestnictwa wierszy tabel w relacji: uczestnictwo obowiązkowe, uczestnictwo opcjonalne.
Relacje jeden do jednego mówimy że między dwoma tabelami istnieje relacja jeden do jednego jeśli pojedynczemu rekordowi z pierwszej tabeli jest przyporządkowany dokładnie jeden rekord z drugiej tabeli i na odwrót, pojedynczemu rekordowi z drugiej tabeli jest przyporządkowany dokładnie jeden rekord z pierwszej tabeli.
Relacje jeden do wielu mówimy że między dwiema tabelami istnieje relacja jeden do wielu, jeżeli z każdym rekordem z pierwszej tabeli jest związany jeden lub kilka rekordów z drugiej tabeli, natomiast każdemu rekordowi z drugiej tabeli odpowiada dokładnie jeden rekord z pierwszej tabeli. Relacje jeden do wielu stanowią zdecydowanie najczęstszy typ relacji występujących w rzeczywistych bazach danych. Typ ten jest szczególnie ważny ponieważ umożliwia ograniczenie nadmiarowości danych do absolutnego minimum.
Relacje wiele do wielu mówimy że między dwiema tabelami występuje relacja wiele do wielu jeżeli pojedynczemu rekordowi w pierwszej tabeli może odpowiadać jeden lub więcej rekordów w drugiej tabeli i na odwrót – pojedynczy rekord z drugiej tabeli może być powiązany z jednym lub większą liczbą rekordów z pierwszej. Zaprogramowanie bezpośredniej relacji wiele do wielu między dwoma tabelami jest rudne, ponieważ wiąże się z wprowadzeniem dużej ilości nadmiarowych danych do jednej z tych tabel. Co więcej, dopisywanie modyfikacja i usuwanie danych z tak powiązanych tabel sprawiłoby duże kłopoty. Dlatego powiązania te są eliminowane i zastępowane w procesie normalizacji dwoma połączeniami typu jeden do wielu z wykorzystaniem dodatkowej tabeli. Umiejętność określania typu relacji i stopnia uczestnictwa pomiędzy tabelami jest bardzo ważna, ponieważ decyduje to o sposobie powiązania tabeli o zależności znajdujących się w nich rekordów oraz o maksymalnej liczbie powiązań między rekordami jakie relacja ta powinna dopuszczać.
Normalizacja relacji jest to proces, podczas którego schematy relacji posiadające niepożądane cechy są przekształcone na mniejsze schematy relacji o pożądanych własnościach. Celem normalizacji jest uzyskanie optymalnej struktury bazy danych. Rozróżniamy pięć kolejnych postaci normalnych relacji. W praktyce stosuje się relacje w trzeciej postaci normalnej jako optymalne do zaprogramowania systemu baz danych. Proces normalizacji musi spełniać następujące warunki: żaden atrybut nie zostanie zagubiony w trakcie normalizacji, dekompozycja relacji nie prowadzi do utraty informacji, wszystkie zależności funkcyjne są reprezentowane w pojedynczych schematach relacji, relacje między tabelami mogą być tylko typu jeden do jeden lub jeden do wielu.
Pierwsza postać normalna – wymaga, aby wszystkie wartości jej kolumn były elementarne(niepodzielne). Dlatego schemat relacji musimy tak przekształcić aby w kolumnach były tylko wartości elementarne oraz aby w trakcie przekształceń nie utracić żadnej informacji.
Druga postać normalna – aby tabela przyjęła taką postać musi być w pierwszej postaci normalnej i każda z jej kolumn musi być w pełni zależna od klucza głównego i od każdego atrybutu klucza głównego, jeśli klucz ten składa się z wielu kolumn. Oznacza to, że elementy każdej kolumny tabeli, nie będącej kluczem muszą być jednoznacznie identyfikowane przez klucz główny tabeli.
Trzecia postać normalna – aby tabela była w tej postaci każda z jej kolumn musi być całkowicie zależna od klucza głównego i niezależna od pozostałych kolumn. A zatem tabela musi spełniać warunki drugiej postaci normalnej, a ponadto każda kolumna, nie będąca kluczem, musi być niezależna od pozostałych kolumn niekluczowych.
Dekompozycja relacji, sięgająca poza trzecią postać normalną, prowadzi na ogół do utworzenia bardzo skomplikowanego modelu, którego implementacja może być nieopłacalna. Warto dodać, że współczesne systemy baz danych dobrze obsługują klucze złożone. Dlatego trzecia postać normalna jest zupełnie wystarczająca dla tabel bazy danych.
SELEKCJA – wybiera z relacji(tabeli) tylko te wiersze, które spełniają podany warunek. W języku SQL selekcję można zrealizować za pomocą polecenia SELECT z klauzulą WHERE, po której następuje predykat wyboru. PROJEKCJA – w czasie projekcji z relacji wybiera się tylko określone atrybuty (kolumny).
ZŁĄCZENIE NATURALNE – umożliwia pobieranie danych z dwu lub większej liczby tabel połączonych odpowiednimi relacjami.
ZŁĄCZENIE ZEWNĘTRZNE – (full outer join) umożliwia pobranie danych z dwu lub większej liczby tabeli połączonych odpowiednimi relacjami. Jeżeli w tych relacjach są wiersze, do których nie można dopasować wierszy z innej tabeli, to atrybuty tych wierszy oznaczane są jako NULL.
SUMA – (union) jest wynikiem dodania do siebie wierszy dwóch tabel mających takie same kolumny określone na tych samych dziedzinach. W wyniku powstaje tabela zawierająca wiersze z obydwu tabel wyjściowych.
STRUKTURA I WŁASNOŚCI BAZY DANYCH – zazwyczaj baza danych składa się z kilku lub kilkudziesięciu , a nawet kilkuset tabel połączonych ze sobą za pomocą odpowiednich relacji.
Struktura bazy danych – elementarne obiekty składowe bazy danych jakimi są wiersze i kolumny widnieją w centrum diagramu. Elementy te są zgrupowane w większe struktury – tabele i perspektywy. Od kilka do kilkuset tabel i perspektyw uzupełnionych indeksami tworzy z kolei bazę danych.
Integracja danych – podstawowym zadaniem w czasie projektowania i użytkowania bazy danych jest zapewnienie integracji jej danych. Integracja danych oznacza, że w bazie danych nie ma powtarzających się i niepotrzebnych danych. Integracja danych ułatwia również ich przetwarzanie, ponieważ przy zmianie danych modyfikujemy je tylko w jednym miejscu
Integralność danych – dotyczy między powiązań między danymi w bazie. Zmiany po jednej stronie danego powiązania powinny być odzwierciedlone również po drugiej jego stronie. Jeśli np. wystawiamy dowód przyjęcia do magazynu wyrobu z produkcji to równoczesnie musi się zmienić stan magazynu wyrobów gotowych.
Współdzielenie danych – dane przechowywane w bazie danych są zazwyczaj wykorzystywane przez wielu użytkowników w tym samym czasie. Jedni użytkownicy modyfikują dane, inni w tym samym czasie korzystają z różnych raportów i zestawień, a wszystko to musi być realizowane tak, żeby nikt nikomu nie przeszkadzał w jego pracy. Dlatego przed systemem zarządzającym baza danych stawia się wymaganie, bezkolizyjnego dostępu do tych danych przez wielu użytkowników równocześnie. Współczesne systemy baz danych wykorzystując tzw transakcje coraz lepiej rozwiązują ten trudny problem współdzielenia danych. Współdzielenie danych ma dwa aspekty. Po pierwsze, na tej samej bazie danych mogą współbieżnie pracować różne aplikacje. Po drugie, na tych samych danych może współbieżnie pracować ta sama aplikacja uruchomiona przez różnych użytkowników.
Bezpieczeństwo danych – bazy danych służą do przechowywania wszelkich informacji o działalności firmy czy instytucji. Mogą to być banki, zakłady pracy, sądy czy też organizacje wojskowe. Nie trzeba wielkiej wyobraźni aby zrozumieć potrzebę ochrony informacji przed nieuprawnionym dostępem. Dlatego bazy danych muszą mieć odpowiednie zabezpieczenia przez swobodnym dostępem do informacji. Dlatego w systemach baz danych informację zabezpiecza się przez jej szyfrowanie oraz przydzielanie zakresu uprawnień dla użytkowników do modyfikowania i odczytywania danych.
Abstrakcja danych – baza danych może być traktowana jako pewien model rzeczywistości. Informacje zawarte w bazie reprezentują tylko niektóre właściwości(atrybuty) obiektów świata rzeczywistego. Do bazy danych zapisuje się tylk9 te dane dotyczące obiektów świata rzeczywistego które mają istotny wpływ na działalność danej instytucji.
Niezależność danych – to oddzielenie danych od procesów operujących na tych danych. Czyli baza danych ma być formalnie niezależna od sytemu baz danych. Poprawianie lub ulepszanie systemu baz danych musi odbywać się więc bez naruszania bazy danych.
Różnorodność widzenia danych – te same dane mogą być prezentowane użytkownikom na różne sposoby. Uzyskuje się to np. za pomocą perspektyw lub zapytań w języku SQL które dotyczą tych samych lub wspólnych danych, lecz zestawianych na różne sposoby.
Spójność bazy danych – zgodność z reprezentowaną rzeczywistością. Na przykład baza danych banku, aby była spójna musi odzwierciedlać aktualny stan kont klientów tego banku. Cechy prawidłowo zaprojektowanej i eksploatowanej bazy danych: Baza danych – niezależność danych, współdzielenie danych, integracja danych, różnorodność widzenia danych, integralność danych, bezpieczeństwo danych, abstrakcja danych, spójność.
INDEKSY TABEL – są specjalną strukturą danych pozwalającą systemowi bazy danych na szybkie ich przeszukiwanie. W systemach baz danych kolejne rekordy są dokładane na koniec odpowiednich tabel. Ich kolejność jest na ogół przypadkowa, natomiast w trakcie przetwarzania poszczególne rekordy powinny być dostępne według wymaganego porządku zwanego kluczem. Jeżeli weźmiemy pod uwagę, że w relacji może być od kilku do kilkuset tysięcy rekordów to metod systematycznego przeszukiwania jest w tym przypadku mało efektywna. Aby przyśpieszyć proces wyszukiwania rekordów wprowadzono indeksy.
Struktura indeksu – indeks jest strukturą danych umożliwiającą szybki dostęp do wybranych wierszy, w oparciu o wartości jednej lubi większej liczby kolumn(klucz indeksu). Ponieważ wartości kluczy indeksów są posortowane, to systemowi zarządzania łatwiej jest wyszukać potrzebne wiersze. Sam indeks zawiera uszeregowaną sekwencję kluczy, zarazem z danymi o położeniu w tabeli poszczególnych wierszy. Dane w tabeli bazowej są nieposortowane, ale alfabetyczny indeks umożliwia szybkie znalezienie interesujących nas danych – system zarządzania może wówczas na podstawie danych zawartych w indeksie wybrać te wiersze z tabeli, w których widnieją odpowiednie dane, unikając powolnego, sekwencyjnego przeszukiwania całej tabeli. Dysponując gotowym indeksem, optymalizator zapytań będzie każdorazowo decydował, czy wykorzystanie go przyspieszy aktualną operację i w razie potrzeby odwoła się doń. Kiedy przypisujesz tabeli klucz podstawowy, system zarządzania automatycznie tworzy indeks tej tabeli, wykorzystując w charakterze klucza indeksu kolumny klucza podstawowego. W momencie wprowadzania nowego wiersza do tabeli pierwsza czynnością wykonywaną przez system zarządzania bazą danych jest sprawdzenie czy klucz podstawowy tego wiersza występuje już w indeksie danej tabeli. Tak więc unikalność kluczy podstawowych jest w rzeczywistości kontrolowana na poziomie indeksu, a nie na poziomie tabeli bazowej. Zaletą tego mechanizmu jest znaczne przyspieszenie operacji dopisywania wierszy do tabeli, ponieważ przeszukiwanie indeksu trwa o wiele krócej niż tabeli. Indeks jest to pomocniczy zbór danej tabeli zawierający posortowaną według wymaganego klucza informację połączoną z numerami rekordów z tabeli macierzystej, co pozwala łatwo i bardzo szybko zlokalizować dany rekord.
TRANSAKCJE – to specjalny sposób pracy z bazą danych, zapewniający wysoki stopień integralności i spójności danych. Za przykład weźmy prosty na pozór przypadek zmiany stanów towarów w magazynie po przyjęciu nowej dostawy. Aby prawidłowo odnotować tę fizyczną transakcję należy zmodyfikować następujące tabele: w tabeli dostawcy należy spisać nowy wiersz dotyczący transakcji; w tabeli dostawy_pozycje należy wpisać tyle nowych wierszy ile przyjmuje się różnych towarów do magazynu; w tabeli stany należy zmodyfikować te wiersze które opisują ilościowo i wartościowo stany magazynowe dostarczonych towarów. Biorąc pod uwagę to że na tych tabelach równocześnie może pracować jeszcze wielu innych użytkowników mogą wystąpić następujące błędy zapisu: nie wprowadzono wiersza do tabeli dostawcy (utrata spójności); do tabeli dostawy_pozycje wprowadzono o jeden wiersz za dużo; nie zmieniono kolumny wartość w tabeli stany. Wszelkie błędy zapisu są niedopuszczalne w systemach baz danych. Dlatego tak wiele uwagi projektanci i programiści systemów baz danych poświęcają zaprogramowaniu prawidłowych transakcji. Każda poprawna transakcja powinna charakteryzować się następującymi właściwościami: niepodzielnością, spójnością, współbieżnością, izolacją, trwałością.
Aksjomaty:
Niepodzielność – zwykle transakcja składa się z kilku do kilkudziesięciu elementarnych akcji. System transakcji powinien zapewnić, że albo cała transakcja zostaje wykonana, albo w ogóle nic. Jest to najważniejsza zasada „dobrych” transakcji. Transakcja może być zdefiniowana jako taka najmniejsza logiczna jednostka pracy, która musi być wykonana w całości.
Współbieżność – jeśli kilka transakcji jest wykonywanych równolegle na współdzielonej bazie danych, to ich wykonanie musi być zsynchronizowane i wzajemnie izolowane. Najbardziej znaną metodą kontroli współbieżności jest metoda blokad dostępu dla innych użytkowników w chwili zapisu.
Spójność – wszystkie transakcje muszą zachowywać spójność i integralność bazy danych. Operacje wykonywane na przykład przez transakcję modyfikującą nie powinny pozostawiać bazy danych w stanie niespójnym lub niepoprawnym. Dlatego na przykład w systemie linii lotniczej nie powinno być możliwości dokonania większej liczby rezerwacji na lot niż jest miejsc w samolocie. Transakcję zapisu można traktować jako funkcję przejścia bazy danych ze stanu spójnego S1 w inny stan również spójny S2 a w przypadku transakcji w czasie której następuje jedynie odczyt danych S1=S2. Więzy integralności zdefiniowane dla bazy danych określają warunki początkowe wykonywania aplikacji i są jej nizmiennikiem, czyli w wyniku transakcji baza danych przechodzi z jednego stanu spójnego w drugi stan spójny.
Izolacja – jeżeli transakcja modyfikuje dane dzielone z innymi transakcjami, to te dane mogą być tymczasowo niespójne. Takie dane muszą być niedostępne dla innych transakcji dopóty, dopóki transakcja nie zakończy ich używać. System transakcji musi więc dostarczać iluzji, że dana transakcja działa w izolacji od innych transakcji.
Blokady – na moment zapisu danych do bazy, dane muszą być „zablokowane” tzn. niedostępne w tym czasie dla innych użytkowników. Istnieją dwie metody blokowania: blokowanie totalne – polega na zablokowaniu na początku, transakcji wszystkich wierszy, które będą zmieniane. Blokowanie optymistyczne – polegające na blokowaniu, kolejnych wierszy w miarę ich modyfikowania. Blokowanie totalne wydłuża czas dostępu do bazy danych, natomiast blokowanie optymistyczne grozi zakleszczeniem które polega na wzajemnym zablokowaniu sobie dostępu do tabel przez dwóch użytkowników. Obecnie stosuje się na ogół blokowanie optymistyczne, ponieważ zostały opracowane skuteczne metody wychodzenia z zakleszczeń.
Trwałość – gdy transakcja kończy się wówczas zmiany dokonane przez nią powinny zostać w pełni utrwalone. To znaczy, nawet w wypadku awarii sprzętu lub oprogramowania powinny one zostać zachowane. Transakcje opierają się na zasadzie, że jeżeli choć jeden z elementów zadania nie został zakończony pomyślnie to wszystkie zmiany związane z tym zadaniem powinny zostać anulowane. Przebieg transakcji można opisać w pięciu punktach: rozpoczęcie transakcji, zapisywanie kolejnych zmian tymczasowo w bazie, informowanie o rezultacie zakończenia (pomyślny lub nie), utrwalenie zmian jeżeli zakończenie transakcji jest pomyślne, wycofanie zmian jeżeli zakończenie transakcji niepomyślne.
PROJEKTOWANIE BAZ DANYCH
Analiza zagadnienia – 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 baz 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 – powinna powstać przy współpracy twórcy bazy danych i kierownictwa danej instytucji. Celem-jakiemu ma służyć projektowana baza danych naszej przykładowej aplikacji, będzie 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 – powinien ustalić twórca bazy przy udziale kierownictwa i przyszłych użytkowników. Opisywany projekt dotyczy bazy danych dla planowania seryjnej produkcji wyrobów o prostej strukturze. Planowanie ma uwzględniać zamówienia zewnętrzne i własne. Poniżej podano przykłady wytwarzania wyrobów uwzględnianych w tym systemie planowania: pakowanie produktów żywnościowych; wytwarzanie wyrobów z tworzyw sztucznych; produkcja seryjna odzieży.
Założenia wstępne do systemu planowania produkcji seryjnej wyrobów: 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, 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ń uwzględnieniem stanu magazynu wyrobów tworzy się wstępny plan okresowy, następnie bilansuje się obciążenie centrów 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: wprowadzanie danych ogólnych, wprowadzenie 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.
BUDOWANIE DIAGRAMU ZWIĄZKÓW MIĘDZY RELACJAMIMetoda przedstawiania związków między relacjami za pomocą diagramu jest bardzo wygodna i znacznie usprawnia proces tworzenia bazy danych. Na diagramie widac od razu wszystkie tabele i powiązania między nimi. Tworzenie diagramów można usprawnić wykorzystując narzędzia typu CASE np. Silverun. Narzędzia takie są jednak bardzo drogie i ich zakup opłaca się tylko w dużych firmach projektujących dużo baz danych. Bez pomocy specjalnych programów zadanie to najlepiej wykonać w kilku następujących etapach: identyfikacja zbioru obiektów w systemie, identyfikacja powiązań bezpośrednich między obiektami z wykorzystaniem tablicy krzyżowej, przekształcenie tablicy krzyżowej powiązań w pojęciowy model danych, przekształcenie każdej relacji typu m.:n ba dwa powiązania typu 1:n, określenie atrybutów kluczowych i pozostałych atrybutów dla wszystkich obiektów, sprawdzenie poprawności struktury bazy danych poprzez porównanie jej struktury z wymaganiami względem systemu.
Pojęciowy model danych – na podstawie tablicy krzyżowej 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: relacja między klientami a złożonymi zamówieniami jest typu jeden do wielu 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 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 wiele do wielu 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 i na każdej maszynie można wykonać wiele roż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ę.