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

Основные понятия

Длительное время до появления реляционных БД на практике пре­обладали иерархические и сетевые модели.

Считается, что впервые наиболее полное изложение реляционной модели сформулировал Е.Ф. Кодд в начале 70-х гг. [24, 38, 64]. К этому времени ста­ло ясно, что при сложных структурах данных реализация новых запросов или введение новых логических связей в сетевых или иерархических БД требует довольно существенных доработок программного обеспечения. Указанный недо­статок обусловлен тем, что в этих БД выбор необходимых записей производится с использованием указателей, через которые связаны записи. Предположим, что исходная иерархическая или сетевая БД содержит сведения о товарах, их ценах в разных поставках и информацию о производителях товаров, причем в графе исходной структуры данных нет пути между вершинами, сопоставленными про­изводителям и их ценам товаров. Тогда при необходимости выбора из БД сведе­ний о ценах товаров указанного производителя придется выполнить несколько

279

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

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

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

Базы данных, объектами которых являются связанные определенным образом таблицы, называют реляционными (от relation - связь, отношение). В реляционной БД таблицы (реляции) должны удовлетворять определенным требованиям.

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

2. Столбцы должны размещаться в произвольном порядке, а данные каждого столбца должны быть однотипными.

3. Каждый столбец должен быть уникальным (недопустимо дублирование столбцов) и иметь уникальное наименование.

4. Строки размещаются в таблице в произвольном порядке.

Связанные отношениями таблицы взаимодействуют по принципу главная (master) - подчиненная (detail). Например, если имеются две таблицы, в одной из которых указаны наименования фирм таможенных брокеров и сведения об оформленных через них ГТД за некоторый период времени, а в другой - све­дения о каждом таможенном брокере (адрес, номер и дата выдачи лицензии), то первая будет главной, а вторая - подчиненной. Часто главную таблицу называ­ют родительской, а подчиненную - дочерней. Одна и та же таблица может быть главной по отношению к одной таблице БД и дочерней по отношению к другой.

280

В теории реляционных БД используется специфическая терминология. В таблице 5.3 приведены основные термины, используемые при работе с реляционными БД.

Таблица 5.3

Основные термины реляционной модели

Элемент модели	Определение
Отношение или реляция	Таблица
Атрибут	Столбец таблицы
Имя атрибута	Заголовок столбца таблицы
Кортеж	Совокупность значений строки таблицы
Домен	Совокупность значений в столбце
Область атрибута	Множество, из которого берутся значения атрибута

Пусть таблица-отношение R (рис. 5.16) содержит столбцы (атрибуты) с име­нами Aj, А₂,..., А_п.

Рис. 5.16. Структура реляционной таблицы-отношения R

Множество значений атрибутов в j-м столбце образуют домен, а множество значений атрибутов в i-й строке образуют кортеж К..

Значение атрибута А. в клетке на пересечении i-й строки и j-ro столбца обоз­начим через а_н.Тогда отношение R образуется множеством упорядоченных кор­тежей:номер кортежа^ = 1,2,..., п - номер домена.

В таблице 5.4 приведен пример реляции (таблицы), названной «Таможен­ный брокер», которая включает три домена и четыре кортежа. Домен 1 содер­жит наименование организации, домен 2 - номер лицензии, домен 3 -регион деятельности таможенного брокера. Каждый домен имеет по 4 значения, а каж­дый кортеж состоит из трех элементов.

281

Таблица 5.4

Отношение «Таможеный брокер»

Ключи

В реляционных БД, как и в других типах БД, для поиска нужных дан­ных используются ключи.

Первичным ключом называют один или несколько атрибутов отношения, однозначно идентифицирующих каждый из кортежей отношения.

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

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

Как и в БД с рассматривавшимися выше моделями данных, в реляционной БД ключ называется простым, когда он состоит из одного атрибута, или состав­ным, когда он состоит из нескольких атрибутов.

