Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
Подскажите пожалуйста, люди умные. Есть таблица, где отображаются движение ден. средств: дата направление (приход - расход) сумма валюта место (касса, руб. счет, USD счет..) отдел Есть также значение в БД - остаток, начальная сумма, причем в единичном виде, т.е на одну дату (xxxx.xx руб, $xxxx.xx ...). Необходимо создать куб для нерегламентированных запросов, где в качестве мер будут - остатки, сумма прихода, сумма расхода. Во первых волнует структура таблицы, правильно ли сделал, что не разделил приход и расход по разным полям, а сделал поле направление. Во вторых смущает поле валюта, т.к суммировать так просто рубль с евро неестественно. Есть ли смысл менять таблицу? И вообще, как дальше быть с мерами, какие у них MDX- выражения должны быть? Заранее благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:21 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
1. остатки лучше считать в OLAP'e, а не в СУБД 2. у измерения "валюта" просто не должно быть уровня ALL. В остальном всё нормально ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 12:46 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
ИМХО еслин е транснациаональная компания, то скорее всего используется Рубль,Доллар,Евро. Проще сделать -СуммаРубль -СуммаДоллар -СуммаЕвро Места не убавиться Направление - это красиво, но тут все зависит от грамотности персонала. ИМХО объяснять что нужно по горизонтали мышкой развертывать еще один уровень ежели нужно сравнить приход с расходом - не до всех дойдет. Для "своих" проще сделать -Сумма Прихода Рубль -Сумма Прихода Доллар -Сумма Прихода Евро -Сумма РАсхода Рубль ... Громоздко, но зато каждому кассиру понятно. Опять же что за отчеты в дальнейшем надо будет делать, какой анализ...? Ну и ID Надеюсь у Вас - суррогатный int ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 13:03 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
Quark -СуммаРубль -СуммаДоллар -СуммаЕвро -Сумма Прихода Рубль -Сумма Прихода Доллар -Сумма Прихода Евро -Сумма РАсхода Рубль ... все эти вещи можно сделать расчетными без изменения структуры таблицы Dmitry Biryukov1. остатки лучше считать в OLAP'e, а не в СУБД далеко не факт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 13:40 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
олапист Dmitry Biryukov1. остатки лучше считать в OLAP'e, а не в СУБД далеко не факт Ну давайте поспорим: 1. если остатки считать в СУБД, то надо писать спец. процедуру и/или тригеры. В ОЛАПе делать использовать Rollup типа LastChild. Ну и сумировать остатки нельзя. Да ещё и хранить их на каждый день - места сколько. 2. если в ОЛАПе - доп. процедур в СУБД не надо, для подсчёта остатков используется банальный CM. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 14:59 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
если остатки считать в СУБД, то надо писать спец. процедуру и/или тригеры. только если OLAP цепляется напрямую к OLTP а не к DWH, в котором все необходимые ETL-процедуры должны быть написаны по определению В ОЛАПе делать использовать Rollup типа LastChild. Почему обязательно Rollup, достаточно банального CM Ну и сумировать остатки нельзя. А какие проблемы? Да ещё и хранить их на каждый день - места сколько. Согласен, в некоторых случаях на каждый день будет крайностью. В таких случаях ищется компромиссный вариант - например на начало месяца. 2. если в ОЛАПе - доп. процедур в СУБД не надо, для подсчёта остатков используется банальный CM. при определенном количестве транзакций этот СМ либо будет тормозить, либо потребует создания агрегатов, которые так же требуют места для хранения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 16:11 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
олапист если остатки считать в СУБД, то надо писать спец. процедуру и/или тригеры. только если OLAP цепляется напрямую к OLTP а не к DWH, в котором все необходимые ETL-процедуры должны быть написаны по определению проще делать DWH без предрасчитанных остатков олапист В ОЛАПе делать использовать Rollup типа LastChild. Почему обязательно Rollup, достаточно банального CM ОК. по этому показателю уравнялись олапист Ну и сумировать остатки нельзя. А какие проблемы? остаток за первый квартал не равен сумме остатков за янв,фев,март. олапист Да ещё и хранить их на каждый день - места сколько. Согласен, в некоторых случаях на каждый день будет крайностью. В таких случаях ищется компромиссный вариант - например на начало месяца. олапист 2. если в ОЛАПе - доп. процедур в СУБД не надо, для подсчёта остатков используется банальный CM. при определенном количестве транзакций этот СМ либо будет тормозить, либо потребует создания агрегатов, которые так же требуют места для хранения Пусть время будет год-месяц-день. Для получения остатка на любую дату надо будет сложить всего лишь несколько чисел: 1 - по предшествующим годам (пусть в среднем 5 таких чисел) 2 - по предшествующим месяцам года (пусть в среднем 6 чисел) 3 - по предшествующим дням месяца (пусть в среднем 15 чисел) подсчёт остатков - 26 операций сложений - совсем не много ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 17:10 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
Пусть время будет год-месяц-день. Для получения остатка на любую дату надо будет сложить всего лишь несколько чисел: 1 - по предшествующим годам (пусть в среднем 5 таких чисел) 2 - по предшествующим месяцам года (пусть в среднем 6 чисел) 3 - по предшествующим дням месяца (пусть в среднем 15 чисел) подсчёт остатков - 26 операций сложений - совсем не много только при условии если OLAP-сервер хранит или кэширует эти агрегаты! и агрегатов этих должно быть 5*6* (количество элементов измерения Продукты) * (количество элементов измерения Склады) (если говорить о складских остатках, но и при анализе ДДС тоже появится достаточное количество своих аналитик - контрагенты, отделы и т д) в итоге получаем тот же обьем данных которые необходимо где-то хранить (при том что операций в случае хранения в субд будет 16 против 26 :) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 17:39 |
|
||
|
движение денежных средств
|
|||
|---|---|---|---|
|
#18+
Спасибо за участие. Сделал следующее: создал представление, где разделил на два поля сумму (сумма прих., сумма расх.); создал CM "delta" как: [Measures].[Sum In]-[Measures].[Sum Out]; поставил в No значение свойства All level у "Валюта" и "Место" Подскажите теперь как остатки считать, имея остаток лишь на одну дату (константа), т.е на начало учета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 11:16 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32899086&tid=1871828]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
41ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 353ms |

| 0 / 0 |
