Вопросы - Ответы БД

Дана пара отношений A и B, связанных внешним ключом. Первичный ключ отношения B

— атрибут B.key. Внешний ключ отношения A, ссылающийся на B — атрибут A.b. Ссылочная целостность для пары отношений A и B имеет место тогда, когда выполняется условие: для каждого кортежа отношения A существует соответствующий кортеж отношения B, то есть кортеж, у которого (B.key = A.b).

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

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

Поддержание ссылочной целостности в БД

Причины нарушений

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

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

o Неполная запись объектов. Данные объекта размещаются в записях нескольких таблиц, а программа не записывает какую-то из них.

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

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

o Удаление записи без каскадного обновления. Из таблицы удаляется запись, на которую имеются ссылки по внешним ключам других таблиц, при этом в связанных записях внешние ключи не меняются. В результате все ссылающиеся на неё записи других таблиц становятся некорректными.

Сбои в работе системного программного обеспечения и оборудования. Даже когда прикладное программное обеспечение работает совершенно правильно, возможно нарушение ссылочной целостности. Например, если при добавлении объекта в базу нужно добавить несколько связанных записей в несколько таблиц, очевидно, что ссылочная целостность будет нарушена в процессе добавления данных (когда часть связанных записей уже добавлена, а часть — ещё нет), и восстановится только после завершения операции. Если во время выполнения операции она будет прервана (из-за переполнения диска, сбоя питания, или по каким-то другим причинам), часть записей будет добавлена в БД, часть — нет. Часть добавленных записей останется с некорректными ссылками.

Пустые внешние ключи

Возможна ситуация, когда внешний ключ вместо ссылки на существующую запись в таблице БД содержит «отсутствующее значение» NULL. Такое положение можно трактовать как отсутствие какой-то части объекта. Хотя с точки зрения чистой теории это недопустимо, на практике иногда бывает удобно разрешить использование пустых внешних ключей. Чтобы корректно работать с группами связанных таблиц, допускающих пустые внешние ключи, используется специфическая операция языка SQL — открытое соединение (другое название — «внешнее соединение», англ. outer join).

Транзакции

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

Ссылочная целостность на триггерах

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

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

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

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

Ссылочная целостность на внешних ключах

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

При операции добавления или редактирования записи автоматически проверяется,

ссылаются ли внешние ключи в этой записи на существующие записи в заявленных при

описании связанных таблицах. Если выясняется, что операция приведёт к появлению некорректных ссылок, она не выполняется — система возвращает ошибку.

При операции редактирования записи проверяется, не изменяется ли её первичный ключ

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

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

o Запрет — удаление блокируется и возвращается ошибка.

o Каскадное удаление — в одной транзакции производится удаление данной записи

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

одной записи, прямо или косвенно ссылающейся на неё. Если хотя бы одну из ссылающихся записей удалить не получается (либо для неё настроен запрет, либо происходит какая-либо ещё ошибка), то все удаления запрещаются.

oОбнуление внешних ключей — во все внешние ключи записей, ссылающихся на данную, записывается псевдозначение NULL (SQL). Если хотя бы для одной из ссылающихся записей это невозможно (например, если поле внешнего ключа описано так, что его нельзя обнулять), то удаление запрещается.

5.Проектирование баз данных. Аномалии удаления, модификации, вставки. Первая, вторая и третья нормальные формы.

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

Основные задачи:

Обеспечение хранения в БД всей необходимой информации.

Обеспечение возможности получения данных по всем необходимым запросам.

Сокращение избыточности и дублирования данных.

Обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

1.Описание объектов предметной области и связей между ними.

2.Описание информационных потребностей пользователей (описание основных запросов к БД).

3.Описание алгоритмических зависимостей между данными.

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

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определѐнным формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.

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

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

1.основные объекты предметной области (объекты, о которых должна храниться информация в БД);

2.атрибуты объектов;

3.связи между объектами;

4.основные запросы к БД.

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

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

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

Первая нормальная форма (1NF)

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

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

Вторая нормальная форма (2NF)

Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав возможного ключа, функционально полно зависит от каждого возможного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа (плюс выполняются условия 1NF).

Пример приведения таблицы ко второй нормальной форме

Пусть Сотрудник и Должность вместе образуют первичный ключ в такой таблице:

Сотрудник Должность Зарплата Наличие компьютера

Зарплату сотруднику каждый начальник устанавливает сам, но еѐ границы зависят от должности. Наличие же компьютера у сотрудника зависит только от должности, то есть зависимость от первичного ключа неполная.

В результате приведения к 2NF получаются две таблицы:

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

Должность Наличие компьютера

Кладовщик Нет Программист Есть

Третья нормальная форма (3NF)

Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:

Отношение R (таблица) находится во второй нормальной форме;

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

Непервичный (неключевой) атрибут R — это атрибут, который не принадлежит ни одному из возможных (альтернативных) ключей R. Транзитивная зависимость — это функциональная зависимость, при которой X → Z (X определяет Z) не напрямую, а посредством отношения X → Y и Y → Z (отношение Y → X не является обязательным условием).

