    ГЛАВА 6

    Проектирование базы данных архитектуры клиент/сервер 

    В последующих трех главах я буду использовать инструментальные средства, 
созданные компанией Computer Systems Advisors Research (CSA). Выбор средств 
именно этой компании является личным выбором автора и не связан с какими бы то 
ни было рекомендациями компании Borland. Эта и две последующие главы 
представляют собой описание процесса разработки приложения архитектуры 
клиент/сервер с точки зрения программиста. В них вы ознакомитесь с принципами 
теории баз данных и проектирования приложений, а также узнаете, как применять 
эти принципы на практике. Эти главы предназначены, прежде всего, для тех 
разработчиков, которые не имеют необходимых фундаментальных знаний и большого 
опыта разработки приложений баз данных. Если вы уже знакомы с принципами 
построения реляционных баз данных и разработки приложений, можете просто 
создать все описываемые в этой главе объекты базы данных и сразу перейти к 
главе 8, "Ваша первая система клиент/сервер". 

    Общий подход к теме 

    Применяемый мною подход к вопросу проектирования баз данных может 
отличаться от того, что вам приходилось встречать в других книгах по этой 
теме. Вместо пространных обсуждений теории баз данных, я стараюсь быть 
прагматиком и смотреть на все с практической точки зрения. Не думаю, что 
копание в деталях исторической статьи Кодда (E.F. Codd) или разбор 
математических принципов нормализации баз данных улучшит книгу и вообще будут 
здесь уместными. Существует немало книг в которых подобные вопросы рассмотрены 
до мельчайших подробностей. Я же постараюсь сосредоточится только на том, что 
поможет вам в разработке и создании реальных приложений. Сначала я ознакомлю 
вас с некоторыми теоретическими посылками, а затем мы перейдем к воплощению 
этих теоретических принципов в реальных приложениях. 
    Самым трудным делом при написании технических книг является нахождение 
удачного сочетания необходимых теоретических сведений и практических вопросов. 
Если автор книги чересчур увлекается практикой, то книга превращается в 
дорогое руководство, так как она отвечает на вопросы "Как?", но не дает ответа 
на вопросы "Для чего?" С другой стороны, книга, перегруженная абстрактными 
концепциями, часто оказывается бесполезной с практической точки зрения. Люди 
чаще всего покупают книги о компьютерных технологиях для того, чтобы научиться 
выполнять какие-то операции или решать практические задачи. Если книга не в 
состоянии принести читателю сколько-нибудь ощутимую пользу в его практической 
деятельности, то, скорее всего, такая книга обречена на провал. 
    Таким образом, идеальной является книга, автору которой удастся избежать 
отмеченных выше крайностей. Именно к этой цели я и стремился, работая над 
книгой в целом и над данной главой, в частности. Хотя для иллюстрации 
излагаемых концепций я избрал определенные инструментальные средства, вместе с 
тем я постарался дать вам необходимые теоретические сведения, на которых 
базируются описываемые практические приемы. Надеюсь, что здесь вы найдете 
ответы и на вопросы "Как?", и на вопросы "Для чего?" 

    90 Часть I. Основы 


    Основные этапы разработки баз данных 

    Процесс разработки приложений баз данных архитектуры клиент/сервер условно 
можно разделить на определенные этапы. Любой разработчик так или иначе 
выполняет все эти этапы, однако для того, чтобы добиться желаемого результата, 
нужно следовать им неукоснительно, какое бы приложение вы не разрабатывали. 
    Итак, процесс создания приложений баз данных архитектуры клиент/сервер 
можно разделить на следующие пять этапов. 
    Q Определение назначения и круга задач приложения. 
    Q Проектирование функциональности приложения и процессов, необходимых для 
реализации этой функциональности. 
    Q Воплощение проекта в реальное приложение путем создания необходимых 
программных объектов и объектов базы данных. 
    О Тестирование приложения на предмет соответствия его назначению и 
правильного функционирования. 
    Q Настройка и установка приложения. 
    Если быть менее многословным, можно кратко обозначить суть каждого их этих 
этапов следующим образом. 
    Q Анализ. 
    Q Проектирование. 
    О Разработка. 
    Q Тестирование. 
    Q Совершенствование. 

    На заметку 
    Этап разработки традиционно назывался этапом программирования. Однако в 
наше время — время повсеместного распространения средств визуального 
проектирования, программирование может является лишь составной частью этапа, 
который я назвал этапом разработки. Термином "разработка" можно обозначить 
программирование, визуальное проектирование или генерацию приложения, в 
зависимости от используемых средств разработки. 

    В этой главе и в других главах книги я постоянно буду ссылаться на 
перечисленные выше этапы создания приложений с помощью только что приведенных 
кратких названий. Во-первых, это позволит не загромождать книгу чересчур 
пространными формулировками, а во-вторых, поможет быстрее усваивать излагаемый 
материал, так как эти короткие названия хорошо знакомы разработчикам 
программного обеспечения. Я надеюсь, что этот нехитрый прием быстро выработает 
у вас ощущение, что разработка приложений баз данных архитектуры клиент/сервер 
в принципе не отличается от разработки любых других приложений. Так оно и есть 
в действительности — существуют методики, с помощью которых вы можете добиться 
любых нужных вам результатов. 

    Подробнее о пяти этапах 

    Чтобы вы ни создавали, будь то программа, дом или картина, — вы 
обязательно должны выполнить определенные этапы, каждый из которых влияет на 
результат в целом. При разработке приложения тот факт, что оно предназначено 
для работы с базами данных, не имеет практически никакого значения. Да и сами 
перечисленные выше этапы — это не молитва, которую надо заучить и повторять по 
нескольку раз в день. Все, что я собираюсь вам рассказать, рождено интуицией и 
здравым смыслом. Упомянутые пять этапов возникли не как некое учение или 
догма, а из практического опыта, который появляется у любого человека, 
занятого созданием чего бы то ни было. 
    Что касается собственно процесса создания приложений баз данных, то на 
первых порах вы можете сосредоточиться только на трех первых этапах. Именно 
при выполнении этих трех этапов и закладываются основы будущего приложения, 
поэтому на этих этапах выполняется большая часть работы по созданию приложений 
баз данных архитектуры клиент/сервер. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 91 

    Анализ 

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

    Проектирование 

    Второй этап — проектирование приложения. На этом этапе концептуальная 
модель, разработанная в ходе анализа, воплощается в виде логической структуры 
приложения. Для всех функций приложения, выделенных на предыдущем этапе, 
разрабатываются логические элементы приложения и базы данных. Логическая 
структура приложения должна показывать, как будут реализованы те или иные 
функции приложения. Именно на этом этапе определяются компоненты приложения и 
базы данных, которые нужно реализовать в соответствии с концептуальной 
моделью, разработанной на этапе анализа. Одним из методов решения этой задачи 
является моделирование логических структур данных и диаграммы "сущность-связь" 
(ER — Entity-Relationship). В конце этого этапа вы должны иметь детальные 
функциональные схемы и структуры данных для всех уровней создаваемого 
приложения архитектуры клиент/сервер. 

    Разработка 

    На третьем этапе создания приложения базы данных — этапе разработки, 
логическая схема приложения воплощается в реальные объекты. При этом 
логические структуры данных реализуются в виде объектов базы данных, а 
функциональные схемы — в формы, программный код и другие программные объекты приложения. 
    Остальные два этапа — тестирование и совершенствование, большей частью 
относятся к эксплуатации приложения, а не к его созданию. Учитывая это, я не 
буду уделять им много внимания. Единственное, о чем считаю необходимым 
предупредить: выполнение этих этапов часто приводит к повторению описанных 
выше этапов, например в связи с обнаружением ошибок или изменениями требований 
пользователей к приложению. Позже мы еще остановимся на некоторых вопросах, 
связанных с тестированием и совершенствованием приложений. 

    Проблемы создания систем клиент/сервер 

    Процесс создания приложений баз данных архитектуры клиент/сервер 
достаточно прост и понятен интуитивно. По большому счету, он ничем не 
отличается от процесса создания любого другого приложения, независимо от того, 
использует ли оно базы данных. Может быть такой подход в некоторой степени 
является упрощенным, но именно так я смотрю на задачу разработки приложений 
баз данных архитектуры клиент/сервер. 
    Тем не менее, объективно существуют некоторые проблемы, проявляющиеся в 
случае прямого переноса общих принципов разработки приложений на архитектуру 
клиент/сервер. Эти проблемы связаны с самой природой систем клиент/сервер, 
состоящих их двух частей — серверной и клиентной. Более того, объекты 
серверной части являются главными объектами приложения. Это свойство систем 
клиент/сервер обуславливает их преимущество перед обычными приложениями, так 
как объекты серверной части должны существовать еще до завершения разработки 
всей системы в целом. С другой стороны, приложение клиент/сервер не будет 
корректно функционировать при наличии проблем в базе данных. Такая 
двойственность природы систем клиент/сервер в значительной степени усложняет 
задачу создания надежных приложений — приходится выполнять анализ, 
проектирование и разработку не только по отношению к самому приложению, но и 
по отношению к базе данных. Кроме того, в процессе разработки систем 
клиент/сервер есть еще одна достаточно сложная задача — обеспечение 
взаимодействия серверной и клиент-

    92 Часть I. Основы 

ной части приложения. Иногда эта задача становится задачей номер один. 
Если к этому добавить проблемы, связанные с коммуникационным оборудованием, 
драйверами и т.п., то становится ясно, почему многих разработчиков отпугивает 
само выражение "клиент/сервер". 
    На сегодняшний день пока еще не придуман способ, с помощью которого можно 
было бы избавиться от всех этих проблем. CASE-средства хороши, но приложения 
должны по-прежнему создаваться разработчиками, а не проектировщиками. Системы 
клиент/сервер — это сложные, многоуровневые программы, поэтому вполне 
естественно, что создавать их могут только специалисты, претендующие на звание 
экспертов. К счастью для вас, эта книга поможет вам в приобретении всех 
знаний, необходимых для выполнения такой сложной работы. 
    Эта и следующая главы продемонстрируют все пять этапов создания приложений 
архитектуры клиент/сервер с практической точки зрения. Эту главу я посвятил 
анализу, проектированию и разработке баз данных. В главе 7, "Проектирование 
приложения архитектуры клиент/сервер", рассказывается об этих этапах 
применительно к приложениям. Кроме того, в главе 7 рассказывается о 
тестировании и совершенствовании приложений баз данных. 
    Нет необходимости рассказывать по отдельности об этапе тестирования баз 
данных и приложений, работающих с этими базами данных, так как при 
тестировании практически невозможно отделить тестирование приложение от 
тестирования, базы данных. Кроме того, даже если все объекты базы данных 
созданы правильно, приложение, использующее такую базу данных, все равно 
должно подвергаться тестированию. 
    Точно так же, нет необходимости в отдельном описании этапа 
совершенствования приложения и базы данных. Так как приложение и база данных 
образуют единое целое, то усовершенствовать их также можно в комплексе. 
Поэтому важно понимать, как выполняется совершенствование законченного 
приложения, включая и базу данных, с которой оно работает. Этот этап 
достаточно важен, поэтому глава 7 рассказывает о тестировании и 
совершенствовании баз данных и приложений баз данных, которые должны 
выполняться по завершении этапа разработки. 

    Многоуровневость систем клиент/сервер 

    Как мне кажется, лучшим способом ощутить многогранность процесса создания 
систем клиент/сервер, является выполнение трех основных этапов создания 
системы отдельно для каждого ее уровня. Другими словами, нужно сначала 
выполнить этапы анализа, проектирования и разработки базы данных, а затем 
повторить все эти этапы для самого приложения. Если в системе имеются какие-то 
промежуточные уровни, связанные, например, с использованием аппаратных средств 
или особенностями операционной системы, то к ним нужно применить такой же 
подход. Именно такая методика предлагается в данной книге. 
    Разработка системы по данной методике обеспечит наличие объектов базы 
данных еще до разработки объектов приложения или вспомогательных объектов, 
что, в свою очередь, приведет к сокращению времени разработки. Как я уже 
отмечал, хотя нельзя полностью отделить базу данных от приложения, но, тем не 
менее, создание элементов базы данных перед созданием приложения и 
вспомогательных элементов является устоявшейся практикой. 

    Прикладная теория баз данных 

    Изучая эту и следующую главы, вы обязательно заметите, что я рассматриваю 
проектирование баз данных и проектирование приложений как взаимосвязанные 
процессы. На мой взгляд, это очевидно, хотя некоторые так не считают. С 
практической точки зрения процесс проектирования базы данных является 
фундаментом по отношению к процессу проектирования приложения, использующего 
эту базу. Таким образом, один процесс, безусловно, влияет на другой. Мне еще 
ни разу не приходилось разрабатывать базу данных, с которой не работало бы в 
той или иной форме какое-либо приложение. 
    Нужно помнить, что база данных — не цель, а только средство ее достижения, 
предназначенное для обслуживания запросов пользователя. Точно так же, 
клиентное приложение функционирует в качестве посредника между пользователем и 
сервером базы данных, поэтому оно также является лишь средством для 
обслуживания пользователя. И только совместная работа клиентной и серверной 
части приложения может дать пользователю то, что он хотел бы получить от 
системы клиент/сервер. 
    В этой главе я ознакомлю вас с тем, какие подходы я использую при 
разработке приложений баз данных архитектуры клиент/сервер. Материал 
основывается на теории баз данных с упором на практическую сторону этой 
теории, применяемой при создании реальных приложений. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 93 

    На заметку 
    Эта глава посвящена исключительно вопросам разработки систем клиент/сервер 
— в ней нет ничего, что можно было бы применить к локальным СУБД, таким как 
Paradox, dBASE и Access. Полноценные системы клиент/сервер имеют очень мало 
общего с локальными СУБД, поэтому подходы, применяемые к проектированию 
приложений архитектуры клиент/сервер очень сильно отличаются от подходов, 
используемых в проектировании локальных баз данных. Так как эта книга 
посвящена вопросам создания систем клиент/сервер, ее материал относится 
только к СУБД такого типа.                                       ., 

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

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

    На заметку 
    В части "Учебный курс" данной книги создание приложения RENTMAN будет 
продолжено. Более подробная информация приведена в главе 8. 

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

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

    Сформулировав назначение приложения, можно перейти к определению его 
основных функций. Что должно делать приложение для выполнения своего 
назначения? Постарайтесь ограничится только самыми важными задачами. Хорошо 
при этом набросать какую-нибудь схему, чтобы лучше представить картину в 
целом. Перечисленные функции должны соответствовать формулировке назначения 
приложения, не противореча и не расширяя ее. Формулируя функции, используйте 
тот же подход, что и при формулировке назначения приложения. 
    Система RENTMAN обслуживает управление арендой недвижимости. 
    Q Система регистрирует и хранит договоры аренды. 
    Q Система отслеживает выполнение текущих эксплуатационных работ. 

    94 Часть I. Основы 

    а Система генерирует счета для арендаторов. 
    О Система выдает информацию об аренде каждого объекта недвижимости. 
    Убедитесь, что вы перечислили все основные функции приложения и при этом 
не увлеклись чрезмерной детализацией. Кроме того, проверьте, чтобы 
сформулированные вами функции не перекрывались, т.е. чтобы две разные функции 
не предназначались для решения одной и той же задачи. 

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

    Первое, что вы наверняка откроете для себя в процессе проектирования баз 
данных, — это то, что данный предмет выходит далеко за рамки физического 
создания базы данных. Вам придется заниматься разработкой концептуальной 
модели, созданием диаграмм "сущность-связь" и моделированием логических 
структур данных. Постепенно продвигаясь от частного к общему, вы пройдете все 
шаги, начиная от моделирования предметной области и заканчивая определением 
столбцов конкретных таблиц вашей базы данных. Вы постепенно будете проникать в 
мельчайшие подробности работы создаваемого приложения, пока не почувствуете, 
что можете воплотить эти знания в самом приложении. Такое продвижение 
невозможно без систематического преобразования концепций, которые вы 
намереваетесь воплотить в жизнь, в реальные программные элементы. 
    Однако, с другой стороны, в действительности процесс проектирования базы 
