Реляционный подход к организации БД

Согласно Дейту, реляционная модель состоит из трех частей:

· Структурной части.

· Целостной части.

· Манипуляционной части.

Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.

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

Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными - реляционную алгебру и реляционное исчисление.

Базовые понятия реляционных баз данных

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

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

 

Таблица 2 Терминология БД.

Теория БД	Практика	SQL Server
Отношение (Relation)	Таблица (Table)	Таблица (Table)
Кортеж (Tuple)	Запись (Record)	Строка (Row)
Атрибут (Attribute)	Поле (Field)	Столбец (Column)
Домен (Domain)	Общая совокупность допустимых значений	Количество столбцов
Степень отношения	Кардинальное число отношения	Количество строк

Смысл некоторых из этих понятий приведен на рис. 7.

Ошибка! Ошибка связи.

Рис. 7.

 

Тип данных - адекватно понятию типа данных в языках программирования.

В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».

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

Например, домен "ФИО" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака).

Отношения – это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}.

Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

Степень или "арность" схемы отношения - мощность этого множества.

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

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.

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

Фундаментальные свойства отношений

1. В отношении нет одинаковых кортежей

Это следует из того факта, что тело отношения это математическое множество (множество кортежей). Множества же по определению не содержат повторяющихся элементов.

2. Кортежи не упорядочены сверху вниз

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

3. Атрибуты не упорядочены слева направо

Поэтому с точки зрения реляционной теории отношение, в котором атрибуты представлены в таком порядке: студ_билет, студ_ФИО, студ_Возраст, студ_стип и отношение, у которого атрибуты представлены в порядке студ_билет, студ_стип, студ_Возраст, студ_ФИО, будут одним и тем же отношением. Т.о. не существует первого, второго, четвертого атрибута. Атрибут всегда определяется по имени, а не по расположению. Это как раз и помогает избежать путаницы при написании программ.

4. Все значения атрибутов отношения атомарные

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

Замечание!

Но в реальной жизни бывают ситуации, когда значение атрибута не может быть представлена атомарно. Например, часто в исторических записях дата рождения иногда указывается «Не известна», или например в графе адрес прописки – «БОМЖ». Как же тогда решить проблему отсутствия информации? Кодд предложил использовать в этом случае специальные значения, которые называются NULL. Т.е. если в кортеже, в какой либо позиции атрибута встречается значение NULL, то считается, что значение атрибута отсутствует.

5. Первичные ключи

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

Первичные ключи должны удовлетворять требованиям:

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

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

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

Замечание (!) На практике выполнение первого требования обязательно. Для второго допустимо нарушение.

Правило целостности объектов (следует из требования а) и из соображений реального мира. Нельзя идентифицировать объект по значению NULL)

В первичном ключе не м.б. отношений со значением NULL!!!

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

Взаимосвязь отношений

Взаимосвязь отношений является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key). Рассмотрим пример. В БД содержатся сведения: по университету (таблица Университет), о различных кафедрах университета (таблица Кафедры), а также сведения о сотрудниках этих кафедр (таблица Сотрудники). Первичным ключом таблицы Университет является поле ИД_Универ, ИД_Сотр и ИД_Каф. Сотрудники является поле ИД_Сотр, а таблицы Кафедры – поле ИД_Каф. Таким образом, поля ИД_Сотр и ИД_Каф таблицы Университет являются внешними ключами для связи с таблицами Кафедры и Сотрудники.

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

Рис. 8. Связывание таблиц

 

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

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

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

1. Каждое значение атрибута внешнего ключа должно являться значением соответствующего потенциального ключа. Причем обратная ситуация необязательно.

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

3. Для внешнего ключа не требуется, чтобы он был компонентом первичного ключа в отношении, к которому он принадлежит. Т.о. значение во внешнем ключе могут повторяться, что не возможно для первичного ключа. Например, в одной и той же …

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

5. Для атрибутов внешнего ключа разрешается иметь значения NULL