Понятие реляционной базы данных возникло в начале 70-х годов XX века. Создателем реляционной модели считается сотрудник фирмы IBM доктор Е. Ф. Кодд (Codd E.F.), опубликовавший в июне 1970 года знаменитую статью «Реляционная модель данных для больших совместно используемых банков данных» («A Relational Model of Data for Large Shared Data Banks», CACM 13: 6), в которой впервые прозвучал термин «реляционная модель». Математик по образованию, Е. Кодд на службу обработки данных поставил аппарат теории множеств. Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение (relation).
В рамках реляционной модели доктора Кодда в 70-х годах был проведен ряд теоретических и практических изысканий, нацеленных на создание прототипа реляционной СУБД. Впечатляющие результаты в этой области весьма скоро были получены научно-исследовательской лабораторией корпорации IBM, построившей первый прототип реляционной СУБД - «System R». Практически параллельно с IBM в Калифорнийском университете в рамках проекта INGRES (INteractive GRaphics REtrival System) была теоретически обоснована состоятельность реляционной модели.
Исходное определение реляционной модели включает «двенадцать правил Кодда», соблюдение которых является необходимым (но далеко не достаточным условием) создания реляционной СУБД. Впервые список правил доктора Кодда был опубликован в журнале «ComputerWorld» в 1985 году:
1. Правило информации. Вся информация в базе данных должна храниться в таблицах.
2. Правило гарантированного доступа. Для доступа к любому значению должно быть достаточно комбинации имени таблицы, столбца и первичного ключа.
3. Правило поддержки недействительных значений. В базе данных должна быть реализована поддержка недействительных (пустых) значений -NULL. Значения NULL должны отличаться от строк нулевой длины, пробелов, нуля или любого другого числа.
4. Правило динамического каталога, основанного на реляционной модели.
Описание БД на логическом уровне не должно быть организовано таким же образом, как и основные данные. Другими словами, база данных должна содержать системные таблицы, в которых будет описываться структура этой БД.
5. Правило исчерпывающего подъязыка данных. Операторы языка СУБД должны уметь:
• определять данные, условия целостности данных, представления;
• обрабатывать данные;
• задавать границы транзакций;
• идентифицировать права доступа.
Практически все СУБД в качестве такого языка используют структурированный язык запросов (SQL). Этому языку посвящена глава 32.
6. Правило обновления представлений (виртуальных таблиц). Все представления должны быть доступны для обновления.
7. Правило добавления, обновления и удаления. Правило требует, чтобы операции записи и удаления данных в СУБД были ориентированы на работу с множествами, а не на отдельную запись.
8. Правило независимости физических данных. Изменение способа хранения данных или методов доступа к ним не должно повлечь за собой изменение на физическом уровне прикладных программ, предназначенных для работы с этими данными.
9. Правило независимости логических данных. Внесение в базовые таблицы любых изменений не должно повлечь за собой изменение на логическом уровне прикладных программ, предназначенных для работы с этими данными.
10. Правило независимости условий целостности. СУБД должна уметь определять условия целостности БД и хранить их в каталоге, а не в прикладной программе.
11. Правило независимости распространения. СУБД обязана обеспечивать возможность работы с распределенными данными, размещенными на различных компьютерных системах.
12.Правило единственности. Работа с БД возможна только на реляционном языке этой БД.
Для реляционной модели, отвечающей этим правилам, утвердилась аббревиатура RM/V1. Однако на этом доктор Кодд не остановился: в модели 1990 года RM/V2 описано 333 характеристики, а в перспективной - RM/V3 - ожидается декларация более 600 характеристик. Стоит отметить, что даже в самых современных СУБД есть существенные отклонения от ряда требований Код-да, о чем осведомлен и сам ученый. Поэтому он предлагает разработчикам придерживаться хотя бы двух ключевых правил. Нулевое правило гласит:
Любая система, которая объявляется или претендует на то, чтобы называться реляционной системой управления базой данных, должна быть в состоянии полностью управлять базой данных, используя ее реляционные свойства. При этом не важно, какими дополнительными свойствами может обладать данная система.
Смысл первого правила в том, что должны отсутствовать обходные пути нулевого правила.
