plik

Rozdział 6

Projektowanie baz danych w modelu
klient/serwer

Pakiet oprogramowania Silverrun, prezentowany i wykorzystywany w najbliższych
trzech rozdziałach, jest jednym z wielu zestawów narzędzi, dostępnych dla
programistów Delphi. Wybór narzędzi Silverrun podyktowany jest wyłącznie
preferencjami autora i

nie oznacza rekomendacji firmy Borland dla tych

produktów. W tym i następnym rozdziale omówiono zagadnienia dotyczące
tworzenia aplikacji typu klient-serwer. Przedstawiono szereg pojęć z zakresu teorii
baz danych i projektowania aplikacji, a także metody wykorzystania elementów
teorii w praktyce. Rozdziały te przeznaczone są przede wszystkim dla osób
dysponujących niewielkim doświadczeniem w tworzeniu aplikacji do obsługi baz
danych. Czytelnicy posiadający podstawową wiedzę na temat teorii baz danych
i projektowania aplikacji mogą ograniczyć się do stworzenia wszystkich obiektów
przykładowej bazy danych, wymienionych w tym rozdziale, i od razu przejść do
rozdziału 8 „Pierwsza rzeczywista aplikacja bazy danych klient/serwer”.

Metoda prezentacji problemu

Proponowana tutaj metoda prezentacji zagadnień z zakresu projektowania baz
danych różni się od spotykanych powszechnie w podręcznikach. W niniejszej
książce mniej miejsca zajmuje teoria baz danych, więcej - zagadnienia praktyczne.
Podręcznik programowania aplikacji klient-serwer w Delphi nie jest najlepszym
miejscem na omówienia szczegółów historycznego artykułu E.F. Codda albo
modeli matematycznych, leżących u podstaw normalizacji. Tego rodzaju tematyce
poświęconych jest wiele osobnych książek. Dlatego najbliższe rozdziały mają
przede wszystkim służyć pomocą w

tworzeniu rzeczywistych aplikacji.

Rozpoczynamy od rzetelnego omówienia podstaw teoretycznych, następnie
przejdziemy do zastosowań elementów teorii w rzeczywistych aplikacjach.

Jednym z najpoważniejszych problemów autora każdej książki technicznej jest
znalezienie „złotego środka” między zakresem podawanych informacji
teoretycznych a praktycznych wskazówek, typowych dla poradnika lub samouczka.
Jeśli książka zaczyna zanadto przypominać samouczek, nabiera charakteru nieco
uszlachetnionej instrukcji obsługi. Czytelnik znajdzie wówczas odpowiedź na
pytanie „Jak?”, ale nie - „Dlaczego?”. Z drugiej strony, jeśli autor skłania się
zanadto ku zagadnieniom teoretycznym, książka może stać się bezużyteczna

140

Część I

w codziennej praktyce. Czytelnicy kupują na ogół książki „komputerowe”, aby
dowiedzieć się, jak wykorzystać określone technologie lub jak zrealizować
określone zadania. Książki, z których nie można uzyskać żadnych praktycznych
informacji, mogą okazać się bezwartościowe dla większości czytelników-
praktyków.

Dobrym rozwiązaniem jest zatem ulokowanie książki pomiędzy dwiema
skrajnościami. Właśnie ten cel przyświecał autorowi niniejszej książki, zarówno
w odniesieniu do całości, jak i bieżącego rozdziału. Można tutaj znaleźć instrukcje
zastosowania konkretnych narzędzi, wspomagających projektowanie baz danych,
a także solidną porcję teorii, leżącej u podstaw prezentowanych praktycznych
informacji. Autor ma nadzieję, że książka niniejsza odpowie równie skutecznie na
oba pytania: „Jak?” i ”Dlaczego?”.

Pięć procesów

Tworzenie aplikacji do obsługi baz danych w modelu klient-serwer można rozbić
na pięć etapów lub procesów. Procesy te tworzą ogólny schemat postępowania
przy budowaniu aplikacji baz danych. Można je uznać za przykazania dobrego
rzemieślnika - autora baz danych klient-serwer. Omawiany schemat powinien
obowiązywać przy tworzeniu każdej takiej aplikacji.

Oto pięć ogólnych procesów, realizowanych podczas tworzenia aplikacji do
obsługi bazy danych typu klient-serwer:

Definiowanie przeznaczenia i funkcji aplikacji.

Projekt bazy danych i procesów aplikacji, niezbędnych do zaimplementowania

żądanych funkcji.

Przekształcenie projektu w

aplikację poprzez utworzenie odpowiednich

obiektów bazy danych i programu.

Testowanie aplikacji pod kątem zgodności z założonym przeznaczeniem

i zakresem funkcji.

Instalacja aplikacji w środowisku użytkownika.

Aby uprościć odniesienia do powyższych pięciu procesów, można przedstawić je
jako pięć etapów, nazwanych pojedynczymi słowami:

Analiza

Projekt

Budowa

Testowanie

Projektowanie baz danych w modelu klient/serwer

141

Instalacja

UWAGA:

Etap budowy nazywa się często także „etapem kodowania”. W

dobie

programowania wizualnego, które nie sprowadza się tylko do pisania tekstu
programu, pierwsze określenie, zaproponowane przez autora, wydaje się bardziej
trafne. Proces „budowy” może obejmować zarówno pisanie programu, jak
i półautomatyczne generowanie aplikacji.

W niniejszym rozdziale i dalszej części książki stosowane będą skrócone
określenia etapów. Cechują się one większą zwięzłością i obejmują pojęcia,
z którymi większość programistów miała wcześniej styczność. Można z nich
wprost wyczytać, że tworzenie aplikacji baz danych typu klient-serwer nie różni
się istotnie od tworzenia dowolnego innego oprogramowania; jak wszędzie,
również tutaj istnieje zdefiniowana metoda postępowania, którą zazwyczaj podąża
się, chcąc uzyskać założone wyniki.

Bliższe omówienie pięciu etapów

Budując jakikolwiek obiekt - program komputerowy, dom, pomnik czy cokolwiek
innego - budowniczy przechodzi szereg etapów. Na końcu tej drogi znajduje się
skończony produkt. Podobna procedura obowiązuje przy tworzeniu wszelkich
aplikacji, nie tylko programów do obsługi baz danych. Droga postępowania,
wiodąca przez szereg etapów, nie jest wcale czymś sztucznie narzuconym twórcy
aplikacji. Przeciwnie - wynika ona z czystej logiki i jest całkowicie zgodna
z intuicją. Podąża się nią zatem instynktownie.

Właściwe zadanie budowania aplikacji do obsługi bazy danych zamyka się
w pierwszych trzech z pięciu ogólnych procesów. Aplikacja powstaje właśnie
podczas realizacji pierwszych trzech etapów, właśnie one stawiają przed autorem
aplikacji najwięcej problemów i wyzwań.

Analiza

Pierwszym etapem tworzenia aplikacji jest analiza. Etap ten polega na
przeanalizowaniu przeznaczenia i funkcji aplikacji. Rozpoczyna się go od
sformułowania podstawowego przeznaczenia programu. W dalszej kolejności
definiuje się funkcje, które aplikacja musi realizować (lub udostępniać
użytkownikowi) aby spełnić swoje przeznaczenie. Funkcje te zdefiniowane są
w kategoriach

wymagań operacyjnych, technicznych i

funkcjonalnych.

Wymagania operacyjne mogą określać procesy, które aplikacja ma zrealizować
w

zadanym przedziale czasu. Wymagania funkcjonalne mogą obejmować

obecność w programie określonego formularza do wprowadzania danych lub

142

Część I

przestrzeganie w aplikacji określonej reguły przetwarzania. Wymagania techniczne
to, na przykład, konieczność działania aplikacji pod kontrolą zadanego sieciowego
systemu operacyjnego albo komunikowania się za pośrednictwem określonego
protokołu. Definicja kluczowych funkcji jest punktem wyjścia w modelowaniu
procesów ekonomicznych. Polega ono na sporządzeniu opisu reguł przetwarzania,
zasobów i strumieni danych, dzięki którym aplikacja może spełnić stawiane jej
podstawowe wymagania.

Projekt

W drugim etapie następuje przekształcenie wyników analizy w projekt. Reguły
przetwarzania, stworzone w pierwszym etapie, przekształcane są w logiczne
elementy projektu aplikacji i bazy danych. Punkt ciężkości przenosi się z pytania
„Co aplikacja ma robić?” na „W jaki sposób ma to realizować”. Na etapie projektu
określane są komponenty aplikacji i bazy danych, niezbędne do zaimplemen-
towania modelu reguł przetwarzania, który powstał w fazie analizy. Metody
przekształcenia modelu w definicję elementów aplikacji i bazy danych obejmują
logiczne modelowanie danych oraz diagramy związków encji (tabela 6.2) (ang.
entity-relationship diagrams). Ostatecznym wynikiem omawianego etapu są
oddzielne projekty każdej z warstw aplikacji typu klient-serwer.

Budowa

W fazie budowy aplikacji projekt logiczny przekształcany jest w obiekty fizyczne.
Oznacza to, że elementy logicznego projektu bazy danych zamienione zostają na
rzeczywiste obiekty bazy danych. Projekt aplikacji, sporządzony w poprzedniej
fazie, zamieni się w formularze, kod i inne obiekty programowe.

Ostatnie dwa spośród pięciu etapów - testowanie i instalacja - rozpoczynają się już
po powstaniu aplikacji, dlatego też nie będą tutaj szczegółowo omawiane. Często
zdarza się, że ich wynikiem jest i tak powrót do jednego z pierwszych trzech
etapów (z uwagi na wykryte błędy lub życzenia, zgłaszane przez użytkowników).

Trudności przy tworzeniu aplikacji w modelu klient/serwer

Proces tworzenia aplikacji do obsługi baz danych typu klient-serwer nie jest ani
skomplikowany ani sprzeczny z intuicją. Metody tworzenia wszelkich aplikacji są
zbliżone - nie jest istotne, czy dana aplikacja obsługuje bazę danych. Stwierdzenie
takie może się wydawać pewnym uproszczeniem, jest jednak zdaniem autora
najlepszym punktem wyjścia w projektowaniu aplikacji do obsługi baz danych
typu klient-serwer.

Trudności, które pojawiają się przy próbie zastosowania typowych metod
w

projektowaniu aplikacji typu klient-serwer, wynikają z

faktu, iż nawet

Projektowanie baz danych w modelu klient/serwer

143

najprostsza aplikacja tego typu składa się z dwóch oddzielnych elementów: części
wykonywanej na serwerze i części klienta. Co więcej, obiekty, które tworzone są
na serwerze bazy danych, stanowią fundament całej aplikacji. Jest zatem wskazane
- jeśli nie konieczne - aby obiekty te istniały jeszcze przed stworzeniem właściwej
aplikacji. Aplikacja nie będzie działać poprawnie, jeśli w

bazie danych

występować będą błędy. Z tą dwoistą naturą aplikacji wiąże się podwojenie
nakładu pracy, wymaganego do jej stworzenia. Procesy analizy, projektu i budowy
muszą zostać przeprowadzone zarówno w odniesieniu do aplikacji, jak i do bazy
danych. Poza problemami, występującymi przy opracowywaniu części
realizowanej na serwerze i części klienta, niebagatelne znaczenie ma komunikacja
między klientem a serwerem. Czasami nawiązanie takiej komunikacji jest samo
w sobie poważnym i

trudnym zadaniem. Uwzględnienie oprogramowania

pośredniczącego (middleware) dodatkowo komplikuje sytuację.

Nie można w prosty sposób uniknąć problemów, wynikających ze złożoności
aplikacji typu klient-serwer. Narzędzia CASE bywają pomocne, nie wyeliminują
jednak udziału programistów i projektantów aplikacji. Aplikacje typu klient-
serwer są  złożonymi, wielowarstwowymi programami; nie ulega wątpliwości,  że
tworzenie ich wymaga pewnej dozy doświadczenia. Autor ma nadzieję,  że
niniejsza książka pozwoli czytelnikom nabyć umiejętności przydatne
w rozwiązywaniu problemów, występujących  w projektowaniu  i tworzeniu
aplikacji klient-serwer.

Ten i następny rozdział zawierają omówienie pięciu faz tworzenia aplikacji typu
klient-serwer. Szczególny nacisk położono na zagadnienia praktyczne. Niniejszy
rozdział omawia fazy analizy, projektu i budowy w odniesieniu do baz danych.
W rozdziale 7, „Projektowanie aplikacji w modelu klient-serwer”, przedstawiono
powyższe etapy w odniesieniu do tworzenia aplikacji. Ponadto rozdział 7 omawia
testowanie i instalację aplikacji do obsługi baz danych.

Faza testowania omawiana jest z konieczności jednocześnie w odniesieniu do baz
danych i aplikacji. Trudno byłoby przetestować bazę danych bez aplikacji, która na
niej operuje. Z drugiej strony, nie da się przetestować aplikacji bez wymaganych
przez nią obiektów bazy danych.

Również fazy instalacji baz danych i aplikacji omawiane są równolegle. Baza
danych i

aplikacja stanowią zazwyczaj nierozłączny zestaw i

są razem

instalowane. Dlatego duże znaczenie mają zagadnienia, związane z jednoczesną
instalacją bazy danych i programu. Po zakończeniu fazy budowy, istnieją już
fizyczne obiekty bazy danych i aplikacji, naturalną konsekwencją jest zatem ich
jednoczesna instalacja.

144

Część I

Dwoista natura aplikacji typu klient-serwer

Prawdopodobnie najlepsza metoda rozwiązania problemów, wynikających
z dwoistej natury aplikacji typu klient-serwer, polega na przejściu trzech głównych
faz projektu dla każdej warstwy aplikacji z osobna. Innymi słowy, najpierw
analizuje się, projektuje i buduje bazę danych, a następnie powtarza analogiczny
proces w odniesieniu do samego programu. Te same trzy etapy powtórzyć można
również w odniesieniu do oprogramowania pośredniczącego (middleware), o ile
występują one w danym projekcie. Właśnie ten sposób tworzenia aplikacji
przyjęto w niniejszej książce jako wzorcowy.

Powyższa metoda postępowania gwarantuje, że w chwili rozpoczęcia budowy
aplikacji lub oprogramowania pośredniczącego (middleware) istnieją już
odpowiednie obiekty bazy danych. Pozwala to skrócić czas opracowywania
programu. Jak już wcześniej wspomniano, nie da się rozpatrywać bazy danych
w całkowitym oderwaniu od aplikacji. Mimo to powszechnie przyjętą praktyką jest
tworzenie obiektów bazy danych wcześniej niż związanych z nimi elementów
programu i oprogramowania pośredniczącego (middleware).

Pomiędzy teorią a praktyką projektowania baz danych

Zapoznając się z treścią niniejszego rozdziału, a także rozdziału 7, Czytelnik
zauważy z pewnością, że projektowanie bazy danych i projektowanie aplikacji
rozpatruje się tutaj jako dwa w naturalny sposób powiązane procesy. Niektórzy
specjaliści uważają jednak, że są to dwa różne zagadnienia. W praktyce proces
projektowania bazy danych tworzy fundament, na którym projektowana jest
aplikacja, korzystająca z tej bazy. Baza danych i program wzajemnie na siebie
wpływają. Autorowi nigdy nie zdarzyło się projektować bazy danych, do której nie
miałaby dostępu jakaś aplikacja.

Trzeba zawsze pamiętać, że baza danych stanowi tylko środek do osiągnięcia celu,
którym jest spełnienie życzeń przyszłych użytkowników. Podobnie aplikacja
klienta pełni funkcję pośrednika między użytkownikiem a serwerem bazy danych.
Ona również jest tylko środkiem służącym do spełniania życzeń użytkowników.
Aplikacja klienta i serwer bazy danych muszą efektywnie współpracować ze sobą
i dostarczać rozwiązania, które użytkownicy zaakceptują.

W niniejszym rozdziale omówione zostały kolejne etapy projektowania aplikacji
do obsługi bazy danych w modelu klient-serwer. Przykładom towarzyszyć będzie
rzetelne omówienie niezbędnych elementów teorii baz danych. Nacisk położono
jednak na realizację zadań, występujących przy projektowaniu rzeczywistych
aplikacji.

Projektowanie baz danych w modelu klient/serwer

145

UWAGA:

Niniejszy rozdział poświęcony jest wyłącznie projektowaniu baz danych w modelu
klient-serwer. Nie omówiono tutaj zastosowania systemów zarządzania lokalnymi
bazami danych, takich jak Paradox, dBASE i Access. Prawdziwe systemy
zarządzania bazami danych, działające w

modelu klient-serwer, w

bardzo

niewielkim stopniu przypominają systemy lokalne. Podobnie metody
projektowania baz danych typu klient-serwer różnią się od stosowanych
w projektowaniu baz lokalnych. Tematem niniejszej książki jest tworzenie baz
danych w modelu klient - serwer, dlatego też pominięto w niej systemy lokalne.

Definiowanie przeznaczenia aplikacji

Pierwszym krokiem w procesie projektowania każdej aplikacji jest zdefiniowanie
jej przeznaczenia. Co aplikacja ma robić? W niniejszym rozdziale rozpoczniemy
projektowanie przykładowej aplikacji dla fikcyjnej firmy Allodium Properties.
Przeznaczeniem tworzonej aplikacji będzie wspomaganie zarządzania licznymi
nieruchomościami, które firma Allodium wynajmuje. Nowa aplikacja nosić będzie
nazwę RENTMAN (od ang. rental management - zarządzanie wynajmem).

UWAGA:

Kontynuację niniejszego rozdziału znajdzie Czytelnik w sekcji „Samouczek”,
w której prześledzić można kolejne etapy pracy nad projektem RENTMAN (zob.
rozdział 8).

Przeznaczenie aplikacji powinno być wyrażone pojedynczym zdaniem,
zawierającym podmiot, orzeczenie i

dopełnienie. Podmiot opisuje zawsze

aplikację, np. „System...” lub „System RENTMAN...”. Orzeczenie opisuje
zadanie, jakie aplikacja ma wykonywać, np. „System będzie prowadził...” lub
„System RENTMAN będzie wspomagał...”. Dopełnienie opisuje obiekt, którego
dotyczy zadanie, np. „System będzie prowadził zapisy na obóz letni” albo „System
RENTMAN będzie wspomagał zarządzanie wynajmem nieruchomości”.

Zdanie, formułujące przeznaczenie, powinno być jak najprostsze i możliwie
krótkie. Należy unikać zbyt skomplikowanych i szczegółowych sformułowań.
Przykładami niepożądanych elementów są określenia, takie jak „na rzecz
instytucji” lub „dla klienta” - nie wnoszą one żadnych informacji, które nie
wynikałyby z kontekstu reszty zdania. Należy także unikać zdań złożonych
i spójników. Redukcja zdania do najprostszej postaci pomaga w zachowaniu
precyzji przy późniejszym sporządzaniu opisu funkcji aplikacji. Dopiero taki opis
może zawierać więcej szczegółów.

146

Część I

Zdanie, wyrażające przeznaczenie aplikacji, należy jak najszybciej przedstawić
potencjalnym użytkownikom i

dowiedzieć się, czy się z

nim zgadzają.

Prawdopodobnie przyszłych użytkowników zdziwi skrajna zwięzłość
przedstawionego im sformułowania. Konieczne jest jednak uzyskanie ich
zapewnienia, że sformułowanie to jest dokładne i kompletne. Sformułowanie
przeznaczenia nie zawiera listy cech i funkcji aplikacji, powinno być jednak na
tyle szerokie, by objąć wszystkie aspekty jej planowanego przeznaczenia.
Użytkownikom należy wyjaśnić, że szczegółowa lista funkcji aplikacji zostanie
sporządzona w następnym etapie pracy.

Definiowanie funkcji aplikacji

