    Ваша первая система клиент/сервер 

    ГЛАВА 8

    Средства пакета Silverrun, описанные в главах 6 и 7, — это только часть 
средств, доступных программистам, использующим Delphi. Автор данной книги в 
качестве примера выбрал систему Silverrun, но это не значит, что эти средства 
являются стандартом, рекомендуемым компанией Borland. 
    Этой главой открывается вторая часть книги — "Учебный курс". Данная часть 
посвящена построению приложения баз данных архитектуры клиент/сервер средней 
сложности. Это приложение называется Rental Management System, или сокращенно 
— RENTMAN. На основе сведений, полученных в главе 6 — "Проектирование базы 
данных архитектуры клиент/сервер" и в главе 7 — "Проектирование приложения 
архитектуры клиент/сервер", в данной главе вы ознакомитесь с полным процессом 
создания приложения баз данных архитектуры клиент/сервер. Будут рассмотрены 
самые важные вопросы разработки мощных приложений баз данных архитектуры 
клиент/сервер в среде Windows. Как и во всех остальных частях книги, основное 
внимание здесь будет уделяться практическим вопросам (т.е. тому, что и как 
работает). Это особенно актуально в отношении данной части книги, где вы 
ознакомитесь с созданием Windows-приложений архитектуры клиент/сервер. 
    Рассматривая процесс разработки системы RENTMAN, я не задавался целью 
создания приложения, которое вы могли бы немедленно использовать в своей 
работе. Ограничения места и времени не позволяют мне слишком углубиться в 
детали приложения RENTMAN. Впрочем, основной моей задачей является 
демонстрация способов построения приложений архитектуры клиент/сервер на 
основе большого количества составных частей. Кроме того, после небольшого 
вступления, в данной части книги будут рассмотрены способы объединения этих 
составных частей с целью создания реального приложения. В основном, я старался 
дать информацию, которая, на мой взгляд, является самой важной, не углубляясь 
в детали. 
    В этой части книги рассматриваются следующие вопросы. 
    • Демонстрация способов практического применения концепций разработки баз 
данных и приложений, описанных ранее в этой книге. 
    • Исследование процесса разработки существующих приложений архитектуры клиент/сервер. 
    • Подсказки и предостережения, которые позволят вам избежать 
распространенных ошибок. 
    • Описание способов оптимизации приложений архитектуры клиент/сервер для 
разных СУБД. 
    Как уже было сказано в главе 6, процесс создания базы данных разбивается 
на пять этапов. 
    • Определение назначения и круга задач приложения. 
    • Проектирование функциональности приложения и процессов, необходимых для 
реализации этой функциональности. 
    • Воплощение проекта в реальное приложение путем создания необходимых 
программных объектов и объектов базы данных. 
    • Тестирование приложения на предмет правильного функционирования и 
соответствия назначению. 
    • Настройка и установка приложения для его использования. 

    158 Часть II. Учебный курс 


    Другими словами, эти пять этапов соответствуют пяти этапам создания любого 
программного обеспечения. 
    • Анализ. 
    • Проектирование. 
    • Разработка. 
    • Тестирование. 
    • Совершенствование. 
    В данной главе описан первый этап из этого списка, а также, частично, 
второй и третий этапы. Более углубленное рассмотрение этапов проектирования и 
разработки приложения RENTMAN приведено в остальных главах части "Учебный курс". 
    Следуя указаниям этой главы, вы выполните большинство работ, практически 
не используя Delphi. Это связано с тем, что разработка любого серьезного 
приложения требует очень внимательного и всестороннего планирования перед 
началом собственно программирования. 
    Многие из задач, связанных с созданием приложения RENTMAN, уже были 
выполнены в главе 6 (особенно это касается создания базы данных). Учитывая 
это, я не буду углубляться в подробности реализации упомянутых задач, а буду 
только ссылаться на соответствующие разделы главы 6. 

    На заметку 
    Работе, описанной в данной главе, должно предшествовать предварительное 
проектирование базы данных, описанное в главе 6. Поэтому вам нужно либо 
выполнить все процедуры, описанные в главе 6, либо использовать готовые 
модели, находящиеся на прилагаемом к книге компакт-диске. Перед тем, как 
продолжать работу убедитесь, что вы как следует разобрались в модели процесса 
управления арендой системы RENTMAN. 

    Как вы помните, в главе 6 мы изучили процесс заключения договоров аренды и 
управления ими в вымышленной компании Allodium Properties. Теперь вы сможете 
реализовать полученные сведения на практике — полностью смоделируете 
составляющие процессов, которые нужно реализовать в приложении. Вначале нужно 
выделить составляющие процесса аренды и обслуживания недвижимости из моделей, 
разработанных в главе 6. Для этого вам придется бегло ознакомиться с описанием 
процесса управления арендой, представленным в той же главе. 

    Определение назначения приложения 

    В первую очередь вы должны решить, что же должно делать ваше приложение. 
Для этого, как было сказано в главе 6, сформулируйте его назначение. Такая 
формулировка должна состоять из одного предложения, в котором должны 
присутствовать подлежащее, сказуемое и дополнение. Подлежащее — ваше 
приложение, сказуемое описывает действия, выполняемые приложением, а 
дополнение описывает то, над чем приложение будет выполнять действия. 
    Приложение, столь детально описанное здесь и в последующих главах, 
преследует очень простую цель: 
    управление арендой недвижимости (разумеется, само по себе приложение не 
может осуществлять управление, оно может только помочь в этом людям). Таким 
образом, описание назначения приложения RENTMAN может выглядеть следующим образом: 
"Система RENTMAN обслуживает управление арендой недвижимости". 

    Определение функций приложения 

    Сформулировав назначение приложения, нужно выделить его основные функции. 
К основным относятся функции, используемые приложением для выполнения его 
назначения. Без точного определения основных функций приложение может работать 
некорректно. В нашем примере нужно точно определить, что должно делать 
приложение для обслуживания управления арендой недвижимости. 
    Для формулировки функций используйте тот же подход, что и для формулировки 
цели приложения. В части 6 приводятся следующие формулировки основных функций приложения. 

    Глава 8. Ваша первая система клиент/сервер 159 


    Система RENTMAN обслуживает управление арендой недвижимости. 
    • Система регистрирует и хранит договоры аренды. 
    • Система отслеживает выполнение текущих эксплуатационных работ. 
    • Система генерирует счета для арендаторов. 
    • Система выдает информацию об аренде каждого объекта недвижимости. 
    Закончив определение функций приложения, приступайте к проектированию 
объектов баз данных и программных объектов, необходимых для выполнения этих функций. 

    Проектирование базы данных и процессов предметной области 

    В главе 6 были описаны элементы базы данных и программные элементы, 
необходимые для организации управления договорами аренды, что соответствует 
первой функции приложения RENTMAN. В данной главе, а также в остальных главах 
этой части, будет рассмотрена реализация остальных функций (предоставление 
информации о текущих эксплуатационных работах, подготовка счетов для 
арендаторов и выдача статистических данных по каждому объекту недвижимости). 
Для описания одной из этих функций можно воспользоваться уже готовыми 
элементами базы данных и программными элементами, описанными в главе 6. 

    Моделирование процессов предметной области 

    Проектирование базы данных начинается моделированием процесса предметной 
области и заканчивается проектированием физических объектов, из которых должна 
состоять база данных. В общем случае процесс проектирования базы данных можно 
разбить на три этапа. 
    1. Документирование процессов предметной области, необходимых для 
выполнения определенных функций. 
    2. Составление диаграмм"сущность-связь", показывающих эти процессы. 
    3. Создание проекта логической структуры данных, необходимого для 
реализации этих связей и процессов. 
    Начнем с документирования процессов предметной области, положив в основу 
работу, выполненную в главе 6. Для создания приложения необходимо разработать 
модели таких процессов. На основании этих моделей выбираются элементы базы 
данных и программные элементы, необходимые для реализации соответствующих 
процессов. Модели представляют собой совокупность процессов, накопителей и 
внешних объектов, объединенных потоками данных. На рис. 8.1 представлен 
окончательный вариант модели управления арендой недвижимости, создание которой 
описано в главе 6. 
    Построение модели процесса предметной области выполняется в три этапа. 
    1. Определение необходимых процессов, внешних объектов, потоков и накопителей. 
    2. Определение связей между этими элементами. 
    3. Создание диаграммы модели, составленной на основе выбранных элементов и 
