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

Специальные операции реляционной алгебры

Операция горизонтального выбора, или фильтрации, или ограничения отношений. Результатом операции выбора, или фильтрации, заданной на отношении R в виде логического условия, определенного на атрибутах отношения R, называется отношение R[G], включающее те кортежи из исходного отношения, для которых истинно условие выбора или фильтрации.

Операция проектирования. Проекцией отношения R на набор атрибутов В, обозначаемой R[B], называется отношение, содержащее кортежи, получаемые из кортежей исходного отношения R путем удаления из них значений, не принадлежащих атрибутам из набора В.По определению отношений все дублирующие кортежи удаляются из результирующего отношения. Операция проектирования, называемая иногда также операцией вертикального выбора, позволяет получить только требуемые характеристики моделируемого объекта.

Операция условного соединения. Соединением отношений R и Q при условии Р будет подмножество декартова произведения отношений R и Q и связанных по группе атрибутов и кортежи, которого удовлетворяют условию Р.

Операция деления. Поясним эту операцию на примере. Операция деления удобна тогда, когда требуется сравнить некоторое множество характеристик отдельных атрибутов. Например, пусть у нас есть отношение R₁, которое содержит номенклатуру всех выпускаемых деталей на нашем предприятии, а в отношении R₂ хранятся сведения о том, что и в каких цехах действительно выпускается. Поставим задачу определить перечень цехов (R₃₎, в которых выпускается вся номенклатура деталей.

Тогда решением этой задачи будет операция деления отношения R₂ на отношение R₁ по набору атрибутов (Шифр детали, Наименование детали).

R₃ ⁼ R₂[Шифр детали, Наименование детали: Шифр детали, Наименование детали] R₁

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

В заключении можно отметить, что данные операции реализованы средствами команды Select языка запросов SQL и не используются в такой математической форме.

В 1985 году в двух статьях в журнале Computer World Э.Ф. Кодд сформулировал правила, которым должны соответствовать настоящие реляционные базы данных (содержание данного пункта скопировано из работы [19]).

Правило 0 (фундаментальное правило). Реляционная система для управления базами данных должна использовать исключительно реляционные возможности. Данное правило является очень жестким и, к сожалению, нарушается многими СУБД. Можно сказать, что правило 0 требует безусловного исполнения следующих двенадцати правил.

Правило 1 (правило информации). Вся информация в реляционной базе данных (включая имена таблиц и столбцов) представляется в явном виде только на логическом уровне и только в виде значений, хранящихся в таблицах. Отсюда кстати вытекает и условие отсутствия порядка строк и столбцов в таблицах. Информация об объектах более низкого уровня, например, индексах, должна быть исключена из модели данных.

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

Правило 3 (правило обработки неизвестных значений). В реляционной базе должна быть реализована возможность представлять неизвестные значения. Предполагается, что неизвестные значения отличаются от каких-либо определенных значений и должны быть реализованы для всех типов данных, хранящихся в базе. Данное правило провозглашает существование в реляционных базах данных значения NULL.

Правило 4 (правило доступа к словарю базы данных). Логическая структура словаря базы данных должна быть реляционной, чтобы пользователь, имеющий соответствующие права могли бы управлять структурой базы данных с помощью стандартного реляционного языка. Другими словами структура базы данных должна храниться в обычных реляционных таблицах.

Правило 5 (правило полноты языка управления данными). Должен существовать, по крайней мере, один язык управления реляционными базами данных, который поддерживал бы интерактивное и программное использование, и который должен быть представлен в виде набора команд, каждая из которых может быть представлена в виде одной строки. Такой язык должен поддерживать следующие возможности: определение структуры данных и представлений; модификацию данных; определения условий целостности, правил авторизации (идентификация прав доступа), определение границ транзакций. Важным требованием к языку является то, что команды этого языка должны представляться в виде только одной строки.

Правило 6 (правило обновления представлений). Все представления, которые теоретически можно обновить, должны быть обновляемы.

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

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

Правило 9 (правило независимости на логическом уровне). Прикладное программное обеспечение не должно зависеть от изменений, вносимых в структуру базы данных, которые теоретически не должны изменять хранящиеся в базе данные. Например, добавление в таблицу нового столбца не может сказаться на функционировании прикладных программ, так как доступ к данным осуществляется по именам столбцов. Порядок столбцов не может влиять на доступ к данным.

Правило 10 (правило независимости условий целостности). Должна существовать возможность формулировки правил целостности специфических для данной базы данных на языке реляционных баз данных.

Правило 11 (правило независимости распространения). База данных может быть распределенной или переносится на другие компьютеры и это не должно сказаться на функционировании прикладного программного обеспечения.

Правило 12 (правило единственности). Если в реляционной системе имеется низкоуровневый язык, то должна отсутствовать возможность использование его для того, чтобы обойти правила и условия целостности, сформулированные на реляционном языке и хранящиеся в каталоге базы данных.

Таким образом, если коротко, то реляционная база данных представляет собой набор взаимосвязан­ных двухмерных таблиц (отношений).

Таблица соответствует одному объекту и состоит из фиксированного числа колонок (доменов или по­лей) и строк (кортежей или записей, кото­рые соответствуют экземплярам объекта). Значения в одной колонке имеют один тип. В реляционной модели можно описывать иерархические и сете­вые связи.

Достоинства: простота (вместо фай­­лов самой разной структуры с различным числом полей в записях ис­поль­зуются простые двумерные таблицы) и гибкость (она не является жесткой, так как связь между табли­ца­ми‑объектами может устанав­ли­вать­ся не до выполнения прикладных прог­­рамм, а во время их выполнения, т.е. не нужно ждать окончания про­ек­ти­ро­вания логической модели, а раз­ра­ба­ты­вать прикладные програм­мы одновременно с процессом создания ло­ги­чес­кой модели, и изменение ло­ги­ческой модели не влечет за собой необхо­ди­мости корректировки всех прикладных программ).

Недостаток: более низкая скорость доступа к данным. Но если учесть, что быстродействие компьютеров и дисковых устройств постоянно и очень быстро растет, то этот недостаток не является сущест­вен­­ным.

Практически все современные СУБД (Oracle (Oracle), Access, MS SQL Server, Visual FoxPro (Microsoft), Interbase (Borland) и др.) являются реляционными.

Дата добавления: 2014-12-10