Что такое моделирование и проектирование данных

Зачем моделирование и проектирование данных

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 отвечает за то, чтобы структуры данных продумывались до того, как их построят в системах. DAMA-DMBOK описывает моделирование так: требования к данным выявляют, разбирают и формулируют, а потом записывают в строго заданном виде — в модели — и доводят до тех, кому по ней работать. Работа идёт кругами и обычно даёт три модели: концептуальную, логическую и физическую 1.

Цель практики: понять устройство данных, подтвердить это понимание и записать его. На такой записи строят приложения под сегодняшние и завтрашние потребности бизнеса, и с неё же начинают крупные начинания — управление основными данными и руководство данными 1.

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

Именно поэтому практика не сводится к рисованию схем: модель — это способ договориться о смысле до того, как несогласие станет дорогим.

Когда практика работает

Три вопроса, ответы на которые видны по ходу проектов.

Модель есть до реализации. Как проверить: перед изменением структуры хранилища существует согласованная модель.

Уровни разведены. Как проверить: организация различает концептуальную, логическую и физическую модели 1.

Модели сопровождаются. Как проверить: сопровождение моделей — отдельная работа практики, а не разовое действие в проекте 1.

Что входит и что рядом

Что на входе и что на выходе

DAMA-DMBOK перечисляет вход и выход прямо. На вход идут 1:

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

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

Три уровня модели и зачем их различать

Уровни идут по возрастанию подробности 1.

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

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

Физическая модель описывает реализацию в конкретной базе: типы, индексы, разбиение, особенности выбранной системы хранения 1.

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

DAMA-DMBOK перечисляет и схемы представления данных; чаще всего пользуются шестью: реляционной, многомерной, объектно-ориентированной, основанной на фактах, хронологической и NoSQL 1. Выбор схемы — решение практики, а не следствие привычки разработчика.

Как это работает

Практика раскладывается на четыре работы: планирование моделирования, построение моделей, проверка и оценка их качества, сопровождение 1.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение

Две строки этой таблицы стоит развернуть.

Второй шаг — разговор с бизнесом, а не с системой. Концептуальная модель содержит только то, без чего бизнесу не обойтись, и описания связей между понятиями 1. Если её строит один разработчик, договорённости не возникает.

Седьмой шаг определяет, останется ли практика. Сопровождение моделей выделено отдельной работой 1: модель, разошедшаяся с базой, вводит в заблуждение вернее, чем её отсутствие.

Что с чем путают

Модель данных и схема базы. Схема — реализация; модель включает и уровень понятий 1.

Моделирование и архитектура данных. Архитектура даёт общую картину и требования, моделирование — конкретные структуры. Разбор про архитектуру — DtAУправление архитектурой данных.

Логическая модель и физическая. Первая не зависит от системы хранения, вторая учитывает её особенности 1.

Модель и документация. DAMA-DMBOK называет модели главным средством общения в проектах 1 — то есть рабочим инструментом, а не отчётом.

Именование и вкусовщина. DAMA-DMBOK относит соглашения об именовании к методам практики 1: это правила, а не предпочтения.

Кто участвует

Как измерять

У качества модели есть готовая мерка со счётом в баллах. DMBOK приводит шаблон ведомости оценки модели данных Data Model Scorecard® (Hoberman, 2015): десять категорий, у каждой свой максимум баллов, эксперт выставляет оценку в этих пределах, а рядом считается процент 1. Категории такие:

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

Балл без объяснения не принимается. В ведомости есть столбец «Комментарии», и заполнять его обязательно: проверяющий «должен объяснять причины снижения оценки относительно максимальной и/или давать рекомендации по устранению недостатков» 1. Это и отличает ведомость от рейтинга: она не выносит приговор модели, а называет, что в ней чинить. Пример счёта книга даёт прямо: 10 баллов из 15 возможных по первой категории дают в столбце степени соответствия значение 66% 1.

Мерка требует эталона. «К объективной оценке качества моделей данных можно подходить с различными наборами мерок и критериев, но в любом случае необходима эталонная база сравнения» 1. Без ответа на вопрос «по сравнению с чем» сумма баллов остаётся числом, о котором нечего сказать.

Зрелость моделирования и проектирования данных

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Модель появляется после базы. Структуру рисуют по факту созданного, и договорённости о смысле не возникает.

Уровни смешаны. Разговор о понятиях подменяется спором о типах полей 1.

Модель не сопровождается. База ушла вперёд, модель осталась в прошлом году 1.

Именование стихийное. Одна сущность называется тремя способами в трёх системах 1.

Дело в моделировании не участвует. Концептуальную модель строит разработчик, а спорят потом с заказчиком 1.

Схема выбрана по привычке. Перечислены шесть распространённых схем представления данных — выбор стоит делать осознанно 1.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

DAMA-DMBOK держит моделирование и проектирование данных отдельной областью знаний с определением, целями, входами, выходами и четырьмя работами 1.

COBIT отдельной цели под моделирование не заводит: требования к структурам данных приходят через управление данными и архитектуру предприятия 2.

ITIL ближайшую работу описывает в проектировании услугУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation и разработке: требования к решению и его устройству 3.

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

Где описано

Что почитать дальше

Три соседние практики: DtAУправление архитектурой данных — общая картина данных, MtMУправление метаданными — смысл полей, MRDУправление требованиями — как требования доходят до решения.