Проектирование реляционных баз данных с использованием нормализации

При проектировании реляционной БД надо решить вопрос о наиболее эффективной структуре данных.

Основные цели, которые при этом преследуются:

1. Обеспечить быстрый доступ к данным в таблице

2. Исключить ненужное повторение данных

3. Обеспечить целостность данных

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм: 1-ая нормальная форма, 2-ая нормальная форма, 3-я нормальная форма, Нормальная форма Бойсса-Кода, 4-ая нормальная форма, 5-ая нормальная форма или нормальная форма проекции-соединения.

Основное свойство нормальных форм: каждая последующая нормальная форма должна удовлетворять требованиям предыдущей формы и некоторым дополнительным условиям.

В большинстве случае достаточно приведение к 3-ей нормальной форме, чтобы разрабатывать работоспособные БД.

1-ая нормальная форма должна удовлетворять следующим требованиям:

1. таблица должна иметь неповторяющиеся записи;

2. в таблице должны отсутствовать повторяющиеся группы полей.

2-ая НФ должна удовлетворять следующим условиям:

1. должна удовлетворять условиям 1-ой нормальной формы;

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

3-ая НФ должна удовлетворять следующим условиям:

1. должна удовлетворять условиям 2-ой нормальной формы;

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

 

Целостность баз данных. Каскадное удаление и изменение данных.

 

Структуры внешней памяти. Хранение отношений. Индексы. Методы организации индексов. Служебная информация

Реализационная СУБД обладает рядом особенностей, влияющих на организацию внешней памяти. В результате этого возникают следующие разновидности объектов во внешней памяти БД:

1. Строки отношений - это основная часть БД, большей частью, непосредственно видимая пользователем.

2. Управляющие структуры - индексы, создаваемые из соображений повышения эффективности выполнения запросов.

3. Журнальная информация - информация, поддерживаемая для удовлетворения потребности надежного хранения данных.

Служебная информация - информация свободной памяти и т.п

Существует 2 подхода к физическому хранению отношений:

1. Покортежное хранение отношений - то есть кортеж является единицей хранения информации (отношения).

2. Хранение отношений по столбцам - то есть единицей хранения является столбец отношения с исключенными результатами.

Под индексом понимают средство ускорения операции поиска записи в таблице, а следовательно и других операций, использующих поиск:

- извлечение;

- модификация;

- сортировка;

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

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

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

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

 

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

1. Внутренние каталоги - описывают физические свойства объектов БД - например, число атрибутов отношения, их размер и возможных типов данных, описание индексов, определенных для данного отношения и т.д.

2. Описатели свободной и занятой памяти в страницах отношения - такая информация требуется для нахождения свободного места при занесении кортежа.

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

 

Журнализация изменений БД

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

Восстановление БД может производиться в следующих случаях:

1. Индивидуальный откат транзакции. Индивидуальный откат транзакции может быть инициирован либо самой транзакцией путем подачи команды Roll Back, либо системой. СУБД может инициировать откат транзакции в случае возникновения какой-нибудь ошибки либо, если эта транзакция выбрана в качестве жертвы при разрешении тупика.

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

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

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

Поддерживается 2 вида буферов:

1. Буферы страниц БД;

Буферы журнала транзакции;

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

Имеются 2 причины для периодического выталкивания страниц во внешнюю память:

1. Недостаток ОП;

2. Возможность сбоев;

Основным принципом согласованной политики выталкивания буфера журнала и буфера страниц БД является то, что запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД. Соответствующий протокол журнализации называется WHL (write a head lock - пиши сначала в журнал) и состоит в том, что, если требуется вытолкнуть во внешнюю память измененный объект БД, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи об его изменении.

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