Шаг 105 - Oracle - Реляционная модель, Правила КОДА (E.F. CODD)

Раз уж мы углубились в дебри реляционной модели данных, давайте уже разберемся со всем этим до конца, вы хорошо все это запомните и мы пойдем дальше. Помимо таблиц и их свойств, реляционная модель имеет еще и собственные операции. Не вдаваясь глубоко в формулировки реляционной математики, отметим, что эти операции позволяют выполнять некоторые действия над подмножествами столбцов строк, объединять (сливать) таблицы. Важно отметить, что все эти операции используют таблицы в качестве исходных данных, а что самое интересное - результат выполнения этих операций так же является таблицами. Все это относится, как вы уже думаю догадались, к языку SQL. Основными операторами этого языка, обеспечивающими манипулирование данными и доступ к ним, являются SELECT, INSERT, UPDATE, DELETE. Вот четыре основных, кирпичика языка DML. А, вот для определения данных и структурированного доступа к ним служат базовые операторы языка DDL - CREATE, ALTER и DROP. Если присмотреться, то эти трое уж очень напоминают, тех четверых. С той лишь разницей, что первые манипулируют с содержимым объектов БД, а вторые с собственно с самими объектами. Хотя может быть объединение в одном языке функций определения и управления очень привлекательно. Вместо двух языков, мы получаем один хотя и более сложный. Что в конечном итоге приводит к тому, что и администратор БД и пользователь применяют одно и то же средство! Вот собственно так и определяется реляционная модель БД. В конце 70х - начале 80х, произошло следующее событие. Была предпринята попытка внедрить средства языка SQL в не реляционные системы, а затем их попросту назвали реляционными! Стали они от этого реляционными или нет - покажет время. А основным критерием по сей день служат двенадцать правил сформулированных Коддом (за которыми так и закрепилось название - правила Кодда). Давайте я приведу сами эти правила, а вы попытайтесь осмыслить каждое из них и сделать к ним свой комментарий. Хотя это довольно не простая задача! :) Итак двенадцать негритят тьфу ! Правил Кодда:

1. ЯВНОЕ ПРЕДСТАВЛЕНИЕ ДАННЫХ. Информация должна быть представлена в виде данных, хранящихся в ячейках.

2. ГАРАНТИРОВАННЫЙ ДОСТУП К ДАННЫМ. К каждому элементу данных должен быть обеспечен доступ с помощью комбинации имени таблицы, первичного ключа (вот тут спорный вопрос, но пусть!) строки и имени столбца.

3. ПОЛНАЯ ОБРАБОТКА НЕОПРЕДЕЛЕННЫХ ЗНАЧЕНИЙ. Неопределенные значения NULL отличные от любого определенного значения, должны поддерживаться для всех типов данных при выполнении любых операций. (Давний спор всего сообщества по поводу тройственной логики!)

4. ДОСТУП К ОПИСАНИЮ БД В ТЕРМИНАХ РЕЛЯЦИОННОЙ МОДЕЛИ. Словарь данных БД должен сохранятся в форме таблицы и СУБД должна поддерживать доступ к нему при помощи стандартных, языковых средств доступа к таблицам.

5. ПОЛНОТА ПОДМНОЖЕСТВА ЯЗЫКА. Язык управления данными и язык определения данных должны поддерживать все операции доступа и быть единственным средством, такого доступа кроме возможно, операций нижнего уровня.

6. ВОЗМОЖНОСТЬ ОБНОВЛЕНИЯ ПРЕДСТАВЛЕНИЙ. Все представления подлежащие обновлению должны быть доступны для этого.

7. НАЛИЧИЕ ВЫСОКОУРОВНЕВЫХ ОПЕРАЦИЙ УПРАВЛЕНИЯ ДАННЫМИ. Операции вставки, удаления, обновления должны применяться к таблице в целом.

8. ФИЗИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы не должны зависеть от используемых способов хранения данных на носителях и методов обращения к ним.

9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы не должны зависеть от логических ограничений.

10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое для поддержания целостности данных, должно храниться в словаре данных.

11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна быть переносимой и способной к распространению.

12. СОГЛАСОВАНИЕ ЯЗЫКОВЫХ УРОВНЕЙ. Допускается использование низкоуровнего языка доступа, где элемент доступа запись.

Но, что самое интересное, существует и правило 0 (ноль)! Оно звучит примерно таким образом:

ДЛЯ ТОГО, ЧТОБЫ СИСТЕМУ МОЖНО БЫЛО КВАЛИФИЦИРОВАТЬ КАК РЕЛЯЦИОННУЮ СУБД, ОНА ДОЛЖНА ИСПОЛЬЗОВАТЬ ДЛЯ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ ИСКЛЮЧИТЕЛЬНО РЕЛЯЦИОННЫЕ ФУНКЦИИ!

Вот такие умозаключения. Если есть мнения, то готов их выслушать. Хотя это тема для длительной дискуссии. :)


Предыдущий Шаг | Следующий Шаг | Оглавление
Автор Летучий Сергей.