powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / отношение "многие ко многим"
33 сообщений из 33, показаны все 2 страниц
отношение "многие ко многим"
    #32980192
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
как то пришел к выводу, что при отношении "многие ко многим" между таблицей фактов и таблицей предполагаемого измерения, - измерение не включается в куб, так до сих пор и думаю. И по этой причине "Тип товара" у иеня не используется в OLAP'е, к большому сожалению. Кто нибудь как-то нашел выход?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980220
Tsaryov S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У тебя один факт относится сразу к нескольким типам товара?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980258
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
да, получается так. Факт связан с товаром (1:М), а товар с типом товара как М:М
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980415
Oleg Perekhrest
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Интересно было бы услышать на примере :-)

Вообще-то отношение между двумя таблицами вида M:M, имеет место быть только в логической модели данных. В физической модели данных, оно всегда реализуется через дополнительную таблицу, связь с которой получается вида 1:M и M:1.
В данном случае, отношение M:M скорее всего не между таблицей фактов и измерений, а между измерением и еще одним измерением.

Но интересен момент: факт сам по себе не может существовать, он должен чтото характеризировать, например для факта "оборот по счету" должно быть измерение "счет", чтобы определить оборот по какому счету. Конечно например если просуммировать все обороты по всем счетам, тогда измерения "счет" уже не будет, но могут появится другие измерения например "период суммирования". Чтобы вообще не было измерения, практически не реально, даже в агрегатах как минимум бывают измерения: ид.времени и ид.филиала.
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980641
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
в AS 2005 заявлено что такие вещи поддерживаются автоматом

в AS 2000 решал следующим образом:
1. схема :
Тип(...); ТипТовара(Тип_ID, Товар_ID); Товар(...); Факт(...Товар_ID...)
я правильно понял?
2. на ней создается обычное измерение Тип->Товар
3. в Тип добавляется элемент "Все" который назначается всем товарам; этот элемент делается элементом по умолчанию в измерении
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980804
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
олапист
1. схема :
Тип(...); ТипТовара(Тип_ID, Товар_ID); Товар(...); Факт(...Товар_ID...)
я правильно понял?

Да, все верно (правда там еще "марка товара" затесалась, но не суть).
Дело в том, что "Тип товара" - иерархическое измерение
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980821
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл уточнить что у меня MS AS 2000.
хотя интересно выслушать и про подобный опыт на других системах.
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32980922
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
optimizer олапист
1. схема :
Тип(...); ТипТовара(Тип_ID, Товар_ID); Товар(...); Факт(...Товар_ID...)
я правильно понял?

Да, все верно (правда там еще "марка товара" затесалась, но не суть).
Дело в том, что "Тип товара" - иерархическое измерение

В смысле parent-child? Тогда видимо никак - в AS 2000 нельзя смешивать различные типы измерений parent-child и snowflake

А если имеется ввиду что Тип(....Тип, Подтип, ...) то видимо придется перейти к схеме
Тип( Тип ); ТипТовара(Тип_ID, Товар_ID);
ПодТип( ПодТип ); ПодТипТовара(ПодТип_ID, Товар_ID);
и сделать 2 отдельных измерения для типов и для подтипов
иначе не понятно как исключать из агрегатов товары попадающие в несколько подтипов
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32981169
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
олапист
иначе не понятно как исключать из агрегатов товары попадающие в несколько подтипов


про это и был вопрос, мало ли, вдруг кто-то извернулся
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32981642
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 олапист
а что подразумевали под этим?
олапист
в AS 2000 нельзя смешивать различные типы измерений parent-child и snowflake
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32981659
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
то что измерение может быть либо parent-child либо star либо snowflake, но нельзя сформировать измерение наполовину из parent-child таблиц наполовину из star таблиц
хотя рад буду ошибиться
кстати как с этим в Yukon?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32983234
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
но как два отдельных измерения связанных с собой можно.
Наприме: есть измерение "организация", и есть отдельное измерение "География", которая выходит на факты через организацию.
А вот у организации есть еще связь М:М с иерархическим измереним "Отрасль", которую я также как и "Тип товара" не могу включить в ОЛАП
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32983561
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мне кажется, что с помощью custom rollup можно решить задачу. Никому в голову MDX не приходит?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32983742
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ну вот еще есть способ
1. ТипТовара делаем кубом и объединяем его с основным в вируальный
2. меры переопределяем примерно вот так

