|
|
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
Есть долгоживущий куб в котором решили произвести некоторые изменения. В связи с этим возникла следующая проблема - ранее один ID продукта мог входить только в одну группу продуктов и все итоги считались простым суммированием, IDPRODGR1AAAA2BBBB3CCCC теперь один продукт может входить в разные группы продуктов и тем самым в общий итог по группам его количество попадает столько раз, в сколько групп он входит. IDPRODGR1AAAA2BBBB2BBBC3CCCC3CCCA Как написать суммирование с условием где будет делаться исключение повторов. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 13:23 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist Как написать суммирование с условием где будет делаться исключение повторов. Спасибо. Это все определяется правильной моделью данных. Надо делать строгие иерархии, а для этого надо вводить суррогатные ключи. А под AAA -- один ключ А под ССС -- другой ключ Далее вы можете с делать строгое дерево и на нем все просуммируется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 13:45 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, т.е. вы сами их в источнике задублировали для того чтобы потом считать уникальные? других вариантов не придумали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 13:46 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor, Еще не задублировали. Но группы в SQL базе придется вести по новой концепции, а значит, как только ее введем, во вьюхе на которой сидит процессинг куба, данные и задвоятся, и затроятся и т.д. со всеми вытекающими... Давайте предоложите поумнее решение, чувствую оно у вас есть :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 14:13 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
a_voronin, Т.е. нужно переделать структуру куба. Не получится обойтись какой нить волшебной mdx функцией? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 14:17 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, Гуглите "<ваше ПО> многие-ко-многим" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 14:38 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
Критик, Не кажется вам что ваш ответ никому не будет полезен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 14:45 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, M2M, Как Вам и сказали ранее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 14:46 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist a_voronin, Т.е. нужно переделать структуру куба. Не получится обойтись какой нить волшебной mdx функцией? За любым кубом стоит хранилище данных. Сделайте его корректно. И проблем у вас не будет. Вы говорите Зеленоград относиться у меня к Москве и к Московской области одновременно. Как мне сделать так, чтобы Зеленоград не считался дважды? Ответ -- решите где у вас Зеленоград, Решите Пупкин из 3 квартиры 7го дома на Нной улице Зеленограда у вас живет в Москве или в МО. И тогда ничто не будет суммироваться дважды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 15:24 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, решение обсуждали недавно MDX урезанный показатель но это с переделкой структуры. без переделки, можно. в SQL это выглядело бы так: Вы по каким-то причинам не хотите или не можете добавить поле и/или справочник в базу. будет несколько подзапросов для суммирования GR, в каждом необходимо будет указать PROD его составляющий. и так каждый раз при каждом изменении параметров отчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 15:25 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor formalist, решение обсуждали недавно MDX урезанный показатель но это с переделкой структуры. без переделки, можно. в SQL это выглядело бы так: Вы по каким-то причинам не хотите или не можете добавить поле и/или справочник в базу. будет несколько подзапросов для суммирования GR, в каждом необходимо будет указать PROD его составляющий. и так каждый раз при каждом изменении параметров отчета. Через DYNAMIC SETS и EXISTING все тормозит. На уровне БД с предрасчетом гораздо быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 15:36 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
a_voronin formalist a_voronin, Т.е. нужно переделать структуру куба. Не получится обойтись какой нить волшебной mdx функцией? За любым кубом стоит хранилище данных. Сделайте его корректно. И проблем у вас не будет. Вы говорите Зеленоград относиться у меня к Москве и к Московской области одновременно. Как мне сделать так, чтобы Зеленоград не считался дважды? Ответ -- решите где у вас Зеленоград, Решите Пупкин из 3 квартиры 7го дома на Нной улице Зеленограда у вас живет в Москве или в МО. И тогда ничто не будет суммироваться дважды. Менеджмент захотел ввести аналитику по новым группам товаров и оказалось что недостаточно определиться с положением условного Зеленограда. Потому что сегодня может возникнуть группа "Города где есть улица Nская" и условный Зеленоград попадет в эту группу весьма вероятно. Завтра введут группу "города где меньше 100 автобусов" и туда он так же может угодить. И процесс создания и ликвидации групп вне контроля. Недосягаем. Значит надо чет сделать на том уровне где я могу попытаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 15:59 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor, Я не имел дела с кубами до текущего момента. Переделки на стороне SQL это быстро можно сделать, но я хочу сделать как правильно. Хочется или уж переделать так чтобы все качественно изменилось (суррогатные ключи ввести вместо терабайт текста, например) или прям чуть слегка почти совсем не трогая ввести это обновление и перекреститься и за другие дела взяться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 16:04 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, правильно - это как хочет менеджмент, ваша задача предложить реализацию. а какими средствами и ресурсами это Вам решать. Вариантов масса. В т.ч. убедить бизнес, что ему это не надо, тоже вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 17:50 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor, Правильно именно в плане реализации потому что бизнес это другой уровень и разговор с бизнесом это нелепое занятие. С бизнесом также как с детьми или не заводить или все для них делать. Я просто не хотел играть в эти кубики и думал отделаться малой кровью но видимо не выйдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2020, 18:03 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist a_voronin пропущено... За любым кубом стоит хранилище данных. Сделайте его корректно. И проблем у вас не будет. Вы говорите Зеленоград относиться у меня к Москве и к Московской области одновременно. Как мне сделать так, чтобы Зеленоград не считался дважды? Ответ -- решите где у вас Зеленоград, Решите Пупкин из 3 квартиры 7го дома на Нной улице Зеленограда у вас живет в Москве или в МО. И тогда ничто не будет суммироваться дважды. Менеджмент захотел ввести аналитику по новым группам товаров и оказалось что недостаточно определиться с положением условного Зеленограда. Потому что сегодня может возникнуть группа "Города где есть улица Nская" и условный Зеленоград попадет в эту группу весьма вероятно. Завтра введут группу "города где меньше 100 автобусов" и туда он так же может угодить. И процесс создания и ликвидации групп вне контроля. Недосягаем. Значит надо чет сделать на том уровне где я могу попытаться. я вот не до конца понял аналитику по новым группам товаров и определиться с положением условного Зеленограда если меняется скажем дименшен города (страны) и т .д появилась новая группа 1) города из 1,2,3,4,5 букв 2) Зеленые города добавили поле в ETL для каждлого случая таблица DimGorod pole1 { 3,4,5,6 } pole2 {зеленые , красные , Синие } изменили дименшен город добавив новые атрибуты пересторили FULL куб и все Сделать группы динамически - я допустим не знаю как - не уверен что это возможно (но м.б кто-то и делал - можно уточнять ) а по переоначальной проблеме - да читайте про M2M есть классный док на английском https://www.sqlbi.com/blog/marco/2011/11/09/the-many-to-many-revolution-2-0-ssas-mdx-dax-m2m/ но для начала поставьте стандартный пример AdventrureWorks - там тоже пример есть M2M ps и да вам придется менять гранулярность - считать как вам сказали на уровне продукт-группа - соответсвтенно структуру куба переделыавть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 12:06 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
Гулин Федор, приведу показательный пример из практики, когда делал M2M. Есть товар с его кодом. У товара есть характеристики. У монитора размер и разрешение, у носков цвет и размер, у утюга мощность, режим отпаривания и т.п. Всего 500+ видов характеристик. 3-40 у одного товара. И вот бизнес хочет искать "товары красного цвета" "Товары 45 размера" "товары с режимом отпаривания" Тут вы делаете измерение "товар" и от него m2m на характеристики товара. И прекрасно можете гонять в Excel раскладывая по характеристикам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 12:30 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
a_voronin, но у ТС задача немного расширенная предположим, у меня под эти три характеристики попадает только один товар, то получается немного не то All = 3 -"товары красного цвета" = 1 -"Товары 45 размера" = 1 -"товары с режимом отпаривания" = 1 А надо All = 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 13:09 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor a_voronin, но у ТС задача немного расширенная предположим, у меня под эти три характеристики попадает только один товар, то получается немного не то All = 3 -"товары красного цвета" = 1 -"Товары 45 размера" = 1 -"товары с режимом отпаривания" = 1 А надо All = 1 В моем примере Носки имеют цвет, Штаны имеют цвет, утюг может иметь цвет. Если вы сделает от товара на характеристики товара Reference , то будет 3. А вот если M2M, то будет 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 13:48 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
a_voronin, Если Товары.All - то да, 1, а Характеристики.All (именно в случае m2m) = 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 16:35 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
ShIgor a_voronin, Если Товары.All - то да, 1, а Характеристики.All (именно в случае m2m) = 3. А что такое 3? Вот есть мера "продано руб" Продано на 1000 руб красных носков, на 2000 руб красных трусов и на 3000 руб красных утюгов. Мы ставим в фильтр характеристика красное. Красное идет M2M --> товар regular -> факт "продано руб". Что вы получите в "продано руб"? Либо есть count от строк. Носков 5, трусов 3, утюгов 2. Что получим в count против красного? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 16:43 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
a_voronin, нет, наоборот у нас есть утюги = 5 красные = 1 с керамической подошвой = 2 в all должно быть 5, а не 6 и не 7, и уж точно не 8 в Вашем же случае они действительно будут равны = 10 и m2m тут особо не нужен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2020, 17:06 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
Гулин Федор есть классный док на английском https://www.sqlbi.com/blog/marco/2011/11/09/the-many-to-many-revolution-2-0-ssas-mdx-dax-m2m/ ага я посмотрел. спасибо, это интересно Гулин Федор ps и да вам придется менять гранулярность - считать как вам сказали увы a_voronin И вот бизнес хочет искать "товары красного цвета" "Товары 45 размера" "товары с режимом отпаривания" В моем случае это не объективные характеристики продукта, а просто воля менеджмента. Менеджмент ведет справочник групп GR_IDGR1ААА2БББ3ВВВ Справочник продуктов PROD_ID PROD1 ННН2 ЗЗЗ3 ЯЯЯ Количество и состав групп определяют и переопределяют, практически каждый день, некие менеджеры "простопотомучтотакаядолжнабытьгруппа" GR_IDPROD_ID1 11 22 13 12 2 я уже начал делать новый куб. старый основывался только на таблице фактов (ни звезда, ни снежинка, а просто одна вьюха и все поля текстовые. вот так вот) надеюсь с этими советами одолеть задачу и сделать нормально или лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2020, 10:41 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, ну это классический м2м последняя таблица бридж на самом деле я всего 2 раза делал m2m (последний раз год+ назад) И оба раза мучительно вспоминал как оно делается правильно там вроде не сложно но и не тривиально и я сходу не могу сообразить какую меру делать (count , count distinct ) на бридже ее по моему надо делать hidden а SSAS на рабочем компе нет и установить его нельзя (соответсвтенно и проектов тоже) вообщем находите хороший пример и делайте по образу и подобию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2020, 11:43 |
|
||
|
Итог по уникальным ID
|
|||
|---|---|---|---|
|
#18+
formalist, Я именно подобную задачу не решал, но были другие, где надо было M2M использовать. SSAS умный и если правильно спроектировать М2М - все посчитает правильно. )) Но! Сразу предупреждайте пользователей, что если они выведут список групп с суммами, общий итог не совпадет, если просуммировать итоги по каждой группе. Это, собственно говоря, так и должно быть (убираем повторы), но люди часто забывают об этой особенности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2020, 12:18 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=39986978&tid=1857275]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
73ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 407ms |

| 0 / 0 |