Kolejnym etapem, po sformułowaniu przeznaczenia aplikacji, jest określenie jej
funkcji. Jakie funkcje musi realizować aplikacja, aby wypełnić zadanie, do którego
została powołana? Sporządzona na tym etapie lista powinna być - w miarę
możliwości - jedynie małym zbiorem najważniejszych funkcji. Funkcje te powinny
bliżej zdefiniować przeznaczenie aplikacji, ale nie wykraczać poza zapisane
wcześniej sformułowanie przeznaczenia. Konstrukcja zdań, opisujących
poszczególne funkcje, powinna przypominać konstrukcję zdania, wyrażającego
przeznaczenie całej aplikacji.

System RENTMAN będzie wspomagał zarządzanie wynajmem nieruchomości.
Będzie:

Rejestrował i obsługiwał umowy najmu nieruchomości;

Śledził prace, związane z konserwacją nieruchomości;

Generował rachunki dla najemców;

Generował informacje o historii poszczególnych nieruchomości;

Lista musi obejmować wszystkie zasadnicze funkcje aplikacji, ale nie powinna być
zbyt szczegółowa. Poszczególne zadania nie powinny się nakładać - dopisując
nową funkcję należy upewnić się, czy nie jest już wymieniona pośrednio w ramach
innego zadania.

Projektowanie bazy danych i procesów aplikacji

Początkujący projektanci bardzo szybko przekonują się, że ich zadanie wykracza
daleko poza samo tylko projektowanie fizycznych elementów bazy danych.
W procesie projektowania bazy danych istotną rolę odgrywa modelowanie reguł
przetwarzania, diagramów związków encji i logiczne modelowanie danych.
Kolejne etapy, począwszy od modelowania reguł przetwarzania aż po budowę
bazy danych, tworzą ciągły proces. Rozpoczynając pracę od modelu reguł

Projektowanie baz danych w modelu klient/serwer

147

przetwarzania, będących podstawą dla aplikacji, i przybliżając się w kolejnych
etapach do definicji poszczególnych kolumn bazy danych, projektant przechodzi
od ogólnej wizji do szczegółów technicznych; uzupełnia i modyfikuje swoją wizję
przeznaczenia aplikacji aż do chwili, gdy gotów jest do przekształcenia jej
w rzeczywisty program.

Rzeczywisty proces projektowania bazy danych nie jest jednak aż tak złożony, jak
wydawałoby się z pozoru. W niniejszym rozdziale rozbito proces projektowania
bazy danych na trzy podstawowe etapy:

1. Sporządzenie dokumentacji reguł przetwarzania, niezbędnych do zrealizowania

funkcji aplikacji.

2. Sporządzenie diagramu związków encji, wymaganych do obsługi tych

procesów.

3. Stworzenie logicznego projektu bazy danych, niezbędnego do implementacji

związków encji i reguł przetwarzania.

Rysunek 6.1 ilustruje związki między pięcioma fazami tworzenia aplikacji
a wymienionymi powyżej trzema etapami. Po sformułowaniu przeznaczenia
aplikacji i określeniu jej kluczowych funkcji, fazy analizy i projektu można
sprowadzić właśnie do tych trzech etapów. W ich efekcie powstanie logiczny
schemat bazy danych, stanowiący punkt wyjścia do rozpoczęcia fazy budowy.

Przejścia pomiędzy kolejnymi etapami od modelowania procesów po logiczny
model danych można częściowo zautomatyzować przy pomocy narzędzi typu

Rysunek 6.1.
Model ilustrujący
różnorodne
elementy pięciu
etapów tworzenia
aplikacji

148

Część I

CASE (computer aided software engineering, komputerowo wspomagana
inżynieria oprogramowania). Narzędzia takie w znacznym stopniu upraszczają
proces tworzenia aplikacji typu klient-serwer.

Narzędzia typu CASE

Dyskusję na temat narzędzi typu CASE wypada rozpocząć od ogólnego
stwierdzenia, że programy tego rodzaju nie są uniwersalne i że nigdy nie
wyeliminują konieczności starannego planowania i

opanowania rzemiosła

programistycznego. Przeciwnie, narzędzia CASE - tak jak wszystkie inne
programy - robią tylko to, co użytkownik im każe, a nie to, czego użytkownik od
nich oczekuje.

Druga z ogólnych uwag autora dotyczy filozofii narzędzi CASE: narzędzia, które
z założenia mają automatyzować wszystkie elementy procesu projektowego,
zamiast zwiększać - obniżają efektywność tworzenia aplikacji. Nie wspomagają
procesu, lecz hamują go wskutek prób automatyzowania tych elementów, które nie
mogą lub nie powinny być zautomatyzowane. W

skrajnych przypadkach

poprawianie automatycznie wygenerowanych rozwiązań zajmuje programistom
i projektantom więcej czasu niż wykonanie zadania bez pomocy narzędzi
programowych. James Rumbaugh, ekspert w dziedzinie modelowania danych
i współautor pracy Unified Method for Object-Oriented Development, ujął tą samą
myśl następująco: „Dobre narzędzie [CASE] nie automatyzuje wszystkiego (co
starali się osiągnąć autorzy niektórych narzędzi, wykorzystujących sztuczną
inteligencję); powinno natomiast automatyzować proste zadania i oferować proste
metody realizacji trudnych zadań, być może poprzez zaoferowanie pewnych
rozwiązań szkieletowych.

Wszelkie rozwiązania, które w zamyśle mają oszczędzać czas, można doprowadzić
do punktu, w którym realnie uzyskiwane efekty zaczną zanikać. Jest to wyraźnym
sygnałem, że należy powrócić do źródeł rozwiązywanych problemów i poszukać
metod automatyzacji, które usprawnią, a nie utrudnią pracę.

W procesie tworzenia aplikacji baz danych typu klient-serwer program typu CASE
powinien zachować status narzędzia, którego zastosowanie wymaga określonych
umiejętności. Narzędzie nie będzie myśleć za autora aplikacji i nie zwolni go
z obowiązku zaplanowania poprawnego rozwiązania problemu. Pomoże jedynie
sprawnie wykonać zadania, które dałoby się zrealizować innymi środkami (choć
być może wymagałoby to większego nakładu pracy). Właśnie taka rola w procesie
modelowania aplikacji typu klient-serwer wydaje się najbardziej odpowiednia dla
narzędzi typu CASE. Niezależnie od rodzaju stosowanych narzędzi, projektant,
który chce tworzyć wydajne aplikacje, musi dysponować podstawową wiedzą
z zakresu teorii projektowania baz danych i funkcjonowania systemu zarządzania
bazą danych.

Projektowanie baz danych w modelu klient/serwer

149

Ponieważ większość czynności, poprzedzających projektowanie bazy danych,
sprowadza się do modelowania rzeczywistości, od narzędzi CASE oczekuje się
efektywnego wspomagania takich prac. Dzisiejsze narzędzia CASE są już
produktami dopracowanymi, odbiegającymi od pierwszych, pionierskich
rozwiązań. Można zatem bezpiecznie zrezygnować z ręcznego przygotowywania
modeli na rzecz szybszych narzędzi typu CASE.

Pozwalając na umieszczanie w modelu nie istniejących jeszcze obiektów,
narzędzia CASE umożliwiają wykonywanie analiz typu „co-jeśli” i

mogą

ostrzegać przed potencjalnymi problemami, wynikającymi z podejmowanych
decyzji. Model procesów i obiektów zawiera informacje, dzięki którym narzędzie
typu CASE może pomóc projektantowi w osiągnięciu zamierzonych celów. Wśród
rodzajów modeli, szczególnie dobrze przystających do możliwości narzędzi typu
CASE, wymienić należy:

Modelowanie reguł przetwarzania:

Kluczowe funkcje aplikacji realizowane są przez wzajemnie
powiązane procesy. Model reguł przetwarzania stanowi formalną
reprezentację tych procesów i ich wzajemnych powiązań. Istnieją
narzędzia typu CASE przeznaczone specjalnie do modelowania
procesów. Wśród przykładów takich narzędzi wymienić można S-
Designor (obecnie PowerDesigner) Process Analyst firmy
Powersoft lub Silverrun-BPM firmy CSA.

Modelowanie związków encji:

Większość projektantów baz danych i

osób zawodowo

zajmujących się modelowaniem danych korzysta z diagramów E-
R. Diagramy takie umożliwiają oddzielenie logicznej reprezentacji
danych od ich fizycznej implementacji. Diagramy związków encji
pozwalają na rozpatrywanie elementów danych w kategoriach
reprezentowanych przez nie obiektów świata rzeczywistego.
Istnieje wiele narzędzi CASE wspomagających modelowanie
związków encji. Należą do nic programy ERwin firmy Logicworks
i ER/1 firmy Embarcadero.

Relacyjny model danych:

Mimo swej popularności, modelowanie związków encji
reprezentuje tylko część procesu relacyjnego modelowania
danych. Relacje między obiektami bazy danych wyrażać można na
różne sposoby, nie tylko przy pomocy diagramów E-R.
Dostępnych jest szereg narzędzi CASE, których możliwości
wykraczają poza proste sporządzanie diagramów E-R i obejmują
zadania związane z projektowaniem całych logicznych schematów

150

Część I

baz danych. Wśród narzędzi tego rodzaju wymienić można
program S-Designor Data Architect i Silverrun-RDM.

W niniejszym rozdziale omówione zostanie zastosowanie narzędzi CASE
w

modelowaniu procesów, zachodzących w

świecie rzeczywistym, a

także

możliwości przekształcania modeli w obiekty baz danych i aplikacji. Obiekty
fizyczne powstają na podstawie logicznych modeli danych, co zilustrowano na
rysunku 6.2. Z kolei logiczne modele danych budowane są na bazie diagramów E-
R, te zaś uzyskuje się na podstawie modeli reguł przetwarzania. W modelach reguł
przetwarzania ujęte są definicje przeznaczenia i kluczowych funkcji aplikacji.
W procesie przechodzenia od definicji przeznaczenia i kluczowych funkcji do
etapu budowy aplikacji stopniowo kształtuje się szczegółowa wizja aplikacji
i realizowanych przez nią czynności.

Wybór narzędzia typu CASE

Nie da się wskazać „najlepszego” narzędzia typu CASE, wspomagającego
modelowanie danych. Oczywiście, istnieją narzędzia mniej i bardziej popularne,
jednak oryginalne, nowatorskie rozwiązania spotkać można również w programach
prawie nieznanych. W przypadku projektów, dotyczących baz danych, kryterium
wyboru narzędzia CASE stanowić może wielkość aplikacji. Do małych projektów,
które powinny być zrealizowane w stosunkowo krótkim czasie, autor najczęściej
używa programu ER/1 firmy Embarcadero, rzadziej - ERWin firmy Logicworks.
ER/1 jest nowym produktem i zasługuje na uwagę ze względu na interfejs
komunikacji z użytkownikiem i prostotę obsługi. Zaletą programu jest również

Rysunek 6.2.
Narzędzia typu
CASE pomagają
przekształcić
koncepcje
w fizyczne obiekty
baz danych
i aplikacji

Projektowanie baz danych w modelu klient/serwer

151

jego szybkość, odczuwalna zwłaszcza przy analizie i odtwarzaniu struktur
istniejących baz danych. Mimo że w programie ER/1 - podobnie jak w ERWin -
stosowana jest notacja IDEF1X, doświadczenia autora wskazują, że można z jego
pomocą uzyskać zadowalającą wydajność pracy. ER/1 przewyższa pod tym
względem inne podobne narzędzia.

W przypadku złożonych projektów autor korzysta najczęściej z pakietu programów
firmy Computer Systems Advisors. Pakiet ten nosi nazwę Silverrun i składa się
z czterech podstawowych modułów: BPM - modułu wspomagającego
modelowanie reguł przetwarzania, ERX - programowego eksperta diagramów E-R,
RDM - modułu do sporządzania relacyjnych modeli danych i WRM - programu
zarządzającego składnicą elementów modelu.

Czytelników zainteresuje zapewne porównanie pakietu Silverrun z innymi,
bardziej popularnymi narzędziami (wśród których wymienić należy m.in.
programy S-Designor i ERWin). Na korzyść pakietu Silverrun przemawia wiele
czynników. Przede wszystkim, w przeciwieństwie do większości narzędzi CASE,
Silverrun dostępny jest na wielu różnych klienckich platformach systemowych.
Z tych samych narzędzi mogą korzystać użytkownicy systemów Sun Solaris,
Windows NT czy Macintosh. W

przypadku dużych projektów, o

zasięgu

korporacyjnym, bardzo istotna jest zarówno zgodność narzędzia do modelowania
z różnymi serwerami baz danych, jak i możliwość stosowania przez projektantów
dowolnego sprzętu komputerowego. Użytkownicy nie muszą wówczas zmieniać
systemu operacyjnego tylko po to, by uzyskać dostęp do narzędzia CASE.

Kolejną zaletą pakietu Silverrun jest jego integracja z Delphi. Moduł do tworzenia
relacyjnych modeli danych (RDM) oferuje specjalny „tryb pracy” Delphi.
W trybie tym możliwe jest projektowanie zbiorów atrybutów, które dadzą się
następnie zapisać w słowniku danych Delphi i które będzie można wykorzystać
w aplikacjach. Dla autora aplikacji, posługującego się na co dzień Delphi,
mechanizmy integracji obu narzędzi stanowią poważne ułatwienie.

W programach Silverrun zachowany jest prawidłowy rozdział diagramów E-R od
podstawowego relacyjnego modelu danych. Wiele osób myli oba modele, sądząc,
że diagram E-R i relacyjny model danych to jedno i to samo. Diagram E-R
rzeczywiście wyraża relacje (związki) między obiektami w bazie danych, jest
jednak tylko jednym z wielu rodzajów logicznego modelowania danych.

Wreszcie podkreślić należy bardzo dużą opłacalność zastosowania pakietu
Silverrun. Jego cena jest porównywalna z cenami takich programów jak S-
Designor i ERWin, natomiast wiele z oferowanych funkcji plasuje go w klasie
bardziej zaawansowanych narzędzi do modelowania, takich jak ADW lub System
Engineer.

152

Część I

WSKAZÓWKA:

Na dysku CD-ROM, dołączonym do niniejszej książki, znajduje się wersja testowa
całego zestawu narzędzi Silverrun. Czytelnicy, którzy nie korzystają z narzędzi
Silverrun, powinni zainstalować wersję testową i używać jej do tworzenia modeli,
omawianych w niniejszym rozdziale i dalszych częściach książki. Wersja testowa
oprogramowania Silverrun jest również dostępna w Internecie, pod adresem
www.silverrun.com.

Wersja testowa Silverrun funkcjonuje w

ograniczonym zakresie. Niektóre

z modeli, prezentowanych w książce, są tak złożone, że nie mogą być przetwarzane
przy pomocy standardowej wersji testowej. U producenta oprogramowania
Silverrun - w firmie Computer Systems Advisors - uzyskać można kod, który
czasowo znosi ograniczenia. Numer telefonu producenta : 1-800-537-4262.

Narzędzia Silverrun charakteryzują się dość nietypowym interfejsem komunikacji
z użytkownikiem, odbiegającym częściowo od zasad CUA (ang. common user
interface), powszechnie stosowanych w aplikacjach Windows. Powodem takiego
odstępstwa jest chęć zachowania jednolitego interfejsu w wersjach programów,
działających na różnych platformach systemowych. Dzięki temu programy
Silverrun, działające np. w systemie Solaris, komunikują się z użytkownikiem
w taki sam sposób jak ich analogiczne wersje na platformie Windows NT.
Zdaniem autora korzyści, wynikające z dostępności tych samych narzędzi na wielu
platformach systemowych, z

nawiązką rekompensują trudności, związane

z nietypowym zachowaniem aplikacji.

Modelowanie reguł przetwarzania

Po zdefiniowaniu przeznaczenia i

funkcji aplikacji przychodzi czas na

sporządzenie modelu reguł przetwarzania, który te funkcje dokładniej opisze.
W niniejszej sekcji prześledzimy krok po kroku proces sporządzania modelu reguł
przetwarzania dla aplikacji typu klient-serwer. W dalszej kolejności omówione
zostanie sporządzanie diagramu związków encji i logicznego modelu danych. Po
zakończeniu faz analizy i projektu przyjdzie pora na implementację projektu bazy
danych przez stworzenie jej fizycznych obiektów. Na tym zakończą się prace nad
bazą danych; w kolejnym rozdziale przejdziemy do projektu samej aplikacji.

Modele procesów ekonomicznych ilustrują związki pomiędzy czterema
podstawowymi elementami: procesami, obiektami zewnętrznymi, zbiorami
i strumieniami danych. Związki te określane są dodatkowo przez kwalifikatory,
zasoby i struktury danych. W tabeli 6.1 scharakteryzowano poszczególne elementy
modelu i ich wzajemne relacje.

Projektowanie baz danych w modelu klient/serwer

153

Tabela 6.1. Elementy modelu reguł przetwarzania

Element modelu

Definicja

Proces

(process)

Zadanie lub decyzja, które (-ą) aplikacja albo
instytucja ma wykonać/podjąć. Procesy opisywane są
w kategoriach czynności realizowanych przy użyciu
zasobów. Jako przykłady procesów podać można
zatrudnianie nowych pracowników, fakturowanie,
przyjmowanie reklamacji, itp.

Obiekt zewnętrzny
(external entity)

Osoba, jednostka organizacyjna lub inny obiekt,
znajdujący się poza opisywaną instytucją lub
aplikacją, ale współpracujący z

nią. Obiekty

zewnętrzne są w modelowanym systemie źródłami
lub odbiorcami informacji. Przykładowe obiekty
zewnętrzne to klienci, najemcy, władze, rynek, itp.

Zbiór (ang. store)

Dane generowane, wykorzystywane lub modyfiko-
wane przez modelowany system. Zbiorami są na
przykład informacje o klientach, plany kont, księgi
wieczyste, itp.

Strumień (ang. flow)

Towary lub dane przepływające między obiektami
zewnętrznymi, procesami i zbiorami. Jako przykłady
strumieni wymienić można informacje udzielane
klientom, zamówienia, przesyłki kurierskie, reklama-
cje, itp.

Zasób (resource)

Element modelowanego systemu, wykorzystywany
w jakiś sposób przez proces. Zasobami są na przykład
serwery sieciowe, napędy pamięci taśmowej, osoby
zajmujące określone stanowiska, artykuły biurowe,
itp.

Kwalifikator (qualifier)

Informacja, dokładniej definiująca obiekt zewnętrz-
ny, strumień, proces lub zbiór. Kwalifikator może na
przykład informować, że reklamacje przyjmowane są
zazwyczaj telefonicznie albo że informacje są
przesyłane do domowego biura za pośrednictwem
faksu.

Struktura danych (data
structure)

Szczegółowa informacja o

danych, zawartych

zbiorze. Struktury danych definiują atrybuty

zawartości zbiorów.

154

Część I

Niniejszy rozdział nie został pomyślany jako przewodnik po pakiecie narzędzi do
modelowania Silverrun. Pakiet ten będzie jednak wykorzystywany w celu
zilustrowania niektórych korzyści, płynących z zastosowania narzędzi CASE.
Dlatego przed przejściem do właściwych zagadnień, związanych z modelowaniem,
przedstawimy kilka praktycznych wskazówek, dotyczących oprogramowania
Silverrun.

UWAGA:

Metody modelowania, przedstawione w niniejszym rozdziale, nie wymagają
stosowania narzędzi typu CASE. Narzędzia takie doskonale nadają się do
prezentowanych tutaj zastosowań, nie są jednak niezbędne. Wielu doświadczonych
projektantów baz danych do dziś korzysta wyłącznie z ołówka i kartki papieru.
Narzędzia należy zawsze dobierać zgodnie z indywidualnymi preferencjami.
Formalny, ścisły opis procesu modelowania pozwala uniknąć wielu typowych
pomyłek. Mimo to można sporządzać doskonałe modele, nie korzystając w ogóle
z narzędzi typu CASE.

Wskazówki dotyczące użycia oprogramowania Silverrun

UWAGA:

