笔者在重新审视一个数据仓库项目的数据模型过程中想到的问题:为什么仓库应该有维度模型,我们为什么要维度建模技术,维度建模给仓库提供那些特性。针对这个问题,笔者做了几点总结: 1、使数据仓库中的数据容易理解:不需要懂如第三范式这类专业知识就可以组合查询分析数据 2、容易集成报表工具,通过特定的设计,可以提高仓库数据加载效率和数据访问速度 3、适应扩展性需求 4、维度建模步骤: 确定业务流程(Select the business process to model) 确定分析粒度(Declare the grain of the business process) 确定维度(Choose the dimensions that apply to each fact table row) 确定度量(Identify the numeric facts that will populate each fact table row) 5、再就是谈到了该用star还是snowflake模型
更多内容见Riitman’s Blog: http://www.rittmanmead.com/2007/04/25/some-thoughts-on-dimensional-modeling/ Some Thoughts on Dimensional Modeling If you’re wondering who the “Mead” in Rittman Mead Consulting is, now’s probably a good time to introduce myself. I’m Jon Mead, I’ve worked with Mark for a number of years on projects around the UK, and together we started up Rittman Mead Consulting earlier this year to try and help Oracle customers around the UK and Europe get the most out of their investment in Oracle business intelligence & data warehousing technology. I’ve actually had my head down on a number of project since we started and now had much of a chance to work on the blog, but I’ve got a bit of time free this evening and I thought I’d put my first posting together, on the always interesting subject of data warehouse data modeling. I have recently been involved in a review of an organisation’s Data Warehouse, and some of the time was spent reviewing the data model. During the review I ended up proposing that the Data Warehouse should have a dimensional model and the question then arose as to why we use this modelling technique, what qualities does it bring to the Data Warehouse and so on. In my view there are a few different answers to this question, which I’ll now attempt to summarize.
备注: --------------------------- 使用维度建模 实体关系建模通常用于为单位的所有进程创建一个复杂的模型。这种方法已被证实在创建高效的联机事务处理 (OLTP) 系统方面很有效。相反,维度建模针对零散的业务进程创建个别的模型。例如,销售信息可以创建为一个模型,库存可以创建为另一个模型,而客户帐户也可以创建为另一个模型。每个模型捕获事实数据表中的事实,以及那些事实在链接到事实数据表的维度表中的特性。由这些排列产生的架构称为星型架构或雪花型架构,已被证实在数据仓库设计中很有效。 维度建模将信息组织到结构中,这些结构通常对应于分析者希望对数据仓库数据使用的查询方法。例如,问题 "What were the sales of food items in the northwest region in the third quarter of 1999?"(1999 年第三季度西北地区的食品销售额是多少?)表示使用三个维度(产品、地理、时间)指定要汇总的信息。
数据仓库模型 销售信息的简单维度模型可能包括一个名为 Sales_Fact 的事实数据表,每个产品项的每个销售在该表中有一条记录,该表还包含售出的数量、单位成本和销售额。有关销售记录的各种信息可能包括客户、销售发生的商店、售出的时间和日期以及售出的产品。这些信息中的每一类都可组织为自己的维度表。客户信息放在 Customer 维度表中,商店信息放在 Store 维度表中,时间和日期信息放在 Time 维度表中,产品信息放在 Product 维度表中。 在星型架构中,每个维度表都有一个由一个部分组成的主键,该主键链接到事实数据表中由多个部分组成的主键的一个部分。在雪花型架构中,一个或多个维度表分解为多个表,每个表都有联接到主维度表而不是事实数据表的相关性维度表。在大多数设计中,星型架构比雪花型架构更可取,因为前者包含的用于信息检索的联接更少,并且更容易管理。
维度建模十大错误 10、在事实表中放置用于约束与分组操作的文字型属性。 9、在维度表中为试图节省空间而限制使用详细的描述属性。 8、将体系与体系层次分解成多个维度。一个体系需要一起归入到单个物理平面维度表中。应该抵制通过生成一组日益增多的、尺寸较小的子维度表来对体系进行雪花处理的企图。在这种情况下,极易引起后台数据转储处理与前台数据展示之间的混淆。如果一个维度同时存在多个堆积形式,那么在绝大多数情况下,将多个体系包括在同一个维度当中是非常合理的,只要该维度是在可能的最低粒度层次上定义的。 7、忽略跟踪维度变化的需要。 6、通过增加更多硬件解决所有的查询性能问题。聚集体或派生的汇总表是提高查询性能最有效的途径。 5、使用操作型或智能型关键字将维度表连接到事实表上。 4、忽略事实表粒度的定义与使用。每种不同的度量粒度都需要有自己的事实表。 3、基于具体的报表来设计维度模型。维度模型是牢牢地建立在度量处理的物理内容之上的。 2、希望用户以规范化的格式查询最底层的原子型数据。最底层的数据总是具有最好的维度性,并且应该成为维度设计的基础。 1、舍弃在单独的事实表之间保持事实与维度的一致。 (摘自《数据仓库工具箱》 Ralph Kimball) http://www.intelligententerprise.com/print_article_flat.jhtml?article=/011024/416warehouse1_1.jhtml
|