Лекция 7. Даталогическое проектирование (на примере реляционных баз данных)

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

Способы проектирования: на основе модели сущность и связь (преобразование концептуальной модели по формальным правилам), на основе универсального отношения (нормализация). CASE-средства логического моделирования.

Седьмая лекция курса «Даталогическое проектирование баз данных» посвящена знакомству с основами логического проектирования реляционных баз данных. В данной лекции приводятся определение ключевых понятий процесса логического проектирования базы данных, рассмотрены основные способы логического проектирования, общие сведения об используемых при логическом проектировании CASE-средствах.

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

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

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

Основные методы проектирование реляционных баз данных: 1) с использованием универсального отношения; 2) с использованием инфологической модели «сущность-связь».

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

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

Пример 7.1. Понятие функциональной зависимости

Дано отношение «Результаты экзаменационной сессии» имеющее следующие атрибуты: «№ зачетной книжки», «Фамилия», «Имя», «Отчество», «Группа», «Дисциплина», «Оценка». Известно, что: 1) каждой студент за одну сессию сдает несколько экзаменов по разным дисциплинам; 2) каждому студенту соответствует определенная группа; 3) по каждой из дисциплин студент может получить только одну оценку. Следовательно: Атрибут «Фамилия» (Y) функционально зависим от атрибута «№ зачетной книжки» (Х), потому что в любой момент времени каждому значению атрибута «№ зачетной книжки» (Х) соответствует ровно одно значение атрибута «Фамилия» (Y). Аналогично для атрибутов «Имя», «Отчество», «Группа». Атрибуты «Дисциплина» и «Оценка» функционально не зависят. Атрибут «Оценка» (Y) функционально зависим от пары атрибутов «№ зачетной книжки» (Х) и «Дисциплина», потому что в любой момент времени каждому значению пары атрибутов «№ зачетной книжки» (Х) и «Дисциплина» соответствует ровно одно значение атрибута «Оценка» (Y).

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

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

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

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

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

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

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

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

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

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

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

Функциональная зависимость множества атрибутов Z от множества атрибутов X (записывается X → Z, произносится «икс определяет зет») является транзитивной, если существует такое множество атрибутов Y, что X → Y и Y → Z. При этом ни одно из множеств X, Y и Z не является подмножеством другого, то есть функциональные зависимости X → Z, X → Y и Y → Z не являются тривиальными.

Определение нормальной формы Бойса-Кодда (BCNF): отношение находится в BCNF, если оно находится во 3NFи в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов (эта нормальная форма вводит дополнительное ограничение по сравнению с 3NF)

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

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

Условие обратимости требует, чтобы декомпозиция сохраняла эквивалентность схем при замене одной схемы на другую, т.е. в результирующих отношениях: 1) не должны появляться ранее отсутствовавшие кортежи; 2) на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.

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

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

В общем виде алгоритм логического проектирования базы данных с использованием универсального отношения выглядит следующим образом: 1) построение универсального отношения для базы данных; 2) определение всех функциональных зависимостей, существующих между атрибутами универсального отношения; 3) удаление всех избыточных функциональных зависимостей из исходного набора функциональных зависимостей с целью получения минимального покрытия (данная процедура проводится путем поочередного удаления избыточных функциональных зависимостей, с последующей проверкой получаемого на каждом шаге набора функциональных зависимостей на наличие хотя бы одной избыточной функциональной зависимости); 4) использование функциональных зависимостей из минимального покрытия для декомпозиции универсального отношения в набор отношений в 5NF; 5) определение того, находятся ли полученные отношения в 5NF (если да, то проектирование завершается, если нет, то отношения не находящиеся в 5NF должны быть разложены на два или несколько отношений); 6) повторение шага 5 для каждого нового отношения, полученного в результате декомпозиции (проектирование завершается, когда все отношения будут находиться в 5NF); 7) если может быть получено более чем одно минимальное покрытие, то осуществляется сравнение результатов, полученных на основе различных минимальных покрытий, с целью определения варианта, лучше других отвечающего требованиям пользователя.

Существует несколько причин, почему не следует использовать универсальное отношение в качестве единственного в базе данных. Различают три специфические проблемы: проблема, связанная с обновлением (модификацией) данных в базе данных; проблема, обусловленная необходимостью удаления кортежей; проблема, обусловленная необходимостью включения новых кортежей. Выделенные проблемы обычно называют аномалиями обновления, удаления и вставки, понимая под аномалией отклонение от нормы.

Проектирование реляционных баз данных с использованием семантических моделей: ER-диаграммы

В общем виде алгоритм логического проектирования базы данных на основе преобразования инфологической модели «сущность-связь» в реляционную модель данных выглядит следующим образом: 1) каждой сущности ER-диаграммы ставится в соответствие отношение реляционной модели данных; 2) каждый атрибут сущности преобразуется в атрибут соответствующего отношения (для каждого атрибута задается тип данных и обязательность (или необязательность) данного атрибута, а также ряд других параметров); 3) ключевой атрибут сущности становится первичным ключом соответствующего отношения; 4) бинарные, N-арные и иерархические cвязи организуются путем добавления новых и/или объединения существующих сущностей и добавления дополнительных атрибутов, соответствующим внешним ключам; 5) отношения не находящиеся в 5NF подвергаются декомпозиции с последующей проверкой их на нахождение в 5NF; 6) п.5 повторяется до тех пор пока все отношения не будут находится в 5NF; 7) если некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях, то в этом случае необходимо пересмотреть ER - диаграммы на предмет устранения возникших затруднений.

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

К основным CASE-средствам, которые используются при даталогическом проектировании можно отнести: CA ERWin Data Modeler, IBM Rational Rose и др.

Подробное изложение теоретических вопросов, затронутых в первой лекции, можно найти в литературе [1,3,5,6]. Практические аспекты этих вопросов можно отыскать в работах [2,4].

Знания следует самостоятельно проверить путем ответов на контрольные вопросы (список контрольных вопросов приведен в Методических рекомендациях по самостоятельному изучению дисциплины «Базы данных», которые являются неотъемлемой частью учебно-методического комплекса дисциплины «Базы данных»).