Бизнес правила предметной области что это

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

Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

Что такое Предметная область? Часть 1

Верхний уровень состоит из Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах). Диаграмма сущность-связь определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области.

Нижний уровень состоит из Transformation Model (Трансформационная модель) и Fully Attributed (Полная атрибутивная модель). Трансформационная модель содержит всю информацию для реализации проекта, который может быть частью общей информационной системы и описывать предметную область. Трансформационная модель позволяет проектировщикам и администраторам БД представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям информационной системы. Фактически из трансформационной модели автоматически можно получить модель СУБД, которая является точным отображением системного каталога СУБД.

Логические модели

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

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

Три уровня моделей, объединяющие в себе логические модели, состоят из Entity Relationship Diagram (Диаграмма сущность-связь), the Key-Based (Модель данных, основанная на ключах) Model и the Fully Attributed model (Полная атрибутивная модель).

Зачем нужны бизнес требования?

Рис. 5.1.Уровни методологииIDEF1X

1.1. Диаграмма сущность-связь

Диаграмма сущность-связь является самым высоким уровнем в модели данных и определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации.

1.2. Модель данных, основанная на ключах

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

1.3. Полная атрибутивная модель

Эта модель включает в себя все сущности, атрибуты и является наиболее детальным представлением структуры данных. Полная атрибутивная модель представляет данные в третьей нормальной форме.

1.4 Компоненты логической модели данных

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

Сущности

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

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

Рис. 5.2.Пример использования ERwin для отображения сущностей в простейшей форме.

Атрибуты

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

Рисунок 2.3 иллюстрирует несколько примеров атрибутов.

Рис. 5.3.В качестве атрибутов могут выступать дата рождения клиента, модель автомобиля или код ISBN книги.

Отношения

Отношения представляют взаимосвязи между объектами, о которых корпорация заинтересована хранить данные. Отношения выражаются глаголами или глагольными фразами, которые описывают взаимосвязь. На рис. 2.4 приведено несколько примеров отношений, представленных в нотации IE (Information Engineering — информационная инженерия) системы ERwin.

Рис. 5.4.Примеры отношений используют нотацию IE системы ERwin, в которой «коровьи копыта» или «трезубцы» отображают многие стороны отношений.

Физические модели

Существует два уровня физических моделей: трансформационная модель и модель СУБД. Физические модели содержат информацию, необходимую системным разработчикам для понимания механизма реализации

логической модели в СУБД.

Трансформационная модель

Целью трансформационной модели является предоставление информации администратору БД для создания эффективной структуры хранения, включающей в себя записи, формирующие БД. Трансформационная модель должна помочь-разработчикам выбрать структуру хранения данных и реализовать систему доступа к ним.

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

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

Модель СУБД

Модель СУБД напрямую транслируется из трансформационной модели, являясь отображением системного каталога. ERWin напрямую поддерживает эту модель через функцию генерации схемы БД. При составлении схемы БД в качестве индексов могут использоваться как ключевой атрибут, так и остальные поля БД.

Преимущества от использования CASE-средства ERWin

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

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

Третье преимущество заключается в независимости логической модели от используемой СУБД, что позволяет применять универсальные методы для ее экспорта в конкретные СУБД.

Кроме того, ERWin предоставляет возможность формирования большого числа отчетов, отражающих текущее состояние процесса проектирования БД.

Инструментарий ERWin

При запуске ERWin появляется основная панель инструментов и палитра инструментов (табл. 5.1).

Таблица 5.1.Основная панель инструментовERWin

Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне панель инструментов выглядит следующим образом (рис. 5.5).

Рис. 5.5.Палитра инструментов на логическом уровне

1. Слева направо, верхний ряд:

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

2. Слева направо, нижний ряд:

