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 odpowiedz
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 znalez
ć 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óz
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.
Rysunek 6.1.
Model ilustrujący
różnorodne
elementy pięciu
etapów tworzenia
aplikacji
Przejścia pomiędzy kolejnymi etapami od modelowania procesów po logiczny
model danych można częściowo zautomatyzować przy pomocy narzędzi typu
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 wyraz
nym
sygnałem, że należy powrócić do z
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.
Rysunek 6.2.
Narzędzia typu
CASE pomagają
przekształcić
koncepcje
w fizyczne obiekty
baz danych
i aplikacji
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ż
 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 Osoba, jednostka organizacyjna lub inny obiekt,
(external entity) znajdujący się poza opisywaną instytucją lub
aplikacją, ale współpracujący z nią. Obiekty
zewnętrzne są w modelowanym systemie z
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 Szczegółowa informacja o danych, zawartych
structure) w 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.
wszystkich programach Silverrun układ menu jest podobny. Menu
We
Presentation zawiera opcje, które zazwyczaj umieszczane są w menu
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.
ułatwić sobie rozmieszczanie elementów można skorzystać z siatki
Aby
ekranowej. Należy w tym celu wybrać opcję Presentation\Grid i uaktywnić
przyciski opcji Grid Shown i Grid Active. Po wybraniu gęstości siatki w osiach
X i Y należy kliknąć OK. 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:
wymaga przynajmniej jednego obiektu zewnętrznego - potencjalnego
Model
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.
do przepływu danych między powyższymi elementami, przyjąć można
Co
następujące założenia:
f& Potencjalni najemcy nawiązują kontakt z pracownikiem firmy
wynajmującej i uzyskują informacje o dostępnych nieruchomościach lub
zawierają umowę najmu.
f& Pracownik rejestruje każdy odebrany telefon, niezależnie od tego, czy
w jego wyniku zawierana jest umowa najmu.
f& Po zweryfikowaniu, umowa najmu trafia do innego pracownika,
odpowiedzialnego za jej wykonanie.
f& Informacje o najemcy, uzyskane podczas zawierania umowy są
rejestrowane.
f& 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.
Rysunek 6.4.
Nowy model
z naniesionym
pierwszym
obiektem
zewnętrznym.
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.
 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 z
ródłowy, a następnie docelowy
(operację łączenia można przerwać klawiszem ESC). Program Silverrun-BPM
poprowadzi linię pomiędzy obiektem z
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 odpowiedz
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.
 Projektowanie baz danych w modelu klient/serwer 161
Rysunek 6.7.
Obiekty typu Flow
pozwalają na
określenie
związków między
poszczególnymi
elementami
modelu.
Wszelkie pozostałe połączenia reprezentują wymianę danych ze zbiorami. Należy
je wprowadzić do modelu, korzystając ze wzoru przedstawionego na rysunku 6.8.
Rysunek 6.8.
Model procesu
wynajmowania
nieruchomości
nowemu najemcy.
Dodawanie struktur danych
Opisane do tej pory czynności doprowadziły do powstania modelu procesu
wynajmowania nieruchomości nowemu najemcy. Kolejny etap pracy stanowi
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 z
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óz
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.
 Projektowanie baz danych w modelu klient/serwer 163
Rysunek 6.9.
Dodawanie
struktur danych
przy pomocy okna
dialogowego Data
Structures.
Rysunek 6.10.
Okno dialogowe
Data Structures
Compositions
umożliwia
dodawanie
elementów do
struktur danych.
Dla każdej ze struktur danych, zdefiniowanych wcześniej, określimy teraz zbiór
atrybutów. Do struktury danych CALL należy dodać następujące elementy*:
Call Number
CallDate
CallTime
Property Number
Call Description
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
znalez
ć 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óz
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.
Rysunek 6.11.
Paleta struktur
danych umożliwia
kojarzenie struktur
danych ze zbiorami
(obiektami typu
Store).
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.
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.
Rysunek 6.12.
Diagram E-R,
sporządzony wg
oryginalnej metody
Chena.
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
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.
Rysunek 6.13.
Bardziej
szczegółowy
diagram E-R,
odbiegający od
klasycznego stylu
diagramów Chena.
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
 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 Rzeczywisty typ obiektu - osoba, miejsce, zdarzenie