SUM(Extract(Distinct(NonEmptyCrossJoin({[Тип].CurrentMember}, [Товар].[Товар].AllMembers)), [Товар]), ValidMeasure([Measures].[Мера]))
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986397
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чего то у меня не получилось таким образом. Буду вам благодарен за более подробное разъяснение
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986584
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
что конкретно не получилось? :)
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986668
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что означает олапист1. ТипТовара делаем кубом ?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986740
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
создаем куб используя в качестве таблицы фактов таблицу ТипТовара из вышеприведенной схемы. какие в нем будут определены меры - не важно
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986892
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а в качестве измерения для данного куба что брать? "Тип"?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986906
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
два измерения: Тип и Товар
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32986974
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
все равно не получилось. общая сумма СМ в 2 раза больше получается
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32987040
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
странно странно
вот "улучшенный" вариант

Sum(Distinct(Extract(NonEmptyCrossJoin({[Тип].CurrentMember}, Descendants([Товар].CurrentMember, [Товар].[Товар])), [Товар])),
ValidMeasure([Measures].[Мера]))
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32987406
Владимир Штепа
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
optimizerвсе равно не получилось. общая сумма СМ в 2 раза больше получается

А у вас куб случайно не виртуальный?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990151
Tsaryov S
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если товары и типы относятся "многие-ко-многим", значит, один товар может быть разных типов. Что означает, должна быть привязка, например в таблице фактов, какой тип используется в каждом конкретном факте. Что опять же означает, что тип - независимое от товара измерение.
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990283
Фотография Добрый Эх
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
optimizer.... хотя интересно выслушать и про подобный опыт на других системах.
....
optimizerвсе равно не получилось. общая сумма СМ в 2 раза больше получается

поделюсь опытом
в BO это разруливается контекстами + меры берутся из алиасов, система сама разбивает данные на кубы, а фактически на разные SQL запрсы и на уровне отчетов вяжет эти кубы и ни каких замножений не происходит.
Минус этого метода - большой объем данных сваливается на клиента и при этом он должен еще их провязать, зато ни каких замножений
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990490
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 олапист

делаю вот так, вроде как вы и говорили

1. создаю куб
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990491
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990499
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
это существующий куб, реальный, а не виртуальн
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990512
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
потом объединяю их, создавая виртуальный куб, а виртуальном создаю следующий СМ

SUM(Extract(Distinct(NonEmptyCrossJoin({[Тип товара].CurrentMember}, [Товар].AllMembers)), [Товар]), ValidMeasure([Measures].[Total Sum]))
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990629
олапист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
все же рекомендую заменить на более корректный вариант

Sum(Distinct(Extract(NonEmptyCrossJoin({[Тип Товара].CurrentMember}, Descendants([Товар].CurrentMember, [Товар].[Товар])), [Товар])),
ValidMeasure([Measures].[Total Sum]))

не получится - кидайте в мыло cab, добъем проблему до победного конца :)
olapist@gmail.com
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990632
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
в итоге СМ считается неверно. Я что-то не так вас понял, олапист?
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32990735
Возможно, поможет, а может и не очень. Особенно не вчитывался, просто что-то похожее на умножение меры при множественной связи между таблицей фактов и измерением возникало и у меня: когда при множественной связи между измерением время и таблицей фактов (по месяцу) значение меры четко умножилось на 28, напрягся, включил DrillThrough, ну и понятно, что месяц оказался февраль, и каждая строка таблицы фактов, связанная с февралем, продублировалась 28 раз, по количеству элементов нижнего уровня в элементе "февраль" измерения времени. Пришлось связать не с месяцем, а первым днем месяца.
...
Рейтинг: 0 / 0
отношение "многие ко многим"
    #32991131
Фотография optimizer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
олапист, премного вам благодарен!
...
Рейтинг: 0 / 0
33 сообщений из 33, показаны все 2 страниц
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / отношение "многие ко многим"
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]