Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Денормализация - это стратегия, используемая в ранее нормализованной базе данных для повышения производительности. В вычислениях денормализация - это процесс попытки улучшить производительность чтения базы данных за счет потери некоторой производительности записи путем добавления избыточных копий данных или группирования данных. [1] [2] Это часто мотивируется производительностью или масштабируемостью в реляционной базе данных программного обеспечения нуждающегося выполнять очень большое количество операций чтения. Денормализация отличается от ненормализованной формы в том, что преимущества денормализации могут быть полностью реализованы только на модели данных, которая в противном случае нормализована.

Реализация [ править ]

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

Поддержка СУБД [ править ]

Один из методов - сохранить нормализованную логическую схему, но позволить системе управления базами данных (СУБД) хранить дополнительную избыточную информацию на диске для оптимизации ответа на запрос. В этом случае ответственность за обеспечение согласованности любых избыточных копий лежит на программном обеспечении СУБД. Этот метод часто реализуется в SQL как индексированные представления ( Microsoft SQL Server ) или материализованные представления ( Oracle , PostgreSQL ). Представление может, среди прочего, представлять информацию в формате, удобном для запросов, а индекс гарантирует, что запросы к представлению оптимизированы физически.

Реализация DBA [ править ]

Другой подход - денормализовать логический дизайн данных. При осторожности это может достичь аналогичного улучшения ответа на запрос, но за счет затрат - теперь разработчик базы данных несет ответственность за то, чтобы денормализованная база данных не стала противоречивой. Это делается путем создания правил в базе данных, называемых ограничениями , которые определяют, как избыточные копии информации должны быть синхронизированы, что может легко сделать процедуру денормализации бессмысленной. Это увеличение логической сложности проекта базы данных и добавленная сложность дополнительных ограничений, которые делают этот подход опасным. Более того, ограничения вводят компромисс , ускоряя чтение ( SELECTв SQL) и замедляя запись ( INSERT,UPDATE, и DELETE). Это означает, что денормализованная база данных при большой нагрузке записи может предложить худшую производительность, чем ее функционально эквивалентная нормализованная копия.

Денормализация в сравнении с ненормализованными данными [ править ]

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

Примеры методов денормализации включают:

  • «Сохранение» количества элементов «многие» в отношении «один ко многим» в качестве атрибута отношения «один»
  • Добавление атрибутов в отношение из другого отношения, с которым оно будет соединено
  • Звездные схемы , которые также известны как модели измерения фактов и были расширены до схем снежинок.
  • Предварительно построенное суммирование или кубы OLAP

С продолжающимся резким увеличением всех трех: хранилища, вычислительной мощности и пропускной способности на всех уровнях, денормализация в базах данных превратилась из необычной или расширенной техники в обычное дело или даже в норму. Например, одним конкретным недостатком денормализации было то, что она просто «использует больше памяти» (то есть буквально больше столбцов в базе данных). Во всех системах, кроме самых огромных, которые можно вообразить, этот конкретный аспект стал неактуальным; опасность использования большего объема памяти не является проблемой.

См. Также [ править ]

  • Кэш (вычисления)
  • Нормализация
  • Масштабируемость

Ссылки [ править ]

  1. ^ Сандерс Г.Л. и С.К. Шин. Влияние денормализации на производительность СУБД . В материалах конференции HICSS, январь 2001 г.
  2. ^ С. К. Шин и Г. Л. Сандерс. Стратегии денормализации для извлечения данных из хранилищ данных . Системы поддержки принятия решений, 42 (1): 267-282, октябрь 2006 г.