Проектирование хранилища «АПТЕКА»

Лабораторная работа №2.

Тема 2.  Консолидация данных и отчетность аптечной сети

Описание бизнес-задачи

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

Предварительно программисты компании создали процедуру выгрузки данных из учетной системы в структурированные текстовые файлы (в качестве пробы сформирована «пачка» данных за несколько месяцев). Требуется:

□ спроектировать структуру реляционного хранилища данных (ХД);

□ наполнить ХД первичной информацией;

□ разработать процедуры пополнения ХД и контроль непротиворечивости содержащихся в нем данных;

□ предложить набор OLAP-отчетов.

Исходные данные. Создать  четыре файла: Группы товаров.txt, Товары.txt, Отделы.txt, Продажи.txt.

Рассмотрим последовательность решения задачи в аналитической платформе Deductor.

 

 

Deductor Warehouse

 

Хранилище данных Deductor Warehouse – это специально организованная база данных, ориентированная на решение задач анализа данных и поддержки принятия решений, обеспечивающая максимально быстрый и удобный доступ к информации. ХД Deductor Warehouse соответствует модели ROLAP (схема «снежинка») и может быть развернуто на одной из следующих СУБД: Firebird, SQL Server, Oracle (в версии Academic – только на Firebird). С Deductor Warehouse на базе Firebird имеется возможность работать локально при помощи динамической библиотеки fbclient.dll (поставляется вместе с Deductor).

Хранилище данных Deductor Warehouse включает в себя потоки данных, поступающие из различных источников, и специальный семантический слой, содержащий так называемые метаданные (данные о данных). Семантический слой и сами данные хранятся в одной СУБД.

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

Все данные в Deductor Warehouse хранятся в структурах типа «снежинка», где в центре расположены таблицы фактов, а «лучами» являются измерения, причем каждое измерение может ссылаться на другое измерение. Именно эта схема чаще всего встречается в реляционных хранилищах данных (рис. 2.1).

 

Рис. 2.1. Структура Deductor Warehouse

 

В Deductor Warehouse имеются следующие типы объектов.

Измерение – последовательность значений одного из анализируемых параметров. Например, для параметра Время это последовательность календарных дней, для параметра Регион – список городов. Каждое значение измерения может быть представлено координатой в многомерном пространстве процесса, например Товар, Клиент, Дата.

Атрибут – свойство измерения (то есть точки в пространстве). Атрибут как бы скрыт внутри другого измерения и помогает пользователю полнее описать исследуемое измерение. Атрибутами измерения Товар могут выступать Цвет, Вес, Габариты.

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

Ссылка на измерение – установленная связь между двумя и более измерениями. Дело в том, что некоторые бизнес-понятия (соответствующие измерениям в хранилище данных) могут образовывать иерархии, например, Товары могут включать Продукты питания и Лекарственные препараты, которые, в свою очередь, подразделяются на группы продуктов и лекарств и т. д. В этом случае первое измерение содержит ссылку на второе, второе – на третье и т.д.

Процесс – совокупность измерений, фактов и атрибутов. По сути, процесс и есть «куб», «снежинка». Процесс описывает определенное действие, например продажи товара, отгрузки, поступления денежных средств и пр.

Атрибут процесса – свойство процесса. Атрибут процесса, в отличие от измерения, не определяет координату в многомерном пространстве. Это справочное значение, относящееся к процессу, например № накладной, Валюта документа и т.д. Значение атрибута процесса, в отличие от измерения, не всегда может быть определено.

В Deductor Warehouse может одновременно храниться множество процессов («звезд» или «снежинок»), имеющих общие измерения, например измерение Товар, фигурирующее в процессах Поступления и Отгрузка.

Все загружаемые в ХД данные обязательно должны быть определены как измерение, атрибут либо факт (рис. 2.2).

 

Рис. 2.2. Проектирование структуры хранилища

 

Информация о принадлежности данных к тому или иному типу (измерение, ссылка на измерение, атрибут или факт) содержится в семантическом слое хранилища. Обратим внимание на то, что:

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

□ таблица процесса содержит только факты и коды измерений (без их атрибутов).

 

Проектирование хранилища «АПТЕКА»

 

Первая подзадача – спроектировать структуру хранилища нашей аптечной сети. Все данные представлены в четырех таблицах. Их фрагменты приведены ниже (табл. 2.1-2.4).

Таблица 2.1

Группы товаров (фрагмент)

Код группы	Наименование группы
33	Иммуномодуляторы
48	Общетонизирующие средства и адаптогены
50	Местные анестетики
108	Микро- и макроэлементы
198	Витамины и витаминоподобные средства
223	Желчегонные средства и препараты желчи
…	…

 

Таблица 2.2

Товары (фрагмент)

Код товара	Наименование товара	Код группы
1	2	3
774	Альмагель	1
810	Иммунорм	33
Окончание таблицы 2.2
1	2	3
824	Ревит	198
898	Настойка пустырника	48
…	…	…

 

Таблица 2.3

Отделы

Код отдела	Наименование отдела
1	Аптека 1
2	Аптека 2
3	Аптека 3

 

Таблица 2.4.

Продажи (фрагмент)