Таблица 5.4 «Таможенный брокер» является примером отношения, для которого первичный ключ состоит из двух атрибутов, т.е. является составным. При этом возможны два варианта первичного ключа: атрибуты «Наименова­ние организации» и «Регион деятельности» либо «Номер лицензии» и «Реги­он деятельности». Если задать какой-нибудь из возможных номеров лицензии и название организации, то в таблице найдется не более одной строки с заданны­ми значениями.

Вторичный ключ - это такой ключ, значения которого могут повторяться в нескольких строках-кортежах.

Он используется для того, чтобы выбирать из таблицы несколько строк, удовлетворяющих заданному значению вторичного ключа. Например, чтобы из табл. 5.2 выбрать фамилии сотрудников, занимающих определенную должность, в качестве вторичного ключа следует взять атрибут «Должность».

282

Таким образом, ключ будет вторичным, если хотя бы одному из его значений соответствуют две или более строки. Заметим, что некоторым значениям вто­ричного ключа может соответствовать всего одна строка.

Так, для табл. 5.4 любой отдельный атрибут будет вторичным ключом. Напри­мер, если задать значение атрибута «Номер лицензии» равным 107000/0003, в таблице будут найдены две строки с этим значением.

Нормализация таблиц-отношений

В реляционных БД существует также понятие внешнего ключа, с помощью которого устанавливаются связи между таблицами, т.е. такой ключ позволяет извлечь данные сразу из нескольких таблиц. Пусть имеется БД из трех таблиц, содержащая информацию о предприятиях-брокерах (на рис. 5.17 показаны только атрибуты этих таблиц). Составной ключ из атрибутов «Лицен­зия» и «ИНН» является внешним ключом для этой БД. Информация о пред­приятиях распределена по трем таблицам. Однако если задать значения лицен­зии и ИНН некоторого предприятия (т.е. задать значение внешнего ключа), то из других таблиц БД будет извлечена вся имеющаяся информация по соот­ветствующему предприятию.

Для обеспечения целостности реляционной БД обычно требуется, чтобы внешний ключ некоторой таблицы, связь с которой устанавливается, являлся первичным для нее.

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

Рис. 5.17. Применение внешних ключей для связи отношений

Для обеспечения вышеуказанных свойств производится нормализация исходных таблиц, позволяющая устранить избыточность, обеспечить целост­ность и однократность ввода данных, исключить неоднозначность при их обра­ботке [24, 64].

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

283

Выделяют следующие формы нормализованных таблиц:

• первая нормальная форма (1НФ);

• вторая нормальная форма (2НФ);

• третья нормальная форма (ЗНФ);

- усиленная третья нормальная форма или нормальная форма Бойса-Кодда (БКНФ);

• четвертая нормальная форма (4НФ);

• пятая нормальная форма (5НФ).

Обычно при создании реляционной БД ее таблицы достаточно привести к третьей нормальной форме (ЗНФ или БКНФ).

При первой нормальной форме все атрибуты отношения должны быть про­стыми, т.е. иметь единственное значение в каждой строке.

Так, например, если фирма продает ЭВМ в двух вариантах исполнения и в прайс-листе, представленном в виде таблицы, столбец в строке с информацией о ЭВМ содержит обозначения сразу обоих вариантов, то таблица является ненор­мализованной, поскольку приводит к неоднозначности выполнения запросов. Преобразование к первой нормальной форме обычно приводит к представлению такой строки в виде нескольких строк или даже требует введения дополнитель­ных таблиц. При нормализации стараются обеспечить неделимость значений атрибутов, которая означает, что содержащиеся в клетках таблицы значения не должны делиться на более мелкие. Например, если в строке некоторой таблицы атрибут содержит одновременно фамилию, имя и отчество сотрудника, следует разделить его на три атрибута - отдельно для фамилии, имени и отчества.

