Если отношение содержит несколько комбинаций атрибутов однозначно идентифицирующих кортеж, то такие комбинации называют возможными ключами. Понятие первичного ключа позволяет устанавливать связи между отношениями: атрибут отношения R1 является внешним ключом, если этот атрибут – не первичный ключ отношения R1, но его значения являются значениями первичного ключа некоторого отношения R2 [5].
Дополнительным объектом, включенным в реляционную модель представления данных, является каталог.
Каталог — это набор системных переменных-отношений, содержащих метаданные о различных элементах, важных для системы (базовых переменных-отношениях, представлениях, индексах, пользователях и т.д.). [7]
Замечательным свойством реляционных систем является то, что их каталог также состоит из переменных-отношений (точнее, из системных переменных-отношений, названных так для того, чтобы отличать их от обычных пользовательских). В результате пользователь может обращаться к каталогу так же, как к своим данным. Например, в каталоге обычно содержатся системные переменные-отношения TABLES и COLUMNS, назначение которых — описание известных системе таблиц (т.е. переменных-отношений) и столбцов этих таблиц. (Мы говорим "обычно", потому что каталоги в различных системах разные, так как существенная часть информации каталога является специфической для конкретной системы.) [7].
Таким образом, реляционная модель представления данных вводит понятия:
Домен
Атрибут
Отношение
Первичный ключ отношения
Внешний ключ отношения
Каталог
Конкретная реализация реляционной СУБД, как правило, включает также возможность определения дополнительных объектов.
Таким образом, в 70-х годах была сформулирована математическая теория, основоположником которой является доктор Э.Ф. Кодд, на основе которой была разработана реляционная модель и средства ее описания, легшие в основу современных СУБД.
Язык описания данных в стандарте SQL
В статье, опубликованной в журнале Computerworld в 1985 году, доктор Э. Ф. Кодд сформулировал 12 правил, которым должна соответствовать реляционная база данных. Перечисленные правила основаны на теоретических основах реляционной модели данных:
Двенадцать правил Кодда, которым должна соответствовать реляционная база данных:
1. Правило информации. Вся информация в базе данных должна быть представлена исключительно на логическом уровне и только одним способом — в виде значений, содержащихся в таблицах.
2. Правило гарантированного доступа. Логический доступ ко всем и каждому элементу данных (атомарному значению) в реляционной базе данных должен обеспечиваться путем использования комбинации имени таблицы, первичного ключа и имени столбца.
3. Правило обработки отсутствующих значений. В настоящей реляционной базе данных должна быть реализована поддержка отсутствующих значений, которые отличаются от строки символов нулевой длины, строки пробельных символов и от нуля или любого другого числа и используются для представления отсутствующих данных независимо от типа этих данных.
4. Правило динамического каталога, основанного на реляционной модели. Описание базы данных на логическом уровне должно быть представлено в том же виде, что и основные данные, чтобы пользователи, обладающие соответствующими правами, могли работать с ним с помощью того же реляционного языка, который они применяют для работы с основными данными.
5. Правило исчерпывающего подъязыка базы данных. Реляционная система может поддерживать различные языки и режимы взаимодействия с пользователем. Однако должен существовать, по крайней мере, один язык, инструкции которого можно представить в виде строк символов в соответствии с некоторым четко определенным синтаксисом и который в полной мере поддерживает все следующие элементы:
a. определение данных;
b. определение представлений;
c. обработку данных (интерактивную и программную);
d. условия целостности данных;
e. идентификацию прав доступа;
f. границы транзакций (начало, завершение и отмена).
6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать не только при выборке данных, по и при добавлении, обновлении и удалении данных.
8. Правило физической независимости данных. Прикладные программы и утилиты для работы с данными должны па логическом уровне оставаться нетронутыми при любых изменениях способов хранения данных или методов доступа к ним.
9. Правило логической независимости данных. Прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться нетронутыми при внесении в таблицы базы данных любых изменений, которые теоретически позволяют сохранить нетронутыми содержащиеся в этих таблицах данные.
10. Правило независимости условий целостности данных. Должна существвать возможность определять условия целостности, специфичные для конкретной реляционной базы данных, на подъязыке этой базы данных и хранить их в динамическом каталоге, а не в прикладной программе.
11. Правило независимости размещения. Реляционная база данных не должна зависеть от особенностей системы, в которой она расположена.
12. Правило единственности. Если в реляционной системе есть низкоуровневый язык (обрабатывающий одну запись за один раз), то должна отсутствовать возможность использования его для того, чтобы обойти правила и условия целостности данных, выраженные на реляционном языке высоко: уровня (обрабатывающем несколько записей за один раз) [4].
Появление реляционных баз данных вызвало появление нескольких диалектов языка управления реляционными базами данных. Стандартом дефакто стал язык структурированных запросов (SQL). Работа над официальным стандартом SQL началась в 1982 году и первый стандарт был официально издан в 1986 году. Однако конкретные реализации значительно отличались от объявленного стандарта.
В стандарте SQL используются понятия, которые основаны на понятиях реляционной модели:
Таблица - Отношение
Строка или запись - Кортеж
Количество строк - Кардинальность
Столбец или поле - Атрибут
Количество столбцов - Степень
Уникальный идентификатор - Первичный ключ
Совокупность допустимых значений - Домен.
Для изменения и описания структуры базы данных предназначен набор инструкций SQL, который называется языком определения баз данных (ЯОД). В большинстве случаев инструкции ЯОД обеспечивают высокий уровень доступа к данным и позволяют пользователю не вникать в детали хранения информации в базе данных на физическом уровне [4].
Основными операторами, реализуемыми в ЯОД являются:
- Оператор создания объекта базы данных (CREATE)
- Оператор удаления объекта (DROP)
- Оператор модификации объекта (ALTER)
Практически все коммерческие СУБД поддерживают ЯОД как неотъемлемую часть языка SQL, хотя стандарт SQL1 этого не требует. В принятом в 1992 году стандарте SQL2 были определены те части ЯОД, которые являются независимыми от структур физического хранения, особенностей операционной системы и других специфических особенностей СУБД. В конкретных же реализациях СУБД включают множество дополнений ЯОД, связанных со спецификой реализации каждой конкретной СУБД [4].
Если рассмотреть три версии стандарта SQL (1986год, 1992 год, 2003 год), то можно проследить развитие реализации реляционной модели представления данных.
Реляционная модель данных не указывает на то, как различные отношения группируются в различные базы данных. Вследствие этого, в различных СУБД изначально применялись неодинаковые подходы к этому вопросу. В стандарте SQL1 содержится спецификация языка SQL, используемого для описания структуры базы данных, но не указывается способ создания базы данных [4]. В настоящее время, методы создания баз данных в различных СУБД также имеют явные различия:
В СУБД DB2 структура базы данных определена по умолчанию. База данных ассоциируется с выполняемой копией серверного обеспечения DB2, и пользователь получает доступ к базе данных, подключаясь к серверу DB2. База данных создается в процессе инсталляции DB2 на конкретную компьютерную систему.
В СУБД Oracle база данных создается в ходе процесса установки программного обеспечения, как и в DB2 [4] В последних версиях СУБД Oracle появилась инструкция CREATE DATABASE, которая определяется стандартом SQL2.
В СУБД MySQL при установке серверного обеспечения создается две системных базы данных: mysql – содержащая, системную информацию и test – тестовая база данных. Пользователь может создавать базы данных с помощью инструкции CREATE DATABASE или просто создав каталог с именем базы данных в каталоге данных сервера mysql.
Описание таблицы происходит с помощью специальной инструкции SQL: каждый оператор CREATE TABLE задает имя создаваемой базовой таблицы, имена и типы данных столбцов этой таблицы, а также первичный ключ таблицы и любые внешние ключи, присутствующие в ней [7].
При этом, важным отличием от реляционной модели является запрет на определение пользователем собственных типов данных. Для определения столбцов можно использовать только встроенные (определенные системой) типы [6].
В стандарте SQL2 умышленно не дано определения термина база данных, поскольку этот термин в различных СУБД трактуется по-разному. Вместо него употребляется термин каталог, означающий именованную коллекцию системных таблиц, описывающих структуру базы данных. В стандарте также не указано как должен создаваться и уничтожаться каталог [4].
В языке SQL существует аналог того, что принято называть каталогом, — информационная схема. ... Нестрого говоря, каталог в языке SQL состоит из дескрипторов (метаданных) для отдельной базы данных, а схема состоит из дескрипторов той части базы данных, которая принадлежит отдельному пользователю. Другими словами, в системе может быть любое число каталогов (по одному для каждой базы данных), каждый из которых делится на произвольное число схем. Однако каждый каталог должен содержать ровно одну схему с именем INFORMATION_SCHEMA (информационная схема), которая, с точки зрения пользователя, и является схемой (как уже указывалось), выполняющей функции обычного каталога.