Projektowanie baz danych.

Projektowanie

konceptualne i diagram

obiektowo-związkowy.

Projektowanie baz danych

Zacznijmy tak prosto, jak to tylko możliwe. Kluczowym pytaniem,

które należy sobie zadad przed rozpoczęciem projektowania, jest – czym
właściwie jest baza danych? Jeśli odpowiedź miałaby zostad zawarta w
jednym zdaniu, brzmiałoby ono mniej więcej tak: „baza danych jest
zbiorem informacji powiązanych ze sobą tematycznie”. Baza danych ma
za zadanie przechowywad informacje dotyczące poszczególnych
przedmiotów lub osób.

OK, ale czemu właściwie nie użyd do tego celu prostego dokumentu

tekstowego? Oczywiście możemy otworzyd notatnik i zacząd wypisywad dane, np.
naszych kolejnych klientów, w postaci długich łaocuchów znaków. Przypuszczam, że
dla kilku, a nawet kilkudziesięciu klientów jest to całkiem proste i możliwe do
wykonania. Jednak w momencie, gdy będziemy chcieli wyszukad nazwisko
interesującego nas klienta spośród wszystkich zapisanych, napotkamy już pewien
problem. Dla większej liczby klientów będziemy musieli niestety przeskrolowad już
cały dokument w celu znalezienia interesującego elementu, co nie będzie już takie
łatwe, a na pewno niezbyt wygodne. Może zatem zeszyt programu Excel? Jest to na
pewno lepszy pomysł niż zwykły dokument tekstowy, ma jednak również wiele wad
– bo co zrobid w przypadku, gdybyśmy chcieli wyświetlid np. dziesięciu najlepszych
klientów z bazy kilku tysięcy osób? Na pewno jest to możliwe, jednak nie takie
proste. Zarządzanie dużą ilością danych w dokumencie programu Excel będzie na
pewno skomplikowane. A co w sytuacji, gdybyśmy chcieli podzielid się tymi danymi
z innymi osobami w naszej organizacji? Może zapisad je na pulpicie i wysład
mailem? Odpowiedź jest prosta – potrzebujemy narzędzia, które ułatwi nam
zarządzanie dużą ilością informacji. Wbrew początkowym zarzutom co do
funkcjonalności w pewnym sensie nawet dokument tekstowy, przy spełnieniu
pewnych założeo, możemy nazwad bazą danych. Jednak dopiero wtedy, gdy
zarządzanie tymi danymi będzie względnie łatwe, taki dokument będziemy mogli
nazwad bazą danych.

W trosce o to, aby tworzona przez nas baza danych spełniała

wspomniany wcześniej szereg użyteczności niezwykle ważne jest, aby cały ten
cykl wytwarzania rozpocząd od etapu projektowania. Często, gdy tworzony jest
prosty projekt informatyczny, pomija się etap jego projektowania. Rozważmy
przez chwilę, czy słusznie. Niezależnie od stopnia złożoności projektu po pewnym
czasie stajemy przed koniecznością dokonania w nim zmian. Zmiany, lub może
poprawki, mogą wynikad na przykład z rozszerzenia funkcjonalności bazy danych.
W przypadku gdy owa baza danych nie opierała się na projekcie z podstawowymi
założeniami, jest niestety wysoce prawdopodobne, że w momencie jej
rozszerzania lub modyfikacji natkniemy się na błędy spójności. Wtedy często
łatwiej będzie zbudowad nową bazę danych od podstaw, pomimo że zmiany
miały byd niewielkie. Przed rozpoczęciem budowania bazy danych należy zatem
koniecznie poświęcid nieco czasu na jej zaprojektowanie. „Stracony” w ten
sposób czas odzyskamy w kilkakrotnie większym wymiarze podczas dalszych
etapów wytwarzania bazy danych. Projektowanie bazy danych wymaga
umiejętności spojrzenia na informację jako na zbiór danych opisujących
poszczególne przedmioty, oraz związki (relacje) zachodzące pomiędzy
poszczególnymi obiektami. Dobry projekt jest podstawą utworzenia bazy danych,
która pozwoli na szybkie, dokładne i skuteczne wykonywanie zamierzonych
celów.