данных не так уж и труден, как может показаться на первый взгляд. Как я уже 
говорил, он начинается с моделирования и заканчивается созданием физических 
объектов, образующих базу данных. В этой главе я упрощу процесс проектирования 
базы данных до трех основных стадий. 
    1. Опишите предметную область и протекающие в ней процессы, реализация 
которых необходима для выполнения основных функций приложения. 
    2. Создайте диаграммы, показывающие связи между этими процессами. 
    3. Создайте логическую структуру базы данных, реализующую эти связи и процессы. 
    На рис. 6.1 показана взаимосвязь между пятью этапами создания приложения и 
перечисленными выше стадиями. После формулировки назначения приложения и 
определения его основных функций, анализ и проектирование концентрируются 
вокруг этих трех стадий. Работа начинается с моделирования процессов 
предметной области, соответствующих определенным ранее функциям, продолжается 
созданием диаграмм, отображающих связи, необходимые для поддержки этих 
процессов, и заканчивается преобразованием ER-диаграмм и выделенных процессов 
предметной области в модель логических структур данных. В итоге мы получаем 
логическую структуру приложения, которая будет использована на этапе разработки. 
    Работа по анализу и проектированию, начиная от создания концептуальной 
модели и заканчивая моделированием логических структур данных, не обязательно 
должна выполняться вручную. Для таких целей существуют CASE-средства, которые 
могут значительно облегчить работу по созданию систем клиент/сервер. 

    CASE-средства 

    Прежде чем приступить к обсуждению CASE-средств, хочу высказать свою точку 
зрения на их использование. Лично я не считаю, что CASE-средства способны 
облегчить разработку любого приложения и что они, тем более, могут заменить 
тщательное планирование или программирование как ремесло. С другой стороны, 
так как CASE-средства ориентированы на работу с компьютером, то помощь, 
которую они могут оказать в работе, большей частью зависит от вашего умения с 
ними обращаться — как и любые другие программы, CASE-средства умеют лишь 
выполнять ваши команды, а не угадывать ваши желания. 
    Я также сомневаюсь, что CASE-средства, претендующие на полную 
автоматизацию всех процессов создания приложений, развиваются в правильном 
направлении. Они чаще не помогают, а мешают работе, пытаясь автоматизировать 
то, что нельзя или не нужно автоматизировать. В результате разработчики и 
проектировщики тратят больше времени на устранение последствий чрезмерной 
автоматизации, чем до того, как они стали использовать такие средства 
"автоматизации". Джеймс Рамбаух (James Rambaugh), эксперт в области 
моделирования данных и соавтор книги Unified Method for Object-Oriented 
Development, высказал по этому поводу следующую мысль: "Хорошее CASE-средство 
не должно автоматизировать все 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 95 

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

    Рис. 6.1. Схема, отображающая пять этапов процесса создания приложения 

    Как и при использовании любых средств, призванных экономить время, в 
случае CASE-средств нужно исходить из принципа разумной достаточности. Если он 
нарушен, значит нужно отказаться от такого средства и поискать какое-нибудь 
другое, которое лучше справляется со своими задачами. 
    Роль, которую CASE-средство должно играть в разработке баз данных 
архитектуры клиент/сервер можно сравнить с ролью, которую играет рейсфедер и 
карандаш на рабочем столе чертежника. С одной стороны, оно должно быть ничем 
иным как инструментом. С другой стороны, каждый инструмент требует наличия 
определенных навыков в его использовании. CASE-средства не могут думать за вас 
или планировать за вас методы устранения проблем, возникающих при разработке. 
Они просто помогают вам решать задачи, которые вы, возможно, могли бы решить и 
без их использования, но с большими затратами времени и усилий. К выполнению 
этой роли в моделировании приложений архитектуры клиент/сервер CASEсредства 
подходят как нельзя лучше. Однако, какое бы конкретное средство вы не 
использовали, для того чтобы создать хорошее приложение вам все равно 
понадобятся знания в области проектирования баз данных и опыт работы с той или 
иной СУБД. 
    С учетом объема работы, который нужно проделать в процессе проектирования 
базы данных, можно понять, чем руководствуются разработчики, выбирая те или 
иные CASE-средства. Сегодняшние CASE-средства прошли долгий путь и уже 
освободились от тех недостатков, которые еще совсем недавно отталкивали от них 
потенциальных пользователей. Вне всякого сомнения, сегодня проще и быстрее 
воспользоваться CASE-средствами, чем выполнять все по-старинке, вручную. 

    96 Часть I. Основы 

    CASE-средства, позволяя нам моделировать объекты до их реального 
воплощения, предоставляют тем самым возможность выполнить анализ 
взаимодействия элементов еще до начала их создания. Кроме того, CASE-средства 
помогают выполнять техническую работу по проектированию, а также предупреждают 
о потенциальных проблемах в принимаемых вами решениях. Создавая модель, 
соответствующую вашим замыслам, вы тем самым даете CASE-средству информацию, с 
помощью которой оно может помочь вам в работе. Ниже перечислены некоторые 
области моделирования, где применение CASE-средств особенно уместно. 

    Моделирование процессов 

    Приложение состоит из взаимосвязанных процессов, выполняющих основные 
функции данного приложения. Моделирование процессов предметной 
области включает разработку диаграмм таких процессов и связей между ними. 
Существуют CASE-средства, специально предназначенные для такого моделирования, 
например Process Analyst системы S-Designor (новая версия называется PowerDesigner) 
компании Powersoft, Silverrun, ВРМ компании CSA и др. 

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

    Диаграммы "сущность-связь" (ER-диаграммы) большинство проектировщиков и 
аналитиков считает незаменимым средством. С их помощью осуществляется 
отделение логического представления данных от их физической реализации. 
ER-диаграммы помогают обращаться с элементами данных в терминологии 
представляемых ими объектов реального мира. Для ER-моделирования также 
существует немало средств, в качестве примеров которых можно привести ERwin 
компании Logicworks и ER/1 компании Embarcadero. 

    Моделирование реляционных структур данных       

   Несмотря на всю популярность ER-моделирования, оно является только составной 
частью процесса моделирования реляционных структур данных. ER-диаграммы — это 
только один из множества методов представления реляционных баз данных. 
Существует много CASE-средств, возможности которых существенно превышают 
построение ER-диаграмм. Такие средства предназначены для разработки полных 
логических схем баз данных. В качестве примера таких систем можно назвать 
средство Data Architect уже упоминавшейся системы S-Designor и Silverrun-RDM 
компании CSA. 
    В этой главе я расскажу, как с помощью CASE-средств моделировать реальные 
приложения и преобразовывать эти модели в объекты баз данных и приложений. Как 
показано на рис. 6.2, физические объекты создаются на основе логических 
моделей. Логические модели данных, в свою очередь, строятся на основе 
ER-диаграмм, а последние получаются в результате моделирования процессов 
прикладной области. Наконец, модели этих процессов реализуют основные функции 
приложения. Продвижение от определения назначения приложения и его основных 
функций до его физической разработки представляет собой эволюционный процесс, 
отражающий степень нашего понимания всех деталей работы создаваемого приложения. 

    Рис. 6.2. CASE-средства помогают трансформировать идеи в реальные объекты 
баз данных и приложений 


    Какое CASE-средство является лучшим? 

    Я не знаю, существует ли вообще CASE-средство, которое можно назвать самым 
лучшим. Конечно же, некоторые средства популярнее других, однако популярность 
сама по себе ничего не означает — мне приходилось работать с системами, в 
которых были реализованы очень интересные идеи, но при этом сами системы были 
практически никому не известны. Что касается CASE-средств, используемых для 
проектирования баз данных, то я обычно выбираю инструментальное средство, 
руководствуясь размером моделируемого приложения. Если передо мной стоит 
задача разработки небольшого приложения, для чего выделяется небольшой 
промежуток времени, я предпочитаю систему ER/1 компании Embarcadero, а не 
популярную ERWin компании Logicworks. Хотя система ER/1 недавно появилась в 
ряду CASE-средств этого ранга, однако мне понравился ее интерфейс и простота 
использования этой программы. Кроме того, она 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 97 
    4 Delphi 3 и системы клиент/сервер 

достаточно быстра, особенно при решении задач перестройки уже существующих 
баз данных. Наконец, как и система ERWin, ER/1 соответствует стандарту 
разработки диаграмм IDEF1X. Исходя из всего вышесказанного, я считаю 
CASE-средство ER/1 самым производительным среди систем такого класса. 
    Для крупномасштабных проектов я предпочитаю использовать пакет 
CASE-средств компании Computer Systems Advisors (CSA), объединенных названием 
Silverrun. Этот пакет состоит из четырех основных модулей: ВРМ (Business 
Process Modelling) — система моделирования процессов предметной области; ERX 
(Entity Relationship eXpert) — система создания ER-диаграмм; RDM (Relational 
Data Modelling) — система моделирования реляционных структур данных и WRM 
(Window Repository Management) — система управления хранением информации. 
    У вас может возникнуть вопрос, почему я предпочел систему Silverrun, а не 
ее ближайших конкурентов (S-Designor, ERWin и т.д.). На то есть целый ряд 
причин. Во-первых, в отличие от многих других CASE-средств, система Silverrun 
поддерживает широкий спектр платформ. Нужно работать с Silverrun в системе 
Solaris? Нет проблем! Хотите Windows NT? Пожалуйста! А как насчет платформы 
Macintosh? К вашим услугам! При разработке проектов масштаба предприятия 
всегда хочется иметь под рукой средство, которое поддерживало бы не только 
всевозможные СУБД, но и различные аппаратные и программные платформы. Все 
многообразие платформ, поддерживаемых Silverrun, предоставляет пользователю 
возможность не переходить на новую операционную систему лишь для того, чтобы 
спроектировать базу данных, а решать поставленную перед ним задачу на тех 
средствах, к которым он привык. 
    Еще одним достоинством системы Silverrun является то, что она поддерживает 
Delphi. Средство Silverrun-RDM обеспечивает уникальный режим работы, названный 
разработчиками системы "Delphi work mode". В этом режиме Silverrun-RDM 
позволяет разрабатывать наборы атрибутов, которые затем сохраняются в словарях 
данных Delphi и, таким образом, могут использоваться при создании приложений. 
Так как сейчас большую часть работы я выполняю с помощью Delphi, то поддержка 
этой среды разработки системой Silverrun мне очень помогает. 
    Кроме того, система Silverrun корректно разделяет процесс создания 
ER-диаграмм и процесс моделирования реляционных структур данных. Многие 
проектировщики считают, что эти два процесса — одно и то же. Хотя ER-диаграммы 
действительно показывают связи между сущностями базы данных, они, тем не 
менее, вторичны по отношению к самим данным и предназначены только для 
визуального их представления. Создание ER-диаграмм — это составная часть 
моделирования логических структур данных, а не отдельный процесс. 
    Еще одним неоспоримым преимуществом системы Silverrun является ее цена. С 
одной стороны, она сопоставима с ценой таких средств, как S-Designor и ERWin, 
а с другой стороны, за эти деньги вы получаете такие возможности, которыми 
чаще всего обладают только системы высшего класса, такие как ADW или System 
Engineer. Если говорить о деньгах, то соотношение эффективность/стоимость у 
системы Silverrun очень высокое. 

    Совет 
    На прилагаемом к данной книге компакт-диске находится демонстрационная 
версия пакета Silverrun, в которую включены системы Silverrun-ERX и 
Silverrun-DRM (система Silverrun-BPM отстутствует). Если у вас еще нет этой 
системы, то для изучения этой и последующих глав данной книги вам нужно 
установить эту демонстрационную версию. Кроме того, систему можно получить 
через Internet no адресу www.silverrun.сот. 

    После установки демонстрационной версии можно обратится в компанию 
Computer Systems Advisors (тел. 1-800-537-4262) и получить ключевой код. Этот 
код на время снимет ограничения, которые налагаются на демонстрационную версию 
программы. Так как некоторые из моделей, приведенные в данной книге, 
достаточно сложны, то при попытке их создания с помощью демонстрационной 
версии вы столкнетесь с ограничениями. Поэтому я настоятельно рекомендую 
связаться с компанией CSA и получить ключевой код. 
    В связи с тем, что средства пакета Silverrun предназначены для работы на 
разных платформах, первое, на что вы обратите внимание — это их немного 
необычный пользовательский интерфейс. Действительно, средства Silverrun не 
полностью соответствуют стандарту интерфейса CUA-системы, к которому вы, 
возможно, привыкли в приложениях Windows. С другой стороны, разработчики 
пакета создали для всех средств единый, универсальный интерфейс, который не 
изменяется при переходе от одной платформы к другой. Независимо от того, в 
какой операционной системе вы используете Silverrun — Solaris или Windows NT, 
— все средства пакета будут выглядеть и работать одинаково. Хотя иногда такой 
подход проявляется в несколько необычных приемах работы с системой, однако, на 
мой взгляд, кроссплатформенность средств Silverrun с лихвой компенсирует эти 
небольшие недостатки. 

    98 . Часть I. Основы 


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

    Давайте вернемся к собственно предмету моделирования. Сформулировав 
назначение и функции приложения, можно приступать к моделированию процессов 
предметной области создаваемого приложения. Я помогу вам проследовать шаг за 
шагом по всем стадиям такого моделирования при разработке приложений баз 
данных архитектуры клиент/сервер. Моделирование процессов предметной области 
переходит в разработку диаграмм "сущность-связь", а затем — в моделирование 
логических структур данных. На этом заканчиваются этапы анализа и 
проектирования и начинается этап собственно разработки базы данных, в течение 
которого вы реализуете проект базы данных путем создания ее объектов. Завершив 
создание базы данных, можно переходить к разработке приложения, 
предназначенного для работы с этой базой данных. 
    Модель процессов предметной области (business process model) показывает 
связи между четырьмя основными элементами: процессами, внешними объектами, 
накопителями и потоками данных. Для уточнения связей между этими основными 
элементами используются спецификаторы, ресурсы и структуры данных. В табл. 6.1 
даны определения всех элементов такой модели и показана их связь с другими 
элементами. 

    Таблица 6.1. Элементы модели процессов предметной области 

    Элемент              Определение 

    Процесс (process) 
    Задача, полностью реализуемая приложением или организацией. Процессы 
определяются в терминах операций, выполняющихся над ресурсами. Примерами 
процессов могут быть прием на работу служащих, рассылка счетов, учет и 
обработка жалоб клиентов и т.д. 
    Внешний объект (external entity) 
    Физическое лицо, подразделение организации или другой объект, являющийся  
внешним по отношению к описываемому подразделению или приложению, но при 
этом взаимодействующий с ним. Примерами внешних объектов могут быть клиент, 
арендатор, орган власти, рынок и т.п. 
    Накопитель (store)
    Совокупность данных, создаваемая, используемая или изменяемая моделируемой              
системой. Примерами накопителей являются учетные записи клиентов, бухгалтерские 
счета, главная книга, паспорт объекта недвижимости и т.д. 
    Поток (flow)       
    Предметы или данные, перемещаемые между внешними объектами, процессами и 
накопителями. Примерами потоков могут быть информация о клиентах, доставка заказов, 
курьерская почта, заявки на обслуживание и т.д. 
    Ресурс (resource)   
    Элемент моделируемой системы, используемый тем или иным способом каким-либо 
процессом. Примерами ресурсов являются сервер базы данных, стример, менеджер по 
персоналу, офисное оборудование и т.п. 
    Спецификатор (qualifier)
    Нечто уточняющее сущность внешнего объекта, потока, процесса или накопителя.           
Например, спецификатор может показывать, что заявки на обслуживание обычно 
принимаются по телефону или информация о приеме на работу служащих рассылается по 
факсу 
    Структура данных (data structure)
    Подробное описание данных, хранящихся в накопителе. Структуры данных перечисляют 
все атрибуты содержимого накопителя 

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

    На заметку 
    Использование CASE-средств не является обязательным условием для 
выполнения задач моделирования, представленных в этой главе. CASE-средства 
являются хорошим подспорьем при выполнении работ такого рода, однако это не 
означает, что вы не сможете обойтись без них. Я лично знаком с некоторыми 
очень опытными проектировщиками, которые по-прежнему используют ручку и бумагу 
и при этом добиваются очень хороших результатов. Если CASE-средства вам не 
нравятся — работайте так, как вы привыкли. Важно помнить, что формализация 
процесса моделирования, используемая CASE-средствами, помогает избежать 
наиболее широко распространенных ошибок и уменьшить вероятность недостаточной 
проработки тех или иных вопросов. Однако вам ничто не сможет помешать 
заниматься моделированием, не прикасаясь к CASE-средствам. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 99 


    Работа с пакетом Silverrun 

    На заметку 
    При запуске демонстрационной версии пакета Silverrun на экране появляется 
