Всем привет!
Размышляю над проектированием структуры данных... было бы интересно послушать мнения.
Задачка совершенно логичная и простая, но нормального решения придумать не получается. Заранее извиняюсь за многабукв.
Итак:
Ритейл, есть чековые данные. К каждой строчке чека может быть привязано несколько (!) сработавших по ней скидок или рекламных акций. Ну например, на один и тот же проданый товар сработала одна сезонная, вторая какая-нибудь по уценке, а третья - предъявленная на кассе подарочная карта.
В ряде отчетов нужно фильтровать продажи по любой рекл.акции. При этом сумму, разумеется, нужно выводить целиком - т.е. если продали нечто за 100 р с учетом трех скидок, то выводим сумму продажи 100, а не 33,33.
Собственно, вопрос - как организовать в BW такую штуку?

Есть несколько вариантов разной степени кривизны:
1. В одном месте держим сумму продаж по каждому чеку, в другом месте держим связку "№ чека, № строки, код акции". В кубах или в DSO, неважно. Дальше соединяем одно с другим через инфосет. Простой штатный бивишный способ, но на нормальных объемах данных он не работает в принципе. Получается джойн таблицы позиций чеков с самой собой, однозначно не взлетит.

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

3. Организационно ограничить количество этих акций, зарезервировать 3-4 поля в строке чека и складывать их туда. Самый простой способ, строка остается одна, просто добавляется пара новых признаков. Но даже в этом случае возникает непростая фильтрация в бексе - нужно вводимую переменную повестить на какой-то один признак акции, а все остальные экзитами из этой вводимой заполнять. Ну и плюс начинаются стандартные базары "как же так, такая крутая система не должна иметь таких ограничений".

4. Держать в одном и том же кубе несколько строк под каждую позицию чека, в одной строке держать сумму продаж, в остальных держать инфу по акциям и нулевую сумму продаж. Тоже не прокатывает, т.к. фильтровать по акции нужно именно сумму продаж.

5. Аналогично варианту 1, но соединять не через инфосет, а через мультикуб, а дальше навешивать константы выбора в бексе (чтобы побороть отсутствие признака акции в одном из кубов). Пытался делать такие решения, пришел к убеждению, что мультикубом такая задача не решается.

Интересно, что в стандартном кубе 0RPA_C01, который заполняется из экстрактора POSDM, на этот счет не предусмотрено ничего. Просто признак акции, просто показатель суммы продаж. Но при этом сам POSDM вполне позволяет передать в него несколько скидок по каждой строке чека. Как они борятся с возможными задвоениями (и борятся ли) - я не понял.

Было бы интересно послушать другие варианты решения, а также конструктивную критику тех, которые я перечислил.