При второй нормальной форме все атрибуты отношения удовлетворяют требованиям ШФ и каждый неключевой атрибут функционально полно зави­сит от ключа. Атрибут А функционально зависит от атрибута В, если каждому значению А соответствует только одно значение В, т.е. во всех кортежах с одним и тем же значением атрибута А атрибут В также имеет одно и то же значение (записывается: А - > В). Если атрибут находится в функциональной зависи­мости от части составного ключа, то такая зависимость называется частичной. Полная функциональная зависимость означает, что ключ однозначно опреде­ляет неключевой атрибут и одному значению ключа соответствует только одно значение неключевого атрибута. Если ключ составной, то подобная зависимость должна выполняться на уровне всего ключа, а не какой-либо его части.

При третьей нормальной форме выполняются требования 1НФ и 2НФ, а каждый неключевой атрибут нетранзитивно зависит от ключа. Атрибут С зависит от атрибута А транзитивно, если для атрибутов А, В и С выполняются условия:

А->ВнВ->С.

Недостатком БД с нормализованными таблицами является то обстоятель­ство, что чем больше атрибутов требуется для описания предметной области, тем из большего числа таблиц будет состоять нормализованная БД, которые для больших систем могут содержать сотни объектов. Их одновременный анализ с учетом взаимосвязей человеку осуществить трудно, поскольку с увеличени-

284

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

Типы полей

Поля - это основные элементы физической модели БД. Для хране­ния данных в каждой клетке таблицы отводится некоторое поле.

Одной из основных характеристик любого поля является его длина (выража­ется в символах или в знаках), т.е. количество единиц памяти ЭВМ, занимаемых полем. От длины поля зависит, сколько данных (символов) или какой величины число в нем сможет разместиться. Обычно длина поля измеряется в байтах.

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

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

1. числовое поле служит для ввода числовых данных. Его длина и способ (формат) представления зависят от типа числа: целое, с плавающей запятой и др.;

2. поле для ввода дат или времени;

3. логическое поле предназначено для ввода логических данных, имеющих только два значения («Да» или «Нет»; «О» или «1» и т.п.). Длина этого поля всег­да равна 1 байту, что достаточно для выражения логического значения;

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

5. поле объекта OLE (Object Linking and Embedding - связывание и внед­рение объектов) используется для хранения картинок, музыкальных клипов и видеоданных;

6. поле MEMO используется для хранения длинного текста (до нескольких тысяч символов). Особенность поля MEMO состоит в том, что реально в поле хранятся не данные, а только указатель места, где расположен текст;

285

7) поле Счетчик - числовое поле, но имеющее свойство автоматического наращивания. Если в базе есть такое поле, то при вводе новой записи в него авто­матически записывается число, на единицу большее, чем значение того же поля в предыдущей записи. Это поле удобно для нумерации записей.

Операции с данными реляционной модели

В своей теории построения реляционных БД В.Ф. Кодд ввел понятия реляционной алгебры и реляционного исчисления. Фактически это два языка формулирования и реализации запросов пользователя [64].

Реляционная алгебра - процедурный язык обработки реляционных таблиц, предполагающий формулирование и реализацию запросов в виде последова­тельности шагов на основе операций этой алгебры.

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

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

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

Рассмотрим основные операторы языка реляционной алгебры.

Объединение - выполняется над двумя отношениями (таблицами) и R₂ с идентичной структурой. В результате операции объединения строится новое отношение R = R, U R,. Отношение R имеет тот же состав атрибутов и совокуп­ность кортежей, как у исходных отношений. Причем в эту совокупность вклю­чается только один представитель от одинаковой пары строк исходных таблиц.

286

Пример

Пусть имеются исходные отношения R, «Данные по складу А» (табл. 5.5) и R₂ «Дан­ные но складу В» (табл. 5.6). Выполним операцию объединения R₃ = R, U R₂. Результат объединения (новая таблица R₃) показан в табл. 5.7.

Таблица 5.5

Отношение R, «Данные по складу А»

Таблица 5.6

Отношение R₂ «Данные по складу В»

Таблица 5.7

Результирующее отношение R

Хотя в исходных отношениях суммарно 8 кортежей (строк), в R₃ всего 6 строк. В новом отношении R₃ одинаковые кортежи К_]2 и К₂₁ представлены одним кортежем К₃₂, а одинаковые кортежи К_и и К₂₂ - кортежем К₃₄.

