Надеюсь, задаю вопрос, волнующий многих, начинающих знакомиться с Microsoft Analysis Services.
Есть таблица фактов примерно - и упрощенно - следующего содержания:

Дата

День недели

Подразделение

Работник

Вид затрат

Проект

План

Отработанные часы

ИД операции

Пытаюсь понять, как работает data mining-модель decisions trees. Хочу, например, выяснить, каким образом зависит день недели от вида затрат и подразделения. (Вопрос, который я задаю, в отношении data mining-подхода должен звучать, наверное, так: "Что и каким образом определяет загруженность персонала в тот или иной день недели").

Если я строю Relational Data Mining Model, то получается очень даже неплохо: я День недели делаю predictable (предсказываемым) параметром, в качестве входов подаю Отработанные часы , Подразделение и Вид затрат , а в качестве идентификатора события (случая, транзакции, операции - короче, case), беру ИД операции . После обсчета получаю набор вполне внятных условий:


Причем получаю заметно разное распределение весов разных дней недели для разных вариантов (например, АХЧ работает равномерно практически все дни - сторожа работают все время, в то время как "Не отдел внедрения" работает четко только с понедельника по пятницу, т.к. не имеет авралов).

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

Куб я построил. Его анализ с помощью OLAP-клиента идет превосходно. Но вот построить нормальный decision trees-анализ не получается.

Во-первых , что считать case'ом? ИД транзакции не получается, т.к. запихнуть ее в измерения не выходит - записей очень много (больше 64000). Да вроде это и неправильно. Что тогда?

Во-вторых , как сделать так, чтобы предсказываемое значение было не атрибутом (member property) или уровнем (level) одного из измерений (dimension), а другим измерением (или даже мерой)? Сделать-то можно, вот только в этом случае он и деревьев строит столько, сколько значений у предсказываемого измерения найдет. И дальше получается какое-то бредовое и трудно понимаемое ветвление между exists и missing с совершенно невразумительным дроблением по входным измерениям.

Если кто подскажет, буду благодарен. Пример MS совершенно не проясняет ситуацию - его Customer Pattern Discovery, хоть и строится по кубу, но по сути является тем же Relational Data Mining Model, поскольку все входы и предсказываемые параметры являются атрибутами одного и того же измерения!

Задача как раз и состоит в изучении Microsoft Analysis Services. Из сторонних продуктов я смотрел Deductor от BaseGroup (в демо-версии, правда, но тем не менее), там действительно идет обработка "плоских" данных. На таких данных, повторюсь, MS AS работает просто превосходно (они могут лежать в таблице или в одном измерении куба).

Но для чего тогда клиент MS AS предлагает анализировать куб, если толком он этого делать не умеет? Непонятно. Может быть, он просто считает его одним из возможных источников - так, на всякий случай, чтобы был?

В MS AS кроме деревьев решений есть еще алгоритмы кластеризации, а по утверждению В. Иванова, активно участвующего в обсуждениях на форуме, есть и какие-то другие, "скрытые" алгоритмы, которые ему удалось найти, пользуясь ADO-доступом к OLAP и DM MS Analysis Services.

Впрочем, и алгоритм кластеризации работает неважно на кубах. Или я чего-то не понимаю.

Спасибо за ответы. Буду пробовать, проверять.