Принципы нормализации. Описание предметной области. Нормальные формы

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

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

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

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

В теории БД существуют следующие нормальные форм:

– первая нормальная форма;

– вторая нормальная форма;

– третья нормальная форма;

– усиленная третья нормальная форма (форма Бойса - Кодда);

– четвертая нормальная форма;

– пятая нормальная форма.

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

Преобразовать эту информацию в отношение можно, повторив многократно фамилии студентов и семестр (см. [1], стр. 150 таблица «Сессия). Необходимо также выявить сущности, «замаскированные» под атрибуты. Такое отношение находится в первой нормальной форме (1НФ): его поля содержат неделимую информацию, и в таблице нет повторяющихся групп полей. Однако при этом появился большой уровень дублирования, потенциальная противоречивость и возможность аномалий. Например, названия предметов могут быть написаны по-разному, а если изменится количество часов по какому-либо предмету, то придется искать и менять все его строки.

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

Получение второй нормальной формы (2НФ) - следующий этап нормализации. 2НФ предъявляет следующие требования:

1) Таблица должна удовлетворять требованиям первой нормальной формы;

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

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

Решение проблем устранения дублирования информации требует введения первичных ключей – идентификаторов и разделения таблицы «Сессия» на таблицы (см.[1], стр. 151):

«Студенты» (Номер, ФИО),

«Преподаватели» (Номер, ФИО),

«Дисциплины» (Номер, Название),

«Учебный план» (Номер строки, Номер дисциплины, Семестр, Количество часов, Форма отчетности, Номер преподавателя, Должность),

«Результаты сессии» (Номер студента, Номер строки учебного плана, Оценка).

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

1) Поле первичного ключа должно быть числовым (для компактности);

2) Поле первичного ключа должно быть уникально в пределах таблицы;

3) Поле первичного ключа должно заполняться автоматически, например, с помощью встроенных средств СУБД или триггеров;

4) Поле первичного ключа рекомендуется называть ID (идентификатор);

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

Например, таблица «Учебный план» содержит внешний ключ со ссылкой на первичный ключ таблицы «Преподаватели» - уникальный номер каждого преподавателя.В каждую таблицу добавляется дополнительный столбец (ID), значение которого численно характеризует любую запись таблицы.

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

1) Таблица удовлетворяет требованиям второй нормальной формы;

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

Т.е. все неключевые атрибуты взаимно независимы, не допускается транзитивная (через другие неключевые атрибуты) зависимость от первичного ключа. Например, в данном случае, чтобы избежать аномалии обновления должности преподавателя, следует устранить функциональную зависимость между неключевыми атрибутами Должность и Преподаватель и провести декомпозицию таблицы «Учебный план», выделить таблицу «Кадровый состав преподавателей».

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

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

Для нашего примера процесс нормализации на этом закончен.

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

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

Четвертая нормальная форма (4НФ) является частным случаем 5НФ и требует, чтобы примененная к каждой таблице полная декомпозиция была соединением ровно двух проекций. Чаще всего БД в 4НФ уже находится в 5НФ.

Схема нормализации

ННФ (ненормализованные данные)

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

1НФ

Полная функциональная зависимость от первичного ключа

(удаление зависимостей от части ключа)

2НФ

«Неприводимая» зависимость от первичного ключа

(удаление транзитивных зависимостей неключевых атрибутов)

3НФ

Удаление из функциональных зависимостей оставшихся аномалий

НФБК

Удаление многозначных зависимостей

4НФ

Удаление зависимостей соединения

5НФ

10. Модель «Сущность-связь». ER - модель. Типы связей: «один к одному», «многие к одному», «один ко многим», «многие ко многим»

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

Эта модель положена в основу многих коммерческих CASE - продуктов, поддерживающих автоматизированную разработку систем БД вплоть до автоматической генерации скриптов создания таблиц для выбранной СУБД. Моделирование предметной области в этом случае производится графически в виде диаграмм. При этом используются различные технологии их построения, обозначения и ограничения, например, такие как в системе Platinum Erwin/ERX.

Основные положения концепции ER-модели:

– Совокупность объектов предметной области представлена как совокупность сущностей, сущности – объекты предметной области;

– Каждая сущность обладает свойствами (набором атрибутов), отличающими ее от других сущностей;

– Сущности классифицируются по типам (классам), имеющим независимое существование, классы могут образовывать иерархическую зависимость;

– Взаимосвязи объектов представляются как связи между двумя или несколькими сущностями.

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

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

Наиболее распространёнными являются бинарные связи “один к одному” (1:1), “один ко многим” (1:M), “многие ко многим” (M:N).

Связи “один к одному”(1:1). Рассмотрим бинарную связь Отделение и Зав. отделением. Это – связь 1:1. Другой пример, Староста и Группа. Такие связи возникают, например, когда сущность имеет слишком много атрибутов и в целях простоты, наглядности и т.п. она разделяется на несколько сущностей. Возможно, сущности «маскируются» под атрибуты, например, при описании сущности группа фамилию старосты можно считать свойством этой группы, но можно и заметить, что тип сущности «Старосты» является самостоятельным и может участвовать в проектировании БД как отдельный объект. Выбор зависит от целей проектирования и эффективности воплощения.

Связи “один ко многим” (1:М). Рассмотрим бинарную связь «Группа» и «Студент». Одна группа – много студентов. Это – связь 1:М. Другой пример, «Группа» и «Специальность» (М:1). Несколько групп обучаются по одной специальности.

Связи “многие ко многим”. Рассмотрим бинарную связь «Преподаватель» и «Дисциплина». Например, преподаватель Иванов может преподавать физику и математику, в то же время Петров также преподает математику, а Сидоров преподает физику и электронику, т.е. многие преподаватели ведут многие предметы. Это – связь М:М. Другой пример, многие товары могут рекламироваться во многих газетах. В реляционной модели данных такие связи реализуются через некоторые промежуточные сущности и сводятся к связям 1:М и М:1.

Инструмент связей позволяет представить сложные объекты в виде более простых.

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

Пример построен по образцу (см. [1], стр. 143) для БД «Сессия» (см. [1], стр.151)

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

Дата добавления: 2015-05-09