Я бы выбрал аналог варианта 3.
Делается поле в котором акции складываются по кодам, например "/1001/1324/2023/", так с фильтром решается просто -- маской */1324/*, текст можно аналогичным образом склеивать. Чтобы пользователи поменьше были недовольны, можно предложить формировать ключ акции по определенным правилам, например первые две цифры -- год, и, соответственно, маска */14++/* -- выбирает все акции 14-го года.

Если пользователям не понравится -- то делать по записи на каждую акцию, суммы везде одинаковые, настроить агрегацию так, чтобы суммы не складывались (вариант 2).

Я бы шел по второму варианту. Не очень понятны сомнения по поводу применимости только к одному признаку (ну да, к акции применяем, а к чему еще может потребоваться?!) и проблемы с агрегатами. Вот если бы акций было очень много, то тогда да, были бы проблемы, а так - непонятно.

2 вариант...
причем бы оставил цену товара без скидки, т.е. скидка = #, а значение скидки (не в процентном выражении) писал бы либо с минусом либо с соседний показатель. Да строк получиться больше... но зато гибче...

Комбинация 2 и 3+ -- как раз и, если надо, можно и строк поменьше отобразить и для анализа данных удобно.

Я, собственно, тоже размышляю над вариантами 2 и 3.

По поводу спецагрегации (2 варианта) - никаких других аналитик, по которым была бы такая же схема, сейчас не прорисовывается... Но все равно, от того, что не будет вообще никакой возможности сделать это для еще каких-то признаков, как-то неуютно.
Кроме того, увеличить количество строк в 2-3-4 раза - это тоже серьезный вопрос. Если бы это не были позиции чеков - то и фиг бы с ними. Но поскольку это они, то тут возможны объемы порядка десятков млн. строк в год. Получается, что нужно взять и вот просто так, ради какой-то локальной задачи, увеличить этот объем еще в несколько раз... Но в итоге, похоже, что так и придется делать.



Вот это, кстати, прикольная идея, я не подумал. Но тут есть риск упереться в размер кода этого общего поля. И в размер текста тоже. Поскольку id акции в ERP 10 символов, то это достаточно реально. Этот вопрос не стоял бы, если бы была 7.4, но у меня 7.3.

Насчет способа 3+: Если код 10 символов, то в ключ BW можно запихать 5-6 акций, этого достаточно.
Насчет способа 2: Количество строк можно увеличивать при необходимости. Т.е. кидая в развёртку аналитику "акция", а можно и не кидать. Или Вы по поводу куба беспокоитесь, а не по поводу отчета? Тогда агрегат можно сделать. Спецагрегация тоже делается по признаку "акция".

А что будет с производительностью такого фильтра при наполнении куба до нескольких млн записей?

Нормально будет

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

Тогда уж разумнее было бы делать отдельный куб без детализации до чека с ограниченным количеством аналитик (чтобы существенно сократить кол-во строк)

Акция
Материал
Завод
...другие важные аналитики

и с уже агрегированными показателями

Сумма по чекам
Кол-во чеков
...другие важные показатели

и для анализа маркетологами использовать только его.

Теоретически - согласен с правильностью такого подхода и пытался по нему идти.
Практически - это сложно. По ряду причин, опять же - как технических, так и политических.
Технические состоят, например, в том, что в ERP это все _уже_ свалено в одну кучу. Могу сейчас ошибиться в деталях, но если в CRM заводят какую-нибудь фигню типа "купи сегодня на 10000 и тогда ты получишь бумажку, которую потом отоваришь на 1000, если успеешь" - то это валится в тот же самый PromoID, в котором лежат обычные рекламные акции. Причем валится как факт выдачи бумажки, так и факт ее использования. Ну вот устроена она так, и никто не будет это менять только из-за того, что у меня инфосет на больших объемах не работает. Потом, недостаточно ведь просто видеть способ оплаты "подарочная карта", нужно же фильтровать по конкретной (в НГ одна серия, на 8 марта вторая и т.д).
А политические состоят в том, что заказчик сам не знает, можно ли методологически разнести их на разные понятия и оставить именно рекламную акцию единственной. И поэтому старается перевести обсуждение в плоскость "вы заложите возможность множественных, т.к. при переходе на новую аналитическую систему мы хотим заложить на будущее универсальность, расширяемость и т.д.".

Решусь поднять тему.

В итоге к какому-то конкретному решению удалось придти? Может поделитесь опытом?

PS: А как вам вариант, аналогичный предложенному murmur, только вместо отдельного куба с ограниченным набором аналитик просто иметь ДСО, в котором хранить связку чека и рекламных акций. Отчет построить на мультике объединяющим это ДСО вместе с кубом с агрегированными показателями, в Bex QD использовать константу выбор на показателях суммы.

Задача решается тем, что на каждую рекламную акцию заводится свой атрибут, была она или нет.

Скажем, есть семь возможных акций. Это 2^7, то есть всего-то 127 комбинаций. Мы можем сделать признак рекламная акция от 0 до 127 и грузить его в куб. У него уже будут атрибуты "Скижка пенсионерам" "Карта любимого покупателя" и так далее.