Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Модель данных (или модель данных ) [1] [2] [3] [4] [5] - это абстрактная модель, которая организует элементы данных и стандартизирует их связь друг с другом и со свойствами объектов реального мира. Например, модель данных может указывать, что элемент данных, представляющий автомобиль, состоит из ряда других элементов, которые, в свою очередь, представляют цвет и размер автомобиля и определяют его владельца.

Термин модель данных может относиться к двум различным, но тесно связанным концепциям. Иногда это относится к абстрактной формализации объектов и отношений, обнаруженных в определенной области приложения: например, клиентов, продуктов и заказов, найденных в производственной организации. В других случаях это относится к набору концепций, используемых при определении таких формализаций: например, такие концепции, как сущности, атрибуты, отношения или таблицы. Таким образом, "модель данных" банковского приложения может быть определена с использованием "модели данных" сущность-связь. В этой статье термин используется в обоих смыслах.

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

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

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

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

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

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

Преимущества моделей данных [8]

Основная цель моделей данных - поддерживать развитие информационных систем путем предоставления определения и формата данных. Согласно Уэсту и Фаулеру (1999), «если это делается последовательно в разных системах, можно добиться совместимости данных. Если одни и те же структуры данных используются для хранения данных и доступа к ним, тогда разные приложения могут обмениваться данными. . Однако создание, эксплуатация и обслуживание систем и интерфейсов часто обходятся дороже, чем они должны. Они также могут ограничивать бизнес, а не поддерживать его. Основная причина заключается в низком качестве моделей данных, реализованных в системах и интерфейсах. ". [8]

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

Причина этих проблем - отсутствие стандартов, которые гарантируют, что модели данных будут соответствовать потребностям бизнеса и быть последовательными. [8]

Модель данных явно определяет структуру данных. Типичные применения моделей данных включают модели баз данных, проектирование информационных систем и обеспечение обмена данными. Обычно модели данных задаются на языке моделирования данных. [3]

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

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

Экземпляр модели данных может быть одного из трех типов согласно ANSI 1975 года: [9]

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

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

История [ править ]

Одна из первых новаторских работ по моделированию информационных систем была сделана Янгом и Кентом (1958), [10] [11], которые выступали за «точный и абстрактный способ определения информационных и временных характеристик проблемы обработки данных ». Они хотели создать «нотацию, которая позволила бы аналитику организовать проблему вокруг любого устройства ». Их работа была первой попыткой создать абстрактную спецификацию и инвариантную основу для разработки различных альтернативных реализаций с использованием различных аппаратных компонентов. Следующий шаг в моделировании ИС сделал CODASYL., консорциум ИТ-индустрии, образованный в 1959 году, который, по сути, преследовал ту же цель, что и Янг и Кент: разработка «надлежащей структуры для машинно-независимого языка определения проблем на системном уровне обработки данных». Это привело к развитию специальной информационной алгебры ИБ . [11]

В 1960-х годах моделирование данных приобрело большее значение с появлением концепции информационной системы управления (MIS). По словам Леондеса (2002), «в это время информационная система предоставляла данные и информацию для целей управления. Система баз данных первого поколения , получившая название Integrated Data Store (IDS), была разработана Чарльзом Бахманом из General Electric. Две известные базы данных модели, сетевая модель данных и иерархическая модель данных , были предложены в этот период времени ". [12] К концу 1960-х Эдгар Ф. Кодд разработал свои теории организации данных и предложилреляционная модель для управления базами данных на основе логики предикатов первого порядка . [13]

В 1970-х годах моделирование отношений сущностей возникло как новый тип концептуального моделирования данных, первоначально предложенный в 1976 году Питером Ченом . Модели сущностей-отношений использовались на первом этапе проектирования информационной системы во время анализа требований для описания информационных потребностей или типа информации, которая должна храниться в базе данных . Этот метод может описывать любую онтологию , т. Е. Обзор и классификацию концепций и их отношений для определенной области интересов .

В 1970-х GM Nijssen разработал метод «Метод анализа информации на естественном языке» (NIAM), который в 1980-х годах в сотрудничестве с Терри Халпином развил в объектно-ролевом моделировании (ORM). Однако именно докторская диссертация Терри Халпина в 1989 году создала формальную основу, на которой основано объектно-ролевое моделирование.