Pierwszym krokiem, jaki musimy postawid w momencie

zabierania się za projektowanie bazy danych jest określenie celu,
któremu ma ona służyd, oraz sposobu jej używania. Musimy przecież
wiedzied, jakich informacji ma nam dostarczad i jak z tych informacji
właściwie skorzystad. Na tej podstawie określimy, jakie zagadnienia będą
przez nią analizowane oraz jakich informacji użyjemy do opisu tych
zagadnieo. Na pewno warto porozmawiad z przyszłymi użytkownikami
bazy danych o tym, na jakie pytania ma im ona odpowiadad. Przed
przystąpieniem do budowy tabel, kwerend, formularzy i innych
obiektów warto pokusid się o naszkicowanie projektu na kartce papieru i
jego dokładne przeanalizowanie. Wstępne zarysy wzorów raportów i
formularzy pozwolą lepiej zobrazowad nam funkcje, jakie będzie pełniła
baza danych. Dla jeszcze lepszego efektu warto zapoznad się z
działaniem już istniejących, dobrze zaprojektowanych baz danych,
podobnych do tej, która ma byd utworzona.

Aby uniknąd rozczarowao ze strony przyszłych użytkowników.

Powinniśmy określid oczekiwania wobec aplikacji z punktu widzenia
osób, które będą z niej korzystały. Na tym etapie zbierania wymagao
ważne jest, aby pod uwagę wziąd perspektywę każdego z użytkowników
– da nam to pewnośd, że zbudowana przez nas baza danych będzie
odzwierciedleniem ich wizji, a jeśli ta jest nierealna, to informacja o tym
dotrze do nich natychmiast, co da im czas na przeredagowanie ich
oczekiwao. Podczas zbierania wymagao mogą pojawid się pomysły
przyszłych użytkowników co do jej działania. Na tym etapie potrzebowad
będziemy przede wszystkim opisów wykorzystywanych i tworzonych
danych, szczegółów dotyczących sposobów wykorzystania lub tworzenia
bazy danych.

Ale czy każdy projekt jest dobry? Projekt bazy danych kryje w

sobie zbiór zasad, którymi należy się posługiwad podczas tworzenia bazy
danych. A zatem jedną z najważniejszych rzeczy podczas planowana
projektu jest zrozumienie, że całym procesem jego realizacji kierują
pewne niezmienne zasady.

Pierwszą wspomnianą zasadą jest nawyk minimalizacji rozmiaru danych

przechowywanych w bazie danych. Zrealizowanie tego punktu polega, najprościej
mówiąc, na redukowaniu zbędnych danych oraz zapewnieniu ich integralności.
Przechowywanie tych samych danych w jednym miejscu, w jednym rekordzie
minimalizuje szanse, że jakaś wersja tej danej będzie niepoprawna. A jeśli nawet w
trakcie jej użytkowania dojdzie do tego, że któraś wartośd zostanie niepoprawnie
wprowadzona, zostanie ona wyświetlona we wszystkich miejscach w ten sam sposób,
przez co łatwiejsze będzie wychwycenie błędu.

Drugim aspektem, na który warto zwrócid uwagę, jest rozłożenie większych

zbiorów danych na mniejsze, powiązane ze sobą elementy. Podział na mniejsze tabele,
a następnie relacyjne ich połączenie sprawi, że nie usuniemy przez przypadek danej,
którą uważaliśmy za niepotrzebną, a która – jak się okazuje – ma powiązania z innym
elementem. Jeśli cała baza danych podzielona jest na mniejsze części, to jeśli zajdzie
potrzeba przywrócenia jakiegoś jej elementu, nie trzeba będzie przywracad całej bazy
danych, a wystarczy kawałek, w którym znajduje się ten element. Dodatkowo, aby
zapewnid lepszą integralnośd danych niezbędne jest zdefiniowanie, jaki typ danych
chcemy przechowywad w danej kolumnie. Chodzi o to, żeby uniemożliwid wpisanie
litery tam, gdzie jakaś wartośd przyjmuje tylko liczbową postad, co uczyni już na starcie
bazę danych bardziej poprawną, a to z kolei podniesie jej integralnośd.

