我正在使用RDBMS并编写等效的ETL程序，但没有像Informatica等工具。
源数据来自三个不同的表，每个表具有不同级别的数据存储，每个帐户都有，但SCD-type-2行为使得行数变量。此外，其中一个消息来源每天都有数据＆＃34;＆＃34;基础，即每天一排。
需要将这些数据（最后是5个属性）合并到一个表中，以便于查找帐号和日期。有效地提供查询服务到＆＃34;当前这个属性的值是什么＆＃34;对于给定的帐户。
挑战主要在于平衡＆＃34; grain＆＃34;的记录。那里有几个蛮力的想法。一种是分解可变粒度行，并生成其他行以使用最低粒度属性进行调整。每个属性每天有效地拥有一行。这对我来说看起来不干净，并且会消耗更多的存储空间。这是一个例子 -
来源 -
table 1 (Customer Details)
Address - dt1 - dt2 - val1
Address - dt2+1 - dt3 - val2
Address - dt3+1 - infinity - val3
table 2 (Loan Details)
Maturity Date - dt4 - dt5 - val8
Maturity Date - dt5+1 - dt6 - val-x
Maturity Date - dt6+1 - dt7 - val-xx
Maturity Date - dt7+1 - infinity - val-y
table 3 (Account Balance) (one record per day)
Daily Interest Accrued - dt1 - val1
Daily Interest Accrued - dt2 - val2
Daily Interest Accrued - dt3 - val3
：定位
dt1 - Address-val - Maturity Date-val - Daily Interest Accrued-val
dt2 - Address-val - Maturity Date-val - Daily Interest Accrued-val
dt3 - Address-val - Maturity Date-val - Daily Interest Accrued-val
这三个属性需要存储在一个表格中...想法请...
答案 0 :(得分：1)
首先让我们处理建模。
在没有任何更多细节的情况下，我认为您已获得ACCOUNT-BALANCE的定期快照，DATE维度，CUSTOMER的Type-2缓慢变化维度以及LOAN的Type-1维度。
FACT_ACCOUNT的属性类似于DIM_DATE_ID，DIM_CUSTOMER_ID，DIM_LOAN_ID，ACCRUED_INTEREST，ACCOUNT_BALANCE。
我之所以认为你没有获得贷款的第二类维度是因为我没有看到它的价值 - 例如帐号，到期日和原始余额 - 改变时间。
通过将ACCOUNT_BALANCE从维度移动到事实表，您可以更好地表示流程。
可能出现的一个问题是存储利率。固定费率是SCD1维度的属性。周期性变化的速率可以是SCD2值。如果它与事实表格相同（即每日）变化，我将其作为非附加措施。
我确实看到了关于在一个表格中存储三个属性的观点，但我没有看到它的目的。如果满足查询所需的属性位于不同的表中，那么这是JOIN的角色。任何称职的可视化或分析工具都将支持这样的简单连接。