    20     ГЛАВА 

    Бизнес-правила и сервер базы данных 

    Бизнес-правилами (business rule) называются ограничения, спецификации или 
критерии, описывающие принятые в организации соглашения по ведению учета и 
отчетности. Их можно описать на языке, понятном для людей без специального 
образования, но обладающих знаниями в соответствующих областях бизнеса. 
Специалисты по базам данных переносят эти правила в базы данных и приложения. 
Вот несколько примеров .типичных бизнес-правил. 
    Q	Все арендаторы должны предоставлять полную информацию о себе. 
    О	Стандартная арендная плата составляет $950 в месяц. 
    О	Сумма гарантийного депозита должна составлять не меньше половины 
арендной платы. 
    О  Арендная плата считается просроченной по истечении пяти дней с дня 
оплаты, указанного в договоре об аренде. 
    D За каждый просроченный день взимается пеня в размере $5. 
    Q  Лица, которые арендуют более одного объекта недвижимости, получают 
скидку в размере  10% при аренде каждого дополнительного объекта. 
    Q  Минимальный срок действия всех договоров об аренде — шесть месяцев. 
    О  Не разрешается поселение арендаторов в арендуемых объектах недвижимости 
до начала срока аренды, указанного в договоре. 
    Каждому из таких правил соответствует тот или иной элемент базы данных или 
программы. Для служащих, отвечающих за внедрение и соблюдение этих правил, 
имеет значение корректная словесная формулировка. Для разработчиков приложений 
имеет значение корректное воплощение бизнес-правил в соответствующих объектах 
базы данных и приложения. Чем больше опыта имеет разработчик систем 
клиент/сервер, тем лучше он разбирается как в словесных формулировках 
бизнес-правил, так и в их тонкостях их реализации. 
    В этой главе рассматривается реализация бизнес-правил в серверной части 
приложений баз данных архитектуры клиент/сервер. Иногда бизнес-правила 
рассматриваются как теоретическая концепция отдельно от ограничений баз данных 
и программных объектов, необходимых для их реализации. Я согласен с тем, что 
для реализации бизнес-правил необходимо полное понимание потребностей 
соответствующей организации, но все же считаю ошибкой отделять теорию от 
практики, тем более, что в конце концов бизнес-правила должны воплотиться в 
виде реальных объектов базы данных или приложения. 
    Реализация бизнес-правил без учета ограничений, накладываемых 
необходимостью обеспечения целостности данных, как мне кажется, является 
недальновидной, поскольку на самом деле правила и данные тесно взаимосвязаны. 
Обеспечение целостности данных — эта основа основ работы информационной 
системы любой организации. Никто не хочет иметь базу данных, переполненную 
строками с незаполненными полями, недопустимыми значениями и другими 
неприятными вещами. С другой стороны, если в информационной системе 
обеспечиваются целостность и достоверность данных, то организация может смело 
полагаться на работу такой системы. Вот почему бизнес-правила и целостность 
данных неразрывно связаны. 
    Существуют три различных мнения по вопросу о наиболее подходящем месте 
воплощения бизнес-правил: серверная часть системы клиент/сервер, ее клиентная 
часть или вспомогательное программное обеспечение (middleware). He вызывает 
сомнений, что в реальном приложении архитектуры клиент/сервер любой сложности 
эти подходы будут сочетаться. Это так же верно, как и то, что вначале система будет 

    414 IV. Темы повышенной сложности 

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

    Определение бизнес-правила 

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

    На заметку 

    В этой главе я часто использую понятия бизнес-правила и ограничения 
(constraint), имея ввиду одно и то же. Ограничения — это основная форма 
реализации бизнес-правил в базах данных и приложениях. Мне никогда не 
нравилось слово ограничение — они не обязательно что-то ограничивают. Иногда 
они определяют стандартные параметры столбцов или связь между таблицами. В 
этой главе термин бизнес-правила часто используется в качестве эквивалента для 
соответствующих им элементов баз данных и приложений. 
    Однако недостаточно просто защитить базу данных от проникновения 
недопустимых данных. На самом деле реализация бизнес-правил в базах данных 
преследует три различные цели: не допустить появления нежелательных данных, 
определить связь между столбцами и таблицами и описать способ появления данных 
в базе. Рассмотрим отдельно каждую из этих целей. 
    Появление некорректной информации в базе данных предотвращают ограничения. 
