Модифицирование представлений

Представление может теперь изменяться командами модификации DML, но модификация не будет воздействовать на само представление. Команды будут на самом деле перенаправлены к базовой таблице:

ЧТО НЕ МОГУТ ДЕЛАТЬ ПРЕДСТАВЛЕНИЯ

Имеются большое количество типов представлений ( включая многие из наших примеров в этой главе ) которые являются доступными только для чтения. Это означает, что их можно запрашивать, но они не могут подвергаться действиям команд модификации. ( Мы будем рассматривать эту тему в Главе 21. ) Имеются также некоторые виды запросов, которые не допустимы в определениях представлений. Одиночное представление должно основываться на одиночном запросе; ОБЪЕДИНЕНИЕ (UNION) и ОБЪЕДИНЕНИЕ ВСЕГО (UNIOM ALL) не разрешаются. УПОРЯДОЧЕНИЕ ПО(ORDER BY) никогда не используется в опреде- лении представлений. Вывод запроса формирует содержание представления, которое напоминает базовую таблицу и является - по определению - неупорядоченным.

УДАЛЕНИЕ ПРЕДСТАВЛЕНИЙ

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

DROP VIEW < view name >

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

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

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

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

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

С Т

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

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

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

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

а)

СТ Н

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

б)

С т н

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

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

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

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

Т Н

Телефон	Н_комн

С Н

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

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

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

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

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

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

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

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

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

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

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

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

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

Существует несколько разновидностей зависимостей, которые рассматриваются реляционной теорией: F-зависимости, MV-зависимости и J-зависимости. В настоящий момент наибольший интерес среди них для нас представляют функциональные зависимости, или F-зависимости.

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

Табл.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя

Фамилия

Отчество

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

Адрес

Телефон

Должность

Разряд

Зарплата

Рейтинг

Дата приема

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные понятия метода

Основными понятиями метода сущность-связь являются следующие:

• сущность,

• атрибут сущности,

• ключ сущности,

• связь между сущностями,

• степень связи,

• класс принадлежности экземпляров сущности,

• диаграммы ER-экземпляров,

• диаграммы ER-типа.

Сущность представляет собой объект, информация о котором хранится в БД. Экземпляры сущности отличаются друг от друга и однозначно иденти­фицируются. Названиями сущностей являются, как правило, существитель­ные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВА­ТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.

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

Связь двух или более сущностей - предполагает зависимость между атрибута­ми этих сущностей. Название связи обычно представляется глаголом. Примера­ми связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕ­ДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ-В ГРУППЕ (Иванов ПРЕПОДАЕТ-В 256 группе), ПРЕПОДА­ВАТЕЛЬРАБОТАЕТ-НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).

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

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

• диаграммы ER-экземпляров,

• диаграммы ER-muna, или ER-диаграммы.

Степень связи является характеристикой связи между сущностями, кото­рая может быть типа: 1:1, 1:М, М:1, М:М.

Класс принадлежности (КП) сущности может быть: обязательным и ие-обязателъным.

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

Этапы проектирования.

Процесс проектирования базы данных является итерационным - допус­кающим возврат к предыдущим этапам для пересмотра ранее принятых ре­шений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER-типа с учетом всех сущностей и их связей.

3. Формирование набора предварительных отношений с указанием пред­
полагаемого первичного ключа для каждого отношения и использованием
диаграмм ER-типа.

4. Добавление неключевых атрибутов в отношения.

5. Приведение предварительных отношений к нормальной форме Бойса -
Кодда, например, с помощью метода нормальных форм.

6. Пересмотр ER-диаграмм в следующих случаях:

• некоторые отношения не приводятся к нормальной форме Бойса - Кодда;

• некоторым атрибутам не находится логически обоснованных мест в пред­
варительных отношениях.

После преобразования ER-диаграмм осуществляется повторное выполне­ние предыдущих этапов проектирования (возврат к этапу 1).

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

В рассмотренных выше примерах связь ВЕДЕТ всегда соединяет две сущно­сти и поэтому является бинарной. Сформулированные ниже правила формиро­вания отношений из диаграмм ER-типа распространяются именно на бинарные связи. Поэтому, когда речь идет о связях, слово «бинарные» далее опускается.

22)Правила формирования отношений для бинарной связи 1:1 с помощью метода "сущность-связь".