Przy uruchamianiu poszczególnych narzędzi, pochodzących z testowej wersji
pakietu Silverrun, na ekranie wyświetlany jest komunikat, informujący o braku
danych, wymaganych przez mechanizm zabezpieczający oprogramowanie.
Komunikat można zignorować - nie przeszkodzi to w tworzeniu i zapisywaniu
modeli. Jednak uruchomiona w ten sposób wersja testowa narzuca ograniczenia co
do maksymalnej liczby elementów, wchodzących w skład modelu. Niektóre
z modeli, prezentowanych w książce, są tak złożone, że nie mogą być przetwarzane
przy pomocy standardowej wersji testowej. Jak już wspomniano, w firmie CSA (u
producenta pakietu Silverrun) uzyskać można kod, który czasowo znosi to
ograniczenie.

Oto kilka wskazówek, dotyczących korzystania z programu BPM:

Większość struktur, używanych do tworzenia modeli reguł przetwarzania,

dostępna jest na palecie narzędzi, widocznej po lewej stronie ekranu.
Najczęściej używane będą narzędzia z prawej części palety. Omawiana paleta
widoczna jest na Rysunku 6.3.

We wszystkich programach Silverrun układ menu jest podobny. Menu

Presentation

zawiera opcje, które zazwyczaj umieszczane są w

kontekstowym, wywoływanym prawym klawiszem myszy. Opcje dostępne

Projektowanie baz danych w modelu klient/serwer

155

w menu

Presentation

dotyczą sposobu wyświetlania (prezentacji) elementów na

ekranie.

Aby ułatwić sobie rozmieszczanie elementów można skorzystać z siatki

ekranowej. Należy w tym celu wybrać opcję

Presentation\Grid

i uaktywnić

przyciski opcji

Grid Shown

Grid Active

. Po wybraniu gęstości siatki w osiach

X i Y należy kliknąć

. Typową wartością, preferowaną przez autora, jest

gęstość 0,25 cala. Po wybraniu wszystkich ustawień program wyświetli na
ekranie siatkę, na której można rozmieszczać obiekty. Uwaga: chcąc
posługiwać się centymetrami, należy wybrać odpowiedni rodzaj jednostek -
służy do tego opcja menu

Presentation\Preferences\Unit Type

Przed przystąpieniem do tworzenia modelu należy wybrać stosowaną notację.

Istnieje szereg sformalizowanych systemów opisu modeli procesów. Program
Silverrun-BPM pozwala na korzystanie z kilku systemów, w tym z notacji
Gane-Sarsona, Merise'a, Yourdona-DeMarco i Warda-Mellora. Dostępna jest
też oryginalna notacja Datarun, opracowana dla potrzeb programu. Użytkownik
może wybrać stosowaną notację, korzystając z opcji menu

Presentation\

Notation\Preset Notation

. Można także zdefiniować własny styl opisywania

modelu przez zmianę ustawień jednego ze standardowych stylów, dostępnych
w programie. Wybrany styl decyduje o postaci graficznej narzędzi z palety
programu BPM. Autor preferuje notację Warda-Mellora.

Po określeniu wszystkich ustawień początkowych należy zapisać pusty model,

tak aby w przyszłości można go było używać w charakterze szablonu. Tworząc
nowy model, należy otworzyć szablon i od razu zapisać go pod inną nazwą
(poleceniem menu

File\Save As).

Pozwala to uniknąć każdorazowego

określania ustawień początkowych.

Rysunek 6.3.
Paleta narzędzi
BPM
(modelowania
reguł
przetwarzania).

156

Część I

Czynności wstępne

Przejście od określenia funkcji do definicji procesów prześledzimy na przykładzie
aplikacji RENTMAN. Jak pamiętamy, przeznaczenie tego programu zostało
określone następującym zdaniem:

„System RENTMAN będzie wspomagał zarządzanie wynajmem nieruchomości.”

Oto wybrane, przykładowe funkcje aplikacji RENTMAN:

Rejestrowanie i obsługa umów najmu nieruchomości.

Śledzenie prac związanych z konserwacją nieruchomości.

Generowanie rachunków dla najemców.

Generowanie informacji o historii poszczególnych nieruchomości.

Najlepsza droga do opanowania sztuki modelowania danych wiedzie przez jak
najszybciej podjęte, praktyczne ćwiczenia. Początkujący projektanci baz danych
wkrótce przekonują się, że modelowanie nie jest procesem liniowym i nie
przebiega prostą drogą od określenia przeznaczenia aplikacji do stworzenia
kompletnego modelu fizycznego. W

praktyce model powstaje w

kolejnych

przybliżeniach, a sam proces modelowania ma charakter iteracyjny. Modele
tworzy się na ogół metodą prób i błędów.

Sporządzimy teraz model procesów, niezbędnych do zrealizowania pierwszej
z kluczowych funkcji systemu RENTMAN: rejestrowania i obsługi umów najmu
nieruchomości. Jak już wspomniano, całą aplikację RENTMAN budować
będziemy w sekcji „Tutorial”, a zatem wysiłek włożony w realizację pewnych
czynności wstępnych nie będzie stracony.

Aby sporządzić model procesów ekonomicznych, należy wykonać trzy
podstawowe czynności:

1. Określić niezbędne obiekty zewnętrzne, procesy, strumienie i zbiory.

2. Zdecydować, jakie związki mają zachodzić pomiędzy powyższymi elementami.

3. Sporządzić diagram, obrazujący te elementy i związki, zachodzące między

nimi.

Pierwszym z

modelowanych procesów będzie obsługa umów najmu

nieruchomości. Należy zatem odpowiedzieć na następujące pytania:

Jakie obiekty zewnętrzne zaangażowane są w rejestrację i obsługę umów najmu

nieruchomości?

Jakie procesy są przy tym realizowane?

Z jakich zasobów korzystają te procesy?

Projektowanie baz danych w modelu klient/serwer

157

Jakie zbiory będą potrzebne?

W jaki sposób dane przepływają pomiędzy poszczególnymi elementami?

W omawianym przypadku można z góry przyjąć następujące założenia:

Model wymaga przynajmniej jednego obiektu zewnętrznego - potencjalnego

najemcy.

Przetwarzanie umów najmu i

wykonanie umów najmu będą dwoma

oddzielnymi procesami.

Zważywszy, że firma wynajmująca nieruchomości jest zainteresowana

rejestrowaniem telefonów od potencjalnych najemców i chce przechowywać
niezależnie informacje o najemcach, umowach najmu i nieruchomościach,
konieczne będzie włączenie do modelu czterech zbiorów danych. Będą w nich
zawarte dane o telefonach, najemcach, nieruchomościach i umowach najmu.

Co do przepływu danych między powyższymi elementami, przyjąć można

następujące założenia:

♦

Potencjalni najemcy nawiązują kontakt z

pracownikiem firmy

wynajmującej i uzyskują informacje o dostępnych nieruchomościach lub
zawierają umowę najmu.

♦

Pracownik rejestruje każdy odebrany telefon, niezależnie od tego, czy
w jego wyniku zawierana jest umowa najmu.

♦

Po zweryfikowaniu, umowa najmu trafia do innego pracownika,
odpowiedzialnego za jej wykonanie.

♦

Informacje o

najemcy, uzyskane podczas zawierania umowy są

rejestrowane.

♦

Rejestrowane są również wykonane umowy.

Przystąpimy teraz do tworzenia modelu procesów zarządzania informacją
o wynajmie. W modelu tym zostaną uwzględnione sformułowane powyżej
założenia.

Dodawanie obiektów zewnętrznych

Należy teraz, w programie Silverrun-BPM, utworzyć nowy model, wybierając
polecenie menu

File\New (

można również załadować pusty model, pełniący rolę

szablonu). Następnie należy wybrać opcję menu

Project\Project Description

i w polu

Project Name

wpisać nazwę projektu RentMan System. Podobnie ustala

się nazwę modelu - należy wybrać opcję menu

Model\Model Description

i w polu

Name

wpisać BPM Diagram for Lease Process lub po polsku Diagram BPM

158

Część I

procesu wynajmu. Naciśnięcie kombinacji klawiszy ALT-S wywoła polecenie
zapisu modelu w pliku, któremu należy nadać nazwę

LEASE.BPM

Można teraz umieścić w modelu obiekt zewnętrzny, reprezentujący potencjalnego
najemcę. W tym celu należy wybrać z palety narzędzie „obiekt zewnętrzny”
(external entity tool) i umieścić obiekt w lewym-górnym rogu pustego obszaru
roboczego. Po podwójnym kliknięciu na obiekcie możliwe będzie wpisanie jego
nazwy - w

tym przypadku PROSPECTIVE TENANT (POTENCJALNY

NAJEMCA). Obiekt ten będzie reprezentował potencjalnego najemcę, który pyta
o dostępne nieruchomości albo zawiera umowę najmu konkretnej nieruchomości.
Na rysunku 6.4 przedstawiono model, zawierający pierwszy obiekt.

Dodawanie procesów

Do modelu należy dodać dwa obiekty reprezentujące procesy: jeden pośrodku
górnej części obszaru roboczego, drugi - w prawym górnym rogu. Pierwszy proces
powinien nosić nazwę Lease Processing (Przetwarzanie umowy), a drugi Lease
Execution (Wykonanie umowy). Aby wpisać nazwę obiektu należy na nim
podwójnie kliknąć myszą. Obiekt Lease Processing reprezentuje przyjęcie
i weryfikację informacji, niezbędnej do przygotowania umowy. Jest to kluczowy
element całego procesu wynajmu. Proces Lease Execution reprezentuje właściwe
wynajęcie nieruchomości, w

tym przekazanie kluczy nowemu najemcy

i zarejestrowanie umowy. Model z naniesionymi procesami przedstawiono na
rysunku 6.5.

Rysunek 6.4.
Nowy model
z naniesionym
pierwszym
obiektem
zewnętrznym.

Projektowanie baz danych w modelu klient/serwer

159

Dodawanie zbiorów (obiektów typu Store)

W dolnej części modelu należy umieścić cztery obiekty typu Store. Będą one
reprezentowały zbiory danych, na których działać będą pozostałe elementy
modelu. Pierwszy zbiór należy nazwać CALL (TELEFON), drugi - PROPERTY
(NIERUCHOMOŚĆ), trzeci TENANT (NAJEMCA), a

czwarty - LEASE

(UMOWA). Obiekty typu Process będą pobierały i

umieszczały dane

w powyższych zbiorach. Na rysunku 6.6 przedstawiono aktualny stan modelu.

Rysunek 6.5.
Nowy model
z naniesionymi
obiektami typu
External Entity
i Process.

Rysunek 6.6.
Cztery obiekty typu
Store naniesione
na model.

160

Część I

Dodawanie strumieni (obiektów typu Flow)

Po umieszczeniu w modelu wszystkich obiektów, procesów i zbiorów przychodzi
czas na określenie jak te elementy są ze sobą powiązane. Związki te definiuje się
przy pomocy obiektów typu

Flow

. Aby poprowadzić strumień między dwoma

obiektami, należy kliknąć narzędzie

Flow

, obiekt źródłowy, a następnie docelowy

(operację łączenia można przerwać klawiszem ESC). Program Silverrun-BPM
poprowadzi linię pomiędzy obiektem źródłowym i docelowym. Dostępne są trzy
narzędzia

Flow

, które różnie prezentują się na ekranie, pełnią jednak identyczne

funkcje i mogą być stosowane zamiennie.

Należy teraz:

1. Połączyć obiekty PROSPECTIVE TENANT i Lease Processing strumieniem

(najbardziej odpowiedni będzie strumień w prawo, choć każdy się do tego
nadaje) przebiegającym z lewej strony na prawą. Następnie podwójnie kliknąć
nowy obiekt typu

Flow

i nadać mu nazwę Applies for Lease (Występuje

o zawarcie umowy). Strumień ten reprezentuje zgłoszenie przez najemcę chęci
zawarcia nowej umowy najmu.

2. Połączyć obiekty Lease Processing i PROSPECTIVE TENANT strumieniem

przebiegającym z prawej strony na lewą. Następnie podwójnie kliknąć nowy
obiekt typu

Flow

i nadać mu nazwę Notifies of Acceptance (Informuje

o przyjęciu). Strumień ten reprezentuje odpowiedź wynajmującego na
zgłoszenie najemcy.

3. Połączyć obiekty Lease Processing i

Lease Processing strumieniem

przebiegającym z lewej strony na prawą. Następnie podwójnie kliknąć nowy
obiekt typu

Flow

i nadać mu nazwę Verifies Lease (Weryfikuje umowę).

Strumień ten reprezentuje przesłanie umowy do wykonania po jej uprzedniej
weryfikacji.

4. Połączyć obiekty Lease Execution i PROSPECTIVE TENANT strumieniem

przebiegającym z prawej strony na lewą. Nadać strumieniowi nazwę Leases
Property (Wynajmuje nieruchomość).

Na rysunku 6.7 przedstawiono poprawną postać modelu na obecnym etapie pracy.

162

Część I

zdefiniowanie struktur danych przechowywanych w obiektach typu

Store

(zbiorach). Dzięki temu odpowiednio mniej czasu trzeba będzie poświęcić na
sporządzenie modeli E-R aplikacji.

Program Silverrun-BPM umożliwia określenie atrybutów dla zbiorów danych;
definicje atrybutów można następnie wykorzystać w programach ERX i RDM.
Struktury danych do pewnego stopnia odpowiadają encjom w diagramach E-R
i tabelom w relacyjnym modelu danych. Informacje o niezbędnych atrybutach
można często uzyskać wprost z

dokumentów źródłowych i

formularzy

dostarczonych przez przyszłych użytkowników, a także w wyniku rozmów z nimi.
Szczegółowe informacje o danych przechowywanych w systemie należy uzyskać
jak najwcześniej, co pozwoli szybciej pokonać późniejsze etapy projektowania.

Dodawanie definicji struktur danych do modelu BPM przebiega dwustopniowo.
Najpierw należy zdefiniować struktury danych przy użyciu polecenia menu

Project\Data Structures

; następnie struktury danych muszą zostać skojarzone

z obiektami typu

Store

Należy zatem uaktywnić opcję menu

Project\Data Structures

i dodać trzy struktury

danych