Klucz podstawowy służy do unikatowej identyfikacji poszczególnych

wierszy danej tabeli. Działa na podobnej zasadzie, jak np. numer seryjny
przedmiotu czy numer identyfikacyjny pracownika. Konkretnie – może nim byd na
przykład identyfikator produktu lub identyfikator zamówienia. Klucz podstawowy
służy do powiązania informacji przechowywanych w różnych tabelach. Na przykład,
aby powiązad klienta ze wszystkimi jego zamówieniami, każda tabela w bazie
danych musi zawierad pole lub zbiór pól, które jednoznacznie określają każdy
wiersz w tej tabeli (po to, żeby np. określid jednoznacznie danego klienta lub
konkretne zamówienie). Kluczem podstawowym nie mogą byd duplikujące się
wartości, takie jak imiona czy nazwiska, ponieważ takie dane mogą się powtórzyd.
Unikatowym natomiast może byd numer produktu czy zamówienia. Zazwyczaj rolę
klucza podstawowego odgrywa dowolny unikatowy numer, a służy on wyłącznie do
identyfikowania danego produktu czy zamówienia. Numer ten zostaje określony
raz i nigdy się nie zmienia dla danego produktu, co sprawia, że jednoznacznie go
określa. Warto zauważyd, że niekiedy może byd wymagane użycie dwóch lub
większej liczby pól, które razem będą stanowiły klucz podstawowy tabeli (zostanie
to dokładniej przybliżone w dalszej części).

Dopiero po tak określonej i przygotowanej strukturze tabel możemy

zacząd wprowadzad do nich wszystkie potrzebne dane, a na ich podstawie tworzyd
następnie dowolne kwerendy, formularze, raporty, makra czy moduły.

Zastanówmy się zatem, jak stworzyd odpowiednią strukturę do przechowywania

danych oraz jak podzielid cały stos informacji na konkretne tabele. Jednym z rozwiązao jest
zastosowanie metody kolejnych podziałów, najpierw na główne jednostki, następnie każdą
jednostkę na mniejsze części czy może tematy. Dla uproszczenia skupimy się teraz na dosyd
oczywistej sytuacji – sprzedaży produktów. Utworzymy wstępną wersję listy, za pomocą której
spróbujemy zorganizowad w pewien sposób posiadane informacje.

Nazwy tabel zostały określone

przez słowa odpowiadające na główne
pytania naszego małego biznesu, czyli: kto
kupuje, co kupuje, jak kupuje?
Konsekwentnie odpowiedzi to: Klient,
Produkt, Zamówienie. A zatem intuicyjnie
rysowane są w naszej wyobraźni trzy
tabele: jedna zawierająca informacje
dotyczące klientów, jedna dotycząca
produktów oraz jedna z produktami
zamawianymi przez klientów. Tak
zdefiniowana lista jest dla nas bardzo
dobrym punktem startu, do którego
możemy następnie dodawad kolejne
elementy.

Wstępne określenie nazw i zawartości tabel

Jeśli mamy już zdefiniowane tabele, rekordy oraz klucze podstawowe, nie pozostaje

nam nic innego, jak poprawnie połączyd powiązane dane w logiczną całośd. Takie właśnie
połączenie pomiędzy tabelami nazywamy relacjami.

Ażeby zabrad się za tę operację, należy przejrzed wszystkie tabele i zdecydowad, jaka

