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

Реляционная модель данных является совокупностью взаимосвязанных двумерных таблиц - объектов модели.

Строки таблицы соответствуют записям базы данных, одинаковые строки в таблице отсутствуют.

Например, реляционной таблицей можно представить информацию о студентах, обучающихся в вузе

Рис. 1.10. Пример реляционной таблицы

№ личного дела	Фамилия	Имя	Отчество	Дата рождения	Группа
16493	Сергеев	Петр	Михайлович	01.01.76	111
16593	Петрова	Анна	Владимировна	15.03.75	112

Связи между двумя логически связанными таблицами в реляционной модели устанавливаются по равенству значений одинаковых атрибутов этих таблиц.

Первичный ключ — это столбец или некоторое под­множество столбцов, которое уникально, т.е. единствен­ным образом определяет строки. Первичный ключ, кото­рый включает более одного столбца, называется множе­ственным или комбинированным, или составным. Осталь­ные ключи, которые также можно использовать в каче­стве первичных, называются потенциальными или аль­тернативными ключами.

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

В примере, показанном на рис. 1.10, ключевым полем таблицы является "№ личного дела".

 Понятие "реляционный" (англ. relation - отношение) связано с разработками известного американского специалиста в области систем баз данных -  Е. Кодда.

Правила Кодда.

Двенадцать правил Кодда определяют требования к реляционным СУБД.

1. Явное представление данных. Информация должна быть представлена в виде данных, хранящихся в ячейках.

2. Гарантированный доступ к данным. К каждому элементу данных должен быть обеспечен доступ с помо­щью комбинации имени таблицы, первичного ключа стро­ки и имени столбца.

3. Полная обработка неопределенных значений. Не­определенные значения Null, отличные от любого опре­деленного значения, должны поддерживаться для всех типов данных при выполнении любых операций.

4. Доступ к описанию базы данных в терминах реля­ционной модели. Словарь данных активной базы данных должен сохраняться в форме таблицы, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств доступа к таблицам.

5. Полнота подмножества языка. Язык управления данными и язык определения данных должны поддер­живать все операции доступа к данным и быть единствен­ным средством такого доступа, кроме, возможно, опера­ций низшего уровня (см. правило 12).

6. Возможность обновления представлений. Все пред­ставления, подлежащие обновлению, должны быть дос­тупны для этого.

7. Наличие высокоуровневых операций управления данными. Операции вставки, обновления и удаления дол­жны применяться к таблице в целом.

8. Физическая независимость данных. Прикладные программы не должны зависеть от используемых спосо­бов хранения данных на носителях и методов обращения к ним.

9. Логическая независимость данных. Прикладные программы не должны зависеть от логических ограни­чений

10. Независимость контроля целостности. Все необ­ходимое для поддержания целостности данных должно храниться в словаре данных.

11. Дистрибутивная независимость. Реляционная база данных должна быть переносимой и способной к рас­пространению.

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

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