~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ D525D21FC17C1EB3D76BB8D894A6C7F6__1717014420 ✰
Заголовок документа оригинал.:
✰ Data model - Wikipedia ✰
Заголовок документа перевод.:
✰ Модель данных — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/Structured_data ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/d5/f6/d525d21fc17c1eb3d76bb8d894a6c7f6.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/d5/f6/d525d21fc17c1eb3d76bb8d894a6c7f6__translat.html ✰
Дата и время сохранения документа:
✰ 21.06.2024 09:58:54 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 29 May 2024, at 23:27 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.)https://arc.ask3.ruОтветы на вопросы (Сервис ответов на вопросы, в основном, научной направленности)https://ask3.ru/answer2questionТоварный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collationПартнерыhttps://comrades.ask3.ru


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

Модель данных — Википедия Jump to content

Модель данных

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

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

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

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

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

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

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

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

Роль данных моделей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример диаграммы сущность-связь IDEF1X , используемой для моделирования самого IDEF1X. [13]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некоторые важные свойства данных [5]

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

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

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

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

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

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

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

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

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

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

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

модели Теория данных

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

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

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

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

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

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

Узоры [ править ]

Узоры [18] — это общие структуры моделирования данных, которые встречаются во многих моделях данных.

Сопутствующие модели [ править ]

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

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

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

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

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

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

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

По словам Ли (1999) [21] информационная модель — это представление концепций, отношений, ограничений, правил и операций для определения семантики данных для выбранной области дискурса. Он может обеспечить разделяемую, стабильную и организованную структуру информационных требований для контекста предметной области. [21] В более общем смысле термин « информационная модель» используется для моделей отдельных объектов, таких как объекты, здания, технологические предприятия и т. д. В этих случаях понятие специализируется на информационной модели объекта , информационной модели здания , информационной модели предприятия и т. д. Информационная модель – это интеграция модели объекта с данными и документами об объекте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. ^ Пол Р. Смит и Ричард Сарфати Publications, LLC, 2009 г.
  2. ^ «Что такое модель данных?» . Princeton.edu . Проверено 29 мая 2024 г.
  3. ^ «Моделирование домена UML — переполнение стека» . Переполнение стека . Stack Exchange Inc. Проверено 4 февраля 2017 г.
  4. ^ Майкл Р. Маккалеб (1999). «Концептуальная модель данных систем данных». Архивировано 21 сентября 2008 г. в Wayback Machine . Национальный институт стандартов и технологий. Август 1999 года.
  5. ^ Перейти обратно: а б с д Это ж г час я дж к Мэтью Уэст и Джулиан Фаулер (1999). Разработка моделей данных высокого качества . Руководитель технического взаимодействия STEP в европейских перерабатывающих отраслях (EPISTLE).
  6. ^ Американский национальный институт стандартов. 1975. Исследовательская группа ANSI/X3/SPARC по системам управления базами данных; Промежуточный доклад . ФДТ (Бюллетень ACM SIGMOD) 7:2.
  7. ^ Янг, Дж.В., и Кент, Гонконг (1958). «Абстрактная постановка задач обработки данных». В: Журнал промышленной инженерии . Ноябрь-декабрь 1958 г., 9 (6), стр. 471–479.
  8. ^ Перейти обратно: а б Янис А. Бубенко-младший (2007) «От информационной алгебры к моделированию предприятия и онтологиям - исторический взгляд на моделирование информационных систем». В: Концептуальное моделирование в разработке информационных систем . Джон Крогсти и др. ред. стр. 1–18
  9. ^ Корнелиус Т. Леондес (2002). Базы данных и сетевые системы передачи данных: методы и приложения . Страница 7
  10. ^ «Выводимость, избыточность и согласованность отношений, хранящихся в больших банках данных» , Э.Ф. Кодд, Отчет об исследованиях IBM, 1969 г.
  11. ^ Данные и реальность
  12. ^ Ян Л. Харрингтон (2000). Четкое объяснение объектно-ориентированного проектирования баз данных . стр.4
  13. ^ Перейти обратно: а б с д Публикация FIPS 184. Архивировано 3 декабря 2013 г. на сайте Wayback Machine , выпущенном IDEF1X Лабораторией компьютерных систем Национального института стандартов и технологий (NIST). 21 декабря 1993 г. (снято в 2008 г.).
  14. ^ Уэйд, Т. и Соммер, С. ред. ГИС от А до Я
  15. ^ Перейти обратно: а б с д Дэвид Р. Соллер1 и Томас М. Берг (2003). Проект национальной базы данных геологических карт: обзор и прогресс. Открытый отчет Геологической службы США 03–471.
  16. ^ Уиттен, Джеффри Л .; Лонни Д. Бентли , Кевин С. Диттман . (2004). Системный анализ и методы проектирования . 6-е издание. ISBN   0-256-19906-X .
  17. ^ Перейти обратно: а б Бейнон-Дэвис П. (2004). Системы баз данных, 3-е издание. Пэлгрейв, Бейзингсток, Великобритания. ISBN   1-4039-1601-2
  18. ^ «Справочник по модели данных: универсальные шаблоны для моделирования данных» Лен Сильверстоун и Пол Агнью (2008).
  19. ^ Джон Аззолини (2000). Введение в практику системной инженерии . Июль 2000 года.
  20. ^ В. Стивенс, Г. Майерс, Л. Константин, «Структурированный дизайн», IBM Systems Journal, 13 (2), 115–139, 1974.
  21. ^ Перейти обратно: а б Ю. Тина Ли (1999). «Информационное моделирование от проектирования до реализации» Национальный институт стандартов и технологий.
  22. ^ Обзор объектной модели Excel
  23. ^ «Общие требования ASCOM» . 13 мая 2011 г. Проверено 25 сентября 2014 г.
  24. ^ Стивен М. Ричард (1999). Геологическое концептуальное моделирование . Открытый отчет Геологической службы США 99–386.
  25. ^ Иоахим Россберг и Рикард Редлер (2005). Профессиональные масштабируемые проекты приложений .NET 2.0. . Страница 27.
  26. ^ Объектное ролевое моделирование: обзор (msdn.microsoft.com) . Проверено 19 сентября 2008 г.
  27. ^ Грэди Буч, Ивар Джейкобсон и Джим Рамбо (2005) Спецификация единого языка моделирования OMG .

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

  • Дэвид К. Хэй (1996). Шаблоны моделей данных: условности мышления . Нью-Йорк: Dorset House Publishers, Inc.
  • Лен Сильверстон (2001). Справочник по модели данных, том 1/2. Джон Уайли и сыновья.
  • Лен Сильверстон и Пол Агнью (2008). Справочник по моделям данных: универсальные шаблоны для моделирования данных, том 3. John Wiley & Sons.
  • Мэтью Уэст (2011) Разработка моделей данных высокого качества Морган Кауфманн
Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: D525D21FC17C1EB3D76BB8D894A6C7F6__1717014420
URL1:https://en.wikipedia.org/wiki/Structured_data
Заголовок, (Title) документа по адресу, URL1:
Data model - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)