Рамиля Латыпова - Базы данных. Курс лекций. Учебное пособие

Иерархические БД имеют следующие достоинства:

1. Структура БД проста для понимания;

2. Отношения «предок – потомок» позволяют моделировать высказывания типа «А – часть В» или «А владеет В»;

3. Записи можно оптимально размещать на носителе информации, т. е. предки возле потомков, тем самым сокращается время доступа.

Самая известная из таких БД – это IMS (англ.: Information management system – система управления информацией) фирмы IBM (1968 г.). Эта система управления базами данных (СУБД) все еще активно эксплуатируется на больших ЭВМ.

Сетевые БД (здесь не имеются в виду сети ЭВМ) позволяют описать те случаи, когда одна запись может участвовать в нескольких отношениях «предок – потомок», т. е. иметь несколько предков (рис. 4). Такие отношения в сетевой модели называют множествами.

Рис. 4. Пример сетевой организации данных

Официальный стандарт сетевых БД был предложен в 1971 г., он получил название CODASYL (англ. COnference on DAta SYstems Language – Конференция по языкам систем обработки данных).

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

1. Найти запись по ее номеру (признаку);

2. Перейти к первому потомку в конкретном множестве;

3. Перейти «в сторону» от потомка к потомку в конкретном множестве;

4. Перейти «вверх» от потомка к предку в другом множестве;

5. Вставлять и удалять записи.

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

Но иерархические и сетевые БД имеют общий недостаток: структура данных описывается жестко на этапе проектирования. При перестройке структуры нужно перестраивать всю БД.

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

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

Теоретический фундамент реляционных БД заложил Э. Кодд, разработавший в 70-е гг. математический аппарат теории отношений. Реляционная модель является теорией, но фактически ни одна из современных БД не придерживается на все 100 % положений этой теории. То есть пользователь должен учитывать теоретические рекомендации, но имеет возможности для их нарушения.

При математическом описании понятию таблицы соответствует понятие отношение, столбцу – атрибут, и строке – кортеж.

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

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

По отношению к пользователю реляционные БД поддерживают два основных принципа:

1. Данные для пользователя представляются в виде таблиц;

2. Пользователь имеет в своем распоряжении операторы, позволяющие получить новые таблицы из старых.

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

1. Все значения данных состоят из простых типов данных. Отсутствуют сложные типы, такие как массивы, указатели, векторы и т. д.;

2. Все данные отображаются в виде двумерных таблиц (отношений). Каждая таблица содержит некоторое число строк (кортежей) и один или несколько столбцов (атрибутов);

3. После ввода данных можно сравнивать значения в различных столбцах и соотносить строки (в том числе и для разных таблиц);

4. Все операции определяются только логикой, а не положением строки в таблице;

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

6. Каждое значение в столбце должно быть атомарной величиной, т. е. содержать только одно значение.

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

Кроме того, реляционные БД используют еще ряд объектов. К ним относятся:

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

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

3. Формы и отчеты иногда называют конструкторскими объектами. Они могут включать в себя элементы управления, такие как надписи, прямоугольники, линии, рисунки, выключатели, флажки и т. п.;

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

5. Макросы – предназначены для выполнения часто исполняемых операций. Каждый макрос содержит одну или несколько макрокоманд. Каждая макрокоманда выполняет определенное действие (открытие формы, печать отчета и т. п.);

6. CASE-средства (Computer-Aided Software Engineering) – это программы для разработки структуры БД в виде диаграмм и автоматической генерации БД на их основе.

Для построения запросов к реляционным БД был разработан язык SQL (англ.: Structured Query Language – язык структурированных запросов). SQL получил характер промышленного стандарта. Его поддерживают все современные БД. При переходе с одной БД на другую разработчик имеет дело с одним и тем же языком SQL. Это позволяет не вникать в детали низкоуровневого доступа к данным, а учитывать только логическое описание БД. SQL является языком более высокого уровня, чем обычные языки программирования.

Операторы SQL выполняются на уровне множеств. Этот язык является декларативным, т. е. пользователь описывает, что ему нужно получить, но описывает алгоритм, при помощи которого это можно сделать. Процедура получения решения строится без участия пользователя [7].

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

К локальным БД относятся Paradox, dBase, Access, FoxPro и др. БД Access занимает особое положение, потому что входит в состав распространенного пакета Microsoft Office. Локальные данные, как правило, располагаются на жестком диске компьютера, на котором работает пользователь, и находятся в монопольном ведении этого пользователя. Пользователь при этом работает автономно, не завися от других пользователей и никоим образом не влияя на их работу.

К серверным БД относятся Oracle, Sybase, SQL Server и др. Удаленные данные располагаются вне компьютера пользователя – на файловом сервере сети или на специально выделенном для этих целей компьютере.

Всего можно выделить три архитектуры серверных БД:

1. Архитектура «файл-сервер»;

2. Архитектура «клиент-сервер»;

3. Многозвенная архитектура.

При работе с локальными БД режим однопользовательский.

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

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