Удаление представлений

Синтаксис удаления представления из базы данных подобен синтаксису удаления базовых таблиц:

DROP VIEW < view name >

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

17)Избыточное дублирование данных и аномалии.

Избыточное дублирование данных и аномалии

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

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

С Т

 

Сотрудник	Телефон
Иванов И.М.	3721
Петров М.И.	4328
СидоровН.Г	4328
Егоров В.В.	4328

Рис. 5.1. Неизбыточное дублирование

Пример избыточного дублирования (избыточности) представляет приведен­ное на рис. 5.2а отношение С_Т_Н, которое, в отличие от отношения С_Т, допол­нено атрибутом Нкомн (номер комнаты сотрудника). Естественно предполо­жить, что все служащие в одной комнате имеют один и тот же телефон. Следова­тельно, в рассматриваемом отношении имеется избыточное дублирование дан­ных. Так, в связи с тем, что Сидоров и Егоров находятся в той же комнате, что и Петров, их номера можно узнать из кортежа со сведениями о Петрове.

На рис. 5.26 приведен пример неудачного отношения С_Т_Н, в котором вместо телефонов Сидорова и Егорова поставлены прочерки (неопределен­ные значения). Неудачность подобного способа исключения избыточности заключается в следующем. Во-первых, при программировании придется по­тратить дополнительные усилия на создание механизма поиска информации

 

а)

СТ Н

 

Сотрудник	Телефон	Нкомн
Иванов И.М.	3721	109
Петров М.И.	4328	111
Сидоров Н.Г.	4328	111
Егоров В.В.	4328	111

б)

с т н

 

Сотрудник	Телефон	Нкомн
Иванов И.М.	3721	109
Петров М.И.	4328	111
Сидоров Н.Г.	—	111
Егоров В.В.	—	111

Рис. 5.2. Избыточное дублирование

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

Возможный способ выхода из данной ситуации приведен на рис. 5.3. Здесь показаны два отношения С_Н и Н_Т, полученные путем декомпозиции ис­ходного отношения С_Т_Н. Первое из них содержит информацию о номерах комнат, в которых располагаются сотрудники, а второе - информацию о но­мерах телефонов в каждой из комнат. Теперь, если Петрова и уволят из уч­реждения и, как следствие этого, удалят всякую информацию о нем из баз данных учреждения, это не приведет к утере информации о номере телефона в 111-й комнате.

Т Н

 

Телефон	Н_комн
3721	109
4328	111

С Н

 

Сотрудник	Н_комн
Иванов И.М.	109
Петров М.И.	111
Сидоров Н.Г.	111
Егоров В.В.	111

Рис. 5.3. Исключение избыточного дублирования

Процедура декомпозиции отношения С_Т_Н на два отношения С_Н и Н_Т является основной процедурой нормализации отношений.

Избыточное дублирование данных создает проблемы при обработке кор­тежей отношения, названные Э. Коддом «аномалиями обновления отноше­ния». Он показал, что для некоторых отношений проблемы возникают при попытке удаления, добавления или редактирования их кортежей.

 

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

Выделяют три основные вида аномалий: аномалии модификации (или ре­дактирования), аномалии удаления и аномалии добавления.

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

Так, например, изменение номера телефона в комнате 111 (рис. 5.2а), что представляет собой один единственный факт, потребует просмотра всей таб­лицы С_Т_Н и изменения поля Нкомн согласно текущему содержимому таблицы в записях, относящихся к Петрову, Сидорову и Егорову.

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

В той же таблице С_Т_Н удаление записи о сотруднике Иванове (напри­мер, по причине увольнения или ухода на заслуженный отдых) приводит к ис­чезновению информации о номере телефона, установленного в 109-й комнате.

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

18)Функциональные зависимости. Проектирование баз данных методом нормальных форм. 1 нормальная форма.

Как неоднократно упоминалось ранее, хранение данных в реляционных базах данных преследует две цели: понизить избыточность данных и повысить их достоверность. Для этого необходимо иметь возможность накладывать некоторые ограничения как на сами хранимые данные, так и на взаимосвязи и взаимозависимости между ними, т.к. в противном случае вместо базы данных мы получим просто свалку, лишенную всякой структуры. Обычно эти ограничения вытекают из анализа предметной области, которая моделируется нашей информационной системой. Одним из средств формализации информации, полученной в результате такого анализа, являются зависимости между данными. Существует несколько разновидностей зависимостей, которые рассматриваются реляционной теорией: F-зависимости, MV-зависимости и J-зависимости. В настоящий момент наибольший интерес среди них для нас представляют функциональные зависимости, или F-зависимости. Перед тем, как дать формальное определение функциональной зависимости, приведу пример (заимствованный из книги: Д.Мейер. Теория реляционных баз данных. - М: Мир, 1987). В этом примере используется отношение График(ПИЛОТ РЕЙС ДАТА ВРЕМЯ-ВЫЛЕТА): Табл.1

ПИЛОТ	РЕЙС	ДАТА	ВРЕМЯ-ВЫЛЕТА
Кушинг	83	09 авг	10:15
Кушинг	116	10 авг	13:25
Кларк	281	08 авг	05:50
Кларк	301	12 авг	18:35
Кларк	83	11 авг	10:15
Чин	83	13 авг	10:15
Чин	116	12 авг	13:25
Коупли	281	09 авг	05:50
Коупли	281	13 авг	05:50
Коупли	412	15 авг	13:25

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

1. Каждый рейс имеет определенное время вылета.

2. Данный пилот в данные день и время может участвовать только в одном рейсе.

3. Для данного рейса и даты назначается только один пилот.

Рассмотрев исходные данные с учетом этих ограничений, мы можем сделать ряд выводов:

1. ВРЕМЯ-ВЫЛЕТА функционально зависит от РЕЙСА.

2. РЕЙС функционально зависит от {ПИЛОТ, ДАТА, ВРЕМЯ-ВЫЛЕТА}.

3. ПИЛОТ функционально зависит от {РЕЙС, ДАТА}.

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

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

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

Рассмотрим проблемы, которые возникают при работе с ненормализованными данными. Рассмотрим таблицу СОТРУДНИКИ, которая имеет следующие атрибуты:

Код сотрудника

Имя

Фамилия

Отчество

Дата рождения

Адрес

Телефон

Должность

Разряд

Зарплата

Рейтинг

Дата приема

Дата увольнения

• Избыточность данных

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

Нормальные формы

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

• Первая нормальная форма

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

19)2, 3 и усиленная 3 нормальные формы

• Вторая нормальная форма

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

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

В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормально форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы. состоит из двух атрибутов — Код сотрудника и Должность. Все же личные данные о сотрудниках зависят только от атрибута Код сотрудника. Атрибуты, соответствующие этим данным, выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию о их должностях и зарплате вынесем в другу таблицу, которой присвоим имя СОТРУДНИКИ. Полученные две таблицы связаны между собой по полю Код физического лица, которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом

для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.

• Третья нормальная форма

Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко-второй нормальной форме. Для этой таблицы существует функциональная зависимость между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной.

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

Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две таблицы: СОТРУДНИКИ и ДОЛЖНОСТИ.

Новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными.

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

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

20)Основные понятия метода "сущность-связь". Этапы проектирования.