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

Cтраница 1

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

Какие бизнес-правила встроены в структуру данных. [2]

Конечно, реализация бизнес-правил снижает производительность. [3]

Со временем в организации меняются бизнес-правила для данных. [4]

Всегда существуют связанные с данными бизнес-правила, которые не могут обеспечиваться через структуру таблицы и ограничения ссылочной целостности. [5]

В идеале ERD должна отразить все бизнес-правила для данных. Однако некоторые правила могут быть выражены только в текстовой форме. Следовательно, аналитическая ERD не будет полной, если к ней не прилагается текстовое описание явных бизнес-правил, не отраженных на диаграмме. [6]

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

Диаграмма сущность-связь включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. [8]

Целью аналитической ERD является полное представление максимально возможного количества бизнес-правил. Любое правило, которое не может быть отображено в модели, должно быть зафиксировано отдельно. На фазе анализа основное внимание снова уделено пользователям, поскольку пока можно не задумываться о способах реализации системы. [9]

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

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

Важно отметить, что когда пользователь редактирует данные локально, при нарушении бизнес-правил ( которые определяются на стороне сервера в виде ограничений) клиентское приложение немедленно оповестит пользователя об этом. Кроме того, сервер передает клиенту значение по умолчанию для поля Salary в случае, если пользователь создает новую запись. На рис. 16.3 вы можете видеть одно из сообщений об ошибке, которое отображается клиентским приложением. Текст сообщения передается клиенту от сервера. [12]

Помимо выполнения функций репозитория проектных документов и различной дополнительной информации, Journey реализует бизнес-правила, регулирующие разработку новых продуктов в Nabisco. Эти правила определяют, что считается в компании финансовым успехом, какие виды работ и в каких объемах производятся в ее пекарнях, какой допускается минимальный балл продукта в потребительских тестах и каковы должны быть производственные издержки. Journey позволяет оценить необходимость в приобретении нового оборудования и возможность использования высвобождающегося на других участках. [13]

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

Миграция имен ролей.| Вкладка RI Actions диалога Relationships. [15]

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