专注于中国的商业智能

导航

2010年8月5日 #

KDT#94 为DW/BI系统建立定制工具

摘要: Building Custom Tools for the DW/BI System市场上有大量的工具帮我们来建立DW/BI系统、把信息交付给业务用户。这些工具的种类也很多,它们包括关系型数据库管理系统、OLAP数据库管理系统、ETL工具、数据挖掘工具、查询工具、报表工具,以及BI门户工具等等。那么在这么多的工具中,定制工具起什么样的作用呢?我们看到的大部分定制工具都是用来支持后台操作的,如元数据... 阅读全文

posted @ 2010-08-05 14:53 李梦蛟 阅读(308) 评论(0) 推荐(1) 编辑

KDT#96 像应用软件开发经理一样思维

摘要: Think Like A Software Development Manager对很多企业来说,广大的用户通过BI应用来使用DW/BI系统。这些BI应用包括标准报表,分析应用,仪表盘和操作型BI等内容。这些应用提供了一个结构化的、参数驱动的、相对简单的方法给用户,用户通过这些方法可以得到他们需要的信息。在“KDT#91 DW/BI系统的营销”之中,我们描述了BI应用作为D... 阅读全文

posted @ 2010-08-05 14:53 李梦蛟 阅读(207) 评论(0) 推荐(0) 编辑

KDT#91 DW/BI系统的营销(一)

摘要: Marketing the DW/BI System技术人员一般都远离营销工作。当有人说“你一定是营销团队的”时,就是在说这种情况。这主要是因为我们不理解营销到底是什么,为什么它非常重要。在本技巧中,我们首先回顾一下营销的经典概念,接着展示我们怎么将其应用到DW/BI系统中。如果把营销看作为培训可能会更好一些。营销人员将产品的功能和特色讲解给客户。营销的名声不好,因为它常习... 阅读全文

posted @ 2010-08-05 14:52 李梦蛟 阅读(379) 评论(0) 推荐(1) 编辑

KDT#91 DW/BI系统的营销(二)

摘要: Marketing the DW/BI System3.位置对于消费品,位置是显而易见的:产品必须放到储藏架上,客户才会买它。对于我们来说,位置意味着我们的客户能在需要的时候找到他们需要的信息。也就是说,我们需要为BI应用建立导航结构,这样用户才能方便的使用。而且一些有用的功能也需要提供,例如搜索功能、报表元数据的描述和分类功能、个性化设置功能等。这部分内容可以参见“KDT#58 BI... 阅读全文

posted @ 2010-08-05 14:52 李梦蛟 阅读(226) 评论(0) 推荐(0) 编辑

KDT#82 改变事实表的粒度

摘要: 通常事实表的粒度直接来自源系统的交易表,但也有时我们会根据需要产生更细粒度的事实数据。这样的情况主要是当需要把事实表中的事实转化为事实维度时发生,例如事实表中的多个事实类型相似但事实的数量可能会增加时。在下面列出的一些情况下,我们可以考虑将为事实表添加新的事实维度,来减小事实表中事实的数量。1.事实表中事实过多时。一般来说,当一个事实表中的事实在三十个左右比较正常,如果到一百个左右就过多了。2.如... 阅读全文

posted @ 2010-08-05 14:38 李梦蛟 阅读(397) 评论(0) 推荐(0) 编辑

KDT#79 有关维度表的大小

摘要: 在很多实施数据仓库的企业里,客户和产品都会有上百万条记录。数据量过大,导致数据的加载和查询都会面临很大的问题。不过处理器和内存技术的大幅度进步很大的解决了这个问题。那么,现在对我们来说,多大的维度表是比较危险的呢?这时该如何处理呢?对于一个大型的银行来说,可能会有3千万个帐户,如果每个帐户有20个字段来进行描述,每个字段为10个字节。这样,帐户维度表就会有6GB的数据。3千万条记录的维度表对于MO... 阅读全文

posted @ 2010-08-05 14:37 李梦蛟 阅读(380) 评论(2) 推荐(1) 编辑

KDT#80 给维度表添加变化原因列

摘要: 通常我们用TYPE2的缓慢变化维策略来处理维度表的历史信息问题。有时,客户会提出下面这样的问题:我们每个月有多少个新增客户?类似这样需要对维度表的数据变化进行分析的需求,使用标准的TYPE2策略处理起来会比较麻烦。这时,我们可以在维度表中添加一个变化原因列(RowChangeReason)。简单的处理方式,我们可以使用两个字节的缩写来标识变化原因。例如,新建列为 ’NW’,... 阅读全文

