SSAS cube с флагами и счетами на самом деле Таблица

Question

Я пытаюсь создать куб для открытия банковского счета. Таблица фактов будет включать следующие поля.

Fact_Clnt_Dtls 

BankID 

BranchID 

PINCode 

RMID (relationship manager) 

Holder_indicator (1,2,3) 

Client_status (1=Active, 2=dormat, 3= closed) 

SMS_Flg (Y/N) 

SMS_Flg_count 

Nomination_Flg (y/n) 

Nomination_Flg_count 

Auth_sign_flg (Y/N) 

Auth_sign_flg_count 

Total_Clients (bank id wise count of all clients) 

and many more flags 



The DIM tables are as below 

DIM_Bank_Mstr 

BankID 

Bank_Name 

PINCode 

Activation_date 



DIM_RM_Mstr 

RMID 

RM_Name 

BankID 

PINCode 

RM_HOD 



DIM_PIN_Code_Mstr 

PINCode 

Zone 

District 

State 

City 

DIM_Zero_Bal_acct - (выяснить, до, как долго счет был с нулевым балансом и, когда счет была зачислена)

BankID 

ClientID 

Activation_Date 

First_credit_date 

Является ли это правильный дизайн, как у меня есть различные флаги и счетчики в таблицу фактов. Я создал эти таблицы и ввел несколько выборок, но я не получаю желаемого результата куба.

Я хочу иметь банк мудрый, держатель мудрый, мудрый, мудрый, весь флаг мудрый, регион мудрый и т. Д. Количество клиентов на период или диапазон периода. Я дам доступ куба к мощным пользователям, и они будут использовать все измерения в powerpivot для создания собственной сводной таблицы. Я думаю, что в дизайне стола что-то не так. Пожалуйста, предоставьте свои предложения.

С уважением,

Manish

Answer 1

Поместите все флаги в измерении (ами) барахла, в зависимости от области. Вы можете получить хороший, небольшой набор коррелированных свойств - я предполагаю, что пользователи хотят объединить эти значения.

DIM_Zero_Bal_acct кажется скорее расчетным кандидатом-кандидатом, чем измерением, но я думаю, это зависит от использования и того, что пользователи ожидают увидеть.

Действительно ли PIN-код каким-либо образом связан с зоной/районом? Если он создан с использованием некоторых Идентификаторов зоны, тогда это имеет смысл, иначе вы получите связку. Оставьте несовместимые вещи (например ... PIN?) На самом деле, он может сэкономить некоторое пространство, но обычно такое объединение не стоит проблем ... и бизнес-пользователям, вероятно, не волнует агрегация по этим значениям. Если они не очень странные люди (например, ... социологи).

Я бы выбрал сначала транзакцию в этом случае, а затем построил вокруг нее - кажется, активация учетной записи является одной из транзакций (события во времени/другом пространстве, которые могут быть как-то измеримы - считаются в этом случае). Еще одна сделка - кредит. Это две несвязанные таблицы фактов. Посыпьте их размерами, извлеките небольшие флаги в мусорные габариты (возможно, в итоге у вас будут интересные отношения между ними) ... и там вы идете.

Answer 2

Как я понимаю, вы создали измерение для Bank, Holder, RM, а затем одно измерение для каждого поля флага. Подход должен работать, и можно применить более одного измерения, чтобы получить желаемый результат, как я могу применить банк dimesnion и флаг SMS. Размер, чтобы получить все счета для выбранного банка, которые подали заявку на предоставление SMS. Я предложу несколько изменений, как

• если RM имеет отношение к банку, а затем связать RM с банковским измерением вместо создания отдельного измерения
• Сделать код Branch уникальных (убедитесь, что вы не получаете повторяющиеся коды филиалов если вы получаете данные из нескольких банков, имеющих один и тот же код филиала внутри) на самом деле, и объединяйте измерения банка и филиала вместе, так как один филиал принадлежит только одному банку, поэтому в банковском измерении будет использоваться идентификатор филиала.

До тех пор, создавая размер нежелательной обеспокоен вы можете по этой ссылке http://www.1keydata.com/datawarehousing/junk-dimension.html и посмотреть, если это поможет, единственное беспокойство, используя их, если вы хотите, чтобы получить значения из факта, полностью игнорируя значение флага, я имею в виду вы хотите получить все значения, несущественные для значения конкретного флага.