сообщение об ошибке. Если вы проигнорируете это сообщение, щелкнув на кнопке 
ОК, система запустится, но количество элементов в разрабатываемых моделях 
будет ограничено. Некоторые из моделей, представленные в данной книге, 
используют количество объектов, превышающее ограничение демонстрационной 
версии. Как я уже упоминал, чтобы на время избавиться от этого ограничения, 
нужно обратиться в компанию CSA за ключевым кодом. 

    Ниже перечислены некоторые советы по работе со средством Silverrun-BPM. 
    Q При запуске системы в левой части окна появляется панель инструментов, 
содержащая самые важные средства, используемые в процессе моделирования (рис. 
6.3). Чаще всего вы будете обращаться к средствам, представленными правым 
рядом кнопок этой панели инструментов. 
    Q Все меню средств пакета Silverrun организованы по одному принципу. 
Команды подменю Presentation появляются также при щелчке правой кнопкой мыши. 
С помощью этих команд можно настроить вид элементов, отображаемых на экране. 
    Q Я рекомендую настроить сетку системы Silverrun, чтобы облегчить операцию 
выравнивания элементов. Для этого выберите команду Presentation=>Grid и в 
появившемся диалоговом окне Grid Spacing установите флажки Grid Shown и Grid 
Active. Настройте шаг по вертикальной и горизонтальной осям в соответствии с 
вашими вкусами (я использую 0,5 см), а затем щелкните на кнопке ОК. После 
этого на экране появится сетка, по линиям которой вы сможете выравнивать 
объекты. Шаг сетки будет установлен в соответствии с выбранными вами 
значениями. (Для изменения единицы измерения шага используйте команду 
Edit=>Preferences=>Unit Type.) 
    Q Прежде чем приступать к моделированию, нужно выбрать тип нотации. 
Существует несколько видов формализованных нотаций моделирования процессов. 
Silverrun-BPM поддерживает нотации Gane-Sarson, Merise, Yourdon-DeMarco и 
Ward-Mellor. Кроме того, в Silverrun применяется собственная нотация — 
Datarun. Изменить текущую нотацию можно с помощью команды 
Presentation=>Notation=>Preset Notation. Кроме того, вы можете разработать 
собственную нотацию на основе любой из стандартных нотаций, поддерживаемых 
Silverrun. Тип выбранной нотации влияет на вид панели инструментов. Лично 
я предпочитаю нотацию Ward-Mellor.         
    Q Настроив все параметры, сохраните текущую пустую модель в качестве 
шаблона. Впоследствии, создав новую модель, откройте шаблон и тут же сохраните 
новую модель под другим именем (команда File=>Save As). Это поможет не 
тратить время на настройку параметров системы при создании новых моделей. 

    Начало моделирования процессов прикладной области 

    Для демонстрации преобразования функций в процессы я вернусь к нашему 
приложению RENTMAN. Как вы помните, мы сформулировали назначение системы 
следующим образом: 
    "Система RENTMAN обслуживает управление арендой недвижимости". 
    Затем мы выделили главные функции приложения RENTMAN. 
    Q Система регистрирует и хранит договоры аренды. 
    Q Система отслеживает выполнение текущих эксплуатационных работ. 
    Q Система генерирует счета для арендаторов. 
    Q Система выдает информацию об аренде каждого объекта недвижимости. 
    Моделирование похоже на плавание — чтобы научиться, нужно войти в воду. 
Если вы не можете назвать себя экспертом в области моделирования данных, то, 
приступив к работе, быстро поймете, что моделирование — процесс нелинейный. 
Невозможно показать прямой и последовательный путь, продвигаясь по которому от 
формулирования назначения приложения можно прийти к полнофункциональной 
модели. Моделирование требует значительного интеллектуального труда и дает 
более хорошие результаты при итерационном подходе. Приобретя некоторый опыт, 
вы убедитесь, что одним из основных методов работы при моделировании является 
метод проб и ошибок. 
    Для создания модели процессов, соответствующих функциям приложения, 
давайте начнем с первой основной функции проектируемой системы RENTMAN, т.е. с 
регистрации и хранения договоров аренды. Как я уже говорил, реальная работа 
над приложением начнется во второй части книги, поэтому данная задача не 
отнимет много времени. 

    100 Часть I. Основы 

    Рис. 6.3. Панель инструментов средства Silverrun-BPM 

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

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 101 

    • Информация об арендаторе, полученная во время составления договора, 
сохраняется оператором. 
    • Менеджер по аренде ведет учет действующих договоров. 
    Теперь давайте приступим к разработке модели процесса управления 
договорами аренды. 

    Внешние объекты 

    Запустив систему Silverrun-BPM, выберите пункт File=>New, чтобы создать 
новую модель (или откройте шаблон модели и сохраните его под новым именем, как 
описано выше). Выберите команду Project=>Project Description и в строке 
Project Name открывшегося диалогового окна введите имя проекта — RentMan 
System. Выберите команду Model=>Model Description и в строке Name открывшегося 
диалогового окна введите имя модели — ВРМ Diagram for Lease Process. Проделав 
это, нажмите <Alt+S> для сохранения новой модели. В окне выбора файла введите 
имя LEASE.ВРМ. 
    Щелкните на средстве External Entity панели инструментов и перетащите его 
на лист модели, разместив объект в левом верхнем углу. Щелкните дважды на 
объекте и в качестве имени введите PROSPECTIVE TENANT. Данный объект будет 
представлять потенциального арендатора, запрашивающего информацию об имеющихся 
предложениях или собирающегося заключить договор об аренде какого-то объекта. 
На рис. 6.4 представлен вид модели на этом этапе. 

    Рис. 6.4. Новая модель с первым внешним объектом 


    Процессы 

    Добавьте в модель два объекта, представляющие процессы. Первый разместите 
посередине верхней части модели, а второй — в верхнем правом углу (рис. 6.5). 
Первому процессу присвойте имя Lease Processing, а второму — Lease Execution 
(для редактирования имени используйте двойной щелчок). Объект Lease Processing 
представляет получение и проверку информации для заключения договора об 
аренде. Этот процесс является ключевой точкой всей модели. Процесс Lease 
Execution представляет текущий договор об аренде конкретного объекта 
недвижимости. Он вступает в силу с момента вручения ключей и документов новому 
арендатору и регистрации нового договора. 

    Накопители 

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

    102 Часть I. Основы 

    Рис. 6.5. Новая модель с добавленными объектами процессов 
    
    Puc. 6.6. Модель с добавленными объектами накопителей 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 103

    Потоки 

    Разместив все объекты, нужно показать, как они взаимодействуют. Это 
осуществляется с помощью объектов потоков. Для того чтобы соединить два 
элемента с помощью такого объекта, нужно щелкнуть на кнопке данного объекта, 
находящейся на панели инструментов, затем щелкнуть на объекте, который будет 
использоваться в качестве источника, а потом — на объекте, который будет 
использоваться в качестве приемника (для отмены операции нажмите <Esc>). После 
этого система Silverrun-BPM отобразит линию, связывающую источник и приемник 
потока. Для создания объектов потоков можно применять любое из трех имеющихся 
средств, представленных на панели инструментов (на их пиктограммах изображены 
линии разного типа со стрелками). Вид средства никак не влияет на функции — вы 
можете выбрать такой тип линии, который вам больше нравится. 
    Свяжите объект PROSPECTIVE TENANT с объектом Lease Processing. Щелкните 
дважды на объекте потока и присвойте ему имя Applies for lease. Этот поток 
будет представлять заявку потенциального арендатора на заключение нового договора. 
    Теперь соедините объект Lease Processing с объектом PROSPECTIVE TENANT. 
Щелкните дважды на объекте потока и присвойте ему имя Notifies of Acceptance. 
Данный объект будет представлять положительный ответ на заявку потенциального 
арендатора. 
    Соедините объекты Lease Processing и Lease Execution. Щелкните дважды на 
объекте потока и присвойте ему имя Verifies Lease. Данный поток показывает, 
что проверенный договор пересылается менеджеру. 
    Наконец, соедините объекты Lease Execution и PROSPECTIVE TENANT. Присвойте 
потоку имя Leases Property. Этот поток будет представлять вступление договора 
об аренде в силу. На рис. 6.7 показан вид нашей модели после размещения на ней 
всех указанных выше объектов. 
    Теперь осталось показать потоки, связывающие объекты с накопителями. 
Посмотрите на рис. 6.8 и приведите вашу модель в соответствие с этим рисунком. 

    Структуры данных 

    Итак, вы только что создали модель процесса заключения договора об аренде 
новым арендатором. Следующий шаг состоит в детализации структуры данных, 
представленных объектами накопителей нашей модели. Это поможет вам в будущем 
сэкономить время при разработке моделей "сущность-связь" приложения. 
    Система Silverrun-BPM позволяет указать атрибуты накопителей, которые 
затем используются системами ERX и RDM. Эти структуры данных примерно 
соответствуют сущностям в ER-диаграммах и таблицам в реляционной схеме данных. 
Чаще всего всю необходимую информацию для определения структуры данных можно 
почерпнуть из имеющихся документов и форм, предоставленных заказчиком 
приложения, или из беседы с ним. Постарайтесь собрать как можно больше 
сведений о том, какие данные должна сохранять проектируемая система. Чем 
точнее будут эти сведения, тем меньше вам придется дорабатывать систему. 
    Добавление описаний структур данных в модель ВРМ состоит из двух частей. 
Во-первых, нужно определить такие структуры с помощью команды Project=>Data 
Structures. Во-вторых, связать эти структуры данных с соответствующими 
объектами накопителей. 
    Выберите пункт Project=>Data Structures и с помощью открывшегося 
диалогового окна добавьте три структуры данных: CALL, LEASE и TENANT. Для 
этого введите имя каждой структуры в строке, расположенной в левом нижнем углу 
диалогового окна Data Structures, и щелкните на кнопке Add (рис. 6.9). 
    Создав все три структуры, нужно определить атрибуты их данных. Щелкните 
дважды на имени структуры в диалоговом окне Data Structures, чтобы открыть 
диалоговое окно Data Structure Composition, с помощью которого определяются 
атрибуты. Введите имя атрибута в строке ввода, расположенной в левом нижнем 
углу окна, и щелкните на кнопке Add (рис. 6.10). 
    Теперь для каждой структуры данных нужно определить атрибуты. Добавьте 
следующие элементы в структуру данных CALL. 
    Call Number 
    Call Date 
    Call Time 
    Property Number 
    Call Description 

    104 Часть I. Основы 


    Рис. 6.7. Объекты потоков позволяют установить связи между элементами модели 

    Рис. 6.8. Окончательный вид диаграммы модели заключения договора об аренде 
новым арендатором 


    Глава 6. Проектирование базы данных архитектуры клиент/сервер 105


    Рис. 6.9. Создание структур данных с помощью диалогового окна Data Structures 

    Puc. 6.10. Добавление элементов структуры данных с помощью диалогового 
окна Data Structure Composition 


    Часть I. Основы  106

    В структуру данных LEASE добавьте следующие элементы. 
    
    Lease Number 
    Tenant Number 
    Property Address 
    Property City 
    Property State 
    Property Zip 
    Property Addition 
    Property BedRooms 
    Property LivingAreas 
    Property BathRooms 
    Property GarageType 
    Property SchoolDistrict 
    Property Deposit 
    Property Rent 
    Property Range 
    Property Refrigerator 
    Property Dishwasher 
    Property CentralHeat 
    Property CentralAir 
    Property GasHeat 
    Property PrivacyFence 
    Property LastSprayDate 
    Property LastLawnDate 
    Lease BeginDate 
    Lease EndDate 
    Lease MovedInDate 
    Lease MovedOutDate 
    Lease Rent 
    Lease Deposit 
    Lease PetDeposit 
    Lease RentDueDay 
    Lease LawnService 
    Lease Comments 
    
    В структуру данных TENANT занесите следующие элементы. 
    
    Tenant Number 
    Tenant Name 
    Tenant Employer 
    Tenant EmployerAddress 
    Tenant EmployerCity 
    Tenant EmployerState 
    Tenant EmployerZip 
    Tenant HomePhone 
    Tenant WorkPhone 
    Tenant ICEPhone 
    Tenant Comments 
    
    Информацию, необходимую для определения структур данных, можно получить из 
заявки на заключение договора, журнала регистрации арендаторов и т.п. 
Заметьте, что пока мы не пытаемся нормализовать данные — этой проблемой мы 
займемся немного позже. Сейчас же ваша главная задача — создать как можно 
более полные модели объектов реального мира, с которыми будет сталкиваться 
ваша система. 
    Обратите внимание на то, что имя каждого из добавляемых атрибутов состоит 
из двух частей, причем в качестве первой части используется имя накопителя. 
Применение такого соглашения позднее позволит вам создавать таблицы физической 
базы данных. Кроме того, как вы скоро убедитесь, такой подход помогает при 
использовании системы Silverrun-ERX. 
    После создания структур данных, их нужно связать с соответствующими 
объектами накопителей. Откройте с помощью команды Presentation=>Palettes=>Data 
Structures палитру структур данных (рис. 6.11). Для того чтобы связать 
определенную структуру данных с накопителем, перетащите эту структуру с 
помощью правой кнопки мыши на нужный объект накопителя. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 107 


    Рис. 6.11. Структуры данных связываются с накопителями с помощью палитры структур 

    Теперь нужно связать структуры данных с соответствующими объектами 
накопителей. Свяжите структуру данных CALL с накопителем CALL, структуру 
TENANT — с накопителем TENANT, а структуру LEASE — с накопителем LEASE. Для 
того чтобы убедится в наличии связи между накопителем и структурой данных, 
щелкните дважды на объекте накопителя. В левом нижнем углу появившегося окна в 
строке Data Structures должно быть указано имя связанной с этим накопителем 
структуры данных. 
    Связав структуры данных с соответствующими накопителями, вы тем самым 
завершили разработку модели процесса, связанного с управлением договорами 
аренды. Следующий этап — моделирование "сущность-связь", необходимое для 
отображения работы построенной модели процесса. На этом этапе нужно 
использовать средство Silverrun-ERX. 
    Однако, прежде чем перейти к следующему этапу, нужно сохранить только что 
созданную модель процесса предметной области в хранилище Silverrun. Это 
позволит вам в дальнейшем при разработке ERдиаграмм снова использовать 
определенные в модели процесса накопители и структуры данных. Для того чтобы 
сохранить созданную модель в хранилище, выполните следующее. 
    1. Выберите из меню команду Util=>WRM Dictionary. В главном меню Silverrun 
должен появится новый пункт WRM Dictionary, а на экране — окно WRM Dictionary. 
    2. Не закрывая окна WRM Dictionary, выберите из подменю WRM Dictionary 
пункт Update WRM Dictionary, чтобы сохранить созданную модель процесса в 
хранилище. В появившемся окне щелкните на кнопке Update и оставьте в качестве 
имени файла указанное по умолчанию значение updt_rep. В этом файле, который 
затем можно просмотреть с помощью любого текстового редактора, Silverrun 
сохранит информацию об обновлении состояния хранилища. 
    3. Выберите из меню WRM Dictionary пункт Save WRM Dictionary. В качестве 
имени нового словаря укажите RENTMAN и щелкните на кнопке Save (Сохранить). 
Теперь другие средства пакета Silverrun могут получить доступ к информации о 
накопителях и структурах данных вашей модели процесса предметной области. 
    Что ж, продолжим. Сохраните сделанное, выйдите из Silverrun-BPM и 
запустите средство Silverrun-ERX. 

    108 Часть I. Основы 

    Моделирование сущностей и связей 

    В 1976 г. Питер Чен (Peter Chen) опубликовал первую спецификацию подхода к 