Они также определяют данные, содержащиеся в столбцах по умолчанию, если не 
поступила другая информация. Типичный пример ограничения: "Все счета должны 
содержать достоверную информацию о покупателе". На языке баз данных это 
означает, что на данные содержащиеся в таблице СЧЕТ, наложено ограничение. Вот 
еще один пример ограничения: "Допустимыми значениями элементов столбца 
СредствоОплаты являются 'Нал', 'Чек', 'КрК'". Ограничение, которое определяет 
значение, используемое по умолчанию для этого столбца, может быть выражено 
следующим образом: "По умолчанию в качестве средства оплаты используются наличные". 
    Бизнес-правила могут также определять зависимость между таблицами 
(например, "Каждому счету должен соответствовать хотя бы один заказ") и между 
столбцами таблицы (такие как "Значение в столбце Комиссионные таблицы СБЫТ 
равно значению в столбце объемПродаж, умноженному на 0.07"). Лично я 
предпочитаю из-бегатьдависимости между столбцами таблицы, по возможности 
производя подобные вычисления во время рабо-~ты приложения, но это не всегда 
возможно. В данном примере столбец Комиссионные зависит от столбца 
ОбъемПродаж. Очевидно, такая зависимость не позволяет полностью нормализовать таблицу. 
    Бизнес-правила могут использоваться для описания происхождения данных. 
Описание происхождения элемента определяет его источник. Откуда взят элемент 
базы данных? Как он был получен, рассчитан или произведен? Является ли он 
суммой элементов в столбце х таблицы Y? Вот простой пример: "Баланс по 
кредиторской задолженности в главной книге обновляется при проводках по счетам 
кредиторской задолженности путем добавления итоговых сумм". Это правило 
описывает происхождение или источник данных баланса по кредиторской 
задолженности главной книги. 
    Как было сказано выше, лучше избегать определения одного элемента через 
другой. Это не означает, что такие вещи недопустимы. Однако, поступая так, 
следует внимательно рассмотреть все возможные последствия. Получение одного 
элемента данных на основании другого приводит к возникновению зависимости 
между этими элементами. Иногда это необходимо, но в некоторых случаях может 
привести к разного рода неприятностям. Если исходные данные меняются, то 
зависимые от них данные также должны измениться. Обычно для решения этой 
проблемы используются механизмы принудительного сохранения 

    Глава 20. Бизнес-правила и сервер базы данных	415 

(posting) информации в базе данных. При таком сохранении до тех пор, пока 
не будут обновлены все элементы, зависящие от сохраняемых данных (как в 
предыдущем примере с главной книгой), сами данные остаются недоступными для 
редактирования. Системы, не содержащие связей такого типа, часто называют 
неблочными (bucketless), поскольку они не используют методов получения одних 
данных на основе других, хранящихся в тех или иных частях базы данных, 
называемых блоками (bucket). 
    Сейчас, когда вы поближе познакомились с бизнес-правилами, возникает 
вопрос: как их лучше реализовать? Как я уже сказал, существуют три разных 
мнения о том, какое место является наиболее подходящим для реализации 
бизнес-правил. Выбор во многом зависит от способа реализации. Очевидно, что 
реализация бизнес-правил на сервере происходит путем создания ограничений. 
Реализация их в клиентной части системы клиент/сервер осуществляется в 
программном коде. Возложение ответственности за соблюдение бизнес-правил на 
вспомогательные программы подразумевает использование тех или иных средств 
таких программ, позволяющих выполнение операций такого рода. 

    Реализация бизнес-правил на сервере 

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

    Преимущества реализации на уровне сервера 

    Одним из преимуществ размещения механизма выполнения бизнес-правил на 
сервере является защищенность данных от намеренной подделки и случайных 
искажений. Поскольку средства управления имеют встроенные связи с данными, 
ограничения уровня серверной части обеспечивают гарантию достоверности данных 
и защиты их от случайного удаления. 
    Другим преимуществом реализации бизнес-правил на уровне сервера является 
автоматическое предоставление доступа к правилам всем клиентным приложениям, 
работающим с базой данных. Большим недостатком реализации бизнес-правил в 
клиентной части системы клиент/сервер является то, что средства разработки 
таких приложений часто зависят от типа операционной системы или аппаратной 
платформы. При серверной реализации эта проблема не возникает. Все основные 
производители СУБД клиент/сервер поддерживают работу своих продуктов с 
клиентными приложениями, работающими на различных платформах. Независимо от 
операционного окружения приложения, оно имеет доступ к информации о 
бизнес-правилах, хранимой на сервере, и действует в рамках этих правил. 
    Еще одна выгода от размещения бизнес-правил на сервере — это скорость. 
Поскольку организации обычно склонны рассматривать затраты на покупку сервера 
баз данных как инвестиции в инфраструктуру, они охотнее приобретут аппаратуру 
и программное обеспечение, которые гарантируют оптимальную работу сервера. 
Если реализация бизнес-правил на сервере сильно снижает его быстродействие, 
корпорация скорее согласится приобрести дополнительные ресурсы для решения 
этой проблемы, чем купить высокопроизводительные компьютеры для пользователей, 
даже если стоимость сервера превысит стоимость всех компьютеров пользователей, 
    Еще одним аргументом в пользу рассматриваемого подхода является 
масштабируемость большинства серверов. Если ваши потребности превысили 
максимальные возможности используемой аппаратной платформы, можно перенести 
сервер вместе с банком данных на более мощную платформу, не покупая другую 
СУБД и не переделывая свою базу данных. В этом пункте реализация бизнес-правил 
на уровне сервера стоит вне конкуренции, поскольку при их реализации на уровне 
приложения или вспомогательных программ, по крайне мере, сегодня, 
масштабирование недоступно. Если ваши приложения работают в Windows, вы в 
значительной степени ограничены платформой Intel. Конечно, Windows NT работает 
и на некоторых других платформах, но все же эта система не столь переносима, 
как СУБД Sybase SQL Server, разработанная для подавляющего большинства 
основных аппаратных платформ и операционных систем. 

    416 IV. Темы повышенной сложности 

    Недостатки реализации на уровне сервера 

    Одним из слабых мест серверной реализации является снижение 
производительности сервера, пропорциональное степени его загрузки. По мере 
наложения ограничений на объекты базы данных доступ к ним (в частности, при 
обновлении) резко замедляется. Слишком сильное замедление может сделать 
невозможным применение сервера. 
    Однако для решения этой проблемы не обязательно переносить бизнес-правила 
на уровень приложения или вспомогательных программ. Достаточно применить тот 
же подход, что и в случае стремительного роста объема данных. В этом случае 
снижение производительности сервера также может привести к невозможности его 
использования. Вложите деньги в программные и аппаратные ресурсы, необходимые 
для приведения сервера в норму. Внезапное увеличение объема данных — еще не 
повод выбросить сервер и вернуться к локальным СУБД. Это справедливо и в 
отношении бизнес-правил: относитесь к их реализации на сервере как к 
неотъемлемой части базы данных и важному элементу сервера. Такой подход 
облегчит принятие решения по выделению средств для поддержки реализации 
бизнес-правил на сервере. 
    Другим недостатком, на который часто указывают противники размещения 
бизнес-правил на сервере, является ориентация на конкретную базу данных или 
сервер. Это означает, что перенос ограничений между базами данных или 
серверами очень затруднен или вообще невозможен. Существует вероятность того, 
что при проверке правильности данных, введенных в одном из столбцов, одна 
таблица не найдет другую по ссылке, или таблица на одном сервере не сможет 
заимствовать данные, которые должны использоваться по умолчанию, из таблицы на 
другом сервере. Это может вызвать проблемы, поскольку организации часто 
распределяют серверы между отделами. 
    Выход заключается в том, чтобы оказать давление на производителей СУБД и 
заставить их улучшить взаимодействие между базами данных и между серверами. 
Sybase, к примеру, уже несколько лет поддерживает обработку запросов между 
базами данных. Более того, такие технологии, как Sybase Replication Server, 
позволяют решить и проблему взаимодействия между серверами путем 
автоматического копирования ключевых таблиц с одного сервера на другой. А 
появление серверов-шлюзов сделало возможными и гетерогенные запросы. Все это 
позволяет осуществлять запросы к таблицам под управлением СУБД различных 
производителей так же, как если бы они находились на одном сервере. 
Независимость от конкретных сервера и базы данных заключается не в смене 
технологии на другую, менее совершенную, а в том, чтобы заставить современных 
производителей улучшить совместимость их продуктов с другими серверами и 
базами данных. 
    Еще одной проблемой реализации бизнес-правил на уровне сервера является 
недостаточная интеграция между программным обеспечением клиентной и серверной 
части системы клиент/сервер. Одно из следствий — частое неправильное понимание 
или полное игнорирование клиентной частью системы клиент/сервер сообщений 
сервера, имеющих отношение к бизнес-правилам. 
    Решением этого вопроса также не является отказ от серверной реализации. 
Вместо этого необходимо оказать давление на производителей инструментальных 
средств разработки клиентного программного обеспечения (таких как Borland) и 
потребовать полной интеграции их продуктов с поддерживаемыми серверами. 
Другими словами, если Delphi поддерживает какую-то конкретную СУБД архитектуры 
клиент/сервер, то эта поддержка должна быть полной и включать в себя поддержку 
всех возможностей данной платформы, имеющих отношение к приложению, в том 
числе и определение случаев нарушения бизнес-правил. 

    j    Преимущества реализации на уровне приложения 

    Одним из преимуществ реализации бизнес-правил на уровне приложения 
является удобство настройки и контроля сообщений и ответов, связанных с 
бизнес-правилами. На уровне приложения проверить несколько полей, как правило 
не составляет большого труда. Например, довольно просто не допустить выхода 
пользователя из формы, пока все введенные им данные не будут находиться в 
допустимом диапазоне. 
    Другим преимуществом клиентской реализации является богатство языков 
программирования, используемых для создания приложений. Так, Object Pascal 
намного богаче SQL. Даже BASIC превосходит SQL. 
    Последним аргументом в пользу реализации бизнес-правил на уровне 
приложения является возможность повторного использования компонентов, 
содержащих бизнес-правила, всеми приложениями, созданными с помощью данного 
средства разработки. Чтобы добавить бизнес-правило в приложение, достаточно 
просто перетащить в форму соответствующий компонент. Этот процесс описывается 
в главе 21,-" Бизнес-правила в приложениях Delphi" . 

    Глава 20. Бизнес-правила и сервер базы данных	417 
    14 Delphi 3 и системы клиент/сервер 

    Недостатки реализации на уровне приложения 

    Основной недостаток принципа размещения бизнес-правил исключительно на 
уровне приложения состоит в том, что появляется необходимость в более мощных 
рабочих станциях. Еще несколько лет назад ресурсов, необходимых сегодня для 
работы клиентной части систем клиент/сервер, было вполне достаточно для 
организации хорошего сервера. Поток жалоб пользователей на производительность 
прекратится только после того, как вы установите на их машинах самые новые, 
самые лучшие аппаратные средства, которые только сможете найти. Приложения, 
перегруженные задачами реализации бизнес-правил, требуют больше памяти и 
работают медленнее других. Это особенно заметно, когда реализация 
бизнес-правил в приложении требует от него отправки запросов на сервер. 
Например, если приложение должно отсылать на сервер запросы для определения 
типа данных в некотором столбце, чтобы потом наложить на них ограничения, то 
работы оказывается слишком много. Гораздо лучше предоставить это дело серверу, 
с которым он хорошо справляется. 
    Создав приложение, которое без особой надобности обращается к серверу за 
информацией, необходимой для использования ограничений, вы сталкиваетесь с 
проблемой "болтливой медсестры". Медсестра пытается самостоятельно 
прооперировать пациента, но из-за отсутствия квалификации вынуждена постоянно 
обращаться к хирургу. Из-за того, что хирург тратит время, ассистируя 
медсестре, он не может сам провести операцию. А поскольку медсестра, как бы 
точно она ни выполняла указания хирурга, не сможет полностью его заменить, ее 
попытка прооперировать больного также обречена на неудачу. Это наглядный 
пример того, как иногда все ставится "с ног на голову". Та же ситуация 
возникает при переносе бизнес-правил с сервера баз данных на уровень приложения. 
    Постоянное обновление аппаратных средств для работы клиентной части систем 
клиент/сервер — неиссякаемый источник головной боли для программиста, 
вызванной необходимостью перенастройки программной и аппаратной конфигурации. 
Исторически сложилось так, что постоянная настройка и подбор аппаратных 
средств является атрибутом серверов. Не нужно становится на этот путь по 
отношению к рабочим станциям — в конце концов вы получите на каждом рабочем 
столе по серверу, для которых потребуется дополнительный обслуживающий 
персонал и специалисты. 
    Этот подход также вступает в противоречие с одним из основных принципов 
философии клиент/сервер — уменьшение потребности клиентной части системы в 
ресурсах. Причиной возрастающей популярности СУБД клиент/сервер является 
выполнение сервером основной работы, что позволяет использовать в качестве 
рабочих станций менее мощные компьютеры. Предполагается, что необходимость в 
увеличении ресурсов удовлетворяется, в первую очередь, за счет сервера, а не 
за счет рабочих станций. Модель "сервер на столе у пользователя" прямо 
противоречит этому подходу. 
    Еще одной проблемой, возникающей при реализации бизнес-правил в 
приложениях, является невозможность переноса такой реализации между различными 
средствами разработки, не говоря уже о продуктах различных производителей. Это 
означает, что если сегодня вы должны написать приложение, обновляющее данную 
таблицу, в Delphi, а через неделю — в Oracle Developer/2000, то придется 
заново изобретать велосипед. Так как Developer/2000 не сможет получить доступ 
к бизнес-правилам, встроенным в приложение Delphi, придется переписать эти 
правила с использованием инструментов данной среды разработки. Еще более 
мрачно выглядит перспектива работы на различных платформах. Возможно, вам 
удастся оформить бизнес-правила в виде набора компонентов Delphi и затем 
использовать этот набор в приложениях Delphi и Borland C++, добившись таким 
образом совместимости с другой средой разработки. Но что вы скажете, если те 
же бизнес-правила необходимо будет встроить в программу, написанную на С и 
работающую в символьном ре жиме в среде UNIX? 
    Кроме того, встраивание бизнес-правил в приложения вместо сервера 
исключает возможность просмотра всех бизнес-правил базы или банка данных из 
одной точки. Поскольку все правила встроены в программный код или объекты, 
нелегко определить, какие ограничения налагаются на какие данные. Для этого 
придется при разработке баз данных любой сложности постоянно пользоваться 
каким-нибудь CASE-средством. Серверная реализация исключает такую проблему. 
    Наконец, приведем последний аргумент в пользу ошибочности реализации 
бизнес-правил на уровне приложения. Хотя конкретное приложение или средство 
предотвращает проникновение в базу недопустимых данных, сама база данных 
остается незащищенной. В результате она чрезмерно зависит от средств 
разработки клиентного программного обеспечения. Ослабить эту зависимость не 
так-то легко. Дальнейшую разработку клиентного программного обеспечения 
приходится проводить с использованием однажды выбранного средства. В противном 
случае бизнес-правила будут игнорироваться или их придется реализовать заново. 
Конечно, это весьма по душе производителям средств разработки программного 
обеспечения, но для вас такая стратегия не очень хороша. Намного лучше 
поместить бизнес-правила на сервер, где они будут соблюдаться независимо от 
типа приложения и смогут совместно использоваться всеми приложе-. ниями, как 
это и должно быть . 

    418 IV. Темы повышенной сложности 

    Преимущества реализации бизнес-правил на уровне вспомогательных программ 

    Вспомогательными программами называются программы, работающие на 
промежуточном уровне между клиентной и серверной частью системы. Его основная 
функция — отделить приложения от сервера, а сервер — от приложений. Все 
взаимодействие приложений и сервера происходит через эти вспомогательные 
программы. Таким образом, к категории вспомогательных программ относится любой 
программное обеспечение, работающее между приложением и сервером базы данных. 
Это может быть система, предоставляющая интерфейс прикладным программам для 
доступа к базам данных, например BDE, или сервер приложений, такой как 
OLEntreprise, входящий в состав Delphi 3 варианта Client/Server. Формы 
вспомогательных программ могуГбыть различными. Концептуально реализация 
бизнес-правил на этом уровне могла бы стать наилучшим из возможных вариантов. 
В идеальном случае бизнес-правила были бы определены в объектах операционной 
системы, которые, в свою очередь, ссылались бы на объекты сервера баз данных. 
Некоторые операционные системы, например NeXTSTEP Стива Джоба (Steve Job), 
далеко продвинулись в этом направлении. 
    Использование вспомогательного программного обеспечения позволило бы 
устранить сегодняшние ЛЕЩНО-Ш? реализации бизнес-правил для нескольких 
серверов или баз данных, так как в этом случае пра-вила_не принадлежат 
конкретной базе данных или серверу. 
    Такой подход позволил бы также избежать проблем вида "все на сервере" или 
"сервер у каждого пользователя". Бизнес-правила не перегружали бы ни сервер, 
ни приложения. Не нужно было бы вкладывать деньги в настольные компьютеры, 
работающие со сверхзвуковой скоростью, чтобы серверы не стонали под тяжестью бизнес-правил. 
    В Delphi поддерживаются так называемые брокеры ограничений и данных, 
использование которых позволяет легко создавать мощные серверы приложений. Это 
делает программирование многоуровневых приложений клиент/сервер не более 
сложным, чем традиционных двухуровневых. Более подробно об этом будет 
рассказано в главе 22, "За пределами двухуровневой модели". 

    Недостатки реализации бизнес-правил на уровне вспомогательных программ 

    Самая большая проблема этого подхода — необходимость создания еще одной 
части системы, кроме обязательных клиентной и серверной. К тому же, поскольку 
бизнес-правила больше не локализованы в одном месте, то просмотреть их все из 
одной точки уже невозможно. Правила больше не принадлежат исключительно 
серверу или приложению — они распределены по всем трем слоям, что затрудняет 
управление. Итак, возникают две проблемы: лишняя работа по развитию системы — 
многие из правил, реализованных в промежуточном слое, нужно реализовать также 
и на сервере — и дополнительные трудности управления бизнес-правилами, так как 
теперь они распределены по нескольким архитектурным слоям. 

    Реализация бизнес-правил на сервере 

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

    Лиха беда - начало 

    Первое, что нужно сделать при создании бизнес-правил, — это построить 
модель процессов предметной области разрабатываемой системы клиент/сервер. 
Этот этап, без сомнения, потребует тесного взаимодействия с пользователями. 
Обсуждение с ними процессов, которые призвано автоматизировать данная система, 
поможет заблаговременно определить необходимые связи между объектами и 
ограничения для объектов баз данных и приложения. 

    Глава 20. Бизнес-правила и сервер базы данных	419 

    Прежде всего нужно определить бизнес-правила двух основных классов: 
обеспечивающие целостность доменов (domain integrity) и ссылочную целостность 
(relational integrity). Целостность доменов означает соответствие данных типу, 
который может содержаться в конкретном столбце. Например, столбец дат должен 
содержать только корректные даты, а допустимые значения данных в столбце вида 
оплаты — наличные, чек или кредитная карточка. Бизнес-правила, контролирующие 
целостность доменов, могут быть реализованы с помощью ограничений столбцов 
базы данных. 
    Ссылочная целостность означает соблюдение соответствующих отношений между 
таблицами. Например, если строка таблицы СЧЕТ содержит ссылку на строку 
таблицы КЛИЕНТ, то ограничения ссылочной целостности гарантируют невозможность 
удаления строки из таблицы КЛИЕНТ до тех пор, пока существует соответствующая 
ей строка в таблице СЧЕТ. 
    Необходимо как можно раньше сформулировать исчерпывающее определение всех 
правил, которые будут применяться к соответствующим данным. Лучше всего 
записать их в виде простых предложений, например. 
    Q	Номера счетов в таблице СЧЕТ должны быть уникальными. 
    Q	Каждому номеру заказчика в таблице СЧЕТ должна соответствовать строка в 
таблице КЛИЕНТ. 
    О	К оплате принимаются кредитные карточки VISA, MasterCard и American Express. 
    О  По каждому наименованию в счете подводится итог путем умножения 
стоимости единицы товара на заказанное количество этого товара. 
    О   Итоговая сумма вычисляется путем суммирования всех промежуточных 
итогов плюс 7% налога на продажу и $5 — за обработку и отправку. 
    Q Заголовок счета не может быть удален, пока в этом счете есть хоть одна 
запись. Q  Используемый по умолчанию метод доставки — через компанию Federal Express. 
    Рассмотрению подлежат все столбцы таблиц. В каждом столбце должны 
содержаться только допустимые данные. Необходимо установить виды связей между 
таблицами и способ их защиты. Все необходимые вычисления и источники данных 
должны быть оговорены заранее. Прежде, чем приступать к работе, обсудите с 
вашим заказчиком достоверность и полноту полученного списка бизнес-правил. 
Позже, когда соответствующие ограничения будут созданы и останется только 
встроить их в базу данных, вы сверите их одно за другим с бизнес-правилами из 
списка. Проявленная на этом этапе скрупулезность сохранит вам впоследствии 
время и нервы. 
    Многие CASE-средства, предназначенные для разработки приложений 
архитектуры клиент/сервер, обладают всеми возможностями, необходимыми для 
реализации бизнес-правил, — начиная от записи формулировок бизнес-правил и 
заканчивая созданием шаблонов триггеров, необходимых для их реализации. Если в 
сложной базе данных нужно реализовать много бизнес-правил, хорошее 
CASE-средство позволит сэкономить не один час работы. 

    Ограничения первичного ключа 

    Ограничения, налагаемые на таблицы и столбцы, являются наиболее популярным 
средством реализации бизнес-правил на сервере. Хотя триггеры могут делать то 
же самое и даже больше, я придерживаюсь в этом вопросе следующей философии. 
    Ограничения всегда предпочтительнее триггеров. Реализуйте максимально 
возможное количество бизнес-правил с помощью ограничений, а остальные — с 
помощью представлений, триггеров и хранимых процедур. 
    Ограничения предпочтительнее, поскольку работают быстрее триггеров. Это 
связано с тем, что ограничения выполняются ядром серверной части системы, 
которое в подавляющем большинстве случаев состоит из машинного кода, 
полученного в результате компиляции исходного текста на языке С. Триггеры, 
напротив, представляют собой частично откомпилированные операторы SQL. 
Машинный код почти всегда выполняется быстрее, чем частично откомпилированный. 
По этой же причине предпочтительнее использовать представления, чем триггеры. 
Синтаксические конструкции WITH CHECK OPTION в представлениях ANSI SQL также 
выполняются ядром сервера, без использования SQL. Однако триггеры все же лучше 
хранимых процедур, поскольку выполняются автоматически. Встраивание 
бизнес-правил в хранимые процедуры имеет еще один недостаток. При обновлении 
основной таблицы процесс может пропустить процедуру и таким образом обойти бизнес-правило. 
    Первый тип применяемых ограничений — ограничения первичного ключа (primary 
key constraint). Такие ограничения определяют, в каком столбце содержатся 
данные, однозначно характеризующие каждую из строк. Первичный ключ — это 
используемый по умолчанию метод доступа к таблице. Например, первич

    420 IV. Темы повышенной сложности 

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

    ALTER TABLE  CLIENT ADD  PRIMARY  KEY   (CustomerNumber) 


    Ограничения внешнего ключа 

    Ограничения внешнего ключа (foreign key constraint) часто используются при 
определении связей между таблицами. Это приводит к появлению данных одного из 
столбцов таблицы в другой таблице. Данные, на которые ссылается другая 
таблица, защищаются от удаления. Ограничение внешнего ключа может 
гарантировать наличие в таблице КЛИЕНТ всех номеров заказчиков, записанных в 
поле КодКлиента таблицы СЧЕТ. Обычно внешний ключ создается при создании 
таблицы, но иногда возникает необходимость сделать это позже, и тогда команда 
SQL будет выглядеть, например, так: 

    ALTER TABLE  ORDER ADD  FOREIGN KEY   (CustomerNumber)   REFERENCES  CLIENT 


    Ограничения проверки 

    Существует еще один вид ограничений — ограничения проверки. Такие 
ограничения обеспечивают контроль за тем, чтобы величина принимала значения 
только из некоторого фиксированного набора. Допустим, организация, 
занимающаяся розничной торговлей, принимает к оплате ряд кредитных карточек, 
например VISA, MasterCard и American Express. Для этого фиксированного набора 
значений можно создать проверочное ограничение. Для этого используется 
следующий оператор SQL. 

    ALTER  TABLE   ORDERS  ADD  CONSTRAINT   INVALID_CREDIT_CARD CHECK   
(CreditCardType   in   ('V,    'M',    'A')) 

    Ограничения проверки могут определяться и при создании таблицы, например: 

    CREATE TABLE NYSE_EVENTS 
    ( 
    EventNo INTEGER NOT NULL, 
    Year INTEGER NOT NULL CHECK (YEAR >= 1790), 
    Description VARCHAR(SO) NOT NULL, 
    Resolution VARCHAR(80) NOT NULL 
    PRIMARY KEY (EventNo) 
    ); 

    Ограничения проверки могут определяться либо для всей таблицы, либо для 
отдельных столбцов, как в предыдущем примере. 

    Используемые по умолчанию значения 

    Цель используемых по умолчанию значений состоит в определении значения, 
появляющегося в столбце при выполнении операции INSERT, если ее параметр не 
задан. Используемые по умолчанию значения гарантируют, что данные в 
создаваемой строке будут допустимыми. 
    CpegHj3a3pa6oT4HKOB существует традиция присваивать столбцам используемые 
по умолчанию значения с помощью программного кода. В Delphi, например, это 
легко сделать, воспользовавшись событием OnNewRecord. 
    Несмотря ца„пррстоту, определение в приложениях используемых по умолчанию 
значений нежелательно. "ЧтоЙьГнайти такие значения, приходится копаться в 
исходном тексте приложения. Гораздо лучше поместить эти данные на сервер, где 
их легко можно просмотреть и, в случае необходимости, заменить. 
    Некоторые производители предлагают средства для определения используемых 
по умолчанию значений, которые зависят от типа платформы. Поэтому я продолжаю 
придерживаться синтаксиса ANSI. Предложение ANSI для ввода значения в столбце 
используемого по умолчанию значения выглядит следующим образом: 

    ALTER TABLE ORDERS 
    ADD CreditCardType chard) 
    DEFAULT 'V 

    Глава 20. Бизнес-правила и сервер базы данных	421 

    Представления 

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

    CREATE VIEW INVOICEDETAIL 
    AS 
    SELECT   InvoiceNumber,   LineNumber,   PriceEach   *   UnitsOrdered  ExtendedTotal 

    Это представление реализует правило "Для каждого наименования в счете 
вычисляется итоговое значение, равное стоимости единицы товара, умноженной на 
заказанное количество этого товара". 

    Триггеры 

    Когда все остальные средства неприменимы, на помощь приходит триггер и 
обычно доводит работу до конца. У многих СУБД существуют специальные 
расширения SQL, придающие триггерам и процедурам особые свойства. Так, СУБД 
Sybase использует диалект Transact-SQL, a Oracle — PL/SQL. Всегда старайтесь 
заменить триггер ограничением. Если же осуществить задуманное с помощью 
ограничения не удается, есть шанс, что триггер сделает эту работу. Вот пример 
триггера, способности которого превышают скромные возможности ограничений: 

    CREATE  TRIGGER  ORDERSInsert   FOR  ORDERS  BEFORE   INSERT  AS BEGIN 
    IF   (New.CreditCardType='V   AND New.Amount<50.00)   THEN 
    EXCEPTION  BELOW_MINIMUM_VISA; END 

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

    Хранимые процедуры 

    В определенных кругах существует тенденция реализовать бизнес-правила в 
виде хранимых процедур SQL. Идея состоит в том, чтобы использовать такие 
процедуры для всех операций DML (Data Manipulation Language — язык управления 
данными), создавая для каждой таблицы свои процедуры вставки, обновления и 
удаления. Этот прием призван обеспечить правильность применения ограничений и 
бизнес-правил при выполнении каждой операции. 
    Проблема, возникающая при осуществлении этого подхода, заключается в 
невозможности быстро оценить безопасность базы данных и реализации 
бизнес-правил. К тому же польза от применения таких средств, как Delphi, 
сводится к нулю, поскольку их способность связывать программные объекты с 
элементами баз данных почти не используется. Благодаря компоненту TUpdateSQL в 
Delphi можно использовать хранимые процедуры DML. Но при этом остаются 
незатребованными основные преимущества программных средств типа Delphi, прежде 
всего — возможность автоматического связывания данных, независимо от их 
структуры. Приходится дублировать структуру таблиц в обрабатывающих 
процедурах, а ведь именно этого позволяют избежать средства быстрой разработки 
приложений вроде Delphi. 
    Если каждая таблица будет иметь хотя бы три хранимые процедуры, это 
заметно усложнит управление базой данных. В базах, содержащих сотни таблиц, 
таких процедур могут быть тысячи. В таких условиях сопровождение базы данных 
превращается в сплошной кошмар для администратора. Увеличение 
производительности при использовании хранимых процедур в таком "осколочном" 
стиле чрезмерно преувеличено и имеет место только при определенном, очень 
редком стечении обстоятельств. Как правило, выгода здесь невелика, если вообще 
ощутима. Зато головную боль, вызванную созданием процедур в таких гигантских 
масштабах, вы почувствуете сразу, да такую, что никаких выгод не захочется. 
    Не забудьте и о том, что хранимые процедуры обработки данных, как и любой 
программный элемент, требуют отладки и сопровождения. Если в таблице 
появляются "плохие" данные, в процедурах обработки 

    422	IV. Темы повышенной сложности 

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

    CREATE PROCEDURE POSTAP (APACCOUNT) 
    AS 
    DECLARE VARIABLE APTOTAL FLOAT 
    BEGIN 
    SELECT   SUM(AmountOfTransaction)   TranAmount 
    INTO   :APTOTAL 
    FROM APTRANS; 
    UPDATE  GLBAL  SET  APMonthEndBalance=APMonthEndBalance+:APTOTAL 
    WHERE  AccountNumber=:APACCOUNT; END 

    Эта процедура делает столбец AmountOfTransaction таблицы APTRANS 
источником данных для столбца APMonthEndBalance. Она реализует бизнес-правило, 
устанавливающее способ вычисления ежемесячного баланса по кредиторской 
задолженности в главной книге. 
    В подобных ситуациях хранимые процедуры полезны, поскольку в них можно 
использовать неограниченное количество операторов SELECT, а также потому, что 
здесь программист решает сам, когда следует выполнять процедуру. В частности, 
они хорошо подходят для пакетно-ориентированных операций, таких, например, как 
процедуры сохранения или создание сложных отчетов. 

    Резюме 

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

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

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

    Глава 20. Бизнес-правила и сервер базы данных	423 