Билл Кент в своей книге 1978 года « Данные и реальность» [14] сравнил модель данных с картой территории, подчеркнув, что в реальном мире «шоссе не окрашены в красный цвет, у рек нет линий графств, проходящих посередине. , и вы не можете увидеть контурные линии на горе ». В отличие от других исследователей, пытавшихся создать математически чистые и элегантные модели, Кент подчеркивал существенную беспорядок в реальном мире и задачу разработчика моделей данных - создать порядок из хаоса, не искажая истину.

В 1980-х годах, согласно Яну Л. Харрингтону (2000), «развитие объектно-ориентированной парадигмы привело к фундаментальным изменениям в нашем подходе к данным и процедурам, которые работают с ними. Традиционно данные и процедуры были хранятся отдельно: данные и их взаимосвязь в базе данных, процедуры в прикладной программе. Однако объектная ориентация объединила процедуру сущности с ее данными ». [15]

В начале 1990-х годов три голландских математика Гвидо Бакема, Харм ван дер Лек и Ян Питер Цварт продолжили развитие работ Г. М. Нейссена . Они больше сосредоточились на коммуникационной части семантики. В 1997 году они формализовали метод полностью коммуникационно-ориентированного информационного моделирования FCO-IM .

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

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

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

Было предложено несколько таких моделей. Общие модели включают:

Плоская модель
Это не может строго квалифицироваться как модель данных. Плоская (или табличная) модель состоит из одного двумерного массива элементов данных, где предполагается, что все элементы данного столбца имеют одинаковые значения, а все элементы строки связаны друг с другом.
Иерархическая модель
Иерархическая модель аналогична сетевой модели, за исключением того, что связи в иерархической модели образуют древовидную структуру, а сетевая модель допускает произвольный граф.
Сетевая модель
Эта модель организует данные с помощью двух фундаментальных конструкций, называемых записями и наборами. Записи содержат поля, а наборы определяют отношения «один ко многим» между записями: один владелец, много членов. Сетевая модель данных - это абстракция концепции проекта, используемой при реализации баз данных.
Реляционная модель
- это модель базы данных, основанная на логике предикатов первого порядка. Его основная идея состоит в том, чтобы описать базу данных как набор предикатов над конечным набором переменных предиката, описывая ограничения на возможные значения и комбинации значений. Сила реляционной модели данных заключается в ее математической основе и простой парадигме пользовательского уровня.
Объектно-реляционная модель
Подобно модели реляционной базы данных, но объекты, классы и наследование напрямую поддерживаются в схемах баз данных и на языке запросов.
Объектно-ролевое моделирование
Метод моделирования данных, который был определен как «свободный от атрибутов» и «основанный на фактах». Результатом является проверяемая правильная система, из которой могут быть получены другие общие артефакты, такие как ERD, UML и семантические модели. Связи между объектами данных описываются во время процедуры проектирования базы данных, так что нормализация является неизбежным результатом процесса.
Схема звездочки
Самый простой стиль схемы хранилища данных. Схема типа "звезда" состоит из нескольких "таблиц фактов" (возможно, только одной, оправдывающей название), ссылающихся на любое количество "таблиц измерений". Схема «звезда» считается важным частным случаем схемы «снежинка» .
  • Плоская модель

  • Иерархическая модель

  • Сетевая модель

  • Реляционная модель

  • Концептуально-ориентированная модель

  • Схема звездочки

Схема структуры данных [ править ]

Пример диаграммы структуры данных

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

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

Есть несколько стилей для представления структуры данных диаграммы, с заметным различием в способе определения моща . Возможен выбор между наконечниками стрелок, перевернутыми наконечниками стрелок ( гусиные лапки ) или числовым представлением мощности.

Пример диаграмм отношений IDEF1X Entity, используемых для моделирования самого IDEF1X [16]

Модель сущности-отношения [ править ]

Модель отношения сущность (ERM), иногда называемая диаграммой сущности-взаимосвязи (ERD), может использоваться для представления абстрактной концептуальной модели данных (или семантической модели данных, или физической модели данных), используемой в разработке программного обеспечения для представления структурированных данных. . Для ERM используется несколько обозначений. Как и в DSD, атрибуты указываются внутри блоков сущностей, а не вне их, в то время как отношения изображаются в виде линий, а ограничения взаимосвязей - в виде описаний в строке. Модель ER, хотя и является надежной, может стать визуально громоздкой при представлении сущностей с несколькими атрибутами.

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

Модель географических данных [ править ]

