Нормализация - за и против

Дата добавления: 2014-11-24 | Просмотров: 1620

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

Однако у нормализованной БД есть и недостатки, прежде всего практического характера.

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

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

Контрольные вопросы

1. В чём заключается смысл нормализации?

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

3. Для чего необходим ключ-кандидат и сколько их может быть у таблицы?

4. Что такое альтернативные ключи?

5. В чём заключается суть всех свойств отношений?

6. Для чего необходима нормализация таблиц?

7. В чём достоинства и недостатки нормализации?

8. Чем отличается первая нормальная форма от третьей нормальной формы?

9. Что необходимо выполнить, что бы таблица была приведена ко второй нормальной форме?

САМОСТОЯТЕЛЬНАЯ РАБОТА №8 (8 часов)

ТЕМА:Связь между записями одной таблицы. Поддержка целостности данных

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

Рассмотрим пример. Пусть необходимо в реляционной БД хранить древовидную структуру произвольного уровня, например, структуру организации (рис. 1.)

Рис.1 - Структура организации

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

Рис. 2 - Представление в таблице структуры организации

Автоматическое обеспечение связей записей внутри одной таблицы реляционными СУБД не поддерживается и эти связи нужно реализовывать программно. Удаление записи, на которую имеются ссылки (у нас это записи со значением поля "№ подразделения", кроме 4,5,6,8,9,11), должно блокироваться, поскольку в противном случае в таблице будут иметь место ссылки на несуществующие номера подразделений. Также нельзя изменять номера подразделений, на которые имеются ссылки - это разрушит достоверность данных. Такие действия необходимо реализовывать программно. Рассмотренный пример является частным случаем более общей проблемы - обеспечения ссылочной целостности между таблицами базы данных.