связей между ними. 
    Вы ведете опрос пользователей, отвечаете на поставленные вопросы и 
переходите к поиску информации, необходимой для построения модели. При 
построении модели процесса управления арендой недвижимости мы отвечали на 
следующие вопросы. 
    • Какие внешние объекты нужны для регистрации и хранения договоров аренды? 
    • Какие процессы участвуют в этих операциях? 
    • Какие ресурсы используются этими процессами? 
    • Какие накопители нужны? 
    • Как направлены потоки данных между элементами? 
    После ответа на поставленные вопросы мы выяснили следующее. 
    • Используется, по крайней мере, один внешний объект — потенциальный арендатор. 
    • Для обработки договоров и их исполнения нужны два отдельных процесса. 

    160 Часть II. Учебный курс 


    Рис. 8.1. Модель процесса управления арендой недвижимости 

    • Мы допустили, что наша вымышленная компания планирует регистрировать 
звонки потенциальных арендаторов, а также учитывать информацию об арендаторах, 
договорах аренды и объектах недвижимости. В таком случае нам понадобятся 
четыре накопителя, в которые будут помещаться сведения о звонках, арендаторах, 
договорах и объектах недвижимости. 
    • Что касается потоков данных между этими элементами, то мы предположили следующее. 
    • Потенциальные арендаторы связываются с оператором компании по аренде 
недвижимости для выяснения сведений об имеющихся предложениях или заключения 
договора об аренде. 
    • Оператор регистрирует звонок независимо от того, был заключен договор 
или нет. 
    • Оператор проверяет наличие свободных объектов недвижимости, и составляет 
договор об аренде. 
    • Подготовленный и проверенный оператором договор передается менеджеру по 
аренде
    • Информация об арендаторе, полученная во время составления договора, 
сохраняется оператором. 
    • Менеджер по аренде ведет учет действующих договоров. 
    Какие дополнительные элементы необходимы для реализации оставшихся функций приложения 
RENTMAN? Вспомним эти функции. 
    • Следить за выполнением заявок арендаторов. 
    • Генерировать счета для внесения арендной платы. 
    • Предоставлять информацию об аренде каждого объекта недвижимости. 
    Давайте возьмем первую из них и применим тот же набор вопросов, что и для 
процесса управления арендой недвижимости. 
    • Какие внешние объекты необходимы для управления эксплуатацией объектов недвижимости? 
    • Какие процессы участвуют в этих операциях? 
    • Какие ресурсы используются этими процессами? 
    • Какие накопители нужны? 
    • Как направлены потоки данных между элементами? 

    Глава 8. Ваша первая система клиент/сервер 
    6   Delphi 3 и системы клиент/сервер 161 


    На поставленные вопросы можно ответить несколькими различными способами, 
однако следующий представляется наиболее очевидным. 
    • Используется, по крайней мере, один внешний объект — обращающийся с 
заявкой арендатор. 
    • Для отслеживания звонков и для управления эксплуатацией необходимо два процесса. 
    • Требуется накопитель для хранения нарядов на работы. 
    • Понадобится, как минимум, три дополнительных накопителя: для хранения 
информации об арендаторах, о звонках и об объектах недвижимости. 
    • При исследовании потоков данных от одного элемента к другому мы можем 
предположить следующее. 
    • Для сообщения о возникшей проблеме арендатор связывается с оператором 
компании по аренде недвижимостью. 
    • Служащие составляют наряд на работы и назначают рабочих для их выполнения. 
    • Рабочие выполняют работы в соответствии с полученным нарядом и сообщают 
об этом в компанию. 
    Подобно тому, как мы это делали в главе 6, разработаем модель процесса 
предметной области, которая будет включать указанные элементы. Запустите 
систему Silverrun-BPM и создайте модель, подобную той, которая представлена на 
рис. 8.2. 

    Совет 
    Вы можете сэкономить время, если будете создавать новые модели на основе 
уже существующих. При этом можно использовать модели, разработанные в главе 6. 
Для этого откройте в системе Silverrun-BPM файл модели LEASE.BPM и с помощью 
команды меню File=>Clone сохраните его под другим именем. Можно использовать 
любое имя. Например, файлу модели, рассматриваемой в данной главе, можно 
присвоить имя MAINT.BPM. После того, как вы сохранили файл модели LEASE.BPM 
под другим именем, закройте его и загрузите новую модель. Альтернативным 
вариантом вышеперечисленных действий является использование команды меню 
File=>Save As. Создавая новую модель на основе уже существующей, вы можете 
воссоздать все элементы исходной модели (например, накопители данных, процессы 
и т.д.). 

    Рис. 8.2. Модель процесса эксплуатации объекта недвижимости 

    162 Часть II. Учебный курс 


    Как вы видите, данная модель содержит два накопителя данных, которых не 
было в модели процесса аренды, разработанной в главе 6. Новый накопитель 
EMPLOYEE появился в связи с тем, что эксплуатационные работы выполняются 
рабочими, данные о которых хранятся в этом накопителе. В связи с пожеланием 
нашей вымышленной компании Alladium, нужно сохранить бумажные формы, 
использовавшиеся до внедрения системы RENTMAN. Поэтому понадобилось добавить 
накопитель WORDER, который содержит информацию о нарядах на выполнение работ. 
Так как ни один из этих накопителей не используется в процессе управления 
арендой, то, естественно, их не было в модели, которую мы разработали в главе 6. 
    Кроме этих двух, все остальные накопители данных представленной модели 
аналогичны накопителям модели процесса аренды. Итак, отвечая на вопрос "Какие 
дополнительные элементы необходимы для реализации остальных функций приложения 
RENTMAN?", можно сказать, что нам нужны два дополнительных накопителя EMPLOYEE 
и WORDER вместе с соответствующими процессами и потоками, которые являются 
уникальными для процесса управления эксплуатацией объектов недвижимости. 
    Так же, как и для процесса аренды, необходимо сразу же описать структуры 
данных, чтобы не тратить на это время в дальнейшем. Структуры данных позволяют 
определять для накопителей информацию на уровне атрибутов. В дальнейшем эта 
информация будет использована для разработки атрибутов в ER-диаграммах и 
таблицах реляционной модели. Давайте определим структуры данных для двух новых 
накопителей. Для этого воспользуйтесь командой меню Project=>Data Structures, 
а затем добавьте атрибуты в каждую из новых структур с помощью команды меню 
Data Structure=>Composition. В структуру данных EMPLOYEE добавьте следующие атрибуты. 
    
    Employee Number 
    Employee Name 
    
    В структуру данных WORDER добавьте следующие атрибуты. 
    
    WOrder Number 
    WOrder Start Date 
    WOrder End Date 
    WOrder Employee Number 
    WOrder Property Number 
    WODetail Line Number 
    WODetail Description 
    Work Type Code 
    Work Type Description 
    Work Type Task Duration 
    WOrder Comments 
    
    После определения структур данных, свяжите их с соответствующими 
накопителями, выполнив следующие действия. 
    1. В системе Silverrun-BPM выберите команду меню 
Presentation=>Palettes=>Data Structures, чтобы отобразить список имеющихся 
накопителей. 
    2. С помощью правой кнопки мыши перетащите каждую структуру данных из окна 
Data Structures Palette на соответствующий накопитель. 
    3. В окне Data Structures Palette слева от структур, связанных с 
накопителями, должен появиться символ звездочки. Кроме того, чтобы убедиться в 
корректности связи накопителя со структурой данных, можно дважды щелкнуть 
мышью на соответствующем объекте-накопителе. 

    Сохранение модели 

    После настройки структур данных можно сохранить модель и перейти к 
построению ER-диаграммы. Чтобы сохранить новую модель на диске, выберите 
команду меню File=>Save. Если ваш файл еще не имеет имени, то можно назвать его MAINT.BPM. 
    Для того, чтобы использовать накопители данных и структуры, описанные в 
