|
|
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
День добрый! Хочу посоветоваться с опытными коллегами, как лучше сделать архитектуру для таблицы типа: Дата1 Месяц1 Сумма1 Статус1 Пользователь1 Дата2 Месяц1 Сумма2 Статус2 Пользователь1 Дата3 Месяц2 Сумма3 Статус1 Пользователь2 Дата4 Месяц2 Сумма4 Статус1 Пользователь2 И тд Сложность(?) в том что суммы по пользователю складывать нельзя, но хочется решать вопросы вроде: 1. Получить последнюю сумму по статусу1 для каждого пользователя и сложить их суммы. В таком случае я думала использовать разную группировку по dimension, я как понимаю если есть календарь иерархичный это сработает как если бы искать аналитически максимальную дату и потом сумму к ней. Но я еще не проверяла. Какие могут быть нюансы при такой структуре? Просто таких статусов много и почти по каждому высчитывать отдельный показатель, а там не только сумма, а еще количество и тд, мне кажется не круто. 2. Еще хотят, более сложный вариант, когда нужно найти последнюю дату по статусу1 по каждому пользователю, но так чтобы был предыдущий статус2 и не обязательно последовательно предыдущий. Тут мне в голову пришло только именно отдельно держать поле по необходимым пред. Статусам, но это конечно далеко неидеальный вариант:) Буду рада любой помощи, может есть какие-то статьи на подобную тему, я к сожалению не смогла найти. Ну и вообще если имели опыт с подобными решениями, как не собрать все грабли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2017, 00:27 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
А в чем именно проблема и почему нельзя сделать так как вы нарисовали? Только зачем отдельное поле с месяцем хранить? Я так понимаю, что ваша табличка вполне может выглядеть как фактовая без партиционирования по дате, так как нужно будет сканировать вашими запросами точно не одну, две партиции в таком случае. Проиндексируете поле с ссылкой на измерение с пользователем, статусом и все по большому счету. Если думаете о том, что ID пользователя в _F таблице будет меняться, то у него есть должен быть неизменный идентификатор в самом dimension, который и будете использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2017, 06:26 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
Be or not to be..., Просто я такое решение не проверяла, и боюсь что что-то упустила, либо будет слишком медленно считаться. Я конечно потестирую, но хотелось бы послушать тех у кого это используется в бою. Месяц нужен для партиций по периоду, и в рамках него будет искаться последняя дата по статусу, а не по всей таблице. А вообще мне просто непривычно делать хранилище по датам, а не по месяцам, причом именно в формате "лога", а не на конец месяца, думала может посоветуют что почитать с подобными примерами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2017, 19:09 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
не нужно хранить месяц в фактовой таблице только ради партишенинга, его можно и по дате сделать верхние уровни иерархий хранят отдельно обычно если показатель неаддитвен (как у вас с пользователями получилось) т.е. если сумма за все дни месяца не равна данным за месяц и их нужно хранить отдельно, редко но бывает сделайте нормальный dimension даты и свяжите его с фактом, имеет смысл подумать об отдельном dimension с пользователем и статусом, по пользователю факт неаддитивен, может получится его аттрибутом сделать? нужно собрать все пожелания по запросам и покрутить их, на основе одного запроса много выводов не сделаешь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.09.2017, 13:50 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
Nenormalka, Вам, конечно, виднее о сути ваших сущностей, но кажется, что партиционирование по дате как раз таки вполне классическое. А если нужны и дневные, и месячные факты, то строятся месячные агрегаты. Но, опять же, это зависит от приходящих запросов. Для таблиц типа операций, платежей и всего прочего чаще всего вообще не уместно партиционирование, так как запросы могут спрашивать данные как за день, так и за месяц, 20 дней, "дату последнего погашения", "дата первой выдачи" и т.п., что все-равно приведет к полному сканированию таблицы. Сколько данных у вас, скажите? Может, там 100к строк всего навсего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2017, 06:39 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
Be or not to be..., попробовала в итоге на примере и не работает это:( Dimension...Formula Other............SUM("ModelName"."F actTableName".Sales) Date.............LAST("ModelName"." FactTableName".Sales) То есть он берет последнюю сумму в периоде, например за два месяца, но не учитывает пользователя, всячески пыталась ему подсунуть пользователя, но не получилось:( Может быть кто-то знает как это сделать? Хочу из такого набора данных: Дата1 Месяц1 Сумма1 Статус1 Пользователь1 Дата2 Месяц1 Сумма2 Статус2 Пользователь1 Дата5 Месяц2 Сумма5 Статус1 Пользователь1 Дата3 Месяц2 Сумма3 Статус1 Пользователь2 Дата4 Месяц2 Сумма4 Статус1 Пользователь2 Получить при выборе Месяца1 и Месяц2, где статус=Статус1: Сумма5+Сумма4 Можно вообще такое сделать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 16:23 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
~ Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 17:06 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
orawish, Замечательный запрос, я такие тоже писать умею:) но вопрос то как это сделать в OBIEE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.09.2017, 20:44 |
|
||
|
Архитектура для Oracle BI
|
|||
|---|---|---|---|
|
#18+
Nenormalka, самый лучший ответ, самой себе видимо:) Вдруг кому пригодится, ибо мне порядок показался странным. Чтобы би именно сложил суммы по пользователю, потом взял их по последней дате и потом опять сложил порядок нужно указать такой -> Others sum(), dim_calendar last(), dim_пользователь sum() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.09.2017, 13:04 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=146&tid=1885261]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 223ms |
| total: | 332ms |

| 0 / 0 |