реляционным структурам данных как к набору связей между сущностями ("The 
Entity Relationship Model — Toward a Unified View of Data", ACM Transaction on 
Database Systems, Vol. 1, No. 1 [March 1976], pp. 9—36). Работа Чена, а также 
других теоретиков, например Хаммера (Hammer) и Мак-Леода (McLeod), создателей 
семантической модели данных, явилась основой для возникновения ER-диаграмм 
(диаграмм "сущность-связь"), которые в наглядной форме представляют связи 
между сущностями и сегодня являются фундаментом моделирования логических 
структур данных. 

    Типы ER-диаграмм 

    ER-диаграммы, как правило, бывают двух основных типов. Первый тип 
использует стандартную нотацию Чена. Диаграммы такого типа очень 
специализированы — каждая диаграмма обычно представляет одну связь между двумя 
сущностями. На рис. 6.12 показан пример простой ER-модели, использующей 
нотацию Чена. 
    Второй тип диаграмм называется подробной ER-диаграммой. Подробные 
ER-модели появились вследствие того, что подход, применяемый в диаграммах 
Чена, приводит при разработке проекта сложной базы данных к необходимости 
создания сотен и даже тысяч отдельных диаграмм. В случае применения подробных 
ER-моделей такого, как правило, не бывает, так как все связи отдельной 
сущности приводятся на одной диаграмме. Такие диаграммы основываются на 
сущностях, а не на связях. Подробные ER-диаграммы обычно содержат информацию 
об атрибутах и по внешнему виду сильно отличаются от простого стиля диафамм 
Чена. На рис. 6.13 показан пример подробной ER-диаграммы. 

    Рис. 6.12. Стандартная ER-диаграмма Чена 


    На заметку 
    Одним из популярных типов диаграмм "сущность-связь" являются диаграммы, 
выполненные по нотации IDEF1X. Этот стандарт был разработан Робертом Брауном 
(Robert G. Brown) в сотрудничестве с учреждениями ВВС США в конце 70-х гг. 
Претерпев несколько пересмотров, он наконец обрел свое нынешнее название 
IDEF1X. Этот стандарт оказал существенное влияние на подходы, применяемые к 
разработке диаграмм, и в гражданских организациях, таких как компании Lockheed 
и Hughes Aircraft, банк Bank of America и др. Благодаря тому, что стандарт 
IDEF1X был создан в военной организации, он в настоящее время является 
составной частью стандарта федеральных систем обработки информации США 
(Federal Information Processing Standards). 

    Стандарт IDEF1X базируется на реляционной модели, разработанной Коддом, и 
модели "сущность-связь" Чена. Однако, несмотря на то что в стандарте IDEF1X 
много общего с моделями Кодда и Чена, они все же имеют ряд довольно 
существенных различий. Каковы эти различия — не так важно, достаточно знать, 
что они имеются, особенно если вы используете средства ERWin или ER/1, 
базирующиеся именно на стандарте IDEF1X. 
    Если не вдаваться в подробности, то сущности, которые вы определяете с 
помощью ER-диаграмм, соответствуют таблицам реляционной модели и последующей 
реализации физической базы данных. Именно поэтому многие популярные средства 
создания таких диаграмм используют не только элементы моделирования сущностей 
и связей, но и элементы реляционной модели и физического проектирования. Более 
оправданным оказался подход, заключающейся в том, чтобы на практике показать 
пользователям корреляцию между сущностями и таблицами, а не заставлять их 
работать с этими элементами по отдельности. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 109 


    Рис. 6.13. Подробная диаграмма "сущность-связь " сильно отличается от 
диаграмм, созданных по нотации Чена 


    Терминология моделирования сущностей и связей 

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

    Таблица 6.2. Основные термины моделирования сущностей и связей             

    Термин                Определение 

    Сущность (entity)    
    Реальный объект (физическое лицо, предприятие, событие, предмет), данные 
которого сохраняются. Сущности также называют классами сущностей (entity class) 

    Экземпляр сущности (entity instance)
    Конкретный представитель класса сущностей. Например, клиент Джон До 
является экземпляром сущности класса сущностей КЛИЕНТ. Экземпляры сущностей 
называют также воплощениями сущностей (entity occurrence) 

    Моделирование сущностей и связей (entity relationship (ER) modelling)
    Подвид моделирования логических структур данных, основывающийся на 
предположении, что все элементы предметной области можно представить в виде 
идеальных прототипов — абстрактных концепций. Такие концептуальные сущности 
описываются в терминах их характеристик, или атрибутов (attribute). Сущности 
связаны друг с другом через действия, которые они выполняют по отношению 
друг к другу. Эти действия устанавливают связи (relationship) между 
сущностями. ER-моделирование ставит своей целью визуальное представление 
таких связей 


    110 Часть I. Основы 


    Окончание таблицы 6.2. 

    Термин 		Определение 

    Подтип (subtype) 
    Класс сущностей, являющийся подмножеством более крупного 
и обширного типа сущностей, называемого супертипом. Например, класс сущностей 
ПОЖАРНЫЙ может быть подтипом супертипа МУНИЦИПАЛЬНЫЙ СЛУЖАЩИЙ. Подтипы обычно 
наследуют атрибуты и связи супертипа, однако могут определять и собственные 
атрибуты и связи. Группа подтипов (например, ПОЖАРНЫЙ, ПОЛИЦЕЙСКИЙ, ДВОРНИК) 
называется кластером подтипов (subtype cluster) 

    Супертип 
    Класс сущностей, является надмножеством более мелких и узких 
классов (supertype) сущностей, называемых подтипами. Например, класс сущностей 
АВТОМОБИЛЬ может быть супертипом сущностей ФОРД АВТО, ДЖЕНЕРАЛ МОТОРС АВТО и 
КРАЙСЛЕРАВТО. Супертипы и подтипы часто называют С-типами (S-Type) 

    Атрибут (attribute) 
    Характеристика сущности или связи. Атрибуты подробно описывают сущности. 
Например, атрибут Номер СтраховогоПолиса может быть характеристикой класса 
сущностей СЛУЖАЩИЙ 

    Домен (domain) 
    Определенный тип данных или диапазон значений, которые может принимать 
атрибут. Например, применение домена TDate к атрибуту Дата Приема может 
потребовать, чтобы все значения этого атрибута представляли собой правильно 
указанные даты. Точно так же, применение домена TNonZeroCost к атрибуту 
Цена может потребовать, чтобы все значения атрибута Цена были отличными от нуля 

    Целостность домена 
    Правила, определяющие типы данных, допускаемые доменом. Обеспечение и 
(domain integrity) лостности домена может означать, например, что значения, 
хранящиеся в атрибуте, к которому применен домен Date, являются правильными 
датами, а значения, хранимые в атрибуте, с которым связан домен Numeric, 
действительно являются числами 

    Связь (relationship) 
    Соединение двух сущностей, приводящее к тому, что состояние одной сущности 
изменяется при изменении состояния другой сущности. Существуют пять основных 
типов связей — "один ко многим", "многие ко многим", "один к одному", 
"взаимное исключение" и "рекурсия"

    Целостность связей (relational integrity)  
    Правила, обеспечивающее поддержание связей между сущностями. Например, 
целостность связей может воспрепятствовать удалению экземпляра сущности КЛИЕНТ, 
у которого имеется связь с экземпляром сущности СЧЕТ 

    Связность (connectivity) 
    Отображение объединения соответствующих классов в виде наличия связей между 
их экземплярами. Например, при определении связности сущностей СЧЕТ и КЛИЕНТ 
можно указать, что каждый экземпляр сущности КЛИЕНТ может иметь много 
соответствующих ему экземпляров класса сущностей СЧЕТ 

    Кардинальность (cardinality)
    Реальное количество связанных между собой экземпляров классов сущностей.  
Кардинальность, базируясь на связности, определяет количество связей между 
сущностями. Например, наличие кардинальности сущностей СЧЕТ и КЛИЕНТ может 
означать, что для каждого экземпляра сущности СЧЕТ имеется, по крайней мере, 
один соответствующий экземпляр сущности КЛИЕНТ 

    Модальность (modality)  
    Определяет обязательность или необязательность наличия экземпляра сущности. 
Модальность является показателем минимальной кардинальности связей между 
сущностями 

    Нормализация 
    Устранение избыточности, противоречивости и непоследовательности модели 
(normalization) данных. Нормализация основывается на идее, заключающейся в том, 
чтобы каждый экземпляр сущности представлял не больше одного объекта реального 
мира 

    Идентификатор сущности (entity identifier) 
    Набор атрибутов, необходимый для того, чтобы отличить один экземпляр сущности 
от другого  


    Глава 6. Проектирование базы данных архитектуры клиент/сервер 111 

    Существует прямая связь между терминологией ER-моделирования и 
терминологией реляционного моделирования. В табл. 6.3 приведены некоторые из 
терминов ER-моделирования вместе с их реляционными аналогами. 

    Таблица 6.3. Сравнение ER-терминов с их реляционными аналогами 

    ER-термин		Реляционный термин 

    Сущность			Таблица (table) 
    Экземпляр сущности		Строка (row) 
    Идентификатор сущности	Первичный ключ (primary key) 
    Уникальный идентификатор	Потенциальный ключ (candidate key) 
    Связь				Внешний ключ (foreign key) 
    Атрибут				Столбец (column) 
    Домен				Тип данных (data tvoe) 

    В пакете Silvenun применен подход, характерный для систем высшего класса, 
заключающийся в том, что ER-моделирование рассматривается как составная часть 
моделирования реляционных структур данных. Однако логическое моделирование не 
состоит лишь из одного ER-моделирования. Кроме того, логическое моделирование 
никак не связано с физическим проектированием базы данных. Поэтому система 
Silverrun-ERX, хотя и позволяет смешивать логические и физические элементы на 
уровне ER-диаграммы, но не имеет специальных средств поддержки такого, не 
совсем корректного, метода моделирования. 
    Теперь, ознакомившись с некоторыми основными концепциями моделирования, 
давайте перейдем к созданию модели сущностей и связей, воплощающей ранее 
построенную модель процесса. 

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

    Поскольку вы на предыдущем этапе разработали полную модель процесса 
предметной области, то вам не придется тратить много времени на ER-модель 
этого процесса. Главная цель, которая будет достигнута при использовании 
системы Silverrun-ERX, состоит в нормализации данных. 
    Как правило, нормализация является составной частью моделирования 
реляционных структур данных или проектирования базы данных. В этой книге мы 
будем рассматривать создание модели "сущность-связь" как первый шаг такого 
процесса. Некоторые разработчики полностью разделяют эти два типа 
моделирования, другие после ER-моделирования переходят сразу к созданию 
объектов базы данных, третьи же сразу создают реляционную модель, ленясь 
тратить время на "нудные" ER-диаграммы. В этой книге я ознакомлю вас с обоими 
типами моделирования. Закончив ER-моделирование с помощью средства 
Silverrun-ERX, мы перейдем к проектированию базы данных с помощью средства 
Silvermn-RDM. Выполнение нормализации можно отложить до этапа моделирования 
реляционных структур данных, но, так как система Silverrun-ERX имеет все 
необходимые для этого средства, мы рассмотрим эту тему, не откладывая ее в 
долгий ящик. 
    Перейдем к созданию ER-модели для созданной выше модели процесса 
управления договорами аренды. Прежде всего необходимо импортировать из 
хранилища информацию, помещенную в него средством Silverrun-BPM. Для этого 
нужно выполнить следующие операции. 
    1. Запустите систему Silverrun-ERX и создайте новую модель. Настройте ее 
так же, как вы настраивали систему Silverrun-BPM. 
    2. Выберите команду Util=>WRM Dictionary. В главном меню появится пункт 
WRM Dictionary. 
    3. Из подменю WRM Dictionary выберите команду Open WRM Dictionary, а затем 
выберите файл хранилища RENTMAN.WRM, созданный средством Silverrun-BPM. 
    4. Из подменю WRM Dictionary выберите команду Update a Model и в 
появившемся диалоговом окне щелкните на кнопке Update. Это приведет к 
обновлению текущей модели объектами, находящимися в хранилище. Когда на экране 
появится запрос, нужно ли связать модель с сохраненным проектом, щелкните на 
кнопке Yes. 

    112             Часть I. Основы 

    5. Когда на экране появится диалоговое окно сохранения отчета об 
обновлении хранилища, щелкните на кнопке Save (Сохранить), чтобы сохранить 
отчет под указанным по умолчанию именем, а затем на кнопке Yes (Да), чтобы 
записать новый отчет поверх имеющейся информации. 
    6. В появившемся окне сообщения о завершении обновления (update completed) 
щелкните на кнопке ОК. 
    7. Щелкните на кнопке закрытия окна WRM Dictionary, чтобы вернуться в 
обычный режим моделирования. 
    8. Выберите команду Presentation=>Palettes=>Component: SR Store, чтобы 
отобразить на экране палитру накопителей Component: SR Store. 
    9. Перетащите каждый накопитель из палитры в область моделирования, 
используя правую кнопку мыши. При этом будут созданы объекты сущностей, 
соответствующие объектам накопителей, определенных в модели процесса 
предметной области. Если вы попытаетесь перетащить накопитель PROPERTY, то 
получите сообщение об ошибке, так как для него нет соответствующей 
структуры данных. 
    10. Щелкните на кнопке закрытия палитры накопителей. 
    11. Расположите объекты сущностей так, чтобы они не перекрывались и 
распределите их по рабочей области. 

    На рис. 6.14 представлен примерный вид полученной модели. 

    Если бы в системе Silverrun-ERX не было бы средства, называемого экспертом 
нормализации, вам пришлось бы провести декомпозицию сущностей по 
нормализованным классам сущностей, а затем объединить их друг с другом с 
помощью связей. Этот подход является стандартным при ER-моделировании. Всю 
работу можно условно разделить на три стадии. 
    1. Определение начального набора сущностей. 
    2. Декомпозиция их в нормализованные формы. 
    3. Объединение сущностей с помощью связей. 
    Однако, благодаря эксперту нормализации системы Silverrun-ERX, мы можем 
опустить некоторую часть работы по моделированию структур данных. В 
большинстве случаев эксперт может выполнить полную нормализацию, задав лишь 
несколько простых вопросов. Для того чтобы запустить эксперта системы
Silverrun-ERX, выполните следующие операции. 
    1. Выберите команду Model=>Abbreviations. С помощью появившегося 
диалогового окна (рис. 6.15) создаются сокращенные варианты имен сущностей и 
атрибутов. Например, можно указать, чтобы все имена Number были заменены 
сокращенным вариантом No. Как я говорил в главе 4, "Соглашения", очень важно, 
чтобы такие сокращенные варианты были одинаковы в именах всех элементов базы 
данных и программных элементов. 
    2. Переключитесь в режим эксперта, выбрав команду Expert=>Expert Mode. 
    3. Выберите команду Expert=>Normalize Model. Когда система спросит вас, 
нужно ли анализировать имена, щелкните на кнопке Yes. Затем будет выдан запрос 
на подтверждение вашего намерения провести нормализацию. Снова щелкните на 
кнопке Yes. 
    4. На экране появится нечто загадочное. Объекты сущностей изменят свое 
положение, а между ними появятся линии связей, соединяющие одни объекты с 
вершинами других. Примерный вид экрана в этот момент представлен на рис. 6.16. 
Разместите сущности и связи таким образом, чтобы они не закрывали друг друга. 
    5. Приведя модель в порядок, вы увидите, что в ней появилась новая 
сущность под названием Property. Эта сущность была выделена экспертом 
нормализации, исходя из избыточности сущности LEASE. Щелкните дважды на новой 
сущности и измените ее имя на PROPERTY. На рис. 6.17 приведен вид, который 
может иметь модель в этот момент. 
    При создании объектов структуры данных в модели процесса вы, должно быть, 
заметили, что я по каким-то причинам не указал вам на необходимость создания 
структуры данных для накопителя PROPERTY. Теперь, я думаю, эти причины вам 
понятны. Атрибуты, которые должны были относиться к накопителю PROPERTY, были 
намеренно помещены в структуру данных LEASE. Это было сделано для того, чтобы 
продемонстрировать всю мощь CASE-средств в моделировании данных. Все атрибуты, 
относящиеся к накопителю RPOPERTY, были извлечены из сущности LEASE и помещены 
в новую сущность Property. Обратите также внимание на то, что атрибут Property 
Number был скопирован из сущности CALL. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер              113 


    Рис. 6.14. Модель с объектами сущностей, полученными из хранилища Silverrun 

    Рис. 6.15. С помощью этого диалогового окна можно настроить сокращения, 