модели процесса предметной области, в диаграммах "сущность-связь", необходимо 
сначала сделать накопители доступными системе Silverrun-ERX. Это сводится к 
обновлению хранилища моделей, к которым можно получить доступ как из средства 
ВРМ, так и из ERX. Для обновления хранилища выполните следующие действия. 
    1. Выберите пункт меню Util=>WRM Dictionary. В результате система 
Silverrun-BPM перейдет в специальный режим работы с локальным хранилищем 
Silverrun. На экране появится диалоговое окно WRM Dictionary, а в строке меню 
Silverrun-BPM — новый пункт WRM Dictionary. 
    2. Не закрывая диалогового окна, выберите пункт меню WRM Dictionary=>Update 
WRM Dictionary. 

    Глава 8. Ваша первая система клиент/сервер 163 

    3. В появившемся на экране диалоговом окне щелкните на кнопке Update, а 
затем — на кнопке Save (Сохранить), чтобы подтвердить имя, используемое по 
умолчанию для файла отчета. В результате расположенная в памяти копия 
хранилища будет обновлена в соответствии с накопителями и структурами данных 
вашей модели. После подтверждения имени файла отчета щелкните на кнопке ОК, 
чтобы закрыть окно сообщения. 
    4. Выберите команду WRM Dictionary=>Save WRM Dictionary As и подтвердите 
имя MAINT.WRM в качестве нового имени файла хранилища, который в дальнейшем 
можно будет импортировать в Silverrun-ERX. 
    5. Щелкните на кнопке закрытия диалогового окна WRM Dictionary. 
    Теперь на диске хранится как сама модель, так и связанное с ней хранилище, 
и вы можете перейти к разработке ER-диаграммы для процесса управления 
обслуживанием аренды. Закройте программу SilverrunВРМ и запустите программу Silverrun-ERX. 

    Создание модели "сущность-связь" 

    Основным преимуществом программы Silverrun-ERX является возможность 
нормализации связей между объектами при проектировании базы данных. Система 
Silverrun-ERX содержит прекрасные средства поиска и исправления некорректных 
связей, не соответствующих требованиям третьей нормальной формы. Вам остается 
лишь слегка помочь ей с помощью присвоения соответствующих имен атрибутам, 
однако даже необходимость в такой "подсказке" не делает это средство менее 
уникальным среди других систем ER-моделирования. Большинство CASE-средств не 
обладает возможностями выполнения нормализации разрабатываемых моделей баз данных. 
    Вообще-то, можно просто пропустить этап создания диаграммы 
"сущность-связь" и перейти сразу к моделированию логических структур данных. 
Система Silverrun-RDM сможет импортировать накопители данных, созданных с 
помощью системы Silverrun-BPM так же, как и созданных с помощью Silverrun-ERX. 
Однако тогда вы не сможете воспользоваться еще одним преимуществом средства 
Silverrun-ERX — обеспечением целостности связей вашей модели. Выбирайте тот 
способ, который вам больше подходит. Например некоторые пользователи считают 
процесс создания ER-диаграмм излишним и переходят от моделирования процесса 
непосредственно к моделированию логических структур данных. 

    Импортирование накопителей из модели процесса предметной области 

    Для преобразования накопителей данных, описанных в модели процесса 
предметной области, в сущности ER-модели нужно импортировать эти накопители в 
программу Silverrun-ERX. Для этого выполните следующие действия. 
    1. Выберите команду меню Util=>WRM Dictionary, чтобы перевести систему 
Silverrun-ERX в режим работы с локальным хранилищем Silverrun. 
    2. Выберите команду меню WRM Dictionary=>Open WRM Dictionary и в 
открывшемся окне выберите файл хранилища MAINT.WRM, созданный системой Silverrun-BPM. 
    3. Выберите команду меню WRM Dictionary=>Update a Model, а затем в 
появившемся диалоговом окне щелкните на кнопке Update и подтвердите имя, 
используемое по умолчанию для файла отчета. При получении запроса о том, 
связывать ли текущую модель с проектом, который находится в хранилище, 
щелкните на кнопке Yes. В результате накопители и структуры данных, описанные 
в модели процесса предметной области, будут добавлены к имеющейся модели. В 
дальнейшем вы сможете использовать их для создания сущностей ER-модели. 
Щелкните на кнопке ОК, чтобы закрыть окно сообщения. 
    4. Щелкните на кнопке закрытия диалогового окна WRM Dictionary. 
    Теперь накопители доступны в вашей модели и вы можете свободно 
перетаскивать их в пределах области моделирования. Это можно использовать для 
преобразования накопителей в сущности, которые могут быть использованы в вашей 
ER-диаграмме. Для того, чтобы преобразовать накопители в сущности модели, 
выполните следующие действия. 
    1. Выберите пункт меню Presentation=>Palettes=>Component: SR Store, чтобы 
отобразить палитру накопителей, которые были импортированы непосредственно из 
модели процесса предметной области. 
    2. За исключением накопителей LEASE и PROPERTY, которые не входят в модель 
процесса управления эксплуатацией объектов недвижимости, перетащите с помощью 
правой кнопки мыши все накопители данных из палитры в область моделирования. 

    164 Часть II. Учебный курс 


    3. Обратите внимание, что каждая сущность создается в центре модели, 
независимо от того, в каком месте области моделирования вы ее опускаете. В 
результате объекты сущности будут располагаться один над другим. После того, 
как все накопители преобразованы, разместите новые сущности таким образом, 
чтобы они не заслоняли друг друга. 
    4. Щелкните на кнопке закрытия палитры Component: SR Store. На рис. 8.3 
показан внешний вид ER-диаграммы, полученный в результате перечисленных действий. 

    Рис. 8.3. Диаграмма "сущность-связь " на начальном этапе разработки 


    Нормализация модели 

    После того, как вы разместили начальный набор сущностей, можно 
нормализовать полученную ER-модель. Для этого в системе Silverrun-ERX нужно 
выполнить следующие действия. 
    1. Выберите команду меню Expert=>Expert Mode, чтобы перевести систему 
Silverrun-ERX в специальный режим, при котором вы сможете выполнять 
дополнительные функции (например, вызов средств нормализации). 
    2. Выберите команду меню Expert=>Normalize Model, чтобы начать 
нормализацию. При появлении запроса на проведение анализа имен, используемых в 
модели, щелкните на кнопке Yes. 
    3. После того, как будет проведен анализ имен элементов модели, щелкните 
на кнопке ОК в диалоговом окне Analyze Attribute Names. 
    4. На экране появится сообщение о том, что нормализация может существенно 
изменить вашу модель. Чтобы начать процесс нормализации, щелкните на кнопке Yes. 
    Теперь ваша модель нормализована в такой степени, насколько позволяют 
возможности системы Silverrun-ERX. Связи, установленные экспертом 
нормализации, первоначально размещаются в модели одна поверх другой. 
Перетащите их так, чтобы они не перекрывали друг друга. Ваша модель примет 
вид, представленный на рис. 8.4. 
    Обратите внимание, что в модели появились две новых сущности: WODetail и 
Work Type. Для того, чтобы имена этих сущностей согласовались с именами 
остальных объектов модели, щелкните дважды на верхней части каждого из 
объектов новых сущностей и введите их имена в верхнем регистре. В соответствии 
с соглашениями о присвоении имен, описанных в главе 4 "Соглашения", удалите 
пробел из имени Work Type. 

    Глава 8. Ваша первая система клиент/сервер 165 


    Рис. 8.4. Внешний вид модели "сущность-связь" после ее нормализации 

    Вне всякого сомнения, нормализация модели с помощью системы Silverrun-ERX 
позволит вам сэкономить немало времени. Однако, при этом могут возникнуть 
некоторые трудноуловимые проблемы. Вопервых, обратите внимание на связь между 
сущностями WORDER и WORKTYPE. Сущность WORKTYPE связана с количеством строк в 
наряде на работу, а по одному наряду могут быть выполнены несколько различных 
типов работ. Поэтому предположительные изменения, выполненные экспертом 
нормализации, будут некорректны. Чтобы избежать подобной проблемы выполните 
следующие действия. 
    1. Щелкните на связи между объектами WORDER и WORKTYPE, а затем нажмите 