Дата	Код отдела	Код товара	Час покупки	Количество	Сумма
01.01.2009	1	3382	15	1	293,92
01.01.2009	1	18346	17	1	22,15
01.01.2009	2	85600	16	1	32,16
01.01.2009	3	62535	14	4	202,72
01.01.2009	2	40315	15	3	47,52
…	…	…	…	…	…

 

Рассмотрим, какие данные являются измерениями, какие – атрибутами, а какие – фактами и что представляет собой процесс.

В табл. 2.1 Код группы является измерением, а Наименование группы – его атрибутом.

В табл. 2.2 Код товара является измерением, Наименование товара – его атрибутом, а Код группы – ссылкой на одноименное измерение.

В табл. 2.3 Код отдела является измерением, а Наименование отдела – его атрибутом.

В табл. 2.4 Дата является измерением, Код отдела, Код товара и Код группы, как было сказано выше, – измерения, Час покупки – измерение, Количество и Сумма – факты. То есть табл. 2.4 представляет собой описание процесса продаж в трех аптеках.

При такой структуре ХД мы предполагаем, что уникальность точки в пространстве определяется совокупностью измерений Дата + Товар + Код отдела + Час покупки. То есть если в одной и той же аптеке в один и тот же день и час будет совершено несколько покупок, скажем, препарата «анальгин», то в хранилище данных будет отражена только одна запись.

Взаимоотношение измерений, атрибутов и фактов внутри процесса продаж в трех аптеках показано на рис. 2.3 (см. выделенную строку табл. 2.4). В силу того, что визуально можно представить только трехмерное пространство, на рисунке показано взаимодействие трех измерений (Дата, Код отдела и Код товара). В рассмотренном примере измерений гораздо больше. Каждое новое может быть представлено новой осью.

 

Рис. 2.3. Измерения, атрибуты и факты внутри процесса продаж

 

 

Создание хранилища

 

Запустите программу Deductor Studio Academic. Для создания нового пустого хранилища данных или подключения к существующему перейдите на вкладку Подключения меню Вид, щелкните правой кнопкой мыши и запустите Мастер подключений (рис. 2.4).

 

Рис. 2.4 Создание (подключение) хранилища данных

 

На первом шаге мастера следует выбрать тип источника (приемника) – Deductor Warehouse (рис. 2.5).

 

Рис. 2.5. Окно выбора типа подключения

 

На следующем шаге из единственно доступного в списке типа базы данных выберите Firebird. Задайте параметры базы данных, в которой будет создана физическая и логическая структура хранилища данных (рис. 2.6):

□ база данных – D:\farma.gdb (или любой другой путь);

□ логин – sysdba, пароль – masterkey;

□ установите флажок Сохранять пароль.

 

Рис. 14.6. Установка параметров базы данных

 

На следующей вкладке выберите последнюю версию для работы с ХД Deductor Warehouse 5 (предыдущие версии необходимы для совместимости с предыдущими хранилищами). Нажмите кнопку Создать файл базы данных с необходимой структурой метаданных и по указанному ранее пути будет создан файл farma.gdb (появится сообщение о его успешном создании). Это и есть пустое хранилище данных.

Осталось выбрать визуализатор для подключения (здесь это Сведения и Метаданные) и задать имя, метку и описание нового хранилища (рис. 2.7).

 

Рис. 2.7. Настройка семантики имен для узла подключения

 

Имя хранилища может быть введено только латинскими буквами. После нажатия кнопки Готово на дереве узлов подключений появится метка хранилища (рис. 2.8).

 

Рис. 2.8. Хранилище данных «Фармация»

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

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

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

□ имя – GR_ID;

□ метка – Группа.Код;

□ тип данных – целый.

Метка – это семантическое название объекта хранилища данных, которое увидит пользователь, работающий с ХД.

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

 

Таблица 2.5

Параметры измерений

Измерение	Имя	Метка	Тип данных
1	2	3	4
Код группы	GR_ID	Группа.Код	Целый
Код товара	TV_ID	Товар.Код	Целый
Окончание таблицы 2.5
1	2	3	4
Код отдела	PART_D	Отдел.Код	Целый
Дата	S_DATE	Дата	Дата/время
Час покупки	S_HOUR	Час	Целый

 

В результате структура метаданных хранилища будет содержать пять измерений (рис. 2.9).

 

Рис. 2.9. Структура метаданных хранилища

 

К каждому измерению, кроме Дата и Час, добавьте текстовый атрибут. Для измерения Группа.Код это будет Группа.Наименование, для измерения Товар.Код – Товар.Наименование, для измерения Отдел.Код – Отдел.Наименование.

Каждое измерение может ссылаться на другое измерение, реализуя тем самым иерархию измерений. В нашем случае измерение Товар.Код ссылается на Группа. Код. Эту ссылку и установите путем простого добавления, а имя ссылки задайте GR_ID_1. Результат работы иллюстрирует рис. 2.10.

Рис. 2.10. Формирование ссылки на измерение

 

После того как все измерения и ссылки на измерения созданы, приступайте к формированию процесса («снежинки»). Назовите его Продажи и добавьте в него ссылки на четыре существующих измерения: Дата, Отдел.Код, Товар.Код, Час. Кроме них, в процессе участвуют два факта: Количество и Сумма, причем первый – целочисленный, а второй – вещественный (рис. 2.11).

 

Рис. 2.11. Создание метаданных процесса

На этом проектирование структуры и метаданных ХД закончено.