Статья :
Информационная система и реляционная СУБД

Автор(ы): Владислав Чистяков

Авторы :
Владислав Чистяков

Аннотация :
Итак. "Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого". Уберем из этого определения плохо детерминированное понятие "хозоперация" и введем понятие "проводка". Так всем будет понятнее. Получится: "Каждая проводка подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого".

Из статьи я так и не понял как получить агрегрированные результаты по группировкам запроса. Можно поподробнее...

Здравствуйте, <Аноним>, Вы писали:

А>Из статьи я так и не понял как получить агрегрированные результаты по группировкам запроса. Можно поподробнее...

Честно говоря, не очень понял вопрос. Попробую ответить, как понял...

В статье приведены общие принципы создания агрегатных (OLAP) таблиц для нормализованной структуры хранящей проводки (двойную запись) в полностью нормализованном виде. Собственно статья родилась в ходе одного бурного обсуждения на этом сайте. Не помню кто, но кто-то утверждал, что проводки невозможно эффективно хранить и обрабатывать в реляционных СУБД.

Важно понимать, что это не законченное решение. Я пытался донести сам принцип. Создание индексированных view содержащие агрегированную информацию для решения проблемы сложности расчетов. Причем эта информация должна быть заведомо более рыхлая, нежели конечный запрос. Таким образом, чтобы конечную информацию можно было вычислить путем повторной агрегации. Весь смысл в том, что расчет по индексированным view на несколько порядков более быстр чем по основной таблице, и в том, что информация преобразовывается, скажем так, в OLAP-вид.

PS

Кстати, в теме нет ссылки на статью. Вот на всякий случай Информационная система и реляционная СУБД

Автор(ы): Владислав Чистяков

.

Здравствуйте, Владислав Чистяков
Если бы кто-то на пальцах объяснил мне, то я был бы очень благодарен.

Смотрим на схемку


У нас в Ref есть например "Поставщики"
В Z2Ref есть запись
Поставщики — Петек
Поставщики — Нюрка

"Предположим теперь, что нам нужно получить обороты для" Петек и Нюрка
т.е. переписываем из статьи запрос

SELECT Agr.Z, Ref.RefName AS Name, Agr.Db, Agr.Cr
   FROM (SELECT ISNULL(DbS.idRef, CrS.idRef) AS Z, 
                ISNULL(CrS.CrSum, 0) AS Db, 
                ISNULL(DbS.DbSum, 0) AS Cr
            FROM (SELECT Z2Ref.idRef, 
                         SUM(Oper.OperSum) AS DbSum
                     FROM Oper INNER JOIN
                          Z ON Oper.Db = Z.idZ
                        INNER JOIN
                          Z2Ref ON Z.idZ = Z2Ref.idZ
                     WHERE (Z2Ref.idRef IN (3,7))
                     GROUP BY Z2Ref.idRef
                 ) DbS
               FULL OUTER JOIN
                (SELECT Z2Ref.idRef, 
                        SUM(Oper.OperSum) AS CrSum
                     FROM Oper INNER JOIN
                          Z ON Oper.Cr = Z.idZ 
                        INNER JOIN
                          Z2Ref ON Z.idZ = Z2Ref.idZ
                     WHERE (Z2Ref.idRef IN (3,7))
                     GROUP BY Z2Ref.idRef
                ) CrS
               ON DbS.idRef = CrS.idRef
        ) Agr 
        INNER JOIN Ref ON Agr.Z = Ref.idRef

Но проводки по Z — Поставщики получается что учитываются суммарные для каждого из выбираемых представителя Ref
Т.е. по связи между Z и Oper нельзя никак сказать о том к какому именно RefId относится OperId


Заранее спаибо за разъяснения