: CALL, LEASE i TENANT (TELEFON, UMOWA i NAJEMCA

Aby dodać nową strukturę danych, należy wpisać jej nazwę w polu edycji,
widocznym w lewym-dolnym rogu okna dialogowego

Data Structures

i kliknąć

przycisk

Add

(zob. rysunek 6.9).

Po dodaniu trzech nazw struktur danych należy zdefiniować atrybuty, które każda
z tych struktur będzie obejmować. Podwójne kliknięcie na nazwie struktury
w oknie dialogowym

Data Structure

spowoduje otwarcie okna

Data Structure

Composition

, w którym można określić poszczególne atrybuty. Podobnie jak

w oknie

Data Structures

, także i w tym przypadku należy wpisać nazwę atrybutu

w lewym dolnym rogu okna i kliknąć przycisk

Add

. Okno dialogowe

Data

Structure

Composition

przedstawiono na rysunku 6.10.

164

Część I

Do struktury danych

LEASE

należy dodać następujące elementy:

Lease Number
Tenant Number
Property Address
Property City
Property State
Property Zip
Property Addition
Property BedRooms
Property LivingAreas
Property BathRooms
Property GarageType
Property SchoolDistrict
Property Deposit
Property Rent
Property Range
Property Refrigerator
Property DishWasher
Property CentralHeat
Property CentalAir
Property GasHeat
Property PrivacyFence
Property LastSprayDate
Property LastLawnDate
Lease BeginDate
Lease EndDate
Lease MovedInDate
Lease MovedOutDate
Lease Rent
Lease Deposit
Lease PetDeposit
Lease RentDueDay
Lease LawnService
Lease Comments

Wreszcie, poniższe elementy należy dodać do struktury danych

TENANT

Tenant Number
Tenant Name
Tenant Employer
Tenant EmployerAdress
Tenant EmployerCity
Tenant EmployerState
Tenant EmployerZip
Tenant HomePhone
Tenant WorkPhone
Tenant ICEPhone
Tenant Comments*

*Przypis od tłumacza: wyjaśnienie znaczenia poszczególnych atrybutów polski Czytelnik
znaleźć może w Tabeli 6.6, w dalszej części tego rozdziału

Projektowanie baz danych w modelu klient/serwer

165

Tego rodzaju informacje pochodzić mogą wprost z wniosków o zawarcie umowy,
rejestru najemców, itp. Należy zwrócić uwagę, że na tym etapie projektu nie jest
jeszcze celowe podejmowanie próby normalizacji danych. Na razie model
powinien jak najlepiej odzwierciedlać obiekty świata rzeczywistego, na których
i pod wpływem których system ma działać.

Nazwa każdego z atrybutów rozpoczyna się od nazwy zbioru. Konwencja taka
okazuje się bardzo przydatna, gdyż zbiory zostaną później przekształcone w tabele
fizycznej bazy danych. Pomoże ona również w pełnym wykorzystaniu możliwości
narzędzia Silverrun ERX (do modelowania związków encji).

Po przygotowaniu struktur danych można przypisać je poszczególnym zbiorom.
Uaktywnienie opcji menu

Presentation\Palettes\Data Structures

spowoduje

wyświetlenie na ekranie palety struktur danych. Aby skojarzyć strukturę danych
z konkretnym obiektem typu

Store

należy przeciągnąć strukturę z palety,

trzymając wciśnięty prawy klawisz myszy, i umieścić na żądanym zbiorze. Paletę
struktur danych przedstawiono na rysunku 6.11.

Należy teraz skojarzyć strukturę danych

CALL

ze zbiorem

CALL

, strukturę danych

TENANT

ze zbiorem

TENANT

i strukturę danych

LEASE

ze zbiorem

LEASE

. Aby

upewnić się, czy struktura danych rzeczywiście została przypisana do zbioru,
wystarczy podwójnie kliknąć na obiekcie, reprezentującym zbiór. Nazwa
skojarzonej struktury danych powinna być widoczna w

polu edycji

Data

Structures

, w lewej dolnej części okna dialogowego, które pojawi się na ekranie.

Rysunek 6.11.
Paleta struktur
danych umożliwia
kojarzenie struktur
danych ze zbiorami
(obiektami typu
Store).

166

Część I

Skojarzenie struktur danych z odpowiednimi zbiorami było ostatnim etapem pracy
nad modelem reguł przetwarzania, związanych z wynajmem nieruchomości.
Kolejnym etapem będzie sporządzenie modelu związków encji, niezbędnych do
obsługi właśnie utworzonego modelu procesów. Do wykonania tego zadania
wykorzystać można program Silverrun ERX.

Przed przystąpieniem do tworzenia modelu związków encji konieczne jest jednak
zapisanie modelu reguł przetwarzania w składnicy pakietu Silverrun. Pozwoli to na
ponowne wykorzystanie zdefiniowanych właśnie zbiorów i struktur danych
w budowanych diagramach E-R. Aby zapisać model w składnicy należy wykonać
następujące czynności:

1. Wybrać z menu opcję

Util.\WRM Dictionary

. Spowoduje to dodanie do

głównego menu programu Silverrun dodatkowej opcji,

WRM Dictionary

2. Nie zamykając okna dialogowego

WRM Dictionary

wybrać opcję

Update WRM

Dictionary

, co spowoduje zapisanie modelu reguł przetwarzania w składnicy.

Następnie należy zaakceptować proponowaną domyślnie nazwę pliku
z raportem z aktualizacji - wystarczy w tym celu kliknąć przycisk

Update

Program Silverrun zapisze informacje statusowe o aktualizacji składnicy
w pliku raportu. Raport taki można przejrzeć przy użyciu dowolnego edytora
tekstowego ASCII.

3. Wybraæ opcjê

Save WRM Dictionary

z menu

WRM Dictionary

. Nowemu

słownikowi składnicy należy nadać nazwę

RENTMAN

, po czym kliknąć przycisk

Save

. Zbiory i struktury danych modelu reguł przetwarzania będą odtąd

dostępne w innych narzędziach, wchodzących w skład pakietu Silverrun.

Można teraz przystąpić do dalszej pracy nad projektem bazy danych - do tworzenia
modelu związków encji. Należy zatem zapisać wyniki dotychczasowych działań,
wyjść z programu Silverrun-BPM i uruchomić narzędzie Silverrun-ERX.

Modelowanie związków encji (ang. entity relationship modeling)

Pierwsza specyfikacja, dotycząca prezentacji danych relacyjnych w postaci
związków, zachodzących między encjami, została opublikowana w roku 1976. Jej
autorem był Peter Chen, a odpowiedni dokument nosił tytuł „The Entity
Relationship Model - Toward a Unified View of Data” (ACM Transactions on
Database Systems, Vol. 1, No. 1 [Marzec 1976], str. 9-36). Praca Chena (a także
opracowania innych teoretyków, takich jak Hammer i McLeod, autorów modelu
Semantic Data Model), dała początek powszechnemu zastosowaniu diagramów E-
R, będących graficznymi reprezentacjami związków encji i

stanowiących

podstawę współczesnego logicznego modelowania danych.

Projektowanie baz danych w modelu klient/serwer

167

Rodzaje diagramów E-R

Wyróżnia się zazwyczaj dwa rodzaje diagramów E-R. Pierwszy rodzaj odpowiada
standardowej notacji, zaproponowanej przez Chena. Diagramy E-R, sporządzane
w notacji Chena, są bardzo silnie rozczłonkowane; każdy diagram reprezentuje na
ogół tylko jeden związek między dwoma encjami. Rysunek 6.12 przedstawia
prosty model tego typu.

Drugi rodzaj modeli E-R to diagramy szczegółowe. Wprowadzono je do użytku,
gdyż w złożonych projektach baz danych notacja Chena wymagała sporządzania
setek (a nawet tysięcy) pojedynczych diagramów. Szczegółowe modele E-R są na
ogół wolne od tej wady, gdyż pojedynczy diagram przedstawia wszystkie związki
danej encji. Centralnym elementem diagramu jest tutaj encja, a nie związek.
Szczegółowe diagramy E-R zawierają zazwyczaj informacje o

atrybutach

i znacząco odbiegają od prostych diagramów, sporządzonych zgodnie z notacją
Chena. Na rysunku 6.13 przedstawiono przykład szczegółowego diagramu E-R.

UWAGA:

Jedną z popularniejszych postaci szczegółowych diagramów E-R jest notacja
IDEF1X. Pierwotna wersja notacji IDEF1X opracowana została przez Roberta G.
Browna oraz lotnictwo wojskowe Stanów Zjednoczonych pod koniec lat 70-tych.
Upłynęło jednak sporo czasu, zanim notacja przyjęła obecny kształt. Duży wpływ

Rysunek 6.12.
Diagram E-R,
sporządzony wg
oryginalnej metody
Chena.

168

Część I

na ostateczną postać IDEF1X miały również instytucje cywilne, takie jak
Lockheed, Hughes Aircraft i Bank of America. Wojskowe korzenie notacji
IDEF1X sprawiły, że włączono ją do zestawu państwowych standardów
informatycznych - Federal Information Processing Standards.

Notacja IDEF1X opiera się zarówno na relacyjnym modelu danych Codda, jak i na
modelu związków encji Chena. Obok podobieństw między IDEF1X a modelami
Codda i Chena występują także liczne różnice. Na ogół nie jest istotna ich
dokładna znajomość, wystarczy zdawać sobie sprawę z ich istnienia. Szczególną
uwagę na wszelkie rozbieżności powinni zwrócić użytkownicy programów ERWin
oraz ER/1, które działają właśnie w oparciu o model IDEF1X.

Najogólniej mówiąc encje, zdefiniowane w diagramach E-R, odpowiadają tabelom
w modelu relacyjnym i fizycznej implementacji bazy danych. Dlatego wiele
popularnych narzędzi do modelowania związków encji pozwala na równoległe
użycie elementów modelu relacyjnego i fizycznych baz danych oraz elementów
modelu E-R. W praktyce bardziej opłacalne jest przedstawianie korelacji między
encjami i tabelami. Nie ma powodu, by zmuszać użytkownika do zachowywania
formalnych podziałów.

Podstawowe pojęcia z zakresu modelowania związków encji (E-R)

Przed rozpoczęciem bliższego omówienia modelowania związków encji
wyjaśnimy wybrane terminy, związane z tym zagadnieniem. Poznanie właściwej
terminologii jest konieczne dla zrozumienia dalszej części dyskusji. Prezentowany

Rysunek 6.13.
Bardziej
szczegółowy
diagram E-R,
odbiegający od
klasycznego stylu
diagramów Chena.

Projektowanie baz danych w modelu klient/serwer

169

tutaj słowniczek terminów nie jest w

pełni wyczerpujący, ale umożliwi

postawienie pierwszych kroków na drodze do tworzenia własnych modeli E-R.
Najistotniejsze - zdaniem autora - terminy zebrano w Tabeli 6.2. Niektóre
przedstawione w niej pojęcia odnoszą się wyłącznie do modelowania związków
encji, inne dotyczą szerszego zagadnienia logicznego modelowania danych.

Tabela 6.2. Słownik najważniejszych pojęć z zakresu modelowania związków

encji.

Pojęcie Definicja

Encja
(ang. entity)

Rzeczywisty typ obiektu - osoba, miejsce, zdarzenie
lub przedmiot - którego dane są przechowywane
w systemie. Encje nazywane bywają też klasami encji.

Wystąpienie encji
(ang. etity instance)

Konkretna jednostka, należąca do klasy encji. Na
przykład, klient Jan Kowalski byłby wystąpieniem
encji KLIENT. KLIENT jest w tym przypadku klasą
encji.

Model związków encji
(ang. entity-relationship
model, E-R model)

Logiczny model danych, oparty na założeniu, że
wszystkie elementy modelowanego środowiska dają
się uogólnić i

przedstawić w

formie wyidealizo-

wanych, abstrakcyjnych jednostek - encji. Encje
opisane są za pomocą ich własności lub - inaczej -
atrybutów. Między encjami zachodzą związki, wynika-
jące z czynności, realizowanych przez poszczególne
encje względem pozostałych. Diagram E-R stanowi
graficzną reprezentację tych związków.

Podklasa
(ang. subtype)

Klasa encji, będąca podzbiorem większego, szerzej
zdefiniowanego typu encji, nazywanego nadklasą. Na
przykład, klasa encji PIŁKARZ mogłaby być podklasą
klasy

SPORTOWIEC

. Podklasy dziedziczą na ogół

atrybuty i związki swoich generalizacji, mogą jednak
mieć również własne, indywidualne atrybuty i związki.
Grupy podklas (np.

PIŁKARZ

KOSZYKARZ

SIATKARZ

) nazywane są po angielsku subtype clusters.

Nadklasa/generalizacja
(ang. Supertype)

Klasa encji, będąca nadzbiorem bardziej zawężonych
typów encji, nazywanych podklasami. Na przykład,
klasa encji

SAMOCHÓD

mogłaby stanowić

generalizację podzbiorów encji

FIAT, OPEL

VOLKSWAGEN

Atrybut

Właściwość encji lub związku encji. Atrybuty

170

Część I

Pojęcie Definicja
(ang. attribute)

szczegółowo opisują encje. Na przykład atrybut

NumerPESEL

mógłby być atrybutem klasy encji

PRACOWNIK

Domena
(ang. domain)

Typ danych lub zakres wartości, dozwolony dla danego
atrybutu. Na przykład, zaliczenie atrybutu

Data

Zatrudnienia

do domeny

TData

oznacza, że

wartości tego atrybutu muszą być poprawnymi datami.
Podobnie zaliczenie atrybutu

Cena

do domeny

TKosztNiezerowy

oznacza, że wartości atrybutu

cena muszą być niezerowe.

Integralność domeny
(ang. domain integrity)

Reguły decydujące o dozwolonych dla danej domeny
typach danych. Zapewnienie integralności domeny
gwarantuje na przykład, że wszystkie wartości,
należące do domeny

TData,

rzeczywiście są

poprawnymi datami, a wartości atrybutu, należącego
do domeny Liczba, są istotnie liczbami.

Zwi¹zek
(ang. relationship)

Połączenie dwóch encji, określające zachowanie jednej
z nich w odpowiedzi na zmianę stanu drugiej.
Wyróżnia się pięć podstawowych typów związków:
jeden-wiele, wiele-wiele, jeden-jeden, wzajemnego
wykluczenia i rekurencyjny.

Integralność związków
(ang. relational
integrity)

Reguły zapewniające zachowanie związków między
encjami. Na przykład, integralność związków
uniemożliwia usunięcie tych wystąpień encji

KLIENT

z którymi skojarzone są wystąpienia encji

FAKTURA

Asocjacja
(ang. Connectivity)

Sposób skojarzenia wystąpień encji w ramach związku.
Przykładowo definicja asocjacji encji

FAKTURA

i KLIENT

może zawierać informację, że dla każdego

wystąpienia encji

KLIENT

może istnieć wiele

skojarzonych wystąpień klasy

FAKTURA

, ponieważ

z każdym klientem może być przeprowadzanych wiele
transakcji.

Liczność
(ang. cardinality)

Liczba wystąpień encji skojarzonych w

ramach

związku. Ilościowo definiuje abstrakcyjne związki
encji, stanowiąc rozwinięcie definicji asocjacji. I tak
liczność związku encji

FAKTURA i

KLIENT

mogłaby gwarantować, że dla każdego wystąpienia
encji

FAKTURA

istnieje przynajmniej jedno skojarzone

Projektowanie baz danych w modelu klient/serwer

171

Pojęcie Definicja

z nią wystąpienie encji

KLIENT

Opcjonalność
(ang. modality)

Określa, czy istnienie wystąpienia encji jest w danym
związku opcjonalne czy wymagane. Jako parametr
liczbowy - minimalna liczność związku encji.

Normalizacja
(ang. normalization)

Usuwanie nadmiarowych, niespójnych i uwikłanych
elementów modelu danych. Celem normalizacji jest
uzyskanie modelu, którego każdy element reprezentuje
nie więcej niż jeden obiekt rzeczywisty.

Identyfikator encji
(ang. etity identifier)

Kombinacja atrybutów jednoznacznie odróżniająca
poszczególne wystąpienia encji.

Między pojęciami z zakresu modelowania związków encji a odpowiednimi
pojęciami, dotyczącymi relacyjnego modelu danych, zachodzi bezpośrednia
korelacja. W tabeli 6.3. zestawiono niektóre pojęcia z zakresu modelowania E-R
z ich odpowiednikami relacyjnymi.

Tabela 6.3. Zestawienie pojęć z zakresu modelowania E-R z odpowiednimi

pojęciami, dotyczącymi relacyjnego modelu danych.

Model E-R

Model relacyjny/logiczny

Encja

Tabela / relacja

Wystąpienie encji

Wiersz / krotka

Identyfikator encji

Klucz główny

Unikalny identyfikator

Klucz potencjalny

Związek Klucz

obcy

Atrybut

Kolumna / atrybut

Domena Typ

danych

W pakiecie Silverrun, podobnie jak w większości rozbudowanych narzędzi do
modelowania, model E-R rozpatrywany jest jako podzbiór relacyjnego modelu
danych. Model E-R nie odpowiada kompletnemu, logicznemu modelowi danych;
jest ponadto niezależny od projektu fizycznej implementacji. Silverrun ERX
pozwala wprawdzie na stosowanie elementów logicznych i fizycznych już na
poziomie modelu E-R, konstrukcja programu nie zachęca jednak do korzystania
z tej możliwości.

172

Część I

Po wstępie, którego zadaniem było przybliżenie podstawowych pojęć dotyczących
modelowania, możemy przystąpić do tworzenia modelu, wspomagającego
zdefiniowane wcześniej procesy.

Budowa modelu E-R

W przypadku omawianego przykładowego systemu, rozpoczęcie budowy modelu
E-R poprzedzone zostało przygotowaniem kompletnego modelu reguł
przetwarzania. Skróci to znacznie czas tworzenia modelu E-R. Narzędzie Silverrun
ERX posłuży w

tym przypadku przede wszystkim do przeprowadzenia

normalizacji danych.

UWAGA:

Normalizację włącza się na ogół do procesu budowy relacyjnego modelu danych
albo projektowania bazy danych. W niniejszej książce modelowanie związków
encji potraktowano jako pierwszy etap powyższego procesu. Niektórzy autorzy
uważają obie metody modelowania za całkowicie niezależne. Część projektantów
przechodzi od modelu E-R bezpośrednio do etapu tworzenia elementów bazy
danych; inni budują modele relacyjne nie sporządzając uprzednio diagramów E-R.
W niniejszym rozdziale zaprezentowane zostaną obie metody modelowania. Po
sporządzeniu modelu związków encji przy pomocy narzędzia Silverrun ERX,
przejdziemy do budowy modelu relacyjnego przy użyciu programu Silverrun RDM
(Relational Data Modeling). Na ogół bardziej naturalne wydaje się wykonanie
normalizacji dopiero na etapie tworzenia modelu relacyjnego (RDM).
Mechanizmy normalizacji są jednak dostępne także w programie Silverrun ERX.
Zostaną zatem omówione już w niniejszej sekcji.

Pierwszą czynnością na drodze do utworzenia modelu E-R będzie dołączenie
informacji o obiektach modelu reguł przetwarzania. Informacje te zostały zapisane
w składnicy obiektów pakietu Silverrun. Aby wczytać i dołączyć informacje ze
składnicy, należy:

1. Uruchomić program Silverrun ERX i utworzyć nowy projekt. Następnie należy

zdefiniować siatkę na ekranie i określić pozostałe ustawienia początkowe -
odbywa się to tak, jak w programie BPM.

2. Wybraæ opcjê menu

Util.\WRM Dictionary

. W głównym menu programu ERX

pojawi się nowa opcja

WRM Dictionary

3. Z menu

WRM Dictionary

wywołać opcję

Open WRM Dictionary

, a następnie

wybrać składnicę RENTMAN.WRM, utworzoną w programie BPM.

4. Wybrać opcję

Update a Model

z menu

WRM Dictionary

, a następnie kliknąć

przycisk

Update

w oknie dialogowym, które pojawi się na ekranie. Bieżący

Projektowanie baz danych w modelu klient/serwer

173

model zostanie zaktualizowany przez dodanie obiektów pobranych ze
składnicy. W odpowiedzi na pytanie, czy model ma zostać połączony
z projektem z WRM Dictionary, należy odpowiedzieć twierdząco (

Yes

5. Kliknąć przycisk

Save

, co spowoduje zaakceptowanie domyślnej nazwy

raportu z

aktualizacji. Program poprosi o

zezwolenie na zastąpienie

poprzedniego raportu. W odpowiedzi należy kliknąć

Yes

6. Kliknąć przycisk

w oknie komunikatu

Update Completed

7. Zamknąć okno

WRM Dictionary

i powrócić do normalnego trybu pracy nad

modelem.

8. Wybrać opcję menu

Presentation\Palettes\Components: SR Stores

, co

spowoduje wyświetlenie na ekranie palety

Store

(obiektów typu zbiór).

9. Przeciągnąć wszystkie zbiory z palety na roboczy obszar modelu, trzymając

przyciśnięty prawy klawisz myszy. Doprowadzi to do utworzenia encji,
odpowiadających obiektom typu Store, zdefiniowanym w modelu procesów.
Próba przeciągnięcia zbioru

PROPERTY

wywoła komunikat o błędzie, gdyż ze

zbiorem tym nie jest skojarzona żadna struktura danych.

10. Zamknąć paletę

Store

11. Rozmieścić encje w polu roboczym, tak aby nie nakładały się na siebie.

Rysunek 6.14 przedstawia poprawny model na obecnym etapie jego budowy.

Rysunek 6.14.
Model zawierający
obiekty typu Entity
(encje) utworzone
na podstawie
zawartości
składnicy
(repository)
systemu Silverrun.

174

Część I

Kolejnym etapem działań powinna być teraz dekompozycja istniejących encji na
znormalizowane klasy encji, a następnie zdefiniowanie związków zachodzących
między nimi. Ogólny sposób postępowania przy tworzeniu modelu związków encji
sprowadza się do trzech kroków:

1. Zdefiniowanie wyjściowego zbioru encji.

2. Dekompozycja encji do postaci znormalizowanych.

3. Zdefiniowanie asocjacji (połączeń) między encjami przez określenie ich

wzajemnych związków.

Program Silverrun ERX oferuje mechanizm automatycznej normalizacji (eksperta
normalizacji), który wyręcza projektanta w wielu czynnościach, związanych
z modelowaniem danych. W wielu przypadkach ekspert może dokonać pełnej
normalizacji modelu po uzyskaniu od projektanta odpowiedzi na kilka prostych
pytań. Aby wywołać narzędzie normalizacyjne programu ERX, należy:

1. Wybrać polecenie menu

Model\Abbreviations

; umożliwia ono zdefiniowanie

skrótów używanych w nazwach encji i atrybutów. Możliwe jest, na przykład,
zastąpienie we wszystkich nazwach słowa

Number

skrótem

. W rozdziale 4,

„Konwencje”, podnoszono wielokrotnie problem jednolitego nazewnictwa
i konsekwencji w używaniu skrótów. Rysunek 6.15 przedstawia pole dialogowe

Abbreviations

2. Uaktywnić tryb eksperta, wybierając opcję

Expert Mode

z menu

Expert

Rysunek 6.15.
Narzędzie
Silverrun
umożliwia
zdefiniowanie
skrótów,
używanych
w nazwach
elementów modelu.

Projektowanie baz danych w modelu klient/serwer

175

3. Wybrać opcję menu

Expert\Normalize Model

. Program spyta, czy ma być

przeprowadzana analiza nazw. Należy odpowiedzieć twierdząco (

Yes

Następnie należy potwierdzić chęć przeprowadzania normalizacji.

4. Po przeprowadzeniu normalizacji diagram widoczny na ekranie stanie się raczej

nieczytelny. Encje będą poprzesuwane, a symbole związków - nałożone na
siebie (zob. rysunek 6.16). Należy zatem tak je poprzesuwać, aby uzyskać
czytelny diagram, bez nakładających się elementów.

5. Prawidłowe rozmieszczenie elementów znormalizowanego modelu ujawni

powstanie nowej encji Property. Została ona dodana automatycznie przez
eksperta normalizacji, z uwagi na nadmiarowość, występującą w oryginalnej
encji LEASE. Należy teraz podwójnie kliknąć na nagłówku nowej encji
i zapisać jej nazwę dużymi literami: PROPERTY. Rysunek 6.17 przedstawia
uzyskany model.

Rysunek 6.16.
Model po
normalizacji
przeprowadzonej
przez program
ERX.

176

Część I

Projektując obiekty struktur danych, stanowiące element modelu procesów,
pominęliśmy strukturę danych dla zbioru PROPERTY. Teraz nietrudno już
domyślić się powodów takiego postępowania. Atrybuty zbioru PROPERTY były
zawarte w strukturze danych LEASE. Atrybuty, dotyczące nieruchomości, zostały
automatycznie usunięte z encji LEASE i umieszczone w nowej encji Property.
Należy ponadto zwrócić uwagę, że atrybut Property Number został skopiowany
z encji CALL. Przykład ten jest dobrą ilustracją olbrzymich możliwości narzędzi
CASE, wspomagających modelowanie danych.

Normalizacja

Proces normalizacji, zrealizowany właśnie przy pomocy narzędzia ERX, wymaga
bliższego omówienia. Normalizacja, której słownikową definicję podano już
wcześniej, przyczynia się do ograniczenia nakładu pracy i

zmniejszenia

prawdopodobieństwa wystąpienia błędów podczas uaktualniania wierszy tabeli.
Na przykład, jeśli adres klienta przechowywany będzie w każdym rekordzie tabeli
FAKTURA, to zmiana adresu klienta pociągnie za sobą konieczność aktualizacji
wszystkich rekordów z fakturami danego klienta. Jeśli jednak adres ten będzie
przechowywany w jednym miejscu, w oddzielnej tabeli, to aktualizacja sprowadzi
się do zmiany pojedynczego rekordu z adresem. Odbędzie się zatem w krótszym
czasie i bez ryzyka pominięcia niektórych wierszy w tabeli FAKTURA.

Proces normalizacji podzielono formalnie na pięć etapów lub postaci - począwszy
od pierwszej postaci normalnej aż do piątej postaci normalnej. Określenia te
odnoszą się do pięciu zestawów kryteriów, które encja musi spełnić, aby przyjąć
odpowiednią postać normalną. Przyjęcie kolejnej postaci normalnej możliwe jest

Rysunek 6.17.
Ekspert
normalizacji
programu ERX
dodał do projektu
nową encję.

Projektowanie baz danych w modelu klient/serwer

177

dopiero po spełnieniu kryteriów narzucanych przez poprzednie postacie. Mimo że
zdefiniowano pięć postaci normalnych, w praktyce wykorzystuje się na ogół tylko
pierwsze trzy. Ostatnie dwie uznawane są za zbyt szczegółowe i restrykcyjne, jeśli
wziąć pod uwagę uwarunkowania typowych projektów baz danych.

UWAGA:

W dotychczasowej dyskusji nie poświęcano wiele uwagi relacyjnemu modelowi
danych. Mimo to przy omawianiu procesu normalizacji pojęcia relacyjne - takie
jak tabela, wiersz i kolumna - stosowane będą zamiennie z odpowiednimi
terminami, dotyczącymi modelowania związków encji, takimi jak encja,
wystąpienie encji i atrybut. Przykłady, opisane w kategoriach relacyjnego modelu
danych i fizycznych obiektów bazy danych, będą prawdopodobnie łatwiejsze
w odbiorze niż te same przykłady podane przy zastosowaniu terminów
abstrakcyjnych.

Pierwsza postać normalna

Aby tabela przyjęła pierwszą postać normalną, wszystkie jej kolumny muszą być
całkowicie niepodzielne; ponadto tabela nie może zawierać grup powtarzalnych.
Kolumna jest niepodzielna, gdy zawiera tylko jeden element danych. Kolumna
Adres zawiera zatem nie tylko nazwę ulicy, lecz także nazwę miasta, kod
pocztowy, itp. Nie jest to zatem kolumna niepodzielna. Chcąc uzyskać zgodność
z warunkami pierwszej postaci normalnej, należy tak zaprojektowane kolumny
rozbić, tj. utworzyć na ich podstawie kilka oddzielnych kolumn.

O grupie powtarzalnej mówimy wówczas, gdy jakaś kolumna powtarza się
w definicji wiersza tylko po to, aby możliwe było przechowywanie w nim wielu
wartości tego samego atrybutu. W przykładowym modelu można było przyjąć, że
informacja o wynajmowanej nieruchomości przechowywana będzie bezpośrednio
w

tabeli LEASE (umowy najmu), a

nie w

oddzielnej tabeli PROPERTY

(nieruchomość). W takim wypadku nie byłoby jednak możliwe wynajęcie jednemu
podmiotowi (np. firmie) więcej niż jednej nieruchomości. Aby rozwiązać ten
problem, wciąż posługując się wyłącznie tabelą LEASE, należałoby ustalić
maksymalną liczbę nieruchomości, które może wynajmować jeden podmiot
i dodać odpowiednią liczbę kolumn do tabeli. Te powtarzające się kolumny byłyby
właśnie grupą powtarzalną.

Niektóre narzędzia i języki do obsługi baz danych zawierają mechanizmy
sprzyjające stosowaniu powtarzalnych grup, a zarazem naruszaniu pierwszej
postaci normalnej. Bazy danych, której tabele nie spełniają warunków pierwszej
postaci normalnej, nie można nazwać relacyjną. Przykładem narzędzia
zawierającego mechanizmy o działaniu sprzecznym z zasadami projektowania
relacyjnych baz danych, jest program Advanced Revelation. W systemie tym

178

Część I

występują tzw. kolumny wielowartościowe, które są w

istocie grupami

powtarzalnymi. Stosowanie kolumn wielowartościowych narusza pierwszą postać
normalną, a mimo to jest często spotykaną praktyką w aplikacjach Advanced
Revelation. Podobną strukturą, naruszającą pierwszą postać normalną, jest tablica
asocjacyjna w języku Perl. Tablice takie są zestawami par typu nazwa/wartość,
pamiętanymi tak jak pojedyncze zmienne. Choć struktura ta daje programiście
duże możliwości i jest wygodna w użyciu, sprzyja jednak tworzeniu baz danych
i aplikacji niezgodnych z pierwszą postacią normalną. Innym przykładem
mechanizmu sprzecznego z zasadami projektowania relacyjnych baz danych jest
konstrukcja języka COBOL: groupname occurs several times. Obecność
w COBOL-u tego rodzaju elementów nie powinna dziwić, gdyż język ten jest
starszy niż teoria relacyjnych baz danych.

Stosowanie grup powtarzalnych jest bardzo złą praktyką - stwierdzenie to odnosi
się tak do projektowania baz danych, jak i aplikacji. Należy pamiętać, że projektu
bazy danych nie da się stworzyć w oderwaniu od projektu aplikacji. Informacja,
przetwarzana przez program, musi być gdzieś przechowywana. W praktyce
stosowanie grup powtarzalnych prowokuje powstawanie wielu problemów.
Weźmy ponownie pod uwagę przykład tabeli LEASE. Jeśli miałaby ona zawierać
informacje o wszystkich nieruchomościach wynajmowanych przez najemcę, to
każdy jej wiersz zawierałby kilkakrotnie powtórzone kolumny z informacjami
o nieruchomościach, niezależnie od tego czy w danym przypadku byłyby one
zapełnione, czy też nie. Spowodowałoby to niepotrzebny rozrost bazy danych.
Ponadto grupy powtarzalne są źródłem problemów przy przetwarzaniu zawartych
w nich danych. W szczególności kłopotliwe jest formatowanie drukowanych
raportów. Zagadnienie przetwarzania szeregu wierszy zamienia się w trudniejsze
zadanie przetwarzania wierszy i

kolumn. Wreszcie zwiększenie założonej

początkowo maksymalnej liczby nieruchomości, jaką może wynająć jeden
podmiot, wymagałoby modyfikacji struktury tabeli i fragmentów samej aplikacji.

Druga postać normalna

Aby tabela przyjęła drugą postać normalną, 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.

Rozważmy ponownie przykład tabeli FAKTURA. Gdyby jej klucz główny składał
się z kolumn NrMagazynu i Nr Faktury, to przechowywanie nazwy magazynu
w każdym wierszu tej tabeli byłoby naruszeniem drugiej postaci normalnej.
Kolumna NazwaMagazynu nie byłaby jednoznacznie identyfikowana przez obie
kolumny klucza głównego. Byłaby zależna od kolumny NrMagazynu, ale nie od
kolumny NrFaktury. Dlatego nazwę magazynu należy pobierać w razie potrzeby

Projektowanie baz danych w modelu klient/serwer

179

z oddzielnej tabeli, korzystając ze złączenia, a nie przechowywać na stałe w tabeli
FAKTURA.

Trzecia postać normalna

Aby tabela przyjęła trzecią postać normalną, 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.

Powróćmy do przykładu tabeli FAKTURA. Załóżmy, że jej kluczem głównym
nadal są kolumny Nr Magazynu i Nr Faktury. W tabeli występuje ponadto
kolumna Nr Klienta, która nie jest kluczem. Jeśli w tej samej tabeli występowałaby
kolumna Nazwa Klienta, to tabela nie spełniłaby warunków trzeciej postaci
normalnej. Kolumny Nr Klienta i Nazwa Klienta są bowiem wzajemnie zależne.
Zmiana numeru klienta musiałaby pociągać za sobą zmianę w kolumnie Nazwa
Klienta i odwrotnie. Dlatego kolumna Nazwa Klienta powinna znaleźć się
w oddzielnej tabeli (np. KLIENT), a jej zawartość powinna być pobierana w razie
potrzeby za pomocą odpowiedniego złączenia.

UWAGA:

Rozszerzona definicja trzeciej postaci normalnej, zwana postacią normalną
Boyce'a - Codda (BCNF, Boyce-Codd Normal Form) zawiera dodatkowy warunek:
każda kolumna, od której zależna jest jakakolwiek inna kolumna, musi być
kluczem unikalnym. Zbiory kolumn, które mogą w

sposób jednoznaczny

identyfikować wiersze, nazywane są kluczami potencjalnymi. Klucz główny tabeli
wybierany jest spośród kluczy potencjalnych. W tabeli znormalizowanej do
postaci BCNF kolumna może być zależna tylko od klucza potencjalnego. Postać
normalna BCNF jest zatem szczególnym przypadkiem trzeciej postaci normalnej,
dopuszczającym zależności pomiędzy kolumnami-kluczami potencjalnymi oraz
innymi kolumnami, nie będącymi kluczami. Należy podkreślić, że występowanie
takich zależności nie stanowi naruszenia trzeciej postaci normalnej, gdyż kolumny
zależne są wyłącznie od kluczy potencjalnych. Klucze takie jednoznacznie
identyfikują wiersze, podobnie jak klucz główny tabeli. A zatem rozróżnienie
między zależnością od klucza głównego i od klucza potencjalnego jest problemem
czysto akademickim - oba rodzaje kluczy jednoznacznie identyfikują wiersze
tabeli.
Nie należy przywiązywać szczególnie dużej wagi do powyższego rozszerzenia
definicji trzeciej postaci normalnej. Zgodność z klasyczną definicją trzeciej postaci
normalnej jest powszechnie przyjętym kryterium normalizacji. Nie należy brać pod
uwagę różnic, które nie mają praktycznego znaczenia.

180

Część I

Czwarta postać normalna

Czwarta postać normalna eliminuje wielowartościowe zależności między
kolumnami. O zależności wielowartościowej mówimy wówczas, gdy jedna
kolumna nie identyfikuje jednoznacznie drugiej, a jedynie zawęża ją do zbioru
predefiniowanych wartości. Przyjrzyjmy się tabeli TENANT (najemca)
przykładowego systemu RENTMAN. Dla uproszczenia dyskusji załóżmy, że
jedyną informacją o

pracodawcy (Employer) najemcy będzie jego nazwa

(pomijamy adres, itp.). W tabeli TENANT znajdzie się zatem atrybut

Employer

Jeśli jeden najemca ma kilku pracodawców (bo jest np. pracoholikiem i pisuje
książki po nocach), to w tabeli TENANT musi znaleźć się kilka wierszy,
związanych z tym samym najemcą. Wiersze te będą niemal identyczne - będą się
różnić jedynie wartością atrybutu

Employer

Relacja między kolumną Employer a każdą inną kolumną tabeli TENANT będzie
zależnością wielowartościową. Każdej wartości w

kolumnie TenantNo

odpowiadać  będzie kilka różnych wartości z kolumny Employer. W praktyce
założenie,  że jeden najemca może mieć kilku pracodawców, może okazać się
przydatne. Ponadto czasami celowe będzie sporządzenie listy wszystkich
najemców, zatrudnionych u danego pracodawcy. W takim przypadku, chcąc
zachować zgodność z warunkami czwartej postaci normalnej, należałoby utworzyć
oddzielną tabelę, której jedyną funkcją byłoby przechowywanie danych o relacjach
między najemcami a pracodawcami. W idealnym przypadku tabela taka składałaby
się z dwóch kolumn: TenantNo (nr najemcy) i Employer (pracodawca). Obie
kolumny tworzyłyby jeden, złożony klucz główny. Chcąc uzyskać komplet
informacji o danym najemcy, należałoby wykonać  złączenie tabeli TENANT
z nową tabelą na podstawie wspólnej kolumny TenantNo.

W rzeczywistych aplikacjach nierzadko można natrafić na tabele, których
konstrukcja narusza warunki czwartej postaci normalnej. Dekompozycja encji,
sięgająca poza trzecią postać normalną, prowadzi czasami do powstania bardzo
skomplikowanego modelu, którego implementacja uznawana jest za nieopłacalną.

Piąta postać normalna

Piąta postać normalna zdefiniowana jest jako postać bazy danych, w której
wszystkie tabele, które mają więcej niż dwa klucze potencjalne i dają się rozbić
bez utraty danych, powinny zostać podzielone na osobne tabele, po jednej dla
każdego klucza potencjalnego. Istnieje kilka powodów, dla których piąta postać
normalna występuje niezmiernie rzadko. Po pierwsze, w praktyce trudno jest
natrafić na tabelę, w której więcej niż dwa zestawy kolumn jednoznacznie
identyfikowałyby wiersze. Po drugie, silna dekompozycja może doprowadzić do
powstawania niedokładnych złączeń, np. generujących nowe wiersze.
W rzeczywistych aplikacjach piąta postać normalna niemal nie występuje. Została
tutaj wspomniana wyłącznie dla zachowania kompletności opisu.

Projektowanie baz danych w modelu klient/serwer

181

O konieczności zachowania umiaru w normalizacji

Przystępując do normalizacji bazy danych należy zachować ostrożność i nie
przekroczyć granicy opłacalności. Zbyt daleko posunięta normalizacja może mieć
fatalny wpływ na wydajność. Można by, na przykład, rozważyć utworzenie
oddzielnej tabeli do przechowywania informacji o

pracodawcach. Obecnie

informacje te pamiętane są w tabeli TENANT. W istocie kolumny

Employer

i EmployerAddress

są w oczywisty sposób zależne, co jest naruszeniem

warunków trzeciej postaci normalnej. Jakie jednak byłyby realne korzyści
z utworzenia oddzielnej tabeli na dane o pracodawcach? Dane te prawdopodobnie
są istotne wyłącznie w odniesieniu do określonego najemcy. Firmy, będącej
użytkownikiem systemu RENTMAN, nie interesuje lista najemców, zatrudnionych
u wybranego pracodawcy. Załóżmy ponadto, że nie występuje w praktyce potrzeba
przechowywania danych o więcej niż jednym pracodawcy każdego najemcy.
Wreszcie sensowne wydaje się założenie, że nigdy nie zajdzie potrzeba
wprowadzania globalnych zmian w danych o pracodawcach. Biorąc pod uwagę
powyższe założenia, można stwierdzić, że wydzielanie osobnej tabeli na dane
pracodawców byłoby jedynie stratą czasu.

Zdarzają się również sytuacje, w których żądaną wydajność można uzyskać tylko
przez świadomą, ograniczoną denormalizację. Jest to szczególnie prawdopodobne
w przypadku aplikacji, które przetwarzają bardzo duże zbiory danych. Rozważmy,
na przykład, aplikację, która dziennie musi przetworzyć setki tysięcy dowodów
płatności kartą kredytową. Każdy dowód płatności zawiera m.in. numer karty,
wysokość kwoty transakcji i datę ważności karty. Na koniec każdego dnia
roboczego system musi wydrukować raport, zawierający listę wszystkich użytych
kart kredytowych, a dla każdej karty - sumę kwot dokonanych nią transakcji i datę
ważności. Ponieważ datę ważności bez trudu można uzyskać ze złączenia dziennej
listy kart z główną tabelą danych o kartach, reguły normalizacji nakazują usunięcie
kolumny „data ważności” z tabeli transakcji, choć data znajduje się na każdym
z dowodów, na podstawie których generowane są wiersze tej tabeli.

Mimo że data ważności znajduje się na każdym dowodzie transakcji, reguły
normalizacji nakazują pobieranie jej z głównej tabeli kart. Niepożądanym,
ubocznym efektem takiego postępowania będzie jednak dwukrotne wydłużenie
czasu sporządzania raportu dziennego. Klient, przyszły użytkownik aplikacji, może
uznać, że wydajność programu jest niezadowalająca.

Jeśli jedynym środkiem poprawy wydajności ma być w

tym przypadku

modyfikacja projektu bazy danych, to należałoby rozważyć przechowywanie daty
ważności razem z każdym dowodem transakcji. Oczywiście prowadzi to do
wystąpienia w bazie nadmiarowości danych. Jest to jednak nadmiarowość
kontrolowana, będąca wynikiem przemyślanej decyzji projektanta. Powyższy
przykład ilustruje możliwe do zaakceptowania odstępstwo od ścisłych reguł

182

Część I

projektowania relacyjnych baz danych, a także wpływ wymagań operacyjnych
aplikacji na projekt.

Decydując się na wprowadzenie kontrolowanej nadmiarowości należy kierować
się jedną, podstawową zasadą: najpierw całkowicie znormalizować bazę danych,
a dopiero potem wprowadzać nadmiarowość, jeśli występuje taka potrzeba. Nie
wolno ulegać pokusie naruszania reguł normalizacji już w pierwszej wersji
projektu. Ponadto względy wydajności nie mogą stanowić wymówki dla
nieprawidłowo sporządzonego projektu bazy danych. Odstępstwa od normalizacji
rzadko znajdują uzasadnienie - wyjątek stanowią systemy przetwarzające
rzeczywiście bardzo duże zbiory danych.

Weryfikacja i uzupełnienie modelu E-R

Model jest formalnie znormalizowany, wymaga jednak jeszcze wielu uzupełnień.
Przede wszystkim nie zdefiniowano w

nim identyfikatorów encji (kluczy

głównych). Ponadto nie zweryfikowano poprawności informacji o asocjacjach,
wygenerowanych automatycznie przez eksperta normalizacji.

Weryfikacja asocjacji

Dalszą pracę nad projektem rozpoczniemy od sprawdzenia, czy ekspert
normalizacji prawidłowo określił warunki asocjacji encji. Aby dokonać takiej
weryfikacji, należy:

1. Wybraæ opcjê menu

Expert\Verify Connectivities

. Na ekranie pojawi się okno

dialogowe

Verify Connectivities

. Należy wybrać opcję

all connectivities

i upewnić się, czy opcja

for selected relationships

pozostaje nieaktywna, po

czym kliknąć przycisk

Verify

2. Program zada teraz szereg pytań, dzięki którym ekspert normalizacji uzyska

dodatkowe informacje o związkach, zachodzących między encjami. Poniższa
lista zawiera odpowiedzi, których należy udzielić na kolejno zadawane pytania:

In general, is it necessary for a ”CALL” to have a ”PROPERTY” to exist?

(Czy z

każdym zgłoszeniem telefonicznym musi być skojarzona

nieruchomość?) - odpowiedź No (Nie).

In general, can one „CALL” have many „PROPERTY”? (Czy z jednym

zgłoszeniem telefonicznym może być skojarzona więcej niż jedna
nieruchomość?) - odpowiedź No (Nie).

In general, is it necessary for a ”PROPERTY” to have a ”CALL” to exist?

(Czy z każdą nieruchomością musi być skojarzone zgłoszenie telefoniczne?)
- odpowiedź No (Nie).

Projektowanie baz danych w modelu klient/serwer

183

In general, can one „PROPERTY” have many „CALL”? (Czy jednej

nieruchomości może dotyczyć wiele zgłoszeń telefonicznych?) - odpowiedź
Yes (Tak).

In general, is it necessary for a ”LEASE” to have a ”PROPERTY” to exist?

(Czy z każdą umową najmu musi być skojarzona nieruchomość?) -
odpowiedź Yes (Tak).

In general, can one „LEASE” have many „PROPERTY”? (Czy jedna

umowa najmu może dotyczyć wielu nieruchomości?) - odpowiedź No (Nie).

In general, is it necessary for a ”PROPERTY” to have a ”LEASE” to exist?

(Czy każda nieruchomość musi mieć umowę najmu?) - odpowiedź No (Nie).

In general, can one „PROPERTY” have many „LEASE”? (Czy jednej

nieruchomości może dotyczyć wiele umów najmu?) - odpowiedź Yes (Tak).

In general, is it necessary for a ”LEASE” to have a ”TENANT” to exist?

(Czy z każdą umową najmu musi być skojarzony najemca?) - odpowiedź
Yes (Tak).

In general, can one „LEASE” have many „TENANT”? (Czy jedna umowa

najmu może dotyczyć wielu najemców?) - odpowiedź No (Nie).

In general, is it necessary for a ”TENANT” to have a ”LEASE” to exist?

(Czy z każdym najemcą musi być skojarzona umowa najmu?) - odpowiedź
No (Nie).

In general, can one „TENANT” have many „LEASE”? (Czy jeden najemca

może mieć wiele umów najmu?) - odpowiedź Yes (Tak).

Ekspert normalizacji programu ERX zmodyfikuje teraz model, zgodnie
z

uzyskanymi odpowiedziami. W

prezentowanym przykładzie tylko jedno

z założeń, przyjętych pierwotnie przez eksperta, okazało się błędne. Na rysunku
6.18 przedstawiono zmodyfikowany, prawidłowy model. Porównanie tego rysunku
z rysunkiem 6.17 wykaże, że zmianie uległ związek pomiędzy encjami

CALL

i PROPERTY

184

Część I

Określenie liczności

Po uruchomieniu eksperta normalizacji, asocjacja encji

CALL i PROPERTY

zmieniła się z

1,1

0,1

. Jak należy interpretować liczby na diagramie?

Oznaczają one minimalną i maksymalną liczność encji, wchodzących w związek.
Liczność

1,1

między encjami

CALL i PROPERTY

oznacza, że dla każdego

wystąpienia encji

CALL

musi istnieć przynajmniej jedno wystąpienie encji

PROPERTY

. W kategoriach bazy danych można ten warunek interpretować

następująco: w każdym wierszu tabeli CALL musi znajdować się poprawny numer
nieruchomości (kolumna PropertyNo), pochodzący z tabeli PROPERTY; kolumna
PropertyNo nie może pozostać pusta. Odpowiedź, udzielona na pytanie eksperta
normalizacji, zmieniła ten warunek - stwierdzała bowiem, że nieprawdą jest, iż
z każdym zgłoszeniem telefonicznym musi być skojarzona nieruchomość (zob.
pierwsze pytanie). Dlatego ekspert normalizacji zredukował minimalną liczność do
zera. Zerowa liczność umożliwia w tym przypadku rejestrowanie telefonów, które
nie dotyczą konkretnych nieruchomości, np. zapytań potencjalnych najemców -
pozwala na niewpisywanie wartości do kolumny PropertyNo.

Z kolei maksymalna liczność równa 1 oznacza, że z każdym wystąpieniem encji

CALL

może być skojarzone najwyżej jedno wystąpienie encji

PROPERTY

A zatem jeden wiersz w tabeli CALL może zawierać odnośnik do jednej tylko
nieruchomości - nie może być skojarzony z wieloma nieruchomościami. Ekspert
podjął poprawną decyzję, jeśli zważyć, że telefony albo nie będą dotyczyły żadnej
konkretnej nieruchomości (np. zapytania potencjalnych najemców), albo będą

Rysunek 6.18.
Model po
zweryfikowaniu
asocjacji.

Projektowanie baz danych w modelu klient/serwer

185

dotyczyły jednej nieruchomości (np. zgłoszenia usterek, pochodzące od
najemców).

Liczność definiuje się z perspektywy najbliższej encji - do jej wyrażania można
użyć następującego zdania:

Dla każdego wiersza BLIŻSZEJ ENCJI wymaganych jest co

naj

mniej MINIMALNA LICZNOŚĆ skojarzonych wierszy i

nie więcej

niż MAKSYMALNA LICZNOŚĆ skojarzonych wierszy tabeli DALSZA

ENCJA.

W omawianym przypadku zdanie, opisujące związek między encjami CALL

PROPERTY, przyjęłoby postać:

Dla każdego wiersza CALL wymaganych jest co najmniej 0

skojarzonych wierszy i

nie więcej niż 1 skojarzony wiersz

tabeli PROPERTY.

Należy zwrócić uwagę, że, aby wyrazić odpowiedni związek z perspektywy encji

PROPERTY

, konieczne jest sformułowanie innego zdania. Jedno zdanie nie

wystarcza na ogół do pełnego opisania związku. Na przykład, wystąpienie encji

PROPERTY

(nieruchomość) nie musi wymagać istnienia skojarzonego z nim

wystąpienia encji

LEASE

(umowa najmu). Natomiast z wystąpieniem encji

LEASE

bez wątpienia musi być skojarzone wystąpienie encji

PROPERTY

. Innymi słowy:

może istnieć nie wynajęta nieruchomość, ale umowa najmu musi dotyczyć
istniejącej nieruchomości.

Związki encji często wyrażane są przy pomocy zdań, podobnych do
przedstawionych powyżej. Wiele narzędzi typu CASE umożliwia opisywanie
diagramów E-R analogicznymi zdaniami. Oto inny sposób opisywania związków
encji przy pomocy zdań:

ENCJA NADRZĘDNA ma co najmniej ... ENCJI POTOMNYCH

A zatem minimalną liczność przykładowego związku encji

CALL i PROPERTY

można byłoby zapisać jako:

CALL ma co najmniej zero PROPERTY

Odpowiednio, zdanie

CALL ma najwyżej jedną PROPERTY

wyrażałoby maksymalną liczność tego związku. Istnieje wiele wariantów zapisu,
wszystkie jednak opierają się na podobnych zasadach. Każdy projektant powinien
wybrać najbardziej odpowiadający mu sposób zapisu.

186

Część I

Wybór identyfikatorów encji

Kolejnym etapem na drodze do uzyskania kompletnego modelu E-R jest wybór
identyfikatorów poszczególnych encji. W modelu relacyjnym identyfikator encji
zostanie przekształcony w klucz główny; w fizycznej implementacji bazy danych
wymagany będzie odpowiedni indeks, zbudowany na bazie tego klucza.

Występują dwa rodzaje identyfikatorów encji: naturalne i sztuczne (zastępcze).
Naturalnym identyfikatorem encji jest atrybut lub zbiór atrybutów już występujący
w encji i jednoznacznie identyfikujący każde jej wystąpienie. Atrybut

NrPESEL

byłby na przykład naturalnym identyfikatorem encji

OBYWATEL

. Identyfikator

sztuczny jest to atrybut dodany do encji specjalnie po to, by służył jako
jednoznaczny identyfikator jej wystąpień. Przykładem identyfikatora sztucznego
jest atrybut

CallNo

encji

CALL

Uzupełnienie encji o sztuczny identyfikator bywa konieczne z wielu powodów.
Nawet jeśli istnieje już identyfikator naturalny, to może on okazać się zbyt długi
lub zbyt skomplikowany, co uniemożliwi jego praktyczne wykorzystanie.
Użytkownik może uznać wielokrotne wpisywanie numerów PESEL pracowników
za zbyt uciążliwe i zażyczyć sobie zastosowania w ich miejsce krótszych numerów
pracowników. Innym powodem, decydującym o

dodaniu sztucznego

identyfikatora, może być brak naturalnego identyfikatora danej encji. Przykładowo
encja

CALL

nie ma żadnego naturalnego atrybutu lub grupy atrybutów, które

mogłyby jednoznacznie rozróżniać poszczególne jej wystąpienia. Jedynym takim
atrybutem jest sztuczny identyfikator

CallNo

W przykładowym systemie RENTMAN wszystkie encje mają sztuczne
identyfikatory, mimo że w niektórych z nich dałoby się wyróżnić grupy atrybutów,
mogące pełnić rolę naturalnych, unikalnych identyfikatorów. Dodanie prostych,
zastępczych identyfikatorów, pozwoliło znacznie uprościć projekt. Przyspieszyło
proces tworzenia projektu i gwarantuje, że w przyszłości nie pojawią się
nieoczekiwane problemy.

Aby określić identyfikatory zdefiniowanych encji, należy:

1. Wybraæ opcjê menu

Expert\Search for Identifiers

2. Kliknąć przycisk

w oknie dialogowym, które pojawiło się na ekranie

(wcześniej należy upewnić się, że opcja for selected entities nie jest aktywna).

3. Program będzie teraz wyświetlał okna dialogowe, służące do wybierania

identyfikatorów kolejnych encji. Każda encja zawiera atrybut o nazwie
ENTITY Number, gdzie „ENTITY” jest nazwą encji:

W odpowiedzi na pytanie o identyfikator encji CALL, należy podwójnie

kliknąć na nazwie atrybutu Call Number, a następnie kliknąć przycisk

Continue

Projektowanie baz danych w modelu klient/serwer

187

W odpowiedzi na pytanie o identyfikator encji LEASE należy podwójnie

kliknąć na nazwie atrybutu Lease Number, a następnie kliknąć przycisk

Continue

W odpowiedzi na pytanie o identyfikator encji PROPERTY należy podwójnie

kliknąć na nazwie atrybutu Property Number, a następnie kliknąć przycisk

Continue

W odpowiedzi na pytanie o identyfikator encji TENANT należy podwójnie

kliknąć na nazwie atrybutu Tenant Number, a następnie kliknąć przycisk

Continue

Identyfikatory encji będą teraz podkreślone, co ilustruje rysunek 6.19.

Ostatnie poprawki

Przed przystąpieniem do dalszych czynności wskazane jest dopracowanie
niektórych szczegółów modelu. Pierwsze uzupełnienie będzie polegało na
automatycznym wygenerowaniu czytelnych nazw elementów modelu. Narzędzie
ERX oferuje mechanizm automatycznego generowania nazw, określanych przez
autorów programu jako „nazwy kodowe” (ang. coded names). Są to odpowiednio
skrócone nazwy encji, atrybutów lub innych obiektów. Ograniczenie długości
gwarantuje, że nazwy mogą być bezpiecznie użyte przy implementacji modelu
w docelowym systemie zarządzania bazą danych, tj. nie będą za długie i nie będą
zawierały niedozwolonych znaków. Większość systemów zarządzania bazami
danych nakłada ograniczenia długości nazw elementów. SQL Server dopuszcza

Rysunek 6.19.
Model po
zdefiniowaniu
identyfikatorów
encji.

188

Część I

nazwy o maksymalnej długości 30 znaków; wiele innych platform narzuca
ograniczenie długości nazw do 18 znaków. Encje zdefiniowane w ramach modelu
zostaną przekształcone w tabele nowej bazy danych, dlatego ich nazwy powinny
spełniać warunki nakładane przez docelowy system. ERX zamienia używane
dotąd, czytelne nazwy na odpowiedniki akceptowane przez system bazy danych.
Czasami nie ma potrzeby wprowadzania jakichkolwiek zmian; czasem jednak
konieczna jest radykalna zmiana nazwy.

Aby na podstawie dotychczasowych nazw elementów wygenerować nazwy
kodowe, należy:

1. Wybrać opcję menu

Model\Generate Coded Names

2. Wartości parametrów Maximum length (maksymalna długość) i Nb. of

characters used from the beginning of each word in the name (liczba
wykorzystywanych początkowych znaków każdego słowa) ustalić na 30.
Tworzone encje zostaną przekształcone w tabele systemu InterBase, który
dopuszcza nazwy o długości 30 znaków. Długość taka jest dozwolona we
wszystkich najpopularniejszych systemach zarządzania bazami danych,
z wyjątkiem systemu Oracle. Zmiana długości skracanych wyrazów z 3 do 30
znaków zapobiega przekształcaniu słów w nieczytelne, trzyliterowe skróty.
Zaakceptowanie domyślnej wartości 3 spowodowałoby, że np. nazwa atrybutu
Tenant Number zostałaby zamieniona na Ten_Num - nazwę nieczytelną
i skróconą bardziej niż to było konieczne.

3. Nie zmieniając żadnych innych ustawień w oknie dialogowym kliknąć przycisk

Generate

Aby obejrzeć nowe nazwy kodowe, należy podwójnie kliknąć na wybranej encji
modelu. Dostęp do nazwy kodowej wybranego atrybutu uzyskuje się po
podwójnym kliknięciu pełnej nazwy tego atrybutu w polu dialogowym

Entity

Attributes

. Nowe nazwy kodowe widoczne są na rysunkach 6.20 i 6.21.

Ostatnią czynnością, poprzedzającą przekształcenie modelu E-R w

model

relacyjny, będzie nadanie mu nazwy. Należy wybrać z

menu polecenie

Model\Model Description

i wpisać np.

E-R diagram for Lease Process

(lub po polsku: Diagram E-R opisujący proces wynajmu) w polu

Model Name

Następnie należy usunąć zawartość pola

Coded Name

i kliknąć

. Rysunek 6.22

przedstawia kompletny model związków encji.

Należy teraz zapisać model jako LEASE.ERX, korzystając z opcji menu

File\Save

a następnie wyjść z programu ERX (opcja

File\Exit

190

Część I

Relacyjny model danych

Efektem dotychczasowych działań jest model związków, zachodzących pomiędzy
encjami. Model ten definiuje obiekty i

zależności w

procesie wynajmu

nieruchomości i posłuży za podstawę do stworzenia relacyjnego modelu danych.
Model relacyjny jest - w porównaniu z diagramem E-R - bliższy fizycznej
implementacji bazy danych. Zawiera definicje kluczy głównych, więzów
integralności relacji i innych fizycznych właściwości bazy danych. Do stworzenia
relacyjnego modelu danych wykorzystać można narzędzie Silverrun RDM. To
samo narzędzie posłuży później do wygenerowania skryptu SQL, który stworzy
obiekty bazy danych, będące implementacją zaprojektowanego modelu.

Logiczny model danych - podstawowe pojęcia

Przed rozpoczęciem dalszego omówienia wyjaśnimy wybrane terminy, związane
z relacyjnymi bazami danych i logicznym modelem danych. Najistotniejsze -
zdaniem autora - terminy, zebrano w Tabeli 6.4. Poznanie właściwej terminologii
ułatwi zrozumienie dalszej części dyskusji. Prezentowany tutaj słowniczek
terminów nie jest w pełni wyczerpujący, ale powinien okazać się przydatny
w praktyce.

Rysunek 6.22.
Gotowy model

związków encji (E-R).

Projektowanie baz danych w modelu klient/serwer

191

Tabela 6.4. Najważniejsze pojęcia, dotyczące relacyjnego modelu danych.

Pojęcie Definicja

Baza danych
(database)

Zbiór danych pogrupowanych w tabele. Bazę danych
można przyrównać do regału. Baza danych zawiera
tabele, które z

kolei zawierają właściwe dane.

Podobnie - regał zawiera segregatory, w

których

zawarte są właściwe dokumenty.

Tabela
(table)

Pojedynczy zbiór danych w ramach bazy. Tabelę
w modelu relacyjnym przedstawia się jako płaską
powierzchnię, podzieloną na wiersze i

kolumny.

Rozwijając metaforę regału, tabelę przyrównać można
do segregatora. Tabela składa się z wielu wierszy
o identycznej strukturze. Podobnie segregator może
zawierać dokumenty jednego rodzaju (na przykład
faktury zakupu).

Wiersz
(row)

Odpowiada jednemu obiektowi rzeczywistemu,
takiemu jak faktura, wyciąg lub pozycja w książce
telefonicznej. Wiersze są podstawowymi elementami
bazy danych. Zamiennie z terminem wiersz używa się
często określenia rekord. W polskich opracowaniach,
dotyczących relacyjnych modeli danych, przyjęło się
także określenie krotka. W

niniejszej książce

stosowane będą zamiennie terminy wiersz (ang. row)
i rekord (ang. record). Bazy danych i tabele są -
w

swych najprostszych postaciach - wyłącznie

mechanizmem grupowania wierszy. Ponownie
przywołując przykład regału i segregatorów, wiersz
należałoby przyrównać do pojedynczego dokumentu
w segregatorze.
W segregatorze oznaczonym FAKTURY ZAKUPU,
znajdą się odpowiednie dokumenty - faktury zakupu.
Podobnie tabela FAKTURY_ZAKUPU składać się
będzie z wierszy, z których każdy odpowiada jednej
fakturze.

Kolumna
(column)

Element wiersza. Kolumna opisuje pewną właściwość
obiektu, reprezentowanego przez wiersz tabeli.
Zamiennie z terminem kolumna używa się często
określenia pole. W polskich opracowaniach, dotyczą-
cych relacyjnych modeli danych, przyjęło się także

192

Część I

Pojęcie Definicja

określenie atrybut. W niniejszej książce stosowane
będą zamiennie dwa pierwsze terminy. Przykładem
kolumny może być adres w tabeli klientów. Sam adres
nie niesie jednoznacznej informacji. Natomiast
w kontekście całej tabeli kolumna ta opisuje adres
klienta.

Klucz główny
(primary key)

Kolumna lub zbiór kolumn, jednoznacznie
identyfikujących każdy wiersz. Jako przykład podać
można kolumnę z numerem faktury w tabeli, której
wiersze reprezentują kompletne faktury. Numer każdej
faktury jest unikalny i jednoznacznie ją identyfikuje;
w tabeli nie ma innego rekordu (wiersza) o tym samym
numerze faktury. Wystarczy zapamiętać sam numer,
aby móc w dowolnej chwili za jego pomocą odwołać
się do całego wiersza. Numer pełni zatem rolę klucza.
Na podstawie kolumn, tworzących klucz główny,
buduje się zwykle indeks, przyspieszający dostęp do
wierszy tabeli.

Klucz obcy
(foreign key)

Kolumna lub zbiór kolumn przejętych z innej tabeli.
Klucz obcy jest na ogół kluczem głównym tabeli,
z której pochodzi. Natomiast rzadkością jest sytuacja,
w której klucz obcy jakiejś tabeli jest jednocześnie jej
kluczem głównym. Załóżmy, że w systemie występują
dwie tabele: FAKTURA, której wiersze reprezentują
faktury, i

KLIENT, której wiersze są rekordami

klientów. W

tabeli FAKTURA kluczem obcym

mogłaby być kolumna, zawierająca numer klienta
i pochodząca z tabeli KLIENT. Pole z numerem klienta
nie może być kluczem głównym tabeli FAKTURA,
gdyż nie identyfikuje jednoznacznie faktur. Może
istnieć kilka faktur, wystawionych dla tego samego
klienta. Jednakże numery klientów, pamiętane na
fakturach, muszą być poprawne. Muszą istnieć
unikalne rekordy klientów, opatrzone numerami,
występującymi na fakturach. Kolumna z numerem
klienta w tabeli FAKTURA jest zatem kluczem obcym,
relacyjnie połączonym z

kluczem głównym tabeli

KLIENT.

Klucz potencjalny
(candidate key)

Kolumna lub zbiór kolumn, jednoznacznie identyfiku-
jących każdy wiersz. Klucz główny tabeli wybierany

Projektowanie baz danych w modelu klient/serwer

193

Pojęcie Definicja
(candidate key)

jest spośród jej kluczy potencjalnych.

Złączenie
(join)

Zapytanie SQL, którego zbiór wynikowy zawiera
kolumny, pochodzące z dwóch tabel. Generowaniem
zbioru wynikowego rządzi określone kryterium.
Tabele, będące argumentami złączenia, określa się jako
„lewą” i

”prawą”, zgodnie z

regułami składni

odpowiedniego polecenia SQL. Rozróżnia się dwa
podstawowe rodzaje złączeń: wewnętrzne i zewnętrzne
(występują też inne rodzaje, które nie będą tutaj
wymieniane). Wynikiem złączenia wewnętrznego jest
zbiór, zawierający tylko te wiersze, dla których
spełniony został warunek złączenia. W skład wyniku
złączenia zewnętrznego wchodzą wszystkie wiersze
tabeli zewnętrznej (lewej), niezależnie od tego, czy
spełniają warunek złączenia.

Więzy
(constraint)

Mechanizmy, uniemożliwiające wygenerowanie lub
wprowadzenie błędnych danych do bazy. Wyróżnia się
dwa ogólne typy więzów: więzy integralności relacji
i więzy integralności domeny. Pierwsze z

nich

zapewniają zachowanie poprawnych relacji między
poszczególnymi tabelami. Więzy integralności domeny
uniemożliwiają wprowadzenie do bazy wartości spoza
dozwolonego zakresu lub danych, których typ nie jest
zgodny z domeną odpowiedniej kolumny.

Indeks
(index)

Mechanizm, wspomagający szybkie odnajdowanie
wierszy tabeli. Indeksy umożliwiają uporządkowanie
wierszy według określonego kryterium i zachowanie
tego uporządkowania. Eliminują zatem potrzebę
przeszukiwania kolejno wszystkich wierszy tabeli
w celu odnalezienia żądanej wartości.

Perspektywa
(view)

Logiczna reprezentacja podzbioru danych tabeli. Sama
perspektywa nie jest zbiorem danych, lecz
skompilowanym zapytaniem SQL, do którego można
się odwoływać, tak jak do tabeli. Perspektywa
zapewnia na ogół dostęp do podzbioru kolumn,
wierszy albo zarówno kolumn, jak i wierszy.

Procedura pamiętana
(stored procedure)

Skompilowany fragment programu w języku SQL,
który może być wykonywany jako jedna procedura.
W zależności od stosowanej platformy systemowej,

194

Część I

Pojęcie Definicja

procedury pamiętane mogą zwracać wartości
i

wynikowe zbiory danych, a

także występować

w wyrażeniach.

Procedura zdarzeń
(trigger)

Szczególny rodzaj procedury pamiętanej, która
wywoływana jest automatycznie, jeśli na wskazanej
tabeli wykonane zostanie określone polecenie SQL lub
inna operacja. Procedur zdarzeń można używać w celu
zapewnienia integralności relacji i domen.

Powyższe zestawienie najważniejszych pojęć stanowi dobrą podstawę do dalszej
dyskusji na temat projektowania baz danych. W kolejnych sekcjach opisany
zostanie proces przekształcania sporządzonego wcześniej diagramu E-R
w kompletny model relacyjny. Zastosowane zostanie narzędzie Silverrun ERX.
Ostatecznym wynikiem opisywanego procesu będzie skrypt SQL, który utworzy
właściwe obiekty bazy danych.

Przekształcanie diagramu związków encji w model relacyjny

Przed przystąpieniem do opracowywania relacyjnego modelu danych konieczne
będzie przekształcenie pliku ERX, utworzonego w programie Silverrun-ERX do
formatu rozpoznawanego przez narzędzie RDM. W pakiecie Silverrun dostępny
jest specjalny konwerter - program Silverrun ERX-RDM. Znajduje się on
w folderze programów Silverrun-RDM. Aby przekształcić diagram E-R w plik
modelu relacyjnego należy:

1. Odszukać i uruchomić program ERX-RDM.

2. Nacisnąć kombinację klawiszy ALT-T, co spowoduje wywołanie opcji

przekształcania pliku ERX; następnie wybrać plik LEASE.ERX i kliknąć

W odpowiedzi na pytanie o nazwę wynikowego pliku RDM, kliknąć

, co

spowoduje przyjęcie proponowanej domyślnie nazwy (zob. rysunek 6.23)

Projektowanie baz danych w modelu klient/serwer

195

3. Wyjść z programu Silverrun ERX-RDM.

Rozbudowa nowego modelu relacyjnego

Uzyskany plik RDM, który można otworzyć w programie Silverrun-RDM,
stanowił będzie podstawę ostatecznego relacyjnego modelu danych. Po
uruchomieniu programu Silverrun-RDM należy wywołać polecenie

File\Open

i wybrać utworzony właśnie plik RDM (jeśli program zaproponuje konwersję
modelu ze starszego formatu pliku, należy odpowiedzieć twierdząco -

Yes

Program zapyta teraz o docelowy system zarządzania bazą danych. W pakiecie
Delphi Client/Server dostarczany jest system InterBase, dlatego tworzona baza
danych powinna funkcjonować właśnie na tej platformie. Należy zatem kliknąć
przycisk

Avail. Target Sys

. i wybrać opcję INTBAS41.TYP z odpowiedniej listy,

po czym kliknąć

. Rysunek 6.24 przedstawia prawidłowo przekształcony model

relacyjny.

Tworzenie słownika danych

Pierwszym etapem przygotowania modelu będzie zbudowanie słownika danych
(ang. data dictionary). W programie Silverrun-RDM słownik danych tworzy się na
drodze definiowania domen. Jak już wspomniano, domena określa typ danych,
jakie mogą być przechowywane w kolumnie. Proces tworzenia słownika danych
jest dość prosty, niezależnie od tego, czy realizuje się go przy pomocy narzędzia
typu CASE czy też nie. Aby zbudować słownik danych, należy:

1. Przygotować listę wszystkich kolumn, zawartych w tabelach sporządzanego

modelu. Lista taka nie musi być przygotowywana przy pomocy żadnego
konkretnego narzędzia, jest jednak niezbędna w dalszej części procedury.

Rysunek 6.23.
Narzędzie
Silverrun ERX-
RDM służy do
przekształcania
modeli E-R
w modele
relacyjne.

196

Część I

2. Dla wszystkich kolumn, które występują w więcej niż jednej tabeli, albo

których zawartość podlega specjalnym ograniczeniom, stworzyć definicje
domen. W dalszej części niniejszej sekcji przedstawiona zostanie procedura
definiowania domen w programie Silverrun-RDM.

3. Dla każdej domeny w słowniku danych zdefiniować reguły logiki aplikacji.

Reguły logiki aplikacji, zdefiniowane na poziomie kolumn, określają, jakie
wartości dozwolone są w poszczególnych kolumnach. Reguły takie mogą, na
przykład, mówić, że wartość kolumny Rent musi być niezerowa, a data
w kolumnie EndDate musi być późniejsza niż data w kolumnie BeginDate.
Zadanie definiowania reguł logiki aplikacji także można wykonać w programie
Silverrun.

4. Skojarzyć zdefiniowane domeny z poszczególnymi kolumnami tabel. Niektóre

kolumny będą zdefiniowane w oparciu o domeny, a nie o typy danych,
oferowane przez stosowany system zarządzania bazą danych. Domeny nadają
kolumnom pewne specyficzne własności, np. ograniczenia dozwolonych
wartości danych. Narzędzie RDM umożliwia przypisanie zdefiniowanych
wcześniej domen poszczególnym kolumnom w tabelach modelu relacyjnego.

A oto szczegółowa procedura tworzenia słownika danych w programie Silverrun-
RDM:

1. Wywołać opcję menu

Project\Target Systems

i wybrać InterBase z listy

dostępnych systemów docelowych, po czym kliknąć

Generate

. Spowoduje to

uzupełnienie modelu o typy danych, dopuszczane przez InterBase. Na obecnym
etapie zostaną one dodane do modelu zarówno jako typy bazowe, jak i jako

Rysunek 6.24.
Oryginalny model
relacyjny,
utworzony na bazie
diagramu E-R.

Projektowanie baz danych w modelu klient/serwer

197

domeny. Typów dodanych do modelu można teraz użyć do definiowania
kolumn tabel. Po wyświetleniu informacji o liczbie elementów dodanych do
modelu należy kliknąć

. Ponowne kliknięcie

spowoduje zamknięcie

okna dialogowego

Target Systems

2. Wybrać opcję menu

Project\Domains

. Na ekranie powinna pojawić się lista,

zawierająca wszystkie standardowe typy danych, dostępne w

systemie

InterBase. Właśnie w tym polu dialogowym definiuje się własne domeny. Jak
już wcześniej wspomniano, definicje domen należy stworzyć dla wszystkich
kolumn, które występują w więcej niż jednej tabeli albo których zawartość
może podlegać specjalnym ograniczeniom. Taki sposób postępowania pozwala
zachować spójność modelu i ograniczyć nakład pracy. Aby utworzyć nową
domenę w polu dialogowym

Domains

, należy wykonać następujące czynności:

1. Klikąć przycisk z wielokropkiem, znajdujący się w lewym-dolnym rogu

okna dialogowego. Spowoduje to wyświetlenie listy wszystkich
dostępnych platform systemowych. Należy wybrać InterBase.

2. Wpisać nazwę domeny w polu edycji, bezpośrednio po prawej stronie pola

z numerem wersji systemu.

3. Klikąć przycisk z wielokropkiem, znajdujący się w prawym-dolnym rogu

okna dialogowego. Spowoduje to wyświetlenie listy wszystkich
dostępnych typów, na bazie których można definiować własne domeny.
Z listy należy wybrać żądany typ bazowy.

4. Kliknąć przycisk

Add

w dolnej części okna dialogowego. Na liście

powinna pojawić się nowa domena.

5. Podwójnie kliknąć nazwę domeny na liście, co spowoduje wyświetlenie

okna dialogowego Domain Description, w

którym określić można

indywidualne cechy wybranej domeny. Należą do nich: maksymalna
długość i liczba cyfr po przecinku, wzorzec (maska) edycji\wprowadzania
danych, przykładowo wprowadzona wartość i wartość domyślna. Ponadto
można określić zakres dozwolonych wartości, zdecydować, czy domena
dopuszcza wartości puste (null), czy ma rozróżniać wartości o zapisane
dużymi i

małymi literami, a

także wiele innych atrybutów. Aby

zdefiniować listę dozwolonych wartości, należy kliknąć przycisk

Domain

i wybrać opcję

Values

, a następnie kolejno dodawać dozwolone wartości.

6. Po dodaniu wszystkich domen kliknąć

198

Część I

UWAGA:

W praktyce okazuje się, że szybszym rozwiązaniem jest wprowadzenie najpierw
samych nazw domen, a

następnie wywołanie okna dialogowego Domain

Description pierwszej domeny i określenie jej atrybutów. Atrybuty kolejnych
domen można wówczas wpisywać w tym samym oknie dialogowym, bez ciągłego
otwierania i zamykania okien.

W tabeli 6.5 zebrano wszystkie domeny, które będą potrzebne w przykładowym
modelu. Należy je wszystkie zdefiniować, korzystając z opisanej powyżej
procedury.

Tabela 6.5 Domeny potrzebne w przykładowym modelu

Nazwa Typ

bazowy

Długość Liczba miejsc

po przecinku

Wartość
domyślna

Wartości

TAddition Character

20 N/D 'Sherwood'

'Sherwood',
'Deerfield',
'Switzerland
Estates',
'Firewheel', 'Legacy
Hills', 'RockKnoll'

TAddress Character

30 N/D

Brak Brak

TCity Character

N/D

'Oklahoma
City'

'Oklahoma City',
'Norman',
'Edmond', 'Dallas',
'Plano', 'Richardson'

TComments VarChar 80

N/D Brak Brak

TPhone Character

13 N/D

Brak

TPropertyNo Integer N/D

N/D Brak

Brak

TRent Numeric

5 2

750

Brak

TRooms Integer

N/D N/D

Brak

0,1,2,3,4,5

TSchoolDistrict Character

N/D

'Putnam
City'

'Putnam City',
'Oklahoma City',
'Edmond', 'Dallas;',
'Richardson',
'Garland', 'Plano'

TState Character

2 N/D

'OK'

'OK',

'TX'

TTenantNo Integer N/D N/D Brak Brak

TYesNo Character

N/D

Brak

'Y', 'N', 'T', 'F'

Projektowanie baz danych w modelu klient/serwer

199

Nazwa Typ

bazowy

Długość Liczba miejsc

po przecinku

Wartość
domyślna

Wartości

TZip Character

10 N/D

'73132' Brak

UWAGA:

Tworząc domenę TComments należy koniecznie uaktywnić opcję Null Value
Possible (dozwolona wartość pusta). Dzięki temu kolumny, należące do tej
domeny, nie będą musiały zawierać wartości. Kolumny, zawierające komentarze,
powinny być zawsze opcjonalne.

Definiując kolejne domeny, należy w oknie dialogowym

Domain Description

każdorazowo uaktywnić opcję

Uniformly Used

. Spowoduje to, że atrybuty domeny

będą traktowane nadrzędnie w stosunku do atrybutów kolumny, z którą ta domena
jest skojarzona. Nie będzie można wówczas zmodyfikować właściwości kolumn -
konieczna będzie ingerencja w definicję odpowiedniej domeny. W przypadku
omawianego przykładu jest to korzystne rozwiązanie, pomagające w zachowaniu
spójności projektu. Jednak w wielu przypadkach opcja

Uniformly Used

zanadto

ogranicza elastyczność modelu. Uniemożliwia, na przykład, określenie, czy dana
kolumna dopuszcza wartości puste, niezależnie od odpowiedniej właściwości
domeny.

Należy także zwrócić uwagę na przestrzeganie konwencji nazewnictwa,
omówionych w rozdziale 4. Nazwa każdej domeny rozpoczyna się od litery T.
Konwencja ta jest zgodna ze stosowaną przez autorów biblioteki Visual
Component Library przy nazewnictwie typów danych. Domeny są bliskimi
odpowiednikami definicji typów w języku Object Pascal, dlatego celowe jest
zachowanie zgodności z zasadami nazewnictwa typów w bibliotece VCL.

200

Część I

Korzystanie ze słownika danych

Po przygotowaniu zestawu domen przychodzi pora na skojarzenie ich
z poszczególnymi kolumnami w tabelach. Tym kolumnom, które nie są oparte
bezpośrednio na domenach, należy przypisać bezpośrednio typy bazowe. Aby
zdefiniować typy kolumn w

programie Silverrun-RDM, należy wykonać

następujące czynności:

1. Podwójnie kliknąć na reprezentacji tabeli w modelu. Na ekranie powinno

pojawić się okno dialogowe

Table Columns

2. Podwójnie kliknąć na każdej z

kolumn. Przypisać kolejno wszystkim

kolumnom domeny i typy bazowe podane w Tabeli 6.6. Ponadto należy usunąć
nazwy encji z

nazw kodowych kolumn. Nazwy kodowe powinny być

identyczne z podanymi w Tabeli 6.6.

3. Powtórzyć powyższy proces dla wszystkich tabel w modelu.

Tabela 6.6

Nazwa kodowa Domena

Długość Liczba

miejsc po
przecinku

Dozwolone

puste?

opis**

Addition TAddition

N Dzielnica

Address TAddress

N Adres

BathRooms TRooms

Łazienki

Rysunek 6.25.
Dla samodzielnie
zdefiniowanych
domen można
definiować zbiory
dopuszczalnych
wartości.

Projektowanie baz danych w modelu klient/serwer

201

Nazwa kodowa Domena

Długość Liczba

miejsc po
przecinku

Dozwolone

puste?

opis**

BedRooms TRooms

Sypialnie

BeginDate DATE

Data
rozpoczęcia
wyn.

CallDate DATE N Data

zgłoszenia

Call_Number INTEGER

Nr
zgłoszenia

CallTime

CHARACTER

Godzina
zgłoszenia

CentralAir TYesNo

Klimatyzacj
a

CentralHeat TYesNo

City TCity

Miasto

Comments TComments

Komentarz

Deposit TRent

N Depozyt

Description CHARACTER

Opis

Dish Washer

TYesNo

Zmywarka
do naczyń

Employer CHARACTER

N Pracodawca

EmployerAddress TAddress

Adres
pracodawcy

EmployerCity TCity

Miasto
pracodawcy

EmployerState TState

Stan
pracodawcy

EmployerZip TZip

Kod
pocztowy
pracodawcy

EndDate DATE N Data

zakończenia
wyn.

GarageType TRooms

Typ

garażu

202

Część I

Nazwa kodowa Domena

Długość Liczba

miejsc po
przecinku

Dozwolone

puste?

opis**

GasHeat TYesNo

N Ogrzewanie

gazowe

HomePhone TPhone

Telefon
domowy

ICEPhone TPhone

N Telefon

komórkowy

LasLawnDate DATE

Ostatnie
koszenie
trawnika

LastSprayDate DATE

Ostatnie

opryskiwanie

LawnService TYesNo

Usługa
koszenia

Lease_Number INTEGER

umowy

najmu

LivingAreas TRooms

Pokoje
dzienne

MovedInDate DATE

Data

objęcia

lokalu

MovedOutDate DATE

Data
opuszczenia
lokalu

Name CHARACTER

Nazwisko

PerDeposit TRent

Depozyt

PrivacyFence TYesNo

Płot

Property_Number TPropertyNo

Nr
nieruchomo-
ści

Range TYesNo

N Zakres

Refrigerator TYesNo

Lodówka

Rent TRent

Czynsz

RentDueDay SMALLINT

Dzień
płatności
czynszu

Projektowanie baz danych w modelu klient/serwer

203

Nazwa kodowa Domena

Długość Liczba

miejsc po
przecinku

Dozwolone

puste?

opis**

SchoolDistrict TSchoolDistri

N Okręg

szkolny

State TState

Stan

Tenant_Number TTenantNo

najemcy

WorkPhone TPhone

Telefon
służbowy

Zip TZip

Kod
pocztowy

*Z wyjątkiem tabeli CALL

** opis dodany w trakcie tłumaczenia w celu zwiększenia czytelności nazewnictwa (przyp.
tłum.)

Określenie rozmiarów kolumn

Definiując kolumny należy zawsze mieć na względzie wydajność systemu do
obsługi bazy danych. Każdorazowo konieczne jest znalezienie jak najmniejszego
typu danych, który pozwoli na przechowywanie największej spośród wartości,
które mogą wystąpić w definiowanej kolumnie. Oto kilka ogólnych wskazówek
przydatnych przy określaniu rozmiarów kolumn:

Jeśli w danym polu nigdy nie wystąpią wartości liczbowe większe niż 255, to

należy wybrać 8-bitowy typ danych (o ile stosowany system obsługi bazy
danych dopuszcza kolumny o rozmiarze jednego bajtu).

Dla kolumn liczbowych, w których nie będą przechowane części ułamkowe,

należy wybierać typy danych całkowitych, a nie zmiennopozycyjnych.

Jeśli długości łańcuchów znaków w poszczególnych wierszach mogą się

znacząco różnić, należy stosować typy znakowe o zmiennej długości w miejsce
typów o ustalonej długości.

Jeżeli stosowana platforma systemowa dopuszcza użycie typów danych

bitowych (przykładem takiej platformy jest SQL Server), to kolumny,
przechowujące wartości logiczne (boolean), należy definiować przy użyciu
typów bitowych, a nie całkowitych lub znakowych.

Generowanie nazw kodowych

Nie jest konieczne generowanie nazw kodowych dla tabel i kolumn, gdyż
analogiczny proces przeprowadzono już w fazie sporządzania modelu E-R.

204

Część I

Niezależnie od tego ponowne generowanie nazw kodowych byłoby niepożądane,
gdyż automatycznie nadane nazwy kolumn zostały w

międzyczasie

zmodyfikowane. Nowe nazwy kodowe zastąpiłyby poprawione, skrócone nazwy.

W odróżnieniu od tabel i kolumn, zdefiniowanym wcześniej, domenom nie nadano
jeszcze automatycznie nazw kodowych. Nazwy kodowe elementów modelu
używane będą w przyszłości do wygenerowania skryptu poleceń DDL, który
utworzy odpowiednie obiekty bazy danych. Dlatego również domeny powinny
mieć nadane własne nazwy kodowe. Aby wygenerować nazwy kodowe domen,
należy:

1. Wybrać opcję menu

Project\Generate Coded Names

2. W polach

Maximum Length

(maksymalna długość) i

Nb. of characters used

from the beginning of each word of the name

(liczba początkowych znaków

każdego słowa w nazwie) wpisać wartość 30.

3. Upewnić się, czy aktywna jest opcja

Partial

, a nie

Complete

4. Kliknąć przycisk

Generate

OSTRZEŻENIE:

W oknie dialogowym

Coded Names Generation

nie należy uaktywniać opcji

Complete

. Spowodowałoby to zastąpienie nowymi wszystkich skróconych nazw

kolumn, zdefiniowanych wcześniej w modelu. Jeśli aktywna jest opcja

Complete

program generuje nowe nazwy kodowe dla wszystkich elementów modelu,
również tych, które już mają nadane nazwy. Natomiast przy aktywnej opcji

Partial

nowe nazwy kodowe otrzymują tylko te elementy, które nie mają zdefiniowanej
nazwy.

Opis projektu

Opatrywanie elementów modelu odpowiednimi komentarzami okazuje się
w praktyce bardzo użyteczne. Niektóre narzędzia, wspomagające modelowanie,
nie oferują jednak żadnych mechanizmów, służących do opisywania projektu.
Silverrun-RDM umożliwia natomiast opatrywanie komentarzami dowolnie
wybranych elementów modelu. Jeśli docelowa platforma systemowa dopuszcza
użycie tego rodzaju komentarzy, to opisy obiektów umieszczane są w skrypcie
SQL, generowanym automatycznie przez program RDM. Przykładem takiej
platformy jest system Oracle. Aby w programie RDM przypisać komentarze
poszczególnym tabelom, należy:

1. Podwójnie kliknąć na nagłówku obiektu, reprezentującego tabelę. Na ekranie

pojawi się okno dialogowe

Table Description

(opis tabeli).

Projektowanie baz danych w modelu klient/serwer

205

2. Kliknąć przycisk

Table

i wybrać opcję

Comment

z rozwijanej listy. Na ekranie

wyświetlone zostanie okno, przeznaczone do wprowadzania opisu tabeli.

3. Wpisać komentarz i kliknąć

(zob. rysunek 6.26)

Aby opatrzyć komentarzem wybraną kolumnę tabeli, należy:

1. Podwójnie kliknąć na zasadniczej części obiektu, reprezentującego tabelę. Na

ekranie pojawi się okno dialogowe

Table Columns

z kolumnami tabeli.

2. Podwójnie kliknąć na nazwie kolumny, która ma być opatrzona komentarzem.

Spowoduje to wyświetlenie okna dialogowego

Column Description

(opis

kolumn).

3. Kliknąć przycisk

Column

i wybrać opcję

Comment

z rozwijanej listy. Na

ekranie wyświetlone zostanie okno, przeznaczone do wprowadzania opisu
kolumny.

4. Wpisać komentarz i kliknąć

(zob. rysunek 6.27)

Komentarze, opisujące poszczególne elementy modelu, ułatwiają zrozumienie
struktury budowanego modelu. W przypadku projektów, w które zaangażowanych
jest wielu programistów, komentarz informuje o intencjach autora danego obiektu.

Generowanie kluczy obcych

Ostatnim etapem przygotowywania modelu jest wygenerowanie specyfikacji
kluczy obcych. Klucze obce stanowią fizyczną implementację związków encji,

Rysunek 6.26.
Tabele, należące
do modelu, można
opatrywać
komentarzami.

206

Część I

zbudowanych w ramach modelu E-R. W procesie generowania kluczy obcych
odpowiednie kolumny pojawiają się w

tabelach różnych od tej, w

której

pierwotnie się znajdowały. Z reguły jedna tabela przyjmuje (dziedziczy) klucz
główny innej tabeli. Odziedziczona kolumna lub zbiór kolumn staje się kluczem
obcym tabeli, która go przyjęła.

Aby w programie RDM wygenerować klucze obce, należy:

1. Wybrać opcję menu

Schema\Foreign Keys\Generate

2. Kliknąć przycisk

Generate

w oknie dialogowym, które pojawi się na ekranie.

3. Kliknąć przycisk

Save

i tym samym zaakceptować proponowaną domyślną

nazwę pliku, w którym zapisany będzie raport dotyczący kluczy obcych.

W obiektach, reprezentujących tabele, powinny pojawić się nowe kolumny. Nazwa
każdej z nich powinna być poprzedzona skrótem FK (od ang. foreign key, klucz
obcy) - zob. rysunek 6.28.

Relacyjny model danych jest już prawie gotowy i prawdopodobnie nadaje się do
wygenerowania na jego podstawie skryptu SQL, który utworzy odpowiednie
obiekty bazy danych.

Rysunek 6.27.
Komentarzami
można również
opatrywać
poszczególne
kolumny.

Projektowanie baz danych w modelu klient/serwer

207

UWAGA:

Bardzo atrakcyjną właściwością programu Silverrun RDM jest możliwość
stosowania wielu różnych notacji do opisu modelu relacyjnego. Program
dopuszcza stosowanie popularnych systemów zapisu Information Engineering
i Information Engineering+, a także notacji Logical Data Structure. Oferuje także
własną notację Datarun, którą wielu użytkowników uzna za wygodniejszą od
wymienionych wyżej standardów. Istnieje również możliwość zdefiniowania
własnego systemu zapisu, a w szczególności określenie sposobu rysowania
połączeń i nadawania nazw elementom modelu. Aby zmodyfikować jeden ze
standardowych sposobów zapisu, dostępnych w programie Silverrun, należy
wybrać opcję

Presentation

(prezentacja) z menu

Notation

(notacja).

Weryfikacja spójności modelu

Przed wygenerowaniem ciągu poleceń SQL, które stworzą odpowiednie obiekty
bazy danych, należy zweryfikować spójność sporządzonego modelu. Program
Silverrun-RDM oferuje wygodne narzędzie, dokonujące takiej weryfikacji. Aby
z niego skorzystać, należy wykonać następujące czynności:

1. Wybrać opcję menu

Schema\Verify Integrity

2. Program zaproponuje teraz domyślną nazwę raportu - Verify. Należy ją

zaakceptować klikając przycisk

Save

Rysunek 6.28.
Gotowy logiczny
model danych.

208

Część I

3. Na ekranie powinien pojawić się komunikat informujący, że w modelu nie

wykryto błędów. Program może zgłaszać ostrzeżenia (ang. warnings),
w modelu nie powinny jednak wystąpić żadne poważne błędy.

4. Wybrać opcję menu

Util.\View a

Text File

, po czym podać nazwę

weryfikowanego raportu (domyślnie przyjmowana jest nazwa Verify) i kliknąć
przycisk

Open

, co umożliwi zapoznanie się z raportem na ekranie.

Weryfikacja spójności modelu, przeprowadzona przed wygenerowaniem skryptu
SQL, pozwala uniknąć usuwania i ponownego tworzenia błędnie zdefiniowanych
obiektów bazy danych. Silverrun kontroluje różnorodne aspekty modelu i pozwala
z dużym prawdopodobieństwem określić, czy może on już posłużyć jako podstawa
do wygenerowania skryptu SQL.

Generowanie poleceń DDL

Polecenia SQL, służące do tworzenia lub definiowania obiektów, określane są
mianem poleceń DDL (ang. Data Definition Language, język definicji danych). Po
zakończeniu prac nad modelem przychodzi pora na jego fizyczną implementację.
Aby wygenerować skrypt SQL, który na podstawie modelu utworzy odpowiednie
obiekty, należy:

1. Wybrać opcję menu

Schema\Generate DDL

2. W oknie dialogowym, które pojawi się na ekranie, uaktywnić przycisk opcji

Coded Name

3. Kliknąć przycisk

Generate

4. Program spyta teraz o

nazwę pliku. Należy podać nazwę, opisującą

podstawową funkcję modelu, uzupełnioną rozszerzeniem SQL. Dla przykładu,
omawianego w tym rozdziale, odpowiednią nazwą będzie LAEASE.SQL.

Listing 6.1 przedstawia zawartość skryptu SQL, który powinien zostać
automatycznie wygenerowany. Polecenia DDL, wygenerowane przez Silverrun, są
zgodne z dialektem InterBase SQL, gdyż rozpoczynając pracę nad modelem
zadeklarowano użycie właśnie systemu InterBase.

Listing 6.1.Skrypt LEASE.SQL wygenerowany przez program
Silverrun-RDM.

CONNECT „E_R_Diagram_for_Lease_Process” USER „ „ PASSWORD „ „;

CREATE DOMAIN TAddition AS CHARACTER(20) NOT NULL CHECK
(VALUE IN ('Deerfield', 'Firewheel', 'Legacy Hills',

➥

'Switzerland Estates', 'Sherwood', 'Rockknoll'));

CREATE DOMAIN TAddress AS CHARACTER(30) NOT NULL;

CREATE DOMAIN TCity AS CHARACTER(30) NOT NULL CHECK

Projektowanie baz danych w modelu klient/serwer

209

(VALUE IN ('Oklahoma City', 'Norman', 'Edmond', 'Dallas',

➥

'Richardson', 'Plano'));

CREATE DOMAIN TComments AS VARCHAR(80);

CREATE DOMAIN TPhone AS CHARACTER(13) NOT NULL;

CREATE DOMAIN TPropertyNo AS INTEGER NOT NULL;

CREATE DOMAIN TRent AS NUMERIC(5, 2) NOT NULL;

CREATE DOMAIN TRooms AS INTEGER NOT NULL CHECK
(VALUE IN (0, 1, 2, 3, 4, 5));

CREATE DOMAIN TSchoolDistrict AS CHARACTER(20) NOT NULL CHECK
(VALUE IN (‘Putnam City’, ‘Oklahoma City’, ‘Richardson’,

➥

‘Edmond’, ‘Garland’, ‘Dallas’, ‘Plano’));

CREATE DOMAIN TState AS CHARACTER(2) NOT NULL CHECK
(VALUE IN (‘OK’, ‘TX’));

CREATE DOMAIN TTenantNo AS INTEGER NOT NULL;

CREATE DOMAIN TYesNo AS CHAR(1) NOT NULL CHECK
(VALUE IN (‘Y’, ‘N’, T’,F’));

CREATE DOMAIN TZip AS CHARACTER(10) NOT NULL;

CREATE TABLE PROPERTY
(....Property_Number

TPropertyNo NOT NULL,

.....Address

TAddress NOT NULL,

.....City

TCity NOT NULL,

.....State

TState NOT NULL,

.....Zip

TZip NOT NULL,

.....Addition

TAddition NOT NULL,

.....SchoolDistrict

TSchoolDistrict NOT NULL,

.....Rent

TRent NOT NULL,

.....Deposit

TRent NOT NULL,

.....LivingAreas

TRooms NOT NULL,

.....BedRooms

TRooms NOT NULL,

.....BathRooms

TRooms NOT NULL,

.....GarageType

TRooms NOT NULL,

.....CentralAir

TYesNo NOT NULL,

.....CentralHeat

TYesNo NOT NULL,

.....GasHeat

TYesNo NOT NULL,

.....Refigerator

TYesNo NOT NULL,

.....Range

TYesNo NOT NULL,

.....DishWasher

TYesNo NOT NULL,

.....PrivacyFence

TYesNo NOT NULL,

.....LastLawnDate

DATE NOT NULL,

210

Część I

.....LastSprayDate

DATE NOT NULL,

PRIMARY KEY (Property_Number)
);

CREATE TABLE TENANT
( Tenant_Number

TTenantNo NOT NULL,

Name

CHARACTER(30) NOT NULL,

Employer

CHARACTER(30) NOT NULL,

EmployerAddress

TAddress NOT NULL,

EmployerCity

TCity NOT NULL,

EmployerState

TState NOT NULL,

EmployerZip

TZip NOT NULL,

HomePhone

TPhone NOT NULL,

WorkPhone

TPhone NOT NULL,

ICEPhone

TPhone NOT NULL,

Comments

TComments,

PRIMARY KEY (Tenant_Number)
);

CREATE TABLE CALL
( Call_Number

INTEGER NOT NULL,

Call_Date

DATE NOT NULL,

CallTime

CHARACTER(11),

Description

CHARACTER(30) NOT NULL,

Property_Number

TPropertyNo,

PRIMARY KEY (Call_Number),
CONSTRAINT FK_PROPERTY1
FOREIGN KEY (Property_Number)
REFERENCES PROPERTY
);

CREATE TABLE LEASE
( Lease_Number

INTEGER NOT NULL,

BeginDate

DATE NOT NULL,

EndDate

DATE NOT NULL,

MovedInDate

DATE NOT NULL,

MovedOutDate

DATE NOT NULL,

Rent

TRent NOT NULL,

Deposit

TRent NOT NULL,

PetDeposit

TRent NOT NULL,

RentDueDay

SMALLINT NOT NULL,

LawnService

TYesNo NOT NULL,

Comments

TComments,

Property_Number

TPropertyNo NOT NULL,

Tenant_Number

TTenantNo NOT NULL,

PRIMARY KEY (Lease_Number),
CONSTRAINT FK_PROPERTY2
FOREIGN KEY (Property_Number)
REFERENCES PROPERTY,
CONSTRAINT FK_TENANT3
FOREIGN KEY (Tenant_Number)
REFERENCES TENANT
);

Projektowanie baz danych w modelu klient/serwer

211

UWAGA:

Kolejność kolumn w tabeli PROPERTY została nieco zmodyfikowana i jest teraz
bardziej logiczna. Encja

PROPERTY

tworzona była automatycznie przez eksperta

normalizacji ERX - stąd przypadkowa kolejność kolumn. Narzucenie kolejności
kolumn zgodnej z naturalnym tokiem myślenia i skojarzeń ułatwia obsługę tabeli
i tworzenie aplikacji, operujących na niej.

Skrypt rozpoczynają polecenia, tworzące obiekty domen Interbase. Odpowiadają
one logicznym domenom, zdefiniowanym dla modelu. Utworzone domeny
wykorzystywane są następnie w definicjach tabel bazy danych. Jest to bardzo
korzystne rozwiązanie. Reguły logiki aplikacji ujęte są w definicjach domen,
z których można dowolnie korzystać w przyszłości, np. przy tworzeniu nowych
kolumn. Gdyby na przykład zaszła potrzeba dodania kolumny, zawierającej
wartości typu

Yes/No (Tak/Nie),

możliwe będzie ponowne użycie domeny

TYesNo. Możliwość taka istnieje dzięki ujęciu reguł logiki aplikacji w domenach,
a nie wprost w definicjach kolumn.

W wygenerowanym skrypcie zauważyć można jedną usterkę: pierwsze, dziwne
polecenie

CONNECT

, które prawdopodobnie nie uaktywni bazy danych na

serwerze InterBase. W charakterze nazwy bazy danych użyto nazwy modelu.
Jednym z rozwiązań tego problemu byłaby zmiana nazwy modelu, tak aby mogła
być użyta również jako poprawna nazwa bazy danych InterBase. Istnieje jednak
lepszy sposób.

Model został utworzony w wyniku odpowiedniego przekształcenia diagramu E-R,
dlatego zachował tytuł, pochodzący z modułu ERX. Zmienimy teraz ten tytuł, tak
aby lepiej opisywał gotowy, relacyjny model danych. W tym celu należy wybrać
opcję menu

Schema\Schema Description

i zmienić zawartość pola Local Name

(Nazwa lokalna), wpisując w nim: Relacyjny model danych dla procesu wynajmu
(Lease). Następnie w polu Coded Name (Nazwa kodowa) należy wpisać poprawną
nazwę bazy danych InterBase, np.

C:\DATA\RENTMAN\RENTMAN.GDB

; we

wskazanej bazie danych przechowywane będą obiekty, utworzone przez skrypt
DDL. Na rysunku 6.29 przedstawiono okno dialogowe Schema Description (Opis
diagramu).

212

Część I

UWAGA:

Należy pamiętać o zapisaniu utworzonego modelu, gdyż będzie on ponownie
wykorzystywany w dalszej części książki, w sekcji „Samouczek”. Autor zapisał
swój projekt jako LEASE.RDM.

Po zmianie nazwy, której program RDM użyje przy generowaniu poleceń DDL,
należy zlecić ponowne utworzenie całego skryptu LEASE.SQL. Ponownie posłuży
do tego polecenie

Schema\Generate DDL

. Należy pamiętać o uaktywnieniu opcji

Coded Names

. Polecenie

CONNECT

w nowym pliku przyjmie postać zbliżoną do

poniższej:

CONNECT „C:\DATA\RENTMAN\RENTMAN.GDB” USER „ „ PASSWORD „ „;

Plik ze skryptem można zmodyfikować, uzupełniając polecenie

CONNECT

odpowiednim hasłem i identyfikatorem użytkownika. Oto przykład, w którym
użyto identyfikatora użytkownika SYSDBA i jego domyślnego hasła:

CONNECT „C:\DATA\RENTMAN\RENTMAN.GDB” USER „SYSDBA” PASSWORD

➥

„masterkey”;

Skrypty SQL można z powodzeniem edytować w środowisku Delphi. Środowisko
to oferuje kilka udogodnień, stworzonych specjalnie z myślą o pracy nad
skryptami, np. wyróżnianie elementów składni SQL i dostęp do baz danych oraz
ich zawartości za pośrednictwem narzędzia Database Explorer. Na rysunku 6.30

Rysunek 6.29.
Nazwę modelu
określa się w oknie
dialogowym
Schema
Description.

Projektowanie baz danych w modelu klient/serwer

213

widoczny jest skrypt LEASE.SQL załadowany do edytora tekstu źródłowego
Delphi.

WSKAZÓWKA:

Do najlepszych dostępnych obecnie edytorów tekstów należy Multi-Edit for
Windows. Jego możliwości zaspokoją niemal wszystkie potrzeby zaawansowanego
programisty. Wśród najistotniejszych funkcji wymienić należy wyszukiwanie
w oparciu o wyrażenia, filtry tekstu, wyróżnianie elementów składni, możliwość
edycji bardzo dużych plików i

integrację z

językami programowania/

kompilatorami (lista języków obejmuje C, HTML, Pascal, BASIC i inne). Multi-
Edit, dzięki doskonałej integracji z Delphi, może w zasadzie zastąpić wbudowany
edytor środowiska programowania i zapewnić pełną synchronizację obu narzędzi.

Multi-Edit może także z powodzeniem zastąpić edytor Delphi przy pisaniu
i modyfikacji skryptów SQL. Mechanizmy konfiguracyjne umożliwiają integrację
edytora Multi-Edit z najczęściej używanymi narzędziami do wprowadzania
poleceń SQL (takimi jak ISQL, WISQL, SQL*Plus, itp.). W ten sposób skrypty
SQL mogą być uruchamiane wprost z edytora, od razu można też uzyskać dostęp
do fragmentów skryptu, zawierających błędy.

Producentem programu Multi-Edit jest firma American Cybernetics (telefon
w USA: 602-968-1945).

Rysunek 6.30.
Do edycji skryptów
SQL można
wykorzystać edytor
tekstu źródłowego
Delphi.

214

Część I

UWAGA:

Program Silverrun RDM może automatycznie przygotowywać zbiory atrybutów
Delphi na podstawie modelu relacyjnego. Tak utworzone zbiory atrybutów można
wykorzystywać w aplikacjach. Szczegółowe omówienie tego zagadnienia znaleźć
można w sekcji „Samouczek, którą otwiera rozdział 8.

Uruchamianie skryptu DDL

Wygenerowanie poprawnego skryptu jest ostatnim etapem przygotowywania
fizycznego projektu. Można teraz uruchomić skrypt w celu utworzenia bazy
danych. Nie jest to oczywiście konieczne na obecnym etapie pracy nad aplikacją,
jednak fizycznie istniejąca baza danych będzie namacalnym dowodem powodzenia
dotychczasowych, żmudnych działań. Aby utworzyć bazę danych RENTMAN
należy uruchomić program Interbase WISQL i wybrać opcję Run an ISQL Script
z menu File. Następnie należy otworzyć przygotowany skrypt SQL. Efektem jego
wykonania będzie utworzenie bazy danych RENTMAN.

UWAGA:

W momencie uruchamiania skryptu musi działać serwer InterBase. Jeśli nie został
on jeszcze uruchomiony, należy wybrać opcję InterBase Server 4.2
z odpowiedniego folderu (oczywiście serwer InterBase musi być zainstalowany
w systemie).