Модель данных в географических информационных системах - это математическая конструкция для представления географических объектов или поверхностей в виде данных. Например,

  • вектор модель данных представляет географию как наборы точек, линий и полигонов;
  • модель растровых данных представляет географию в виде матриц ячеек, хранящих числовые значения;
  • а модель данных триангулированной нерегулярной сети (TIN) представляет географию в виде наборов смежных неперекрывающихся треугольников. [17]
  • Группы связаны с процессом создания карты [18]

  • Приложения модели данных NGMDB [18]

  • Базы данных NGMDB связаны между собой [18]

  • Представление информации о 3D-карте [18]

Общая модель данных [ править ]

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

Семантическая модель данных [ править ]

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

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

Логическая структура данных системы управления базами данных (СУБД), будь то иерархическая , сетевая или реляционная , не может полностью удовлетворить требования к концептуальному определению данных, поскольку она ограничена по объему и смещена в сторону стратегии реализации, используемой СУБД. Следовательно, необходимость определения данных с концептуального представленияпривело к развитию методов семантического моделирования данных. То есть методы определения значения данных в контексте их взаимосвязей с другими данными. Как показано на рисунке. Реальный мир с точки зрения ресурсов, идей, событий и т. Д. Символически определяется в физических хранилищах данных. Семантическая модель данных - это абстракция, которая определяет, как хранимые символы относятся к реальному миру. Таким образом, модель должна достоверно отражать реальный мир. [16]

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

Архитектура данных [ править ]

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

Архитектура данных описывает структуры данных, используемые бизнесом и / или его приложениями. Есть описания данных в хранилище и данных в движении; описания хранилищ данных, групп данных и элементов данных; и сопоставления этих артефактов данных с качеством данных, приложениями, местоположениями и т. д.

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

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

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

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

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

Свойства данных [ править ]

Некоторые важные свойства данных, для которых необходимо выполнить требования:

  • свойства, связанные с определением [8]
    • актуальность : полезность данных в контексте вашего бизнеса.
    • ясность : наличие четкого и общего определения данных.
    • согласованность : совместимость однотипных данных из разных источников.
Некоторые важные свойства данных [8]
  • свойства, связанные с контентом
    • своевременность : доступность данных в нужное время и насколько они актуальны.
    • точность : насколько близки к истине данные.
  • свойства, относящиеся как к определению, так и к содержанию
    • полнота : сколько требуемых данных доступно.
    • доступность : где, как и кому данные доступны или недоступны (например, безопасность).
    • Стоимость : затраты, понесенные при получении данных и предоставлении их для использования.

Организация данных [ править ]

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

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

Другой подход - использовать адаптивные системы, такие как искусственные нейронные сети, которые могут автономно создавать неявные модели данных.

Структура данных [ править ]

Бинарное дерево , простой тип ветвления связанной структуры данных

Структура данных - это способ хранения данных на компьютере для эффективного использования. Это организация математических и логических концепций данных. Часто тщательно подобранная структура данных позволяет использовать наиболее эффективный алгоритм . Выбор структуры данных часто начинается с выбора абстрактного типа данных .

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

Сущности, представленные моделью данных, могут быть материальными сущностями, но модели, которые включают такие конкретные классы сущностей, имеют тенденцию изменяться со временем. Надежные модели данных часто идентифицируют абстракции таких сущностей. Например, модель данных может включать в себя класс сущности под названием «Человек», представляющий всех людей, которые взаимодействуют с организацией. Такой абстрактный класс сущностей обычно более уместен, чем классы под названием «Поставщик» или «Сотрудник», которые определяют конкретные роли, которые играют эти люди.

  • Множество

  • Хеш-таблица

  • Связанный список

  • Стек (структура данных)

Теория моделей данных [ править ]

Термин модель данных может иметь два значения: [20]

  1. Теория модели данных , то есть формальное описание того, как данные могут быть структурированы и доступны.
  2. Экземпляр модели данных , т.е. применение теории модели данных для создания практического экземпляра модели данных для некоторого конкретного приложения.

Теория модели данных состоит из трех основных компонентов: [20]

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

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

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

Выкройки [ править ]

Шаблоны [21] - это общие структуры моделирования данных, которые встречаются во многих моделях данных.

Связанные модели [ править ]

Диаграмма потока данных [ править ]

Пример диаграммы потока данных [22]

Диаграмма потока данных (DFD) - это графическое представление «потока» данных через информационную систему . Она отличается от блок - схемы , как это показывает данные потока вместо управления потоком программы. Диаграмма потока данных также может быть использована для визуализации в процессе обработки данных (структурированный дизайн). Диаграммы потоков данных были изобретены Ларри Константином , первым разработчиком структурированного дизайна [23], на основе модели вычислений Мартина и Эстрина «граф потока данных».

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

