Денормализация уровня доступа
Денормализация уровня доступа распадается на несколько категорий действий, заключающихся в развитии или изменении структуры физической модели на основе типов доступа, с помощью которых будут использоваться данные. Ни при каком условии не следует производить денормализацию без предварительной проверки путей доступа. Следующие методы основываются на потребностях производительности, а на не произвольных причудах.
Перемещение атрибутов. Перемещение атрибутов из одной сущности в другую строго базируется на удостоверении путей доступа проектной группой, включающей людей из областей приложения и моделирования. Администраторам данных не следует перемещать атрибуты без соответствующей поддержки документации.
При выполнении этого вида денормализации атрибут копируется в новую сущность и удаляется из старой сущности. Эта задача выполняется на уровне физической модели и представляет собой обмен атрибутами, который приводит к изменениям в описаниях на DDL и физической структуры базы данных. Очевидно, что для уменьшения объема повторной работы с этими изменениями должен быть ознакомлен весь персонал.
Консолидация сущностей. Консолидация сущностей не является распространенным подходом, поскольку представляет собой физическое комбинирование атрибутов двух таблиц в одной таблице. В результате может появиться составной ключ, включающий атрибуты обеих таблиц, или более детализированный ключ из атрибутов сжимаемой иерархии.
Обычно консолидация сущностей производится для объединения сущностей с поисковыми ограничениями или ограничениями доменов в одну сущность предка. Консолидация может казаться противоречащей логическим представлениям, но в действительности может быть очень логичной, если результирующие сущности появились в результате "сверхнормализации" (разбиения сложных групп элементов вплоть до атомарного уровня). Консолидация сущностей не должна противоречить требуемым путям доступа.
Порождаемые атрибуты и суммарные данные: добавляемые проектировщиком сущности и атрибуты.
Создание сущностей или атрибутов для облегчения множественных или специализированных представлений проектной группы строго основывается на обосновании путей доступа проектной группой, включая специалистов из областей приложения и моделирования.
Сущности создаются типичным образом; не определяются никакие связи между данной сущностью и сущностями модели. Атрибуты определяются как нормальные атрибуты сущности, в которой они будут присутствовать. Сущности проектировщиков обычно поддерживаются для целей агрегирования данных, сохраняя частичные или полные результаты вычислений. Атрибуты проектировщиков предназначены для полных операционных данных, таких как переключатели, а также для хранения следующего числа в последовательности чисел.
Реализация повторяющихся групп. Введение повторяющихся групп строго основывается на обосновании путей доступа проектной группой, включающей специалистов в области приложения, администраторов данных и администраторов баз данных. Кроме того, повторяющаяся группа должна быть небольшой, ограниченной размером тома и не возрастающей. В этой области администраторы баз данных не выполняют большой работы по денормализации.
Для реализации повторяющихся групп должны быть созданы атрибуты в описании экземпляров точно таким же образом, как если бы они были обычными атрибутами. Следует продолжать эти действия, пока не появится столбец для каждого члена повторяющейся группы.
Введение избыточности. Избыточность строго основывается на обосновании путей доступа проектной группой, включающей специалистов в области приложений и инфраструктуры. Подход состоит в избыточном помещении атрибута или другой сущности для достижения лучшей производительности. В большинстве случаев администратор базы данных копирует атрибут в новую сущность или создает его как новый атрибут этой сущности; это делается по той причине, что между сущностями существует связь. Важно помнить о том, что за каждую избыточность нужно платить. Каждый избыточный атрибут должен обновляться в то же время, что и оригинал, чтобы обеспечить соблюдение ссылочной целостности.
Введение суррогатных или синтезированных ключей. Основывается на потребностях более экономичного по памяти и более быстрого доступа. Суррогатные ключи могут потребоваться в тех случаях, когда распространяемые ключи слишком длинны или нарушают реализационные ограничения СУБД. В разумных случаях создается суррогатный ключ, и естественный ключ либо переносится в отдельную сущность, либо размещается как атрибут сущности, для работы с которой предназначен. В тех случаях, когда естественный ключ переносится в отдельную сущность, он снабжается идентификатором суррогата, создавая тем самым ассоциативную таблицу на уровне реализации.
Вертикальная или горизонтальная сегментация. Если размер экземпляра сущности превышает реализационные ограничения на длину строки целевой СУБД, можно произвести вертикальную сегментацию. Новая сущность создается в тем же ключом, что и исходная (конечно, должна обеспечиваться уникальность ключа), а атрибуты исходной строки делятся поровну, и каждая половина становится атрибутами одной из сущностей. В результате эти две таблицы могут быть соединены в одну сущность на основе значений ключа.