jest relacja danych z jednej tabeli do danych w innych tabelach. Aby jasno określid relacje,
niekiedy trzeba dodad nowe tabele. W relacyjnej bazie danych informacje są rozdzielane do
osobnych, tematycznych tabel. Dla poszczególnych sytuacji, z którymi mamy do czynienia,
możemy zdefiniowad kilka typów relacji: „jeden do wielu”, „jeden do jednego” oraz „wielu do
wielu”. Zastanówmy się przez chwilę, co na pierwszy rzut oka, jakie tabele oraz jakie elementy
mogłyby stanowid podwaliny bazy danych, np. sklepu.

Jeśli chcielibyśmy określid relację w naszej bazie danych pomiędzy tabelami Produkty

oraz Klienci, to łatwo zauważyd, że jednemu klientowi może byd przyporządkowanych kilka
produktów, dlatego relację należy określid „jeden do wielu”. No to teraz bardziej konkretnie, aby
zrealizowad praktycznie relację „jeden do wielu”, należy klucz podstawowy z tabeli Klienci
(„jeden”) dodad jako kolumnę do tabeli Produkty („wiele”). W tabeli Produkty kolumna ta jest
kluczem obcym. Klucz obcy to, jak łatwo zauważyd, klucz podstawowy innej tabeli. Sprzęganie
tabel polega zatem na ustanawianiu takich par kluczy podstawowych i obcych. Co w przypadku,
kiedy każdemu produktowi może odpowiadad wiele zamówieo, a każdemu zamówieniu może
odpowiadad wiele produktów? Samo się nasuwa, żeby zastosowad relację „wiele do wielu”.
Należy zauważyd, że aby wykryd relację „wiele do wielu” pomiędzy tabelami, trzeba się przyjrzed
obu stronom relacji. Tym razem niestety nie możemy postąpid podobnie, jak w przykładzie
powyżej. Jeśli dodamy klucz podstawowy tabeli Produkty (identyfikator tabeli Produkty) do
tabeli Zamówienia, to o ile dla zamówienia zawierającego jeden produkt byłoby możliwa do
zrealizowania relacja „jeden do wielu”, to przy zamówieniu zawierającym wiele produktów
należałoby dla każdego produktu tworzyd nowe zamówienie.

Ostatnim etapem weryfikacji poprawności projektu bazy danych

jest sprawdzenie, czy umożliwia ona wszystkie podstawowe funkcje:
•projektowanie rekordów:
- nazwa pola,
- długośd pola,
- rodzaj pola (tekstowe, liczbowe, logiczne),
•edycja (dopisywanie, usuwanie, poprawianie rekordów),
•sortowanie,
•wyszukiwanie i selekcja danych,
•tworzenie zapytao,
•tworzenie raportów,
•drukowanie.

Projektowanie konceptualne

Projektowanie konceptualne jest to faza uściślenia i

sformalizowania
wymagao dotyczących polityki bezpieczeostwa, a więc podmiotów i
obiektów ważnych z punktu widzenia zabezpieczeo, praw dostępu i reguł
dostępu.

Etap projektowania konceptualnego jest jednym z najtrudniejszych i

najważniejszych zadao. Od poprawnie zaprojektowanego schematu zależy
właściwe działanie systemu.
Poprawny schemat to taki, który posiada ścisły związek z faktami świata
rzeczywistego, jest podatny na zmiany, zawiera kompletne dla danej
aplikacji informacje oraz pozwala na tworzenie różnych obrazów danych,
czyli różnych logicznych modeli baz danych.

Oto przykład fragmentu konceptualnego modelu bezpieczeostwa
dla pewnego
systemu opisany przy pomocy pseudojęzyka wykorzystującego
zapytania SQL
1. Identyfikacja podmiotów:
podmiot {Bartoszek} nazwa kier_dziekanatu;
podmiot {Jakow, Martan, Nowak} nazwa kier_płac;
podmiot {Ada, Ewa} nazwa prac_płac;
podmiot {Nowak} nazwa ABD;
podmiot {*}ABD nazwa użytkownicy BD;
2. Identyfikacja obiektów:
obiekt{Pracownicy(NrPrac, Nazwisko, Adres, Wiek, Oddział,
Stanowisko,
Płaca)}nazwa dane1;
obiekt {SELECT NrPrac, Nazwisko, Adres, Oddział Stanowisko,
Płaca
from Pracownicy} nazwa dane2;
obiekt {SELECT NrPrac, Płaca from Pracownicy} nazwa dane3;

