Rozdział 8
Pierwsza rzeczywista aplikacja bazy
danych klient/serwer
Programy Silverrun, opisywane w rozdziałach 6,7 i 8, są jednymi z wielu
zestawów narzędzi dostępnych dla osób programujących w języku Delphi
(wybrane zostały przez autora i nie są odbiciem preferencji firmy Borland).
Rozdział ten rozpoczyna drugą część książki -  Tutorial . Czytelnik znajdzie
w niej informacje na temat budowania aplikacji bazy danych klient\serwer.
W naszych rozważaniach jest to aplikacja, którą można określić jako system
zarządzania wynajmem (w skrócie RENTMAN) - konstruowana według założeń
zaprezentowanych w rozdziałach 6 i 7.
Ograniczona objętość tej książki nie pozwoliła omówić wyczerpująco wszystkich
aspektów dotyczących konstruowania aplikacji RENTMAN - ograniczyliśmy się
więc do tych, których znajomość jest niezbędna przy tworzeniu aplikacji
klient/serwer. Naszym celem było:

Zaprezentowanie praktycznej realizacji (prezentowanych wcześniej w książce),
koncepcji dotyczących projektowania aplikacji i bazy danych.

Wielostronna analiza procesu tworzenia rzeczywistej aplikacji klient/serwer.

Podanie wyczerpujących wskazówek i zasygnalizowanie trudności.

Pokazanie sposobu optymalizacji aplikacji dla systemu zarządzania bazą
danych klient\serwer.
Jak już mówiliśmy w rozdziale 6, w procesie budowania aplikacji bazy danych
formalnie można wyróżnić następujące procesy:

Definiowanie celu i funkcji bazy danych .

Projektowanie fundamentu bazy danych i procesów aplikacji, niezbędnych do
implementowania tych funkcji.

Przekształcenie projektu w aplikację - przez stworzenie bazy danych i obiektów
programowych.

Testowanie aplikacji pod kątem zgodności ze zdefiniowanym celem
i funkcjami.

Instalowanie aplikacji.
244 Część II
Wyróżnić zatem możemy pięć faz tworzenia oprogramowania:

Analiza

Projekt

Budowa (konstrukcja)

Testowanie

Eksploatacja
Poprawne budowanie złożonej aplikacji dowolnego typu wymaga starannego
planowania.
Wiele zadań z zakresu konstrukcji aplikacji RENTMAN zostało zrealizowanych
wcześniej, szczególnie dotyczy to zagadnień odnoszących się do projektowania
bazy danych.
UWAGA
Wstępny projekt bazy danych, opisany w rozdziale 6, stanowi punkt wyjścia prac
projektowych, z którymi obecnie się zaznajomimy. Przed przejściem do
następnego etapu należy więc najpierw wykonać zadania przedstawione
w rozdziale 6 lub zapoznać się z modelem zapisanym na dołączonym do książki
dysku CD-ROM.
Możemy odwołać się do rozdziału 6, w którym opisany został proces zarządzania
i pobierania opłat dzierżawnych dla firmy Allodium Properties. Obecnie,
wykorzystując nabyte w rozdziale 6 umiejętności, można zbudować i zbadać
proces konserwacji. Wykonany zostanie pełny model procesu z wykorzystaniem
tych elementów, związanych z regułami przetwarzania, które powinny być
włączone do aplikacji. W pierwszej kolejności - do tworzonego modelu
wbudowywane będą elementy wspólne dla procesów dzierżawienia i konserwacji
oraz dla modeli z rozdziału 6.
Definiowanie celu aplikacji
Pierwszą czynnością, jaką należy wykonać przed rozpoczęciem opracowywania
aplikacji, jest określenie jej zadań i naszych oczekiwań.
Podobnie jak w rozdziale 6, możemy to zrobić, deklarując cel. Deklaracja ta
powinna zawierać zdanie, które składa się z podmiotu, orzeczenia i dopełnienia.
Podmiotem jest zawsze aplikacja, orzeczenie opisuje pracę, którą ona wykonuje,
a podmiot identyfikuje odbiorcę (tej pracy).
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 245
Aplikacja opisywana w tym rozdziale ma jasny cel: zarządzanie własnością
dzierżawioną. System nie zastąpi ludzi, szczególnie przy podejmowaniu decyzji,
a jedynie pomoże im w zarządzaniu. Tak więc deklaracja celu aplikacji
RENTMAN, sformułowana już w rozdziale 6, jest następująca:
System RENTMAN ułatwia zarządzanie nieruchomościami.
Definiowanie funkcji aplikacji
Po sformułowaniu deklaracji celu można przystąpić do określenia obowiązkowych
funkcji aplikacji, czyli takich, bez których byłaby ona niekompletna (które musi
posiadać, aby wypełnić deklarację celu). W tym przypadku należy dokładnie
określić, co powinna wykonywać aplikacja w celu  ułatwienia zarządzania
własnością dzierżawioną .
Należy postępować tak, jak w przypadku określania deklaracji celu. W rozdziale 6,
stosując tę metodę, wyodrębniliśmy następujące funkcje systemu RENTMAN:
System RENTMAN ułatwia zarządzanie nieruchomościami poprzez:

Rejestrację i obsługę umów najmu nieruchomości.

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

Generowanie rachunków dla najemców.

Dostarczanie informacji archiwalnych o poszczególnych nieruchomościach.
Po zdefiniowaniu podstawowych funkcji aplikacji nadszedł czas na
zaprojektowanie bazy danych i obiektów programowych, niezbędnych do
wykonywania zdefiniowanych funkcji.
Projektowanie podstaw bazy danych i procesów
W rozdziale 6 badane są: baza danych i elementy programowe, niezbędne do
zaimplementowania zarządzania wynajmem. Odpowiada to pierwszej z czterech
podstawowych funkcji systemu RENTMAN. Omówimy tutaj czynniki niezbędne
do obsługi pozostałych funkcji podstawowych, a szczególnie przebieg prac
remontowych - (konserwacji) nieruchomości, fakturowanie najemcy
i archiwizowanie danych statystycznych najmu. Szczęśliwie korzystają one
w dużym stopniu z tej samej bazy danych, stosując niektóre elementy programowe
procesu najmu.
246 Część II
Modelowanie reguł przetwarzania
Rzeczywiste projektowanie bazy danych rozpoczyna się modelowaniem procesu,
a kończy projektowaniem tworzących ją obiektów fizycznych. Ogólnie mówiąc,
projekt bazy danych można sprowadzić do trzech etapów:
1. Dokumentowanie reguł przetwarzania, koniecznych do spełnienia wymaganych
funkcji aplikacji.
2. Tworzenie związków encji niezbędnych do obsługi tych procesów.
3. Stworzenie logicznego projektu bazy danych, niezbędnego do zrealizowania
związków encji i reguł przetwarzania.
Rozpoczniemy dokumentację reguł przetwarzania od ponownego przyjrzenia się
pracy wykonanej w rozdziale 6.
Modele reguł przetwarzania mogą pomóc projektantowi w myśleniu kategoriami
procesów, z których składa się aplikacja. Pomagają one w określaniu, które
elementy programu i bazy danych są niezbędne przy implementowaniu zadanych
reguł przetwarzania. Modele składają się ze zbiorów, procesów i zewnętrznych
elementów połączonych razem strumieniami. Na rysunku 8.1 pokazano końcową
wersję modelu reguł przetwarzania zarządzania wynajmem (z rozdziału 6).
Rysunek 8.1.
Model reguł
przetwarzania
zarządzania
wynajmem.
Modelowanie reguł przetwarzania realizowane jest w trzech etapach:
1. Określenie niezbędnych procesów, obiektów zewnętrznych, strumieni i zbiorów
danych.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 247
2. Określenie wzajemnych relacji między tymi elementami.
3. Schemat tych elementów i związków w modelu.
Najpierw, w celu uzyskania informacji niezbędnej do budowania procesu, należy
przeprowadzić wywiad z użytkownikiem, sformułować pytania i poznać
interesującą nas rzeczywistość. W konstruowaniu modelu procesu zarządzania
wynajmem należałoby uzyskać odpowiedzi na następujące pytania:
obiekty zewnętrzne są niezbędne do prowadzenia dokumentacji
Jakie
i zarządzania wynajmem majątku?

Jakie procesy można wyróżnić?

Jakich zasobów wymagają te procesy?