<Delete>. В результате помеченная связь будет удалена. 
    2. Щелкните на каком-либо инструменте работы со связями на панели 
инструментов системы SilverrunERX (предпочтительней использовать инструмент, 
который позволяет работать с диагональными линиями), а затем щелкните 
последовательно на объектах WODETAIL и WORKTYPE. В результате между этими 
двумя объектами появится связь. Обратите внимание на то, что значения 
минимальной и максимальной кардинальности этой связи по умолчанию остаются 
пустыми. Это будет исправлено позже при проверке связности модели. 
    Еще одной проблемой модели является отсутствие связей с сущностью TENANT. 
Эта проблема не является следствием некорректной нормализации средствами 
системы Silverrun-ERX — она проявляется вследствие недостатков структуры 
данных, созданной в ходе моделирования процесса. Модель процесса эксплуатации 
не содержит каких либо ссылок на накопитель данных TENANT со стороны других 
накопителей, в отличие от модели процесса аренды, в которой накопитель TENANT 
ссылается на накопитель LEASE, a накопитель LEASE ссылается на накопитель 
PROPERTY. В модели процесса эксплуатации накопители PROPERTY и LEASE либо были 
описаны без поддержки структур данных, либо вообще не используются. В 
результате накопитель TENANT потерял все связи. 
    С учетом того, что позже вы будете объединять модели данных для процессов 
аренды и эксплуатации, указанная проблема не является настолько серьезной, как 
это может показаться на первый взгляд. Этой проблемы можно избежать простым 
удалением сущности TENANT из модели. Для этого нужно щелкнуть на ней левой 
кнопкой мыши и нажать <Delete> (рис. 8.5). 

    166 Часть II. Учебный курс 


    Рис. 8.5. Внешний вид модели после удаления сущности TENANT 


    Проверка связности 

    После проведения небольшой правки модели можно приступить к проверке 
корректности результатов нормализации связей между сущностями. В процессе 
нормализации вашей модели эксперт настраивал связи между сущностями на 
основании нескольких факторов. Прежде чем продолжать работу, вы должны 
убедиться в корректности результатов работы эксперта нормализации. Для этого 
выполните следующие действия. 
    1. Выберите пункт меню Expert=>Verify Connectivities, чтобы запустить 
эксперта проверки связности, который задаст вам ряд вопросов в соответствии с 
характером связей между объектами вашей диаграммы. 
    2. Щелкните на переключателе All Connectivities в диалоговом окне Verify 
Connectivities и убедившись, что флажок for selected relationships не 
установлен, щелкните на кнопке Verify. 
    3. Вам будут заданы несколько вопросов в последовательности, 
соответствующей связям между сущностями. В дальнейшем программа Silverrun-ERX 
использует ваши ответы на поставленные вопросы для настройки связности модели. 
Отвечайте на вопросы в соответствии с табл. 8.1. 

    Таблица 8.1. Ответы на вопросы, предлагаемые экспертом связности 

    Вопрос												Ответ 

    In general is it necessary for a "WORDER" to have an "EMPLOYEE" to exist?	Yes 
    In general can one "WORDER" have many "EMPLOYEE"?					No 
    In general is it necessary for an "EMPLOYEE" to have a "WORDER" to exist?	No 
    In general can one "EMPLOYEE" have many "WORDER"?					Yes 
    In general is it necessary for a "WORDER" to have a "WODETAIL" to exist?	No 
    In general can one "WORDER" have many "WODETAIL"?					Yes 
    In general is it necessary for a "WODETAIL" to have a "WORDER" to exist?	Yes 
    

    Глава 8. Ваша первая система клиент/сервер 167 


    Продолжение табл. 8.1 

    Вопрос													Ответ 

    In general can one "WODETAIL" have many "WORDER"?						No 
    In general is it necessary for a "CALL" to have a "WORDER" to exist?		No 
    In general can one "CALL" have many "WORDER"?						No 
    In general is it necessary for a "WORDER" to have a "CALL" to exist?		No 
    In general can one "WORDER" have many "CALL"?						Yes 
    In general is it necessary for a "WORKTYPE" to have a "WODETAIL" to exist? 	No 
    In general can one "WORKTYPE" have many "WODETAIL"?					Yes 
    In general is it necessary for a "WODETAIL" to have a "WORKTYPE" to exist?	Yes 
    In general can one "WODETAIL" have many "WORKTYPE"?					No 

    После того, как вы ответите на все поставленные вопросы, эксперт связности 
системы Silverrun-ERX соответствующим образом настроит связи между сущностями 
модели. Обратите внимание на то, что кардинальность связей между сущностями 
WORDER и WODETAIL уже указана (рис. 8.6). 

    Рис. 8.6. Внешний вид модели после проверки связности 


    Определение идентификаторов сущностей 

    Теперь все связи между сущностями модели определены корректно, и вы можете 
приступить к созданию идентификаторов для каждого класса сущностей. Для того 
чтобы отобразить атрибуты, которые однозначно идентифицируют каждую сущность, 
выполните следующие действия. 
    1. Выберите команду меню Expert=>Search for Identifiers, чтобы запустить 
эксперт идентификаторов сущностей. 

    168 Часть II. Учебный курс 


    2. Убедитесь, что в появившемся диалоговом окне сброшен флажок for 
selected entities, и щелкните на кнопке Search. 
    Перед тем, как приступить непосредственно к поиску, эксперт отобразит 
несколько подсказок, которые позволят вам определить идентификаторы для всех 
атрибутов. Используя информацию, приведенную в табл. 8.2 для определения 
идентификатора каждой сущности, щелкните на нужном идентификаторе, а затем на 
кнопке Continue. При выборе идентификатора он перемещается в верхнюю часть 
списка атрибутов, а в столбце Id. диалогового окна рядом с ним появляется 
символ звездочки. 

    Таблица 8.2. Идентификаторы сущностей ER-диаграммы 

    Сущность	Идентификатор 

    CALL		Call Number 
    EMPLOYEE	Employee Number 
    WODETAIL	WORDER identifier, WODetail Line Number 
    WORDER		WOrder Number 
    WORKTYPE	Work Type Code 

    Обратите внимание на составной идентификатор сущности WODETAIL. Каждый 
наряд на работу может иметь несколько строк, описывающих работу, планируемую к 
выполнению. Каждая из этих строк будет пронумерована, для чего предназначен 
атрибут WODetail Line Number. Тем не менее, нумерации строк не достаточно для 
того, чтобы однозначно определить во всех случаях каждую из сущностей WODETAIL 
(например, все наряды будут иметь строку с номером 1). Для этого нужно 
добавить к номеру строки номер самого наряда. Этот номер является 
идентификатором сущности WORDER. Используя комбинацию номера наряда на работу 
и номера строки, можно однозначно описать любой экземпляр сущности WODETAIL. 
Таким образом, WODETAIL является сущностью, зависящей от WORDER, потому что ее 
идентификатор содержит идентификатор сущности WORDER. Система Silverrun-ERX 
обозначает эту зависимость посредством выделения полужирным шрифтом 
соответствующего показателя кардинальности в модели. 
    Как легко заметить, эксперт идентификаторов системы Silverrun-ERX 
размещает атрибут идентификатора WORDER под атрибутом WODetail Line Number в 
списке, который составляет идентификатор сущности WODETAIL. Может показаться, 
что в физической реализации базы данных столбец номера наряда на работу должен 
предшествовать столбцу номера строки. Однако вас не должно это очень 
беспокоить. Когда средство Silverrun-RDM генерирует сценарий SQL, необходимый 
для создания базы данных, то оно должным образом упорядочивает все атрибуты в 
соответствии с ограничениями первичного ключа WORDER. Помещение идентификатора 
сущности WORDER в крайнюю слева позицию в первичном ключе WODETAIL приведет к 
созданию индекса WODETAIL, который будет основан на заданном порядке 
следования этих двух столбцов. Это значит, что позиция идентификатора WORDER 
не имеет значения до тех пор, пока не будут использованы ограничения 
первичного ключа WODETAIL. В этом случае индексы будут создаваться корректно. 

    На рис. 8.7 показана модель, использующая первичные ключи. 


    Сохранение модели 

    Работа над вашей ER-диаграммой практически завершена. Теперь можно 