287

Пересечение - выполняется над двумя отношениями R, и R₂. Результирую­щее отношениесодержит одинаковые кортежи исходных таблиц (без дубликатов), и они имеет тот же состав атрибутов.

Пример

Выполним пересечение двух отношений R_[ «Данные по складу А» (см. табл. 5.5) и R₂ «Данные по складу В» (см. табл. 5.6). Результат пересечения приведен в табл. 5.8.

Таблица 5.8

Кортеж	Товар	Страна-производитель	Получатель
к11	Масло	Китай	ОАО «Шанс»
к12	Сахар	Куба	ООО «Петров и К»

Операция пересечения дала новое отношение, состоящее из двух кортежей. Это кор­тежи, которые содержатся в обоих пересекаемых отношениях (К₍ совпадает с корте­жами К₁₂ и К₂₁, а К₂ - с кортежами К₁₄ и К₂₂).

] Разность - выполняется над двумя совместимыми отношениями R,, R₂

с идентичным набором атрибутов. В результате операции строится новое

отношение R = R, - R₂ с тем же набором атрибутов, содержащее только те

кортежи первого отношения R₍, которые не повторяются в отношении R₂.

В рассматриваемом выше примере (см. табл. 5.5 и табл. 5.6) К₁₂=К₂₁ и К₁₄=К₂₂, поэтому в результате вычитания из R, («Данные по складу А») отношения R₂ («Данные по складу В») получено отношение, представленное в табл. 5.9 и состо­ящее из строк, входящих в R,, но не входящих в R₂.

Таблица 5.9

Результирующее отношение R = R₁ - R₂

Кортеж	Товар	Страна-производитель	Получатель
к11	Сахар	Украина	ООО «Петров и К»
к13	Чайники	Франция	ООО «Престиж»
к,3	Чайники	Китай	ООО «Корвет»

288

Произведение выполняется над двумя отношениями R1 и R2 имеющи- ми в общем случае разный состав атрибутов: (а1, а₂, ..., а_п) и (р1, р₂, .... рn)

соответственно. В результате операции образуется новое отношение

R = R1 х R₂, которое включает все атрибуты исходных отношений (а1, а₂

аn, р1, р₂,..., рn). Результирующее отношение состоит из всевозможных соче- таний по два кортежа исходных отношений R, и R₂. Операция аналогична

операции декартова произведения элементов двух множеств.

Пример

Пусть отношение R1 представлено в табл. 5.10, a R₂ - в табл. 5.6. Таблицы отношений R1 и R₂ содержат по три строки, поэтому после выполнения операции произведения R = R1 х R₂ будет получено отношение из 9 строк (табл. 5.11). При этом количест­во столбцов будет равно суммарному числу столбцов исходных отношений - 5 (без столбца с номерами кортежей).

Возможно, что исходные R1 и R₂ будут содержать одинаковые атрибуты (столб­цы). Тогда оба столбца войдут в результирующее отношение, но одному из них надо будет изменить имя.

Таблица 5.10

Кортеж	№ контракта	Стоимость по контракту ($)
к1	11	120 ООО
к2	12	500 000
К3	13	800 000

Отношение R₁

Кор­теж	Товар	Страна-произво­дитель	Получатель	№ конт­ракта	Стоимость по контракту ($)
к1	Масло	Китай	ОАО «Шанс»	11	120 000
К2	Сахар	Куба	ООО «Петров и К»	12	500 000
к.3	Яблоки	США	ООО «Престиж»	13	800 000
к4	Масло	Китай	ОАО «Шанс»	13	800 000
К5	Сахар	Куба	ООО «Петров и К»	11	120 000
к6	Яблоки	США	ООО «Престиж»	12	500 000
к7	Масло	Китай	ОАО «Шанс»	12	500 000
к8	Сахар	Куба	ООО «Петров и К»	13	800 000
к3	Яблоки	США	ООО «Престиж»	11	120 000