Jakie zbiory danych będą niezbędne?

Jak będą przepływały dane z jednego elementu do drugiego?
Po uzyskaniu odpowiedzi na te pytania możemy stwierdzić, że:

Potrzebny jest co najmniej jeden obiekt zewnętrzny - spodziewany najemca.
oddzielić procesy niezbędne do obsługi wynajmu od procesów
Należy
realizowania wynajmu.
Allodium Properties chce śledzić zgłoszenia od spodziewanych
Firma
najemców i zbierać oddzielnie informacje o najemcach, umowach wynajmu
i nieruchomości, co pociąga za sobą konieczność istnienia czterech zbiorów
danych. W zbiorach tych będą gromadzone zgłoszenia, najemcy, umowy
wynajmu i nieruchomości.
Co się tyczy przepływu danych między tymi elementami, można przyjąć, że:

Spodziewani najemcy kontaktują się z urzędnikiem w biurze, w celu
zasięgnięcia informacji o dostępnych nieruchomościach lub zawarcia umowy
najmu.

Urzędnik rejestruje każde odebrane zgłoszenie, bez względu na to, czy jego
wynikiem

jest zawarcie umowy, czy też nie.

Urzędnik sprawdza dostępne nieruchomości.
zweryfikowaniu przez niego umowy najmu, przekazywana jest ona do
Po
zatwierdzenia (dyrektorowi działu).

Informacja o najemcy jest zapisywana do pliku.

Dyrektor działu przechowuje zapis zawartej umowy.
248 Część II
Ponieważ proces zarządzania wynajmem jest zasadniczo zakończony, narzuca się
pytanie, jakie inne czynności należy wykonać, aby zaimplementować pozostałe
funkcje systemu RENTMAN, czyli:

Śledzenie prac konserwacyjnych nieruchomości.

Generowanie rachunków dla najemców.

Archiwizowanie informacji dotyczących nieruchomości.
Wez
my pierwszą z tych funkcji i wykorzystajmy podobny zestaw pytań, jak
w przypadku procesu zarządzania wynajmem.
obiekty zewnętrzne są niezbędne do śledzenia prac konserwacyjnych
Jakie
majątku?

Jakie procesy można wyróżnić?

Jakich zasobów wymagają te procesy?

Jakie zbiory danych będą niezbędne?

Jak będą przepływały dane z jednego elementu do drugiego?
Dochodzimy do następujących wniosków:

W modelu niezbędny jest co najmniej jeden obiekt zewnętrzny, reprezentujący
najemców, którzy zgłaszają się z żądaniami konserwacji.
obsługi przetwarzania zgłoszeń i prac konserwacyjnych będą potrzebne
Do
oddzielne procesy.

Konieczny będzie zbiór danych, w którym będzie można zbierać (a następnie
udostępniać z niego) informacje o pracach konserwacyjnych.
potrzebne co najmniej trzy dodatkowe zbiory danych: zbiór najemców,
Będą
zbiór zgłoszeń i zbiór danych majątku.
Co do przepływu danych między tymi elementami, można przyjąć, że:

Najemcy kontaktują się z biurem, aby poinformować o zaistniałym problemie

Personel biura otwiera zlecenie pracy i przyporządkowuje je konserwatorowi.

