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

Рис. 1.7. Распределение курсов между преподавателями.

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

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

Рис. 1.9. Сетевая модель данных.

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

Рис. 1.10. Реляционная модель данных: НП – номер преподавателя; НК – номер курса.

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

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

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

Рис. 1.11. Архитектура СУБД: а – однозвенная; б – двухзвенная; в – трехзвенная.

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