Денормализация данных для оптимизации базы данных

Универсальных рекомендаций по денормализации нет, это всегда компромисс между размером базы данных и временем выполнения запроса. Если вы исчерпали все возможные способы оптимизации запросов и физической памяти в заданной схеме базы данных, вам следует рассмотреть возможность дальнейшей денормализации, но это не единственный способ решить проблемы с производительностью системы. Самый распространенный метод — организация более агрегированных таблиц (представлений) и многомерных кубов на основе хранилища данных, которое служит непосредственной базой данных для запросов пользователей.Пример денормализацииПредлагаемая модель использует некоторые из приведенных выше правил денормализации. Новые блоки выделены синим цветом, измененные — розовым.Рис. 4. Пример моделиЕдинственная новая функция в таблице продуктов — это строка stock_units. В нормализованной модели мы можем рассчитать это значение следующим образом: заказанная единица - проданная единица - (рекомендованная единица) - списанная единица). Расчет повторяется каждый раз, когда клиент запрашивает товар. Это трудоемкий процесс. Вместо этого можно предварительно рассчитать стоимость, чтобы все было готово, когда придет запрос покупателя.С другой стороны, атрибут stock_unit_unit должен обновляться после каждой вставки, обновления или удаления в таблицах order_products, списание, рекомендуемый продукт и проданный продукт.Единственная новая функция в таблице product — строка units_in_stock. В нормализованной модели мы можем рассчитать это значение следующим образом: заказанная единица - проданная единица - (рекомендованная единица) - списанная единица (unitsordered — unitssold — (unitsoffered) — unitswrittenoff). Расчет повторяется каждый раз, когда клиент запрашивает товар. Это трудоемкий процесс. Вместо этого можно предварительно рассчитать стоимость, чтобы все было готово, когда придет запрос покупателя.С другой стороны, атрибут stock_unit_unit должен обновляться после каждой вставки, обновления или удаления в таблицах products_on_order, writeoff, product_offered и product_sold.Рис. 5. Пример моделиВ таблицу taskдобавлены два новых атрибута: client_name и user_first_last_name. Они оба хранят значения на момент создания задачи — это необходимо, потому что каждое из них может меняться со временем. Вы также должны сохранить внешний ключ, который связывает их с исходным идентификатором пользователя и клиента. Есть и другие значения, которые необходимо сохранить, такие как адрес потребителя или информация о налогах, включенных в цену, таких как НДС.Рис. 6. Пример моделиДенормализованнаятаблица product_presented имеет два новых атрибута: unit_price и price. Первое необходимо для поддержания текущей цены на момент поставки. Нормальный шаблон показывает только текущее состояние. Следовательно, по мере изменения цены меняется и «история цен». Нововведение не только ускоряет работу базы данных, но и улучшает ее функциональность. В строке priceрассчитывается количество проданных единиц. Таким образом, не нужно производить расчеты каждый раз, когда необходимо посмотреть список предлагаемых товаров. Это небольшая цена за повышение производительности.Изменения в таблицу product_sold вносятся по тем же причинам. Разница лишь в том, что в данном случае речь идет о проданных товарах.Рис. 7. Пример моделиТаблица Statistics_per_year в тестовом шаблоне — это совершенно новый элемент. По сути, это денормализованнаятаблица, потому что все ее данные можно вычислить из других таблиц. В нем хранится информация о текущих задачах, успешно выполненных задачах, встречах, звонках по каждому закрепленному клиенту. В этом месте также хранится общая сумма вычислений, сделанных за каждый год. После внесения, обновления или удаления каких-либо данных в расписании заказов, встреч, звонков и продаж продуктов эти данные должны быть пересчитаны для каждого клиента и за соответствующий год. Поскольку изменения касаются только текущего года, отчеты прошлых лет могут остаться без изменений. Значения в этой таблице предварительно рассчитаны, поэтому мы экономим время и ресурсы, когда нужны результаты расчета.Денормализация — мощный подход. Его не следует использовать каждый раз, когда вам нужно повысить производительность. Но в некоторых случаях это может быть лучшим или единственным решением.Однако перед принятием окончательного решения о применении денормализации необходимо убедиться, что она действительно необходима. Необходимо анализировать текущую производительность системы — часто после запуска системы применяется денормализация. Бояться этого не нужно, но все изменения нужно тщательно отслеживать и документировать, и тогда не должно быть проблем и отклонений данных.ЗАКЛЮЧЕНИЕВ работе рассмотрены основные принципы построения интерфейса V5.Также перечислены существующие типы и функции, связанные с переносом информации через данный тип интерфейса.При денормализации важно сохранить баланс между повышением скорости работы базы и увеличением риска появления противоречивых данных. Поэтому проводить денормализацию базы надо очень аккуратно, очень выборочно, только там, где без этого никак не обойтись.СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВНормализация и денормализация базы данных, нормальные формы. [Электронный ресурс]. URL: https://oracle-patches.comЗачем нужна денормализация баз данных, и когда ее использовать. [Электронный ресурс]. URL: https://itnan.ru/post.php?c=1&p=281262Гольдштейн Б.С., Ехриель И.М., Кадыков В.Б., Рерле Р.Д. Протоколы V5.1 и V5.2. Справочник//СПб.: BHV-2003.Гольдштейн Б.С. Протоколы сети доступа. Том 2. — М.: Радио и связь, 2001.- 292 с. ОСТ45.154-2001 Местная телефонная сеть. Сопряжение цифровой автоматической телефонной станции и сети доступа по интерфейсу V5. Спецификация протокола передачи телефонной сигнализации (Уровень 3).