Бизнес правила для бд

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

При внедрении принудительной проверки целостности данных, по сути, обеспечивается гарантия правильности данных в таблицах и отсутствие в них каких-либо несоответствий, которые могут появляться как прямо во время первоначального процесса ввода данных, так и позже, при внесении в них тех или иных изменений. Кроме того,модель должна предусматривать проверку целостности данных посредством применения соответствующих ограничений, предоставляемых самой РСУБД. ER-модель позволяет делать пометки о необходимых ограничений и планировать их обработку заранее.

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

• Можно использовать первичные ключи для принудительного обеспечения уникальности данных в таблицах. Обратите внимание на то, что значения первичных ключей должны обязательно быть уникальными и не нулевыми. Значение первичного ключа не должно меняться на протяжении всей жизни экземпляра сущности.
• Можно использовать внешние ключи для принудительного обеспечения целостности ссылочных данных и тем самым получения уверенности в целостности и согласованности всех данных. Под обеспечением целостности ссылочных данных (referential integrity) подразумевается поддержание правильных отношений зависимости между двумя таблицами, а под обеспечением декларативной целостности ссылочных данных (declarative referential integrity) — гарантирование целостности данных за счет определения отношения между двумя разными таблицами.
• Можно обеспечивать действительность и значимость данных путем принудительного ввода доменных ограничений, наподобие проверочных ограничений целостности (check constraints). Доменные ограничения (domain constraints) гарантируют получение действительных значений для определенных сущностей. Например, в базе данных, связанной с банковским делом, может присутствовать ограничение,утверждающее, что сумма снятия в любой транзакции всегда должна быть меньше или равна общей сумме денежного баланса владельца счета.
• Можно использовать триггеры баз данных (database triggers), которые будут автоматически выполнять определенные операции в случае возникновения того или иного указанного действия для обеспечения действительности данных.

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

Источник: oracle-patches.com

Бизнес-правила и требования

Просто задавая пользователем вопрос: «Что представляют собой ваши бизнес-правила?», практически невозможно получить нужную информацию, точно так же, как не удается собрать нужные сведения отребованиях, задавая при сборе требований вопрос пользователям: «Чего вы хотите?» В зависимости от приложения бизнес-правила иногда создаются по ходу работы, а иногда — в процессе обсуждения требований, Зачастую заинтересованные в проекте лица уже знают, какие бизнес-правила влияют на создаваемое приложение, и команда разработчиков будет работать в рамках, определяемых этими правилами, Комплексный процесс выявления бизнес-правил описан Barbara von Halle (2002).

На семинарах для выявления требований аналитик может поинтересоваться обоснованием требований и ограничений, выдвигаемых пользователями. Нередко выясняется, что они определяются бизнес-правилами. Иногда аналитику удается также выявить бизнес-правила, которые определяют прочие артефакты и модели требований (Gottes-diener, 2002). На рис.

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

Рис. 9-2. Выявление бизнес-правил с помощью разнообразных вопросов

Идентифицировав и задокументировав бизнес-правила, определите, какие из них необходимо реализовать в программном продукте. Некоторые правила определяют варианты использования и функциональные требования, которые их реализуют. Рассмотрим три правила:

· Правило № 1 (активатор операции). «Если срок хранения контейнера с химикатом истек, об этом необходимо уведомить лицо, у которого в данный момент находится контейнер»;

· Правило № 2 (вывод). «Считается, что срок хранения контейнеров с химикатами, разлагающимися на взрывоопасные составляющие, истекает через один год с даты изготовления»;

· Правило № 3 (факт). «Эфир может спонтанно образовывать взрывоопасную перекись».

Эти правила определяют вариант использования, известный, как «Известить владельца химиката об истечении срока хранения». Одно из функциональных требований для данного варианта использования таково: «Система должна по электронной почте уведомить об владельца контейнера с химикатом об истечении срока хранения химиката».

Связи между функциональным требованием и породившими его бизнес-правилами определяют двумя способами:

