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

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

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

Таблица 2.4

Пример отношения

Фамилия и инициалы

Курс

Группа

Специальность

Аверчук Л. Д

1

105

Банковское дело

<- Кортеж 1

Невойда0. М

1

105

Банковское дело

<- Кортеж 2

Певец П. Б

2

203

Банковское дело

<- Кортеж 3

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

Таблица 2.5

Эквивалентная терминология реляционной модели

Терминология реляционной модели

Терминология программиста

Терминология пользователя

Отношение

Файл

Таблица

Кортеж

Запись

Строка

Атрибут

Поле

Столбец

Чтобы двумерная таблица была отношением, она должна удовлетворять определенные ограничения. Во-первых, значения в ячейках таблицы должны быть одиночными. Все записи в столбце должны быть одного типа. Например, если третий столбец первой строки таблицы содержит номер группы, тогда и в других строках таблицы третий столбец также должен содержать номер группы. Каждый столбец должен иметь уникальное имя. Наконец, в отношении не может быть двух одинаковых строк. Обобщенный формат отношение - студент (фамилия и имя, Курс, Группа, Специальность) - называется структурой отношения.

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

Для понимания понятия "нормализация" надо прежде всего определить два важных термина: функциональная зависимость и ключ.

Функциональная зависимость - это связь между атрибутами. Допустим, если нам известно значение одного атрибута, тогда можем найти значение другого атрибута. Например, если нам известен номер счета клиента, тогда мы можем определить состояние этого счета. В таком случае мы можем сказать, что атрибут СтанРахункуКлиента функционально зависит от атрибута Номер счета Клиента. Иными словами, если нам известно значение X, мы можем определить значение Y. Функциональные зависимости значки: НомерСтудента -> Специальность.

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

В функциональные зависимости могут быть включены группы атрибутов. Рассмотрим отношение Оценки (НомерСтудента, Дисциплина, оценка). Функциональная зависимость (НомерСтудента, Дисциплина) -> Оценка определяет оценку студента по дисциплине.

Ключ (key) - это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку. Рассмотрим отношение Секция, которое имеет атрибуты НомерСтудента, Секция, плата (табл. 2.6).

Таблица 2.6

Отношение Секция

НомерСтудента

Секция

Плата

10701

Борьба

70

15002

Плавание

45

20003

Гимнастика

80

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

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

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

Для понимания сути аномалии модификации снова рассмотрим отношение Секция (см. Табл. 2.6). Если мы удалим строку, в которой записаны данные о студенте с номером 10701, то не только потеряем информацию о том, что студент с номером 10701 является борцом, но и тот факт, что абонемента секцию борьбы стоит 70 грн. Это называется аномалией удаления - то есть, изымая факты по одной сущности (студент с номером 10701 является борцом), мы изымаем факты относительно другой сущности (плата за абонемент в секцию борьбы). Выполнив одну операцию удаления, мы теряем информацию о двух сущности.

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

Мы можем ликвидировать как аномалию изъятия, так и аномалию вставки, разделив отношение Секция на два отношения, каждое из которых будет иметь информацию относительно определенной темы. Например, на первое отношение мы включим атрибуты НомерСтудента и Секция (назовем это отношение Студент / Секция), а в другое - атрибуты Секция и плата (назовем это отношение Секция / Плата). Эти два отношения данным из нашего примера отражены в табл. 2.7,2.8.

Таблица 2.7 Студент / Секция (НомерСтудента, Секция)

НомерСтудента

Секция

10701

Борьба

15002

Плавание

20003

Гимнастика

Таблица 2.8 Секция / Плата (Секция, плата)

Секция

Плата

Борьба

70

Гимнастика

80

Плавание

45

Теперь, если мы удалим запись о студенте с номером 16002 с таблицы Студент / Секция, мы уже не потеряем тот факт, что абонемент в секцию Плавание стоит 45 грн. Более того, мы можем добавить в таблицу Секция / Плата секцию Теннис с указанием стоимости абонемента, не дожидаясь, пока кто-то запишется в эту секцию. Таким образом, аномалии изъятия и вставки ликвидированы.

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

Есть пять основных форм нормализации отношений (от 1NF к 5NF). Каждая следующая ликвидирует один из видов избыточных данных. На практике нормальные формы 4NF и 5NF используют крайне редко.

