Когда несколько месяцев назад я первый раз установил на свой компьютер третий Delphi, времени разбираться с новыми компонентами особенно не было. На днях, решив выяснить, что же все-таки находится на вкладке с загадочным названием Decision Cube, я был буквально очарован новым способом обработки и представления данных. Borland, словно бы в подтверждение выражения "все гениальное просто", создала мощный инструмент, не требующий от программиста написания ни единой строки кода.

Пролог

Пусть некоторая компания (назовем ее "Бендер и К") занимается оптовой торговлей. Вся информация о совершенных сделках собирается в таблицу, записи которой имеют следующую структуру: номер заказа, дата, наименование покупателя, наименование товара, цена единицы и количество заказанного товара. Спецификой деятельности компании является неширокий круг постоянных клиентов. Исходя из накопленных данных, руководство компании могут интересовать следующие отчеты: общая сумма продаж за определенный период, общая сумма продаж конкретного наименования товара и конкретному клиенту, как распределялись продажи по видам товаров и клиентам за определенный промежуток времени и т.п. Компания решила автоматизировать свою деятельность при помощи персонального компьютера и соответствующего программного обеспечения. Для этого с фирмой-разработчиком заключается договор и оформляется техническое задание, где оговариваются параметры будущей программы, в частности список отчетных форм, которые будет выдавать программа. Последовательность действий программиста при создании отчета можно разбить на три этапа. На первом при помощи специального языка запросов (например, SQL) или с использованием библиотек функций доступа к базам данных (например, Borland Database Engine) создается выборка данных, удовлетворяющих некоторым критериям. Затем выбранные данные отображаются на экране и выводятся на печатающее устройство. Существующие технологии вынуждают разработчика создавать по одному (как минимум) запросу для каждого вида отчетов, что является достаточно трудоемкой задачей, особенно при большом количестве этих самых отчетов.

Применение Decision Cube

Но посмотрим на задачу несколько иначе. Итак, мы имеем таблицу, где собрана информация обо всех продажах компании "Бендер и К". Определим трехмерное пространство, одним измерением которого будет время, вторым - товарная номенклатура, и третьим - множество всех клиентов компании. В этом случае каждую сделку, совершаемую компанией, можно представить ячейкой в нашем пространстве. Ячейка содержит два числовых значения: цена единицы и количество проданного товара. Три координаты ячейки - это дата продажи, наименование товара и наименование клиента.

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

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

Эпилог

Быть может, что преимущества нового подхода в представлении данных на вышеприведенном примере покажутся не столь убедительными. Действительно, имея всего одну таблицу с шестью полями, создать вышеупомянутые отчеты не займет много времени и при использовании стандартной методики (запрос - отображение на экране - вывод на печать). Но представим такую ситуацию. Руководство компании "Бендер и К" решило, что имеющихся данных недостаточно для принятия грамотных решений. Решено регистрировать дополнительно следующую информацию о каждой сделке: регион, где находится клиент, форма оплаты (предоплата, оплата по факту поставки, оплата в течение 30 дней и т.п.), способ доставки товара. Кроме этого, в связи с расширением товарной номенклатуры решено ввести товарные группы: ТНП, медикаменты, продукты питания и проч. Если компания-разработчик будет работать по-старому, то при внесении изменений в существующую систему, для того чтобы учесть новые требования заказчика, ей придется внести исправления во все существующие запросы и отчетные формы, а также создать множество новых. При использовании же подхода, предложенного Borland в компоненте Decision Cube, в пространство, рассмотренное выше, надо будет добавить еще четыре измерения, соответственно: регион, форма оплаты, способ доставки, товарная группа и... больше ничего! Ни единой дополнительной строчки кода.

Андрей КИРЕЕВ,
andreik@gs.minsk.by