РЕЛЯЦИОННЫХ МОДЕЛЕЙ ДАННЫХ - ТЕОРЕТИЧЕСКИЕ ОСНОВЫ

Концепция реляционной модели принадлежит американскому ученому Е. Кодду [14,18,24].

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

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

Структуры данных реляционной модели

Реляционная таблица является основным типом структуры данных (объектом) реляционной модели. Структура этой таблицы определяется совокупностью столбцов (атрибутов).

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

Основной логической единицей обработки (поиск, выборка, сортировка, вычисления) в реляционной БД является строка таблицы.

Важнейшими свойствами реляционной таблицы являются:

· не может быть двух одинаковых строк.

· в каждой строке содержится по одному значению каждого атрибута.

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

Определения и основные понятия реляционного подхода

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

Реляционная таблица-отношение. На рис.2.4 дана в общем виде иллюст-рация реляционной таблицы-отношенияR.

Формальное определение отношения R (реляционной таблицы) опирается на представление о ее доменах Di(столбцах) и кортежах Kj(строках).

Отношением R, определенным на множествах доменов í D i ý , называется подмножество декартова произведения доменов D1* D2* .... *DN.

Рис.2.4 Иллюстрация реляционной таблицы-отношения Rразмерности n=6.

Таблица-отношение R (рис.2.4) содержит столбцы с именами атрибутов (A1, A2, ... ). Значения атрибутов d находятся в содержательной части таблицы и образуют строки и столбцы. Множество значений атрибутов в одной строке образуют один кортеж К j. Множество значений атрибутов в одном столбце образуют один домен Di.

Отношение R образуется множеством упорядоченных кортежей

Ключ таблицы-отношения. Кортежи не должны повторятся внутри таблицы-отношения и соответственно должны иметь уникальный идентификатор – первичный ключ. В общем случае ключи бывают двух видов: первичный (уникальный) ключ (ПК) и вторичный ключ (ВК)

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

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

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

Нормализация данных реляционной модели

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

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

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

· при первой нормальной форме все атрибуты отношения должны быть простыми;

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

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

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

Ниже показан пример первично нормализованной реляционной таблицы таблицы (рис.2.5)..

Существуют и более высокие формы нормализации, которые не имеют большого практического значения [18].

Если принять в качестве ключа для плановой поставки принять – идентификатор договора + идентификатор изделия, то очевидно не выполнится требование второй нормальной формы, так как атрибут Заказчик ф-полно зависит от ид. Договора, то есть от части ключа.

Если принять в качестве ключа - идентификатор договора ……

Если принять в качестве ключа - идентификатор изделия…….

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

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

Внешним ключом подчиненной таблицы-отношения (в связи) часто является вторичный ключ этого отношения или не ключевой атрибут.

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

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

Целостность базы данных. Реляционная база нормализованных данных может быть наделена свойствами поддержания целостности.

Целостность – это набор определенных правил, которые устанавливают допустимость типов, значений данных, отсутствие дублирования и обязательность значений атрибутов в разных объектах базы, а также корректность связей между таблицами.

Ссылочной целостностью считается требование обязательного наличия связанной строки главной таблицы для каждой строки подчиненной таблицы. Таким образом, внешнему значению ключа связи подчиненной таблицы всегда должна найтись запись с таким же значением первичного ключа [17]. Ссылочная целостность может поддерживаться автоматически при условии нормализации таблиц БД. Нормализация таблиц может быть обеспечена на этапе проектирования БД.

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

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

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

В таблицах этой реляционной базы данных содержатся без повторения атрибуты соответствующих объектов: ДОГОВОР (номер,дата, код заказчика, сумма по договору; ИЗДЕЛИЕ (код, наименование, ед. измерения, цена); ЗАКАЗЧИК (код, наименование, адрес, банк); ЗАКАЗ (номер договора, код изделия, минимальная партия, месяц, плановое количество, сумма поставки). На связях между таблицами указаны внешние ключи.

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