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

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

В процессе перехода от требований к реализации базы данных для информационной системы разрабатываются три типа моделей данных^[2]. Требования к данным первоначально отражаются в концептуальной модели данных — независимом от технологий наборе спецификаций, предназначенном для обсуждения начальных требований с бизнес-стейкхолдерами. Затем концептуальная модель преобразуется в логическую модель данных, в которой документируются структуры данных, подлежащие реализации в базах данных. Одна концептуальная модель может требовать реализации в виде нескольких логических моделей данных. Заключительный этап — преобразование логической модели данных в физическую модель данных, которая организует данные в таблицы, учитывая вопросы доступа, производительности и хранения. Моделирование данных определяет не только элементы данных, но и их структуры и взаимосвязи^[3].

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

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

Моделирование данных может производиться на разных этапах и типах проектов. Модели данных развиваются во времени: не существует окончательной окончательной модели для бизнеса или приложения. Модель данных — это «живой» документ, изменяющийся по мере изменения бизнеса. Желательно хранить их в репозитории для последующего поиска, расширения и редактирования. Уитт выделяет два типа моделирования данных:^[4]

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

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

Модели данных предоставляют каркас (структуру) для использования данных в рамках информационных систем, задавая их формат и определения. Последовательное использование модели данных в разных системах обеспечивает совместимость данных. Если одни и те же структуры данных используются для хранения и доступа, приложения могут напрямую обмениваться данными. Впрочем, создание и поддержка таких систем и интерфейсов может быть дорогостоящим, а непродуманные модели способны ограничить, а не поддержать бизнес. Это происходит, когда качество реализованных моделей данных в системах и интерфейсах невысоко^[1].

Распространённые проблемы моделей данных:

• Бизнес-правила, характерные для конкретной организации, зачастую «зашиваются» в структуру модели данных. В результате даже небольшие изменения в бизнес-процессах приводят к необходимости сильно менять информационные системы и интерфейсы. Поэтому бизнес-правила должны реализовываться гибко, с минимизацией сложных зависимостей, а сама модель данных — быть достаточно адаптивной для быстрых и эффективных изменений.
• Типы сущностей часто определяются неверно или не определяются вовсе, что порождает дублирование данных, структур и функций, увеличивая издержки на разработку и сопровождение. Определения данных должны быть максимально явными и понятными — для устранения неоднозначностей и дублирования.
• Модели данных разных систем зачастую различаются без объективной причины, из-за чего для обмена данными требуются сложные интерфейсы, иногда составляющие от 25 до 70 % стоимости систем. Необходимые интерфейсы следует закладывать на этапе проектирования модели данных, иначе она окажется малоприменимой сама по себе.
• Данные не могут быть переданы клиентам и поставщикам в электронном виде из-за несогласованности структур и значений. Поэтому для оптимального использования внедрённой модели крайне важно определить стандарты, обеспечивающие удовлетворение бизнес-потребностей и согласованность данных^[1]

В 1975 году ANSI выделил три вида экземпляров модели данных:^[5].

• Концептуальная схема: описывает семантику предметной области (область применимости модели). Это может быть модель интересов организации или отрасли, состоящая из классов сущностей (типов данных) и описаний отношений между парами классов. Концептуальная схема фиксирует виды фактов или утверждений, которые могут быть представлены с помощью данной модели — то есть определяет допустимые высказывания некоего искусственного языка, ограниченного её областью. Это первая стадия организации требований к данным.
• Логическая схема: отражает структуру некоторой области данных — таблицы, столбцы, классы объектов, XML-тэги и др. Иногда логическая и концептуальная схема реализуются совместно^[2].
• Физическая схема: описывает физическую организацию хранения данных (разделы, процессоры, табличные пространства и т.д.).

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

В рамках интеграции бизнес-процессов моделирование данных дополняет моделирование бизнес-процессов и в итоге приводит к генерации базы данных^[6].

Дизайн базы данных включает создание трёх описанных выше типов схем: концептуальной, логической и физической. Проектная документация преобразуется с помощью языка определения данных, используемого затем для генерации базы данных. Полноценная модель данных включает детальные атрибуты для каждой сущности. Термин «проектирование базы данных» может обозначать различные аспекты проектирования, но, строго говоря, — это логическое проектирование базовых структур хранения данных: таблиц и представлений в реляционной модели или классов и отношений — в объектной модели. Иногда термином обозначают и проектирование форм, запросов и других элементов интерфейса внутри системы управления базами данных (СУБД).

Современные интерфейсы систем занимают от 25 до 70 % затрат на разработку и сопровождение, часто из-за отсутствия общего стандарта модели данных. Если модели данных разрабатываются по отдельности для каждой системы, дублирование анализа и дополнительная разработка интерфейсов многократно увеличивают трудозатраты. Большинство корпоративных систем используют одни и те же базовые данные, адаптируя их под свои цели. Эффективно спроектированная базовая модель данных минимизирует повторную работу и упрощает интеграцию систем^[1]

Модели данных описывают информационные сферы интересов. Хотя существует множество способов их построения, по мнению Лена Сильверстона (1997)^[7]., особо выделяются две методологии: нисходящая и восходящая:

• Восходящие модели (или модели интеграции представлений) возникают обычно при реинжиниринге: они строятся на основе существующих форм хранения данных, экранных форм, отчётов приложений. Обычно это физические, специфичные для приложения и неполные с точки зрения корпоративной архитектуры модели, не способствующие обмену данными (особенно без учёта других частей организации)^[7].
• Нисходящие логические модели данных, напротив, конструируются абстрактно — на основании информации, полученной от экспертов предметной области. Конкретная система может реализоваться не полностью в рамках логической модели, но она служит ориентиром или шаблоном^[7].

Иногда используется сочетание обоих подходов: при одновременном учёте потребностей/структуры приложения и ссылках на модели предметной области. В ряде сред граница между логической и физической моделью размыта; некоторые CASE-системы вообще не разграничивают их^[7]

Существует несколько нотаций моделирования данных. Наиболее часто модель называют моделью «сущность–связь», так как она отображает данные в терминах сущностей и отношений между ними. Модель «сущность–связь» (ERM) — это абстрактное концептуальное представление структурированных данных. Этот метод моделирования является основным для реляционных схем, используется для проектирования концептуальных моделей данных (или семантических моделей) системы, часто реляционной базы данных, и её требований — в «нисходящем» стиле.

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

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

• Диаграммы Бахмана
• нотация Баркера
• нотация Чена
• Data Vault Modeling
• расширенная форма Бэкуса — Наура
• IDEF1X
• объектно-реляционное отображение
• object-role modeling и полностью коммуникационно-ориентированное информационное моделирование
• реляционная модель
• реляционная модель/Tasmania

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

По сути, определение обобщённой модели данных похоже на описание естественного языка. Например, такая модель может предусматривать отношения «классификация» (бинарная связь между объектом и классом) либо «часть–целое» (бинарная связь между двумя объектами, один из которых — часть, другой — целое, вне зависимости от их типа).

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

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

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

Цель семантического моделирования — построить структурную модель части реального мира (или «универсума дискурса»). Для этого выделяют три фундаментальных отношения:

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

Семантическая модель данных может быть использована для:^[8]

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

Общая задача — повысить выразительность моделей за счёт интеграции реляционных представлений с более мощными средствами абстракции, заимствованными из искусственного интеллекта. Это позволяет вводить высокоуровневые примитивы моделирования как неотъемлемую часть модели данных — для представления сложных реальных ситуаций^[10].