Операция произведения, как правило, используется в сочетании с другими операциями.

Выбор - выполняется над одним отношением R, из которого по заданно­му условию (предикату) осуществляется выборка подмножества кортежей. Результирующее отношение имеет ту же структуру, но число его кортежей

будет меньше или равно исходному.

Пример

Из таблицы 5.5 выбираются кортежи, содержащие информацию о товарах, получае­мых ООО «Петров и К». В результате выполнения операции будет получено отно­шение R1 из двух кортежей (табл. 5.12).

Таблица 5.12

Отношение R_t"

Кортеж	Товар	Страна-производитель	Получатель
k13	Сахар	Украина	ООО «Петров и К»
k14	Сахар	Куба	ООО «Петров и К»

Для выполнения данной операции надо указать атрибуты и их значения, по кото­рым будет производиться выбор. Языки СУБД для задания условий выбора допускают использование операторов сравнения: =, >, <, <, >= и их сочетаний «не=», «не >» и т.д., а также логических операторов И, ИЛИ. Их применение позволяет, например, выбирать из таблицы строки, в которых некоторый атрибут больше заданного значения.

Проекция - выполняется над одним отношением R.

Если операцию выбора можно рассматривать как операцию удаления ненуж­ных строк, то проекцию - как удаление ненужных столбцов. Операция фор!МИ-рует новое отношение, содержащее только заданное подмножество атрибутов, являющееся частью исходного отношения R. Оно может содержать меньше кор­тежей, так как после отбрасывания части атрибутов и возможного исключения при этом первичного ключа могут образоваться кортежи, дублирующие друг друга, которые должны быть исключены.

Пример

Пусть исходным является отношение R3, представленное в табл. 5.7. Необходимо определить его проекцию на два атрибута - «Товар» и «Получатель». В полученном отношении R₃' (табл. 5.13) будет два атрибута, но только пять строк, так как в исход­ных кортежах К₃₁ и К₃₄ заданные атрибуты имеют одинаковые значения.

290

Таблица 5.13

Результирующее отношение R₃"

Товар	Получатель
Сахар	ООО «Петров и К»
Масло	ОАО «Шанс»
Чайники	ООО «Престиж»
Чайники	ООО «Корвет»
Яблоки	ООО «Престиж»

Соединение - выполняется для заданного условия соединения над двумя логически связанными отношениями. Исходные отношения R, и R₂ имеют разные структуры, в которых есть одинаковые атрибуты - внешние ключи.

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

Деление - выполняется над двумя отношениями R,h R₂, имеющими в общем случае разные структуры и некоторые одинаковые атрибуты. В итоге завер­шения операции образуется новое отношение, структура которого полу­чается исключением из множества атрибутов отношения R, и отношения R₂. Результирующие строки не должны содержать дубликаты. Возможны несколько вариантов этой операции.

Рассмотренные выше операции в той или иной мере реализуются в средствах СУБД, обеспечивающих обработку реляционных таблиц. К таким средствам относятся средства запросов и другие языковые конструкции.

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

Реляционные модели имеют ряд достоинств, к которым относятся простота представления данных, минимальная избыточность данных при нормализации отношений. Кроме того, в них обеспечивается независимость приложений поль-

291

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

Недостатком реляционной модели является то обстоятельство, что нормали­зация ее данных приводит к значительной их фрагментации, тогда как во многих реальных задачах необходимо объединение фрагментированных данных.

К числу реляционных баз относятся Dbase фирмы dBASE Inc., FoxPro фир­мы Fox Software (затем - корпорации Microsoft), Clipper корпорации Nantucket (затем - Computer Associates), Paradox фирмы Borland (затем - фирмы Corel), DB2 корпорации IBM, Rdb/VMS корпорации Digital Equipment, ORACLE кор­порации Oracle, SYBASE компании Sybase Inc., Microsoft Access корпорации Microsoft и др.,

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

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

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

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

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

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

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

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

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

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

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

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

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

292

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

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