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

Эта статья дублирует тематику других статей , в частности Модель данных . Пожалуйста, обсудите этот вопрос и помогите ввести стиль резюме в статью. ( Март 2023 )

Моделирование данных в программной инженерии — это процесс создания модели данных для информационной системы путем применения определенных формальных методов. Может применяться как часть более широкой концепции Model-driven engineering (MDE).

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

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

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

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

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

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

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

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

Вот некоторые распространенные проблемы, встречающиеся в моделях данных:

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

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

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

Согласно ANSI, этот подход позволяет трем перспективам быть относительно независимыми друг от друга. Технология хранения может меняться, не влияя ни на логическую, ни на концептуальную схему. Структура таблицы/столбца может меняться, не влияя (обязательно) на концептуальную схему. В каждом случае, конечно, структуры должны оставаться согласованными во всех схемах одной и той же модели данных.

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

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

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

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

• Модели «снизу вверх» или модели View Integration часто являются результатом усилий по реинжинирингу . Обычно они начинаются с существующих структур данных, форм, полей на экранах приложений или отчетов. Эти модели обычно являются физическими, специфичными для приложений и неполными с точки зрения предприятия . Они могут не способствовать обмену данными, особенно если они построены без ссылки на другие части организации. ^[7]
• С другой стороны, логические модели данных сверху вниз создаются абстрактным способом, получая информацию от людей, которые знают предметную область. Система может не реализовывать все сущности в логической модели, но модель служит точкой отсчета или шаблоном. ^[7]

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

Существует несколько обозначений для моделирования данных. Фактическая модель часто называется «моделью сущность–связь», поскольку она отображает данные в терминах сущностей и связей, описанных в данных . [ ^4] Модель сущность–связь (ERM) — это абстрактное концептуальное представление структурированных данных. Моделирование сущности–связь — это метод моделирования реляционной схемы базы данных , используемый в программной инженерии для создания типа концептуальной модели данных (или семантической модели данных ) системы, часто реляционной базы данных , и ее требований сверху вниз .

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

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

• Диаграммы Бахмана
• Нотация Баркера
• Обозначение Чена
• Моделирование хранилища данных
• Расширенная форма Бэкуса–Наура
• IDEF1X
• Объектно-реляционное отображение
• Объектно-ролевое моделирование и полностью коммуникационно-ориентированное информационное моделирование
• Реляционная модель
• Реляционная модель/Тасмания

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

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

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

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

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

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

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

• Планирование ресурсов данных
• Создание общих баз данных
• Оценка программного обеспечения поставщика
• Интеграция существующих баз данных

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

• Архитектурный образец
• Сравнение инструментов моделирования данных
• Данные (компьютерные науки)
• Словарь данных
• Моделирование документов
• Моделирование корпоративных данных
• Модель данных сущности
• Управление информацией
• Информационная модель
• Информационное моделирование зданий
• Моделирование метаданных
• Трёхсхемный подход
• Структура Захмана

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

• JH ter Bekke (1991). Семантическое моделирование данных в реляционных средах
• Джон Винсент Карлис, Джозеф Д. Магуайр (2001). Освоение моделирования данных: подход, ориентированный на пользователя .
• Алан Чмура, Дж. Марк Хойманн (2005). Логическое моделирование данных: что это такое и как это делать .
• Мартин Э. Моделл (1992). Анализ данных, моделирование данных и классификация .
• М. Папазоглу, Стефано Спаккапьетра, Захир Тари (2000). Достижения в объектно-ориентированном моделировании данных .
• Г. Лоуренс Сандерс (1995). Моделирование данных
• Грэм К. Симсион, Грэм К. Витт (2005). Основы моделирования данных
• Мэтью Уэст (2011) Разработка высококачественных моделей данных

На Викискладе есть медиафайлы по теме «Моделирование данных» .

• Гибкое/эволюционное моделирование данных
• Статьи по моделированию данных Архивировано 7 марта 2010 г. на Wayback Machine
• Моделирование базы данных в UML
• Моделирование данных 101
• Семантическое моделирование данных
• Разработка систем, методологии и моделирование Архивировано 7 марта 2012 г. в Wayback Machine Заметки Тони Дрюри
• Запрос предложений - Метамодель управления информацией (IMM) Группы управления объектами
• Моделирование данных предназначено НЕ только для СУБД Часть 1 Крис Брэдли
• Моделирование данных предназначено НЕ только для СУБД Часть 2 Крис Брэдли