Специалисты Microsoft советуют решать эту задачу через Microsoft_Decision_Trees

Вот пример из нашей методички.

CREATE MINING MODEL MarketBasketAnalysis
{
BasketID LONG KEY,
Basket TABLE PREDICT
{
ProductName TEXT KEY
}
} USING Microsoft_Decision_Trees


CREATE MINING MODEL dm
( CustomerID LONG KEY,
Products TABLE PREDICT
( ProductID KEY,
ProductName RELATED TO ProductID
)
) USING Microsoft_Decision_Trees

Исследовать решение можно через Dependency Network или запросами подобными этому (

SELECT FLATTENED TopCount(Predict(dm.Products, EXCLUSIVE, INCLUDE_STATISTICS), $Probability, 5) -- top 5 most likely products
FROM dm PREDICTION JOIN <your input data> AS t
ON dm.Products.ProductID = t.Products.ProductID.

Я обычно для таких задач использую все же кластеры.

"Для решения нужно создать кластеры куда войдут группы клиентов и группы товаров. Очень важно чтобы это были именно группы, в противном случае решение может не получится (товары будут видны не вероятностями а exists-missing)".

В принципе в DM от Microsoft имеет довольно много подводных камней. Лучше посмотреть где-то рабочее решение, и только потом делать самому.

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

В Юконе будет явно объявлен алгоритм для "корзинки", но это всего лишь настройка подобная описанной мной.
Если я ошибаюсь, Моша поправит.

Потом я достаточно равнодушно смотрю на то что там советуют производители.
Маркетологу для "корзинного" нужно часто сгруппировать Клиент-Продукт.
Тут достаточно кластера, остальное от лукавого.

Ну за теорией наверное в Duwamish Books, а сами вопросы достаточно разжеваны на microsoft.public.sqlserver.datamining

Вот примеры обсуждений.

http://groups.google.ru/groups?hl=ru&lr=&threadm=3d3329c1%241%40news.microsoft.com&rnum=1&prev=/groups%3Fq%3DCREATE%2BMINING%2BMODEL%2BMarketBasketAnalysis%26hl%3Dru%26btnG%3D%25D0%259F%25D0%25BE%25D0%25B8%25D1%2581%25D0%25BA%2B%25D0%25B2%2BGoogle

http://groups.google.ru/groups?hl=ru&lr=&threadm=%23Fh7HzLwBHA.2620%40tkmsftngp03&rnum=2&prev=/groups%3Fhl%3Dru%26lr%3D%26q%3DCREATE%2BMINING%2BMODEL%2BProductName%2Bbasket

К слову, я бы хотел по-возможности обсудить не только схоластические вопросы математического моделирования в DM, но и практику его внедрения.
Давайте поделимся ПРАКТИКОЙ.
Мои наблюдения

1) Основная проблема DM, это высокая квалификация аналитика который смотрит на результаты. Даже я бы сказал другая философия анализа, поэтому таких аналитиков как правило нет. Как ни странно, достаточно удачно тут работают бывшие IT-шники, которые несколько лет назад бросили IT и перешли в реальную экономику. Если у вашего клиента нет подходящего аналитика и он не может его создать, внедрять DM не стоит.

2) DM-анализ если без теории, это штука для аналитика весьма ИНТУИТИВНАЯ, т.к. даже опытный аналитик затрудняется представить правила формирования модели и ее ДЕЙСТВИТЕЛЬНУЮ релеватность реальным данным.

3) Следствия. п.1 и п.2 нужны простые ВИЗУАЛЬНЫЕ инструменты просмотра DM-моделей и хороший тренинг аналитика. Лучше в это вложиться, чем в вычислительные навороты.

2OLAPMASTER

Внимательно перечитайте что я сказал выше и кластер получится.
Как минимум "что-то вразумительное" и я бы сказал интересное для анализа будет.

"Для решения нужно создать кластеры куда войдут группы клиентов и группы товаров. Очень важно чтобы это были именно группы , в противном случае решение может не получится (товары будут видны не вероятностями а exists-missing)".

Да, не обратил внимание, что речь об Юконе.
см. описание DM в Юконе.

Analytical problem
Association: Advanced counting for correlations

Examples
• Market basket analysis
• Advanced data exploration

Microsoft algorithms
• Decision Trees
• Association Rules

Чего-то на меня щедрость напала. :)
Для практикующих DM вот пример как сделать DM-клиент для пользователя из компонент Microsoft, но без Analysis Manager.

