Мой ответ учитывает, что вы не хотите переформатировать свои данные в традиционную схему хранилища данных.Если это продвинет вас дальше по пути, тогда это хорошо для вас, но я подозреваю, что по мере развития проекта вы столкнетесь с большим количеством этих проблем.Возможно, стоит подумать над тем, как преобразовать данные в схему типа «звезда», прежде чем она вам понадобится.
Я могу предложить несколько вариантов.Первое, что приходит на ум, - это создать вырожденное измерение в кубе счетов, основанное на таблице фактов платежей.Следующий пример отвечает на вашу проблему «все аккаунты, у которых есть платеж», но это должно работать для похожих вопросов.Я принял дату выписки по счету за последний день каждого календарного месяца, поэтому вам нужно будет считать платежи, сделанные за каждый календарный месяц.
create table accounts_fact
( account_id int not null,
statement_date datetime not null,
bal int not null,
constraint acc_pk primary key (account_id, statement_date)
)
create table payments_fact
( account_id int not null,
payment_date datetime not null,
amount money not null
)
insert into accounts_fact values (1, '20100131', 100)
insert into accounts_fact values (1, '20100228', 120)
insert into accounts_fact values (1, '20100331', 0)
insert into accounts_fact values (2, '20100131', 100)
insert into accounts_fact values (2, '20100228', 20)
insert into accounts_fact values (2, '20100331', 50)
insert into accounts_fact values (3, '20100131', 10)
insert into accounts_fact values (3, '20100228', 30)
insert into accounts_fact values (3, '20100331', 50)
insert into payments_fact values (1, '20100112', 50)
insert into payments_fact values (1, '20100118', 60)
insert into payments_fact values (1, '20100215', 70)
insert into payments_fact values (1, '20100318', 80)
insert into payments_fact values (1, '20100331', 90)
insert into payments_fact values (2, '20100112', 50)
insert into payments_fact values (2, '20100215', 60)
insert into payments_fact values (2, '20100320', 70)
insert into payments_fact values (3, '20100101', 50)
insert into payments_fact values (3, '20100118', 60)
insert into payments_fact values (3, '20100318', 70)
create view dim_AccountPayments
as
select acc.account_id, acc.statement_date,
sum(case when pay.payment_date IS NULL THEN 0
else 1
end) as payment_count
from accounts_fact acc
left outer join payments_fact pay on acc.account_id = pay.account_id
and pay.payment_date >= dateadd(mm, -1, dateadd(dd, 1, acc.statement_date))
and pay.payment_date <= acc.statement_date
group by acc.account_id, acc.statement_date
select * from dim_AccountPayments
Это дает следующие результаты:
account_id statement_date payment_count
1 2010-01-31 00:00:00.000 2
1 2010-02-28 00:00:00.000 1
1 2010-03-31 00:00:00.000 2
2 2010-01-31 00:00:00.000 1
2 2010-02-28 00:00:00.000 1
2 2010-03-31 00:00:00.000 1
3 2010-01-31 00:00:00.000 2
3 2010-02-28 00:00:00.000 0
3 2010-03-31 00:00:00.000 1
Теперь создание куба платежей в кубе учетных записей должно быть пустяком.Чтобы получить дополнительные баллы, удалите группу и суммируйте в представлении, чтобы позволить SSAS выполнить агрегацию;мне подошло показать таблицу результатов выше.Используйте представление SQL в представлении источника данных, у вас нет разрешения на создание представления в исходной базе данных.
Вариант 2 - подсчет платежей из представления выше показателя в кубе счетов.Вы можете сделать это аналогично приведенному выше решению, за исключением того, что факт ваших счетов использует представление, аналогичное dim_AccountPayments.На этот раз вы должны сгруппировать по всем ключевым полям и агрегировать меры в базе данных ... Очень некрасиво.Я не рекомендую его, но это возможно.
Если вы выберете вариант 1, то достаточно просто создать именованный набор в измерении платежей по счету под названием «Внес платеж в этом месяце», который является дочерним для всехотфильтрованный, чтобы удалить 0.
Надеюсь, я понял ваш вопрос.Мне пришлось сделать довольно много предположений о ваших структурах данных, но я надеюсь, что это полезно.
Удачи.