При появлении нового клиента (но договор не заключен), надо включать кортеж с нулевыми и пустыми значениями

Проблема вставки.

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

Тексты будут пустыми, а число – 0. Выборка будет неверной.

2) Проблема обновления.

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

Присутствует явная и неявная избыточность данных.

Явная

предприятие и его реквизиты появляются несколько раз;

аэропорт и его реквизиты появляются несколько раз.

Изменять значения реквизитов надо в нескольких местах.

Неявная

один и тот же тариф для одних и тех же городов; при изменении тарифа только в одном месте возникает противоречивость – где правильно?

При печати – разные тарифы для одного города.

3) Проблема удаления.

Есть Клиент, у которого только один договор. При удалении договора исчезает и Клиент.

Есть Аэропорт, в который выполнен только один рейс. При удалении рейса исчезает и Аэропорт.

3 ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ.

НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ

Корректная схема БД – схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Логическое проектирование БД – процесс разработки корректной схемы РБД.

Существуют два пути проектирования схемы БД:

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

2) синтез – компоновка схемы БД из заданных исходных зависимостей между объектами ПО.

Первый путь.

Проектирование РБД связано с теорией нормализации,

Процесс проектирования с использованием декомпозиции – процесс последовательной нормализации схем отношений.

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

Введены несколько уровней нормализации схем отношений и соответственно нормальные формы отношений 1НФ, 2НФ, 3НФ, 4НФ, 5НФ.

Эти формы подчиняются правилу вложенности по возрастанию номеров: если отношение находится в 5НФ, то оно будет соответствовать 3НФ, 2НФ, 1НФ.

Обратно: если отношение находится в 1НФ, но не в 2НФ, то оно не будет соответствовать ни 3НФ, ни 4НФ, ни в 5НФ.

Каждой НФ соответствует некоторый набор ограничений. Отношение находится в некоторой НФ, если удовлетворяет свойственному ей набору ограничений.

Основные свойства НФ:

1) каждая следующая НФ улучшает свойства предыдущей;

2) при переходе к следующей НФ свойства предыдущих НФ сохраняются.

Каждая следующая итерация соответствует НФ более высокого уровня и обладает лучшими свойствами по сравнению с предыдущими:

Для проектирования необходимо получить ответы на вопросы:

1) Из какого источника взять отношение перед началом?

2) Как распознать отношение, нуждающееся в декомпозиции?

3) Каким образом декомпозиция осуществляется?

4) Что является признаком завершения декомпозиции?

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

Нормализация основана на анализе ФЗ между атрибутами отношений.

Понятие ФЗ – фундаментальное в теории нормализации РБД.

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

Атрибут Б функционально зависит от атрибута А, если в любой момент времени каждому значению атрибута А соответствует ровно одно значение Б. (А и Б могут быть составными): А®Б

Во всех кортежах с одинаковым значением атрибута А атрибут Б также имеет одно и то же значение.

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

ФЗ определяют не текущее состояние БД, а все возможные ее состояния –отражают связи между атрибутами, которые присущи реальному объекту, моделируемому с помощью БД.

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

В реальности это невыполнимо, поэтому набор ФЗ уточняет постановщик.

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

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

Полная ФЗ - зависимость неключевого атрибута от всего ключа (составного).

Частичная (неполная) ФЗ - зависимость неключевого атрибута от части составного ключа.

Взаимно-независимые атрибуты – атрибуты, которые не зависят функционально один от другого.

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

Отношение должно быть в 1НФ даже до постановки вопроса о его разбиения.

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

При составном ключе атрибут может зависеть и от его части.

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

Преобразование, исключающее частичную зависимость атрибутов, – приведение к 2НФ.

Если таких зависимостей не было, то отношение изначально находится в 2НФ.

R1(Клиент,Груз,Город,Расстояние,Телефон,Тариф,Упаковка,Объем)

ФЗ: Клиент+Груз®Объем поставки Груз®Упаковка

Клиент®Город, Телефон, Расстояние, Тариф Город® Тариф, Расстояние