Определение 3НФ, эквивалентное определению Кодда, но по-другому сформулированное, дал Карло Заниоло в 1972 году. Согласно ему, таблица находится в 3НФ тогда и только тогда, когда для каждой из ее функциональных зависимостей X → A выполняется хотя бы одно из следующих условий:

Х содержит А (то есть X → A — тривиальная функциональная зависимость)

Х — суперключ

А — первичный атрибут (то есть А входит в состав альтернативного ключа).

Определение Заниоло четко определяет разницу между 3НФ и более строгой нормальной формой Бойса-Кодда (НФБК): НФБК исключает третье условие («А — первичный атрибут»).

«Ничего, кроме ключа»

Запоминающееся и, по традиции, наглядное резюме определения 3НФ Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чем, кроме ключа». Это определение часто дополняется словами «и да поможет мне Кодд!»(Что созвучно с "да поможет мне Бог". so help me

Codd/so help me God(Eng))[1]

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

Крис Дэйт говорит о резюме Кента как о «интуитивно привлекательной характеристике» 3НФ, и замечает, что с небольшим изменением она может служить и как определение более строгой нормальной формы Бойса-Кодда: «Каждый атрибут должен предоставлять информацию о ключе, полном ключе и ни о чем, кроме ключа». Вариант определения 3НФ Кента является менее строгим, чем вариант НФБК Дэйта, поскольку первая утверждает только, что неключевые атрибуты зависят от ключей. Первичные атрибуты (которые являются ключами или их частями) вовсе не должны быть функционально зависимыми; каждый из них предоставляет информацию о ключе предоставлением самого ключа или его части. Здесь следует отметить, что это правило справедливо только для неключевых атрибутов, так как применение его ко всем атрибутам будет полностью запрещать все сложные альтернативные ключи, поскольку каждый элемент такого ключа будет нарушать условие «полного ключа».

Пример

Пример приведения таблицы к третьей нормальной форме

Исходная таблица:

Фамилия Отдел Телефон

В результате приведения к 3НФ получаются две таблицы:

Фамилия Отдел

Гришин 1 Васильев 1 Петров 2

Отдел Телефон

111-22-33

244-55-66

Аномалии – это проблемы, возникающие в данных из-за дефектов проектирования БД. Существуют три вида аномалий: вставки, удаления и модификации.

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

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

этих сотрудников в БД больше не будет ни одной записи, содержащей информацию об отделе 128.

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

6.Реляционная алгебра. Операторы реляционной алгебры. Пересечение, вычитание отношений. Декартово произведение отношений. Запросы невыразимые средствами реляционной алгебры.

Теоретико-множественные операторы

Объединение

Отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих или A, или B, или обоим отношениям. Синтаксис:

A UNION B

Пересечение

Отношение с тем же заголовком, что и у отношений A и B, и телом, состоящим из кортежей, принадлежащих одновременно обоим отношениям A и B.

Синтаксис:

A INTERSECT B

Вычитание

Отношение с тем же заголовком, что и у совместимых по типу отношений A и B, и телом, состоящим из кортежей, принадлежащих отношению A и не принадлежащих отношению

B.

Синтаксис:

A MINUS B

Декартово произведение

Отношение (A1, A2, …, Am, B1, B2, …, Bm), заголовок которого является сцеплением заголовков отношений A(A1, A2, …, Am) и B(B1, B2, …, Bm), а тело состоит из кортежей, являющихся сцеплением кортежей отношений A и B:

(a1, a2, …, am, b1, b2, …, bm)

таких, что (a1, a2, …, am) A, (b1, b2, …, bm) B.

Синтаксис:

A TIMES B

Запросы, невыразимые средствами реляционной алгебры

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

Плохая нормализация отношений

Данный пример взят из книги Гилуа М.М. [6, стр.43].

Пример 16. Пусть имеется отношение ХИМИЧЕСКИЙ_СОСТАВ_ВЕЩЕСТВ с набором атрибутов (Наименование вещества, Водород, Гелий, …, 105_элемент). Значением атрибута "Вещество" являются наименования химических веществ, значениями остальных атрибутов - процентный состав соответствующих элементов в этом веществе. Такое отношение могло бы иметь, к примеру, следующий вид:

Таблица 24 Отношение ХИМИЧЕСКИЙ_СОСТАВ_ВЕЩЕСТВ

Рассмотрим запрос "Найти все химические элементы, содержание которых в каком-либо из веществ превышает заданный процент (скажем, 90)".

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

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

На самом деле, этот пример показывает, что таблица плохо нормализована (нормализация отношений рассматривается в гл.6 и 7). В таблице есть набор однотипных атрибутов ("Водород", "Гелий" и т.д. в количестве 105 столбцов).

Правильнее разбить это отношение на три различных отношения:

1.ВЕЩЕСТВО(НОМ_ВЕЩЕСТВА, ВЕЩЕСТВО),

2.ЭЛЕМЕНТЫ(НОМ_ЭЛЕМЕНТА, ЭЛЕМЕНТ),

3.ХИМИЧЕСКИЙ_СОСТАВ_ВЕЩЕСТВ(НОМ_ВЕЩЕСТВА, НОМ_ЭЛЕМЕНТА, ПРОЦЕНТ).