Информационная модель [ править ]

Пример информационной модели EXPRESS G

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

Согласно Ли (1999) [24] , информационная модель - это представление концепций, отношений, ограничений, правил и операций для определения семантики данных для выбранной области дискурса. Он может обеспечить общую, стабильную и организованную структуру требований к информации для контекста предметной области. [24] В более общем случае термин модель информация используется для моделей отдельных вещей, таких как объекты, здания, технологических установок и т.д. В этих случаях понятие специализируется на Facility Information Model , Building Information Model, Информационная модель предприятия и др. Такая информационная модель представляет собой интеграцию модели объекта с данными и документами об объекте.

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

Объектная модель документа , стандартная объектная модель для представления HTML или XML

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

Объектная модель в информатике - это набор объектов или классов, с помощью которых программа может исследовать и управлять некоторыми конкретными частями своего мира. Другими словами, объектно-ориентированный интерфейс к некоторой службе или системе. Такой интерфейс называется объектной моделью представляемой службы или системы. Например, объектная модель документа (DOM) [1] - это набор объектов, представляющих страницу в веб-браузере , используемых программами- скриптами для проверки и динамического изменения страницы. Существует объектная модель Microsoft Excel [25] для управления Microsoft Excel из другой программы, а также ASCOM.Telescope Driver [26] - это объектная модель для управления астрономическим телескопом.

В вычислениях термин объектная модель имеет особое второе значение общих свойств объектов на конкретном языке компьютерного программирования , технологии, нотации или методологии, которая их использует. Так , например, Java , объектная модель , то COM - модель объекта или объектная модель ОМТА . Такие объектные модели обычно определяются с использованием таких понятий, как класс , сообщение , наследование , полиморфизм и инкапсуляция.. Существует обширная литература по формализованным объектным моделям как подмножеству формальной семантики языков программирования .

Объектно-ролевая модель [ править ]

Пример применения объектно-ролевого моделирования в «схеме для геологической поверхности», Стивен М. Ричард (1999) [27]

Объектно-ролевое моделирование (ORM) - это метод концептуального моделирования , который может использоваться как инструмент для анализа информации и правил. [28]

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

Концептуальный проект может включать в себя данные, процессы и поведенческие аспекты, а фактическая СУБД, используемая для реализации проекта, может быть основана на одной из многих логических моделей данных (реляционной, иерархической, сетевой, объектно-ориентированной и т. Д.). [29]

Модели на унифицированном языке моделирования [ править ]

Унифицированный язык моделирования (UML) - это стандартизированный язык моделирования общего назначения в области разработки программного обеспечения . Это графический язык для визуализации, определения, построения и документирования артефактов программно-интенсивной системы. Унифицированный язык моделирования предлагает стандартный способ написания чертежей системы, включая: [30]

  • Концептуальные вещи, такие как бизнес-процессы и системные функции
  • Конкретные вещи, такие как операторы языка программирования , схемы баз данных и
  • Многоразовые программные компоненты .

