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

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

Однако источник данных с родственными отношениями порождает классическую дилемму проектирования: одна часть данных доступна лишь на родительском уровне, а другая — на дочернем. Нужны ли две таблицы данных в многомерной модели или достаточно одной? Что делать с данными, доступными лишь на родительском уровне, когда потребуется спуститься до уровня потомков?

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

К данным родительского уровня относятся:

  • четыре стандартных признака: общая дата счета, имя сотрудника отдела продаж, имя заказчика и условия оплаты;
  • один вырожденный признак: номер счета (о нем чуть позже);
  • пять аддитивных параметров: полная окончательная цена на все товары, поощрительная скидка на весь счет, общая стоимость транспортировки, сумма налогов и общий итог («Итого»).

К данным дочернего уровня относятся:

  • два признака: товар и поощрительная скидка;
  • четыре аддитивных параметра: число единиц товара, общая цена (число единиц x цена), окончательная цена [число единиц x (цена за единицу товара — скидка)] и цена за единицу товара и поощрительная скидка за этот товар (о ней — также позже);
  • «контекст» общего счета (пять родительских измерений).

Может показаться, что дело сделано, когда указаны все признаки и параметры. У нас есть две «красивые» таблицы. У родительской таблицы счета — пять признаков и пять численных параметров, у таблицы-потомка — семь признаков и три численных параметра.

Но модель с такой структурой обречена на провал.

Нельзя свести все к одному товару! Если ограничиться только товаром, непонятно, что делать со скидками на уровне всего счета, грузовыми расценками и налогами. На всех более высоких уровнях признак «товар» придется опустить, но в большинстве случаев это неприемлемо. Существует лишь один способ решить проблему. Следует взять данные уровня счета и распределить вниз по иерархии до уровня отдельных строк. Да, такое распределение спорно, и на определенных этапах придется принимать решения несколько произвольным образом. Но выхода нет — в противном случая не удастся выполнять анализ на уровне отдельных товаров.

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

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

  • общая дата счета (признак);
  • имя сотрудника отдела продаж (признак);
  • заказчик (признак);
  • условия оплаты (признак);
  • товар (признак);
  • поощрительная скидка (признак).

Что делать с номером счета? Он, конечно же, однозначен даже на уровне строк, но мы уже «высветили» все, что известно о счете, в своих первых шести признаках. Номер счета следует сохранить в инфраструктуре, но не следует его выносить в отдельный признак, так как он все равно окажется пустым. Мы называем его вырожденным признаком.

Теперь числовые параметры дочерней таблицы включают:

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

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

Вы можете немедленно восстанавливать точные количества на уровне счета, складывая все элементы строк с определенным номером счета. Таблица с фактическими данными родителя-счета теперь не нужна, поскольку эти данные легко определить, агрегируя элементы более детальной таблицы потомков-строк. Распределение до отдельных строк никак не повлияло на общие цифры счета.

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

Конфликт методов распределения

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

При распределении по объему большая часть стоимости распределялась на подушки, а при распределении по весу или цене — на подсвечники. Спор был «политическим», ведь производственные подразделения стали бы более прибыльными, если бы им удалось избежать ответственности за транспортные расходы!

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

  • транспортные расходы, распределенные по объему;
  • транспортные расходы, распределенные по весу;
  • транспортные расходы, распределенные по стоимости.

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

Трудная среда для распределения

Счета за поставку товара хорошо подходят для указанной схемы распределения. Многие суммы на уровне счета и другие бизнес-расходы исчисляются «по объему хозяйственной деятельности». Хотя и приходится идти на определенные компромиссы и натяжки, принимая решение о критерии распределения, тем не менее все обычно соглашаются, что без него не обойтись. В этой сфере деятельности методология исчисления затрат по объему хозяйственной деятельности (activity based costing, ABC) часто позволяет осуществлять необходимый анализ на основе описанных манипуляций с родительскими данными.

Но в некоторых областях процесс распределения чрезвычайно сложен или вообще невозможен. Обычно на предприятиях со сложной структурой затрат, которые не связаны напрямую с продаваемыми товарами или услугами, очень сложно договориться о распределении и методике ABC. Например, в огромной телефонной компании с миллиардными затратами на инфраструктуру, включая оборудование, персонал и недвижимость, очень трудно распределить эти затраты вплоть до отдельных телефонных звонков. По этой же причине большому банку весьма очень сложно распределить затраты на инфраструктуру до уровня отдельных расчетных счетов. Если вас попросят распределить затраты в одной из подобных организаций, чтобы вычислить «доходность продукта», я советую вам попросить финансовый отдел самостоятельно выполнить распределение, которое вы потом с удовольствием разместите в информационном хранилище. Не лезьте в пекло добровольно!

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

Ральф Кимбалл (Ralph Kimball) — один из авторов системы Star Workstation компании Xerox, учредитель компании Red Brick Systems. Автор трех бестселлеров о технологиях информационных хранилищ, в том числе The Data Webhouse Toolkit (Wiley, 2000). Связаться с ним можно через Web-сайт http://www.rkimball.com.