Чем определяется модель данных

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

В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

1) аспект структуры: методы описания типов и логических структур данных в базе данных;

2) аспект манипуляции: методы манипулирования данными;

3) аспект целостности: методы описания и поддержки целостности базы данных.

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

Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д.

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

См. также

Примечания

Литература

Кент Бек • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Мейер Бертран • Дэвид Парнас • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл

Моделирование данных • Архитектура ПО • Функциональная спецификация • Язык моделирования • Парадигма • Методология • Процесс разработки • Качество • Обеспечение качества • Структурный анализ)

CMM • CMMI • Данных • Function model • IDEF • Информационная • Metamodeling • Object model • View model • UML

Источник

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

В работе мы с коллегами часто видим как компании сталкиваются с проблемой управления данными – когда таблиц и запросов становится сильно много и управлять всем этим очень сложно. В таких ситуациях мы рекомендуем моделировать данные. Чтобы разобраться, что это такое – я перевела статью-обзор про моделирование данных от Towards Data Science, в которой кроме основных терминов и понятий можно найти наглядный пример использования моделирования данных в ритейле. Вперед под кат!

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

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

Моделирование данных можно сравнить со строительством дома. Допустим, компании ABC необходимо построить дом для гостей (база данных). Компания вызывает архитектора (разработчик моделей данных) и объясняет требования к зданию (бизнес-требования). Архитектор (модельер данных) разрабатывает план (модель данных) и передает его компании ABC. Наконец, компания ABC вызывает инженеров-строителей (администраторов баз данных и разработчиков баз данных) для строительства дома.

Ключевые термины в моделировании данных

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

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

Сущность пересечения. Если между сущностями есть связь типа «многие ко многим», то можно использовать сущность пересечения, чтобы декомпозировать эту связь и привести ее к типу «многие к одному» и «один ко многим».

Простой пример: есть 2 сущности — телешоу и человек. Каждое телешоу может смотреть один или несколько человек, в то время как человек может смотреть одно или несколько телешоу.

Эту проблему можно решить, введя новую пересекающуюся сущность «Просмотр записи»:

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

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

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

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

Основные этапы моделирования данных:

Реляционное vs размерное моделирование

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

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

Компания ABC имеет 200 продуктовых магазинов в восьми городах. В каждом магазине есть разные отделы, такие как «Товары повседневного спроса», «Косметика», «Замороженные продукты», «Молочные продукты» и т.д. В каждом магазине на полках находится около 20 000 отдельных товаров. Отдельные продукты называются складскими единицами (SKU). Около 6 000 артикулов поступают от сторонних производителей и имеют штрих-коды, нанесенные на упаковку продукта. Эти штрих-коды называются универсальными кодами продукта (UPC). Данные собираются POS-системой в 2 местах: у входной двери для покупателей, и у задней двери, где поставщики осуществляют доставку.

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

Разработайте модель данных для анализа операций этой продуктовой сети.

Решение

Шаг 1. Сбор бизнес-требований

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

Шаг 2: Идентификация сущностей

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

Количество, которое необходимо рассчитать (например, объем продаж, прибыль и т.д), будет отражено в таблице с фактическими продажами.

Шаг 3: Концептуальная модель данных

Предварительная модель данных будет создана на основе информации, собранной о сущностях. В нашем случае она будет выглядеть так:

Шаг 4: Доработка атрибутов и создание логической модели данных

Теперь необходимо завершить работу над атрибутами для сущностей. В нашем случае дорабатываются следующие атрибуты:

Date Dimension:

Product:

Store:

Promotion:

Sales Fact:

Объем продаж (например, количество банок овощного супа с лапшой).

Сумма продаж в долларах: количество продаж * цена за единицу.

Стоимость в долларах: стоимость продукта, взимаемая поставщиком.

Логическая модель данных будет выглядеть так:

Шаг 5: Создание физических таблиц в базе данных

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

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

Источник

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

Вы будете перенаправлены на Автор24

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

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

Классификация моделей данных

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