· используя атрибут «Источник», указывают правила в качестве источников функционального требования (подробнее — в главе 18);

· определяют связи между функциональным требованием и соответствующими бизнес-правилами в матрице связей (подробнее — в главе 20).

Правила ссылочной целостности данных зачастую реализуют в виде триггеров и хранимых процедур БД. Такие правила описывают операции по обновлению, вставке и удалению данных, которые должна выполнять система в результате наличия отношений между сущностями данных (von Halle, 2002). Например, если клиент отменил заказ, система должна удалить все пункты, касающиеся неотправленных товаров, входящих в этот заказ.

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

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

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

· исчезает необходимость модифицировать и бизнес-правило, и соответствующие функциональные требования при изменении правила;

· в спецификации требований к ПО отражаются последние изменения правил, поскольку спецификация требований к ПО просто ссылается на основную копию правила;

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

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

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

Источник: poisk-ru.ru

Формулировка бизнес правил

1) на каждом стеллаже лежат книги; каждая книга может лежать только на одном стеллаже.

Аналогично строятся бизнес правила для отношений [Книги — Автор] и [Книги — Издательства].

2) в определенную смену могут работать несколько сотрудников; каждый сотрудник может работать только в одну смену.

3) сотрудники выдают книги студентам, также они их принимают у студентов. Эти операции агрегируются в сущностях «Возврат» и «Выдача».

4) на каждом факультете есть кафедры. Кафедра может принадлежать только 1 факультету

Построение базы данных

1. SQL описание (ER-Win).

После составления логической и физической моделей в программе ER-Win была произведена генерация SQL описания. Оно представлено ниже:

