Недостатки

§ отсутствие стандартных средств идентификации отдельных записей

§ сложность описания иерархических и сетевых связей.

§ Невысокое быстродействие промышленных реализаций.

 

Пример. Разработаем модели данных различных типов для задачи «Преподаватель читает курс».

Множество учебных курсов представим совокупностью Kl, K2, КЗ. Множество преподавателей, соответственно, П1, П2, ПЗ.

Рис. 5. Исходные данные задачи «Преподаватель читает курс».

В иерархической модели связи между данными о преподавателях и читаемых ими курсах могут быть отражены в виде дерева, где возможны только односторонние связи от старших вершин к младшим (рис. 6.). Это облегчает быстрый доступ к необходимой информации, но только если запросы учитывают структуру дерева. Например, оперативно можно определить, какие курсы читает преподаватель П2. Запросы, не учитывающие структуру дерева (например, какие преподаватели читают курс К1), выполняются медленнее.

Рис. 6. Иерархическая модель данных задачи «Преподаватель читает курс».

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

Рис. 7. Сетевая модель данных задачи «Преподаватель читает курс».

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

ПРЕПОДАВАТЕЛЬ		ЧИТАЕТ			КУРС
НП	ФИО_П		НП	НК		НК	НАИМ_К
П1	Бек О.И.		П1	К1		К1	АСУ
П2	Ильин С.К.		П1	К2		К2	КСЕ
П3	Сомова Н.Н.		П1	К3		К3	Экология
			П2	К1
			П2	К3
			П3	К2
			П3	К3

Рис. 8. Реляционная модель данных «Преподаватель читает курс», где НП — номер преподавателя; НК — номер курса

Данный пример наглядно показывает, как таблица ЧИТАЕТ будет расти с ростом таблиц ПРЕПОДАВАТЕЛЬ и КУРС.

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

Доминирование реляционной модели в современных СУБД определяется следующими обстоятельствами:

· наличием развитой теории (реляционной алгебры);

· наличием аппарата сведения других моделей данных к реляционной модели;

· наличием специальных средств ускоренного доступа к информации;

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

 

Задания для самостоятельной работы

1. Расширить задачу «Преподаватель читает курс» данными об аудиториях. Оценить усложнение схемы.

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

 

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

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