которые система Silverrun будет использовать для присвоения имен элементам 

    Часть I. Основы 114


    Рис. 6.16. Вид модели после выполнения нормализации экспертом системы Silverrun-ERX 

    Рис. 6.17. Эксперт нормализации системы Silverrun-ERX добавил новую 
сущность в разрабатываемую модель 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 115

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

    Поскольку вы, наверняка, хотите разобраться в происходящем "за кулисами", 
я решил дать исчерпывающее описание нормализации. Отставив в сторону научные 
определения, можно сказать, что нормализация позволяет уменьшить затраты труда 
и снизить вероятность возникновения ошибок при обновлении таблиц базы данных. 
Например, если я сохраняю адрес клиента в каждой записи таблицы INVOICE, то 
при изменении этого адреса мне придется изменить все записи этой таблицы, 
содержащие старый адрес. Если же информацию об адресе клиента поместить в 
одной строке отдельной таблицы, то изменения нужно будет внести только один 
раз. Понятно, что это существенно уменьшает время обновления информации и 
полностью устраняет вероятность возникновения ошибки, связанной тем, что в 
какой-то строке остался старый адрес. 
    Формально процесс нормализации делится на пять форм, или этапов, — от 
первой нормальной формы до пятой нормальной формы. Под этими несколько 
туманными названиями скрываются пять наборов реляционных критериев, которым 
может соответствовать или не соответствовать сущность. Выполнение каждого 
последующего этапа возможно только в том случае, если предыдущий этап 
завершился успешно. Хотя, как я уже сказал, существуют пять форм нормализации, 
для практических задач вполне достаточно первых трех. Последние две формы 
обычно пропускаются, так как для применения в проектировании типичных баз 
данных они являются слишком узкоспециализированными. 

    На заметку 
    Хотя мы еще не обращались к теме проектирования реляционных баз данных, 
далее я буду использовать реляционные термины, такие как таблица, строка и 
столбец в качестве синонимов ER-терминов, таких как сущность, воплощение 
сущности и атрибут. Я исхожу из тех соображений, что примеры, приводимые мной 
при описании каждой нормальной формы, проще понять, руководствуясь объектами 
реляционных и физических баз данных, а не абстрактными концепциями. 

    Первая нормальная форма 

    Для того чтобы таблица соответствовала первой нормальной форме, каждый 
столбец этой таблицы должен быть полностью атомарным и не содержать 
повторяющихся групп. Столбец считается атомарным, когда он содержит только 
один элемент данных. Например, столбец Адрес, содержащий не только название 
улицы, но и название города, страны и почтовый индекс, атомарным не является. 
Такие столбцы нужно разбивать на несколько столбцов, для того чтобы таблица 
полностью соответствовала первой нормальной форме. 
    Повторяющаяся группа — это столбцы, которые повторяются в пределах одной и 
той же строки для хранения нескольких значений одного и того же атрибута. 
Например, мы могли применить такой подход, когда разрабатывали таблицу LEASE, 
и использовать ее для хранения информации об арендуемом объекте недвижимости 
вместо создания отдельной таблицы PROPERTY. Однако в том случае, если 
арендатор будет арендовать более одного объекта недвижимости, в таблице LEASE 
пришлось бы создавать столько дополнительных столбцов, сколько объектов может 
арендовать один клиент. Именно эти дополнительные столбцы и называются 
повторяющейся группой. 
    Некоторые инструментальные средства и языки для разработки баз данных 
содержат прямую поддержку повторяющихся групп и тем самым поощряют применение 
нереляционной архитектуры. Естественно, что при нарушении первой нормальной 
формы дальнейшая разработка реляционной базы данных невозможна. Примером 
такого средства является система Advanced Revelation. Множественные столбцы 
(multivalued column), которые можно создавать с помощью этой системы, на самом 
деле являются ни чем иным как повторяющейся группой. Применение таких столбцов 
в приложениях AREV — широко распространенная практика, нарушающая первую 
нормальную форму. Подобная же конструкция — ассоциативный массив (associative 
array) — имеется в языке Peri. Ассоциативный массив — это набор пар 
имя-значение, хранимых в одной переменной. Хотя наличие такой конструкции 
позволяет получать на практике определенные выгоды, ее применение влечет за 
собой создание баз данных, не соответствующих первой нормальной форме. 
Наконец, еще одним примером языковой поддержки нереляционной архитектуры, 
является команда имя_группы occurs several times языка COBOL. Однако, что 
касается этого языка, то здесь поддержка нереляционных элементов, по крайней 
мере, неудивительна, так как он появился в дореляционную эпоху. 
    Независимо от того, разрабатываете ли вы базу данных или приложение базы 
данных, использование повторяющихся групп является плохой практикой. Я 
упоминаю здесь приложения, так как их архитектура неизбежно оказывает влияние 
на архитектуру баз данных. Так или иначе, но информация, которая обра-

    116 Часть I. Основы 

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

    Вторая нормальная форма 

    Для того чтобы таблица соответствовала второй нормальной форме, каждый из 
ее столбцов должен полностью зависеть от первичного ключа или от каждого 
атрибута первичного ключа, если такой ключ состоит из нескольких столбцов. Это 
означает, что все неключевые столбцы должны однозначно определяться с помощью 
первичного ключа таблицы. 
    Давайте снова вернемся к примеру таблицы INVOICE. Если первичный ключ 
таблицы состоит из столбцов LocationNo и InvoiceNo, то хранение адреса 
(location) в столбце LocationName этой же таблицы может привести к нарушению 
второй нормальной формы. Причина этого заключается в том, что содержимое 
столбца LocationName для строк, содержащих один и тот же адрес, не будет 
однозначно идентифицироваться первичным ключом. Однозначная идентификация 
будет происходить только по значению поля LocationNo, а значение InvoiceNo 
никак не повлияет на нее. Поэтому столбец LocationName нужно получать, при 
необходимости, из отдельной таблицы с помощью объединения, а не хранить в 
таблице INVOICE. 

    Третья нормальная форма 

    В таблице, соответствующей третьей нормальной форме, каждый столбец должен 
полностью зависеть только от первичного ключа, и все неключевые столбцы не 
должны зависеть друг от друга. Иными словами, неключевые столбцы таблицы, 
соответствующей третьей нормальной форме, должны не только однозначно 
определятся первичным ключом, но и не зависеть друг от друга. 
    Снова рассмотрим пример таблицы INVOICE. Пусть первичный ключ таблицы 
состоит из столбцов LocatioNo и InvoiceNo. Одним из неключевых столбцов 
таблицы будет, по-видимому, столбец CustomerNo. Если кроме столбца CustomerNo 
в таблицу INVOICE поместить столбец CustomerName, то она не будет 
соответствовать критерию третьей нормальной формы, так как оба эти столбца 
могут зависеть друг от друга. При изменении значения поля CustomerNo может 
возникнуть необходимость и в изменении значения поля CustomerName, и наоборот. 
Таким образом, столбец CustomerName нужно вынести в отдельную таблицу 
(например, в таблицу CUSTOMER) и при необходимости обращаться к нему с помощью 
объединения. 

    На заметку 
    Усовершенствованная третья нормальная форма, называемая нормальной формой 
Бойса-Кодда (BCNF — Boyce-Codd Normal Form), требует, чтобы каждый столбец, от 
которого зависит другой столбец, сам являлся уникальным ключом. Наборы 
столбцов, которые могут однозначно идентифицировать строки, называются 
потенциальными ключами (candidate key). Первичный ключ таблицы выбирается из 
таких потенциальных ключей. BCNF требует, чтобы любой зависимый столбец 
зависел только от потенциальных ключей. Таким образом, BCNF улучшает третью 
нормальную форму путем разрешения зависимости между неключевыми столбцами 
и потенциальными ключами. Однако здесь нет никакого нарушения третьей
нормальной формы, как может показаться на первый взгляд, поскольку неключевые 
столбцы зависят от потенциальных ключей, которые также могут однозначно 
идентифицировать строки, как и первичный ключ. Поэтому зависимость столбцов 
от потенциальных ключей, отличных от первичного ключа, является чистой 
академическим отличием, так как и первичный ключ, и потенциальные ключи могут 
однозначно идентифицировать каждую строку таблицы, 
    Если это кажется вам непонятным, не волнуйтесь. Соответствия третьей 
нормальной форме в большинстве случаев вполне достаточно, чтобы считать 
таблицу или сущность нормализованной. Различие, которое ни на чем не 
отражается, не является различием. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 117 

    Четвертая нормальная форма 

    Четвертая нормальная форма запрещает существование между столбцами 
многозначной зависимости. Если столбец не идентифицирует однозначно другой 
столбец, а лишь ограничивает его до определенных значений, то говорят, что 
между такими столбцами существует многозначная зависимость. Давайте для 
примера рассмотрим таблицу TENANT системы RENTMAN. Предположим, что 
информация, которую вы хотите сохранять в этой таблице о работодателе 
арендатора, ограничивается лишь фамилией работодателя. Для хранения этой 
информации вы в сущности TENANT создаете атрибут Employer. Однако если у 
арендатора более одного работодателя (скажем, он трудоголик и пишет по ночам 
книги о проектировании систем клиент/сервер), вам понадобится завести в 
таблице TENANT по одной строке для каждого работодателя. Все атрибуты таких 
строк будут идентичными, за исключением атрибута Employer. 
    Таким образом, связь между другими столбцами таблицы TENANT и столбцом 
Employer может принять форму многозначной зависимости — у одного и того же 
значения столбца TenantNo может быть несколько значений Employer. Исходя из 
практических соображений, вы можете пойти на это сознательно, так как у 
арендатора действительно может быть несколько работодателей. Кроме того, вас 
может интересовать, какую работу выполняет арендатор у каждого работодателя. 
Однако для того, чтобы- таблица соответствовала четвертой нормальной форме, 
нужно создать отдельную таблицу, предназначенную для сопоставления арендаторов 
и работодателей. В идеальном случае такая таблица должна содержать только два 
столбца TenantNo и Employer, каждый из которых являлся бы частью составного 
первичного ключа. Тогда, если вам нужно было бы получить информацию по 
определенному арендатору, вы могли бы создать объединение таблицы TENANT с 
новой таблицей с помощью их общего поля TenantNo. 
    На практике операция приведения таблицы к четвертой нормально форме 
выполняется достаточно редко. Декомпозиция сущностей даже до третьей 
нормальной формы иногда дает столько новых сущностей, что разработчикам 
становится трудно с ними справиться. То, что в теории звучит хорошо, на 
практике может оказаться не столь приятным. 

    Пятая нормальная форма 

    Согласно критерию пятой нормальной формы, если таблица имеет три или более 
потенциальных ключей и можно провести ее декомпозицию без потери данных, то 
такую таблицу нужно разделить на отдельные таблицы для каждого потенциального 
ключа. Приведение таблицы к пятой нормальной форме выполняется крайне редко по 
ряду соображений. Во-первых, очень редко удается найти таблицу с тремя или 
более столбцами, каждый из которых однозначно бы идентифицировал ее строки. 
Во-вторых, чрезмерная декомпозиция может привести к неправильному созданию 
объединений, например, создающих новые строки. В подавляющем большинстве 
случаев вы не встретите (скорее всего, этот вопрос даже не будет обсуждаться) 
пятой нормальной формы на практике. Я привожу ее описание только для полноты картины. 

    Не увлекайтесь нормализацией 

    В нормализации достаточно важно не заходить слишком далеко. Чрезмерное 
увлечение нормализацией может отрицательно сказаться на производительности. 
Например, у вас может возникнуть мысль создать отдельную таблицу для 
информации о работодателе, хранящейся в таблице TENANT. В конце концов, зная о 
существовании третьей нормальной формы, как можно допустить явную зависимость 
столбцов Employer и EmployerAddress друг от друга?! Однако принесет ли вам 
создание такой таблицы какие-нибудь реальные плоды? Скорее всего, — нет. 
Информация о работодателе интересна не сама по себе — она связана с каждым 
конкретным арендатором. Компании Allodium Properties, в общем-то, все равно, 
на кого работают ее клиенты. Тогда давайте предположим, что компания не будет 
хранить сведения о нескольких работодателях арендатора и никогда не будет 
менять всю структуру данных о работодателях. В этом случае создание отдельной 
таблицы будет пустой тратой времени. 
    Кроме того, бывают случаи, когда единственным способом повышения 
производительности, особенно при обработке больших объемов информации, 
является так называемая ограниченная денормализация (limited denormalization). 
Например, предположим, что вы создаете приложение, которое ежедневно 
обрабатывает сотни тысяч кредитных карточек. Каждая запись об использовании 
кредитной карточки, помимо других сведений, содержит данные о номере карточки, 
количестве выполнявшихся по ней операций, а также дату истечения срока 
действия карточки. В конце каждого рабочего дня системе нужно напечатать отчет 
по всем прошедшим через нее кредитным карточкам, а также общее количество 
операций за день по каждой карточке и дату истечения срока действия каждой 
карточки. Поскольку вы легко можете создать объединение с таблицей базы данных 
выданных кредитных карточек для получения этой даты, то, вооружась знаниями о 
нормализации, не станете хранить эту информацию в базе данных операций по карточкам. 

    118 Часть I. Основы 

    Хотя при каждой операции по кредитной карточке дата истечения ее срока 
действия автоматически считывается и пересылается вместе с другими данными, вы 
решаете не использовать ее, а обращаться к таблице базы данных выданных 
карточек. С точки зрения теории реляционных баз данных вы поступили правильно. 
Однако на практике вы неожиданно столкнетесь с побочным эффектом принятого 
решения, в результате которого время подготовки ежедневного отчета увеличилось 
в два раза. Столкнувшись с необходимостью такого ожидания, вряд ли ваш 
заказчик сочтет производительность приложения приемлемой. 
    Решение этой проблемы заключается, выражаясь в терминах проектирования 
базы данных, в хранении даты истечения срока действия карточек в каждой записи 
об их использовании. Это повысит избыточность информации, хранимой в базе 
данных. Однако такой прием, называемый управляемой избыточностью, полностью 
решает вышеописанную проблему. Данный пример показывает, что иногда отклонение 
от теории реляционных баз данных может привести к определенным практическим 
результатам. 
    Общее правило, которым можно подытожить все вышесказанное таково. Сначала 
проведите нормализацию базы данных, а затем, если это действительно 
необходимо, внесите в нее управляемую избыточность. Не занимайтесь 
денормализацией только ради самой денормализации. Не жертвуйте реляционностью 
в угоду скорости работы. Денормализация, как правило, бывает оправдана только 
в случае обработки очень больших объемов информации. 

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

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

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

    Давайте начнем с проверки правильности предположений, сделанных экспертом 
нормализации о связности сущностей. Для этого нужно выполнить следующие операции. 
    1. Выберите команду Expert=>Verify Connectivities. В появившемся диалоговом 
окне Verify Connectivities выберите переключатель all connectivites, 
убедитесь, что сброшен флажок for selected relationships, и щелкните на кнопке Verify. 
    2. Вам будет задан ряд вопросов, с помощью которых эксперт нормализации 
должен точнее определить связи между сущностями модели. Вам нужно дать 
следующие ответы на вопросы. 
    • На вопрос In general, is it necessary for a "CALL" to have a "PROPERTY" 
to exist? отвечайте No (т.е. щелкните на кнопке No). Звонок может иметь место 
даже в случае отсутствия свободного объекта аренды. 
    • На вопрос In general, can one "CALL" have many "PROPERTY"? отвечайте No. 
Исходим из того, что каждый звонок приводит к заключению договора на аренду 
только одного объекта недвижимости. 
    • На вопрос In general, is it necessary for a "PROPERTY" to have a "CALL" 
to exist? отвечайте No. Объекты недвижимости существуют независимо от того, 
звонят ли потенциальные арендаторы. 
    • На вопрос In general, can one "PROPERTY" have many "CALL"? отвечайте 
Yes. По каждому объекту может быть несколько заявок от потенциальных арендаторов. 
    • На вопрос In general, is it necessary for a "LEASE" to have a "PROPERTY" 