Pracownik wykonuje pracę i po jej zakończeniu powiadamia biuro.
Wzorując się na rozdziale 6, należy skonstruować reguły przetwarzania, które
obejmują te elementy, czyli uruchomić narzędzie Silverrun-BPM i zbudować
model podobny do pokazanego na rysunku 8.2.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 249
WSKAZÓWKA
Wykorzystanie starych modeli przy konstruowaniu nowych oszczędza czas - unika
się ponownego tworzenia elementów modelu (zbiorów danych, procesów itp.),
które występowały w modelu pierwotnym. W tym przypadku nowy model reguł
przetwarzania możemy oprzeć na procesie opisanym w rozdziale 6. Należy
w Silverrun-BPM ponownie otworzyć plik modelu LEASE.BPM i - używając opcji
menu File\Clone - zapisać go pod inną nazwą. Następnie zamknąć LEASE.BPM
i załadować nowy model (alternatywą klonowania, zamknięcia i ponownego
załadowania jest wybór polecenia File\Save as - wybór należy do użytkownika).
Rysunek 8.2.
Model reguł
przetwarzania dla
zarządzania
majątkiem.
W opisanym powyżej modelu są dwa zbiory danych, które nie występowały
w modelu procesu wynajmu, skonstruowanym w rozdziale 6 (EMPLOYEE
i WORDER). Ich pojawienie się związane jest z koniecznością przyporządkowania
konserwatora do zleconych prac konserwacyjnych.
Firma Allodium chce, aby w nowym systemie naśladować formularze papierowe.
W celu przechowywania informacji, dotyczących zleceń prac w mieszkaniach,
dołączono zbiór danych WORDER. Żaden z tych dwóch zbiorów danych nie był
potrzebny w modelu procesu wynajmu, w związku z tym nie były one tam
implementowane.
Tak jak w przypadku procesu wynajmu należy w tym miejscu określić struktury
danych. Pozwolą one na zdefiniowanie informacji o atrybutach dla zbiorów
danych. Póz
niej informacja ta będzie wykorzystana do tworzenia atrybutów
w schematach E-R i tabelach w relacyjnym modelu danych. Na schemacie
250 Część II
znajdują się dodane właśnie dwa zbiory danych i niezbędne struktury danych.
Należy zdefiniować dwie nowe struktury (Project\Data Structures),
następnie dodać atrybuty do każdej struktury (Data\Structure
Composition).
Do struktury danych EMPLOYEE należy dodać następujące atrybuty:
Employee Number (numer pracownika)
Employee Name (nazwisko pracownika)
Do struktury danych WORDER należy dodać te atrybuty:
WOrder Number (numer zlecenia)
WOrder Start Date (data rozpoczęcia zlecenia)
WOrder End Date (data zakończenia zlecenia)
WOrder Employee Number (nr pracownika przyporządkowanego do
Ą' zlec.)
WOrder Property Number (nr własności)
WODetail Line Number (numer wiersza)
WODetail Description (opis szczegółu)
Work Type Code (kod typu)
Work Type Description (opis typu)
Work Type Task Duration (czas trwania zadania)
WOrder Comments (komentarze)
Po ustanowieniu struktury danych, należy skojarzyć ją z odpowiednim zbiorem
danych. W tym celu powinniśmy postępować zgodnie z procedurą opisaną poniżej:
1. Wyświetlić listę aktualnie zdefiniowanych zbiorów danych. W tym celu
w aplikacji Silverrun-BPM należy wybrać opcję menu Presentation\Palettes\
Data Structures.
2. Używając prawego przycisku myszy przeciągnąć strukturę danych - z Data
Structure Palette - do odpowiedniego zbioru danych.
3. W Data Structure Palette, na lewo od skojarzonych struktur danych, widoczna
jest gwiazdka. Można również dwukrotnie kliknąć zbiór (store) - aby upewnić
się, że jest on prawidłowo połączony ze strukturą danych.
Zachowywanie modelu
Po prawidłowym ustawieniu struktur danych nie ma przeszkód, aby zapisać nowy
model (należy w tym celu kliknąć opcję File\Save ). Dobrą nazwą dla tego pliku
(o ile nie jest już nazwany) jest MAINT.BPM. Następnie przechodzimy do
tworzenia schematu E-R.
Specjalny zestaw instrukcji, służący do udostępnienia zbiorów danych dla
programu narzędziowego Silverrun-ERX, pozwala na wykorzystanie zbiorów
i struktur danych, zdefiniowanych w modelu reguł przetwarzania, w diagramach
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 251
związków encji. Przede wszystkim należy uaktualnić składnicę elementów modelu,
w taki sposób, aby utworzony model był dostępny dla obu narzędzi - BPM i ERX.
W tym celu powinniśmy:
1. Kliknąć opcję menu Util\WRM. Spowoduje to przejście do trybu specjalnego,
umożliwiającego pracę lokalnej składnicy Silverrun. Powinno pojawić się okno
dialogowe, zatytułowane WRM Dictionary, i nowe menu WRM Dictionary, które
zostanie wyświetlone na menu głównym Silverrun-BPM.
2. Kliknąć pozycję menu WRM Dictionary\Update WRM Dictionary (przy
widocznym na ekranie oknie dialogowym).
3. W wyświetlonym właśnie oknie dialogowym kliknąć opcję Update. Następnie -
aby zaakceptować nazwę uaktualnionego raportu - należy kliknąć przycisk
Save. Efektem będzie kopiowanie składnicy i uaktualnienie jej o zbiory danych
i struktury istniejące w modelu. Zaakceptować domyślną nazwę pliku
uaktualnianego raportu, a następnie kliknąć OK. - co spowoduje wykasowanie
komunikatu informacyjnego, wyświetlonego po uaktualnieniu.
4. Kliknąć opcję menu WRM Dictionary\Save WRM Dictionary, następnie podać
nazwę MAINT.WRM - jako nową dla pliku składnicy Na dysk twardy zapisana
zostanie kopia składnicy, skąd można ją importować do programu Silverrun-
ERX.
5. Kliknąć przycisk zamknięcia (Close) na ramce okna dialogowego WRM
Dictionary.
Teraz, gdy model i skojarzona z nim składnica są zapisane na dysku, można
przejść do konstruowania diagramu E-R dla procesu zarządzania konserwacją.
Zamknąć narzędzie Silverrun-BPM i uruchomić ERX.
Modelowanie związków encji
Podstawową zaletą (jak już wspomniano w rozdziale 6) stosowania narzędzia
Silverrun ERX do projektowania bazy danych jest to, że można normalizować
związki encji. ERX ułatwia wykrywanie i ustalanie tych powiązań, które nie są
zgodne z trzecią postacią normalną. Proces ten można nieco uprościć, nazywając
atrybuty tak, aby nieodpowiednie wzajemne relacje były łatwiejsze do zauważenia
(jest to jednak czymś niezwykłym wśród narzędzi E-R). W wielu narzędziach
CASE, wspierających tworzenie baz danych, nie ma udogodnień normalizujących
projekt.
Można pominąć proces wykonywania schematu E-R i przejść prosto do tworzenia
logicznego modelu bazy danych. Narzędzie Silverrun RDM importuje zbiory
danych zarówno z narzędzia BPM, jak i ERX. Powtórzmy jeszcze raz -
podstawową zaletą użycia w tym momencie programu ERX jest to, że pomaga
252 Część II
zabezpieczyć spójność relacji modelu. Niektórzy programiści uważają proces
tworzenia schematu E-R za zbędny i bezpośrednio - z fazy modelowania procesów
- przechodzą do modelowania logicznego danych.
Importowanie zbiorów modelu reguł przetwarzania
Aby przetransponować zbiory danych, zdefiniowane w modelu reguł
przetwarzania, na encje, należy je wpierw importować do programu
narzędziowego ERX Silverrun. W tym celu trzeba:
1. Wybrać opcję menu Util\WRM Dictionary. Spowoduje to przejście ERX do
specjalnego trybu pracy z lokalną składnicą Silverrun.
2. Kliknąć opcję menu WRM Dictionary\Update a Model i wybrać plik składnicy
MAINT.WRM, stworzony w narzędziu BPM.
3. Wybrać opcję menu WRM Dictionary\Update a Model, następnie kliknąć Update
w oknie dialogowym i zaakceptować domyślną nazwę dla uaktualnionego pliku
raportu. Po zapytaniu, czy dołączyć model do tego samego projektu, w którym
znajduje się składnica, należy kliknąć Yes. Dodane zostaną do bieżącego
modelu zbiory danych i struktury, zdefiniowane w modelu reguł przetwarzania.
Póz
niej będzie można użyć ich do konstruowania encji w schemacie E-R. Po
kliknięciu OK skasowany zostanie komunikat informacyjny, pojawiający się po
zakończeniu uaktualnienia.
4. Kliknąć przycisk zamknięcia (Close) na ramce okna dialogowego WRM
Dictionary.
Teraz zbiory dostępne są w modelu i można je przeciągnąć (myszą) na
powierzchnię modelowania i w ten sposób przetransponować na encje, które
można ująć w schemacie E-R. Aby tego dokonać, należy:
1. Wybrać opcję menu Presentation\Palettes\Component: SR Store - wyświetli się
paleta zbiorów importowanych pośrednio z modelu reguł przetwarzania.
2. Z wyjątkiem zbiorów LEASE i PROPERTY, każdy zbiór danych należy
przeciągnąć z palety na powierzchnię modelowania, używając prawego
przycisku myszy. Zbiory danych LEASE i PROPERTY można pominąć,
ponieważ nie istnieją one w modelu procesu zarządzania konserwacją. Każdy
z nich pozostaje w modelu procesu wynajmu.
3. Należy zauważyć, że każda encja jest tworzona w centrum modelu - bez
względu na to, gdzie jest  upuszczana , co powoduje narastanie stosu encji. Po
przetransponowaniu wszystkich zbiorów do modelu, należy przesunąć każdą
encję tak, aby nie nakładała się na inne.
4. Zamknąć okno dialogowe Componnet:SR Store palette przyciskiem Close.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 253
Na rysunku 8.3 pokazano możliwy wygląd schematu E-R.
Rysunek 8.3.
Schemat E-R
w etapach
początkowych.
Normalizacja modelu
Teraz, gdy uporządkowany jest wyjściowy zestaw encji, można przystąpić do
normalizacji modelu E-R. W tym celu należy:
1. Kliknąć opcję menu Expert\Expert Mode - ERX przejdzie do specjalnego trybu,
w którym możliwe jest wykonanie zaawansowanych funkcji oraz
przeprowadzenie normalizacji.
2. Kliknąć opcję menu Expert\ Normalize Model. Spowoduje to uruchomienie
normalizacji. Po zapytaniu, czy analizować nazwy aktualnie używane
w modelu, klikamy Yes.
3. Po analizie nazw elementów modelu kliknąć OK w oknie dialogowym Analyze
Attribute Names.
4. Następnie zostanie wyświetlone okno dialogowe z komunikatem
ostrzegającym, że normalizacja może znacząco zmienić model. Wybranie Yes
sygnalizuje ERX zgodę na kontynuowanie procesu normalizacji.
Model jest obecnie znormalizowany w pełnym zakresie oferowanym przez ERX.
Relacje są początkowo układane w modelu na stosie (jedno na drugim). Należy
rozmieścić je w taki sposób, aby nie nakładały się na siebie. Na rysunku 8.4
pokazano przykładowy wygląd modelu.
254 Część II
Rysunek 8.4.
Schemat E-R po
wykonaniu
normalizacji.
Należy zwrócić uwagę na dwie nowe encje w modelu, a mianowicie WODetail
i Work Type. Aby uzyskać zgodność z resztą modelu, należy dwukrotnie kliknąć
górną część każdej z nich i zmienić ich nazwy na pisane dużymi literami. Zgodnie
z przyjętą w rozdziale 4 konwencją, dotyczącą nazewnictwa, podczas zamiany
małych liter na duże, z nazwy encji Work Type powinna zostać usunięta spacja.
Nie ma wątpliwości, że normalizując model, przy pomocy ERX, programista
oszczędza czas. Pojawia się jednak również kilka problemów. Po pierwsze, należy
zwrócić uwagę na wzajemne związki między encjami WORDER i WORKTYPE.
WORKTYPE jest w rzeczywistości powiązany z pozycjami wierszy zleceń pracy;
w przypadku jednego zlecenia pracy może być realizowane kilka różnych typów
prac.
Złożenie dokonane przez eksperta normalizacji jest więc nieprawidłowe. Aby
zapobiec takiej sytuacji, należy postępować zgodnie z procedurą opisaną poniżej:
1. Kliknąć obiekt relacji między encjami WORDER i WORKTYPE i wybrać
Delete - powiązania między tymi dwoma obiektami zostaną usunięte.
2. Wybrać narzędzie relacji w palecie narzędzi ERX (najlepiej dopuszczające
linie diagonalne), a następnie kliknąć (jeden raz) encję WODETAIL
i WORKTYPE - między nimi zostaną utworzone powiązania. Należy
zauważyć, że minimalna i maksymalna liczność relacji jest pozostawiona pusta.
Można je póz
niej ustawić po zweryfikowaniu połączeń modelu.
Inny problem, związany z modelem wynika z faktu, iż TENANT jest encją
 wiszącą . Nie znajduje się ona w jakichkolwiek relacjach z innymi encjami.
Problem ten nie jest wynikiem złej pracy narzędzi normalizacji ERX, ale luki
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 255
w oryginalnych, wcześniej stworzonych, definicjach struktury danych BPM.
W modelu procesu konserwacji nie ma bezpośredniego odniesienia, przez
jakiekolwiek inne zbiory, do zbioru danych TENANT. W modelu procesu
wynajmu zbiór TENANT jest powiązany ze zbiorem LEASE , a LEASE ze
zbiorem PROPERTY. W modelu procesu konserwacji zbiory PROPERTY
i LEASE są albo definiowane bez odpowiednich struktur danych albo są
całkowicie pominięte. W konsekwencji zbiór danych TENANT jest nie związany.
Ponieważ w póz
niejszym okresie relacyjne modele danych procesu wynajmu
i konserwacji będą połączone, nie ma to aż tak istotnego znaczenia. W tym
momencie można usunąć z modelu encję TENANT. W tym celu należy kliknąć
lewym przyciskiem myszy wskazując encję TENANT a następnie nacisnąć
klawisz Delete. Na rysunku 8.5 pokazano przykładowy wygląd modelu na tym
etapie.
Rysunek 8.5.
Model po
uporządkowaniu.
Weryfikowanie połączeń
Uporządkowany model jest gotowy do zweryfikowania. W procesie weryfikacji
sprawdzane jest, czy normalizacja połączeń encji, oparta na przypuszczeniach
eksperta, jest poprawna. Aby sprawdzić dokładność bieżących wzajemnych
zależności encji, należy:
1. Wybrać opcję menu Expert\Verify Connectivities - aby rozpocząć pracę eksperta
połączeń, który postawi szereg pytań, odnoszących się do wzajemnych
związków między encjami w schemacie.
256 Część II
2. Kliknąć przełącznik (radio button) All Connectivities w oknie dialogowym
Verify Connectives i upewnić się, czy dla wybranego pola wyboru wzajemnych
związków nie dokonano już weryfikacji. Kliknąć Verify.
3. Następnie ekspert zada kilka pytań odnoszących się do wzajemnych związków
między encjami. Silverrun-ERX wykorzysta uzyskane w ten sposób informacje
do ustawienia połączeń w modelu. Odpowiadając na pytania, należy używać
odpowiedzi podanych w tabeli 8.1.
Tabela 8.1 Odpowiedzi na pytania stawiane przez eksperta połączeń ERX
Pytanie Odpowiedz

In general, is it necessary for a WORDER to have an Yes
EMPLOYEE to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Tak)
WORDER jest istnienie odpowiadającego wystąpienia
encji EMPLOYEE?)
In general, can one WORDER have many EMPLOYEEs? No
Czy jedno wystąpienie encji WORDER może odpowiadać (Nie)
wielu wystąpieniom encji EMPLOYEE?
In general, is it necessary for a EMPLOYEE to have an No
WORDER to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Nie)
EMPLOYEE jest istnienie odpowiadającego wystąpienia
encji WORDER?)
In general, can one EMPLOYEE have many WORDERSs? Yes
Czy jedno wystąpienie encji EMPLOYEE może (Tak)
odpowiadać wielu wystąpieniom encji WORDER?
In general, is it necessary for a WORDER to have No
a WODETAIL to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Nie)
WORDER jest istnienie odpowiadającego wystąpienia
encji WODETAIL?)
In general, can one WORDER have many WODETAILs? Yes
Czy jedno wystąpienie encji WORDER może odpowiadać (Tak)
wielu wystąpieniom encji WODETAIL?
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 257
Pytanie Odpowiedz

