将关系数据库 (OLTP) 转换为数据仓库模型
Posted
技术标签:
【中文标题】将关系数据库 (OLTP) 转换为数据仓库模型【英文标题】:Transforming Relational Database (OLTP) to Data Warehousing Model 【发布时间】:2013-06-12 11:03:59 【问题描述】:这是我第一个围绕 BI 的项目,我将基于现有的关系数据库创建一个数据仓库。我有一个包含 6 个具有许多关系的表的数据库(一对多)
我想给你一个关于关系数据库现有模式的想法:
-------------
HeadOperation
-------------
head_col1
head_col2
head_col3
col4
col5
col6
....
-------------
Item
-------------
head_col1
head_col2
head_col3
colItem1ID
colItem2
colItem3
valueitem
....
每个HeadOperation至少有一个Item,我们也可以说Item是HeadOperation的细节> 表。
head_col1,head_col1,head_col3:是HeadOperation的主键和Item表的外键
要创建一个事实表并作为 BI 建模中的新功能,我不知道如何制作一个事实表,第一个有多个主键(多个主键)并且 Item 表具有相同的键+它的主键关键 colItemID。
我想到的另一件事是合并/融合这些表,但数据仓库会很大。
有解决这个建模问题的建议吗?
谢谢
【问题讨论】:
您有两列名为 head_col1。请在我们尝试给出答案之前解决此问题。 在开始构建数据仓库之前,请尝试弄清楚您需要对其进行哪些类型的报告。 我在维度表中有复合主键的问题,这是我的问题:s 对于初学者,您应该将仓库中的列名称更改为有意义的 business 名称。那么 head_col1 代表什么?将这些放在您的问题中,它可能会帮助我们回答。 有人告诉我,我应该做一个代理键,我应该将数据加载到维度中,然后将数据加载到事实表中。你怎么看? 【参考方案1】:肯定有人告诉你正确的事情。大多数情况下,代理键只是唯一的整数值自动递增值。然后你应该填充你的维度表。填充维度表后,您应该将数据加载到 Fact 表中。之后,如果您的 Fact 表非常大,您可以选择创建 Aggregate Fact 表。
【讨论】:
以上是关于将关系数据库 (OLTP) 转换为数据仓库模型的主要内容,如果未能解决你的问题,请参考以下文章