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

Ну для начала с чего вы решили, что это мусор? Если 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 тыс. фактов взятых случайным образом. Мелкие выборки надо уметь делать (знать стат. теорию), поэтому тут давим числом, но без перебора.