In general, is it necessary for a WODETAIL to have Yes
a WORDER to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Tak)
WODETAIL jest istnienie odpowiadającego wystąpienia
encji WORDER?)
In general, can one WODETAIL have many WORDERs? No
Czy jedno wystąpienie encji WODETAIL może (Nie)
odpowiadać wielu wystąpieniom encji WORDER?
In general, is it necessary for a CALL to have a WORDER No
to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Nie)
CALL jest istnienie odpowiadającego wystąpienia encji
WORDER?)
In general, can one CALL have many WORDERs? No
Czy jedno wystąpienie encji CALL może odpowiadać (Nie)
wielu wystąpieniom encji WORDER?
In general, is it necessary for a WORDER to have a CALL No
to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Nie)
WORDER jest istnienie odpowiadającego wystąpienia
encji CALL?)
In general, can one WORDER have many CALLs? Yes
Czy jedno wystąpienie encji WORDER może odpowiadać (Tak)
wielu wystąpieniom encji CALL?
In general, is it necessary for a WORKTYPE to have No
a WODETAIL to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Nie)
WORKTYPE jest istnienie odpowiadającego wystąpienia
encji WODETAIL?)
In general, can one WORKTYPE have many Yes
WODETAILs?
Czy jedno wystąpienie encji WORKTYPE może (Tak)
odpowiadać wielu wystąpieniom encji WODETAIL?
258 Część II
Pytanie Odpowiedz