(ang. entity) lub przedmiot - którego dane są przechowywane
w systemie. Encje nazywane bywają też klasami encji.
Wystąpienie encji Konkretna jednostka, należąca do klasy encji. Na
(ang. etity instance) przykład, klient Jan Kowalski byłby wystąpieniem
encji KLIENT. KLIENT jest w tym przypadku klasą
encji.
Model związków encji Logiczny model danych, oparty na założeniu, że
(ang. entity-relationship wszystkie elementy modelowanego środowiska dają
model, E-R model) 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 Klasa encji, będąca podzbiorem większego, szerzej
(ang. subtype) zdefiniowanego typu encji, nazywanego nadklasą. Na
przykład, klasa encji PIA
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. PIA
KARZ, KOSZYKARZ,
SIATKARZ) nazywane są po angielsku subtype clusters.
Nadklasa/generalizacja Klasa encji, będąca nadzbiorem bardziej zawężonych
(ang. Supertype) typów encji, nazywanych podklasami. Na przykład,
klasa encji SAMOCHÓD mogłaby stanowić
generalizację podzbiorów encji FIAT, OPEL
i 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 Typ danych lub zakres wartości, dozwolony dla danego
(ang. domain) 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 Reguły decydujące o dozwolonych dla danej domeny
(ang. domain integrity) 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 Połączenie dwóch encji, określające zachowanie jednej
(ang. relationship) 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 Reguły zapewniające zachowanie związków między
(ang. relational encjami. Na przykład, integralność związków
integrity) uniemożliwia usunięcie tych wystąpień encji KLIENT,
z którymi skojarzone są wystąpienia encji FAKTURA.
Asocjacja Sposób skojarzenia wystąpień encji w ramach związku.
(ang. Connectivity) 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ść Liczba wystąpień encji skojarzonych w ramach
(ang. cardinality) 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ść Określa, czy istnienie wystąpienia encji jest w danym
(ang. modality) związku opcjonalne czy wymagane. Jako parametr
liczbowy - minimalna liczność związku encji.
Normalizacja Usuwanie nadmiarowych, niespójnych i uwikłanych
(ang. normalization) elementów modelu danych. Celem normalizacji jest
uzyskanie modelu, którego każdy element reprezentuje
nie więcej niż jeden obiekt rzeczywisty.
Identyfikator encji Kombinacja atrybutów jednoznacznie odróżniająca
(ang. etity identifier) 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 OK 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 No. W rozdziale 4,
 Konwencje , podnoszono wielokrotnie problem jednolitego nazewnictwa
i konsekwencji w używaniu skrótów. Rysunek 6.15 przedstawia pole dialogowe
Abbreviations.
Rysunek 6.15.
Narzędzie
Silverrun
umożliwia
zdefiniowanie
skrótów,
używanych
w nazwach
elementów modelu.
2. Uaktywnić tryb eksperta, wybierając opcję Expert Mode z menu Expert.
 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.
Rysunek 6.16.
Model po
normalizacji
przeprowadzonej
przez program
ERX.
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.
176 Część I
Rysunek 6.17.
Ekspert
normalizacji
programu ERX
dodał do projektu
nową encję.
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
 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.
Wez
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ą z
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 znalez
ć 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 znalez
ć 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ść?) - odpowiedz
No (Nie).
general, can one  CALL have many  PROPERTY ? (Czy z jednym
In
zgłoszeniem telefonicznym może być skojarzona więcej niż jedna
nieruchomość?) - odpowiedz
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?)
- odpowiedz
No (Nie).
 Projektowanie baz danych w modelu klient/serwer 183
general, can one  PROPERTY have many  CALL ? (Czy jednej
In
nieruchomości może dotyczyć wiele zgłoszeń telefonicznych?) - odpowiedz

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ść?) -
odpowiedz
Yes (Tak).
general, can one  LEASE have many  PROPERTY ? (Czy jedna
In
umowa najmu może dotyczyć wielu nieruchomości?) - odpowiedz
No (Nie).

In general, is it necessary for a  PROPERTY to have a  LEASE to exist?
(Czy każda nieruchomość musi mieć umowę najmu?) - odpowiedz
No (Nie).
general, can one  PROPERTY have many  LEASE ? (Czy jednej
In
nieruchomości może dotyczyć wiele umów najmu?) - odpowiedz
Yes (Tak).
general, is it necessary for a  LEASE to have a  TENANT to exist?
In
(Czy z każdą umową najmu musi być skojarzony najemca?) - odpowiedz

