Денормализация
 | Эта статья нуждается в дополнительных цитатах для проверки . ( май 2008 г. ) |
Денормализация — это стратегия, используемая в ранее нормализованной базе данных для повышения производительности. В вычислительной технике денормализация — это процесс попытки улучшить производительность чтения базы данных за счет потери некоторой производительности записи путем добавления избыточных копий данных или путем группировки данных. [1] [2] Это часто мотивируется производительностью или масштабируемостью программного обеспечения реляционных баз данных , которому необходимо выполнять очень большое количество операций чтения. Денормализация отличается от ненормализованной формы тем, что преимущества денормализации могут быть полностью реализованы только в модели данных, которая в противном случае нормализована.
Реализация [ править ]
Нормализованный проект часто «хранит» разные , но связанные фрагменты информации в отдельных логических таблицах (называемых отношениями). Если эти отношения хранятся физически в виде отдельных файлов на диске, выполнение запроса к базе данных , который извлекает информацию из нескольких отношений ( операция соединения ), может быть медленным. Если соединено много отношений, это может быть непомерно медленным. Есть две стратегии решения этой проблемы путем денормализации:
- «Поддержка DMBS»: система управления базами данных хранит в фоновом режиме избыточные копии, согласованность которых поддерживается программным обеспечением СУБД.
- «Реализация DBA»: администратор (или разработчик) базы данных решает проблему, денормализуя структуру логических данных.
Поддержка СУБД [ править ]
При таком подходе администраторы баз данных могут сохранить нормализованную логическую структуру, но разрешить системе управления базами данных (СУБД) хранить дополнительную избыточную информацию на диске для оптимизации ответа на запросы. В этом случае ответственность за обеспечение согласованности всех избыточных копий лежит на программном обеспечении СУБД. Этот метод часто реализуется в SQL в виде индексированных представлений ( Microsoft SQL Server ) или материализованных представлений ( Oracle , PostgreSQL ). Представление может, помимо прочего, представлять информацию в формате, удобном для выполнения запросов, а индекс гарантирует, что запросы к представлению физически оптимизированы.
Реализация администратора базы данных [ править ]
При таком подходе администратору или проектировщику базы данных приходится денормализовать логическую структуру данных. При осторожном подходе это может привести к аналогичному улучшению ответа на запрос, но за это придется заплатить — теперь ответственность за то, чтобы денормализованная база данных не стала несогласованной, лежит на разработчике базы данных. Это делается путем создания в базе данных правил, называемых ограничениями , которые определяют, как должны синхронизироваться избыточные копии информации, что может легко сделать процедуру денормализации бессмысленной. Именно увеличение логической сложности конструкции базы данных и усложнение дополнительных ограничений делают этот подход опасным. Более того, ограничения приводят к компромиссу , ускоряя чтение ( SELECT в SQL) при замедлении записи ( INSERT, UPDATE, и DELETE). Это означает, что денормализованная база данных при большой нагрузке на запись может иметь худшую производительность, чем ее функционально эквивалентный нормализованный аналог.
и ненормализованные данные Денормализованные
Денормализованная модель данных — это не то же самое, что модель данных, которая не была нормализована, и денормализация должна происходить только после того, как достигнут удовлетворительный уровень нормализации и созданы все необходимые ограничения и/или правила для решения присущих аномалии в конструкции. Например, все отношения находятся в третьей нормальной форме , и любые отношения с зависимостями соединения и многозначными зависимостями обрабатываются соответствующим образом.
Примеры методов денормализации включают в себя:
- «Хранение» количества элементов «многие» в отношении «один-ко-многим» в качестве атрибута отношения «один».
- Добавление атрибутов в отношение из другого отношения, с которым оно будет соединено.
- Звездчатые схемы , которые также известны как модели измерения фактов и были расширены до схем-снежинок.
- Готовое суммирование или кубы OLAP
С продолжающимся резким увеличением всех трех показателей: хранилища, вычислительной мощности и пропускной способности на всех уровнях денормализация в базах данных превратилась из необычного метода расширения в обычное явление или даже норму. [ когда? ] Например, одним конкретным недостатком денормализации было просто то, что она «использует больше памяти» (то есть буквально больше столбцов в базе данных). За исключением действительно огромных систем, использование хранилища в 2020-х годах стало восприниматься как небольшая проблема.
См. также [ править ]
Ссылки [ править ]
- ^ Г.Л. Сандерс и С.К. Шин. Влияние денормализации на производительность СУБД . В материалах конференции HICSS, январь 2001 г.
- ^ С.К. Шин и Г.Л. Сандерс. Стратегии денормализации для извлечения данных из хранилищ данных . Системы поддержки принятия решений, 42(1):267-282, октябрь 2006 г.