plik

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).

Modelowanie reguł przetwarzania realizowane jest w trzech etapach:

1. Określenie niezbędnych procesów, obiektów zewnętrznych, strumieni i zbiorów

danych.

Rysunek 8.1.
Model reguł
przetwarzania
zarządzania
wynajmem.

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:

Jakie obiekty zewnętrzne są niezbędne do prowadzenia dokumentacji

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.

Należy oddzielić procesy niezbędne do obsługi wynajmu od procesów

realizowania wynajmu.

Firma Allodium Properties chce śledzić zgłoszenia od spodziewanych

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.

Po zweryfikowaniu przez niego umowy najmu, przekazywana jest ona do

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.

Weźmy pierwszą z tych funkcji i wykorzystajmy podobny zestaw pytań, jak
w przypadku procesu zarządzania wynajmem.

Jakie obiekty zewnętrzne są niezbędne do śledzenia prac konserwacyjnych

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.

Do obsługi przetwarzania zgłoszeń i prac konserwacyjnych będą potrzebne

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.

Będą potrzebne co najmniej trzy dodatkowe zbiory danych: zbiór najemców,

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

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

- wybór należy do użytkownika).

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óźniej informacja ta będzie wykorzystana do tworzenia atrybutów
w schematach E-R i tabelach w relacyjnym modelu danych. Na schemacie

Rysunek 8.2.
Model reguł
przetwarzania dla
zarządzania
majątkiem.

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 z

lecenia)

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ąć

. - 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 (

) 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óźniej będzie można użyć ich do konstruowania encji w schemacie E-R. Po
kliknięciu

skasowany zostanie komunikat informacyjny, pojawiający się po

zakończeniu uaktualnienia.

4. Kliknąć przycisk zamknięcia (

) 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

Pierwsza rzeczywista aplikacja bazy danych klient/serwer

253

Na rysunku 8.3 pokazano możliwy wygląd schematu E-R.

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ąć

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.

Rysunek 8.3.
Schemat E-R
w etapach
początkowych.

254

Część II

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

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óź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

Rysunek 8.4.
Schemat E-R po
wykonaniu
normalizacji.

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óź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.

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.

Rysunek 8.5.
Model po
uporządkowaniu.

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

Odpowiedź

In general, is it necessary for a WORDER to have an
EMPLOYEE to exist?

Yes

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WORDER jest istnienie odpowiadającego wystąpienia
encji EMPLOYEE?)

(Tak)

In general, can one WORDER have many EMPLOYEEs?

Czy jedno wystąpienie encji WORDER może odpowiadać
wielu wystąpieniom encji EMPLOYEE?

(Nie)

In general, is it necessary for a EMPLOYEE to have an
WORDER to exist?

(Czy niezbędnym warunkiem istnienia wystąpienia encji
EMPLOYEE jest istnienie odpowiadającego wystąpienia
encji WORDER?)

(Nie)

In general, can one EMPLOYEE have many WORDERSs?

Yes

Czy jedno wystąpienie encji EMPLOYEE może
odpowiadać wielu wystąpieniom encji WORDER?

(Tak)

In general, is it necessary for a WORDER to have
a WODETAIL to exist?

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WORDER jest istnienie odpowiadającego wystąpienia
encji WODETAIL?)

(Nie)

In general, can one WORDER have many WODETAILs?

Yes

Czy jedno wystąpienie encji WORDER może odpowiadać
wielu wystąpieniom encji WODETAIL?

(Tak)

Pierwsza rzeczywista aplikacja bazy danych klient/serwer

257

Pytanie

Odpowiedź

In general, is it necessary for a WODETAIL to have
a WORDER to exist?

Yes

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WODETAIL jest istnienie odpowiadającego wystąpienia
encji WORDER?)

(Tak)

In general, can one WODETAIL have many WORDERs?

Czy jedno wystąpienie encji WODETAIL może
odpowiadać wielu wystąpieniom encji WORDER?

(Nie)

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

(Czy niezbędnym warunkiem istnienia wystąpienia encji
CALL jest istnienie odpowiadającego wystąpienia encji
WORDER?)

(Nie)

In general, can one CALL have many WORDERs?

Czy jedno wystąpienie encji CALL może odpowiadać
wielu wystąpieniom encji WORDER?

(Nie)

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

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WORDER jest istnienie odpowiadającego wystąpienia
encji CALL?)

(Nie)

In general, can one WORDER have many CALLs?

Yes

Czy jedno wystąpienie encji WORDER może odpowiadać
wielu wystąpieniom encji CALL?

(Tak)

In general, is it necessary for a WORKTYPE to have
a WODETAIL to exist?

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WORKTYPE jest istnienie odpowiadającego wystąpienia
encji WODETAIL?)

(Nie)

In general, can one WORKTYPE have many
WODETAILs?

Yes

Czy jedno wystąpienie encji WORKTYPE może
odpowiadać wielu wystąpieniom encji WODETAIL?

(Tak)

258

Część II

Pytanie

Odpowiedź

odpowiadać wielu wystąpieniom encji WODETAIL?

In general, is it necessary for a WODETAIL to have
a WORKTYPE to exist?

Yes

(Czy niezbędnym warunkiem istnienia wystąpienia encji
WODETAIL jest istnienie odpowiadającego wystąpienia
encji WORKTYPE?)

(Tak)

In general, can one WODETAIL have many
WORKTYPEs?

Czy jedno wystąpienie encji WODETAIL może
odpowiadać wielu wystąpieniom encji WORKTYPE?

(Nie)

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ć.

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

Rysunek 8.6.
Model po ustaleniu
połączeń między
encjami.

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ąć

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.

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

Rysunek 8.7.
Schemat E-R po
zdefiniowaniu
kluczy
pierwotnych.

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.

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

Rysunek 8.8.
Schemat końcowy
E-R.

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

. 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 ź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

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

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

13. W oknie dialogowym

Connectors

klikamy

, 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

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

zamykamy okno dialogowe

Table Columns

. Na rysunku 8.10 pokazano

przykład ilustrujący tę sytuację.

Rysunek 8.9.
Logiczny model
danych
RENTMAN.

Pierwsza rzeczywista aplikacja bazy danych klient/serwer

265

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.

Rysunek 8.10.
Usuwanie kolumny
Property Number
z tablicy CALL.

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

Tabela

Kolumna

Domena

Długość

Miejsca
dziesiętne

Wart.
domyśl.

Czy
możliwa
wart.
zerowa

EMPLOYEE

Employee Number

Employee Name

INTEGER

CHARACTER

N/A

pusty

Nie

WORDER

WOrder Number

WOrder Start Date

WOrder End Date

WOrder Comments

INTEGER

DATE

TComments

N/A

pusty

N/A

Nie

Tak

WODETAIL

WODetail Line

Number

WODetail
Description

INTEGER

CHARACTER

N/A

Nie

Tak

WORKTYPE

Work Type Code

Work Type
Description

Work Type Task
Duration

INTEGER

CHARACTER

DECIMAL

N/A

Nie

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ąć

. Stworzone obiekty znajdują się

w bazie danych InterBase (tak więc

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

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

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.

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

Rysunek 8.11.
Używając
narzędzia
Connector RDM
można łatwo
połączyć tabele.

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.

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

Rysunek 8.12.
Model po dodaniu
kluczy obcych.

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

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

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 znaleźć 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

. 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ć:

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