В основе реляционной базы данных лежит идея о связанных двумерных таблицах, состоящих из строк и столбцов, как показано на ниже.
В отличие от иерархического подхода, между таблицами нет заранее определенного взаимоотношения (relationship). Это означает, что не нужно определять никаких данных для связывания различных участков, как в сетевой или иерархической модели. Тот факт, что для извлечения данных пользователь не обязан понимать, как они представлены на устройстве хранения (а многим пользователям необходимо предъявлять заранее непредусмотренные запросы), немало способствовал популяризации реляционной модели.
Программирование в реляционной модели не является процедурным, и программа оперирует множеством строк. Если между двумя таблицами есть взаимоотношение «главная-подчиненная» (master detail), то каждой строке главной таблицы может соответствовать одна или несколько строк в подчиненной. Тем не менее, команды, применяемые для доступа к данным, вставки и изменения данных, описывают всего лишь результирующее множество. Во многих ранних реляционных СУБД для доступа к данным необходимо было использовать процедурные языки, позволяющие получать по одной записи на каждом шаге.
Но ориентированность на множества упрощает для программы получение сразу нескольких записей из реляционной базы. Реляционные СУБД более эффективны при извлечении значений из большого набора данных.
Строки на рисунке часто называют записями. Значение на пересечении столбца и строки называется полем. Таблицы хранятся в схеме базы данных; так называется логическая организационная единица в СУБД.
Помимо таблиц, в схеме хранятся другие логические структуры, на пример:
Представления
Обеспечивают единое представление данных, взятых из одной или нескольких таблиц или других представлений. Представление – это альтернативный интерфейс к данным, хранящимся в базовой таблице (или нескольких таблицах).
Последовательности
Механизм генерации уникальных числовых значений в столбцах.
Хранимые процедуры
Логические модули, которые можно вызывать из программы.
Синонимы
Механизм назначения альтернативных имен объектам базы данных.
Индексы
Обеспечивают быстрый доступ к строкам таблицы.
Связи баз данных
Механизм формирования связей между распределенными базами данных.
Взаимоотношения между столбцами разных таблиц обычно описываются с помощью ключей, которые реализуются посредством ограничений ссылочной целостности и поддерживаемых индексов. Например, обращаясь к рисунку, мы можем установить связь между столбцом DEPTNO второй таблицы, который называется внешним ключом (foreign key), и столбцом DEPTNO первой таблицы, который называется первичным ключом (primary key) этой таблицы.
Наконец, даже если для некоторой таблицы определено несколько индексов, вы не обязаны понимать, как они устроены, и самостоятельно управлять хранящимися в них данными. В состав Oracle входит оптимизатор запросов (описан в главе 4), который решает, нужно ли использовать для доступа к данным какие нибудь индексы и как это сделать наилучшим образом.
Реляционный подход привел к созданию структурированного языка запросов Structured Query Language (SQL). Изначально язык SQL определялся исследовательским отделом компании IBM, что заняло несколько лет, но именно корпорация Oracle первой вывела его на рынок в 1979 году. В то время SQL считался единственным языком, необходимым для работы с реляционными базами данных, поскольку он:
- позволял формулировать запросы (с помощью команды SELECT);
- мог выступать в качестве языка манипулирования данными (Data
- Manipulation Language, DML) (команды INSERT, UPDATE и DELETE);
- мог выступать в качестве языка определения данных (Data Definition Language, DDL) (команды CREATE и DROP для создания и удаления таблиц);
- позволял назначать привилегии отдельным пользователям или группам (команды GRANT и REVOKE).
Ныне для языка SQL есть много расширений, а также стандарты ANSI/ISO, определяющие его базовый синтаксис.