Первая нормальная форма (1NF) закладывает основы реляционной системы. При первой нормальной формы все атрибуты отношения являются простыми. В 1NF на пересечении строки и столбца значения не могут повторяться, то есть не могут располагаться несколько значений. В табл. 2.9 Клиенты / Арендаторы приведены базу данных без нормализации, ключевым атрибутом которой является Код_клиента. На пересечении строк и столбцов табл. 2.9 содержится несколько значений, а именно: два значения (РА4 и РА5) в ячейке Код_ объекта; два значения в ячейке Адрес тому подобное. Значениями повторяющихся называются значения, образуются из одного и более атрибутов таблицы и определяются ключевым атрибутом таблицы. Таким образом, структура повторяющихся значений, для табл. 2.9 есть. такой Значение повторяющихся (Код_обьекта, адрес, Початкова_дата, Кинцева_дата, Сума_оренды, Код_власника, Имя ^ владельца).

Таблица 2.9 ненормализованное таблица Клиенты / Арендаторы

Код клиента

Имя клиента

Код объекта недвижимости

Адрес объекта

Начальная дата

аренды

Конечная

дата аренды

Арендная плата

Код владельца

Имя владельца

R76

Волк Б. волк Б.

РА4 РА5

Львов, ул. Панча, 26 Стрый, ул. Коперника, 1

1.06.2002 1.08.2002

31.12.05 31.12.06

4000 5800

С040 С039

Лескив В. Ващук С.

Савчук Д.

PA 8

Львов, ул. Панча, 26

1.07.2002

15.07.2004

3900

С040

Лескив В.

R77

Савчук Д.

PA9

Стрый, ул. Стуса, 12

1.09.2002

31.08.2007

6700

С039

ВащукС.

Савчук Д.

РАЯ

Львов, ул. Зеленая, 98

1.04.2002

31.05.2006

4700

С041

Мазур X.

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

• изъятие повторяющихся значений, посредством введения в каждую строку соответствующих сведений о клиенте. Первичным ключом этого отношения выберем группу (Код_клиента и Код_ объекта) и расположим атрибуты этого первичного ключа рядом, слева в отношении (табл. 2.10);

• изъятие повторяющихся значений, и перемещения их в другое отношение вместе с копией ключевого атрибута Код_ клиента (табл. 2.1 1, 2.12).

Таблица 2.10

Первая нормальная форма таблицы Клиенты / Арендаторы

Код клиента

Код объекта недвижимости

Имя клиента

Адрес объекта

Начальная дата

аренды

Конечная дата аренды

Арендная плата

Код владельца

Имя владельца

R76

РА4

Волк Б.

Львов, ул. Панча, 26

1.06.2002

31.12.05

+4000

С040

Лескив В.

R76

РА5

Волк Б.

Стрмй, ул. Коперника, 12

1.08.2002

31.12.06

5 800

С039

Ващук С.

R77

РА8

Савчук Д.

Львов, ул. Панча, 26

1.07.2002

15.07.04

3900

С040

Лескив В.

R77

РА9

Савчук Д.

Стрый, ул. Коперника, 12

1.09.2002

31.08.07

6700

С039

Ващук С.

R77 п.

РАЯ

Савчук Д.

Львов, ул. Зеленая, 98

1.04.2002

31.05.06

4700

С041

Мазур X.

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

Используя второй подход нормализации, значения, повторяющиеся (сведения о арендованные объекты недвижимости), извлекается из отношения, нормализуются, и вносят в иное отношение вместе с копией входного ключевого атрибута (табл. 2.11). Остаток атрибутов входного отношение приведены в табл. 2.12. Первичными ключами для отношения Код_обьекта / Арендатор будет Код_клиента и Код_обьекта, а для отношения Клиенты - первичный ключ Код_клиента

Таблица 2.11

Альтернативное представление первой нормальной формы -_видношення Код_ объекта / Арендатор

Код клиента

Код объекта

Адрес объекта

Начальная дата аренды

Конечная дата аренды

Арендная плата

Код владельца

Имя владельца

R76

РА4

Львов, ул. Панча, 26

1.06.2002

31.12.2005

+4000

С040

Лескив В.

R76

РА5

Стрый, ул. Коперника, 12

1.08.2002

31.12.2006

5 800

С039

Ващук С.

R77

РА8

Львов, ул. Панча, 26

1.07.2002

15.07.2004

3900

С040

Лескив В.

R77

РА9

Стрый, дядю. Коперника, 12

1.09.2002

31.08.2007

6700

