Содержание 5-го вопроса

Основные компоненты хранилища данных таковы:

·        оперативные источники данных;

·        средства переноса и трансформации данных;

·        метаданные;

·        реляционное хранилище;

·        OLAP-хранилище;

·        средства доступа и анализа данных.

Рассмотрим основные потоки данных в хранилище. Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в реляционное хранилище. При этом они уже доступны для анализа при помощи средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. При этом они могут быть загружены в специальную БД OLAP или оставаться в реляционном хранилище. Важнейшим элементом хранилища являются метаданные, т.е. данные о структуре, размещении, трансформации данных. 

Методика проектирования будет рассмотрена на примере проектирования многомерной БД для анализа состояния подписки издательского предприятия.

5.3.1. Определение требований

Первым шагом проектирования многомерной БД является анализ запросов и требований, предъявляемых пользователями к СМЭАД. Необходимо проконсультироваться со специалистами, занимающимися анализом в данной области и выяснить вопросы, с которыми конечные пользователи хотели бы обратиться к СМЭАД. На этом этапе интерес представляют не столько тексты вопросов, сколько понимание того, о каких фактах, событиях и объектах в них спрашивается.

Пример:

1.      На сколько процентов изменилось количество подписчиков на журнал Официальный вестник Украины по всем регионам на протяжении последних 6 месяцев?

2.      В каких регионах наибольшее увеличение числа подписчиков?

3.      В каких регионах уменьшилось число подписчиков?

4.      Какой из выпускаемых журналов принес больше прибыли за последний квартал?

5.      Какая средняя длительность подписки на журналы за прошлый год?

5.3.2. Анализ вопросов

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

Пример:

1.      Количество подписчиков

2.      Общая сумма подписки

5.3.3. Определение структуры многомерной БД

Теперь необходимо определить структуру многомерной БД, т.е. определить конкретные Измерения и Факты, их взаимосвязи и уровни агрегации хранимых данных.

1. Факты – это элементы, которые могут быть измерены и проанализированы. Факты могут быть числовыми и аддитивными. Числовые факты – это количественные величины. Над числовыми фактами допускается выполнение различных математических операций, их легко измерить.

Фактом, представленным последовательным рядом значений (continuously valued), может быть любая из набора величин; обычно она часто изменяется. Факты, представленные последовательно выбранными значениями, полезны, поскольку всегда содержат новую информацию. 

Аддитивный факт может суммироваться по всем измерениям. С помощью аддитивных фактов можно получить компактные наборы результатов. Число записей, просматриваемых по запросам к исторической базе данных, может достигать нескольких тысяч, так что суммировать их содержимое - ценная возможность.

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

Некоторые факты полуаддитивны (semiadditive). Их можно корректно суммировать по одним измерениям, но нельзя по другим. Например, имеет смысл суммировать складские запасы по продуктам или по регионам, но не по времени. Полуаддитивные факты нельзя суммировать по всем измерениям, но их можно оценивать другими способами. Средняя величина складских запасов во времени имеет смысл, как и максимальный и минимальный уровни запасов и некоторые другие статистические показатели.

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

Пример:

Факты (меры) многомерной БД для анализа состояния подписки издательского предприятия:

·        Количество подписчиков

·        Общая сумма подписки

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

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

Пример:

2. Измерения многомерной БД для анализа состояния подписки издательского предприятия:

·        Время

·        Подписчики

·        Продукты

3. Следующий шаг - определение структурной единицы (зерна). Зерно (grain) - нижний уровень детализации данных, хранящихся в киоске.

Информация может суммироваться на различных уровнях в соответствии с иерархической структурой. Ежедневные продажи могут суммироваться по неделям, месяцам или годам; проданные товары можно суммировать по продуктам, категориям продуктов или линейкам продуктов.

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

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

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

Пример:

Таблица 1. Степень детализации многомерной БД для анализа состояния подписки издательского предприятия:

Иерархия строится по принципу убывания сверху вниз: вверху более общие определения, внизу более подробные. В измерении Время я выбрал 4 уровня иерархии: Год, Квартал, Месяц, Неделя. Это обусловлено тем, что издательство выпускает еженедельные, ежемесячные и ежеквартальные издания и необходимо отслеживать изменения информации в данных временных отрезках. В измерении Продукты я выбрал 3 уровня иерархии чтобы можно было отбирать данные по Типу издания (бумажное, электронное), По частоте выхода (еженедельные, ежемесячные и ежеквартальные издания), по Названию. В измерении Подписчики я выбрал один уровень иерархии, т.к. в качестве подписчиков в данном случае выступают областные отделения УкрПошти, и в каждой области находится только одно областное отделение.

Таким образом, общая структура измерений выглядит следующим образом (Таблица 2).

Таблица 2. Общая структура измерений выглядит следующим образом

5.3.4. Определение реляционной схемы многомерной БД

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

Пример базы данных со схемой звезды представлен на Рис. 6.1., схема снежинки представлена на Рис.5.2.

После этого можно приступать к загрузке данных в БД, построенную по схеме снежинки. Сначала заполняется «справочная» таблица, в нашем примере – это Prod_class, далее заполняем данными таблицу subscribers, а потом заполняются данными таблицы Facts и Time.