to exist? отвечайте Yes. Договор аренды не может быть заключен при отсутствии 
объекта недвижимости. 
    • На вопрос In general, can one "LEASE" have many "PROPERTY"? отвечайте 
No. Каждый договор заключается на аренду только одного объекта недвижимости. 
    • На вопрос In general, is it necessary for a "PROPERTY" to have a "LEASE" 
to exist? отвечайте No. Объекты недвижимости могут существовать независимо от 
наличия договоров на их аренду. 
    • На вопрос In general, can one "PROPERTY" have many "LEASE"? отвечайте 
Yes. По каждому объекту может быть несколько договоров, каждый из которых 
заключался в свое время. 
    • На вопрос In general, is it necessary for a "LEASE" to have a "TENANT" 
to exist? отвечайте Yes. Договор аренды не может быть заключен без арендатора. 
    • На вопрос In general, can one "LEASE" have many "TENANT"? отвечайте No. 
Каждый договор заключается только с одним арендатором. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 119 

    • На вопрос In general, is it necessary for a "TENANT" to have a "LEASE" 
to exist? отвечайте No. Информация об арендаторах может существовать 
независимо от наличия действующих договоров на аренду. 
    • На вопрос In general, can one "TENANT" have many "LEASE"? отвечайте Yes. 
Любой арендатор может иметь несколько договоров, каждый из которых заключался 
в свое время. 
    Эксперт нормализации системы Silverrun-ERX изменяет модель в соответствии 
с ответами на эти вопросы. В нашем примере только в одном случае исходные 
предположения эксперта не совпали с ответом. На рис. 6.18 показан примерный 
вид модели после проверки связности. Сравнив его с рис. 6.17, вы увидите, что 
изменилась связь между сущностями CALL и PROPERTY. 

    Рис. 6.18. Модель после проверки связности 

    Итак, после работы эксперта связность между сущностями CALL и PROPERTY 
изменилась с 1,1 на 0,1. Что это означает? Числа, которые приведены на 
диаграмме, означают, соответственно, минимальную и максимальную кардинальность 
связи между данными сущностями. В частности, кардинальность 1,1 связи между 
сущностями CALL и PROPERTY показывает, что для каждого экземпляра сущности 
CALL должен существовать как минимум один экземпляр сущности PROPERTY. В 
терминах баз данных это означает, что для каждой строки таблицы CALL должно 
существовать правильное значение в столбце PropertyNo таблицы PROPERTY, причем 
это значение не может быть пустым. Отвечая на вопросы эксперта, вы указали, 
что существование экземпляра сущности PROPERTY не связано с существованием 
экземпляра сущности CALL, поэтому эксперт снизил минимальную кардинальность до 
значения 0. Такая кардинальность необходима, если компания хочет 
регистрировать все звонки, даже не связанные с конкретным объектом 
недвижимости, например звонки от потенциальных арендаторов. Это позволяет 
столбцу PropertyNo таблицы CALL оставаться пустым. 
    Точно так же, максимальная кардинальность, равная 1, подразумевает, что 
для каждого экземпляра сущности CALL существует, самое большее, один 
соответствующий ему экземпляр сущности PROPERTY. Это означает, каждая строка 
таблицы CALL будет ссылаться только на один объект недвижимости. Это удачное 
предположение, так как звонок может не касаться какого-то конкретного объекта 
недвижимости (если, например, звонит потенциальный арендатор) или быть 
связанным с каким-то одним объектом (например, заявка арендатора на ремонт). 

    120 Часть I. Основы 

    Кардинальность связей отображается с точки зрения ближайшей сущности. 
Другим словами, можно составить фразу, с помощью которой вам будет легче 
интерпретировать кардинальность сущности. 
    Для каждой строки таблицы БЛИЖАЙШАЯ СУЩНОСТЬ мне нужно минимум МИНИМАЛЬНАЯ 
КАРДИНАЛЬНОСТЬ соответствующих строк и максимум МАКСИМАЛЬНАЯ КАРДИНАЛЬНОСТЬ 
соответствующих строк в таблице УДАЛЕННАЯ СУЩНОСТЬ. 
    В данном примере для выражения кардинальности связи CALL-PROPERTY, 
получаем следующее предложение. 
    Для каждой строки таблицы CALL мне нужно минимум 0 соответствующих строк и 
максимум 1 соответствующая строка в таблице PROPERTY. 
    Заметьте, что такую же фразу можно составить с точки зрения сущности 
PROPERTY. Причем одной фразы, как правило, недостаточно. Например, хотя 
экземпляр сущности PROPERTY может не требовать существования экземпляра 
сущности LEASE, последний определенно требует существования первого. 
    Связи между сущностями часто выражаются в подобных терминах. Многие 
CASE-средства поддерживают автоматическое создание аннотаций к диаграммам, 
использующих такого рода формулировки. Другой метод выражения характера связей 
между сущностями использует следующий формат: 

    РОДИТЕЛЬСКАЯ СУЩНОСТЬ имеет не меньше N ДОЧЕРНЯЯ СУЩНОСТЬ 

    Возвращаясь к нашему примеру, можно записать минимальную кардинальность в 
следующем виде: 

    CALL имеет не меньше О PROPERTY 

    Точно так же, выражение 

    РОДИТЕЛЬСКАЯ СУЩНОСТЬ имеет не больше N ДОЧЕРНЯЯ СУЩНОСТЬ 

    используется для отображения максимальной кардинальности. В нашем случае 
это выражение будет иметь следующий вид: 

    CALL имеет не больше 1 PROPERTY 

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

    Выбор идентификаторов сущностей 

    Следующий шаг в завершении ER-модели состоит в выборе идентификаторов для 
каждой сущности. При создании реляционной модели эти идентификаторы будут 
преобразованы в первичные ключи, которые в физической реализации базы данных 
потребуют создания соответствующих индексов. 
    Идентификаторы сущностей бывают двух видов: естественные и искусственные, 
либо суррогативные. Естественный идентификатор (natural identifier) — это 
атрибут (или набор атрибутов) сущности, который уже присутствует в сущности и 
однозначно идентифицирует каждый экземпляр этой сущности. Например, для 
сущности ГРАЖДАНИН таким естественным идентификатором является атрибут 
НомерПаспорта. Искусственный идентификатор (artifical identifier) — это 
атрибут, который добавляется к сущности только для обеспечения однозначной 
идентификации экземпляров этой сущности. Примером искусственного 
идентификатора является атрибут CalINo сущности CALL. 
    Добавление искусственного идентификатора может быть вызвано рядом причин. 
Во-первых, даже при наличии естественного идентификатора последний может быть 
слишком длинным или громоздким, чтобы использовать его на практике. Например, 
пользователю может не понравится необходимость постоянно вводить номер 
паспорта сотрудника, поэтому он может потребовать, чтобы вместо номера 
паспорта использовался короткий табельный номер. Во-вторых, сущность может и 
не иметь естественного идентификатора. Например, если из сущности CALL удалить 
атрибут CalINo, то среди оставшихся атрибутов может не найтись такого, который 
однозначно бы идентифицировал любой экземпляр этой сущности. 
    В разрабатываемой нами системе RENTMAN каждая сущность имеет искусственный 
атрибут. Хотя в некоторых сущностях можно объединить те или иные атрибуты для 
получения уникальных идентификаторов, я решил упростить задачу путем создания 
во всех сущностях искусственных идентификаторов. Это позволяет сэкономить 
время и обеспечить отсутствие проблем при дальнейшей работе. 
    Для определения идентификаторов сущностей нужно выполнить следующие операции. 
    1. Выберите команду Expert=>Search for Identifiers. 
    2. Щелкните на кнопке Search появившегося диалогового окна, убедившись что 
флажок for selected entities сброшен. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 121 

    3. На экране будут появляться диалоговые окна, с помощью которых вам будет 
предложено выбрать идентификатор каждой сущности. В нашем случае каждая 
сущность имеет искусственный идентификатор с именем вида СУЩНОСТЬ Number, где 
СУЩНОСТЬ представляет имя сущности. 
    • Когда вам будет предложено выбрать идентификатор сущности CALL, щелкните 
дважды на атрибуте Call Number, а затем — на кнопке Continue. 
    • Когда вам будет предложено выбрать идентификатор сущности LEASE, 
щелкните дважды на атрибуте Lease Number, а затем — на кнопке Continue. 
    • Когда вам будет предложено выбрать идентификатор сущности PROPERTY, 
щелкните дважды на атрибуте Property Number, а затем — на кнопке Continue. 
    • Когда вам будет предложено выбрать идентификатор сущности TENANT, 
щелкните дважды на атрибуте Tenant Number, а затем — на кнопке Continue. 
    Обратите внимание, что теперь в каждой сущности идентификаторы сущностей 
выделены полужирным шрифтом. На рис. 6.19 показан примерный вид нашей модели 
на данном этапе. 

    Последние штрихи 

    Прежде чем перейти к следующей стадии моделирования, давайте наведем лоск 
в нашей модели. Первое, что можно сделать — это сгенерировать с помощью 
системы Silverrun-ERX имена для всех элементов модели. В терминах системы 
Silverrun такие имена, несущие смысловую нагрузку, называются кодированными 
именами (coded name). Кодированные имена — это имена объектов сущностей, 
атрибутов и т.д., приведенные к сокращенной форме для обеспечения надежности 
реализации. Под надежностью реализации я подразумеваю возможность 
использования кодированных имен в конкретной СУБД независимо от использования 
или неиспользования длинных имен или недопустимых символов. Например, многие 
СУБД имеют те или иные ограничения на максимальную длину имени элементов. Так, 
система SQL Server поддерживает имена длиной до 30 символов, тогда как другие 
платформы используют ограничение всего в 18 символов. Поскольку сущности, 
которые вы определили в модели, будут воплощаться в таблицы базы данных, то 
важно использовать для них имена, соответствующие правилам конкретной СУБД. 
Система Silverrun-ERX заменяет ранее использовавшиеся имена, близкие к 
естественному языку, на имена, которые облегчают работу СУБД. Иногда такие 
замены минимальны, а иногда приводят к кардинальному изменению системы имен. 
    Для очистки используемых имен элементов, выполните следующие операции. 
    1. Выберите команду Model=>Generate Coded Names. 
    2. Установите значения параметров Maximum Length и Nb. of characters used 
from beginning of each word in the name равными 30. Поскольку созданные нами 
сущности будут реализованы в виде таблиц базы данных InterBase, то длина 
идентификатора, равная 30 (первый параметр диалогового окна), является 
приемлемым значением, поддерживаемым данной СУБД. Практически все основные 
СУБД, за исключением Oracle, могут работать с идентификаторами длиной до 30 
символов. Изменение длины сокращений (второй параметр диалогового окна) с 3 до 
30 символов обеспечит неизменность частей написанных вами идентификаторов, 
сохранив их от сокращения до трех символов. Если этого не сделать, то такие 
идентификаторы, как Tenant Name, будут сокращены до Ten_Nam — выгоды от этого 
практически никакой, но понимание назначения данного элемента ухудшается. 
    3. Не изменяя других параметров окна, щелкните на кнопке Generate. 
    Для того чтобы увидеть новые кодированные имена, щелкните дважды на любой 
из сущностей модели (рис. 6.20). Для просмотра кодированных имен атрибутов 
щелкните дважды на интересующем вас атрибуте в диалоговом окне Entity 
Attributes (рис. 6.21). 
    Теперь осталось лишь присвоить имя нашей модели. Выберите команду 
Model=>Model Description и в строке Model Name диалогового окна Model 
Description введите имя ER-Diagram for Lease Process. Удалите значение, 
приведенное в строке ввода Coded Name, и щелкните на кнопке ОК. На рис. 6.22 
показан примерный вид завершенной модели "сущность-связь". 
    С помощью команды File=>Save сохраните модель в файле с именем LEASE.ERX 
и щелкните на пункте File=>Exit, чтобы завершить сеанс работы с системой Silverrun-ERX. 

    122 Часть I. Основы 


    Рис. 6.19. Модель после определения идентификаторов сущностей 

    Рис. 6.20. Система Silvenvn-ERX автоматически генерирует имена сущностей 


    Глава 6. Проектирование базы данных архитектуры клиент/сервер 123


    Рис. 6.21. Система Silvenvn-ERX создает имена и для других элементов, 
например атрибутов 

    Рис. 6.22. Завершенная модель "сущность-связь' 


    124 Часть I. Основы 


    Моделирование реляционных структур данных 

    Теперь, когда у нас есть модель связей, объединяющих сущности модели 
процесса управления арендой недвижимости, можно перейти к моделированию 
реляционных структур данных. Моделирование реляционных, или логических, 
структур данных является следующим шагом после создания диаграмм 
"сущность-связь". На этом этапе нужно определить первичные ключи, ограничения 
ссылочной целостности и задать другие характеристики проектируемой физической 
базы данных. Для выполнения данной задачи используется средство Silverrun-RDM. 
В результате будут получены операторы SQL, необходимые для реализации вашего проекта. 

    Терминология моделирования логических структур данных 

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

    Таблица 6.4. Основные термины реляционного моделирования 

    Термин Определение 

    База данных (database)
    Набор данных, организованных в виде таблиц. Аналогом базы данных является 
шкаф для хранения документов. В базе данных хранятся таблицы, 
содержащие данные, точно так же как в шкафу хранятся папки с различными 
документами 

    Таблица (table) 
    Основной контейнер хранения данных в базе данных. Реляционную таблицу 
можно представить в виде плоскости, разделенной на строки и столбцы. Если 
продолжить сравнение базы данных со шкафом, то каждая таблица представляет 
собой отдельную папку, хранящуюся в шкафу. В таблице размещаются строки 
определенного вида, точно так же, как в папке могут хранится документы 
одного типа (например, счета за телефон) 

    Строка (row) 
    Соответствует одному объекту реального мира. Таким объектом может быть 
счет-фактура, квитанция о снятии денег с банковского счета, запись в 
телефонной книге и т.п. Строки — это основа основ базы данных. Часто строки 
называют записями, хотя педанты баз данных предпочитают термин строка. В этой 
книге оба термина используются как синонимы. В самой простой форме базы данных 
и таблицы — всего лишь средство для организации строк. Возвращаясь к аналогии 
со шкафом, строка — это документ, хранящийся в папке, которая, в свою очередь, 
находится в шкафу. Если папка называется "СЧЕТА ЗА ТЕЛЕФОН", мы можем 
предполагать, что каждый ее элемент представляет собой счет определенного 
типа. Точно так же, каждая строка таблицы СЧЕТ_ТЕЛЕФОН должна содержать данные 
определенного типа 

    Столбец (column)
    Элемент строки. Каждый столбец представляет собой определенную характеристику 
объекта, представленного строкой таблицы. Часто столбцы называют полями, хотя 
пуристы баз данных предпочитают первый термин. В этой книге оба термина 
используются как синонимы. Примером столбца может быть адрес в таблице клиентов. 
Сам по себе, этот адрес не говорит ни о чем, однако в контексте таблицы он 
представляет адрес определенного клиента 

    Первичный ключ (primary key) 
    Столбец или набор столбцов таблицы, который однозначно идентифицирует 
каждую строку. Примером первичного ключа может быть номер счета в таблице 
счетов. Номера счетов в каждой строке являются уникальными. Если вы знаете, 
что в какой-то строке имеется определенный номер, то всегда можете найти эту 
строку, используя данный номер. Столбец, являющийся первичным ключом, обычно 
используется для создания индекса таблицы, предназначенного для ускорения 
доступа к ее строкам 


    Глава 6. Проектирование базы данных архитектуры клиент/сервер 125 


    Окончание табл. 6,4. 


    Термин Определение 

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

    Потенциальный ключ (candidate  key) 
    Столбец или набор столбцов таблицы, который однозначно идентифицирует 
ее строки. Потенциальные ключи называют также уникальными (unique) ключами. 
Первичный ключ таблицы выбирается из его потенциальных ключей 

    Объединение (join) 
    Запрос SQL, который объединяет столбцы двух таблиц в один набор данных, 
