Банк данных (стр. 10 )

Пример 2: с помощью отношений

Р123 (учетный_№, Дата_преступления, вид_преступления, срок_заключения)

А117(учетный_№, Имя, адрес, почтовый_индекс)

А125(учетный_№, Имя, профессия, годовой_доход)

образовать отношение Q, содержащее признаки: вид_преступления и срок_заключения лиц с профессией Бухгалтер:

Q(Р123∙вид_преступления, Р123∙срок_заключения) : ∃ А125 (А125 ∙ профессия = «Бухгалтер» ∧ А125 ∙ учетный номер = Р123 ∙ Учетный_№).

Пример 3: используя отношения

Студент (№_студента, Имя_студента, прочие_сведения_о_студенте).

Преподаватель (№_преподавателя, Имя_преподавателя, прочие_сведения_о_преподавателе)

Студ_Преп(№_студента, №_преподавателя)

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

Q(Студент∙№_студента, Студент∙Имя_студента) : ∀ преподаватель ∃ ∧ Студ_Преп (Студ_преп∙№_студента = Студент ∙ №_студента ∧ Студ_Преп ∙ №_преподавателя = Преподаватель ∙ №_преподавателя).

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

Недостатком исчисления отношений является сложность его разработки. Исчисление отношений требует более высокого уровня автоматизации.

Итак, можно выделить три уровня автоматизации, применяемые в языках пользователя БД:

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

Преимущества реляционной базы (базы, заданной в третьей нормальной форме).

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

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

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

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

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

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

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

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

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

Пусть Х и У – наборы, каждый из которых объединяет одно или несколько полей файла 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

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

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

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

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

№_заказа

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

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

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

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

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

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

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

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

Рис. 30

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

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

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

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

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

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

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

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

Рис. 31