С039

Ващук С.

R77

РАЯ

Львов, ул. Зеленая, 98

1.04.2002

J 31.05.2006

4700

С041

Мазур X.

Таблица 2.12

Альтернативное представление первой нормальной формы - отношение Клиенты

Код_клиента

Имья_клиента

R76

Волк Б.

R77

Савчук Д.

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

Для демонстрации дальнейшего процесса нормализации отношений с переходом от 1NF к 2NF будем использовать только отношение Клиенты / Арендаторы (см. Табл. 2.10).

Вторая нормальная форма основана на понятии полной функциональной зависимости.

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

Во второй нормальной форме все атрибуты отношения просты и каждый неключевой атрибут функционально полно зависит от ключа. Для иллюстрации рассмотрим такую функциональную зависимость: Призвище_студента. Предмет -> Оценка. Здесь каждая пара значений Призвище_студента и

Предмет связана с единственным значением Оценка. Эта функциональная зависимость является полной, поскольку Оценка не может быть определена отдельно по фамилии или по Предметом. В функциональной зависимости Код-сотрудника Имя сотрудника -> Код_пидроздилу каждая пара значений также связана с единственным значением Код_пидроздилу. Однако эта функциональная зависимость не является полной, поскольку Код-пидроздилу также функционально зависит от атрибута Код_спивробитника.

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

На рис. 2.18 показано функциональные зависимости для отношения Клиенты / Арендаторы (см. Табл. 2.10) с первичным ключом (Код_клиента, Код_обьекта). Линия со стрелкой указывает на функциональеом зависимость указанного реквизита от реквизита замеченного линией без стрелки. После выявления функциональных зависимостей процесс нормализации отношения Клиенты / Арендаторы продолжается проверкой его принадлежности ко второй нормальной форме. Для этого нужно найти по крайней мере один случай частичной зависимости от первичного ключа. Нетрудно заметить, что атрибут имья_клиента частично зависит от первичного ключа, то есть он зависит только от атрибута Код_клиента (эта зависимость представлена как Ф32). Кроме того, атрибуты объекта недвижимости (Адреса__обьекта, Орендна_плата, Код__ владельца, Имья_власника) также частично зависят от первичного ключа, но в этом случае только от атрибута Код_обьекта (эта зависимость представлена как ФЗЗ).

Функциональные зависимости отношение Клиенты / Арендаторы

Рис. 2.18. Функциональные зависимости отношение Клиенты / Арендаторы

В свою очередь, атрибуты арендованных объектов недвижимости (Начальная дата, Конечная дата) полностью функционально зависят от первичного ключа в целом (эта зависимость представлена как ф31). Таким образом, отношению Клиенты / Арендаторы присущи функциональные зависимости ф31-Ф36 (табл. 2.13).

Таблица 2.13

Функциональные зависимости отношение Клиенты / Арендаторы

Функциональные зависимости

Формат отношение

Зависимость

ФЗИ

Код_клиента, Код_обьекта -> Начальная дата аренды. Конечная дата аренды

Первичный ключ

Ф32

Код_клиента -> Имя клиента

Частичная зависимость

ФЗЗ

Код_обьекта -> Адрес объекта, Арендная плата, Код владельца, Имя владельца

Частичная зависимость

Ф34

Код владельца -> Имя владельца

Транзитивная зависимость

Ф35

Код_клиента, Начальная дата аренды -> Код объекта Адрес объекта, Конечная дата аренды, арендная плата, Код владельца, Имя владельца

Потенциальный КЛЮЧ

Ф36

Код_обьекта, Начальная дата аренды -> Код клиента, Имя клиента, Конечная дата аренды

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

Выявление частичных зависимостей внутри отношение Клиенты / Арендаторы означает, что отношения не содержится во второй нормальной форме. Для преобразования отношение Клиенты / Арендаторы в 2NF следует создать новые отношения, причем так, чтобы атрибуты, которые не входят в первичного ключа, были перемещены в них вместе с копией части первичного ключа, от которой они функционально зависят. Использование этого правила в нашем варианте приведет к созданию трех новых отношений - Клиенты, Обьекти_оренды, Арендаторы, которые представлены в табл. 2.14,2.15, 2.16 соответственно.

Таблица 2.14

Отношение Клиенты

Код_клиента

Имья_клиента

R76

Волк Б.

R77

Савчук Д.

Таблица 2.15

Отношение Обьекти_Оренды