3. Definicja praw dostępu:
prawo_dostępu {SELECT}nazwa READ;
prawo_dostępu {INSERT, UPDATE}nazwa WRITE;
prawo_dostępu {DELETE, DROP}nazwa DELETE;
prawo_ABD {GRANT}nazwa GRANT;
prawo_ABD {REVOKE}nazwa REVOKE;
4. Definicja reguł dostępu:
ABD can GRANT, REVOKE użytkownicy BD*,*;
użytkownicy BD cannot GRANT, REVOKE;
kier_dziekanatu can READ,WRITE, DELETE dane1;
kier_płac can READ,WRITE dane2;
prac_płac can READ dane3;
kier_dziekanatu can GRANT kier_płac READ dane1;

Diagram obiektowo-związkowy ER

(Entity – Relationship)

Podstawowe elementy tego modelu to: encje,

atrybuty i związki.
•Encja – coś, co istnieje niezależnie i jest jednoznacznie
identyfikowalne. Encja może byd obiektem fizycznym
(pojazd), usługą (wizyta), jak i pojęciem (zamówienie).
•Atrybut – opisuje własności encji. Wszystkie encje danego
typu mają wspólne własności (atrybuty), np. pracownik
posiada numer, nazwisko, imię, itd. Każdy atrybut przybiera
wartości z określonego zbioru wartości (dziedziny).
•Związek – opisuje połączenia między encjami. Encje
objęte związkiem są uczestnikami tego związku

Każdy związek jest określany przez:
• Liczebnośd – liczba uczestników w związku.
Maksymalna liczba instancji jednej encji
(wystąpieo w danej encji), które mogą byd
powiązane z instancją innej encji.
• Związek E/R może byd związkiem:
- Jeden do jeden (1 : 1)
- Jeden do wiele (1 : M)
- Wiele do wiele (M : N)

Związek jeden-do-jeden:
• Najprostszy typ powiązania
• Jedna instancja pierwszej encji jest powiązana z tylko jedną instancją drugiej encji.
• Przykład:
* Każdy dział w przedsiębiorstwie może posiadad tylko jednego kierownika
* Każdy pracownik musi mied przyznany pokój do wyłącznego użytku, tylko jeden. Mogą
istnied pokoje nie przydzielone żadnemu pracownikowi.

Związek jeden-do-wiele:
• Najczęstsze powiązanie
• Pojedyncza instancja jednej encji może byd połączona z jedną lub wieloma instancjami
drugiej encji.
• Przykład:
* Matki – dzieci
* Budynki – Pomieszczenia

Związek wiele-do-wiele:
• Przykład
* Studenci – Wykłady
* Zamówienia - Produkt

Każdy związek jest określany przez:
• Uczestnictwo – uczestnictwo w związku może byd:
* Opcjonalne – uczestnictwo encji w związku jest opcjonalne,
jeżeli istnieje przynajmniej jedna instancja encji, która nie bierze
udziału w związku.
* Wymagane – uczestnictwo encji jest wymagane, jeżeli
wszystkie instancje encji muszą brad udział w związku.

http://msdn.microsoft.com/pl-pl/library/projektowanie-baz-danych.aspx

http://www.wstt.edu.pl/pliki/materialy/mch/bdwsk/wyk1.pdf

http://www.itbiznes.us.edu.pl/images/justyna/bazy_danych_wyk.pdf

Źródła:

Wykonawcy:

Arkadiusz Pacek
Karol Niebrzydowski