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

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

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

В литературе предложено и опубликовано достаточно много моделей данных. Они подразделяются на следующие две категории: объектные (object-based) модели данных и модели данных на основе записей (record-based).

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

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

 Модель типа “сущностьсвязь” или ERмодель (EntityRelationship)

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

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

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

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

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

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

Список составных частей изделия представляет собой иерархическую структуру. Для хранения данных, имеющих такую структуру, и была разработана иерархическая модель данных. В этой модели каждая запись представляет конкретную составную часть. Между записями существовали отношения предок/потомок, связывающие каждую составную часть с частями, входящими в нее.

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

 найти конкретную запись (по ее номеру)

 перейти “вниз” к первому потомку

 перейти “вверх” к предку

 перейти “в сторону” к другому потомку.

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

4.2.2 Сетевая модель данных

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

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

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

 найти конкретную запись предка по ключу (например, номер клиента)

 перейти к первому потомку в конкретном множестве (первый заказ, размещенный клиентом)

 перейти в сторону от одного потомка к другому в конкретном множестве (следующий заказ, сделанный этим же клиентом)

 перейти вверх от потомка к его предку в другом множестве (служащий, принявший заказ)

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

Подобно своим иерархическим предкам, сетевые базы данных были очень “жесткими”. Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры базы данных обычно означало перестройку последней.

Как иерархическая, так и сетевая базы данных были инструментами программистов. Чтобы получить ответ на запрос: “Какой товар наиболее часто заказывает компания Х? ”, программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.