Моделирование данных
 | Эта статья дублирует сферу применения других статей , в частности , модели данных . . ( март 2023 г. ) |
| Часть серии о |
| Разработка программного обеспечения |
|---|
Моделирование данных в разработке программного обеспечения — это процесс создания модели данных для информационной системы с применением определенных формальных методов. Его можно применять как часть более широкой концепции проектирования на основе моделей (MDE).
Обзор [ править ]
Моделирование данных — это процесс , используемый для определения и анализа требований к данным , необходимых для поддержки бизнес-процессов в рамках соответствующих информационных систем в организациях. Таким образом, в процессе моделирования данных участвуют профессиональные специалисты по моделированию данных, работающие в тесном контакте с заинтересованными сторонами бизнеса, а также с потенциальными пользователями информационной системы.
Существует три различных типа моделей данных, создаваемых по мере перехода от требований к фактической базе данных, которая будет использоваться для информационной системы. [2] Требования к данным первоначально записываются в виде концептуальной модели данных , которая по сути представляет собой набор технологических независимых спецификаций данных и используется для обсуждения первоначальных требований с заинтересованными сторонами бизнеса. Концептуальная модель затем преобразуется в логическую модель данных , которая документирует структуры данных, которые могут быть реализованы в базах данных. Реализация одной концептуальной модели данных может потребовать нескольких логических моделей данных. Последним шагом в моделировании данных является преобразование логической модели данных в физическую модель данных , которая организует данные в таблицы и учитывает детали доступа, производительности и хранения. Моделирование данных определяет не только элементы данных, но также их структуры и отношения между ними. [3]
Техники и методологии моделирования данных используются для моделирования данных стандартным, последовательным и предсказуемым образом с целью управления ими как ресурсом. Использование стандартов моделирования данных настоятельно рекомендуется для всех проектов, требующих стандартных средств определения и анализа данных внутри организации, например, с использованием моделирования данных:
- помочь бизнес-аналитикам, программистам, тестировщикам, авторам руководств, подборщикам ИТ-пакетов, инженерам, менеджерам, соответствующим организациям и клиентам понять и использовать согласованную полуформальную модель, которая охватывает концепции организации и то, как они связаны друг с другом
- управлять данными как ресурсом
- интегрировать информационные системы
- проектировать базы данных/ хранилища данных (также известные как репозитории данных)
Моделирование данных может выполняться в ходе различных типов проектов и на нескольких этапах проектов. Модели данных являются прогрессивными; не существует такой вещи, как окончательная модель данных для бизнеса или приложения. Вместо этого модель данных следует рассматривать как живой документ, который будет меняться в ответ на изменение бизнеса. В идеале модели данных должны храниться в репозитории, чтобы их можно было извлекать, расширять и редактировать с течением времени. Уиттен и др. (2004) определили два типа моделирования данных: [4]
- Стратегическое моделирование данных: это часть создания стратегии информационных систем, которая определяет общее видение и архитектуру информационных систем. Инженерия информационных технологий — это методология, которая использует этот подход.
- Моделирование данных во время системного анализа. В системном анализе логические модели данных создаются как часть разработки новых баз данных.
Моделирование данных также используется как метод детализации бизнес- требований к конкретным базам данных . Иногда это называют моделированием базы данных , поскольку модель данных в конечном итоге реализуется в базе данных. [4]
Темы [ править ]
Модели данных [ править ]
Модели данных обеспечивают основу для данных использования в информационных системах, предоставляя конкретные определения и форматы. Если модель данных используется последовательно во всех системах, можно достичь совместимости данных. Если для хранения данных и доступа к ним используются одни и те же структуры данных, разные приложения могут беспрепятственно обмениваться данными. Результаты этого показаны на диаграмме. Однако создание, эксплуатация и обслуживание систем и интерфейсов часто обходятся дорого. Они также могут ограничивать бизнес, а не поддерживать его. Это может произойти, когда качество моделей данных, реализованных в системах и интерфейсах, низкое. [1]
Некоторые распространенные проблемы, возникающие в моделях данных:
- Бизнес-правила, специфичные для того, как все происходит в определенном месте, часто фиксируются в структуре модели данных. Это означает, что небольшие изменения в способах ведения бизнеса приводят к большим изменениям в компьютерных системах и интерфейсах. Таким образом, бизнес-правила должны быть реализованы гибким способом, который не приводит к сложным зависимостям, а модель данных должна быть достаточно гибкой, чтобы изменения в бизнесе могли быть реализованы в модели данных относительно быстро и эффективно.
- Типы сущностей часто не идентифицируются или идентифицируются неправильно. Это может привести к репликации данных, структуры данных и функциональности, а также к сопутствующим затратам на дублирование при разработке и обслуживании. Поэтому определения данных должны быть максимально ясными и простыми для понимания, чтобы свести к минимуму неправильное толкование и дублирование.
- Модели данных для разных систем сколь угодно различны. В результате между системами, обменивающимися данными, требуются сложные интерфейсы. Эти интерфейсы могут составлять от 25 до 70% стоимости существующих систем. При разработке модели данных следует учитывать необходимые интерфейсы, поскольку модель данных сама по себе невозможно использовать без интерфейсов в различных системах.
- Данные не могут передаваться в электронном виде клиентам и поставщикам, поскольку структура и значение данных не стандартизированы. Чтобы получить оптимальную ценность от реализованной модели данных, очень важно определить стандарты, которые гарантируют, что модели данных будут соответствовать потребностям бизнеса и быть согласованными. [1]
Концептуальные, логические и физические схемы [ править ]
В 1975 году ANSI модели данных описал три типа экземпляров : [5]
- Концептуальная схема : описывает семантику предметной области (объем модели). Например, это может быть модель области интересов организации или отрасли. Он состоит из классов сущностей, представляющих виды вещей, имеющих значение в предметной области, и утверждений об отношениях между парами классов сущностей. Концептуальная схема определяет виды фактов или предположений, которые могут быть выражены с помощью модели. В этом смысле он определяет разрешенные выражения на искусственном «языке» с областью действия, ограниченной областью действия модели. Проще говоря, концептуальная схема — это первый шаг в организации требований к данным.
- Логическая схема : описывает структуру некоторой области информации. Он состоит из описаний (например) таблиц, столбцов, объектно-ориентированных классов и тегов XML. Логическая схема и концептуальная схема иногда реализуются как одно и то же. [2]
- Физическая схема : описывает физические средства, используемые для хранения данных. Это касается разделов, процессоров, табличных пространств и т.п.
Согласно ANSI, этот подход позволяет трем точкам зрения быть относительно независимыми друг от друга. Технология хранения может меняться, не затрагивая ни логическую, ни концептуальную схему. Структура таблицы/столбца может меняться без (обязательно) влияния на концептуальную схему. Разумеется, в каждом случае структуры должны оставаться согласованными во всех схемах одной и той же модели данных.
моделирования Процесс данных
В контексте интеграции бизнес-процессов (см. рисунок) моделирование данных дополняет моделирование бизнес-процессов и в конечном итоге приводит к созданию базы данных. [6]
Процесс проектирования базы данных включает в себя создание ранее описанных трех типов схем — концептуальных, логических и физических. Проект базы данных, документированный в этих схемах, преобразуется с помощью языка определения данных , который затем можно использовать для создания базы данных. Полностью атрибутированная модель данных содержит подробные атрибуты (описания) для каждой сущности внутри нее. Термин «проектирование базы данных» может описывать множество различных частей проектирования всей системы базы данных . В принципе и наиболее правильно его можно рассматривать как логическое проектирование базовых структур данных, используемых для хранения данных. В реляционной модели это таблицы и представления . В базе данных объектов сущности и отношения напрямую сопоставляются с классами объектов и именованными отношениями. Однако термин «проектирование базы данных» можно также использовать для применения к общему процессу проектирования, не только базовых структур данных, но также форм и запросов, используемых как часть общего приложения базы данных в пределах базы данных. Система управления базами данных или СУБД.
При этом системные интерфейсы составляют от 25% до 70% затрат на разработку и поддержку существующих систем. Основная причина такой стоимости заключается в том, что эти системы не используют общую модель данных . Если модели данных разрабатываются посистемно, то не только один и тот же анализ повторяется в перекрывающихся областях, но необходимо выполнить дальнейший анализ для создания интерфейсов между ними. Большинство систем внутри организации содержат одни и те же основные данные, переработанные для конкретной цели. Таким образом, эффективно разработанная базовая модель данных может свести к минимуму доработку с минимальными изменениями для целей различных систем внутри организации. [1]
Методологии моделирования [ править ]
Модели данных представляют собой информационные области, представляющие интерес. существует множество способов создания моделей данных. По словам Лена Сильверстона (1997), [7] выделяются только две методологии моделирования: нисходящая и восходящая:
- Модели «снизу вверх» или модели интеграции представлений часто являются результатом усилий по реинжинирингу . Обычно они начинаются с существующих форм структур данных, полей на экранах приложений или отчетов. Эти модели обычно являются физическими, ориентированными на конкретные приложения и неполными с точки зрения предприятия . Они могут не способствовать обмену данными, особенно если они созданы без привязки к другим частям организации. [7]
- С другой стороны, нисходящие логические модели данных создаются абстрактным способом путем получения информации от людей, знающих предметную область. Система может не реализовывать все объекты логической модели, но модель служит ориентиром или шаблоном. [7]
Иногда модели создаются сочетанием двух методов: путем рассмотрения потребностей в данных и структуры приложения и путем последовательной ссылки на модель предметной области. Во многих средах различие между логической моделью данных и физической моделью данных размыто. Кроме того, некоторые инструменты CASE не делают различия между логическими и физическими моделями данных . [7]
Диаграммы сущность-связь [ править ]
Существует несколько обозначений моделирования данных. Фактическую модель часто называют «моделью сущность-связь», поскольку она отображает данные с точки зрения сущностей и отношений, описанных в данных . [4] Модель сущность-связь (ERM) — это абстрактное концептуальное представление структурированных данных. Моделирование сущностей-связей — это метод моделирования базы данных с реляционной схемой , используемый в разработке программного обеспечения для создания типа концептуальной модели данных (или семантической модели данных ) системы, часто реляционной базы данных , и ее требований в нисходящем порядке.
Эти модели используются на первом этапе проектирования информационной системы во время анализа требований для описания информационных потребностей или типа информации , которая должна храниться в базе данных . Технику моделирования данных можно использовать для описания любой онтологии (т. е. обзора и классификации используемых терминов и их взаимосвязей) для определенной вселенной дискурса, т. е. области интересов.
Для проектирования моделей данных было разработано несколько методов. Хотя эти методологии служат руководством для разработчиков моделей данных в их работе, два разных человека, использующие одну и ту же методологию, часто получают совершенно разные результаты. Наиболее примечательны:
- Диаграммы Бахмана
- Обозначение Баркера
- Обозначения Чена
- Моделирование хранилища данных
- Расширенная форма Бэкуса – Наура
- IDEF1X
- Объектно-реляционное отображение
- Объектно-ролевое моделирование и полностью коммуникационно-ориентированное информационное моделирование
- Реляционная модель
- Реляционная модель/Тасмания
данных Общее моделирование
Общие модели данных являются обобщением традиционных моделей данных . Они определяют стандартизированные общие типы отношений, а также виды вещей, которые могут быть связаны таким типом отношений. Определение общей модели данных аналогично определению естественного языка. Например, общая модель данных может определять такие типы отношений, как «классификационное отношение», представляющее собой бинарное отношение между отдельным объектом и типом объекта (классом), и «отношение часть-целое», представляющее собой бинарное отношение между две вещи, одна с ролью части, другая с ролью целого, независимо от того, какие вещи связаны между собой.
Учитывая расширяемый список классов, это позволяет классифицировать любую отдельную вещь и определять отношения часть-целое для любого отдельного объекта. За счет стандартизации расширяемого списка типов отношений общая модель данных позволяет выражать неограниченное количество видов фактов и приближается к возможностям естественных языков. С другой стороны, традиционные модели данных имеют фиксированную и ограниченную область применения, поскольку создание (использование) такой модели позволяет выражать только те виды фактов, которые заранее определены в модели.
данных моделирование Семантическое
Логическая структура данных СУБД, будь то иерархическая, сетевая или реляционная, не может полностью удовлетворить требования к концептуальному определению данных, поскольку она ограничена по объему и смещена в сторону стратегии реализации, используемой СУБД. Это происходит только в том случае, если семантическая модель данных не реализована в базе данных намеренно — выбор, который может незначительно повлиять на производительность, но в целом значительно повышает производительность.
Таким образом, необходимость определения данных с концептуальной точки зрения привела к разработке методов семантического моделирования данных . То есть методы определения значения данных в контексте их взаимосвязей с другими данными. Как показано на рисунке, реальный мир с точки зрения ресурсов, идей, событий и т. д. символически определяется в физических хранилищах данных. Семантическая модель данных — это абстракция , которая определяет, как хранимые символы соотносятся с реальным миром. Таким образом, модель должна быть истинным представлением реального мира. [8]
Целью семантического моделирования данных является создание структурной модели части реального мира, называемой «вселенной дискурса». Для этого рассматриваются четыре фундаментальных структурных отношения:
- Классификация/создание экземпляров: объекты с некоторым структурным сходством описываются как экземпляры классов.
- Агрегация/декомпозиция: составные объекты получаются путем соединения их частей.
- Обобщение/специализация: отдельные классы с некоторыми общими свойствами пересматриваются в более общий класс с общими атрибутами.
Семантическая модель данных может использоваться для многих целей, таких как: [8]
- Планирование ресурсов данных
- Создание общих баз данных
- Оценка программного обеспечения поставщика
- Интеграция существующих баз данных
Общая цель семантических моделей данных — передать больше смысла данных путем интеграции реляционных концепций с более мощными концепциями абстракции , известными из области искусственного интеллекта . Идея состоит в том, чтобы предоставить примитивы моделирования высокого уровня как неотъемлемую часть модели данных, чтобы облегчить представление ситуаций реального мира. [10]
См. также [ править ]
- Архитектурный образец
- Сравнение инструментов моделирования данных
- Данные (информатика)
- Словарь данных
- Моделирование документов
- Моделирование корпоративных данных
- Модель данных сущности
- Управление информацией
- Информационная модель
- Информационное моделирование зданий
- Моделирование метаданных
- Трехсхемный подход
- Захман Фреймворк
Ссылки [ править ]
- ^ Перейти обратно: а б с д Это ж Мэтью Уэст и Джулиан Фаулер (1999). Разработка моделей данных высокого качества. Архивировано 9 сентября 2020 г. на Wayback Machine . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).
- ^ Перейти обратно: а б Симисон, Грэм. К. и Витт, Грэм. К. (2005). Основы моделирования данных . 3-е издание. Издательство Морган Кауфманн . ISBN 0-12-644551-6
- ↑ Глоссарий по интеграции данных. Архивировано 20 марта 2009 г. в Wayback Machine , Министерство транспорта США, август 2001 г.
- ^ Перейти обратно: а б с Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2005). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X .
- ^ Американский национальный институт стандартов. 1975. Исследовательская группа ANSI/X3/SPARC по системам управления базами данных; Промежуточный доклад . ФДТ (Бюллетень ACM SIGMOD) 7:2.
- ^ Перейти обратно: а б Пол Р. Смит и Ричард Сарфати (1993). Создание стратегического плана управления конфигурацией с использованием инструментов компьютерной разработки программного обеспечения (CASE). Документ для группы пользователей CAD/CAE Национального Министерства энергетики/подрядчиков и предприятий 1993 года.
- ^ Перейти обратно: а б с д Лен Сильверстон, WHInmon, Кент Грациано (2007). Справочник по модели данных . Уайли, 1997. ISBN 0-471-15364-8 . Обзор Ван Скотта на tdan.com . По состоянию на 1 ноября 2008 г.
- ^ Перейти обратно: а б с д Публикация FIPS 184. Архивировано 3 декабря 2013 г. на сайте Wayback Machine , выпущенном IDEF1X Лабораторией компьютерных систем Национального института стандартов и технологий (NIST). 21 декабря 1993 года.
- ^ Амнон Шабо (2006). Стандарты данных клинической геномики для фармакогенетики и фармакогеномики. Архивировано 22 июля 2009 г. в Wayback Machine .
- ^ «Семантическое моделирование данных» В: Метаклассы и их применение . Серия книг «Конспекты лекций по информатике». Издательство Springer Берлин/Гейдельберг. Том Том 943/1995.
Эта статья включает общедоступные материалы Национального института стандартов и технологий.
Дальнейшее чтение [ править ]
- Дж. Х. тер Бекке (1991). Семантическое моделирование данных в реляционных средах
- Джон Винсент Карлис, Джозеф Д. Магуайр (2001). Освоение моделирования данных: подход, управляемый пользователем .
- Алан Чмура, Дж. Марк Хьюманн (2005). Логическое моделирование данных: что это такое и как это сделать .
- Мартин Э. Моделл (1992). Анализ данных, моделирование данных и классификация .
- М. Папазоглу, Стефано Спаккапьетра, Захир Тари (2000). Достижения в объектно-ориентированном моделировании данных .
- Дж. Лоуренс Сандерс (1995). Моделирование данных
- Грэм К. Симсион, Грэм К. Витт (2005). Основы моделирования данных»
- Мэтью Уэст (2011) Разработка моделей данных высокого качества
Внешние ссылки [ править ]
- Гибкое/эволюционное моделирование данных
- Статьи о моделировании данных. Архивировано 7 марта 2010 г. в Wayback Machine.
- Моделирование базы данных в UML
- Моделирование данных 101
- Семантическое моделирование данных
- Разработка систем, методологии и моделирование. Архивировано 7 марта 2012 г. в Wayback Machine. Заметки Тони Дрюри.
- Запрос предложений - Метамодель управления информацией (IMM) группы управления объектами
- Моделирование данных предназначено НЕ только для СУБД, часть 1 Крис Брэдли
- Моделирование данных предназначено НЕ только для СУБД, часть 2 Крис Брэдли