сохранить эту модель и преобразовать ее в формат, поддерживаемый системой 
Silverrun-RDM. Для этого выполните следующие действия. 
    1. Выберите команду меню File=>Save, чтобы сохранить модель на диске 
(назовем ее MAINT.ERX). Для описания модели перед сохранением вы можете 
использовать команду меню Model=>Model Description. На рис. 8.8 показана модель 
с ее описанием. 
    2. Закройте программу Silverrun-ERX и запустите утилиту Silverrun ERX-RDM. 
Эта утилита используется для преобразования модели, разработанной в системе 
Silverrun-ERX, в формат, совместимый с системой Silverrun-RDM. 

    Глава 8. Ваша первая система клиент/сервер                         169 


    Рис. 8.7. Внешний вид модели после определения первичных ключей 

    Рис. 8.8. Окончательный вид вашей диаграммы "сущность-связь" 


    170 Часть II. Учебный курс 


    3. Находясь в системе Silverrun ERX-RDM, выберите команду меню 
File=>Transform ERX->RDM. 
    4. Выберите файл, содержащий ER-модель, которую вы создали для процесса 
эксплуатации объектов недвижимости. Он должен иметь имя MAINT.ERX. 
    5. Когда появится приглашение на выбор имени выходного файла, оставьте 
используемое по умолчанию имя MAINT.RDM. Этот файл будет совместим с 
программой Silverrun-RDM. 
    6. Закройте программу Silverrun ERX-RDM и запустите Silverrun-RDM. 

    Моделирование логической структуры данных 

    Теперь, когда диаграмма "сущность-связь" готова и преобразована в формат, 
совместимый с SilverrunRDM, можно приступать к разработке модели реляционной 
структуры данных. Здесь основное внимание при моделировании уделяется 
физической реализации базы данных. Происходит переход от описания абстрактных 
понятий (например, сущностей) к описанию физических (например, таблиц). 
Конечным результатом работы является сценарий SQL, который используется для 
создания объектов, описанных в модели логической структуры данных. В 
дальнейшем я покажу вам, как запустить этот сценарий для создания таблиц 
приложения RENTMAN и других объектов базы данных для выбранной СУБД. В случае 
приложения RENTMAN такой СУБД является система InterBase. 

    Объединенная реляционная модель процесса аренды 

    Первое, что нужно сделать, приступая к построению модели логической 
структуры данных (LDM — Logical Data Model) для процесса эксплуатации объектов 
аренды, — это объединить новую модель с логической моделью процесса управления 
арендой. Такое объединение позволит иметь единую модель структуры данных для 
всей базы данных RENTMAN. При этом отпадает необходимость создавать вручную в 
LDM процесса эксплуатации объекты, используемые в LDM процесса аренды. 
    К счастью, система Silverrun-RDM содержит средства, разработанные 
специально для объединения различных моделей. Для того чтобы объединить модели 
процессов аренды и эксплуатации в единую реляционную модель, выполните 
следующие действия. 
    1. Щелкните на кнопке закрытия окна, чтобы закрыть модель, созданную 
системой Silverrun-RDM по умолчанию. 
    2. Щелкните на кнопке Open панели инструментов Silverrun-RDM и выберите 
файл MAINT.RDM, созданный утилитой Silverrun ERX-RDM. 
    3. Появится сообщение о том, что данный файл модели, соответствует более 
ранней версии программы Silverrun-RDM. Щелкните на кнопке Yes. 
    4. Теперь вы должны выбрать СУБД модели. Щелкните на кнопке Avail. Target 
Sys. и выберите из раскрывающегося списка пункт INTBAS=>INTBAS41.TYP, а затем 
щелкните на кнопке ОК. В результате в качестве целевой СУБД будет выбрана 
последняя поддерживаемая системой Silverrun-RDM версия СУБД InterBase — версия 
4.1, а ваша модель будет открыта в окне Silverrun-RDM. 
    5. Выберите команду меню Schema=>Schema Description, смените описание на 
Relational Data Model for Maintenance Process и сохраните вашу модель. 
    6. Щелкните на кнопке Open еще раз и откройте модель реляционной структуры 
данных, созданную в главе б, для процесса аренды. Файл этой модель должен 
называться LEASE.RDM. 
    7. Выберите команду меню Util=>lntegrate, чтобы запустить эксперта 
объединения системы SilverrunRDM. 
    8. В диалоговом окне Schema Integration укажите реляционную модель аренды 
в качестве источника (Source Schema), а реляционную модель эксплуатации в 
качестве назначения (Dest. Schema). Щелкните на кнопке Integrate. 
    9. Появится сообщение о том, что модель процесса аренды станет подчиненной 
схемой в модели процесса эксплуатации. Это сообщение не имеет особого значения 
— щелкните на кнопке ОК, чтобы продолжить работу. 
    10. В диалоговом окне Integration Report щелкните на кнопке Save 
(Сохранить), чтобы подтвердить использование установленного по умолчанию имени 
файла отчета. 
    11. В диалоговом окне Target systems в списке СУБД выберите пункт 
InterBase и щелкните на кнопке ОК. 

    Глава 8. Ваша первая система клиент/сервер 171 


    12. В диалоговом окне Tables щелкните на кнопке Link by Name, чтобы 
связать объекты двух моделей с одинаковым именем. В данном случае — это 
таблица CALL. Щелкните на кнопке ОК, чтобы продолжить работу. 
    13. В диалоговом окне Connectors щелкните на кнопке ОК, чтобы подтвердить 
информацию о типе соединительных линий, используемых по умолчанию. После этого 
эксперт объединит модель процесса аренды с моделью процесса эксплуатации. 
    14. Перейдите в окно, содержащее LDM процесса эксплуатации, — вы увидите 
модель процесса аренды, добавленную к модели процесса эксплуатации. Возможно, 
вам понадобится изменить расположение элементов в модели, чтобы они не 
перекрывали друг друга, а связи между ними четко просматривались. 
    15. Выберите команду меню Schema=>Schema Description и сократите название 
новой модели до Relational Data Model. Все изменения имени проекта 
отображаются в строке заголовка окна. 
    16. Сохраните новую модель под именем RENTMAN.RDM (не затирайте файл 
MAINT.RDM). На основании этой новой реляционной модели вы будете создавать 
базы данных RENTMAN. На рис. 8.9 представлен внешний вид новой модели. 

    Рис. 8.9. Модель логической структуры данных системы RENTMAN 

    Возможность объединения различных реляционных моделей — одно из самых 
мощных свойств пакета Silverrun. Вы не сможете найти подобных возможностей ни 
в одном другом CASE-средстве. Если бы их не было и в системе Silverrun, вам 
пришлось бы осуществлять объединение вручную, а это достаточно утомительный 
процесс, в котором часто допускаются ошибки. 
    Особый случай — это объединение двух различных представлений таблицы CALL. 
В модели процесса аренды таблица CALL связана с таблицей PROPERTY, а в модели 
процесса эксплуатации — с таблицей WORDER. Обратите внимание, что в новой 
модели сохраняются обе связи. 
    Таблица CALL содержит столбец с названием Property Number, оставшийся от 
исходной модели процесса эксплуатации. Этот столбец был включен в модель 
потому, что вымышленная компания Allodium использовала в бумажных формах 
регистрации звонков номера объектов собственности. Однако теперь между 
таблицами CALL и PROPERTY установлена связь по внешнему ключу и вы можете, 
нисколько не рискуя, удалить лишний столбец. Он уже не нужен, так как связь по 
внешнему ключу все равно приведет к созданию столбца Property Number в 
физической базе данных. В этом случае нужно щелкнуть дважды 

    172 Часть II. Учебный курс 


объекте таблицы CALL, выбрать столбец Property Number (его параметры Coded 
Name и Domain не имеют значений, как показано на рис. 8.10) и щелкнуть на 
кнопке Delete. После этого можно закрыть диалоговое окно Table Columns, 
щелкнув на кнопке ОК. 

    Рис. 8.10. Удаление столбца Property Number из таблицы CALL 

    Таблица WORDER также имеет лишний столбец WOrder Property Number. Удалите 
