Jump to content

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

Процесс моделирования данных. На рисунке показано, как сегодня разрабатываются и используются модели данных. Концептуальная модель данных разрабатывается на основе требований к данным для разрабатываемого приложения, возможно, в контексте модели деятельности . Модель данных обычно состоит из типов сущностей, атрибутов, отношений, правил целостности и определений этих объектов. Затем это используется в качестве отправной точки для проектирования интерфейса или базы данных. [1]

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

Обзор [ править ]

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

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

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

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

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

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

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

Темы [ править ]

Модели данных [ править ]

Как модели данных приносят пользу. [1]

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

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

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

Концептуальные, логические и физические схемы [ править ]

Трехуровневая архитектура ANSI/SPARC. Это показывает, что модель данных может быть внешней моделью (или представлением), концептуальной моделью или физической моделью. Это не единственный способ рассмотрения моделей данных, но это полезный способ, особенно при сравнении моделей. [1]

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

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

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

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

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

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

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

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

Методики моделирования [ править ]

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

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

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

Диаграммы сущность-связь [ править ]

Пример диаграммы сущность-связь IDEF1X , используемой для моделирования самого IDEF1X. Имя представления — мм. Также приведены иерархия доменов и ограничения. Ограничения выражаются в виде предложений в формальной теории метамодели. [8]

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

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

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

данных моделирование Общее

Пример общей модели данных. [9]

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

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

данных Семантическое моделирование

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

Семантические модели данных. [8]

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

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

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

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

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

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

См. также [ править ]

Ссылки [ править ]

  1. ^ Jump up to: Перейти обратно: а б с д и ж Мэтью Уэст и Джулиан Фаулер (1999). Разработка моделей данных высокого качества. Архивировано 9 сентября 2020 г. на Wayback Machine . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).
  2. ^ Jump up to: Перейти обратно: а б Симисон, Грэм. К. и Витт, Грэм. К. (2005). Основы моделирования данных . 3-е издание. Издательство Морган Кауфманн . ISBN   0-12-644551-6
  3. Глоссарий по интеграции данных . Архивировано 20 марта 2009 г. в Wayback Machine , Министерство транспорта США, август 2001 г.
  4. ^ Jump up to: Перейти обратно: а б с Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2005). Системный анализ и методы проектирования . 6-е издание. ISBN   0-256-19906-X .
  5. ^ Американский национальный институт стандартов. 1975. Исследовательская группа ANSI/X3/SPARC по системам управления базами данных; Промежуточный отчет . ФДТ (Бюллетень ACM SIGMOD) 7:2.
  6. ^ Jump up to: Перейти обратно: а б Пол Р. Смит и Ричард Сарфати (1993). Создание стратегического плана управления конфигурацией с использованием инструментов компьютерной разработки программного обеспечения (CASE). Документ для группы пользователей CAD/CAE Национального Министерства энергетики/подрядчиков и предприятий 1993 года.
  7. ^ Jump up to: Перейти обратно: а б с д Лен Сильверстон, WHInmon, Кент Грациано (2007). Справочник по модели данных . Уайли, 1997. ISBN   0-471-15364-8 . Обзор Ван Скотта на tdan.com . По состоянию на 1 ноября 2008 г.
  8. ^ Jump up to: Перейти обратно: а б с д Публикация FIPS 184. Архивировано 3 декабря 2013 г. на сайте Wayback Machine , выпущенном IDEF1X Лабораторией компьютерных систем Национального института стандартов и технологий (NIST). 21 декабря 1993 года.
  9. ^ Амнон Шабо (2006). Стандарты данных клинической геномики для фармакогенетики и фармакогеномики. Архивировано 22 июля 2009 г. в Wayback Machine .
  10. ^ «Семантическое моделирование данных» В: Метаклассы и их применение . Серия книг «Конспекты лекций по информатике». Издательство Springer Берлин/Гейдельберг. Том Том 943/1995.

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 4f8f6fd38aa98985bcdf183c71781c58__1714297560
URL1:https://arc.ask3.ru/arc/aa/4f/58/4f8f6fd38aa98985bcdf183c71781c58.html
Заголовок, (Title) документа по адресу, URL1:
Data modeling - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)