UML предлагает сочетание функциональных моделей , моделей данных и моделей баз данных .

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

  • Модель бизнес-процесса
  • Модель данных базовой архитектуры
  • Словарь с данными
  • JC3IEDM
  • Модель процесса
  • Язык описания формата данных (DFDL)
  • Система сбора данных

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

  1. ^ «Модель данных - Моделирование домена UML - Переполнение стека» . Переполнение стека . Стек Обмен Inc . Проверено 4 февраля 2017 года .
  2. ^ «Модель данных XQuery и XPath 3.1» . Консорциум World Wide Web (W3C) . W3C . Проверено 4 февраля 2017 года .
  3. ^ "модель данных" . npm . НПМ, Inc . Проверено 4 февраля 2017 года .
  4. ^ "Модель данных (Java EE 6)" . Документация по Java . Oracle . Проверено 4 февраля 2017 года .
  5. Островский, Стан. «iOS: три способа передачи данных из модели в контроллер» . Средний . Средняя корпорация . Проверено 4 февраля 2017 года .
  6. ^ Пол Р. Смит и Ричард Sarfaty Публикации, LLC 2009
  7. ^ Майкл Р. Маккалеб (1999). «Концептуальная модель данных базовых систем». Архивировано 21 сентября 2008 года на Wayback Machine . Национальный институт стандартов и технологий. Август 1999 г.
  8. ^ a b c d e f g h i j k Мэтью Уэст и Джулиан Фаулер (1999). Разработка высококачественных моделей данных . Технический представитель по связям с общественностью STEP в Европе, занимающийся перерабатывающей промышленностью (EPISTLE).
  9. ^ Американский национальный институт стандартов. 1975. Исследовательская группа ANSI / X3 / SPARC по системам управления базами данных; Промежуточный отчет . FDT (Бюллетень ACM SIGMOD) 7: 2.
  10. ^ Янг, JW, и Кент, HK (1958). «Абстрактная постановка задач обработки данных». В: Журнал промышленной инженерии . Ноябрь-декабрь 1958. 9 (6), стр. 471-479.
  11. ^ a b Янис А. Бубенко-младший (2007) «От информационной алгебры к моделированию предприятий и онтологиям - историческая перспектива моделирования информационных систем». В кн . : Концептуальное моделирование в инженерии информационных систем . Джон Крогсти и др. ред. стр. 1-18
  12. ^ Корнелиус Т. Леондес (2002). Базы данных и сетевые системы передачи данных: методы и приложения . Стр.7
  13. ^ «Производность, избыточность и согласованность отношений, хранящихся в больших банках данных» , EF Codd, IBM Research Report, 1969
  14. ^ Данные и реальность
  15. ^ Ян Л. Харрингтон (2000). Ясно объясненный объектно-ориентированный дизайн базы данных . стр.4
  16. ^ a b c d Публикация 184 FIPS, заархивированная 3 декабря 2013 г. на Wayback Machine, выпущенная для IDEF1X лабораторией компьютерных систем Национального института стандартов и технологий (NIST). 21 декабря 1993 г. (снято в 2008 г.).
  17. ^ Уэйд, Т. и Соммер, С. редакторы. ГИС от А до Я
  18. ^ а б в г Дэвид Р. Соллер1 и Томас М. Берг (2003). Проект базы данных национальных геологических карт: Обзор и прогресс Геологической службы США Отчет открытого файла 03–471.
  19. ^ Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2004). Системный анализ и методы проектирования . 6-е издание. ISBN 0-256-19906-X . 
  20. ^ a b Бейнон-Дэвис П. (2004). Системы баз данных 3-е издание. Пэлгрейв, Бейзингсток, Великобритания. ISBN 1-4039-1601-2 
  21. ^ "Справочник по модели данных: Универсальные шаблоны для моделирования данных" Лен Сильверстоун и Пол Агнью (2008).
  22. ^ Джон Аззолини (2000). Введение в практики системного проектирования . Июль 2000 г.
  23. ^ В. Стивенс, Г. Майерс, Л. Константин, «Структурированный дизайн», IBM Systems Journal, 13 (2), 115-139, 1974.
  24. ^ а б Ю. Тина Ли (1999). «Информационное моделирование от проектирования до реализации» Национальный институт стандартов и технологий.
  25. ^ Обзор объектной модели Excel
  26. ^ «Общие требования ASCOM» . 2011-05-13 . Проверено 25 сентября 2014 .
  27. ^ Стивен М. Ричард (1999). Моделирование геологической концепции . Отчет Геологической службы США в открытом доступе 99-386.
  28. Иоахим Россберг и Рикард Редлер (2005). Проекты масштабируемых приложений .NET 2.0. . Стр. 27
  29. ^ Моделирование роли объекта: обзор (msdn.microsoft.com) . Проверено 19 сентября 2008 года.
  30. ^ Грэди Буч, Ивар Якобсон и Джим Рамбо (2005) OMG Unified Modeling Language Specification .

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

  • Дэвид С. Хэй (1996). Шаблоны моделей данных: общепринятые представления . Нью-Йорк: Dorset House Publishers, Inc.
  • Лен Сильверстон (2001). Справочник по модели данных Том 1/2. Джон Вили и сыновья.
  • Лен Сильверстон и Пол Агнью (2008). Справочник по моделям данных: Универсальные шаблоны для моделирования данных Том 3. John Wiley & Sons.
  • Мэтью Уэст и Джулиан Фаулер (1999). Разработка высококачественных моделей данных . Технический представитель по связям с общественностью STEP в Европе, занимающийся перерабатывающей промышленностью (EPISTLE).
  • Мэтью Уэст (2011) Разработка моделей данных высокого качества Морган Кауфманн