Помимо этого, современными БД широко используются страничные организации данных. Физические модели данных, которые основаны на страничной организации, наиболее перспективны в наши дни.

На рисунке 1 представлена схема классификации моделей данных.

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

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

Готовые работы на аналогичную тему

Различают даталогические модели двух основных категорий:

Гораздо более простым и удобным, чем SGML, является язык HTML, позволяющий оформлять элементы документа с помощью некоторого ограниченного набора инструкций (тегов) для осуществления процесса разметки. Инструкции HTML в основном используются в управлении процессом вывода содержимого документа на экран программы-клиента и определяют таким образом способ представления документа, а не его структуру. Как элемент гипертекстовой БД, описываемой HTML, представлен текстовый файл, легко передаваемый по сети с использованием протокола HTTP. Данная особенность, а также тот факт, что HTML представляет собой открытый стандарт и большая масса пользователей может применять возможности данного языка при оформлении своих документов повлияли на рост популярности HTML, ставшим на сегодняшний день главным механизмом представления информации в Интернете. Однако и HTML уже перестает удовлетворять в полном объеме требованиям, которые предъявляются современными разработчиками к языкам такого типа. Поэтому ему на смену пришел новый язык гипертекстовой разметки, более мощный, гибкий и удобный язык XML.

XML (Extensible Markup Language) является языком разметки, описывающим целый класс объектов данных, которые называются XML-документами.

Кроме того, его используют как средство описания грамматики других языков и как средство контроля за правильностью составления документов. Сам XML не содержит никаких тегов разметки, он лишь определяет порядок их создания.

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

Хранимые в базе данные представлены определенной логической структурой, т.е. описаны определенной моделью представления данных (моделью данных), которая поддерживается СУБД.

К классическим моделям данных относятся:

Помимо этого, в последние годы стали появляться и активно внедряться на практике следующие модели данных:

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

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

Главный и подчиненные объекты связаны по типу «один ко многим». Для каждого подчиненного типа объекта имеется лишь один исходный тип объекта.

Основной недостаток данной модели – достаточно длительный поиск необходимой информации.

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

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

В моделях подобного рода связи заложены внутри описаний объектов.

Достоинством является гибкость модели, т.е. имеется возможность повышения быстродействия системы.

Недостатком является нагрузка на информационные ресурсы.

Реляционная модель данных (РМД) свое название получила от английского термина relation, что означает «отношение». При соблюдении определенных условий отношение можно представить в виде двумерной привычной для человека таблицы. Основная масса современных БД для компьютеров являются реляционными.

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

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

Объектно-ориентированные БД включают в свой состав 2 модели данных: реляционную и сетевую, и применяются при создании крупных баз данных со сложными структурами.

По характеру использования СУБД бывают:

К персональным СУБД относят Visual FoxPro, Paradox, Clipper, dBase, Access и др. К многопользовательским СУБД относят Oracle и Informix. Многопользовательские СУБД состоят из сервера БД и клиентской части, работают в неоднородной вычислительной среде (разные типы ЭВМ и различные операционные системы). Поэтому СУБДМ можно использовать для создания информационной системы, функционирующей по технологии «клиент-сервер». Универсальность многопользовательских СУБД отражается на их высокой цене и компьютерных ресурсах, необходимых для их поддержки.

Источник

Модели данных и концептуальное моделирование

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

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

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

Объектные модели данных

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

Модели данных на основе записей

В модели на основе записей база данных состоит из нескольких записей фик­сированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фикси­рованную длину. Существуют три основных типа логических моделей данных на основе записей: реляционная модель данных ( relational data model ), сетевая мо­дель данных ( network data model ) и иерархическая модель данных ( hierarchical data model ). Иерархическая и сетевая модели данных были созданы почти на де­сять лет раньше реляционной модели данных, потому их связь с концепциями традиционной обработки файлов более очевидна.

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

Таблица 1. Пример описания сущности Branch в реляционной схеме

Таблица 2. Пример описания сущности Staff в реляционной схеме

Источник

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

СОДЕРЖАНИЕ

Обзор

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

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

Три перспективы

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

История

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

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

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

Источник