Конспект DMBOK2 → Глава 5. Моделирование данных

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

Конспект DAMA DMBOK2 на русском языке

Глава 5

Глоссарий проекта и вебинар-обсуждение

Конспект каждой главы мы сопровождаем онлайн-дискуссией с экспертами по теме

Вебинар DMBOK2 → Глава 5. Моделирование данных

Вебинар по прикладным идеям DMBOK2

Глоссарий → DAMA DMBOK2

Все термины и определения по проекту Конспекта DAMA DMBOK2. Собраны на одной страничке для вашего удобства с любовью

Понятие и цель моделирования данных

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

Наиболее часто используются следующие схемы представления данных:
→ реляционная
→ многомерная (dimensional)
→ объектно-ориентированная
→ основанная на фактах (fact-based)
→ хронологическая (time-based)
→ NoSQL2

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

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

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

Формализация

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

Определение области применения

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

Сохранение и документирование знаний

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

Основные концепции моделирования

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

NB: Данные в покое и в движении. Что это?

Как правило, модели данных включают «данные в покое» (data at rest), т.е. статичные данные, находящиеся в местах хранения. Однако «данные в движении» (data in motion) (динамичные, перемещающиеся данные) также можно моделировать: например, с помощью описаний системных решений, включая протоколы, а также специфических схем для систем обмена сообщениями и систем на основе событий (event-based systems).

Компоненты модели данных

Сущность

Предмет, о котором организация собирает информацию

Альтернативные наименования (aliases) понятия «сущность»

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

Используемые компоненты модели данных могут называться по-разному, в зависимости от типа модели данных. Например, для обозначения понятия «сущность» могут использоваться:

в реляционных схемах — сущность
в многомерных схемах — таблица фактов (fact table) и таблица измерений (dimension table)
в объектно-ориентированных схемах — термины класс (class) или объект (object)
в хронологических схемах — термины концентратор (или хаб — hub), сателлит (satellite) и связь (link)
в схемах NoSQL — такие термины, как документ (document) или узел (node)

Связь (relationship)

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

Мощность (cardinality) связи

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

Атрибут (attribute)

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

Идентификатор
(или ключ — key)

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

Ключи могут быть:
→ простыми
→ составными
→ композитными
→ потенциальными

Домен (domain)

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

Домены атрибутов задаются наложением ограничений следующих видов:
→ Типы данных
→ Форматы данных
→ Списки
→ Допустимые интервалы
→ Реализация правил

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

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

Концептуальная модель данных (Conceptual Data Model, CDM)

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

Логическая модель данных (Logical Data Model, LDM)

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

Физическая модель данных (Physical Data Model, PDM)

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

Представление (view)

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

Секционирование (partitioning)

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

Денормализация (denormalization) данных

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

Зачем нужна денормализация?

Основная причина — повышение производительности за счет использования следующих приемов:

→ Предварительная заготовка сводных таблиц данных из множества других таблиц во избежание необходимости затратного по времени и аппаратным ресурсам многократного повторного объединения одних и тех же данных во время выполнения приложения
→ Создание предварительно отфильтрованных выборочных копий данных с целью снижения затрат времени на операционные расчеты и/или сканирование больших таблиц
→ Предварительное проведение и сохранение результатов ресурсоемких расчетов с использованием базовых данных с целью снижения конкуренции процессов за системные ресурсы во время выполнения

Нормализация (normalization) данных

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

Уровни нормализации

→ Первая нормальная форма (1NF).
→ Вторая нормальная форма (2NF)
→ Третья нормальная форма (3NF)
→ Нормальная форма Бойса — Кодда (BCNF)
→ Четвертая нормальная форма (4NF)
→ Пятая нормальная форма (5NF)

Абстрагирование

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

Проводимые работы

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

→

Прямое проектирование — forward engineering. Построение нового приложения, начиная с выяснения предъявляемых к нему требований. Cначала создается CMD, чтобы понять границы и состав предстоящих работ, выработать и согласовать ключевую терминологию. Затем создается LMD, документирующая бизнес-решение, и наконец — PMD, документирующая техническое решение.

Создание концептуального моделирования данных (CMD) включает:

Выбор схемы
Выбор нотации
Создание исходной CMD
Учет корпоративной терминологии
Окончательное согласование

→

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

Анализ информационных потребностей
Анализ имеющейся документации
Добавление ассоциативных сущностей
Добавление атрибутов
Определение доменов
Определение ключей

→

Физическое моделирование данных включает:

Разрешение логических абстракций
Добавление детальной информации об атрибутах
Добавление объектов справочных данных
Определение суррогатных ключей
Повышение производительности за счет денормализации
Повышение производительности за счет индексирования
Повышение производительности за счет секционирования
Создание представлений данных

→

Обратное проектирование (или реверс-инжиниринг — reverse engineering). Это процесс документирования существующей базы данных. Первым делом составляется PMD с целью понять техническое устройство имеющейся системы, затем создается LMD с целью документирования решаемых ею бизнес-задач, и, наконец, подготавливается CMD для документирования области применения системы и используемой терминологии.

Лучшие практики

Рекомендации в области именования содержатся в международном стандарте ISO 11 179 «Регистры метаданных».

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

Также, есть стандарт проектирования баз данных PRISM.

Performance: Производительность и простота использования
Reusability: Возможность повторного использования
Integrity: Целостность (все без исключения данные должны быть корректными и непротиворечивыми вне зависимости от контекста, а также обязаны точно отражать фактическую ситуацию в бизнесе)
Security: Безопасность (достоверные и точные данные должны быть всегда доступны авторизованным пользователям, но надежно защищены от несанкционированного доступа)
Maintainability: Удобство сопровождения (Весь комплекс работ по сопровождению данных должен быть окупаемым, т. е. суммарные затраты на создание, хранение, ведение, использование и ликвидацию данных должны быть ниже суммарной оценки выгод, которые эти данные приносят организации)

Управление качеством моделей и проектных решений

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

Управление версиями и интеграцией моделей данных

Почему проект или ситуация потребовали внесения изменения?

Что и Как именно было изменено?

С точным описанием добавленных, удаленных или измененных столбцов и связанных с ними изменений

Когда было утверждено решение о внесении изменения и когда оно было внесено в модель?

Кто внес изменение?

Где внесено изменение?

Конспект по управлению данными → DAMA DMBOK2

Глоссарий → DAMA DMBOK2

Эксперты проекта → DAMA DMBOK2

Конспект DMBOK2 → Глава 1. Управление данными

Конспект DMBOK2 → Глава 2. Этика данных