15.10. Создание Data Mining клиента в Internet Explorer

<HTML>
<HEAD>
<TITLE></TITLE>
</HEAD>
<SCRIPT LANGUAGE="VBScript">
sub DoIT()
CubeBrowser1.Connect "Provider=MSOLAP;Data Source=SERVER;Catalog=FoodMart 2000","Customer Pattern Discovery", 1, "Загрузка DM-модели"
end sub
</SCRIPT>


<BODY>

<P><INPUT id=button1 name=button1 type=button value="Подключиться к Серверу" onclick="DoIT()"></P>
<OBJECT classid="clsid:BF7D1C83-CFD4-48DA-8C0E-F4D3FC49F1D0"
codebase=""
id=CubeBrowser1 style="LEFT: 0px; TOP: 0px" VIEWASTEXT>
<PARAM NAME="_ExtentX" VALUE="25000">
<PARAM NAME="_ExtentY" VALUE="14000"></OBJECT>

</BODY>
</HTML>

2Константин.
Если г-н Raymond из Microsoft не знает как реализуется корзинка это не значит, что это позиция Microsoft. Обратите внимание на подписи сотрудников Microsoft в форумах, типа "за базар не отвечаем".

А вот Jamie MacLennan и Peter Kim из Microsoft знают как эта задача решается и предлагаю даже разные варианты. Просмотрите их ответы, достаточно квалифицированные и точные советы, причем решающие не просто "Basket-что-то там", а проблемную задачу на конкретную корзинку поставленную клиентом.

MicrosoftОт:Sal Terillo (sterillo@hotmail.com)
Тема:Shopping Basket Analysis


View this article only
Группы новостей:microsoft.public.sqlserver.datamining
Дата:2002-02-28 06:55:06 PST


Is it possible to do this type of data mining with Microsoft Decision Trees?

Thanks.

Sal Terillo
Сообщение 2 в разделе
От:Peter Kim [MS] (peterkim@online.microsoft.com)
Тема:Re: Shopping Basket Analysis


View this article only
Группы новостей:microsoft.public.sqlserver.datamining
Дата:2002-02-28 17:05:44 PST


Yes, it is.
Suppose you have the following mining model:
CREATE MINING MODEL dm
( CustomerID LONG KEY,
Products TABLE PREDICT
( ProductID KEY,
ProductName RELATED TO ProductID
)
) USING Microsoft_Decision_Trees

olapmaster Вот скорее всего так и получаеться бред.
Вопрос то в том как найти эти группы которые должны уже потом в ходить в кластер. Придеться брать бубен и шаманить!!!

Не понял. Обычно номенклатура имеет группировку. Если у вас номенклатор без групп, то какие прогнозы. Как вы фактические данные смотрите-то?
Линейный список на тысячи позиций? Если так, аналитики и IT-шники должны быть уволены, а лучше убиты, чтобы в другое место не понесли такой кошмар.

К группам товаров которые завели аналитики еще стоит добавить группы и признаки от вендора. Вендоры обычно умнее продавцов и тщательно классифицируют свою продукцию в том числе по товаро-заменителям.
Иногда даже такие классификаторы доступны в XML. Например, Creo и Heidelberg позволяет их получить по интимным договорам. Вероятно они сами у себя DM крутят против конкурентов.

Несколько сложнее с клиентами. Цивилизованный метод, провести анкетирование клиентов по дисконтной программе и получить признаки. Это не только для корзинок нужно. Еще вариант вскрыть структуру ИНН. Он то везде есть и в нем есть расшифровки.

Вероятно всеже придется пояснить подходы к basket-анализу.
1) Нужно определить что такое корзинка в вашем случае. Это не так тривиально как кажется.
Варианты.
- Покупка за 1н раз, значит это ID кассового чека (case).
- Покупка 1го покупателя за всю историю
- Покупка 1го покупателя за период времени
- другое
2) Вам нужно из п.1 сделать case (сказать KEY)
3) Далее набиваем корзину (TABLE PREDICT)

Дерево покажет как товары влияли на покупку друг друга.
Влияние товаров лучше смотреть на на Дереве, а на Dependency Network, не у всех DM-поставщиков есть такая визуализация, возможно это и путает. Деревья это не обязательно древа.
Анализ будет весьма приличным, т.к. он покажет не только что пиво влияет на подгузники, но и что пиво+подгузники неприменно требует покупки презерватива и т.д.

