Бизнес-правила

Cтраница 2

Правила ссылочной целостности ( referential integrity ( RI) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генерации схемы базы данных на основе опций логической модели, задаваемых во вкладке RI Actions ( рис. 2.2.25), будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. [16]

Разработчик должен собрать все требования к системе и отжать их до размера бизнес-правил. Бизнес-правила рассматриваются в двух местах, одним из которых будет аналитическая ERD. Но в ERD могут быть отражены не все правила уровня данных. Следовательно, требования должны быть отражены и в тексте, а на фазе построения они будут транслироваться в триггеры базы данных. [17]

Рассмотрим простейший пример, в котором переопределим шаблон триггера для сущности. Предположим, что бизнес-правила требуют, чтобы при любом изменении имени клиента ( колонка CustomerName таблицы CUSTOMER, рис. 2.3.21) в таблице SECURITY создавалась строка, в которой бы фиксировалось прежнее значение имени, новое значение, дата изменения и имя пользователя, произведшего изменение. [18]

Дополнительная сущность с общими по смыслу атрибутами. [19]

Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущности-потомки Постоянный сотрудник и Совместитель. [20]

Закладка Code диалога Triggers. [21]

Код шаблона триггера, соответствующий бизнес-правилу рассматриваемого примера ( создан на основе шаблона триггера ссылочной целостности), приведен ниже. [22]

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

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

Операции процесса прикладного проектирования и инструментальные средства Oracle Designer. [25]

Вероятно, понадобится дополнить табличный API для реализации каких-либо бизнес-правил или для выполнения стандартного сопровождения данных. [26]

Бесконечный цикл. [27]

Колонки в различных таблицах имеют одинаковое имя и определения, но таблицы не связаны друг с другом. Такие таблицы должны быть тщательно изучены, и, если бизнес-правила требуют установить связь между такими таблицами, она должна быть создана. [28]

СТА является вымышленной компанией. Эти примеры не используют подход на основе анализа проблемы, поэтому бизнес-правила и подробности реализации не имеют значения при обсуждении. Однако полезно познакомиться с кратким описанием возможностей системы СТА. [29]

Следующий вопрос связан с корректностью ERD. Логически правильная диаграмма ERD должна представлять собой третью нормальную форму возможно большего числа бизнес-правил, связанных с данными. Если такие правила не могут быть отражены в диаграмме ERD, их следует указать в документе другого формата. Разработчики должны быть уверены, что ERD поддерживает все бизнес-транзакции организаций. Для этого следует взять наиболее сложный пример сохранения любых данных и проверить присутствие таких данных в ERD. Модель часто считают правильной, пока не попытаются поместить туда данные. [30]

Страницы: 1 2 3