Yes (Tak).

In general, can one  LEASE have many  TENANT ? (Czy jedna umowa
najmu może dotyczyć wielu najemców?) - odpowiedz
No (Nie).
general, is it necessary for a  TENANT to have a  LEASE to exist?
In
(Czy z każdym najemcą musi być skojarzona umowa najmu?) - odpowiedz

No (Nie).

In general, can one  TENANT have many  LEASE ? (Czy jeden najemca
może mieć wiele umów najmu?) - odpowiedz
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
Rysunek 6.18.
Model po
zweryfikowaniu
asocjacji.
Określenie liczności
Po uruchomieniu eksperta normalizacji, asocjacja encji CALL i PROPERTY
zmieniła się z 1,1 na 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. Odpowiedz
, 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ą
 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
najmniej 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
i 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 Search 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:
odpowiedzi na pytanie o identyfikator encji CALL, należy podwójnie
W
kliknąć na nazwie atrybutu Call Number, a następnie kliknąć przycisk
Continue.
 Projektowanie baz danych w modelu klient/serwer 187
odpowiedzi na pytanie o identyfikator encji LEASE należy podwójnie
W
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.
odpowiedzi na pytanie o identyfikator encji TENANT należy podwójnie
W
kliknąć na nazwie atrybutu Tenant Number, a następnie kliknąć przycisk
Continue.
Identyfikatory encji będą teraz podkreślone, co ilustruje rysunek 6.19.
Rysunek 6.19.
Model po
zdefiniowaniu
identyfikatorów
encji.
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
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ąć OK. 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).
 Projektowanie baz danych w modelu klient/serwer 189
Rysunek 6.20.
Program ERX
może
automatycznie
wygenerować
poprawne nazwy
encji.
Rysunek 6.21.
ERX może również
automatycznie
nazwać inne
elementy modelu,
np. atrybuty.
190 Część I
Rysunek 6.22.
Gotowy model
związków encji (E-R).
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óz
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.
 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 Zbiór danych pogrupowanych w tabele. Bazę danych
(database) 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 Pojedynczy zbiór danych w ramach bazy. Tabelę
(table) 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 Odpowiada jednemu obiektowi rzeczywistemu,
(row) 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 Element wiersza. Kolumna opisuje pewną właściwość
(column) 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 Kolumna lub zbiór kolumn, jednoznacznie
(primary key) 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 Kolumna lub zbiór kolumn przejętych z innej tabeli.
(foreign key) 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 Kolumna lub zbiór kolumn, jednoznacznie identyfiku-
(candidate key) 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 Zapytanie SQL, którego zbiór wynikowy zawiera
(join) 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 Mechanizmy, uniemożliwiające wygenerowanie lub
(constraint) 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 Mechanizm, wspomagający szybkie odnajdowanie
(index) 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 Logiczna reprezentacja podzbioru danych tabeli. Sama
(view) 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 Skompilowany fragment programu w języku SQL,
(stored procedure) 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ń Szczególny rodzaj procedury pamiętanej, która
(trigger) 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ąć OK.
W odpowiedzi na pytanie o nazwę wynikowego pliku RDM, kliknąć OK, co
spowoduje przyjęcie proponowanej domyślnie nazwy (zob. rysunek 6.23)
 Projektowanie baz danych w modelu klient/serwer 195
Rysunek 6.23.
Narzędzie
Silverrun ERX-
RDM służy do
przekształcania
modeli E-R
w modele
relacyjne.
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ąć OK. 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.
196 Część I
Rysunek 6.24.
Oryginalny model
relacyjny,
utworzony na bazie
diagramu E-R.
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óz
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
 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ąć OK. Ponowne kliknięcie OK 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ąć OK.
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
Liczba miejsc
Nazwa Typ Długość Wartość Wartości
po przecinku
bazowy domyślna
TAddition Character 20 N/D 'Sherwood' 'Sherwood',
'Deerfield',
'Switzerland
Estates',
'Firewheel', 'Legacy
Hills', 'RockKnoll'
TAddress Character 30 N/D Brak Brak
TCity Character 30 N/D 'Oklahoma 'Oklahoma City',
City' 'Norman',
'Edmond', 'Dallas',
'Plano', 'Richardson'
TComments VarChar 80 N/D Brak Brak
TPhone Character 13 N/D Brak 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 20 N/D 'Putnam 'Putnam City',
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 1 N/D Brak 'Y', 'N', 'T', 'F'
 Projektowanie baz danych w modelu klient/serwer 199
