«Перенормализованные» модели данных.

До сего момента предполагалось, что при достижении пятой нормальной формы дальнейшая декомпозиция не только бессмысленна, но и просто вредна. Однако, с чисто формальной точки зрения, она остается возможной, и декомпозиция отношения в V НФ будет полной, если все проекции будут иметь общий ключ. Рассмотрим, что может выиграть, а что проиграть разработчик при работе с подобными информационными моделями, которые иногда неофициально называют «перенормализованными».

Рассмотрим упоминавшееся выше отношение «Студенты».

Отношение «Студенты»

№ зач.	Груп-па	ФИО Студента	Дата рожд.
4567	5203	Петров	01.10.80
4568	5203	Иванов	14.05.79
4569	5104	Сидоров	17.08.80

Его можно представить как набор следующих проекций. (Можно привести и другие варианты).

Отношение «Студенты 1» Отношение «Студенты 2»

№ зач.	ФИО Студента		№ зач.	Группа	Дата рожд.
4567	Петров		4567	5203	01.10.80
4568	Иванов		4568	5203	14.05.79
4569	Сидоров		4569	5104	17.08.80

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

Введем в отношение «Студенты» атрибут Факультет.

Отношение «Студенты»

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Факультет
4567	5203	Петров	01.10.80	Мехмат
4568	5203	Иванов	14.05.79	Мехмат
4445	4401	Кузнецов	10.08.77	Машфак
8902	4382	Сергеев	24.05.79	Машфак
8844	4382	Андреев	22.12.78	Машфак
7569	4405	Сидоров	17.08.80	Машфак

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

Отношение «Студенты Мехмата»

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Факультет
4567	5203	Петров	01.10.80	Мехмат
4568	5203	Иванов	14.05.79	Мехмат

Отношение «Студенты Машфака»

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Факультет
4445	4401	Кузнецов	10.08.77	Машфак
8902	4382	Сергеев	24.05.79	Машфак
8844	4382	Андреев	22.12.78	Машфак
7569	4405	Сидоров	17.08.80	Машфак

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

• Время поиска записи в таблице для всех СУБД пропорционально³ объему таблицы. Если нет острой необходимости обрабатывать всю базу данных одновременно (например, при анализе уникальности номера зачетки), то подобная декомпозиция позволит заметно ускорить работу приложений. Это соображение актуально для аппаратного и программного обеспечения, выпущенного в 80-х годах (системы на базе 8086, 80286 и пр.). Современные персональные ЭВМ и разработанные для них СУБД позволяют обрабатывать сотни тысяч записей с приемлемой скоростью.

• В случае, если подготовка данных ведется в деканатах факультетов, расположенных в разных зданиях, становится невозможным использовать для организации доступа к данным доступные и дешевые технологии Ethernet. С учетом того, что сводные отчеты могут собираться с достаточно большим периодом, становится целесообразной такая организация работы, при которой на факультетах работают независимые банки данных, а исходные данные для получения сводных отчетов по университету передаются на «центральный» компьютер с помощью сменных носителей (в простейшем случае – с помощью дискет). Такое решение может, несмотря на усложнение сценария работы, оказаться дешевле, чем организация многоуровневой сети большой протяженности. Однако следует отметить, что бурное развитие в последнее время технологий удаленного доступа (прежде всего Internet и Intranet) может в ближайшее время снять этот довод.

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

Отношение «Студенты»

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Факультет	Вид спорта	Разряд
4567	5203	Петров	01.10.80	Мехмат	Лыжи	I
4568	5203	Иванов	14.05.79	Мехмат
4445	4401	Кузнецов	10.08.77	Машфак
8902	4382	Сергеев	24.05.79	Машфак	Волейбол	КМС
8844	4382	Андреев	22.12.78	Машфак
7569	4405	Сидоров	17.08.80	Машфак

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

Отношение «Студенты»

№ зач.	Груп-па	ФИО Студента	Дата рожд.	Факультет
4567	5203	Петров	01.10.80	Мехмат
4568	5203	Иванов	14.05.79	Мехмат
4445	4401	Кузнецов	10.08.77	Машфак
8902	4382	Сергеев	24.05.79	Машфак
8844	4382	Андреев	22.12.78	Машфак
7569	4405	Сидоров	17.08.80	Машфак

Отношение «Спортивные разряды»

№ зач.	Вид спорта	Разряд
4567	Лыжи	I
8902	Волейбол	КМС

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