базируясь на указанном условии. Таблицы, используемые в объединении, обычно 
называются левыми и правыми частями объединения, исходя из синтаксиса оператора 
SQL, используемого для создания объединений. Объединения бывают двух основных 
видов: внутренние (inner join) и внешние (outer join). Внутренние объединения 
возвращают только те строки, которые соответствуют заданному условию. Внешние 
объединения возвращают строки внешней таблицы, независимо от того, выполняется 
ли условие объединения 

    Ограничение (constraint) 
    Механизм, обеспечивающий невозможность попадания неправильных 
данных в базу данных. Существуют два основных типа ограничений: 
ограничения ссылочной целостности (referential integrity) и ограничения 
целостности доменов (domain integrity). Ограничения первого типа обеспечивают 
соблюдение целостности связей между таблицами. Ограничения второго типа не 
допускают попадания в базу данных значений неправильного типа, выходящих за 
заданные диапазоны и т.п. 

    Индекс (index) 
    Механизм физического хранения информации, который позволяет ускорить 
операции поиска строк в таблице. Использование индексов дает возможность 
отказаться от необходимости последовательного перебора всех строк 
таблицы — строки сортируются таким образом, чтобы обеспечить максимально 
быстрый поиск. Индексы бывают двух основных типов: кластерные и некластерные 
(несмотря на подобие терминов, они не имеют никакого отношения к кластерам 
СУБД Oracle). Создание кластерного индекса таблицы приводит к физической 
сортировке данных, хранящихся в таблице. Таким образом, таблица может иметь 
только один кластерный индекс. Некластерные индексы состоят из справочных 
таблиц, содержащих информацию о расположении строк в таблице данных. При 
использовании некластерных индексов поиск осуществляется сначала в таблицах 
индекса, а затем — в соответствующей таблице данных 

    Представление (view)
    Логический метод отображения подмножества данных таблицы. 
Представление само по себе не содержит никаких данных — это просто 
откомпилированный запрос SQL, к результатам которого можно обратиться, как 
если бы он был таблицей. Представление обычно предоставляет методы доступа к 
строками и (или) столбцам соответствующего подмножества таблицы 

    Хранимая процедура (stored procedure) 
    Откомпилированный набор логически связанных операторов языка SQL, который 
можно выполнить как единый модуль. В зависимости от используемой СУБД, 
хранимые процедуры могут возвращать значения и наборы данных, а также могут 
использоваться в выражениях 

    Триггер (trigger) 
    Хранимые процедуры специального вида, которые выполняются, когда к 
таблице применяются определенные операции или запускается, определенный 
оператор SQL. Триггеры часто используют как средство обеспечения ссылочной 
целостности и целостности доменов 


    126 Часть I. Основы 

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

    Преобразование диаграммы "сущность-связь" в реляционную модель 

    Итак, начнем с того, что преобразуем файл, созданный системой 
Silverrun-ERX, в формат, понятный системе Silverrun-RDM. Для этого нужно 
воспользоваться специальной утилитой Silverrun ERX-RDM. Она должна находится в 
одной папке с программой Silverrun-RDM. Для преобразования файла диаграммы 
"сущность-связь" выполните следующие операции. 
    1. Найдите каталог с утилитой Silverrun ERX-RDM и запустите ее на выполнение. 
    2. Нажмите <Alt+T>, чтобы открыть окно выбора файла. С помощью этого окна 
найдите файл LEASE.ERX и щелкните на кнопке ОК. Начнется процесс преобразования, 
по завершении которого вам будет предложено указать имя файла, в котором нужно 
сохранить преобразованную модель (рис. 6.23). Щелкните на кнопке ОК, чтобы 
принять предложенные по умолчанию параметры. 
    3. Выйдите из программы Silverrun ERX-RDM. 

    Рис. 6.23. С помощью средства Silverrun ERX-RDM модель "сущность-связь" 
преобразуется в реляционную модель 


    Доработка новой реляционной модели 

    Теперь, преобразовав ER-модель в реляционную, можно приступать к последней 
стадии проектирования базы данных. Запустите средство Silverrun-RDM, выберите 
пункт меню File=>Open и с помощью открывшегося окна выберите только что 
созданный файл LEASE.RDM. (На экране может появится окно сообщения с 
предложением преобразовать модель в новый формат; в таком случае щелкните на 
кнопке Yes.) Появится диалоговое окно выбора СУБД. В нашем примере мы будем 
использовать систему InterBase, так как она поставляется вместе с Delphi 
Client/Server. Щелкните на кнопке Avail. Target Sys. и из открывшегося списка 
выберите INTBAS41.TYP, а затем щелкните на кнопке ОК. На экране появится 
изображение модели, вид которой представлен на рис. 6.24. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 127 


    Рис. 6.24. Исходная реляционная модель 


    Создание словаря данных 

    Прежде всего нам нужно создать словарь данных нашей модели. В системе 
Silverrun-RDM эта операция выполняется через домены. Как вы помните, домены 
определяют типы данных, содержащихся в столбцах. Независимо от того, 
используете ли вы CASE-средство, процесс создания словаря данных (называемого 
также хранилищем полей или атрибутов) выполняется достаточно просто. Для этого 
нужно выполнить следующие операции. 
    1. Создайте список всех столбцов, содержащихся в таблицах вашей модели. 
Для этого вам не нужно использовать какие-нибудь специальные средства. Этот 
список может вам понадобится для справки во время создания словаря. 
    2. Создайте определения доменов для тех столбцов, которые содержатся в 
двух или более таблицах или требуют наложения специальных ограничений. Ниже я 
покажу, как это сделать с помощью системы Silverrun-RDM. 
    3. Определите бизнес-правила для каждого домена словаря данных. 
Бизнес-правила столбцов контролируют данные, вводимые в соответствующие 
столбцы. С их помощью можно, например, указать, чтобы столбец Rent всегда 
содержал ненулевые значения или чтобы значение содержимого столбца EndDate 
таблицы LEASE было больше значения столбца BeginDate. Немного ниже я покажу, 
как это делается с помощью Silverrun-RDM. 
    4. Свяжите домены с соответствующими столбцами таблиц. После этого 
некоторые столбцы создаваемой базы данных будут использовать данные, тип 
которых отличается от стандартных типов СУБД. Кроме того, домены могут 
задавать специальные характеристики столбцов, например ограничение диапазона 
приемлемых значений. Применение доменов к столбцам реляционной модели также 
выполняется с помощью средства Silverrun-RDM. 
    Итак, приступим к созданию словаря данных с помощью Silverrun-RDM. Для 
этого нужно выполнить следующие операции. 
    1. Выберите команду Project=>Target Systems, затем из полученного списка 
выберите пункт InterBase и щелкните на кнопке Generate. При этом стандартные 
типы данных InterBase будут добавлены в модель 

    128 Часть I. Основы 

как в качестве базовых типов, так и в качестве доменов. Получив сообщение 
о количестве добавленных элементов, щелкните на кнопке ОК, а затем еще раз — 
на кнопке ОК диалогового окна Target Systems, чтобы закрыть его. 
    2. Выберите команду Project=>Domains. На экране должен появится список всех 
стандартных типов данных InterBase. Как я уже упоминал, нужно определить 
домены для каждого атрибута, который используется в модели более одного раза 
или требует специальных ограничений представляемых им данных. Это поможет 
сохранить целостность модели и избавит вас в последствии от лишней работы. Для 
того чтобы создать новый домен с помощью диалогового окна Domains, выполните 
следующие операции. 
    • Щелкните на кнопке подстановки (на ней изображены три точки), 
находящейся в левом нижнем углу окна, чтобы открыть список поддерживаемых 
платформ. Выберите из этого списка пункт InterBase. 
    • В строке ввода, расположенной справа от строки версии СУБД, введите имя 
нового домена. 
    • Щелкните на кнопке подстановки, расположенной в правом нижнем углу 
диалогового окна, чтобы открыть список стандартных типов данных, на основании 
которых можно создать домен. Выберите из этого списка нужный тип данных. 
    • Щелкните на кнопке Add, чтобы добавить домен в список. 
    • После того как домен появится в списке доменов, дважды щелкните на нем, 
чтобы открыть диалоговое окно Domain Description. С помощью этого окна можно 
определить специальные характеристики домена — максимальную длину (Length), 
количество знаков после точки (Nbr. Decimals), маску ввода (Picture), пример 
формата (Example) и используемое по умолчанию значение (Default Value). Кроме 
того, можно определить другие атрибуты, например: может ли домен содержать 
неопределенные значения (Null Value Posible), имеет ли он атрибут подлинности 
(Identity), различает ли он строчные и прописные буквы (Case Sensitive) и др. 
Указав все желаемые значения параметров, щелкните на кнопке Domain и выберите 
пункт Values. В появившемся диалоговом окне (рис. 6.25) укажите значения домена. 
    • Закончив определение домена, щелкните на кнопке ОК диалогового окна Domains. 

    Рис. 6.25. Определение допустимых значений создаваемого домена 


    Глава 6. Проектирование базы данных архитектуры клиент/сервер 
    5 Delphi 3 и системы клиент/сервер 129 

    На заметку
    Для того чтобы ускорить работу, сначала создайте список всех доменов, а затем
откройте диалоговое окно Domain Description и, перемещаясь по списку доменов, 
определите с его помощью атрибуты всех доменов. Этот метод более удобен, чем 
последовательное определение каждого домена no отдельности с постоянным открытием 
и закрытием окон. 

    В табл. 6.5 перечислены все домены, которые должны быть созданы для нашей 
модели. Используя приведенную выше методику, добавьте их в модель. 

    Таблица 6,5 Домены словаря данных       -: 

    Имя                  Базовый	Длина   Десятичные   Значение по   Значения 
                         тип                знаки        умолчанию 

    TAddition         Character 	20      -            'Sherwood'  'Sherwood', 'Deerfield', 
                                                                     'Switzerland Estates', 
                                                                     'Firewheel', 'Legacy Hills', 
                                                                     'RockKnoll' 
    TAddress         Character 	30      -         	нет        нет 
    TCity            Character 	30      -            'Oklahoma   'Oklahoma City', 'Norman', 
										City'	    'Edmond', 'Dallas', 'Piano', 
         								                'Richardson' 
    TComments        VarChar   	80      -         	нет        нет 
    TPhone           Character 	13      -               нет        нет 
    TPropertyNo      Integer        -       -               нет        нет 
    TRent            Numeric   	5       2               750        нет 
    TRooms           Integer        -       -               нет        0,1,2,3,4,5 
    TSchoolDistrict  Character      20      -              'Putnam     'Putnam City', 'Oklahoma City', 'Edmond', 
                                                            City'       'Dallas', 'Richardson', 'Garland', 'Piano' 
    TState 		   Character      2       -               'OK'        'OK', 'TX'
    TTenantNo        Integer        -       -               нет         нет 
    TYesNo           Character      1       -               нет         'Y', 'N', T', 'F' 
    TZip             Character     10       -               '73132'     нет 

    При создании домена TComments обязательно убедитесь в том, что установлен 
флажок Null Values Possible, чтобы для столбцов, создаваемых на основе этого 
домена, не требовалось ввода какого-либо значения (как правило, заполнять поля 
комментариев не обязательно). 
    Определяя домены, устанавливайте флажок Uniformly Used диалогового окна 
Domain Description. При этом атрибуты столбца, к которому вы применяете домен, 
перекрываются атрибутами домена. Включение этого режима приводит к тому, что 
характеристики столбца можно изменить только через изменение характеристик 
соответствующего домена. В рассматриваемом примере это свойство поможет нам 
сохранить целостность структуры данных. Иногда такой режим можно не включать, 
чтобы получить большую гибкость при работе с данными. Например, если вы 
выключите режим Uniformly Used, то сможете устанавливать допустимость 
неопределенных значений не только на уровне домена, но и на уровне столбца. 
    Обратите внимание, что, следуя соглашениям о присвоении имен, 
обсуждавшихся в главе 4, я предваряю все имена доменов заглавной буквой T. 
Такое соглашение совместимо с соглашениями Delphi относительно имен 
компонентов библиотеки VCL. Из всех элементов языка Object Pascal домены 
больше всего напоминают типы данных, поэтому я применил к именам доменов такие 
же соглашения. 

    130     Часть I. Основы 


    Использование словаря данных 

    Определив домены, можно применить их к столбцам таблиц нашей модели. Кроме 
того, нужно связать остальные столбцы с базовыми типами, допустимыми в данной 
СУБД. Для того чтобы решить эту задачу с помощью Silverrun-RDM, проделайте 
следующие операции. 
    1. Щелкните дважды на таблице модели. На экране должно появится диалоговое 
окно Table Columns. 
    2. Щелкните дважды на каждом столбце и установите его домен в соответствии 
с табл. 6.6. Кроме того, в строке Coded Name удалите левую часть кодированного 
имени, представляющую имя сущности, как показано в той же таблице. 
    3. Повторите эти операции для всех таблиц модели. 

    Таблица 6.6. Описание столбцов таблиц реляционной модели 

    Кодированное имя	Домен		Длина		Допустимы ли неопределенные значения 

    Addition		TAddition			нет 
    Address			TAddress			нет 
    BathRooms		TRooms			нет 
    BedRooms		TRooms			нет 
    BeginDate		DATE				нет 
    Call Date		DATE				нет 
    Call Time		CHARACTER	11		нет 
    Call Number		INTEGER			нет 
    CentralAir		TYesNo			нет 
    CentralHeat		TYesNo			нет 
    City			TCity				нет 
    Comments		TComments			да 
    Deposit			TRent				нет 
    Description		CHARACTER	30		нет 
    DishWasher		TYesNo			нет 
    Employer		CHARACTER	30		нет 
    EmiоyerAddress	TAddress			нет 
    EmployerCity		TCity				нет 
    EmployerState		TState			нет 
    EmployerZip		TZip				нет 
    EndDate			DATE				нет 
    GarageType		TRooms			нет 
    GasHeat			TYesNo			нет 
    HomePhone		TPhone			нет 
    ICEPhone		TPhone			нет 
    LastLawnDate		DATE				да 
    Last Spray Date	DATE				да 
    LawnService		TYesNo			нет 
    Lease Number		INTEGER			нет 
    LivingAreas		TRooms			нет 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 131 


    Окончание табл. 6.6. 

    Кодированное имя	Домен		Длина		Допустимы ли неопределенные значения 

    MovedInDate		DATE				нет 
    MovedOutDate		DATE				да 
    Name			CHARACTER	30		нет 
    PetDeposit		Trent				да 
    PrivacyFence		TYesNo			нет 
    Property Number	TPropertyNo			нет* 
    Range			TYesNo			нет 
    Refrigerator		TYesNo			нет 
    Rent			TRent				нет 
    RentDueDay		SMALLINT			нет 
    School District	TSchoolDistrict		нет 
    State			TState			нет 
    Tenant Number		TTenantNo			нет 
    WorkPhone		TPhone			нет 
    Zip			ТZip				нет 

    * за исключением таблицы CALL 

    Ширина столбцов 

    Установив типы данных столбцов, можно заняться вопросами эффективности. 
Зададимся вопросом: "Какой минимальный и максимальный размер данных, 
хранящихся в каждом столбце?" Ниже перечислены некоторые советы, позволяющие 
установить оптимальную, с точки зрения эффективности, ширину столбцов. 
    О Если поле никогда не будет содержать значения, превышающего 255, 
используйте для него 8-битовый тип данных, применяемый в конкретной СУБД. 
    Q Для чисел, не имеющих дробной части, лучше применять тип INTEGER, а не NUMERIC. 
    Q Если длина символьного поля может значительно отличаться в разных 
строках, лучше использовать символьный тип переменной, а не фиксированной длины. 
    Q Если СУБД поддерживает битовые типы данных (например, как SQL Server), 
то для создания столбцов, представляющих булевы значения, применяйте этот тип, 
а не целые или односимвольные типы данных. 

    Генерация кодированных имен 

    Поскольку вы уже сгенерировали кодированные имена на этапе 
ER-моделирования, то повторять этот процесс уже не надо. Более того, так как 
вы только что модифицировали созданные ранее кодированные имена, то повторная 
их генерация приведет к удалению внесенных изменений. Однако для доменов 
генерация кодированных имен не выполнялась. Поскольку такие имена должны 
использоваться в качестве имен элементов модели при генерации сценария DDL (о 
них мы поговорим чуть позже), то без генерации имен доменов обойтись нельзя. 
Это противоречие устраняется следующим образом. 
    1. Выберите команду Project=>Generate Coded Names. В появившемся диалоговом 