posted @ 2010-08-05 14:37 李梦蛟 阅读(251) 评论(0) 推荐(0) 编辑

KDT#81 事实表中的代理键

摘要: 在数据仓库的建模中,代理键通常是建立在维度表中的。那么在事实表中如何呢?在建立逻辑模型时,事实表中显然是没必要建立代理键的,但是到了物理模型,在某些特定的情况下是可以考虑建立代理键。代理键一般是无意义的整型值,做为维度表的主键,它的分配过程一般是顺序的。代理键可以很好的隔离源系统的数据变化,对数据仓库中的查询性能也能起到很好的作用。在事实表中,主键一般定义为维度外键的子集,通常几个维度外键即可实现... 阅读全文

posted @ 2010-08-05 14:37 李梦蛟 阅读(935) 评论(0) 推荐(0) 编辑

KDT#77 维度建模中不要只有汇总数据

摘要: 很多人对维度建模有一个误解,认为维度建模是为了管理和战略分析的需要而建立的汇总数据。事实上,这是一种错误的观点。维度建模应该保存最细的原子粒度的数据。这样才能满足用户的不确定的需求。出于性能的考虑,数据库管理员要建立一些汇总事实表(也称聚集事实表,Aggregated Fact Table)。这类表每一条记录保存的是选定的几个维度及在这几个维度上汇总的事实值。这些表可以是物理表,也可以是物化视图(... 阅读全文

posted @ 2010-08-05 14:36 李梦蛟 阅读(390) 评论(1) 推荐(1) 编辑

KDT#78 迟到的维度记录

摘要: 在数据迁移的过程中,可能会遇到由于各种原因而迟到的维度记录。它们有可能是比事实记录晚到的维度记录,也可能是维度属性变化了但是延迟提交给数据仓库的维度记录。对于迟到的维度记录有几种处理策略。第一种方案是,ETL系统可以在事实记录相关的维度记录到了之后再将该事实记录迁移入数据仓库中。这样做的缺点是,事实表的记录可能会不完全。第二种方案是在维度表中建立一条“未知”的维度记录,对于... 阅读全文

posted @ 2010-08-05 14:36 李梦蛟 阅读(513) 评论(0) 推荐(0) 编辑

KDT#71 数据建模时的命名方法

摘要: 确定数据建模时的命名是一件麻烦的事,因为不同的人对同样的事情有不同的理解。下面通过三个步骤来完成命名的过程。前两步一般是在模型给业务用户看之前。第三步是业务用户看过并理解了模型之后。1.准备阶段首先,建模人员需要掌握公司或者团队内的命名规则,如果没有的话,需要建立一套。建模时,需要先根据实际情况定下数据项的名称,这些名称需要简洁、能描述清除事物并且是唯一的。通常字段的名称包括如下三部分:Prime... 阅读全文

posted @ 2010-08-05 14:35 李梦蛟 阅读(395) 评论(0) 推荐(0) 编辑

KDT#72 再谈业务处理过程

摘要: 采用Kimball开发方法构建数据仓库系统,关注于业务处理过程是至关重要的一步。业务处理过程是维度建模的数据仓库的基础单元。对应一个业务处理过程至少可以建立一个事实表,所以标识业务处理过程的时候也就标识了需要建立的事实表。对一个业务处理过程建立多个事实表是很常见的。当业务处理过程中涉及不同种类的产品时经常需要建立多个相似的事实表。通过描述事实表的粒度,我们可以判断是否正确的标识出了业务处理过程。如... 阅读全文

posted @ 2010-08-05 14:35 李梦蛟 阅读(264) 评论(0) 推荐(0) 编辑

KDT#73 谈谈敏捷开发方法

摘要: 敏捷开发方法是一套开发方法学,包括极限编程(XP)、SCRUM、自适应软件开发等,特点是迭代开发、降低风险、在短期内提高新的功能。和传统的开发方法相比,敏捷开发方法通常称为“轻量级开发方法”。Kimball开发方法和敏捷开发方法有很多相似之处。1.最主要的目标都关注于满足用户的需求。2.重视与用户的合作,尤其是与业务代表的关系。3.都注重与用户面对面的交流,注重用户的反馈。... 阅读全文

posted @ 2010-08-05 14:35 李梦蛟 阅读(221) 评论(0) 推荐(0) 编辑

KDT#69 业务处理过程的选择

摘要: 遵从Kimball的MD架构来建立数据仓库时,设计维度模型的过程通常包括四个步骤,分别是选择业务处理过程、选择粒度、选择维度和选择事实。在这个过程中,选择业务处理过程是Kimball非常强调的一步。业务处理过程(Business Process)指的是组织中的存在的业务活动,在这个业务活动中可以产生或者收集到数据。在维度建模过程中,我们要关注于这些产生数据的业务处理过程,而不应该关注于业务处理部门... 阅读全文

posted @ 2010-08-05 14:34 李梦蛟 阅读(328) 评论(0) 推荐(0) 编辑

KDT#70 如何规划数据仓库的架构

摘要: 在我们构建DW/BI系统时,如何来规划架构是非常重要的一步。我们是选择将系统建立在关系数据库中,还是建立在多维数据库中,还是关系数据库和多维数据库中都进行建立。在建立的多维数据库后,是否还有必要将多维模型建立在关系数据中?这些都是在架构数据仓库时首先要考虑的问题。通常的建议是关系数据库和多维数据库都需要。目前,直接建立多维数据库也是可以实现数据仓库的,直接在交易系统中ETL数据到多维数据库中。但是... 阅读全文

posted @ 2010-08-05 14:34 李梦蛟 阅读(447) 评论(0) 推荐(0) 编辑

KDT#64 要避免DW/BI的隔离

摘要: 通常在一个组织中,DW项目组和BI项目组是分开的两个项目组。其中DW项目组,即数据仓库项目组,主要负责后台数据仓库的建模、数据的整合等功能的实现;而BI项目组,即商业智能项目组,主要负责前台数据展现、报表、OLAP及数据挖掘等功能的实现。而很多组织过分的划分了这两个项目组,使DW项目组和BI项目组沟通过少,前后台脱节。这其实是一件很危险的事情。对数据仓库和商业智能来说,最关键的都是用户的需求。在数... 阅读全文

posted @ 2010-08-05 14:33 李梦蛟 阅读(270) 评论(0) 推荐(1) 编辑

KDT#65 为ETL系统做好文档记录

摘要: 在建立和维护数据仓库系统时,不论你的ETL系统是采用ETL工具开发的还是自己手工开发的,对整个ETL系统的每一步做好详细记录都是至关重要的一份工作。随着时间的推移,建好的数据仓库也在不断发展,ETL系统也需要逐步改变,为了能尽快的适应新的情况的变化,完善的文档对快速理解系统的架构和实现的细节能起到非常大的作用。ETL工具也可以自动做一些文档记录,但是对于维护一个数据仓库的良好运转来说,这是远远不够... 阅读全文

posted @ 2010-08-05 14:33 李梦蛟 阅读(262) 评论(0) 推荐(0) 编辑

KDT#68 一个简单的交叉探察的SQL例子

摘要: 交叉探查(Drill Across)指查询多个事实表并将结果合并成一个结果集的查询操作。下面是一个查询销售实际值和预测值的例子。通常的BI工具都支持交叉探查操作。SELECT Act.Customer, Act.Year, Act.Month, Actual_Amount, Fcst.Forecast_AmountFROM--子查询"Act"返回实际值 (SELECT Customer_Name ... 阅读全文

posted @ 2010-08-05 14:33 李梦蛟 阅读(362) 评论(0) 推荐(0) 编辑

KDT#57 早到的事实

摘要: 在数据仓库中,事实表和维度表的数据通常都是同时到来的,我们根据维度记录的不同情况会对事实表中的维度外键进行如下的处理:1.如果维度记录是个新的,我们分配一个新的代理键给这个记录。2.如果维度记录是以前的修改版,我们用TYPE 2的缓慢变化维度处理策略来处理,即生成新的代理键,生成新的维度记录。3.如果维度记录是以前就有的,我们就使用以前的维度键。对于迟来的事实记录,我们需要在维度表中进行搜索,确定... 阅读全文

posted @ 2010-08-05 14:32 李梦蛟 阅读(312) 评论(0) 推荐(0) 编辑

KDT#58 BI门户(WEB数据仓库)

摘要: 一个数据仓库或者商业智能系统是否成功,依赖于企业是否可以从中得到有价值的信息。企业为用户提供BI门户,用户通过BI门户来访问企业数据仓库或者商业智能系统中的信息。很多时候,BI门户的主页关注于数据仓库中的历史信息、加载过程的当前状态等内容。这些都是很有意义的信息,但是这些并不是BI用户最渴望得到的信息。BI门户是用户访问数据仓库的入口,它必须能满足用户最重要的需求。对BI门户的页面有两个基本的要求... 阅读全文

posted @ 2010-08-05 14:32 李梦蛟 阅读(424) 评论(0) 推荐(0) 编辑