его так же, как это делалось в таблице CALL. Позже мы установим связь по 
внешнему ключу между таблицами WORDER и PROPERTY с помощью инструмента системы 
Silvermn-RDM Connector. 

    Определение столбцов 

    Мы объединили LDM процессов аренды и эксплуатации в одну реляционную 
модель для использования в приложении RENTMAN. Теперь необходимо определить 
домены для таблиц, представленных в модели эксплуатации. Для модели аренды все 
параметры доменов таблиц уже были определены ранее. Вы можете убедиться в 
этом, дважды щелкнув на какой-либо из таблиц, представленных на рис. 8.10. 
Модель эксплуатации содержит следующие уникальные таблицы: WORDER, WODETAIL, 
WORKTYPE и EMPLOYEE. Для всех этих таблиц нужно установить следующие параметры 
доменов: тип столбца, его длину, правила объединения или ограничения и другие 
параметры. Эти параметры используются программой Silverrun-RDM для генерации 
сценариев SQL. 
    Дважды щелкните на каждой из таблиц модели эксплуатации и установите 
параметры доменов, руководствуясь табл. 8.3. 

    На заметку 
    Возможно, вы обратили внимание на то, что столбцы Description в таблицах 
CALL, WODETAIL и WORKTYPE очень похожи. Я не хочу убеждать вас в необходимости 
создания для этих столбцов домена, однако при разработке баз данных вы должны 
обращать внимание на подобные моменты. Объединение общих типов данных в 
центральных доменах сбережет немало времени и позволит избежать проблем при 
изменении описаний связанных столбцов. В случае использования отдельного 
домена для описания нескольких столбцов вы можете изменять все эти столбцы 
одновременно, изменяя соответствующий домен. 

    Глава 8. Ваша первая система клиент/сервер 173 

    Обратите внимание на возможность использования домена TComments для 
определения столбца WOrder Comments таблицы WORDER. Объединение LDM процесса 
аренды с другими моделями выгодно в том смысле, что вы можете получать доступ 
к пользовательским доменам, изначально определенным в модели аренды. 

    Таблица 8.3. Информация о доменах столбцов для таблиц модели эксплуатации 

Таблица	Столбец		Домен		Длина		Десятичные  Значение по		Возможность
							знаки	 			умолчанию		использования 
														значения NULL 

EMPLOYEE	Employee Number	INTEGER	-		-		нет			нет     
		Employee Name	CHARACTER	30		-		нет			нет 
WORDER	WOrder Number	INTEGER	-		-		нет			нет 
		WOrder Start 	DATE		-		-		нет			нет 
		Date	
		WOrder End Date	DATE		-		-		нет			да 
		WOrder Comments	TComments	-		-		нет			да 
WODETAIL	WODetail Line 	INTEGER	-		—		-			нет 
		Number
		WODetail 		CHARACTER	30		-		—			да 
		Description
WORKTYPE	Work Type Code	INTEGER	-		-		-			нет 
		Work Type 		CHARACTER	30		-		—			нет 
		Description
		Work Type Task	DECIMAL	5		2		—			нет 
		Duration
    
    Генерирование кодированных имен 
    
    После описания всех столбцов можно приступать к генерированию кодированных 
имен для элементов вашей модели. Кодированные имена — это имена элементов 
модели, учитывающие соглашения и ограничения выбранной СУБД. Программа 
Silverrun-RDM удаляет пробелы, обрезает длинные имена и выполняет другие 
подобные операции с именами, используемыми в модели. Обратите внимание, что 
выбранные вами исходные имена останутся нетронутыми — кодированные имена 
хранятся отдельно. При генерации сценария SQL, с помощью которого будут 
создаваться реальные объекты базы данных, можно определить, какие имена нужно 
использовать для элементов модели — обычные или кодированные. Можно также 
управлять способом отображения кодированных имен при графическом представлении 
модели в системе Silverrun-RDM с помощью команды меню Presentation=>Displayed 
Descriptor. Для того, чтобы сгенерировать кодированные имена, выполните 
следующие действия. 
    1. Выберите команду меню Schema=>Generate Coded Names. 
    2. В появившемся окне Coded Names Generation щелкните на кнопке Specify и 
установите значения Maximum Length и Nb. of characters used from the beginning 
of each word in the name равными 30. Создаваемые вами объекты будут 
использоваться в базе данных СУБД InterBase, поэтому 30 — это наиболее 
подходящее значение. Увеличив длину сокращения от 3 до 30 символов, вы 
предотвратите сокращение слов в именах элементов до трех символов. 
    3. Оставьте все остальные параметры неизменными и щелкните на кнопке ОК, 
чтобы вернуться в диалоговое окно Coded Names Generation. Щелкните на кнопке Generate. 
    Чтобы просмотреть новые кодированные имена, дважды щелкните на любой из 
таблиц вашей модели. Для того, чтобы просмотреть кодированные имена для 
отдельного столбца, дважды щелкните на этом столбце в диалоговом окне Table Columns. 
    После генерации кодированных имен элементов модели нужно отредактировать 
имена, сгенерированные для столбцов таблиц WORDER, WODETAIL, EMPLOYEE и 
WORKTYPE. Удалите название таблицы из левой части кодированного имени каждого 
из столбцов, за исключением столбцов, включенных в первичный 

    	174      Часть II. 
	Учебный KVDR 

ключ. Эти префиксы добавлялись в качестве вспомогательной информации для 
эксперта нормализации Silverrun-ERX, и они больше не нужны. Название 
WODetail_Description можно сократить например, до Description, а имя 
WODetail_Line_Nurriber оставить без изменений, так как этот столбец является 
первичным ключом. Сократив имена, вы облегчите работу с приложением, которое 
будет использовать эти имена. Это позволит с уверенностью использовать столбцы 
для создания внешних ключей в других таблицах, а первичные ключи останутся 
уникальными для всей базы данных. 

    Установка связей между таблицами 

    После того, как вы импортировали вашу модель из Silverrun-ERX, большинство 
связей между таблицами уже установлено. Однако учитывая то, что объекты 
недвижимости никогда не описывались в ERдиаграмме для процесса эксплуатации, 
еще не установлена ни одна связь между таблицами WORDER и PROPERTY. Вполне 
естественно, что у компании Allodium Properties может появиться необходимость 
включить информацию об объектах недвижимости в наряды, выдаваемые рабочим. 
Несмотря на то, что эта информация должна выбираться через таблицу CALL, не 
все наряды выписываются по звонкам арендаторов. Например, ознакомившись с 
описанием использования объекта недвижимости, менеджер по эксплуатации может 
принять решение о ремонте крыши данного объекта. В результате будет выдан 
наряд на работу, никак не связанный со звонком какого-либо арендатора. 
    Решить эту проблему можно с помощью реляционной связи между таблицами. Для 
этого нужно щелкнуть на инструменте Angular Connector панели инструментов 
системы Silverrun-RDM, а затем щелкнуть на таблице PROPERTY и связать ее с 
таблицей WORDER. Между этими двумя таблицами сразу же появится связь с 
назначенными по умолчанию параметрами (рис. 8.11). К счастью, в данном случае 
связь, устанавливаемая системой Silverrun-RDM, является корректной и не 
нуждается в модификации. Учитывая последовательность щелчков на таблицах, 
система считает таблицу, на которой был сделан первый щелчок, родительской, а 
вторую — дочерней. 

    Рис. 8.11. Связать таблицы можно с помощью инструмента Angular Connector 


    Генерирование внешних ключей 

    После установки всех связей между таблицами вашей модели можно 
сгенерировать внешние ключи. Вместо автоматического создания внешних ключей 
при связывании таблиц друг с другом, система Silverrun-RDM предоставляет 
возможность генерирования внешних ключей для всех таблиц модели одновременно. 

    Глава 8. Ваша первая система клиент/сервер 175 

При генерировании внешних ключей столбцы родительской таблицы ставятся в 
соответствие со столбцами их дочерних таблиц. При физическом проектировании 
внешний ключ обычно создается на основе столбца (или столбцов) дочерней 
таблицы, который ссылается на первичный ключ родительской таблицы. Для 
генерирования внешних ключей выполните следующие действия. 
    1. Выберите команду меню Schema=>Foreign Keys=>Generate. 
    2. В появившемся диалоговом окне щелкните на кнопке Generate. 
    3. Щелкните на кнопке Save (Сохранить), чтобы подтвердить имя файла, 