CREATE TABLE Author (

AVT_FAM char(20) NOT NULL,

AVT_KOD int NOT NULL,

AVT_NAME char(20) NOT NULL,

AVT_OTCH char(20) NULL

ALTER TABLE Author

ADD PRIMARY KEY NONCLUSTERED (AVT_KOD)

CREATE TABLE Book (

B_NAME char(30) NOT NULL,

B_KOD int NOT NULL,

AVT_KOD int NOT NULL,

IZ_KOD int NOT NULL,

ST_KOD int NOT NULL

ALTER TABLE Book

ADD PRIMARY KEY NONCLUSTERED (B_KOD)

CREATE TABLE Chitateli (

CH_PROF char(20) NOT NULL,

CH_KOD int NOT NULL

ALTER TABLE Chitateli

ADD PRIMARY KEY NONCLUSTERED (CH_KOD)

CREATE TABLE Employees (

E_FAM char(20) NOT NULL,

E_KOD int NOT NULL,

E_NAME char(20) NOT NULL,

E_OTCH char(20) NULL,

E_RANK char(20) NOT NULL,

SM_KOD int NOT NULL

ALTER TABLE Employees

ADD PRIMARY KEY NONCLUSTERED (E_KOD)

CREATE TABLE Fakultet (

FAK_NAME char(30) NOT NULL,

FAK_KOD int NOT NULL

ALTER TABLE Fakultet

ADD PRIMARY KEY NONCLUSTERED (FAK_KOD)

CREATE TABLE Izdatelstva (

IZ_NAME char(20) NOT NULL,

IZ_KOD int NOT NULL

ALTER TABLE Izdatelstva

ADD PRIMARY KEY NONCLUSTERED (IZ_KOD)

CREATE TABLE Kafedra (

KAF_NAME char(35) NOT NULL,

FAK_KOD int NOT NULL,

KAF_KOD int NOT NULL

ALTER TABLE Kafedra

ADD PRIMARY KEY NONCLUSTERED (KAF_KOD)

CREATE TABLE Smena (

SM_NACH datetime NOT NULL,

SM_KOD int NOT NULL,

SM_KONEC datetime NOT NULL

ALTER TABLE Smena

ADD PRIMARY KEY NONCLUSTERED (SM_KOD)

CREATE TABLE Stellazh (

ST_TEMA char(30) NULL,

ST_KOD int NOT NULL

ALTER TABLE Stellazh

ADD PRIMARY KEY NONCLUSTERED (ST_KOD)

CREATE TABLE Students (

CH_KOD int NOT NULL,

STUD_KOD int NOT NULL,

STUD_FAM char(20) NOT NULL,

STUD_NAME char(20) NOT NULL,

STUD_OTCH char(20) NULL,

STUD_KURS int NOT NULL,

STUD_GROUP int NOT NULL,

FAK_KOD int NOT NULL

ALTER TABLE Students

ADD PRIMARY KEY NONCLUSTERED (STUD_KOD)

CREATE TABLE Teachers (

CH_KOD int NOT NULL,

T_KOD int NOT NULL,

T_FAM char(20) NOT NULL,

T_NAME char(20) NOT NULL,

T_OTCH char(20) NULL,

T_TEL char(17) NULL,

T_MAIL char(30) NULL,

KAF_KOD int NULL

ALTER TABLE Teachers

ADD PRIMARY KEY NONCLUSTERED (T_KOD)

CREATE TABLE Vidacha (

V_DATE datetime NOT NULL,

VD_KOD int NOT NULL,

B_KOD int NOT NULL,

CH_KOD int NOT NULL,

E_KOD int NOT NULL

ALTER TABLE Vidacha

ADD PRIMARY KEY NONCLUSTERED (VD_KOD)

CREATE TABLE Vozvrat (

V_DATE datetime NULL,

VZ_KOD int NOT NULL,

B_KOD int NOT NULL,

CH_KOD int NOT NULL,

E_KOD int NOT NULL

ALTER TABLE Vozvrat

ADD PRIMARY KEY NONCLUSTERED (VZ_KOD)

ALTER TABLE Book

ADD FOREIGN KEY (IZ_KOD)

ALTER TABLE Book

ADD FOREIGN KEY (AVT_KOD)

ALTER TABLE Book

ADD FOREIGN KEY (ST_KOD)

ALTER TABLE Employees

ADD FOREIGN KEY (SM_KOD)

ALTER TABLE Kafedra

ADD FOREIGN KEY (FAK_KOD)

ALTER TABLE Students

ADD FOREIGN KEY (FAK_KOD)

ALTER TABLE Students

ADD FOREIGN KEY (CH_KOD)

ALTER TABLE Teachers

ADD FOREIGN KEY (KAF_KOD)

ALTER TABLE Teachers

ADD FOREIGN KEY (CH_KOD)

ALTER TABLE Vidacha

ADD FOREIGN KEY (E_KOD)

ALTER TABLE Vidacha

ADD FOREIGN KEY (B_KOD)

ALTER TABLE Vidacha

ADD FOREIGN KEY (CH_KOD)

ALTER TABLE Vozvrat

ADD FOREIGN KEY (CH_KOD)

ALTER TABLE Vozvrat

ADD FOREIGN KEY (E_KOD)

ALTER TABLE Vozvrat

ADD FOREIGN KEY (B_KOD)

Диаграммы БД (MS Access, MS SQL Server).

После генерации данного кода был произведен его ввод в СУБД MS Access и в СУБД MS SQL Server. Ниже представлены диаграммы баз данных в обеих СУБД.

При вводе данных в MS Access выше представленное SQL описание немного не подходило, а именно: для создания таблицы нужно было не писать 2 запроса:

CREATE TABLE Stellazh (

ST_TEMA char(30) NULL,

ST_KOD int NOT NULL

ALTER TABLE Stellazh

ADD PRIMARY KEY NONCLUSTERED (ST_KOD);

а надо было написать 1 запрос такого вида:

CREATE TABLE Stellazh (

ST_TEMA char(30) NULL,

ST_KOD int PRIMARY KEY NOT NULL

1) Диаграмма БД в MS SQL_Server.

Источник: studbooks.net