• Кнопка перенесения атрибутов внутри сущностей и между ними. Атрибуты могут быть перемещены способом drag https://itteach.ru/bpwin/metodologiya-idef1x» target=»_blank»]itteach.ru[/mask_link]

  Пример описания предметной области с использованием Unified Modeling Language (UML) при разработке программных систем

  Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия.

  В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей странеCASE-средствами являются Rational Rose, BPwin, Silverrun, Process Analyst . Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Однако немаловажным, с нашей точки зрения, является комплексность подхода и использование единой унифицированной нотации, не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы, как это имеет место в CASE Rational Rose .

  В настоящей статье на конкретном примере демонстрируется возможный подход к моделированию предметной области с использованием унифицированной нотации, основанный на применении Унифицированного Языка Моделирования ( Unified Modeling Language ) (UML), и гармонично сочетающий в себе достоинства структурных и объектных методов проектирования в CASE Rational Rose.

  Итак, основными задачами при моделировании предметной области являются описание:

  1. Бизнес-процессов предприятия;
  2. Действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;
  3. Бизнес-сущностей;
  4. Сценариев выполнения бизнес-функций, подлежащих автоматизации;
  5. Состояний бизнес-сущностей;
  6. Бизнес-правил.

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

  При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). И только в этом случае описание бизнес-процессов может считаться корректным.

  На рис. 1 представлен пример описания бизнес-процессов с использованием диаграммы деятельности ( activity diagram ) UML и CASE Rational Rose.

  Рассмотрена задача, которую следует автоматизировать: «Оприходование товара на складе предприятия от продавца».

  Рис. 1. Описание технологии работы склада
  при оприходовании товара от продавца

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

  На основе описания бизнес-процессов с использованием диаграммы деятельности ( activity diagram ) определяются виды деятельности, которые следует автоматизировать.

  Из примера на рис. 1 видно, что таковыми являются (функции отмечены цветом) следующие виды деятельности:

  1. Выписывает доверенность;
  2. Выписывает приемный акт в двух экземплярах;
  3. Регистрирует товар в картотеке;
  4. Передает экземпляр акта в бухгалтерию;
  5. Получает приходный акт.

  Следует отметить: наш значительный опыт при описании бизнес-процессов с использованием различных CASE-средств, например, BPwin, Silverrun, Process Analyst и Rational Rose показал, что наиболее понятным описанием бизнес-процессов для обсуждения его с экспертами предметной области и получения от них конструктивных замечаний является представленная выше нотация в CASE Rational Rose.

  На наш взгляд, причинами этого являются:

  1. Соответствие парадигмы диаграммы деятельности представлению пользователей о бизнес-процессе на уровне связей по управлению, а не по информации как, например, в BPwin ;
  2. Четкое ролевое выражение ответственностей за ту или иную деятельность;
  3. Возможность совмещения в диаграммах описание документов, связанных с деятельностью и их состояний;
  4. Развитая нотация описания состояний бизнес-сущностей (при использовании объектов;
  5. Четко отслеживаемые горизонтальные связи между подразделениями, что позволяет структурировать процессы предметной области (абсолютно необходимо для последующих этапов проектирования).

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

  На основе этой модели строится модель функций системы .

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

  На рис. 2-7 представлены модель структуры предприятия, построенная с использованием диаграммы функций UML ( use case diagram ).

  Рис. 2. Автоматизируемого предприятия

  Рис. 3. Автоматизируемые отделы предприятия

  Рис. 4. Сотрудники склада и документы склада

  Рис. 5. Роли на складе

  рис. 6. Задачи кладовщика

  Рис. 7. Функции кладовщика по задаче «Оприходование товара на складе от продавца» (цветом помечены выходные документы)

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

  Следующей задачей при описании предметной области является моделирование документов.

  Цель моделирования документов — описать атрибуты документов, их типы, значения, правила формирования для:

  1. Проектирования пользовательского интерфейса системы;
  2. Проектирования Базы данных системы;
  3. Формирования альбома выходных форм системы;

  На рис. 8. представлен пример модели документа «Приемный акт» разработанный с использованием диаграммы классов ( class diagram ) языка UML в CASE Rational Rose :

  Дополнительным преимуществом при моделировании документов в Rational Rose является возможность присоединение к модели документа или бизнес-сущности описание его внешнего вида с примером, например, подготовленного в редакторе Word или в средствах визуального проектирования интерфейсов.

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

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

  На рис. 9 представлен пример сценария работы кладовщика с карточкой товара и накладной, описанного с использованием диаграммы последовательности действий UML ( sequence diagram ), а на рис. 10 пример диаграммы состояний приемного акта, описанного с использование диаграммы ( statechart diagram) .

  Рис. 9. Сценарий работы кладовщика с карточкой товара и накладной

  Рис. 10. Пример диаграммы состояний ( state diagramm ) с описанием состояний приемного акта

  При описании предметной области не следует забывать о моделировании бизнес-правил . Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Для моделирования бизнес-правил могут использоваться диаграммы деятельностей ( activity diagram) и диаграммы классов ( class diagram ). Диаграммы деятельностей ( activity diagram) могут использоваться для моделирования например, алгоритмически описываемых правил, диаграммы классов ( class diagram ) — для моделирования структурных правил.

  Итак, подводя итог выше сказанному об описании предметной области при разработке программных систем, отметим следующее:

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

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

  2. Результаты бизнес-моделирования в CASE Rational Rose легко могут быть преобразованы в документацию соответствующую промышленным стандартам разработки программных систем.

  3. Полное и детальное описание предметной области крайне удобно производить в CASE средстве, поддерживающем универсальный язык моделирования UML.

  В отличие от CASE Rational Rose популярные в нашей стране BPwin, Silverrun, Process Analyst не имеют пока полноценной поддержки всех перечисленных выше этапов бизнес-моделирования. Что ограничивает сферу их применения.

  Описание предметной области с использованием UML хорошо воспринимается экспертам предметной области и не требует от них никакой специальной подготовки для понимания представленных им на рассмотрение моделей.

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

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

  P.S. Авторы выражают глубокую благодарность слушателям курса «Объектный анализ и проектирование программных систем с использованием CASE Rational Rose «, регулярно читаемого в Учебно-консалтинговом центре Interface Ltd, за участие в разработке примера по описанию предметной области для целей проектирования программной системы в качестве экспертов предметной области.

  02.2001

  Источник: www.interface.ru Инфологическое (концептуальное) моделирование предметной области — подход Oracle Концептуальная модель: Называется «Модель сущность-связь», Иллюстрируется с использованием «Диаграммы сущность-связь» (ERD) Является результатом завершения процесса моделирования данных Предприятия используют данные для увеличения продаж и/или снижения затрат. Чтобы точно собирать эти данные, бизнес должен создать концептуальную модель данных, которые он считает важными. 4 5. Концептуальная модель важна для бизнеса, потому что она: Описывает именно информационные потребности бизнеса Облегчает дискуссию (коммуникации) Предотвращает ошибки и недоразумения Формирует важную документацию «идеальной системы» Формирует надежную основу для проектирования физической базы данных Документирует процессы (также известные как «бизнес-правила») бизнеса Принимает во внимание правила и законы, регулирующие предметную область. 6. Сущность: «Что-то», что имеет значение для предметной области, о которой должны быть известны данные Имя для набора (класса) похожих объектов, которые вы можете перечислить Обычно существительное Примеры: объекты, события, люди У сущностей есть экземпляры. Экземпляр — это единственное вхождение объекта. 6 7. Назначение сущностей Зная, как организовать и классифицировать данные, можно сделать полезные выводы о кажущихся случайными фактах. Наш богатый технологиями мир производит огромное количество фактов, нуждающихся в структуре и порядке. Важно знать о сущностях, потому что это то, о чем мы храним данные. Например: Университет должен хранить данные о (как минимум): СТУДЕНТАХ, ПРЕПОДАВАТЕЛЯХ, ДИСЦИПЛИНАХ, ГРУППАХ, АУДИТОРИЯХ и др. 8. Назначение атрибутов Атрибуты предоставляют более конкретную информацию об объекте. Атрибуты помогают различать экземпляры сущности, предоставляя для нее более подробные сведения. Например: При создании нескольких отчетов о продажах вы должны иметь возможность идентифицировать конкретный отчет из списка отчетов. 9. Назначение уникальных идентификаторов Уникальные идентификаторы позволяют отличить один экземпляр объекта от другого. Например: Отличить одного студента от другого. При перечислении транзакций в финансовом отчете отличать одну транзакцию от другой. 10. Сущности и экземпляры Сущность Экземпляры Факультет Менеджмента, ФМЭСИ, Маркетинга … Кафедра Базовая кафедра компании 1С Высшей математики ПИиИБ … 10 11. Связи в моделях данных Показывают, как объекты связаны друг с другом Существуют только между объектами (или одним объектом и самим собой) Двунаправленные Названы с обоих концов Имеют опциональность Имеют мощность Имеют свойство трансферабельности 11 12. Опциональность (модальность) связи Связи являются обязательными или необязательными. Рассмотрим два объекта СОТРУДНИК и РАБОТА. Определим опциональность, ответив на два вопроса: 1. Должен ли каждый иметь работу, т.е. для работника обязательна или необязательна связь с работой? 2. Должна ли каждая работа назначаться сотруднику, т.е. обязательна или необязательна связь работы с сотрудником? 12 13. Опциональность (модальность) связи Модальность связи определяет минимальное значение экземпляров сущностей. Каждая связь может иметь одну из двух модальностей связи: Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром, в этом случае допускаются значения null для внешнего ключа. Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов. 13 14. Мощность в связях Мощность определяет степень, с которой одна сущность связана с другой, т.е. отвечает на вопрос «Сколько экземпляров сущности связано с экземпляром данной сущности?». Иначе говоря, мощность определяет минимальное и максимальное количество экземпляров сущностей в связи и характеризуется модальностью связи и типом связи. Например: Может ли сотрудник работать в разных структурных подразделениях компании или только в одном (разрешено ли совместительство)? Сколько сотрудников может выполнять одну конкретную работу? Только один сотрудник? Или 14 более одного сотрудника? 15. Мощность в связях Максимальные значения экземпляров сущности для каждого правила отношения, определяется типом связи: связь один-к-одному (1:1); связь один-ко-многим (1 :М) или многие-кодному (М: 1); связь много-ко-многим (М:М); связь рекурсивная. 15 16. Переносимость связей (трансферабельность) Трансферабельность определяет возможность изменения родительской записи. Например: Может ли СОТРУДНИК быть переведен из одного отдела в другой? ДА – связь трансферабельна 16 17. Переносимость связей (трансферабельность) Например: Может ли СТУДЕНТ перевестись в другую группу? ДА – связь трансферабельна 17 18. Переносимость связей (трансферабельность) Например: СТУДЕНТУ может быть выписан СЧЕТ за сдачу сертификационного экзамена. После того, как СЧЕТ был выписан, он не может быть передан другому СТУДЕНТУ. Если СЧЕТ был выписан по ошибке, его нужно отменить, но не передавать другому лицу. Связь нетрансферабельна 18 19. Пример бизнес-сценария 1 Каковы связи в следующем бизнессценарии? В ресторане клиент подходит к стойке и делает заказ. Клиент может заказать не только для себя но и для других. Например, мать заказывает себе и своим детям. Считается, что мать является клиентом, который владеет заказом и несет ответственность за платеж. С течением времени клиент может разместить столько заказов, сколько захочет. 19 20. КЛИЕНТЫ ЗАКАЗЫ: опциональность Опциональность = Должен или может? Каждый ЗАКАЗ (ORDER) должен быть размещен одним (и только одним) ЗАКАЗЧИКОМ. Каждый ЗАКАЗЧИК (CUSTOMER) должен разместить один или несколько ЗАКАЗОВ. 20 21. КЛИЕНТЫ ЗАКАЗЫ: мощность (кардинальность) Кардинальность = Сколько? Каждый ЗАКАЗ должен быть размещен одним и только одним ЗАКАЗЧИКОМ. Каждый ЗАКАЗЧИК должен разместить один или несколько ЗАКАЗОВ. 21 22. Пример бизнес-сценария 2 Связи могут присоединяться в сущности к самой себе. Необходимо отслеживать сотрудников и их менеджеров. У каждого сотрудника есть один менеджер, в том числе управляющий, который управляет собой. Каждый менеджер может управлять несколькими сотрудниками. 22 23. Пример бизнес-сценария 2 Связи могут присоединяться в сущности к самой себе. Поскольку менеджеры также являются сотрудниками, оба они перечислены в одной СУЩНОСТИ: СОТРУДНИК. Каждый СОТРУДНИК может управляться одним и только одним СОТРУДНИКОМ Каждый СОТРУДНИК может управлять одним или несколькими СОТРУДНИКАМИ 23 24. Соглашения по рисованию ER-диаграмм Сущности представлены прямоугольниками. Имена сущностей входят в прямоугольник. Имена сущностей указываются в единственном числе и записываются прописными буквами. 24 25. Условные обозначения на ER-диаграммах Атрибуты перечислены под именами сущностей. Обязательные атрибуты отмечены звездочкой: * Необязательные атрибуты отмечены кружком: 0 Уникальные идентификаторы отмечены символом «хэш»: # 25 26. Условные обозначения на ER-диаграммах Связи — это линии, которые соединяют объекты. Эти линии являются сплошными или пунктирными. Эти линии заканчиваются либо одиночной чертой (single toe), либо вороньей лапой (crow’s foot). 26 27. Как правильно читать ER-диаграмму Каждый экземпляр сущности A ОПЦИОНАЛЬНОСТЬ (должна быть / может быть) Имя связи КАРДИНАЛЬНОСТЬ (один и только один или один или много) Экземпляр сущности B 27 28. Как правильно читать ER-диаграмму Поскольку каждая связь имеет две стороны, читаем связь слева направо (или сверху вниз, в зависимости от схемы ERD). Каждый сотрудник (экземпляр сущности СОТРУДНИК) должен (ОПЦИОНАЛЬНОСТЬ – сплошная линия) работать в (имя связи) одном и только одном (КАРДИНАЛЬНОСТЬ – одиночная черта) отделе (сущность ОТДЕЛ) 28 29. Как правильно читать ER-диаграмму Теперь читаем связь справа налево Каждый отдел (экземпляр сущности ОТДЕЛ) может (ОПЦИОНАЛЬНОСТЬ – пунктирная линия) отвечать за (имя связи) один или более (КАРДИНАЛЬНОСТЬ – воронья лапа) сотрудников (сущность СОТРУДНИК) 29 30. Как правильно читать ER-диаграмму Теперь читаем все вместе Каждый сотрудник (экземпляр сущности СОТРУДНИК) должен (ОПЦИОНАЛЬНОСТЬ – сплошная линия) работать в (имя связи) одном и только одном (КАРДИНАЛЬНОСТЬ – одиночная черта) отделе (сущность ОТДЕЛ) Каждый отдел (экземпляр сущности ОТДЕЛ) может (ОПЦИОНАЛЬНОСТЬ – пунктирная линия) отвечать за (имя связи) один или более (КАРДИНАЛЬНОСТЬ – воронья лапа) сотрудников (сущность СОТРУДНИК) 30 31. Супертипы и подтипы Супертипы и подтипы встречаются часто в реальном мире: • типы питания (есть, идти) • типы продуктовых мешков (бумага, пластик) • типы платежей (чек, наличные деньги, кредит) • типы сотрудников (штатные, совместители, работающие по договору) 31 32. Супертипы и подтипы Часто некоторые экземпляры объекта имеют атрибуты и / или отношения, которые другие экземпляры не имеют. Представьте себе бизнес, который должен отслеживать платежи от клиентов. Клиенты могут оплачивать наличными, чеком или кредитной картой. 32 33. Супертипы и подтипы Все платежи имеют некоторые общие атрибуты: дату платежа, сумму платежа и т. д. Но только кредитные карты будут иметь атрибут номер карты. А для оплаты кредитной картой и чеками нам может понадобиться знать, какой ЗАКАЗЧИК совершил платеж, в то время как это не нужно для оплаты наличными. 33 34. Супертипы и подтипы Иногда имеет смысл подразделить сущность на подтипы. Это может иметь место, когда группа экземпляров имеет специальные свойства, такие как атрибуты или отношения, которые существуют только для этой группы. В этом случае объект называется супертипом, а каждая группа называется подтипом. 34 35. Характеристики подтипа Подтип: Наследует все атрибуты супертипа Наследует все связи супертипа Обычно имеет свои собственные атрибуты или связи Изображается внутри супертипа Не существует самостоятельно Может иметь собственные подтипы 35 36. Пример супертипа Супертип: EMPLOYEE Подтипы: STAFF_MEMBER, PART_TIME_WORKER, EMPLOYEE_AGREEMENT Подтипы имеют несколько общих атрибутов. Эти общие атрибуты перечислены на уровне супертипа. Подтипы наследуют все атрибуты сущности супертипа. 36 37. Пример супертипа То же самое относится к связям. Связи с сущностями PHONE и EMAIL относятся к супертипу и наследуются подтипами. Т.о. подтипы наследуют все атрибуты и связи сущности супертипа. 37 38. Подтипов должно быть несколько Если сущность имеет подтип, должен существовать и второй подтип. Один подтип совпадает с супертипом. Эта идея приводит к двум правилам подтипа: 1. Исчерпания: каждый экземпляр супертипа также является экземпляром одного из подтипов. Все подтипы перечислены без упущений. 2. Исключения: каждый экземпляр супертипа является экземпляром только одного возможного подтипа. 38 39. Подтипов должно быть несколько На этапе концептуального моделирования хорошей практикой является включение подтипа OTHER, чтобы убедиться, что ваши подтипы являются исчерпывающими, — что вы обрабатываете каждый экземпляр супертипа. 39 40. Подтипы всегда существуют Любая сущность может быть декомпозирована на подтипы путем составления правила, которое подразделяет экземпляры на группы. Однако создавать подтипы имеет смысл только тогда, когда существует потребность показать сходства и различия между экземплярами сущности. 40 41. Правильное определение подтипов При моделировании супертипов и подтипов следует ответить на три вопроса, чтобы определить, правильно ли идентифицирован подтип: 1. Этот подтип является разновидностью супертипа? 2. Рассмотрены все возможные случаи? (правило исчерпания). 3. Каждый экземпляр супертипа принадлежит одному и только одному подтипу? (исключения) 41 42. Вложенные подтипы Один подтип можно вложить в другой. Для удобства чтения обычно показывают подтипы только с двумя уровнями, но нет правила, которое ограничивало бы число уровней вложенности. 42 43. 44. Структурные и процедурные бизнес-правила Структурные бизнес-правила указывают типы информации, подлежащей хранению, и то, как элементы информации взаимосвязаны. Процедурные правила касаются предварительных условий, шагов, процессов или требований рабочего процесса для бизнеса. Многие процедурные бизнес-правила связаны со временем. Например, событие A должно произойти до события B. Структурные бизнес-правила можно практически всегда отображать в ERD. Некоторые процедурные бизнес-правила не могут быть отображены на диаграмме, но их необходимо документировать, чтобы их можно было 44 запрограммировать позже. 45. Примеры структурных бизнес-правил Структурные бизнес-правила указывают типы информации, подлежащей хранению (атрибуты), и то, как информационные элементы взаимосвязаны (связи). Вот несколько примеров: Все заказы в ресторане должны обрабатываться сотрудником (в частности, заказчиком). Система заказа самообслуживания отсутствует. 45 46. Примеры структурных бизнес-правил В компании могут работать только сотрудники, имеющие следующий статус: Состоящие в штате; Работающие по совместительству; Работающие на основе договора (ГПХ). При этом для штатных сотрудников разрешено внутреннее совместительство (в том числе в одном структурном подразделении). Работающие по совместительству могут занимать только одну должность и состоять только в одном подразделении. Работающие на основе договора не числятся ни в одном структурном подразделении. 46 47. Примеры процедурных бизнес-правил Заявление на служебную командировку может быть подписано руководителем организации только после его подписания непосредственным руководителем сотрудника. Один сотрудник не может одновременно курировать более чем 10 договоров. Студент может выбрать дисциплину (по выбору) CASE-технологии только, если он изучил дисциплину «Проектирование информационных систем» 47 48. Невозможность отражения в ER-модели некоторых бизнес-правил В процессе разработки модели концептуальных данных можно моделировать не все бизнес-правила. Некоторые правила, должны быть реализованы путем программирования процессов, которые взаимодействуют с данными. Например. Для любого сотрудника, чья сверхурочная работа превышает 10 часов в неделю, часовая тарифная ставка должна быть увеличена в 1,5 раза Клиенты, нарушившие график платежей лишаются скидок. 48 Источник: ppt-online.org