Модели представления данных. Реляционная модель

 

 

 

 

 

 

 

 

 

Отношения, атрибуты, кортежи  отношения

Фундаментальным понятием реляционной  модели данных является понятие отношения. В определении понятия отношения  будем следовать книге К. Дейта. Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена>.

Имена атрибутов должны быть уникальны  в пределах отношения. Часто имена  атрибутов отношения совпадают  с именами соответствующих доменов. Отношение, определенное на множестве  доменов (не обязательно различных), содержит две части: заголовок и  тело. Заголовок отношения содержит фиксированное количество атрибутов  отношения:

Тело отношения содержит множество  кортежей отношения. Каждый кортеж отношения  представляет собой множество пар  вида <Имя_атрибута : Значение_атрибута>: таких что значение атрибута принадлежит домену

Отношение обычно записывается в виде:

,

или короче

,

или просто

.

Число атрибутов в отношении  называют степенью (или -арностью) отношения. Мощность множества кортежей отношения называют мощностью отношения.

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

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

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

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

Термины, которыми оперирует реляционная  модель данных, имеют соответствующие "табличные" синонимы:

Реляционный термин	Соответствующий "табличный" термин
База данных	Набор таблиц
Схема базы данных	Набор заголовков таблиц
Отношение	Таблица
Заголовок отношения	Заголовок таблицы
Тело отношения	Тело таблицы
Атрибут отношения	Наименование столбца таблицы
Кортеж отношения	Строка таблицы
Степень(-арность) отношения	Количество столбцов таблицы
Мощность отношения	Количество строк таблицы
Домены и типы данных	Типы данные в ячейках таблицы

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

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

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

Атрибуты не упорядочены (слева  направо). Т.к. каждый атрибут имеет  уникальное имя в пределах отношения, то порядок атрибутов не имеет  значения. Это свойство несколько  отличает отношение от математического  определения отношения. Это также  третья причина, по которой нельзя отождествить отношения и таблицы - столбцы  в таблице упорядочены. Одно и  то же отношение может быть изображено разными таблицами, в которых  столбцы идут в различном порядке.

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

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

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

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

Труднее всего дать определение  вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое  формальное определение, то оно, как  правило, или тривиально, или слишком  громоздко. Именно такая ситуация с  определением отношения в Первой Нормальной Форме (1НФ). Дать определение 1НФ сложно ввиду его тривиальности.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Целостность реляционных  данных

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

• Целостность сущностей.
• Целостность внешних ключей.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Null-значения

Основное назначение баз данных состоит в том, чтобы хранить  и предоставлять информацию о  реальном мире. Для представления  этой информации в базе данных используются привычные для программистов  типы данных - строковые, численные, логические и т.п. Однако в реальном мире часто  встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно  было бы вводить пустую строку, то что вводить вместо неизвестной даты? Ответ - пустую дату - не вполне удовлетворителен, т.к. простейший запрос "выдать список людей в порядке возрастания дат рождения" даст заведомо неправильных ответ.

Для того чтобы обойти проблему неполных или неизвестных данных, в базах  данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение - это, собственно, не значение, а некий маркер, показывающий, что  значение неизвестно.

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

Первый вариант состоит в  том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных  данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС  НЕИЗВЕСТЕН" и есть те данные, которые  нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность  на правильную трактовку таких данных. В частности, может потребоваться  написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие  при этом очевидны - не все данные становятся равноправны, требуется  дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Потенциальные ключи и  целостность сущностей

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

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

• Свойством уникальности - в отношении не может быть двух различных кортежей, с одинаковым значением .
• Свойством неизбыточности - никакое подмножество в не обладает свойством уникальности.

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

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

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

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

Это определяет следующее правило  целостности сущностей:

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Внешние ключи и их целостность

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

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

Потенциальным ключом этого отношения  может выступать пара атрибутов {"Номер поставщика", "Номер  детали"} - в таблице они выделены курсивом.

Приведенный способ хранения данных обладает рядом недостатков.

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