Моделирование - острый вопрос, непонятный процесс, отсутствующая методология... Есть, конечно, индустриальные модели, которые можно взять и изучить - вот так сразу, целиком,.. но это неподъёмная задача, по крайней мере, для новичков. Так с чего начать? с какой стороны подойти?
Данных очень много, хочется как-то их систематизировать и разбить на группы, чтобы было понятно всем, с одной стороны, а с другой стороны, чтобы облегчить процесс моделирования. Процесс создания структур для больших областей знаний есть не что иное как создание онтологий. Онтология - это смысловой каркас или шаблон, наложенный сверху, ракурс (holistic view), позволяющий быстро ориентироваться в выбранной области знаний и, конечно, добавлять новые значения и термины в правильные, заранее отведенные им места. Самый известный всем пример онтологии - это систематизация живых организмов.
В статье про супер-домены данных был пример онтологии предприятия - это архитектурный фреймворк Захмана:
Используя этот фреймворк, можно подвергнуть систематизации данные в организации. Логика тут очень простая: если данные описывают всё, что происходит на предприятии от задумки (планов) до реализации (результатов), и охватывают абсолютно все бизнес-функции, то будет вполне очевидным действием поделить все данные на шесть кучек по аналогии с фреймворком Захмана.
Вот теперь моделировать данные станет на порядок проще и понятнее. Моделирование осуществляется от процесса/продукта или бизнес-сервиса. Любой процесс можно описать через взаимодействие основных бизнес-сущностей. Минимально в любом процессе выделяют шесть бизнес сущностей, которые описывают процесс, каждая отвечает на свой вопрос. Сам процесс или документ, который его описывает, тоже является бизнес-сущностью.
Теперь, принимая во внимание всё выше изложенное, подготовим шаблон для типового процесса/продукта. Спроектируем модель данных процесса, используя любой из способов визуализации - ER-диаграммы или Class-диаграммы. Для разнообразия выполнено в ERD.
Получили так называемую "рыбу", которую можно подставить в любой процесс/продукт. Заполните названия сущностей своими оригинальными именами из продукта/процесса и - Вуаля! - концептуальная модель данных готова)) Что дальше? Нужно будет рассмотреть каждую бизнес-сущность детально, практически под лупой, чтобы из концептуальной модели плавно перетечь в логическую.
На пути к ЛМД (логической модели данных) один простой шаг - моделирование бизнес-сущностей: наполнение каждой выделенной вами в процессе сущности характеристиками и свойствами, которые важны для выполнения бизнес-процесса. Кое-какие из этих свойств тоже окажутся бизнес-сущностями или справочными данными, т.е. у вас на диаграмме появятся связи с новыми объектами данных. Хорошо, если у вас есть заранее подготовленные Концепты* или Шаблоны, на которые можно опереться при дальнейшем проектировании, если нет, то придётся брать на себя ответственность за создание новых объектов. Не забывайте классифицировать ваши новые объекты - относить их к той или иной категории данных в соответствии с Рис.2 и аккуратненько складывать куда-то, чтоб было "под рукой". Поверьте мне, вы ещё не раз к ним вернётесь. Очень хорошо для такого склада подойдут системы проектирования с репозиториями данных.
Не все из бизнес-сущностей вашего процесса будут создаваться внутри него. Некоторые из сущностей вы будете заимствовать из чужих процессов, а что-то, возможно, даже из внешних систем. Для таких бизнес-сущностей вы не сможете определить полный набор характеристик, так как не владеете полной информацией о них. Про Владельцев и владение сущностями - читайте тут. Если бизнес-сущность создается и контролируется бизнес-процессом – вы ей владеете, она ваша родная бизнес-сущность и является мастер-сущностью для вашего процесса. Если бизнес-сущность необходима для функционирования процесса, но создана и доставлена из других систем и процессов, то она – переиспользуемая сущность. Не нужно напрягаться и пытаться угадать для таких бизнес-сущностей все атрибуты, укажите только те, которые используете в своем процессе.
Признак - мастер/переиспользуемая - полезно иметь на бизнес-сущности, поэтому старайтесь помечать им объекты данных при проектировании своей предметной области (процесса). Для чего он вам может пригодиться, можно посмотреть в статье DQ: Бизнес-требования к качеству данных. Часть 2.
*Концепт - это объект концептуальной модели данных, является проекцией объекта реального мира и существует не зависимо от деятельности организации. Концепт - это домен данных, который является родительской сущностью для прочих объектов, наследующих от него поведение и основные свойства (характеристики). Пример: Концепт - Заказ, подтипы (потомки или бизнес-сущности) - Заказ на продажу, Заказ на покупку.
Материалы статьи выложены на Bootsy - по ссылке
Увидели незнакомые слова - поищите в Толковом словаре Data Governance
Поддержать канал | Подписаться на скачивание файлов | Читать в телеграм
Если статья была полезна или просто понравилась, помогите другим быстрее найти её - поставьте лайк.