используемого по умолчанию для отчета о генерации внешних ключей. 
    В таблицах реляционной модели появится несколько новых столбцов. В 
зависимости от выбранного стиля условного отображения, каждый внешний ключ 
может предваряться буквами FK (рис. 8.12). 

    Рис. 8.12. Модель после добавления внешних ключей 

    Теперь ваша модель практически завершена. Осталось только сгенерировать 
сценарий SQL, необходимый для создания объектов, описанных в этой модели. 

    Проверка целостности модели 

    Перед генерированием сценария SQL для создания объектов базы данных 
необходимо проверить целостность модели. Это можно сделать с помощью 
специального средства системы Silverrun-RDM. 
    1. Выберите команду меню Schema=>Verify Integrity. 
    2. В появившемся на экране диалоговом окне выберите переключатель Maximum 
Level of Verification и щелкните на кнопке Verify. 
    3. Подтвердите указанное по умолчанию имя файла отчета (verify), щелкнув 
на кнопке Save (Сохранить). 
    4. Появится сообщение об отсутствии ошибок в вашей модели. Могут появиться 
какие-либо предупреждения, но никаких серьезных проблем с моделью быть не должно. 
    5. Если вы хотите просмотреть отчет о целостности модели, сгенерированный 
средством Silverrun-RDM, выберите команду меню Util=>View a Text File и укажите 
имя отчета (по умолчанию Verify), а затем щелкните на кнопке Open (Открыть). 

    176                          Часть II. Учебный курс 


    Генерирование DDL 

    После завершения разработки модели и проверки ее целостности можно 
приступать к генерированию операторов DDL, необходимых для реализации вашего 
проекта в базе данных. В системе Silverrun эта операция заключается в 
генерации сценария SQL, который вы сможете запустить для создания объектов 
вашей базы данных. 
    Кроме оператора CREATE TABLE для всех таблиц вашей модели, система 
Silverrun-RDM также включит в сценарий оператор CONNECT для организации связи 
с базой данных, в которой будут размещены новые объекты. Silverrun-RDM берет 
имя базы данных из кодированного имени текущей схемы, поэтому лучше установить 
кодированное имя для базы данных до генерирования DDL. Благодаря этому, 
оператор CONNECT, сгенерированный RDM, будет корректно осуществлять соединение 
с базой данных. Чтобы установить кодированное имя схемы, выполните следующие действия. 
    1. Выберите команду меню Schema=>Schema Description, чтобы открыть 
диалоговое окно Schema Description. 
    2. В строке Coded Name введите полный путь к базе данных InterBase, в 
которой вы хотите разместить новые объекты. Я использовал путь 
С:\DATA\RENTMAN\RENTMAN.GDB. 
    3. Щелкните на кнопке ОК, чтобы закрыть диалоговое окно. 
Теперь можно сгенерировать сценарий SQL. Для этого выполните следующие действия. 
    1. Выберите команду меню Schema=>Generate DDL. 
    2. В появившемся на экране диалоговом окне щелкните на переключателе Coded Name. 
    3. Щелкните на кнопке Generate. 
    4. В запросе на ввод имени файла наберите *.SQL и нажмите <Enter>. Будет 
отображен список всех сценариев SQL, а используемое по умолчанию расширение 
файла тхт изменится на SQL. Введите имя файла RENTMAN.SQL и щелкните на 
кнопке Save (Сохранить). В результате будет сгенерирован сценарий SQL. 
    Теперь у вас есть модель и соответствующий ей сценарий SQL. Сохраните 