окне Coded Names Generation щелкните на кнопке Specify. Появится окно Specification. 
    2. Установите параметры Maximum Length и Nb. of characters used from the 
beginning of each word in the name равными 30 и щелкните на кнопке ОК. 
    3. Убедитесь, что установлен режим частичной, а не полной генерации 
(кнопка режима рядом с кнопкой Specify должна называться Partial). 
    4. Щелкните на кнопке Generate. 

    132     Часть I. Основы 

    Обязательно убедитесь, что кнопка режима называется Partial, а не 
Complete. В противном случае произойдет повторная генерация всех кодированных 
имен модели, и сделанные вами изменения исчезнут. В режиме Complete 
выполняется генерация кодированных имен для всех элементов, независимо от 
того, существуют ли такие имена. И наоборот, режим Partial предназначен для 
генерации кодированных имен только для тех элементов, у которых таких имен еще нет. 

    Описание модели 

    Создание комментариев, описывающих элементы модели, — не только 
похвальное, но и полезное занятие. В некоторых организациях комментирование 
модели данных входит в круг служебных обязанностей разработчиков. Система 
Silverrun-RDM позволяет создавать комментарии произвольного содержания. 
Объекты комментариев включаются в генерируемую процедуру SQL, если СУБД, для 
которой разрабатывается база данных, поддерживает такие комментарии. Для того 
чтобы добавить комментарий к модели в системе Silverrun-RDM, выполните 
следующие операции. 
    1. Щелкните дважды на заголовке объекта таблицы. Появится окно Table Description. 
    2. Щелкните на кнопке Table этого окна и из раскрывающегося списка 
выберите пункт Comment. Появится диалоговое окно (рис. 6.26), в котором можно 
создать комментарий, описывающий таблицу. 
    3. Введите текст комментария и щелкните на кнопке ОК для закрытия окна. 
    Для того чтобы добавить комментарий к определенному столбцу таблицы, 
проделайте следующее. 
    1. Дважды щелкните на объекте таблицы вне заголовка. Появится окно Table Columns. 
    2. В этом окне дважды щелкните на имени столбца, для которого вы хотите 
создать комментарий. Появится окно Column Description. 
    3. Щелкните на кнопке Column и из появившегося раскрывающегося списка 
выберите пункт Comment. Появится окно, с помощью которого можно создать 
комментарий к столбцу (рис. 6.27). 
    4. Введите текст комментария и щелкните на кнопке ОК для закрытия окна. 
    Создание комментариев, описывающих модель, поможет лучше понять назначение 
тех или иных элементов. В крупных проектах, над которыми работает группа 
программистов, комментарии пригодятся не только вам, но и вашим коллегам, 
которые будут использовать созданные вами объекты. 

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

    Последнее, что осталось сделать для завершения модели, — сгенерировать 
спецификации внешних ключей. Внешние ключи — это физическое воплощение связей 
между сущностями, созданными на этапе ER-моделирования. Генерация внешних 
ключей приводит к тому, что указанные в виде таких ключей столбцы заносятся во 
все соответствующие таблицы. Чаще всего таблица заимствует в качестве своего 
внешнего ключа первичный ключ другой таблицы. Заимствованные таким образом 
столбцы или наборы столбцов становятся внешними ключами. 
    Для того чтобы сгенерировать с помощью системы Silverrun-RDM внешние 
ключи, выполните следующее. 
    1. Выберите команду Schema=>Foreign Keys=>Generate. 
    2. Щелкните на кнопке Generate полученного диалогового окна. 
    3. Щелкните на кнопке Save (Сохранить) диалогового окна сохранения файла, 
чтобы принять установленное по умолчанию имя файла. 
    В объектах таблиц модели данных должны появится новые столбцы. Перед 
каждым таким столбцом будут стоять символы FK, указывающие на то, что данный 
столбец является внешним ключом. На рис. 6.28 приведен окончательный вид модели. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер              133 


    Рис. 6.26. С помощью этого диалогового окна можно создать комментарий таблицы 

    Рис. 6.27. С помощью этого диалогового окна можно создать комментарий столбца 

    Часть I. Основы 

    Рис. 6.28. Вид завершенной модели логической структуры данных 

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

    На заметку 
    Одной из примечательных особенностей средства Silverrun-RDM является 
поддержка различных реляционных нотаций, среди которых—системы Information 
Egineering, Information Egineering+, Logical Data Structure и собственная 
нотация системы — Datarun. Если вам не нравится ни одна из стандартных 
нотаций, можете создать собственную, настраивая типы соединительных линий и 
имена моделируемых элементов. Для этого нужно воспользоваться соответствующими 
командами меню, открывающегося при выборе команды Presentation=>Notation. 


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

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

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 135 

    Генерация сценария DDL 

    Операторы SQL, создающие или определяющие объекты, в более общем смысле 
называются операторами DDL (Data Definition Language — язык описания данных). 
Закончив разработку модели, нужно сгенерировать файл сценария DDL, с помощью 
которого выполняется их физическая реализация. Для этого нужно выполнить 
следующие операции. 
    1. Выберите команду Schema=>Generate DDL. 
    2. В открывшемся диалоговом окне выберите переключатель Coded Name и 
щелкните на кнопке Generate. 
    3. В появившемся диалоговом окне сохранения файла укажите имя файла, 
описывающее основную функцию вашей модели, и добавьте расширение SQL. В нашем 
случае файл лучше всего назвать LEASE.SQL. 
    В листинге 6.1 приведено содержимое созданного сценария SQL. Так как в 
самом начале вы выбрали СУБД InterBase, то все сценарии DDL, генерируемые 
системой Silverrun-RDM, будут представлять собой сценарии SQL диалекта InterBase. 

    Листинг 6.1. Файл LEASE.SQL, сгенерированный системой Silverrun-RDM 

    CONNECT "E_R_Diagram_for_Lease_Process" USER " " PASSWORD " "; 
    CREATE DOMAIN TAddition AS CHARACTER(20) NOT NULL CHECK 
    (VALUE IN ('Deerfield', 'Firewheel', 'Legacy Hills', 'Switzerland 
Estates', 'Sherwood', Rockknoll') ) ; 
    CREATE DOMAIN TAddress AS CHARACTER(30) NOT NULL; 
    CREATE DOMAIN TCity AS CHARACTER(30) NOT NULL CHECK (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 (VALUE IN ('OK', 
'TX')) ; 
    CREATE DOMAIN TTenantNo AS INTEGER NOT NULL; 
    CREATE DOMAIN TYesNo AS CHAR(1) NOT NULL CHECK (VALUE IN ('Y', 'N')) ; 
    CREATE DOMAIN TZip AS CHARACTER(10) NOT NULL; 

    CREATE TABLE PROPERTY 
   ( Property_Number PropertyNo 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, 

    136 Часть I. Основы 

     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 NOT NULL, 
     LastSprayDate      TYesNo NOT NULL, 
     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 NOT NULL, 
     PRIMARY KEY (Tenant_Number) 
   );
    
   CREATE TABLE CALL 
   ( Call_Number        INTEGER NOT NULL, 
     CallDate          DATE NOT NULL, 
     CallTime          CHARACTER(11), 
     Description        CHARACTER(30) NOT NULL, 
     Property_Number    TPropertyNo, 
     PRIMARY KEY (Call_Number), 
     CONSTRAINT FK_PROPERTY1 
       FOREIGN KEY (Property__Number) 
         REFERENCES PROPERTY 
    ); 
    
    CREATE TABLE LEASE 
    ( LeaseJMumber       INTEGER NOT NULL, 
      BeginDate          DATE NOT NULL, 
      EndDate            DATE NOT NULL, 
      MovedInDate        DATE NOT NULL, 
      MovedOutDate       DATE NOT NULL, 
      Rent               TRent NOT NULL, 
      PetDeposit         NUMERIC(5, 2) NOT NULL, 
      RentDueDay         SMALLINT NOT NULL, 
      LawnService        TYesNo NOT NULL, 
      Comments           TComments NOT NULL, 
      Property_Number    TPropertyNo NOT NULL, 
      Tenant_Number      TTenantNo NOT NULL, 
      PRIMARY KEY (Lease_Number), 
      CONSTRAINT FK_PROPERTY2 
        FOREIGN KEY (Property_Number) 
          REFERENCES PROPERTY,     
      CONSTRAINT FK_TENANT3 
       FOREIGN KEY (Tenant_Number) 
         REFERENCES TENANT 
    ); 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер 137 

    Как можно заметить из листинга, я изменил порядок следования столбцов 
таблицы RPOPERTY, чтобы они располагались более логично. Поскольку сущность 
PROPERTY была создана экспертом нормализации, ее столбцы были расположены 
несколько бессистемно. Упорядочение таблиц облегчает как управление базой 
данных, так и разработку приложения, использующего эти таблицы. 
    Обратите внимание, что сценарий начинается с создания логических доменов, 
которые вы определили в качестве доменов InterBase. Данные объекты доменов 
впоследствии используются для определения таблиц базы данных. Это именно то, 
что нужно. Заданные бизнес-правила выполняются с максимальной точностью с 
помощью повторно используемых объектов доменов. При необходимости эти объекты 
можно применить для создания новых столбцов. Например, если вам понадобится 
создать еще один столбец, содержащий значения Yes/No, можно воспользоваться 
доменом TYesNo. В этом состоит преимущество внедрения бизнес-правил 
посредством доменов, а не с помощью самих столбцов. 
    В полученном сценарии есть одна проблема — в его начале указан оператор 
CONNECT, который, на самом деле, не сможет подключится к базе данных 
InterBase, так как в качестве имени базы данных использовано имя модели. 
Конечно, можно исправить это оператор, указав правильное имя базы данных и 
другие параметры, однако есть лучший способ. 
    Поскольку модель была получена путем преобразования диаграммы 
"сущность-связь", в ней содержится заголовок, созданный средством 
Silverrun-ERX. Давайте изменим его, чтобы показать, что теперь наша модель 
является законченной реляционной моделью. 
    Для этого выберите команду Schema=>Schema Description и введите в строке 
Local Name открывшегося окна текст Relational Data Model for Lease Process 
(рис. 6.29). Затем в качестве параметра Coded Name укажите корректное имя базы 
данных СУБД InterBase. Я, например, использовал путь с:\DATA\RENTMAN\RENTMAN.GDB, 
так как именно в этом каталоге и под таким именем я собираюсь хранить объекты, 
созданные сценарием DDL. 

    Рис. 6.29. Использование диалогового окна Schema Description для 
определения имени модели 

    138      Часть I. Основы 

    Обязательно сохраните модель, так как она будет использоваться в следующей 
части этой книги, "Учебный курс". Лучше всего использовать имя LEASE.DRM. 
    Изменив имя базы данных реляционной модели, нужно выполнить повторную 
генерацию сценария DDL. Снова выберите команду Schema=>Generate DDL и создайте 
файл LEASE.SQL (не забудьте выбрать переключатель Coded Name). В новой 
версии сценария оператор CONNECT будет заменен на следующий оператор. 

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

    Теперь можно отредактировать исходный текст сценария и указать правильные 
имя пользователя и пароль. Например, можно задать в качестве имени 
пользователя стандартный идентификатор SYSDBA и соответствующий ему 
используемый по умолчанию пароль. 

    CONNECT "C:\DATA\RENTMAN\RENTMAN.GDB" USER "SYSDBA" PASSWORD "masterkey"; 

    Хорошим средством редактирования сценария SQL является сама система 
Delphi. Входящий в состав интегрированной среды разработки Delphi редактор 
умеет различать сценарии и процедуры SQL и использовать для них синтаксическое 
выделение, а также открывать соответствующие базы данных через Database 
Explorer. На рис. 6.30 представлен вид окна редактирования Delphi с загруженным 
в него сценарием LEASE.SQL. 

    Рис. 6.30. Для модификации сценариев SQL можно воспользоваться встроенным 
редактором Delphi 

    Мой любимый текстовый редактор для Windows — Multi-Edit for Windows. Для 
программиста это просто незаменимый инструмент. Он обладает всеми 
средствами, необходимыми для редактирования исходных текстов программ, включая 
поиск по выражениям, фильтрацию текста, поддержку редактирования файлов очень 
большого объема, а также интеграцию с компиляторами всех основных языков 
программирования (С, HTML, Pasal, Basic и т.д.). Интеграция с Delphi настолько 
хороша, что вы можете использовать Multi-Edit вместо встроенного редактора 
Delphi без каких-либо неудобств в работе. 

    Глава 6. Проектирование базы данных архитектуры клиент/сервер              139 

    Именно поэтому для редактирования сценариев SQL я часто пользуюсь 
редактором Multi-Edit, а не встроенным редактором Delphi. Я настроил средства 
поддержки языков программирования, имеющиеся в MultiEdit, для работы с 
утилитами командной строки SQL (например, ISQL, WISQL, SQL*Plu5 и т.д.). Это 
позволяет мне выполнять сценарии SQL и автоматически отслеживать появляющиеся 
ошибки. Добавьте к этому синтаксическое выделение конструкций SQL, имеющееся в 
Multi-Edit, и вы получите неподражаемый редактор SQL. За более подробной 
информацией обращайтесь в компанию American Cybernetics, разработавшую Multi-Edit.
    Система Silverrun-RDM обладает средствами специальной поддержки Delphi и 
наборов атрибутов Delphi. С помощью этих средств можно по созданной 
реляционной модели получить наборы атрибутов Delphi, которые затем могут быть 
использованы при разработке приложения. Более подробно мы поговорим об этой 
возможности в части "Учебный курс", которая начинается с главы 8. 

    Запуск сценария на выполнение 

    Закончив последнюю доработку сценария, вы получили практически завершенный 
физический проект базы данных. Теперь можно запустить этот сценарий на 
выполнение и создать базу данных. Хотя пока что в этом нет особой 
необходимости, но увидеть воочию результаты такого титанического труда — 
всегда приятно и желанно. Итак, чтобы создать базу данных RENTMAN, запустите 
утилиту WISQL InterBase, выберите из меню File команду Run an ISQL Script, а 
затем откройте только что созданный файл сценария. Запустив сценарий на 
выполнение с помощью кнопки Run, вы тем самым создадите базу данных RENTMAN. 
    Прежде чем выполнять сценарий, нужно запустить программное обеспечение 
сервера InterBase. Для этого можно воспользоваться пиктограммой InterBase 
Server 4.2, находящейся в папке InterBase 4 .2 (если, конечно, при установке 
Delphi Client/Server вы установили InterBase). 

    Резюме 

    Из этой главы вы узнали как связаны между собой моделирование процессов 
предметной области, моделирование сущностей и связей и моделирование 
реляционных структур данных. Начав с одной идеи, вы создали все необходимое 
для функционирования приложения RENTMAN. В конце главы были получены три 
модели, представляющие три разные аспекта приложения и базы данных. Я надеюсь, 
что выбранный мною подход помог вам разобраться в методике проектирования и 
создания баз данных. Эта методика универсальна — ею можно пользоваться 
независимо от применяемых средств автоматизации разработки. 
    Создав львиную долю базы данных RENTMAN, вы тем самым уменьшили объем 
работы, которую вам придется проделать в следующей части, "Учебный курс". В 
ней вы будете использовать только что созданную базу данных в качестве основы 
полнофункционального приложения архитектуры клиент/сервер. Даже если вы 
пропустите следующую часть, все равно эта глава дала вам хорошие основы 
проектирования баз данных клиент/сервер. С помощью приведенной методики можно 
смело приступать к разработке реальных проектов. 

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

    Глава 7, "Проектирование приложения архитектуры клиент/сервер", продолжает 
обсуждение пяти основных этапов разработки приложений баз данных и, развивая 
тему, показывает, как они применяются в проектировании приложений. В этой 
главе мы рассмотрим всю гамму вопросов, связанных с проектированием 
приложений, — от выбора лейтмотива пользовательского интерфейса до создания 
форм ввода данных и поддержки решений. Глава 7 дополняет эту главу, добавляя к 
полученным вами знаниям о проектировании баз данных углубленные сведения о 
подходах, применяемых к проектированию приложений. 

    140     Часть I. Основы 
