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

Помимо этого, версия 7.3 может с помощью гистограмм значений столбцов определять, в каких секциях производить поиск по индексу, а в каких - путем полного сканирования таблицы. Это позволяет устранить упомянутый выше серьезный недостаток, связанный с включением лишних секций, и вынуждает генераторы запросов предыдущего поколения выполнять эту оптимизацию в процессе генерации запросов, а не перекладывать ее на плечи оптимизатора запросов. В версиях до 7.2 секционирование все равно дает те преимущества, которые мы обсуждали в главе 10, посвященной архивации. Тем не менее, мы не советуем пытаться выполнять соединение с представлением, содержащим UNION ALL; лучше взять генератор запросов, который создает полный запрос по каждой секции и формирует объединение UNION ALL полученных результатов.

Возможно секционирование и более чем по одному атрибуту (SALES NORTH 0197, SALES NORTH 0297, SALES SOUTH 0197 и т.д.). Однако этот метод уводит нас в сторону от идеи упрощения структуры и порождает сложности при комбинировании таблиц.

Для хранилища данных можно разработать специальную программу, которая будет выполняться в конце каждого месяца, извлекать данные за этот месяц и создавать новую таблицу (SALES 0197). Очевидно, что этот метод характеризуется избыточностью, но его можно эффективно использовать, если над извлеченными данными выполняются агрегирующие операции, обобщающие их для месячного представления. Когда пользователь детализирует данные, вы начинаете применять секции для каждого дня, содержащие более подробные сведения.

Правила агрегирования

Как мы уже говорили, большинство хранилищ данных содержит данные двух типов:

атомарные данные, соответствующие данным из систем ООТ;

агрегированные данные, т.е. обобщения данных, хранящихся в системах ООТ;

Необходимо определить, когда, что и как агрегировать. Когда

Давайте сначала посмотрим, когда следует агрегировать данные, потому что это относительно простой вопрос. Лучше всего это делать на этапе

перехода из загрузочной секции в хранилище. Следующий удобный (и более привычный) метод - загрузить данные в таблицу фактов и выполнять агрегирование там. Существует и другой вариант - одновременно с созданием загрузочного файла атомарных данных создать загрузочный файл обобщенных данных. Однако он имеет ряд недостатков;

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

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

Теперь рассмотрим более сложную проблему: агрегатные данные какого типа создавать. Для ответа на этот вопрос лучще всего изучить вероятные направления использования данных. Это трудно, потому что, пока хранилище данных не введено в эксплуатацию, никто не знает, как оно будет использоваться. Однако если при сборе информации о потребностях пользователей удалось получить какие-то мнения на этот счет, эти сведения могут оказать больщую помощь. Посмотрите на некоторые потенциальные группы агрегированных значений для нащего примера с продажами (табл. 13.1). Если мы будем формировать все возможные сочетания агрегированных значений, то создадим в таблице фактов огромное число новых фактов. Естественно, мы должны выбрать из них важные, а остальные удалить.

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

Таблица. 13.1. Агрегированные значения

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

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

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

1. В той же таблице, что и базовые (неагрегированные) данные о фактах.

2. В таблице фактов, но отдельно от базовой таблицы фактов.

3. Выделить для каждой категории агрегированных значений отдельную таблицу.

Как и следовало ожидать, у каждого из них есть достоинства и недостатки.

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

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

3. Вариант 3, вероятно, самый привлекательный, но здесь требуются хорошие правила именования, позволяющие отслеживать имена всех таблиц.