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

История реляционных СУБД ведет свое начало с конца 60-х, когда одновремнно несколькими авторами были выдвинуты предложения об использовании теоретико-множественных операторов для организации доступа к данным. Наиболее известными являются работы Е. Кодда. Затем была экспериментальная система управления базми данных System R и использованный в ней язык SEQUEL, который можно считать непосредственным предшественником языка SQL. В настоящее время именно язык SQL является и де-юро, и де-факто стандартом для работы с реляционными СУБД. Например, семейство серверов реляционных баз данных Informix Dynamic Server поддерживают все эти стандарты и, кроме того, обеспечивают дополнительные возможности.

Интересно отметить, что еще в 1980 году Джефри Ульман (J.D. Ullman) писал в своей монографии "Основы систем баз данных" ("Principles of Databse Systems"), что почти все существующие коммерческие системы баз данных базируются либо на сетевой, либо на иерархической модели данных, но не реляционной модели и "эта ситуация будет меняться медленно". Тем не менее, уже в 1985 году ситуация резко поменялась - реляционные СУБД и язык SQL стали очень популярными. А в начале 90-х годов реляционные СУБД и язык SQL практически вытеснили все остальное с рынка СУБД. Причиной для такого кардинального изменения ситуации стала разработка эффективных, быстрых и надежных методов хранения и доступа к реляционным данным.

Понятие отношения и таблицы

Давайте определим, что же такое реляционная СУБД и как в ней представляются данные. Для реляционной СУБД выбрано представление на основе математического понятия "отношение". Оно очень близко к знакомым всем нам понятию "таблица". По-английски отношение называется "relation", отсюда и название "реляционные СУБД (если называть такие базы "относительными", то это может исказить смысл).

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

В дальнейшем мы будем использовать все же термин "таблица", а не "отношение", так как этот термин понятен, привычен и самый распространненый язык доступа к реляционным базам данных - язык SQL - использует именно этот термин, хотя и понимает под ним "неупорядоченные" таблицы.

Представление базы данных

Реляционная база данных - это набор информации, сгруппированной в одну или несколько таблиц. Таблицу можно представить как двумерный массив, или как набор записей одинаковой (для данной таблицы) структуры. Записи еще называют рядами. Другими словами, таблица состоит из рядов и столбцов. Число столбцов и записей для каждой таблицы теоретически неограничено, хотя на практике ограничения, естественно, существуют. Превысить ограничения хорошего сервера базы данных практически невозможно - например, сервер баз данных Infomix DS позволяет иметь до 32 767 столбцов и до 8 миллиардов записей в каждой таблице.

+-----+----+-----+-------+ ¦ ¦ ¦ ¦ ¦ <-------- запись (ряд) ¦-----+----+-----+-------¦ ¦ ¦XXXX¦ ¦ ¦ <-------- запись (ряд) ¦-----+-+--+-----+-------¦ ¦ ¦ ¦ ¦ L----------------+----> значение данного атрибута ¦ ................... ¦ для данной записи ¦-----+----+-----+-------¦ ¦ ¦ ¦ ¦ ¦ +-----+----+-----+-------+ ^ ^ ¦ ¦ ¦ L---------- столбец (атрибут, поле) L-------------- столбец (атрибут, поле)

Рис. 2.6. Структура таблицы (отношения).

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

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

Связь между таблицами

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

Таблица "Издательства": +--------------------------+-----------------+ ¦ Название ¦ Адрес ¦ +--------------------------+-----------------+ ¦ Бухгалтерия и спорт ¦ Одесса, п/я 13 ¦ ¦ Драконоведение ¦ Энск, 5-е авеню ¦ ¦ .................... ¦ ............... ¦ +--------------------------+-----------------+

Таблица "Сборники": --------------------------T------------------------+ ¦ Сборник ¦ Издательство ¦ +-------------------------+------------------------+ ¦ Финансы в спорте’97 ¦ Бухгалтерия и спорт ¦ ¦ Как уйти от налогов ¦ Бухгалтерия и спорт ¦ ¦ Техника бега ¦ Бухгалтерия и спорт ¦ ¦ Китайские бумажные змеи ¦ Драконоведение ¦ ¦ ...... ¦ .................... ¦ L-------------------------+------------------------+

Рис. 2.7. Структура некоторых таблиц из базы данных для издательств (отношения).

Теперь по названию сборника всегда можно определить название и адрес издательства (или нескольких издательств), его выпустившего. Для этого надо в таблице "Сборники" найти запись, у которой поле "Сборник" есть требуемое название, из найденной запись взять название издательства (атрибут “Издательство”), а потом в таблице "Издательства" найти нужный адрес.

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

Основным достоинством реляционных СУБД, обеспечившим таким СУБД высокую популярность, является нефункциональность языков запроса, в частности, языка SQL. Это означает, что Вы формулируете не то, КАК Вам надо найти данные, а то, ЧТО Вам надо найти.

SQL - классическая язык доступа к реляционным СУБД

Практически все современные реляционные СУБД поддерживают Structured Query Language (SQL) - язык структурированных запросов. Синтаксис и семантика данного языка определены стандартами ISO, базирующимися на соответствующих стандартах ANSI SQL 87, SQL-89 и SQL-92.

Описание схемы базы данных для нашего примера с издательствами будет выглядеть примерно так:

CREATE TABLE Издательства ( Название CHAR(20), Адрес CHAR(40) )

CREATE TABLE Сборники ( Сборник CHAR(20), Издательство CHAR(20) )

Запрос, который определит адрес издательства (или издательств), выпустивший сборник “Китайские воздушные змеи” будет выглядеть следующим образом:

SELECT Адрес FROM Издательства WHERE Название = (SELECT Издательство FROM Сборники WHERE Сборник = “Китайские воздушные змеи”)

Достоинства и недостатки

Основным достоинством реляционных СУБД, обеспечившим таким СУБД высокую популярность, является нефункциональность языка запросов - языка SQL. Это означает, что Вы формулируете не то, КАК Вам надо найти данные, а то, ЧТО Вам надо найти.

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

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

Более подробно реляционная модель и язык SQL будут рассмотрены ниже.