Реляционная модель

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

7.5.3 Реляционные системы управления базой данных и их характеристики

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

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

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

Проектирование реляционной бд

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

Правила построения отношений БД по инфологической модели:

1. Если степень бинарной связи 1:1 и класс принадлежностей обоих объектов является обязательным, то требуется только одно отношение. Ключевым атрибутом этого отношения может быть ключ любого из объектов.

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

3. Если степень бинарной связи 1:1 и класс принадлежностей ни одного объекта не является обязательным, то необходимо построить 3 отношения или перейти к трем объектам от двух. Среди атрибутов третьего объекта связи должны находиться по одному ключу от связываемых объектов.

4. Если степень бинарной связи n : 1 или 1: n и класс принадлежностей n - связного объекта является обязательным, то достаточно двух отношений, по одному для каждого объекта. Ключевой атрибут 1- связного объекта добавляется к атрибуту n - связного объекта.

5. Если степень бинарной связи n : 1 или 1 : n и класс принадлежностей n - связной сущности является не обязательным, то необходимо формировать 3 отношения, по одному для каждого объекта и одно для связи. При этом отношение связи должно содержать ключи обоих объектов.

6. Если степень бинарной связи n : m, то требуется 3 отношения, по одному для каждого объекта и одно для связи. Отношение связи должно содержать ключи обоих объектов.

Эта технология решает задачу определения базовых отношений и необходимых для них атрибутов. Например:

Первый тип связи – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В (работник и его ставка.)

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

 

 

	Первый тип связи – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В (работник и его ставка.)
	Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В

 

 

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

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

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

Рассмотрим 5-ю нормальную форму.

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

Отношение находится в 1-й нормальной форме, если все домены содержат только скалярные значения.

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

Отношение находится в 3-й нормальной форме тогда и только тогда, если оно удовлетворяет определению 2НФ, и ни одно значение неключевого атрибута не зависит функционально от любого другого значения неключевого атрибута.

Если не удается перейти к 5НФ, можно ограничиться получением 3НФ. Если отношение находится в 3НФ и первичный ключ является простым, то это отношение находится и в 5НФ.

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

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

Отношения, не имеющие 2НФ, 3НФ, НФБК, 4НФ не имеют и 5НФ, т.е. не могут быть нормализованы.

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

 

№ личного дела	Класс	Фамилия	Имя	Отчество	Дата рождения
К-25	8 «Б»	Коноплев	Михаил	Александрович	13.10.83
М-20	9 «Б»	Мухин	Алексей	Вячеславович	30.03.84
У-7	8 «Б»	Украинская	Татьяна	Леонидовна	24.08.84
И-33	10 «А»	Иванова	Елена	Сергеевна	14.02.81
Ф-3	9 «Б»	Фонарева	Анастасия	Александровна	11.11.84

 

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

 На основании этой таблицы создадим базу данных школьников и назовем ее «Наша школа».

Модель данных, как и сама база данных, является объектом, имеющим свои определенные свойства. Реляционная модель базы данных имеет следующие свойства:

q                                Каждый элемент таблицы – один элемент данных.

q                                Все столбцы в таблице являются однородными, т. е. имеют один тип (числа, текст, дата и т. д.).

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

q                                Одинаковые строки в таблице отсутствуют.

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

В приведенном выше примере данные представлены в виде таблицы, которая содержит сведения об учениках школы. Раз мы хотим создать базу данных, то данной таблице необходимо присвоить имя. Пусть она называется «Школа».

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

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

q        Сортировку данных (например, по алфавиту);

q        Выборку данных по группам (например, по датам рождения или по фамилиям);

q        Поиск записей (например, по фамилиям) и т. д.

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