На главную Напишите нам! Напишите нам!
25-08-2012

Нормализация базы данных - Delphi (Lazarus)

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

Процесс нормализации данных заключается в устранении избыточности данных в таблицах.

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

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

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

Под понятием повторяющиеся группы подразумевают поля, содержащие одинаковые по смыслу значения. Взгляните на рисунок:

Студент 1Студент 1Студент 1
Иванов И.И.Петров П.ПСидоров С.С.
Рис. 1.6. Повторяющиеся группы

Верно, такую таблицу можно сделать, однако она нарушает правило первой нормальной формы. Поля "Студент 1", "Студент 2" и "Студент 3" содержат одинаковые по смыслу объекты, их требуется поместить в одно поле "Студент", как в рисунке 1.4. Ведь в группе не бывает по три студента, правда? Представляете, как будет выглядеть таблица, содержащая данные на тридцать студентов? Это тридцать одинаковых полей! В приведенном выше рисунке поля описывают студентов в формате "Фамилия И.О.". Однако если оператор будет вводить эти описания в формате "Фамилия Имя Отчество", то нарушается также правило неделимости. В этом случае каждое такое поле следует разбить на три отдельных поля, так как поиск может вестись не только по фамилии, но и по имени или по отчеству.

Вторая нормальная форма (2НФ) требует, чтобы таблица удовлетворяла всем требованиям первой нормальной формы, и чтобы любое не ключевое поле однозначно идентифицировалось полным набором ключевых полей. Рассмотрим пример: некоторые студенты посещают спортивные платные секции, и ВУЗ взял на себя оплату этих секций. Взгляните на рисуноки Рис. 1.7. и Рис. 1.8ab.:

Неправильная вторая нормальная форма

№ студентаСекцияПлата
Плавание 
Скейтборд 
Теннис 
Плавание 
Теннис 
Рис. 1.7. Нарушение второй нормальной формы

В чем здесь нарушение? Ключом этой таблицы служат поля "№ студента" - "Секция". Однако данная таблица также содержит отношение "Секция" - "Плата". Если мы удалим запись студента № 110, то потеряем данные о стоимости секции по скейтборду. А после этого мы не сможем ввести информацию об этой секции, пока в нее не запишется хотя бы один студент. Говорят, что такое отношение подвержено как аномалии удаления, так и аномалии вставки.

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

Правильная вторая нормальная форма

№ студентаСекция
Плавание
Скейтборд
Теннис
Плавание
Теннис
Рис. 1.8a. Ключ: № студента
СекцияПлата
Плавание 
Скейтборд 
Теннис 
Плавание 
Теннис 
Рис. 1.8b. Ключ: Секции

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

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

СекцияПлатаКоличествоОбщая
Плавание25.0010250.00
Скейтборд   
Теннис   
Плавание   
Теннис   
Рис. 1.9. Нарушение третьей нормальной формы

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

Поле "Общая стоимость" в данном примере можно спокойно убрать из таблицы, ведь если потребуется вывести такие данные, нетрудно будет перемножить значения полей "Плата" и "Количество студентов", и создать для вывода вычисляемое поле.

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

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

Добавить в Мой Мир  Добавить в ВКонтакте.ру  Добавить в Facebook  Добавить в LiveJournal  Добавить в twitter

Яндекс.Метрика
Копирование возможно при указании прямой индексируемой гиперссылки