- •Методология моделирования бизнес-процессов
- •Оглавление
- •Введение
- •Глава 1. Методология моделирования бизнес-процессов в среде business studio Урок 1. Начало работы в Business Studio Основные целы
- •Теоретическая часть
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Учебное задание
- •Технология выполнения учебного задания
- •Самостоятельное задание 2
- •Урок 3. Создание диаграммы декомпозиции Основные цели
- •Теоретическая справка
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Самостоятельное задание 3
- •Урок 4. Создание диаграммы декомпозиции а2 Основные цели
- •Теоретическая справка
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Самостоятельное задание 4
- •Урок 5. Создание диаграммы в нотации «Процесс» Основные цели
- •Теоретическая справка
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Самостоятельное задание 5
- •Урок 6. Создание организационной структуры предприятия Основные цели
- •Теоретическая справка
- •Учебное задание
- •Технология выполнения учебного задания
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Самостоятельное задание 7
- •Глава 2. Методология моделирования данных в среде erwin Тема 1. Создание диаграммы сущность-связь Основные цели
- •Теоретическая часть
- •Учебное задание
- •Технология выполнения учебного задания
- •Рекомендации при выборе первичного ключа.
- •Контрольные вопросы
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Учебное задание
- •Технология выполнения учебного задания
- •Учебное задание
- •Технология выполнения учебного задания
- •Контрольные вопросы
- •Самостоятельное задание
- •Приложение 1. Методология моделирования данных idef1x
- •Диаграмма сущность-связь
- •Сущность
- •Именование сущностей
- •Описание сущностей
- •Атрибут
- •Тип связи
- •Идентифицирующая и неидентифицирующая связи
- •Связи типа «один-ко-одному», «один-ко-многим», «многие ко-многим»
- •Имя связи
- •Мощность связи
- •Правила ссылочной целостности
- •Модель данных, основанная на ключах
- •Правила ссылочной целостности
- •Зависимые и независимые сущности
- •Идентифицирующие и неидентифицирующие связи.
- •Связь «многие ко многим»
- •Распространенные ошибки при моделировании сущностей и выборе ключей
- •Моделирование ролей
- •Перегрузка сущностей
- •Избыточные сущности
- •Выбор неправильного первичного ключа
- •Использование неудачных имен сущностей
- •Использование неудачных описаний сущностей
- •Полная атрибутивная модель
- •Нормализация
- •Денормализация
- •Создание физического уровня модели
- •Приложение 2. Наиболее часто задаваемые вопросы Понятие бизнес-процесса
- •Подходы к разработке модели бизнес-процессов Последовательность разработки модели бизнес-процессов
Перегрузка сущностей
Перегруженными являются сущности, содержащие информацию более чем об одном концептуальном объекте. Если некоторые атрибуты сущности описывают одну и ту же концепцию, такие сущности следует проверить. Перегруженные сущности имеют значения не для каждого из атрибутов.
Иногда эксперты из разных предметных областей в корпорации используют имя сущности, которое звучит и пишется одинаково, но имеет разный смысл для разных экспертов. Единственный способ убедится, что одинаковые имена описывают одинаковые объекты, это проверка описаний. Убедитесь, что сущность содержит данные, описывающие единственную концепцию.
Например, сущность ОБОРУДОВАНИЕ может иметь совершенно разное значение для подразделений информационных технологий и для отдела средств массовой информации и коммуникаций.
Избыточные сущности
Избыточными являются сущности, имеющие различные имена, но содержащие информацию о сходных концепциях. Английский язык включает много слов для представления одних и тех же вещей. Один из способов обнаружить такие сущности – это поиск сущностей, содержащих сходные атрибуты. Сравните описания каждой из таких сущностей, чтобы определить, не представляют ли они сходные концепции. Избыточные сущности часто появляются в результате тенденции к моделированию ролей в качестве сущностей.
Например, сущности УПРАВЛЕНЕЦ и СОТРУДНИК могут содержать сходную информацию, поскольку обе являются ролями, которые может играть экземпляр сущности ПЕРСОНА.
Выбор неправильного первичного ключа
Выбор неправильного первичного ключа означает, что вы выбрали первичный ключ, не выдерживающий тестирования. Распространенными ошибками, связанными с первичным ключом, являются:
Не уникальность: первичный ключ не является уникальным для каждого из экземпляров. Например, разработчик модели может считать, что номер социального страхования является уникальным для каждой ПЕРСОНЫ. Однако номер социального страхования может повторно использоваться в том случае, если первоначальный его владелец скончался.
Требуемое значение/неопределенность: первичный ключ не имеет значения для некоторых из экземпляров. Например, не каждый экземпляр сущности ПЕРСОНА будет иметь номер социального страхования. Иностранцы и маленькие дети – вот две категории людей, у которых он будет отсутствовать.
Использование неудачных имен сущностей
Непонятные, неоднозначные или неточные имена затрудняют для новых пользователей и команд разработчиков повторное использование или расширение существующей модели.
Не используйте аббревиатуры или акронимы в качестве части имени. Аббревиатуры и акронимы открыты для неправильной интерпретации и даже могут иметь разное значение в разных предметных областях.
Не включайте месторасположение в качестве части имени. Как правило, вам неизбежно потребуется и другое месторасположение. Имя с указанием расположения является признаком того, что вы моделируете конкретный экземпляр вместо класса сущностей.
Использование неудачных описаний сущностей
Не используйте описаний, заимствованных только из словаря. Описания из словаря не будут включать значимую для бизнеса информацию.
Не пытайтесь перефразировать имя сущности. Не используйте имя сущности в ее описании.
Неясные, расплывчатые или, что еще хуже, неполные описания затрудняют повторное использование и расширение существующей модели. Пользователь не сможет проверить, содержит ли сущность всю необходимую информацию.
При этом значительно повышается риск возникновения перегруженных сущностей и использования их для хранения информации о разных объектах.
Концепции, которые кажутся очевидными для всех участников рабочих сессий, могут перестать быть столь очевидными с течением времени, когда перед новой командой разработчиков будет поставлена задача расширения существующей модели.
