Введение в банки данных (стр. 11 )

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

d.  Секретность. Контроль секретности упрощается. Для каждого отношения задается правомерность доступа.

e.  Связность. Реляционное представление дает явную картину взаимосвязей атрибутов из различных отношений и файлов.

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

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

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

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

i.  Ясность. Логическая схема БД при изображении связей с помощью стрелок выглядит ясной, пока количество стрелок невелико.

Тема: Принципы нормализации.

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

Необходимы еще шаги нормализации.

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

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

Задавая отношение над элементами данных разработчик должен интересоваться тем, какие из атрибутов объекта являются зависимыми.

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

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

٭

Служащий (№_служащего, имя_служащего, з/пл, №_проекта, дата_окончания). Функциональные зависимости файла можно представить с помощью диаграммы.

٭

№_служащего

имя_служащего

з/пл

№_проекта

Дата_окончания

Рис. 29

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

F1 ·	F2
a	h
b	i
c	j
b	k

Итак, файл имеет два поля F1 и F2. F2 не связано функциональной зависимостью с F1, так как значению в поле F1 соответствуют два различных значения поля F2. Можно сказать, что F1 функционально зависит от F2, если наряду с имеющимися записями. На файл наложено ограничение, запрещающее вводить в него такие новые записи, как например:

F1

F2

c

k

Атрибут может зависеть не от какого – то одного атрибута, а от целой группы атрибутов.

Если Х состоит из нескольких полей, то говорят, что У находится в полной функциональной зависимости от Х тогда и только тогда, когда:

a.  У функционально зависит от Х;

b.  У функционально не зависит от любого Х’, где X’ – такое подмножество Х, что по меньшей мере одно из Х не принадлежит Х’.

Приведем простой пример файла, который иллюстрирует данное определение. Файл «Заказы» содержит поля:

№_заказа

Шифр товара {шифр, присвоенный заказанному товару}

Описание {описание товара}

Количество {заказанное количество единиц товара}

Первичный ключ этого файла состоит из двух полей №_заказа и Шифр_товара. В одиночку каждое из указанных полей не может быть ключом, так как файл может содержать по несколько записей с одинаковыми значениями №_заказа и с одинаковыми значениями Шифр_товара. Тогда как пара этих значений однозначно идентифицирует конкретную запись. Поле Количество связано полной функциональной зависимостью с полем №_заказа и Шифр_товара. Условие б) также выполняется: не исключено появление записей с повторяющимися значениями полей №_заказа и Шифр_товара, поэтому поле Количество не зависит функционально ни от того, ни от другого в отдельности. Поле Описание не находится в полной функциональной зависимости от ключа №_заказа, Шифр_товара.

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

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

В частности, приведем пример, демонстрирующий, как две проекции файла Зоопарки_мира:

Зоопарк	Животное	Зона_обитания
Москва	Кенгуру	Австралия
Москва	Верблюд	Аравия
Стокгольм	Эму	Австралия
Стокгольм	Верблюд	Аравия

Рис. 30

proj Зоопарк, Животное(Зоопарки_мира)

proj Животное, Зона_обитания (Зоопарки_мира)

соединяясь, образуют полную декомпозицию файла Зоопарки_мира.

С другой стороны, соединение проекций

proj Зоопарк, Зона_обитания (Зоопарки_мира)

proj Животное, Зона_обитания (Зоопарки_мира)

даст следующий набор записей:

Зоопарк	Животное	Зона_обитания
Москва	Кенгуру	Австралия
Москва	Эму	Австралия
Москва	Верблюд	Аравия
Стокгольм	Кенгуру	Австралия
Стокгольм	Эму	Австралия
Стокгольм	Верблюд	Аравия

Рис. 31

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

Москва	Эму	Австралия
Стокгольм	Кенгуру	Австралия

Поэтому соединение этих проекций нельзя получить полную декомпозицию файла Зоопарки_мира.

К основным задачам реляционной теории нормализации относятся:

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

2.  Определение правил выбора одной из двух альтернативных возможностей:

·  хранить файл в его непосредственном виде или

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

Рассмотрим задачу 2.

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

Шифр_товара	Название	№_телефона
АС15	Вектор	3-15-22
ВК79	Флора	4-10-73
ВР28	Гарант	2-17-38
СР12	Вектор	3-15-22
ТА54	Вектор	3-15-22
ТС43	Гарант	2-17-38

Рис.32