joj*_*ojo 11 sql database-design star-schema
我很困惑应该从哪里开始设计星型模式.
例如,我在数据库中有如下表:
Branch(branchNo, bStreetAddress, bCity)
LoanManager(empNo, empName, phone, branchNo)
Customer(custNo, custName, profession, streetAddress, city, state)
Account(accNo, accType, balance, accDate, custNo)
LoanContract(contractNo, loanType, amount, loanDate, empNo, custNo)
Run Code Online (Sandbox Code Playgroud)
我想设计一个数据仓库来分析负载,例如:
在创建星型模式时,我应该从哪里开始?
根据我的理解,所有星型模式都必须有一个中心,而中心事实表包含"Measures"和"与其他事实表的关系".
那么,在设计星型模式时,我们总是从中心开始,首先确认测量的是什么?然后选择与另一个事实表的正确关系?
但是我还有另一个问题,我们应该选择哪些措施?在选择措施时,我应该问自己什么问题?
星型模式的设计始终由客户的业务需求驱动.有什么问题要问?答案应该有多细粒度?
在您的示例中,有趣的问题可能是"分支或贷款经理合同的数量"或"按分支或贷款经理管理的贷款总额".在这种情况下,Branch并LoanManager会成为你的尺寸的同时Count(LoanContract),并Sum(LoanContract.amount)会成为你的措施.常见的附加维度是时间,通常week或quarter.
回答这些问题的架构可能如下所示:
DimBranch ( branchNo )
DimLoanManager ( empNo )
DimQuarter ( year, qNo ) -- qNo in (1,2,3,4)
DimWeek ( year, weekNo ) -- weekNo in (0..53), depending on business rules
Measures ( branchNo, empNo, year, qNo, weekNo, numContracts, sumLoans )
Run Code Online (Sandbox Code Playgroud)
对于您在问题中提出的业务问题,维度和度量将是这样的:
year,衡量:Sum(LoanContract.amount)loanType,衡量:Count(LoanContract)将这两者放在同一个星型模式中并没有多大意义,因为它们既不共享维度也没有措施.
| 归档时间: |
|
| 查看次数: |
14631 次 |
| 最近记录: |