Атрибуты Город, Телефон, Тариф зависят от части Клиент составного ключа, что ведет к дублированию данных, если клиент обслуживается не один раз.

Атрибут Упаковка зависит от части Груз составного ключа, что ведет к дублированию данных, если есть несколько одинаковых грузов.

Избыточность:

изменение любого из этих атрибутов требует менять его во всех кортежах для данного клиента;

невозможно хранить клиента без поставок;

невозможно хранить груз без клиента.

S1(Аэропорт,ТипВС,УЕ ЗаПасс,Тариф,ДУ,ПассВм,Тяга,Билеты)

ФЗ: Аропорт+ТипВС®Билеты Аэропорт®УЕ, ЗаПасс, Тариф,

ТипВС®ПассВм, ДУ, Тяга, ДУ®Тяга

Атрибуты УЕ, ЗаПасс, Тариф зависят от части Аэропорт составного ключа, что ведет к дублированию данных, если в аэропорт полеты совершаются не один раз.

Атрибуты ДУ, Тяга, ПассВм зависят от части ТипВС составного ключа, что ведет к дублированию данных, если данный тип ВС совершает полеты не в один аэропорт.

Избыточность:

изменение любого из этих атрибутов требует менять его во всех кортежах для данного аэропорта;

невозможно хранить аэропорт без рейсов;

невозможно хранить тип ВС без рейсов.

Вместо R1 проекции R2, R3, R4:

1) на составной первичный ключ и атрибуты, находящиеся в полной ФЗ от него:

R2 (Клиент, Груз, Объем)	Клиент	Груз	Объем
Восток	Продукты
Восток	Мебель
Восток	Запчасти
Заря	Продукты
Заря	Запчасти
Заря	Мебель
Маяк	Запчасти
Маяк	Продукты
Маяк	Мебель
Салют	Продукты

2) на часть Клиент составного ключа и атрибуты, зависящие от нее:

R3 (Клиент, Город, Телефон, Расстояние, Тариф)	Клиент	Город	Тел.	Расст.	Тариф
Восток	Уфа
Заря	Казань
Маяк	Уфа
Салют	Казань

3) на часть Груз составного ключа и атрибуты, зависящие от нее:

R4 (Груз, Упаковка)	Груз	Упаковка
Продукты	Коробки
Мебель	Контейнер
Запчасти	Ящики

Сокращение избыточности, R2, R3, R4 – вместо R1.

Вместо S1 проекции S2, S3, S4:

1) на составной первичный ключ и атрибуты, находящиеся в полной ФЗ от него:

S2 (Аэропорт, ТипВС, Билеты)	Аэропорт	ТипВС	Билеты
Алматы	Ил-62М
Алматы	Ту-154М
Анапа	Ту-154
Анапа	Ту-154М
Анапа	Ан-24
Баку	Ил-62М
Баку	Ту-154
Волгоград	Ан-24

4) на часть Аэропорт составного ключа и атрибуты, зависящие от нее:

S3 (Аэропорт, УЕ, ЗаПасс, Тариф)	Аэропорт	УЕ	ЗаПасс	Тариф
Алматы	Да
Анапа	Нет
	Баку	Да
	Волгоград	Нет

3) на часть ТипВС составного ключа и атрибуты, зависящие от нее:

S4 (ТипВС, ПассВм, ДУ, Тяга,)	Тип ВС	ПассВм	ДУ	Тяга
Ил-62М		Д30-КУ	11.0
Ту-154М		Д30-КУ154	10.5
Ту-154		НК-8-2	10.5
	Ан-24		НК-8-2	10.5

Сокращение избыточности, S2, S3, S4 – вместо S1.

Атрибут С зависит от атрибута А транзитивно, если для атрибутов А,Б,С выполняются условия А®Б, Б®С, но обратная зависимость отсутствует.

Детерминант – атрибут или набор атрибутов, от которого зависит другой атрибут (левая часть ФЗ).