Если вас волнует анализ попроще Client-Product (корзинка это клиент), то можно просто сделать кластер.

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

Ну для начала с чего вы решили, что это мусор? Если 50 человек не котролируя себя делают повторные покупки, это не случайность, а не познанная закономерность, которая на лицо и на нее можно делать ставку в том числе при формировании банделов.

Соответственно, хочется, чтобы алгоритм такие случаи отбрасывал и не засорял результаты. Можно ли это настроить.

Конечно и их обычно меняют, те кто решает задачи на практике.
У Microsoft есть такие
COMPLEXITY_PENALTY и MINIMUM_LEAF_CASES.
Во втором можно сказать,что MINIMUM_LEAF_CASES=5 и ваши случайные покупки отваляться.
COMPLEXITY_PENALTY сложнее, этот параметр контролирует коррелируемость результатов.
На практике я обычно понижаю и COMPLEXITY_PENALTY и MINIMUM_LEAF_CASES, т.к. аналитики хотят видеть максимально связей и сами фильтровать что тут шум.

Ну, и второе - а нельзя ли сюда кусочек дерева запостить?
Интересно, что там в корне этого дерева находится?

Если брать tree view, то на вершине окажется товар, который имеет максимальную корреляцию на опеределение связанных покупок.
Однако обычно этот вид для такого анализа не используется.
Представление что Дерево Решение это ДЕРЕВО просто обывательское.
Смотрят обычно Dependecy Network, где выбирают нужный товар и он показывает связи с другими товарами, причем видна и сила связи.

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

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

Здесь, очевидно, требуется эвристический подход, поскольку если начнёте решать в лоб через DISTINCT COUNT, то сразу же наткнётесь на комбинаторный взрыв. Представляете сколько вариантов надо перебрать, чтобы нарыть сочетаемость в стандартном супермаркете с 20-30 тысячами наименований?

Константин. Снова не спешите с выводами. Анализ-то не так плох, хотя бы потому что результаты "DM" в удобном виде добавляются в OLAP для пользователей.
Проблема взрыва решается сама собой. Только те кто не применяли DM попробуют поискать что-то на уровне конкретных товаров.
Обычно это бессмыслено. Дело в том, что покупатель купил не кондиционер FUJITSU 25R, а "Бытовой канальный кондиционер среднего класса".
Товары меняются, группы товарозаменителей остаются. Относительно их и ищут.
Для розницы с обротом $100 млн. в год, скорее всего будет достаточно вести анализ относительно 50-70 групп. Берем 70 в квадрате и все не так страшно.

PS. Для знатоков MDX. Может кто предложит улучшенный вариант решения Microsoft, где Distinct Count считается не относительно константного товара, а относительно всех товаров, т.е. в кубе есть 2ва измерения Товар и нужно вывести Calc member с distinct count относительно Покупателя.
Я как-то делал, помню в чем-то была заморочка. Если у кого есть, приведите MDX плиз.

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

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

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

И вообще, сейчас обижусь и поеду за документами. :)
Глумитесь без меня.

Группа - Пиво Премиум.
Результаты вашего анализа скорее всего будут верны и для Стеллы и т.д.
В принципе есть тут большой опт, то можно и без группы, но с группой (премиум) лучше с точки зрения маневра в товарозаменителях.

А вот сопуствующие товары (с чем покупают) точно в группы. Там без групп совсем плохо выйдет, даже если у вас номеклатура из 2х позиций: Хольстен и Кальмар к Пиву.

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

Именно слабость статбазы и блокирует ваш анализ, слишком мало повторных case, у вас с точки зрения DM идут просто разнородные факты.

Еще совет. Как ни странно, но алгоритм из RDBMS-данных работает лучше чем из OLAP. RDBMS при однотипном анализа ловит закономерности лучше.
В чем причина - загадка. Но факт есть факт.

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

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

Еще. Не делайте overeating. Т.е. не нужно совать в DM лимоны фактов. У него крыша поедет. Подготовте выборку из следующего соображения. Для статистической достоверности наличия закономерно в 99% достаточно иметь 27 фактов (критерий хи-квадрат). Иными словами для 5 кластеров нужно иметь минимум 150 фактов. В принципе лучше сувать примерно 10-15-30 тыс. фактов взятых случайным образом. Мелкие выборки надо уметь делать (знать стат. теорию), поэтому тут давим числом, но без перебора.