модель и закройте программу Silverrun-RDM. В листинге 8.1 представлено 
содержимое сценария RENTMAN.SQL. 

    Листинг 8.1. Сценарий языка DDL (в данном случае в качестве DDL 
используется SQL), сгенерированный системой Silverrun-RDM по реляционной 
модели данных приложения RENTMAN 

    CONNECT "С:\DATA\RENTMAN\RENTMAN.GDB" USER " " PASSWORD " "; 

    CREATE DOMAIN TAddition AS CHARACTER(20) NOT NULL CHECK 
    (VALUE IN ('Deerfield', 'Firewheel', 'Legacy Hills', 'Switzerland 
     Estates', 'Sherwood',  'Rockknoll')) ; 

    CREATE DOMAIN TAddress AS CHARACTER(30) NOT NULL; 

    CREATE DOMAIN TCity AS CHARACTER(30) NOT NULL CHECK (VALUE IN ('Oklahoma 
     City', 'Norman', 'Edmond', 'Dallas', 'Richardson', 'Piano')); 

    CREATE DOMAIN TComments AS VARCHAR(SO); 

    CREATE DOMAIN TPhone AS CHARACTER(12) NOT NULL; 

    CREATE DOMAIN TPropertyNo AS INTEGER NOT NULL; 

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

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

    CREATE DOMAIN TSchoolDistrict AS CHARACTER(20) NOT NULL CHECK 
    (VALUE IN ('Putnam City', 'Oklahoma City', 'Richardson', 'Edmond', 'Garland', 'Dallas',
    'Piano')); 

    CREATE DOMAIN TState AS CHARACTER(2) NOT NULL CHECK 


    Глава 8. Ваша первая система клиент/сервер 177 


    (VALUE IN ('OK', 'TX'));

    CREATE DOMAIN TTenantNo AS INTEGER NOT NULL;

    CREATE DOMAIN TYesNo AS CHAR(l) NOT NULL CHECK
    (VALUE IN ('Y', 'N')) ;

    CREATE DOMAIN TZip AS CHARACTER(10) NOT NULL;

    CREATE TABLE EMPLOYEE ( 
      Employee_Number INTEGER NOT NULL, 
      Name CHARACTER(30) NOT NULL,
      PRIMARY KEY (Employee_Number)
    );
    
    CREATE TABLE PROPERTY (   
      Property_Number    TPropertyNo NOT NULL,
      Address            TAddress NOT NULL,
      City               TCity NOT NULL,
      State              TZip NOT NULL,
      Zip                TZip NOT NULL,
      Addition           TAddition NOT NULL,
      SchoolDistrict    TSchoolDistrict NOT NULL,
      Rent               TYesNo NOT NULL,
      Deposit            NUMERIC(5, 2) NOT NULL,
      LivingAreas        TRooms NOT NULL,
      BedRooms           TRooms NOT NULL,
      BathRooms          TRooms NOT NULL,
      GarageType         TRooms NOT NULL,
      CentralAir         TYesNo NOT NULL,
      CentralHeat        TYesNo NOT NULL,
      GasHeat            TYesNo NOT NULL,
      Refigerator        TYesNo NOT NULL,
      Range              TYesNo NOT NULL,
      Dishwasher         TYesNo NOT NULL,
      PrivacyFence       TYesNo NOT NULL,
      LastLawnDate       DATE,
      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    TAddress NOT NULL,
     EmployerCity       TCity NOT NULL,
     EmployerState      TState NOT NULL,
     EmployerZip        TZip NOT NULL,
     HomePhone          TPhone NOT NULL,
     WorkPhone          TPhone NOT NULL,
     ICEPhone           TPhone NOT NULL,
     Comments           TComments,
     PRIMARY KEY (Tenant_Number)
   );

   CREATE TABLE WORKTYPE (   
    Work_Type_Code     INTEGER NOT NULL,
    Description        CHARACTER(30) NOT NULL,
    TaskDuration       DECIMAL(5, 2) NOT NULL,
    PRIMARY KEY (Work_Type_Code)
  );

  CREATE TABLE LEASE (   
   Lease_Number       INTEGER NOT NULL,



178 Часть II. Учебный курс


   BeginDate          DATE NOT NULL,
   EndDate            DATE NOT NULL,
   MovedInDate        DATE,
   MovedOutDate       DATE,
   Rent               TRent NOT NULL,
   PetDeposit         NUMERIC(5, 2),
   RentDueDay         SMALLINT NOT NULL,
   LawnService        TYesNo NOT NULL,
   Comments           TComments,
   Property_Number    TPropertyNo NOT NULL,
   Tenant_Number      TTenantNo NOT NULL,
   PRIMARY KEY (Lease_Number),
   CONSTRAINT FK_TENANT1
     FOREIGN KEY (TenantJMumber)
       REFERENCES TENANT,
   CONSTRAINT FK_PROPERTY2
     FOREIGN KEY (Property_Number)
       REFERENCES PROPERTY
  );

  CREATE TABLE WORDER (   
   WOrder_Mumber      INTEGER NOT NULL,
   StartDate          DATE NOT NULL,
   EndDate            DATE,
   Comments           TComments,
   Property_Number    TPropertyNo NOT NULL,
   Employee_Number    INTEGER NOT NULL,
   PRIMARY KEY (WOrderJMumber),
   CONSTRAINT FK_PROPERTY3
     FOREIGN KEY (Property_Number)
       REFERENCES PROPERTY,
   CONSTRAINT 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_Mumber      INTEGER,
   PRIMARY KEY (Call_Number),
   CONSTRAINT FK_PROPERTY5
     FOREIGN KEY (Property_Number)
       REFERENCES PROPERTY,
   CONSTRAINT FK_WORDER6
     FOREIGN KEY (WOrderJMumber)
       REFERENCES WORDER
  );

  CREATE TABLE WODETAIL (   
    WODetail_Line_Number INTEGER NOT NULL,
    Description          CHARACTER(30),
    Work_Type_Code       INTEGER NOT NULL,
    WOrder_Number        INTEGER NOT NULL,
    PRIMARY KEY (WOrder_Mumber, WODetail_LineJSIumber) ,
    CONSTRAINT FK_WORKTYPE7
      FOREIGN KEY (Work_Iype_Code)
        REFERENCES WORKTYPE,
    CONSTRAINT FK_WORDER8
      FOREIGN KEY (WOrder_Mumber)
        REFERENCES WORDER
  );


  Глава 8. Ваша первая система клиент/сервер 179

    Обратите внимание на то, что сценарий еще не готов к выполнению, так как 
оператор CONNECT содержит неправильное имя пользователя и пароль. Запустите 
Delphi и в окне редактирования исходного текста откройте файл сценария 
RENTMAN.SQL. Замените строку, содержащую оператор CONNECT, на следующую. 
CONNECT "С:\DATA\RENTMAN\RENTMAN.GDB" USER "SYSDBA" PASSWORD "masterkey"; 
После внесения изменений сохраните файл сценария и закройте Delphi. 

    Создание базы данных 

    Теперь, когда у вас есть готовый сценарий SQL, можно приступать к созданию 
базы данных RENTMAN. Для того, чтобы создать базу данных в СУБД InterBase, в 
которой будут размещаться объекты базы данных RENTMAN, выполните следующие действия. 
    1. Запустите сервер InterBase, если он еще не запущен. Вполне вероятно, 
что запуск сервера будет производиться на локальной машине. Для этого откройте 
приложение InterBase Server 4.2, расположенное в папке InterBase 4.2. При 
работе в Windows NT 4.0 и Windows 95 вы можете получить доступ к папке 
InterBase 4.2 через приложение Explorer (Проводник). При работе в Windows NT 
3.51 найдите группу InterBase 4.2 и дважды щелкните на пиктограмме InterBase 
Server 4.2, чтобы запустить сервер. 
    2. Создайте каталог на компьютере, используемом в качестве сервера базы 
данных, в котором будет размещаться новая база данных. На моей машине этот 
каталог называется C:\DATA\RENTMAN. 
    3. Запустите утилиту InterBase windows ISQL и выберите пункт меню 
File=>Create Database. 
    4. В строке Database Name введите полный путь к создаваемому файлу базы 
данных, например C:\DATA\RENTMAN\RENTMAN.GDB. Указанное имя должно 
соответствовать имени, введенному в строке Coded Name диалогового окна Schema 
Description программы Silverrun-RDM. 
    5. Укажите имя пользователя и пароль в соответствующих строках ввода. По 
умолчанию используются имя SYSDBA и пароль masterkey. Регистр букв имеет значение. 
    6. Щелкните на кнопке ОК, чтобы создать базу данных. После небольшой 
задержки утилита ISQL создаст базу данных и автоматически подключится к ней. 
    Теперь можно выполнить сценарий SQL, созданный в системе Silverrun-RDM. 
Для этого выполните следующие действия. 
    1. В окне утилиты ISQL выберите команду меню File=>Run an ISQL Script и 
укажите имя сценария, сгенерированного в системе Silverrun-RDM. 
    2. Щелкните на кнопке Open (Открыть), чтобы выполнить сценарий. 
    3. В запросе на сохранение результатов выполнения сценария в файле 
щелкните на кнопке No (Нет). В этом случае после выполнения сценария 
произойдет возврат в окно утилиты ISQL. 
    4. После небольшой задержки утилита ISQL отобразит сообщение об удачном 
выполнении сценария. Теперь можно выйти из ISQL. 

    Подведем итог 

    Поздравляю! Вы только что создали базу данных RENTMAN. Начав с простых 
концепций, отображающих назначение и функции приложения RENTMAN, вы 
разработали полностью нормализованную полнофункциональную базу данных 
архитектуры клиент/сервер. 

    Остальные функции приложения RENTMAN 

    Как это часто бывает при разработке баз данных, беглый обзор новой базы 
данных RENTMAN показывает, что для реализации третьей и четвертой основных 
функций не требуется применения каких-либо специальных методов. Эти функции 
(генерация счетов и информации об объектах недвижимости) можно реализовать на 
основании уже готовой базы данных в виде отчетов приложения RENTMAN. 
Предположим, что генерация счетов будет заключаться в ежемесячном выводе на 
печать напоминания арендатору о необходимости выплаты арендной платы. Все, что 
нам нужно в этом случае, — получить доступ к перечню арендаторов, их адресам, 
срокам оплаты и величине арендной платы. Все указанные элементы содержатся в 
таблицах TENANT, PROPERTY и LEASE. 

    180 Часть II. Учебный курс 

    Предоставление информации об объектах недвижимости соответствует выводу 
сроков аренды и проводимых на этих объектах эксплуатационных работ. В главе, 
12 "Отчеты", вы увидите, что приложение RENTMAN может предоставлять информацию 
о каждом объекте недвижимости посредством отчетов. Для того, чтобы реализовать 
эти функции, приложению RENTMAN не требуется описание каких-либо 
дополнительных процессов или объектов. 
    Конечно же, на основе описанных процессов можно создать и другие процессы. 
Например, для того, чтобы осуществлять регулярное обслуживание объектов 
недвижимости, компания должна накапливать материалы и инструменты, необходимые 
для проведения определенных работ. Для того, чтобы управлять этим имуществом и 
оплачивать его, можно составить диаграмму абсолютно независимого процесса. 
Точно так же, с генерацией счетов арендаторам можно связать внутреннюю систему 
бухгалтерского учета. Эта система будет дополнять возможности основной системы 
при печати счетов, проверяя проведение оплат, создавая баланс прошлых платежей 
и т.д. Я не хотел бы углубляться в эти вспомогательные процессы. Как я уже 
отмечал, вы, в основном, будете иметь дело с главными функциями приложения RENTMAN. 

    Резюме 

    В этой главе вы спроектировали и реализовали базу данных InterBase 
архитектуры клиент/сервер для приложения RENTMAN. Вы определили назначение и 
основные функции приложения, а затем спроектировали и создали объекты базы 
данных, необходимые для реализации этих функций. При этом вы основывались на 
информации, полученной в главе 6, о построении моделей процессов предметной 
области, ER-диаграммах, моделях реляционных структур данных и физических схемах 
баз данных. Теперь вы знакомы со всеми средствами создания баз данных 
архитектуры клиент/сервер. 

    Что дальше... 

    В следующей главе мы начнем создание программных объектов Delphi, 
необходимых для реализации основных функций приложения RENTMAN. Вы построите 
полнофункциональное приложение базы данных архитектуры клиент/сервер на 
основании объектов баз данных, созданных в данной главе. 

    Глава 8. Ваша первая система клиент/сервер 181 