Код клиента

Код объекта

Начальная дата аренды

Конечная дата аренды

R76

РА4

1.06.2002

31.12.2005

R76

РА5

1.08.2002

31.12.2006

R77

РА8

1.07.2002

15.07.2004

R77

РА9

1.09.2002

31.08.2007

R77

РАЯ

1.04.2002

31.05.2006

Таблица 2.16

Отношение Арендаторы

Код

объекта

Адрес

объекта

Арендная

плата

Код

владельца

Имя

владельца

РА4

Львов, ул. Панча, 26

+4000

С040

Лескив В.

РА5

Стрый, ул. Коперника, 12

5 800

С039

Ващук С.

РА8

Львов, ул. Панча, 26

3900

С040

Лескив В.

РА9

Стрый, ул. Коперника, 12

6700

С039

Ващук С.

РА10

Львов, ул. Зеленая, 98

4700

С041

Мазур X.

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

В третьей нормальной форме все атрибуты отношения просты и каждый неключевой атрибут функционально полно зависит от ключа, причем каждый неключевой атрибут нетранзитивно зависит от ключа. Хотя 2NF-eidHouteHHK) в меньшей степени присуща избыточность данных, чем lNF-отношению, они еще могут страдать от аномалий обновления. Так, при попытке обновления имени владельца недвижимости, например, Лескив С.В. с кодом С040, надо будет восстановить две строки отношение Арендаторы (см. табл. 2.16). Если восстановить только один из этих двух строк, то база данных трапляе в противоречие. Эта аномалия обновления объясняется транзитивной зависимостью - если для атрибутов А, В и С некоторого отношения существуют зависимости вида А-> В и В-> С, тогда говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В, при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С.

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

Таким образом, нормализация 2NF-eidnouienb с образованием 3NF-eidno-шень предусматривает изъятие транзитивных зависимостей. Если в отношении существует транзитивная зависимость между атрибутами, транзитивно-зависимые атрибуты изымаются из него и перемещаются в новое отношение вместе с копией их детерминант.

Для выполнения таких действий сначала рассмотрим функциональные зависимости в отношениях Клиенты, Объекты) _оренды и Арендаторы. Отношение Клиенты

Ф32 Код клиента-> Имя клиента Отношение Объекты аренды

Ф31 Код клиента, Код объекта-> Начальная дата аренды, Конечная дата аренды

Ф35 Код клиента, Начальная дата аренды -> Код объекта. Адрес объекта, Конечная дата аренды, арендная плата, Код владельца, Имя владельца

Ф36 Код объекта Начальная дата аренды -> Код клиента, имья клиента, Конечная дата аренды Отношение Арендаторы

ФЗЗ Код объекта -> Адрес объекта, Арендная плата, Код владельца, Имя владельца

Ф34 Код владельца Имя владельца

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

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

Для преобразования отношение Арендаторы в третье нормальную форму нужно прежде всего исключить транзитивных зависимость путем создания двух новых отношений Довидник_обьектив_оренды Довидник_Орендари, которые приведены в табл. 2.17, 2.18.

Таблица 2.17

Довидник_ обьектив_ аренды

Код объекта

Адрес объекта

Арендная плата

Код владельца

РА4

Львов, ул. Панча, 26

+4000

С040

РА5

Стрый, ул. Коперника, 12

5 800

С039

РА8

Львов, ул. Панча, 26

3900

С040

РА9

Стрый, ул. Коперника, 12

6700

С039

РА10

Львов, ул. Зеленая, 98

4700

С04И

Таблица 2.18

Довидник_Орендари

Код владельца

Имя владельца объекта

С040

Лескив В.

С039

Ващук С.

С041

Мазур X.

Таким образом, в результате выполнения нормализации входящее отношение (см. Табл. 2.10) было преобразовано в четыре отдельные отношения (см. Табл. 2.14, 2.15, 2.16,2.17), каждое из которых в третьей нормальной форме. На рис. 2.19 приведена схема процесса преобразования, которая объясняет, как lNF-отношение было преобразовано в четыре 3№-отношения.

Схема декомпозиции lNF-отношение Клиенты

Рис. 2.19. Схема декомпозиции lNF-отношение Клиенты / Арендаторы на четыре отношение в третьей нормальной форме

Дальнейшая нормализация отношений может привести к получению новых отношений в четвертой и пятой нормальных формах.

 
< Пред   СОДЕРЖАНИЕ   След >