odpowiadać wielu wystąpieniom encji WODETAIL?
In general, is it necessary for a WODETAIL to have Yes
a WORKTYPE to exist?
(Czy niezbędnym warunkiem istnienia wystąpienia encji (Tak)
WODETAIL jest istnienie odpowiadającego wystąpienia
encji WORKTYPE?)
In general, can one WODETAIL have many No
WORKTYPEs?
Czy jedno wystąpienie encji WODETAIL może (Nie)
odpowiadać wielu wystąpieniom encji WORKTYPE?
Po udzieleniu odpowiedzi na pytania ekspert połączeń ERX ustala wzajemne
związki między encjami - aby określić liczność relacji na podstawie uzyskanych
odpowiedzi. Należy zauważyć, że liczność relacji między encjami WORDER
i WODETAIL nie jest już pusta. Na rysunku 8.6 pokazano, jak taki model
powinien wyglądać.
Rysunek 8.6.
Model po ustaleniu
połączeń między
encjami.
Definiowanie identyfikatorów encji
Teraz, gdy związki między encjami są ustawione prawidłowo, można przystąpić do
ustanawiania identyfikatorów dla każdej klasy encji. Postępując zgodnie
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 259
z procedurą opisaną poniżej, należy wskazać atrybuty, które identyfikują każdą
z encji.
1. Aby uruchomić eksperta identyfikacji encji, należy kliknąć opcję menu
Expert\Search for Identifiers.
2. Upewnić się, że znacznik wyboru encji nie został już wybrany w otwartym
oknie dialogowym i kliknąć Search.
Zamiast przeszukiwania ekspert wyświetla więc szereg okien dialogowych, które
pozwalają na określenie identyfikatora dla każdego atrybutu. Aby wykorzystać
identyfikatory podane w tabeli 8.2, należy dwukrotnie kliknąć wpierw
identyfikator encji, a następnie przycisk Continue.
Spowoduje to przesunięcie identyfikatora na wierzchołek listy. W jego kolumnie
id zostanie wyświetlona gwiazdka.
Tabela 8.2 Identyfikatory obiektów dla schematów E-R.
Encja Identyfikator
CALL Numer zgłoszenia
EMPLOYEE Numer pracownika
WODETAIL Identyfikator WORDER, numer wiersza WODetail
WORDER Numer WOrder
WORKTYPE Kod typu pracy
Należy zauważyć złożoność identyfikatora encji WODETAIL. Każde zlecenie
pracy może mieć wiele wierszy opisujących pracę do wykonania. Każdy z wierszy
będzie kolejno numerowany, w ten sposób nadany zostanie atrybut numeru
wiersza WODetail Line Number. Jednakże numery wiersza same w sobie nie są
wystarczające do jednoznacznej identyfikacji każdej wystąpienia encji
WODETAIL (np. wszystkie zlecenia pracy powinny normalnie mieć wiersz
o numerze 1) Do prawidłowej identyfikacji potrzebny jest dodatkowy element.
W tym przypadku pominiętym składnikiem jest numer wiersza głównego zlecenia
pracy. Numer ten jest identyfikatorem encji WORDER. Stosując połączenie
numerów zlecenia pracy i numeru wiersza, można określić każde pojawienie się
encji WODETAIL. W ten sposób WODETAIL jest zależny od encji WORDER,
ponieważ jego identyfikator encji zawiera co najmniej częściowo identyfikator
encji WORDER. ERX podświetla tą encję zależnie od podkreślenia odpowiedniej
liczności w modelu.
260 Część II
UWAGA:
Ekspert identyfikatorów ERX umieszcza atrybut identyfikatora WORDER poniżej
atrybutu numeru linii WODetail w liście, którą determinuje identyfikator encji
WODETAIL. Pomimo tego może wydawać się, że kolumna numeru zlecenia pracy
powinna poprzedzać kolumnę numeru linii w fizycznej implementacji bazy
danych, ale nie należy się tym niepokoić. Silverrun RDM, generujący, wymagany
do stworzenia projektu bazy danych, skrypt SQL, poradzi sobie z właściwym
ustawieniem kolejności atrybutów w więzach klucza pierwotnego WODETAIL.
Umieszczenie identyfikatora encji WORDER po lewej stronie klucza pierwotnego
WODETAIL spowoduje zbudowanie indeksu WODETAIL przy pomocy trzech
kolumn ustawianych w określonej kolejności. Wszystko to oznacza, że położenie
identyfikatora WORDER jest nieistotne, gdy więzy klucza pierwotnego
WODETAIL i indeksy są zbudowane w sposób prawidłowy.
Na rysunku 8.7 pokazano model z rozmieszczonymi kluczami pierwotnymi.
Rysunek 8.7.
Schemat E-R po
zdefiniowaniu
kluczy
pierwotnych.
Zachowywanie modelu
Zasadniczo budowa schematu E-R została zakończona. Teraz można zachować
model i przekształcić go na format pliku narzędzia RDM. Aby przygotować model
dla Silverrun-RDM, należy:
1. Wybrać opcję File\Save - w celu zapisania modelu na dysk twardy (nazwa
MAINT.ERX). Jak już była mowa w rozdziale 6, model przed zapisaniem
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 261
można opisać, używając opcji menu Model\Model Description. Na rysunku 8.8
pokazano wygląd modelu z opisem.
2. Opuścić narzędzie ERX i uruchomić Silverrun ERX-RDM. Narzędzie to jest
wykorzystywane do przekształcenia modelu, zaprojektowanego w ERX, na
format pliku, który jest kompatybilny z Silverrun-RDM.
3. W Silverrun ERX-RDM wybrać opcję menu File\Transform ERX->RDM.
4. Wybrać plik zawierający model E-R, stworzony dla procesu konserwacji.
Powinien być nazwany MAINT.ERX.
5. Po zapytaniu o wybór nazwy pliku wyjściowego, należy zaakceptować
proponowaną MAINT.RDM. Plik ten powinien być zgodny z narzędziem
Silverrun RDM.
6. Zamknąć narzędzie Silverrun ERX-RDM i uruchomić Silverrun-RDM.
Rysunek 8.8.
Schemat końcowy
E-R.
Konstruowanie logicznego modelu danych
Po przetłumaczeniu schematu E-R na format pliku kompatybilnego z Silverrun-RD
możemy przejść do budowy relacyjnego modelu projektowanej bazy danych.
Należy zdać sobie sprawę, że w tym miejscu główny akcent w procesie
modelowania zaczyna się przesuwać w kierunku fizycznej implementacji bazy
danych. Następuje przejście od definiowania pojęć abstrakcyjnych - np. encji - do
definiowania struktur fizycznych (tabel). Efektem pracy będzie skrypt SQL, który
262 Część II
można użyć do tworzenia obiektów, wyszczególnionych w logicznym modelu
danych. W dalszej części podręcznika omówiliśmy wykorzystanie skryptu do
tworzenia tabel RENTMAN i innych obiektów baz danych na platformie
docelowej DBMS ( dla systemu RENTMAN platformą docelową jest Inter Base).
Integracja relacyjnego modelu wynajmu
Aby rozpocząć budowę logicznego modelu danych (LDM - logical data model) dla
procesu konserwacji, należy w pierwszej kolejności dołączyć logiczny model
danych procesów wynajmu. Integracja ta umożliwi uzyskanie pojedynczego
modelu danych dla całości bazy danych RENTMAN - z pominięciem ponownego,
 ręcznego tworzenia obiektów.