Liczba miejsc
Nazwa Typ Długość Wartość Wartości
po przecinku
bazowy domyślna
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
Rysunek 6.25.
Dla samodzielnie
zdefiniowanych
domen można
definiować zbiory
dopuszczalnych
wartości.
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 Dozwolone opis**
puste?
miejsc po
przecinku
Addition TAddition N Dzielnica
Address TAddress N Adres
BathRooms TRooms N A
azienki
 Projektowanie baz danych w modelu klient/serwer 201
Nazwa kodowa Domena Długość Liczba Dozwolone opis**
puste?
miejsc po
przecinku
BedRooms TRooms N Sypialnie
BeginDate DATE N Data
rozpoczęcia
wyn.
CallDate DATE N Data
zgłoszenia
Call_Number INTEGER N Nr
zgłoszenia
CHARACTER
CallTime 11 N Godzina
zgłoszenia
CentralAir TYesNo N Klimatyzacj
a
CentralHeat TYesNo N CO
City TCity N Miasto
Comments TComments Y Komentarz
Deposit TRent N Depozyt
Description CHARACTER 30 N Opis
Dish Washer TYesNo N Zmywarka
do naczyń
Employer CHARACTER 30 N Pracodawca
EmployerAddress TAddress N Adres
pracodawcy
EmployerCity TCity N Miasto
pracodawcy
EmployerState TState N Stan
pracodawcy
EmployerZip TZip N Kod
pocztowy
pracodawcy
EndDate DATE N Data
zakończenia
wyn.
GarageType TRooms N Typ garażu
202 Część I
Nazwa kodowa Domena Długość Liczba Dozwolone opis**
puste?
miejsc po
przecinku
GasHeat TYesNo N Ogrzewanie
gazowe
HomePhone TPhone N Telefon
domowy
ICEPhone TPhone N Telefon
komórkowy
LasLawnDate DATE Y Ostatnie
koszenie
trawnika
LastSprayDate DATE Y Ostatnie
opryskiwanie
LawnService TYesNo N Usługa
koszenia
Lease_Number INTEGER N Nr umowy
najmu
LivingAreas TRooms N Pokoje
dzienne
MovedInDate DATE N Data objęcia
lokalu
MovedOutDate DATE Y Data
opuszczenia
lokalu
Name CHARACTER 30 N Nazwisko
PerDeposit TRent Y Depozyt
PrivacyFence TYesNo N Płot
Property_Number TPropertyNo N* Nr
nieruchomo-
ści
Range TYesNo N Zakres
Refrigerator TYesNo N Lodówka
Rent TRent N Czynsz
RentDueDay SMALLINT N Dzień
płatności
czynszu
 Projektowanie baz danych w modelu klient/serwer 203
Nazwa kodowa Domena Długość Liczba Dozwolone opis**
puste?
miejsc po
przecinku
SchoolDistrict TSchoolDistri N Okręg
ct szkolny
State TState N Stan
Tenant_Number TTenantNo N Nr najemcy
WorkPhone TPhone N Telefon
służbowy
Zip TZip N 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).
kolumn liczbowych, w których nie będą przechowane części ułamkowe,
Dla
należy wybierać typy danych całkowitych, a nie zmiennopozycyjnych.
długości łańcuchów znaków w poszczególnych wierszach mogą się
Jeśli
znacząco różnić, należy stosować typy znakowe o zmiennej długości w miejsce
typów o ustalonej długości.
stosowana platforma systemowa dopuszcza użycie typów danych
Jeżeli
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ąć OK (zob. rysunek 6.26)
Rysunek 6.26.
Tabele, należące
do modelu, można
opatrywać
komentarzami.
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ąć OK (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,
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.
Rysunek 6.27.
Komentarzami
można również
opatrywać
poszczególne
kolumny.
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.
 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).
Rysunek 6.28.
Gotowy logiczny
model danych.
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.
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
Rysunek 6.29.
Nazwę modelu
określa się w oknie
dialogowym
Schema
Description.
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
 Projektowanie baz danych w modelu klient/serwer 213
widoczny jest skrypt LEASE.SQL załadowany do edytora tekstu z
ródłowego
Delphi.
Rysunek 6.30.
Do edycji skryptów
SQL można
wykorzystać edytor
tekstu z
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).
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 znalez
ć
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).