Моделирование данных в программной инженерии — это процесс создания модели данных для информационной системы путем применения определенных формальных методов. Может применяться как часть более широкой концепции Model-driven engineering (MDE).
Моделирование данных — это процесс , используемый для определения и анализа требований к данным , необходимых для поддержки бизнес-процессов в рамках соответствующих информационных систем в организациях. Таким образом, процесс моделирования данных включает профессиональных разработчиков моделей данных, работающих в тесном сотрудничестве с заинтересованными сторонами бизнеса, а также потенциальными пользователями информационной системы.
Существует три различных типа моделей данных, создаваемых при переходе от требований к фактической базе данных, которая будет использоваться для информационной системы. [2] Требования к данным изначально регистрируются как концептуальная модель данных , которая по сути является набором независимых от технологий спецификаций данных и используется для обсуждения начальных требований с заинтересованными сторонами бизнеса. Затем концептуальная модель преобразуется в логическую модель данных , которая документирует структуры данных, которые могут быть реализованы в базах данных. Реализация одной концептуальной модели данных может потребовать нескольких логических моделей данных. Последним шагом в моделировании данных является преобразование логической модели данных в физическую модель данных , которая организует данные в таблицы и учитывает доступ, производительность и детали хранения. Моделирование данных определяет не только элементы данных, но также их структуры и отношения между ними. [3]
Методы и методики моделирования данных используются для моделирования данных стандартным, последовательным и предсказуемым образом, чтобы управлять ими как ресурсом. Использование стандартов моделирования данных настоятельно рекомендуется для всех проектов, требующих стандартных средств определения и анализа данных в организации, например, с использованием моделирования данных:
Моделирование данных может выполняться в ходе различных типов проектов и на нескольких этапах проектов. Модели данных являются прогрессивными; не существует такого понятия, как окончательная модель данных для бизнеса или приложения. Вместо этого модель данных следует рассматривать как живой документ, который будет меняться в ответ на изменение бизнеса. В идеале модели данных должны храниться в репозитории, чтобы их можно было извлекать, расширять и редактировать с течением времени. Уиттен и др. (2004) определили два типа моделирования данных: [4]
Моделирование данных также используется как метод детализации бизнес- требований для конкретных баз данных . Иногда его называют моделированием базы данных , поскольку модель данных в конечном итоге реализуется в базе данных. [4]
Модели данных обеспечивают основу для данных , которые будут использоваться в информационных системах , предоставляя конкретные определения и форматы. Если модель данных используется последовательно во всех системах, то может быть достигнута совместимость данных. Если для хранения и доступа к данным используются одни и те же структуры данных, то различные приложения могут беспрепятственно обмениваться данными. Результаты этого показаны на диаграмме. Однако системы и интерфейсы часто дороги в создании, эксплуатации и обслуживании. Они также могут ограничивать бизнес, а не поддерживать его. Это может произойти, когда качество моделей данных, реализованных в системах и интерфейсах, является низким. [1]
Вот некоторые распространенные проблемы, встречающиеся в моделях данных:
В 1975 году ANSI описал три типа экземпляров модели данных : [5]
Согласно ANSI, этот подход позволяет трем перспективам быть относительно независимыми друг от друга. Технология хранения может меняться, не влияя ни на логическую, ни на концептуальную схему. Структура таблицы/столбца может меняться, не влияя (обязательно) на концептуальную схему. В каждом случае, конечно, структуры должны оставаться согласованными во всех схемах одной и той же модели данных.
В контексте интеграции бизнес-процессов (см. рисунок) моделирование данных дополняет моделирование бизнес-процессов и в конечном итоге приводит к созданию базы данных. [6]
Процесс проектирования базы данных включает создание ранее описанных трех типов схем — концептуальной, логической и физической. Проект базы данных, задокументированный в этих схемах, преобразуется с помощью языка определения данных , который затем может быть использован для создания базы данных. Полностью атрибутированная модель данных содержит подробные атрибуты (описания) для каждой сущности в ней. Термин «проект базы данных» может описывать множество различных частей проекта всей системы базы данных . В основном и наиболее правильно его можно рассматривать как логический проект базовых структур данных, используемых для хранения данных. В реляционной модели это таблицы и представления . В объектной базе данных сущности и отношения напрямую отображаются в классы объектов и именованные отношения. Однако термин «проект базы данных» также может использоваться для применения к общему процессу проектирования, не только базовых структур данных, но также форм и запросов, используемых как часть общего приложения базы данных в системе управления базами данных или СУБД.
В этом процессе системные интерфейсы составляют от 25% до 70% затрат на разработку и поддержку текущих систем. Основной причиной этих затрат является то, что эти системы не используют общую модель данных . Если модели данных разрабатываются на основе систем, то не только один и тот же анализ повторяется в перекрывающихся областях, но и должен быть выполнен дополнительный анализ для создания интерфейсов между ними. Большинство систем в организации содержат одни и те же основные данные, переработанные для определенной цели. Поэтому эффективно спроектированная основная модель данных может минимизировать переделку с минимальными изменениями для целей различных систем в организации [1]
Модели данных представляют информационные области интереса. Хотя существует много способов создания моделей данных, по словам Лена Сильверстона (1997) [7], выделяются только две методологии моделирования: сверху вниз и снизу вверх:
Иногда модели создаются в смеси двух методов: путем рассмотрения потребностей в данных и структуры приложения и путем последовательного обращения к модели предметной области. Во многих средах различие между логической моделью данных и физической моделью данных размыто. Кроме того, некоторые инструменты CASE не делают различия между логическими и физическими моделями данных . [7]
Существует несколько обозначений для моделирования данных. Фактическая модель часто называется «моделью сущность–связь», поскольку она отображает данные в терминах сущностей и связей, описанных в данных . [ 4] Модель сущность–связь (ERM) — это абстрактное концептуальное представление структурированных данных. Моделирование сущности–связь — это метод моделирования реляционной схемы базы данных , используемый в программной инженерии для создания типа концептуальной модели данных (или семантической модели данных ) системы, часто реляционной базы данных , и ее требований сверху вниз .
Эти модели используются на первом этапе проектирования информационной системы во время анализа требований для описания информационных потребностей или типа информации , которая должна храниться в базе данных . Метод моделирования данных может использоваться для описания любой онтологии (т. е. обзора и классификации используемых терминов и их взаимосвязей) для определенной области дискурса, т. е. области интереса.
Было разработано несколько методов для проектирования моделей данных. Хотя эти методологии направляют разработчиков моделей данных в их работе, два разных человека, использующих одну и ту же методологию, часто будут приходить к совершенно разным результатам. Наиболее примечательными являются:
Универсальные модели данных являются обобщениями обычных моделей данных . Они определяют стандартизированные общие типы отношений, а также виды вещей, которые могут быть связаны таким типом отношений. Определение универсальной модели данных похоже на определение естественного языка. Например, универсальная модель данных может определять такие типы отношений, как «отношение классификации», являющееся бинарным отношением между отдельной вещью и видом вещей (классом), и «отношение часть-целое», являющееся бинарным отношением между двумя вещами, одна из которых играет роль части, а другая — роль целого, независимо от вида вещей, которые связаны.
Учитывая расширяемый список классов, это позволяет классифицировать любую отдельную вещь и определять отношения часть-целое для любого отдельного объекта. Благодаря стандартизации расширяемого списка типов отношений, общая модель данных позволяет выражать неограниченное количество видов фактов и приближается к возможностям естественных языков. Обычные модели данных, с другой стороны, имеют фиксированную и ограниченную область действия, поскольку инстанцирование (использование) такой модели допускает выражения только тех видов фактов, которые предопределены в модели.
Логическая структура данных СУБД, будь то иерархическая, сетевая или реляционная, не может полностью удовлетворить требованиям концептуального определения данных, поскольку она ограничена по объему и смещена в сторону стратегии реализации, используемой СУБД. Это если только семантическая модель данных не реализована в базе данных намеренно, выбор, который может немного повлиять на производительность, но в целом значительно повышает производительность.
Таким образом, необходимость определения данных с концептуальной точки зрения привела к разработке методов семантического моделирования данных . То есть методов определения значения данных в контексте их взаимосвязей с другими данными. Как показано на рисунке, реальный мир, с точки зрения ресурсов, идей, событий и т. д., символически определен в физических хранилищах данных. Семантическая модель данных — это абстракция, которая определяет, как хранимые символы соотносятся с реальным миром. Таким образом, модель должна быть истинным представлением реального мира. [8]
Целью семантического моделирования данных является создание структурной модели фрагмента реального мира, называемого «универсумом дискурса». Для этого рассматриваются четыре фундаментальных структурных отношения:
Семантическая модель данных может использоваться для решения многих задач, например: [8]
Общая цель семантических моделей данных — захватить больше смысла данных путем интеграции реляционных концепций с более мощными концепциями абстракции, известными из области искусственного интеллекта . Идея состоит в том, чтобы предоставить примитивы моделирования высокого уровня как неотъемлемую часть модели данных для того, чтобы облегчить представление ситуаций реального мира. [10]
В статье использованы материалы, являющиеся общественным достоянием Национального института стандартов и технологий.