Silverrun-RDM posiada opcje, zaprojektowane specjalnie w celu integracji
różnych modeli. Aby wykorzystać je do połączenia procesu wynajmu
i konserwacji w jeden relacyjny model danych, powinniśmy:
1. Klikając przycisk zamknięcia na ramce okna, zamknąć domyślny model
stworzony przez RDM.
2. Kliknąć przycisk otwarcia na pasku narzędzi i wybrać plik MAINT.RDM -
stworzony jako ostatni przez Silverrun ERX-RDM.
3. Może pojawić się komunikat sygnalizujący, iż plik modelu odpowiada starszej
wersji narzędzia RDM. Aby jednak go otworzyć klikamy Yes
4. Teraz zapytani zostaniemy o wybór systemu docelowego dla modelu.
Wybieramy Avail.Target Sys. oraz - z wyświetlonego, rozwijalnego menu -
INTBASINTBAS41.TYP i klikamy OK. Umożliwi to wybranie ostatniej wersji
InterBase (4.1), obsługiwanej przez Silverrun-RDM, oraz platformy docelowej
DBMS. Otwarty zostanie model w narzędziu RDN.
5. Klikamy opcję menu Schema\Schema Description i zmienić opis na:
Realtional Data Model for Maintenance Process, a następnie
zapisujemy model.
6. Po raz drugi wybieramy przycisk otwarcia i otwieramy, stworzony w rozdziale
6 dla procesu wynajmu, relacyjny model danych. Powinien nazywać się
LEASE.RDM.
7. Aby uruchomić eksperta integracji RDM, klikamy opcję menu Util.\Integrate.
8. W oknie dialogowym Schema Integration wybieramy schemat relacyjny
wynajmu - jako schemat z
ródłowy (Source Schema) i schemat relacyjny
konserwacji - jako docelowy (Dest. Schema) i klikamy Integrate.
9. Wyświetlone zostanie okno dialogowe sygnalizujące, że model wynajmu
powinien być uwzględniony jako schemat cząstkowy modelu konserwacji. Ten
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 263
komunikat jest mało znaczący - by przejść do dalszej realizacji zadań klikamy
OK.
10. Aby zaakceptować nazwę pliku dla raportu integracji klikamy Save w oknie
dialogowym Integration Report.
11. W oknie dialogowym Target Systems, w liście platform docelowych,
wybieramy opcję Inter Base i potwietrdzamy przyciskiem OK.
12. Aby połączyć obiekty, wykorzystujące wspólną nazwę, w oknie dialogowym
Tables należy kliknąć przycisk Link by Name. W tym przypadku jest to tablica
CALL. Klikamy OK.
13. W oknie dialogowym Connectors klikamy OK, akceptując domyślną
informację konektora. Ekspert zintegruje wówczas model wynajmu z modelem
konserwacji.
14. Otworzyć okno, zawierające logiczną strukturę danych konserwacji. Powinien
wówczas zostać wyświetlony model wynajmu, połączony z modelem
konserwacji. Prawdopodobnie będziemy musieli przemieścić pozycje w tym
modelu tak, aby nie zachodziły na siebie, a ich wzajemne relacje stały się
bardziej wyraziste.
15. Wybrać opcje menu Schema\Schema Description i obciąć nową nazwę modelu
do postaci Relational Data Model (nazwa projektu zawarta jest
w tytule okna, więc szerszy opis nie ma uzasadnienia).
16. Zapisujemy nowy model jako RENTMAN.RDM (nie nadpisywać
MAINT.RDM). Jest to teraz relacyjny model danych, na podstawie którego
będzie konstruowana baza danych RENTMAN. Na rysunku 8.9 pokazano
przykładowy wygląd takiego modelu.
264 Część II
Rysunek 8.9.
Logiczny model
danych
RENTMAN.
Zdolność do integracji oddzielnych modeli relacyjnych jest jedną z największych
zalet Silverrun (cechy tej nie posiadają znane autorowi inne narzędzia typu
CASE). Jeśli (z jakichkolwiek przyczyn) nie będziemy mogli jej wykorzystać,
wówczas będziemy musieli  ręcznie połączyć modele, w narażonym na błędy
i nudnym procesie.
Szczególnie interesująca jest integracja dwóch różnych widoków tabeli CALL.
W modelu wynajmu jest ona przyłączona do tabeli PROPERTY, natomiast w
modelu konserwacji - do tabeli WORDER. Należy zauważyć, że nowy model
obsługuje wstępnie obydwie relacje, co oznacza istotną oszczędność czasu.
Tabela CALL zawiera w dalszym ciągu kolumnę o nazwie Property Number -
pozostałość pierwotnego modelu reguł przetwarzania konserwacji. Atrybut
Number Property został włączony do modelu procesu konserwacji, ponieważ
znajdował się w formularzu zgłoszenia firmy Allodium. Obecnie, gdy między
tabelami CALL i PROPERTY została ustanowiona relacja z użyciem klucza
obcego, można tę kolumnę bezpiecznie skasować. Nie będzie ona już więcej
potrzebna, ponieważ zastępująca ją relacja spowoduje stworzenie kolumny
Property Number w fizycznej bazie danych. Aby usunąć kolumnę należy
dwukrotnie kliknąć tabelę CALL, wybrać kolumnę Property Number (jej kolumny
Coded Name i Domain powinny być puste), a następnie kliknąć Delete. Klikając
OK zamykamy okno dialogowe Table Columns. Na rysunku 8.10 pokazano
przykład ilustrujący tę sytuację.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 265
Rysunek 8.10.
Usuwanie kolumny
Property Number
z tablicy CALL.
W tabeli WORDER pojawia się ten sam problem; posiada ona zbędną kolumnę
Property Number, która bez wątpienia przeszła z formularza zamówienia
Allodium. Należy usunąć ją w taki sam sposób, jak w przypadku kolumny Property
Number z tabeli CALL. Następnie należy - używając narzędzia konektora RDM -
ustanowić relację z użyciem klucza obcego między tabelami WORDER
i PROPERTY.
Definiowanie kolumn
Dla zachowania jednolitości aplikacji RENTMAN należy - po zintegrowaniu
logicznego modelu danych wynajmu i konserwacji w pojedynczy model relacyjny
- zdefiniować informacje o domenach dla tych tabel, które powstały dopiero
w modelu konserwacji. Tabele pochodzące z modelu wynajmu mają już określone
domeny (co można łatwo sprawdzić po dwukrotnym kliknięciu lub oglądając
uważnie rysunek 8.10). Dla pojawiających się w modelu konserwacji tabel:
WORDER, WODETAIL, WORKTYPE i EMPLOYEE musimy określić
ustawienia domen - tj. typ kolumny, jej długość, wszystkie zasady integralności
lub więzy i różne inne szczegóły określane na poziomie kolumny (dwukrotnie
klikamy każdą tabelę modelu konserwacji i definiujemy domeny zgodnie z tabelą
8.3).
Zwróćmy uwagę na wykorzystanie domeny użytkownika (Tcomments) w kolumnie
Worder Comments tabeli WORDER. Dodatkową korzyścią integracji logicznego
modelu danych wynajmu i konserwacji jest uzyskanie dostępu do domen
użytkownika, pierwotnie zdefiniowanych w modelu wynajmu.
266 Część II
UWAGA:
Kolumny Descriptions w tabelach CALL, WODETAIL i WORKTYPE są bardzo
podobne. Ze względów praktycznych nie były one wcześniej definiowane. Warto
o tym pamiętać podczas tworzenia własnych baz danych. Dzięki gromadzeniu
najczęściej spotykanych typów danych w domenach centralnych oszczędzamy czas
i unikamy kłopotów, gdyby kiedykolwiek zaistniała potrzeba dokonywania zmian
w definicjach przyłączanych kolumn. Jeśli do definiowania wielu kolumn używana
jest pojedyncza domena, można jednocześnie wprowadzić zmiany do wszystkich
kolumn, modyfikując tylko ich domenę
Tabela 8.3 Informacje dotyczące domen kolumn dla tabel modelu konserwacji
Miejsca Wart. Czy
Tabela Kolumna Domena Długość
dziesiętne domyśl. możliwa
wart.
zerowa
EMPLOYEE
Employee Number INTEGER N/A N/A pusty Nie
Employee Name CHARACTER 30 N/A pusty Nie
WORDER
WOrder Number INTEGER N/A N/A pusty Nie
WOrder Start Date DATE N/A N/A pusty Nie
WOrder End Date DATE N/A N/A N/A Tak
WOrder Comments TComments N/A N/A N/A Tak
WODETAIL
WODetail Line INTEGER N/A N/A N/A Nie
Number
WODetail
CHARACTER 30 N/A N/A Tak
Description
WORKTYPE
Work Type Code INTEGER N/A N/A N/A Nie
Work Type CHARACTER 30 N/A N/A Nie
Description
Work Type Task
DECIMAL 5 2 N/A Nie
Duration
Generowanie nazw kodowych
Po zdefiniowaniu wszystkich kolumn możemy przystąpić do generowania nazw
kodowych dla poszczególnych elementów modelu. Są one drugimi nazwami
elementów, które są dopuszczalne na wybranej platformie DBMS. Silverrun-RDM
usuwa spacje, obcina długie nazwy i ogólnie porządkuje nazwy wykorzystywane
przez model. Należy zauważyć, że zachowywane są nazwy pierwotne, wybrane
przez użytkownika; nazwy kodowe są przechowywane oddzielnie. Podczas
generowania skryptu SQL który będzie używany do konstruowania obiektów bazy
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 267
danych, można stosować pełne nazwy elementów modelu lub ich nazwy kodowe.
Za pośrednictwem opcji menu Presentation\Displayed Descriptor można także
skontrolować, czy RDM będzie wyświetlać nazwy kodowe w reprezentacji
graficznej modelu. Aby wygenerować nazwy kodowe dla modelu, należy:
1. Wybrać opcję menu Schema\Generate Coded Name.
2. Kliknąć przycisk Specify, a następnie ustawić maksymalną długość
(Maximum Lenght), a dla ilości znaków od początku do końca
każdego słowa w nazwie przyjąć 30. Stworzone obiekty znajdują się
w bazie danych InterBase (tak więc 30 jest dobrym wyborem).
3. Ustawienia innych okien dialogowych należy pozostawić nie zmienione.
Następnie, aby powrócić do okna dialogowego Coded Names Generation,
klikamy kolejno OK i przycisk Generate.
Nowe nazwy kodowe zostaną wyświetlone po dwukrotnym kliknięciu każdej tabeli
w modelu. Aby zobaczyć nazw kodowe dla dowolnej kolumny, klikamy ją
dwukrotne w oknie dialogowym Table Column.
Po wygenerowaniu nazw kodowych dla elementów modelu należy edytować
nazwy dla kolumn w tabelach WORDER, WODETAIL, EMPLOYEE
i WORKTYPE (podobnie jak w przypadku tabel modelu wynajmu). Za wyjątkiem
klucza pierwotnego tabel, należy usunąć nazwy tabeli na lewo od każdej kodowej
nazwy kolumny. Pierwotnie te przedrostki nazw pełniły funkcję pomocniczą dla
eksperta normalizacji w Silverrun-ERX, ale w tym momencie stają się zbędne.
Stąd np. należy zredukować WODetail_Description na Description, ale
nazwa WODetail_Line_Number powinna pozostać nie zmieniona. W ten
sposób obiekty otrzymują nazwy ułatwiające pracę nad aplikacjami, które będą je
używać. Takie podejście gwarantuje też, że nazwy kolumn najbardziej nadających
się do tworzenia obcych kluczy w innych tabelach (tj. klucze pierwotne) pozostają
unikalne w całej bazie danych.
Ustanawianie relacji
Z uwagi na fakt, iż model był importowany z Silverrun-ERX, większość relacji jest
już właściwa. Jednakże z racji tego, że encja nieruchomości nie była nigdy
definiowana w schemacie E-R dla procesu konserwacji, żadna relacja między
tabelami WORDER i PROPERTY nie została jeszcze ustanowiona. Firma
Allodium Properties mogłaby naturalnie zamieścić informacje na temat
nieruchomości (majątku) na zleceniach pracy, przyporządkowanych do
konserwatorów. Mimo, że informację tę można uzyskać za pośrednictwem tabeli
CALL, nie wszystkie zlecenia pracy zostaną przyporządkowane zgłoszeniom.
W oparciu o historię nieruchomości kierownik konserwacji firmy może
zdecydować, czy w danym obiekcie powinien być wymieniony dach. Zlecenie
byłoby wtedy wydawane bez powiadamiania najemcy.
268 Część II
Rozwiązaniem tego problemu będzie relacyjne powiązanie dwóch tabel. Aby to
uczynić klikamy narzędzie Connector w palecie narzędzi RDM, następnie kolejno
tabele PROPERTY i WORDER. Wyświetlony zostanie wówczas ich tymczasowy
związek. Założenie przyjęte przez RDM, odnoszące się do liczności relacji, jest
poprawne i być może nie zajdzie potrzeba przeprowadzania modyfikacji. Jest to
w dużej mierze spowodowane kolejnością, w której obsługiwane były tabele.
RDM przyjmuje, że pierwsza wskazana tabela jest pierwotna (parent), a druga jest
tabelą pochodną (child). Na rysunku 8.1 pokazano nowe związki, które możemy
zobaczyć na ekranie.
Rysunek 8.11.
Używając
narzędzia
Connector RDM
można łatwo
połączyć tabele.
Generowanie kluczy obcych
Po wyznaczeniu wszystkich relacji między tabelami w modelu, można przystąpić
do generowania kluczy obcych. Zamiast automatycznego propagowania kluczy
obcych przy wzajemnym łączeniu tabel, narzędzie RDM stwarza nam możliwość
pracy wsadowej - w celu generowania kluczy obcych dla wszystkich tabel modeli
w jednym przebiegu. Generowanie kluczy obcych powoduje powielanie kolumn
kluczy z tabel pierwotnych (parent) do ich tabel pochodnych (child). W projekcie
fizycznym klucz obcy jest zazwyczaj implementowany jako kolumna (lub
kolumny) w tabeli pochodnej, która odnosi się do kluczy pierwotnych tabeli
pierwotnej.
Aby wygenerować klucze obce, należy postępować zgodnie z następującą
procedurą:
1. Wybrać opcję menu Schema\Foreign Keys.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 269
2. Kliknąć przycisk Generate w wyświetlonym oknie dialogowym.
3. Aby zaakceptować proponowaną nazwę pliku dla raportu, kliknąć przycisk
Save.
Do obiektów tabeli zostanie dodana pewna ilość nowych kolumn. W zależności od
wybranego stylu notacji, każdy klucz obcy zostanie prawdopodobnie poprzedzony
przedrostkiem FK. Na rysunku 8.12 pokazano przykładowy wygląd modelu.
Rysunek 8.12.
Model po dodaniu
kluczy obcych.
W tym momencie model jest już prawie ukończony. Można w zasadzie przystąpić
do generowania skryptu SQL, niezbędnego do tworzenia obiektów definiowanych
przez model.
Weryfikowanie integralności modelu
Przed generowaniem skryptu SQL, koniecznego do stworzenia obiektów bazy
danych, należy zweryfikować integralność modelu. Dla tego celu Silverrun-RDM
oferuje wygodne narzędzia. Tok postępowania będzie tutaj następujący:
1. Wybieramy opcję menu Schema\Verify.
2. Z okna dialogowego wybieramy Maximum Level of Verification,
a następnie przycisk Verify.
3. Po zapytaniu o nazwę pliku raportu, akceptujemy proponowaną nazwę.
Klikamy przycisk Verify.
270 Część II
4. Zostanie teraz wyświetlony komunikat, sygnalizujący brak błędów w modelu
(mogą również pojawić się ostrzeżenia - nie powinny one jednak sygnalizować
żadnych istotnych błędów).
5. Jeśli chcemy zobaczyć generowany przez RDM raport integralności modelu,
wybieramy opcję menu Util.\View a Text File i wpisujemy nazwę raportu
integralności (Verify, domyślnie). Aby obejrzeć wygenerowany raport, klikamy
Open.
Generowanie DDL
Po zakończeniu budowania modelu i zweryfikowaniu jego integralności można
przejść do generowania instrukcji SQL Data Definition Language (DDL) (język
definicji danych), niezbędnych do utworzenia bazy danych. Silverrun stworzy
pojedynczy skrypt SQL, który możemy uruchomić i stworzyć tym samym obiekty
bazy danych.
Dodatkowo - aby wygenerować instrukcje CREATE TABLE dla wszystkich tabel
w modelu narzędzie RDM umieszcza w skrypcie instrukcję CONNECT, która służy
do połączenia z bazą danych obejmującej nowe obiekty. RDM pobiera używaną
przez siebie nazwę bazy danych z bieżącego schematu nazw kodowych.
W związku z tym, przed przystąpieniem do generowania DDL, zalecane jest
ustalenie nazw kodowych bazy danych. Wówczas instrukcja CONNECT,
generowana przez RDM, zawierać będzie poprawną nazwę bazy danych. Aby
ustalić nazwę kodową schematu, powinniśmy:
1. Kliknąć opcję menu Schema\Schema Desciption. Spowoduje to wyświetlenie
okna dialogowego Schema Description.
2. W oknie wprowadzania danych Coded Name wpisać pełną ścieżkę nazwy bazy
danych InterBase, w której znajdują się nowe obiekty. Domyślnie ustawiono:
\DATA\RENTMAN\RENTMAN.GDB.
3. Aby opuścić okno dialogowe, klikamy OK.
Ustawianie bazy danych zostało zakończone i można przystąpić do generowania
skryptu SQL. W tym celu należy:
1. Wybrać opcję menu Schema\Generate DDL.
2. Kliknąć przełącznik (radio button) Coded Name w pojawiającym się oknie
dialogowym.
3. Wybrać opcję Generate.
4. Po zapytaniu o nazwę pliku, wpisać *.SQL (i wcisnąć ENTER). W efekcie
wyświetlone zostaną wszystkie skrypty SQL i zmieni się domyślne rozszerzenie
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 271
pliku - z TXT na SQL. Następnie wpisać RENTMAN.SQL i kliknąć Save.
Rozpocznie się teraz generowanie skryptu.
Właśnie utworzyliśmy model i skrypt (choć ten nie jest jeszcze całkowicie
gotowy). Model należy zapisać i opuścić Silverrun-RDM. listing 8.1 przedstawia
skrypt RENTMAN.SQL.
Listning 8.1 Skrypt DDL, generowany przez Silverrun-RDM, dla
relacyjnego modelu danych RENTMAN
CONNECT  C:\DATA\RENTMAN\RENTMAN.GDB USER   PASSWORD  ;
CREATE DOMAIN TAddition AS CHARACTER(20) NOT NULL CHECK
(VALUE IN ( Deerfield , Firewheel , Legacy Hils ,
Ą'  Switzerland Estates , Sherwood , Rockknoll ));
CREATE DOMAIN TAddres AS CHARACTER(30) NOT NULL CHECK
CREATE DOMAIN TCity AS CHARACTER(30) NOT NULL CHECK
(VALUE IN ( OklahomaCity , 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 No AS NUMERIC(5,2) NOT NULL;
CREATE DOMAIN TRooms No 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 TTenatNo AS INTEGER NOT NULL;
CREATE DOMAIN TYesNo AS CHARACTER(1) NOT NULL CHECK
(VALUE IN ('Y', 'N', 'T', 'F'));
CREATE DOMAIN TZip AS CHARACTER910) NOT NULL;
CREATE TABLE EMPLOYEE
( Employe_Number INTEGER NOT NULL
Name CHARACTER(30) NOT NULL
272 Część II
PRIMARY KEY (Employee_Number)
);
CREATE TABLE PROPERTY
( Property_Number TPropertNo 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'
Refrigerator TYesNo NOT NULL'
Range TYesNo NOT NULL'
DishWasher TYesNo NOT NULL'
PrivacyFence TYesNo NOT NULL'
LastLawnDate DATE,
LastSprayDate DATE,
PRIMARY KEY (Property_Number)
);
CREATE TABLE TENANT
( TENANT_Number TTenantNo NOT NULL,
Name CHARACTER (30) NOT NULL,
Employer CHAR(30) NOT NULL,
EmployerAddress TAddres NOT NULL,
EmployerCity TCity NOT NULL,
EmployeeState 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 WORKTYPE
( Wor_Type_Code INTEGER NOT NULL,
Description CHARACTER(30) NOT NULL,
TaskDuration NUMERIC(5,2) NOT NULL,
PRIMARY KEY (Wor_Type_Code)
);
CREATE TABLE LEASE
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 273
( Lease_Number INTEGER NOT NULL,
BeginDate DATE NOT NULL,
EndDate DATE NOT NULL,
MovedInDate DATE,
MovedOutDate DATE,
Rent TRent NOT NULL,
Deposit TRent,
PetDeposit TRent,
RentDueDay SMALLIINT NOT NULL,
LawnService TYesNo NOT NULL,
Comments TComments,
Property_Number TPropertyNo NOT NULL,
Tenant_Number TTenantNo NOT NULL,
PRIMARY KEY (Lease_Number),
CONSTRAINT FK_TENANT1
FOREIGN KEY (Tenant_Number)
REFERENCES TENANT,
CONSTRAINT FK_PROPERTY2
FOREIGN KEY (Property_Number)
REFERENCES PROPERTY
);
CREATE TABLE WORDER
( WOrder_Number INTEGER NOT NULL,
StartDate DATE NOT NULL,
EndDate DATE,
Comments TComments
Property_Number TPropertyNo NOT NULL,
Employee_Number INTEGER NOT NULL,
PRIMARY KEY (WOrder_Number),
CONSTRAINT FK_PROPERTY3
FOREIGN KEY (Property_Number)
REFERENCES PROPERTY
CONSTRINT FK_EMPLOYEE4
FOREIGN KEY (Employee_Number)
REFERENCES EMPLOYEE
);
CREATE TABLE CALL
( Call_Number INTEGER NOT NULL,
CallDate DATE NOT NULL,
CallTime CHARACTER(11) NOT NULL,
Description CHARACTER(30) NOT NULL,
Property Number TPropertyNo,
WOrder_Number INTEGER,
PRIMARY KEY (Call_Number)
CONSTRAINT FK_PROPERTY5
FOREIGN KEY (Property_Number)
REFERENCES PROPERTY,
CONSTRINT FK_WORDER6
FOREIGN KEY (WOrder_Number)
REFERENCES WORDER
274 Część II
);
CREATE TABLE WODTAIL
( WODetail_Line_Number INTEGER NOT NULL,
Description CHARACTER(30),
Work_Type_Code INTEGER NOT NULL,
WOrder_Number INTEGER NOT NULL,
PRIMARY KEY (WOrder_Number, WODetail_Line_Number),
CONSTRAINT FK_WORKTYPE7
FOREIGN KEY (Work_Type_Code)
REFERENCES WORKTYPE,
CONSTRAINT FK_WORDER8
FOREIGN KEY (WOrder_Number)
REFERENCES WORDER
);
Instrukcja CONNECT w skrypcie nie zawiera ważnej nazwy użytkownika i hasła.
Przy pomocy edytora kodu Delphi można edytować plik skryptu oraz do instrukcji
CONNECT dodać obowiązującą nazwę użytkownika i hasło. W tym celu należy
uruchomić Delphi i otworzyć (w edytorze) skrypt RENTMAN.SQL. Instrukcję
CONNECT należy zmienić zgodnie z poniższym wzorem:
CONNECT "C:\DATA\RENTMAN\RENTMAN.GDB" USER "SYSDBA" PASSWORD
Ą' "masterkey";
Po dokonaniu tej zmiany zapisać plik skryptu i opuścić Delphi.
Tworzenie bazy danych
Skrypt SQL DDL jest już kompletny i można przystąpić do tworzenia bazy danych
RENTMAN. Aby stworzyć bazę danych InterBase do obsługi obiektów bazy
danych RENTMAN, należy postępować zgodnie z poniższą procedurą:
1. Uruchomić serwer InterBase (jeśli tego jeszcze nie uczyniliśmy). Będzie on
prawdopodobnie pracował na komputerze lokalnym, aczkolwiek wcale tak być
nie musi. Aby uruchomić lokalną kopię serwera, należy wywołać aplikację
InterBase 4.2 w folderze InterBase 4.2. W systemie Windows NT 4.0
i Windows 95 dostęp do foldera InterBase 4.1 uzyskamy z poziomu
Exploratora. W NT 3.51, aby uruchomić serwer, należy znalez
ć grupę InterBase
4.2 i otworzyć ikonę InterBase 4.2.
2. Na serwerze stworzyć katalog, służący specjalnie do przechowywania
tworzonej bazy danych (na komputerze autora jest to: C:\DATA\RENTMAN).
3. Uruchomić narzędzie InterBase Windows ISQL i kliknąć jego opcję menu
File\Create Database. Na ekranie wyświetlone zostanie okno dialogowe Create
Database.
 Pierwsza rzeczywista aplikacja bazy danych klient/serwer 275
4. Po Database Name wpisać pełną ścieżkę dostępu do tworzonego pliku bazy
danych (domyślnie powinna to być: C:\DATA\RENTMAN\RENTMAN.GDB).
Wybrana nazwa powinna być zgodna z nazwą kodową (Name Coded), wpisaną
w oknie dialogowym Schema Description narzędzia RDM.
5. Do odpowiednich pól wprowadzania wpisać obowiązującą nazwę użytkownika
i hasło. Domyślnie proponowana nazwa użytkownika SYSDBA. Hasło
proponowane dla użytkownika SYSDBA InterBase przyjmuje nazwę
masterkey. Jest niezwykle istotne, należy więc upewnić się, że jest wpisane
prawidłowo.
6. Aby stworzyć bazę danych, klikamy OK. Wkrótce ISQL powinien zakończyć
proces tworzenia bazy danych i automatycznie przyłączyć do niej użytkownika.
Teraz baza danych jest gotowa i możemy przystąpić do uruchomienia skryptu
SQL, stworzonego przez Silverrun-RDM. Aby to zrobić, należy:
1. Wybrać opcję menu Script ISQL File\Run i podać nazwę pliku skryptu
wygenerowanego przez RDM.
2. Aby wykonać skrypt, klikamy Open.
3. Na zapytanie o zapisanie komunikatów do pliku należy odpowiedzieć: No.
Spowoduje to wyprowadzenie komunikatów do ISQL, co w tym przypadku jest
istotnym uproszczeniem.
4. Teraz ISQL powinien wyświetlić komunikat informujący o pomyślnym
wykonaniu skryptu. Możemy opuścić narzędzie ISQL.
Inne funkcje aplikacji RENTMAN
Pobieżny przegląd nowej bazy danych RENTMAN ujawnia, iż - dla implementacji
trzeciej i czwartej z głównych funkcji aplikacji RENTMAN - nie jest potrzebny
oddzielny proces i dodatkowe funkcje. Funkcje te (generowanie faktur dla najemcy
i historyczne informacje dotyczące majątku) można zrealizować na podstawie już
istniejącej bazy danych. Rola aplikacji RENTMAN sprowadza się do
wydrukowania odpowiednich raportów. Zakładając, że generowanie faktur stanowi
proste drukowanie pozostałych do zapłacenia rat najmu za każdy miesiąc dla
każdego najemcy, potrzebny jest jedynie dostęp do listy najemców, ich adresów,
terminy płatności rat oraz ich wysokość. Tabele TENANT, PROPERTY i LEASE
zawierają wszystkie elementy, niezbędne do uzyskania tych informacji.
Zapoznanie się z odpowiednią informacją archiwalną pozwala na określenie
okresów najmu i prac konserwacyjnych, które w tym czasie powinny być
wykonane. Powtórzmy to jeszcze raz - wszystkie niezbędne do właściwej pracy
aplikacji elementy są już dostępne. Jak będzie można zobaczyć w rozdziale 12,
RENTMAN - za pośrednictwem raportów - może wygenerować zestawienia
276 Część II
archiwalne dla każdej nieruchomości. Funkcje te nie wymagają definiowania
w aplikacji RENTMAN żadnych dodatkowych procesów lub obiektów danych.
Istnieją oczywiście procesy pochodne, wywodzące się z już omówionych . I tak
np. - w celu regularnej konserwacji majątku przedsiębiorstwo będzie musiało
sporządzić inwentarz narzędzi i materiałów do prowadzenia robót. Dla
przeprowadzenia inwentaryzacji i jej rozliczenia można by stworzyć oddzielny
model. Podobnie - do stworzonego już procesu generowania faktur możemy
dołączyć system płatności. Pozwoliłoby to na rozszerzenie możliwości systemu
o wydruk wystawianych najemcy faktur, zaległych płatności i tak dalej. Większość
z nich pominięto, aby skupić się na głównych funkcjach systemu RENTMAN.