Тренд (отчет изменений)

Тренд – это отчет, отражающий изменение показателей во времени и динамику этих изменений.

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

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

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

Рисунок 14. Тренд

1. Панель инструментов – предназначена для настройки параметров отчета измерений.

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

3. Темпы изменений – таблица, отображающая динамику изменений показателей (первая производная).

4. Графическое представление данных отчета.

В графическом интерфейсе тренда отображается три графика:

1. Первый график строится по абсолютным значениям показателя в определенные моменты времени и показывает, как изменялось значение показателя – увеличивалось или уменьшалось.

2. Второй график строится по значениям изменений показателя за периоды между двумя соседними моментами времени и определяет направление развития показателя. С точки зрения математики график – это первая дискретная производная, а с точки зрения физики – скорость изменений показателя от периода к периоду.

3. Третий график строится по величине изменений скорости и показывает изменение интенсивности развития показателя. С точки зрения математики график – это вторая дискретная производная от значений показателя, а с точки зрения физики – ускорение изменения на каждом интервале времени. Именно этот график и является трендом.

Для настройки отчета изменений укажите (рис. 15):

1. Запрос, на основании которого будут поступать данные из источников.

2. Поле запроса, которое будет являться измерением.

Рисунок 15. Настройка тренда

3. Поле запроса, которое будет использовано в качестве измерения Дата.

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

5. Алгоритм агрегации факта.

6. Название отчета изменений.

7. Краткое описание отчета изменений.

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

Готовое приложение вы можете передать конечному пользователю. Это делается путем передачи пользователю caf-файла и инструкции по настройке приложения на источники данных.

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

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

Разграничение прав доступа может быть реализовано несколькими способами.

Если приложение использует локальные таблицы, то возможны два варианта.

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

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

Если же приложение настроено на реляционную базу данных, доступ пользователя к базе будет контролироваться средствами СУБД. При первом обращении пользователя к базе данных из системы Контур Стандарт можно запрашивать login и пароль пользователя, и далее доступ к данным базы предоставлять в соответствии с правами этого пользователя.

6. Пример анализа продаж по данным БД “Northwind” с помощью «Контур Стандарт».

Проиллюстрируем теорию примером. Создадим отчет для анализа продаж с помощью “Контур Стандарт”. Данные о продажах представим в разрезе товаров, покупателей и менеджеров. Учтем также географический и временной факторы. В качестве источника данных используем БД “Northwind”, предлагаемую в составе MS SQL Server и MS Access.

На первом этапе настройки OLAP-приложения определим путь к БД “Northwind” и в терминах предметной области опишем ее структуру (таблицы и отдельные поля этих таблиц). Описывая таблицы, выберем только те поля, которые нам необходимы для анализа. Для удобства российских пользователей при описании источников данных (таблиц и их полей) дадим им русскоязычные имена. Далее в отчетах пользователей будут фигурировать именно эти наименования.

Для анализа продаж воспользуемся таблицами:

· Products (Товары): ProductID (Код товара), ProductName (Наименование товара), CategoryID (Группа товаров).

· Categories (Группы товаров): CategoryID (Код группы товаров), CategoryName (Группа товаров).

· Employees (Сотрудники): EmployeeID (Код сотрудника), LastName (Сотрудник).

· Customers (Покупатели): CustomerID (Код покупателя), CompanyName (Компания), Region (Регион), Country (Страна), City (Город).

· Orders (Договора): OrderID (Договор), OrderDate (Дата), EmployeeID (Сотрудник), CustomerID (Покупатель).

· Order Details (Детали договора): OrderID (Договор), ProductID (Товар), Quantity (Количество), Discount (Скидка).

Далее создаем запрос – “выборку” в терминах “Контур Стандарт”. Здесь описываются отображаемые поля, связи таблиц по ключевым полям, условия фильтрации. Таким образом, запрос описывает алгоритмы генерации SQL-запросов к источникам данных.

Перечислим отображаемые в запросе поля таблиц: “Группа товаров”, “Наименование товара”, “Сотрудник”, “Регион”, “Страна”, “Город”, “Компания”, “Дата”, “Скидка” и “Количество”. В этот список входят все информативные поля, используемые при анализе. Поля-идентификаторы не включены в список, т.к. в отчетах они фигурировать не будут.

Запрос объединяет данные нескольких таблиц. Поэтому необходимо указать связи таблиц по ключевым полям, например (рис. 16).

Рисунок 16. Настройка выборки данных – добавление связей между таблицами

Соединим таблицы Покупатели и Договора по полю «Код покупателя», таблицы Договора и Сотрудники по полю «Код сотрудника», таблицы Товары и Детали договора по полю «Код товара», таблицы Договора и Детали договора по полю «Код договора», таблицы Товары и Группы товара по полю «Код группы товара».

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

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

В терминах "Контур Стандарт" отчет, содержащий динамическую таблицу, называется «срез». При настройке среза из списка полей выборки добавляем необходимые для отчета «факты» и «измерения». При добавлении поля «факта» пользователь выбирает один или несколько алгоритмов его агрегации: сумма, количество и т.д. При добавлении поля даты как «измерения» данные можно разложить на выбранные временные периоды. То есть «измерений» даты будет несколько: год, квартал, день и т.д.

В этом примере в отчете будут использоваться все поля выборки (рис. 17). Измерение «Дата» разложим на периоды: год, квартал, месяц, дата.

Результат настройки отчета можно увидеть в режиме «предварительный просмотр». На практике отчеты обычно оперируют меньшим количеством измерений. При анализе более 7-8 измерений человек с трудом воспринимает информацию. Поэтому, в режиме «предварительный просмотр» настроим внешний вид отчета, удобный для восприятия и оценки информации.

Например, перенесем в область «неактивных» измерений – вверху таблицы – измерения, которые будем использовать для фильтрации таблицы, а не для вычисления итогов продаж по ним (рис. 17): “Страна”, ”Регион”, ”Город”, ”Компания”, “Год”, ”Квартал”, ”Дата” и ”Группа товаров”.

Рисунок 17. Редактирование отчета в режиме «предварительный просмотр»

Таким образом, мы получили отчет о продажах товаров по месяцам в разрезе менеджеров. Для изменения ракурса анализа пользователь в процессе работы с отчетом может вернуть любое измерение в таблицу – «открыть» измерение.

На этом процесс создания приложения закончен. Все настройки сохраняются в файле OLAP-приложения.