Отношение находится в 3НФ, тогда и только тогда, когда оно находится в 2НФ, и не содержит транзитивных зависимостей.

Преобразование отношения, находящегося в 2НФ, исключающее ВСЕ транзитивные зависимости неключевых атрибутов от ключа – приведение к 3НФ.

Если таких зависимостей нет, то отношение находится в 3НФ.

В отношении R3 атрибуты Тариф и Расстояние зависят от ключа не прямо, а через зависимость от Город (транзитивно). Если стоимость транспортировки любого груза одинакова – избыточность (в одном городе несколько поставщиков, стоимость одна и та же).

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

Вместо отношения R3 – две проекции R5 и R6:

1) на ключ и все атрибуты, кроме зависящих от него транзитивно:

R6 (Клиент, Город, Телефон)	Клиент	Город	Тел.
Восток	Уфа
Заря	Казань
Маяк	Уфа
Салют	Казань

2) на связный атрибут транзитивной ФЗ и атрибуты, зависящие от него:

R5 (Город, Расстояние, Тариф)	Город	Расст.	Тариф
	Уфа
	Казань

Отношения R5 и R6 заменяют R3.

Остались:

R2 (Клиент, Груз, Объем поставки)

R4 (Груз, Упаковка)

R5(Город, Расстояние, Тариф)

R6 (Клиент, Город, Телефон)

Проведенные преобразования позволяют иметь в БД данные:

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

Если это делать в исходном отношении, то при прекращении поставок информация о клиенте исчезает.

Вместо отношения S4 – две проекции S5 и S6:

1) на ключ и все атрибуты, кроме зависящих от него транзитивно:

S6 (ТипВС, ПассВм, ДУ)	Тип ВС	ПассВм	ДУ
Ил-62М		Д30-КУ
Ту-154М		Д30-КУ154
Ту-154		НК-8-2
Ан-24		НК-8-2

2) на связный атрибут транзитивной ФЗ и атрибуты, зависящие от него:

S5 (ДУ, Тяга)	ДУ	Тяга
	Д30-КУ	11.0
	Д30-КУ154	10.5
	НК-8-2	10.5

Отношения S5 и S6 заменяют S4.

Остались:

S2 (Аэропорт, ТипВС, Билеты)

S3 (Аэропорт, УЕ, ЗаПасс, Расст, Тариф)

S5 (ДУ, Тяга)

S6 (ТипВС, ПассВм, ДУ)

Проведенные преобразования позволяют иметь в БД данные:

о потенциальных ТипахВС и ДУ (которые пока не используются), потенциальных аэропортах и данных о них (в которые пока не летали).

Если это делать в исходном отношении, при прекращении полетов на данном типе ВС информация о нем исчезает.

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

Алгоритм метода проектирования реляционных БД с помощью декомпозиции:

1) Разработка универсального отношения для БД.

2) Определение всех ФЗ между атрибутами отношения.

3) Проверка на нахождение в 3НФ: если «Да» - проектирование завершается; если «Нет» - разложить на два.

Удалить межатрибутные зависимости:

– частичные зависимости неключевых от ключа (2НФ)

– транзитивные зависимости неключевых от ключа (3НФ)

– зависимости атрибутов составных ключей от неключевых (НФБК)

4) Шаги 2 и 3 повторяются для каждого полученного отношения.

Ведение БД на ПК

Файл БД состоит из отдельных записей, каждая из которых соответствует одной строке таблицы.

Запись состоит из отдельных полей, количество которых соответствует числу атрибутов (столбцов).

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

В файлах БД содержатся определение схемы (структуры) отношения и собственно данные в строках (записях). Они имеют специальный формат.

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

Следующий этап – ввод данных.

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

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

Редактирование – процесс внесения изменений и исправления ошибок в записях БД.

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

Включает в себя

– дополнение файла БД новыми записями;

– удаление существующих записей;

– изменение данных в отдельных записей.

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

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

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

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

Возможно получение средних значений, сумм, а также количества записей, удовлетворяющих определенным условиям.

Дата добавления: 2015-05-09