专注于中国的商业智能

导航

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 李梦蛟 阅读(315) 评论(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 李梦蛟 阅读(213) 评论(0) 推荐(0)

KDT#91 DW/BI系统的营销（二）

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

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

KDT#91 DW/BI系统的营销（一）

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

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

KDT#82 改变事实表的粒度

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

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

KDT#79 有关维度表的大小

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

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

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

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

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

KDT#81 事实表中的代理键

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

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

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

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

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

KDT#78 迟到的维度记录

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

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

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

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

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

KDT#72 再谈业务处理过程

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

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

KDT#73 谈谈敏捷开发方法

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

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

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

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

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

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

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

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

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

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

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

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

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

posted @ 2010-08-05 14:33 李梦蛟 阅读(270) 评论(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 李梦蛟 阅读(381) 评论(0) 推荐(0)

KDT#57 早到的事实

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

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

KDT#58 BI门户（WEB数据仓库）

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

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

KDT#59 数据概况的作用

摘要： 数据概况（Data Profiling）是大部分数据仓库的建立者都会忽略或误解的一部分内容。很多人会认为数据概况是ETL系统建立之后的数据不规则检验。事实上，数据概况是对源数据内容的概况分析，这个分析应该在需求收集之后就开始。概况分析从小的方面来说包括计算数据量的大小、检验数据的基数关系等，从大的方面来说包括任何判断数据是否满足需求的方法。数据概况的分析一般可以通过如下分析来完成。对于字段，主要分... 阅读全文

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

KDT#54 再谈缓慢变化维（二）

摘要： 如果要处理的维度表很大，有一百个以上的维度属性，按上述方法进行当前信息和历史信息保存的话就会变得很麻烦。在这种情况下，我们可以考虑将维度表的自然键添加到事实表中作为外键。这样，事实表上就会有两种相似但是完全不同的方式和维度表进行关联。第一个是使用代理键与维度表进行关联，可以使用TYPE 2的技术对维度属性的历史信息进行分析，即使用事实表加载时对应的维度属性对事实数据进行分析。第二个是使用自然键与维... 阅读全文

posted @ 2010-08-05 14:31 李梦蛟 阅读(295) 评论(0) 推荐(0)

KDT#55 文本事实的处理

摘要： 在维度建模中，我们经常会遇到一些文本型的事实，它们通常是一些标识信息、属性或者描述信息。这些字段看似属于事实表中的事实，但是它们又不是键、度量事实或者退化维度。通常，不太建议将这些文本事实字段建立到事实表中，而应该在维度表中给它们找到适当的位置。当遇到文本型的事实时，我们首先要考虑的应该是这个事实是否属于某个维度表。例如，客户类型标识出每个客户的一个值，应该属于客户维度表。如果事实不属于已存在的任... 阅读全文

posted @ 2010-08-05 14:31 李梦蛟 阅读(304) 评论(0) 推荐(0)

KDT#53 给维度添加描述属性

摘要： 在维度建模时，我们会尽力在维度表中添加描述性的字段。我们在维度表中添加的描述性的属性越多，用户在进行分析和出报表时就会越灵活。在大型的客户维度表中尤其如此。在进行维度建模时，我们不应该将一些业务逻辑留给分析工具去完成。比如一些经过业务逻辑处理才能得到的派生数据，应该在ETL层就完成，这样才能保证数据的一致性，无论使用任何工具都可以。如果这步在分析工具中完成，不同人有可能会建立起不同的业务逻辑，导致... 阅读全文

posted @ 2010-08-05 14:30 李梦蛟 阅读(291) 评论(0) 推荐(0)

KDT#54 再谈缓慢变化维（一）

摘要： 在数据仓库系统中，维度属性的变化是不可避免的，通常我们会用缓慢变化维的三类处理策略来解决这个问题。也就是类型一，覆盖原属性。类型二，添加新的维度行。类型三，添加新的维度列。当维度的属性发生变化时，客户除了要求能用当前值对历史事实信息进行分析外，经常会要求能以历史上的属性分类信息对事实进行分析。随着大家对商业智能的了解和期望程度，这种分析需求变得越来越多。二十年前（Kimball的二十年前），大家对... 阅读全文

posted @ 2010-08-05 14:30 李梦蛟 阅读(418) 评论(0) 推荐(0)

KDT#52 改进数据仓库系统的维护工作（二）

摘要： 4．尽量保持测试环境和生产环境相同，如果要节省硬件环境的开支的话，建议先减小存储的容量，在历史数据的子集上进行测试。接下来可以减少处理器的个数。如果还需要缩减的话，最后减小内存的大小。但是硬件环境的缩减，会对查询性能产生巨大的影响。也就是说，如果在测试环境减少了数据范围、处理器或者内存，运行情况会和正式环境有很大的不同。开发环境也应该尽量和测试环境、生产环境相同。5．对于像部署一个新的数据集市、添... 阅读全文

posted @ 2010-08-05 14:29 李梦蛟 阅读(315) 评论(0) 推荐(0)

KDT#52 改进数据仓库系统的维护工作（三）

摘要： 8．在数据仓库项目组中应该有专门的人员管理系统中使用的各种工具产品及程序，负责监控其升级和维护。当报表工具或者数据库等产品有新的补丁或者版本提供时，首先需要评估升级或者打补丁对系统的重要程度，确定需要升级后也需要经过培训和测试后才可以发布到生产环境。如果升级太超前的话，可能会为产品的bug等付出代价。升级时的操作步骤一定要书写清楚并按顺序完成。操作步骤文档要保证每一步都尽量详细。可以事先定义好操作... 阅读全文

posted @ 2010-08-05 14:29 李梦蛟 阅读(303) 评论(0) 推荐(0)

KDT#51 时间维度表

摘要： 有时，事实表中的日期比一天要细，会详细到时分秒，而且用户可能会对时分秒进行查询，如果我们将日期维度的粒度细到秒级，日期维度表中的记录就会变的太多。这时，我们有两种建模方法来处理这个问题。一种方法是，在事实表除了保存日期维度的外键（代理键）以外，还将这个日期当作一个事实保存在事实表中，保存成SQL的DataTime型。这样，如果用户需要更精确的查询的话，可以查询这个DataTime型的字段。另一种方... 阅读全文

posted @ 2010-08-05 14:28 李梦蛟 阅读(626) 评论(0) 推荐(0)

KDT#52 改进数据仓库系统的维护工作（一）

摘要： 数据仓库系统开发完成后进入维护阶段。从实际情况来看，尽管数据仓库系统的维护要求不像业务系统那样有24×7的维护要求，但是大多数的数据仓库系统维护工作不如业务系统的维护工作完成的好。事实上，维护数据仓库系统的正常运转和维护其他业务系统没有很大的区别，都需要做好遵从实践标准，为故障和灾难做好计划等内容。下面是做好维护工作的一些比较基本的建议。1．首先要做的是需要提供服务的级别与用户进行协商... 阅读全文

posted @ 2010-08-05 14:28 李梦蛟 阅读(357) 评论(0) 推荐(0)

维度建模中的数据存储（三）

摘要： Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用关系数据保存维度模型的缺点1．对于非常复杂的分析和应用来说，SQL是一种很可怕的语言。2．SQL不能像OLAP那样对各个维度来说是对称的。3．尽管有很多调优的功能，但是性能还是很容易变差。 阅读全文

posted @ 2010-08-05 13:58 李梦蛟 阅读(331) 评论(0) 推荐(0)

维度建模中的数据存储（四）

摘要： Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用OLAP保存维度模型的优点1．一般来说，如果Cube设计的正确的话，性能要比使用关系数据保存强很多。而且和使用关系数据库比，在调优上可以省很多力气。2．与使用关系数据库相比，分析能力要强大很多。例如，在面对复杂的层级... 阅读全文

posted @ 2010-08-05 13:58 李梦蛟 阅读(312) 评论(0) 推荐(0)

维度建模中的数据存储（一）

摘要： Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日维度模型保存在关系数据库中还是OLAP中在维度建模的数据仓库之中，是使用关系数据库来保存数据还是使用OLAP Cube来保存数据是一个需要数据仓库架构师作出选择的问题。在本文中列举了两种可选方式的34条优点和缺点，供大家... 阅读全文

posted @ 2010-08-05 13:58 李梦蛟 阅读(729) 评论(0) 推荐(0)

维度建模中的数据存储（二）

摘要： Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用关系数据保存维度模型的优点1．关系数据库大部分都是由独立的供应商提供的，维度模型数据的加载很容易实现。但是，如果加载时使用命令行脚本或者类似PL/SQL类似的私有代码来完成的话，加载过程不是很轻便。2．所有的主流DB... 阅读全文

posted @ 2010-08-05 13:58 李梦蛟 阅读(368) 评论(0) 推荐(0)

浅析代理关键字

摘要： 在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。代理关键字的称呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificia... 阅读全文

posted @ 2010-08-05 13:57 李梦蛟 阅读(900) 评论(0) 推荐(0)

浅析多值维度

摘要： 在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾... 阅读全文

posted @ 2010-08-05 13:57 李梦蛟 阅读(1199) 评论(0) 推荐(1)

浅析冰山查询

摘要： 在数据仓库领域有一个概念叫Iceberg query，中文一般翻译为“冰山查询”。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。以销售数据为例，你想产生这样的一个顾客－商品对的列表，这些顾客购买商品的数量达到3件或更多。这可以用下面的冰山查询表示：Select P.cust_ID, P.item_ID, SUM(P.qty)From Pur... 阅读全文

posted @ 2010-08-05 13:57 李梦蛟 阅读(803) 评论(0) 推荐(0)

浅析操作集市

摘要： 在数据仓库领域有一个概念叫Oper Mart，中文一般翻译为“操作集市”。操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储（ODS）。它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。一个操作集市应该有如下特征：1．操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。2．操作集市中的数据和ODS中的数据同步更新。3．操作集市以多维... 阅读全文

posted @ 2010-08-05 13:57 李梦蛟 阅读(408) 评论(0) 推荐(0)

维度建模中的数据存储（五）

摘要： Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用OLAP保存维度模型的缺点1．OLAP最大的缺点的是它是私有的，每个供应商之间没有共同的标准。2．不要期待从一个供应商的OLAP方案转换到另一个供应商的OLAP方案。如果需要转换的话，基本上要抛弃开发中的一切从头开始... 阅读全文

posted @ 2010-08-05 13:57 李梦蛟 阅读(389) 评论(0) 推荐(0)

浅析即席查询

摘要： 在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常... 阅读全文

posted @ 2010-08-05 13:56 李梦蛟 阅读(1430) 评论(0) 推荐(0)

浅析交叉探查

摘要： 在维度建模的数据仓库中，有一种操作叫Drill Across ，中文一般翻译为“交叉探查”。鉴于经验的局限，在这里我只能进行一下浅显的分析。在基于总线架构（Bus Architecture）的维度建模中，大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度&rdq... 阅读全文

posted @ 2010-08-05 13:56 李梦蛟 阅读(849) 评论(0) 推荐(0)

浅析非事实型事实表

摘要： 在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。第一类非事实型事实表是用来跟踪事件的事实表。例如... 阅读全文

posted @ 2010-08-05 13:56 李梦蛟 阅读(1603) 评论(0) 推荐(0)

浅析合并事实表

摘要： 在数据仓库领域有一个概念叫merged fact table，或者consolidated fact table，中文一般都翻译为“合并事实表”。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法，合并的事实要保证在相同的粒度。这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术，可以避免性能... 阅读全文

posted @ 2010-08-05 13:56 李梦蛟 阅读(1280) 评论(0) 推荐(0)

浅析缓慢变化维

摘要： 维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。处... 阅读全文

posted @ 2010-08-05 13:56 李梦蛟 阅读(579) 评论(0) 推荐(0)

浅析数据世系

摘要： 数据仓库中有一个概念叫做Data Lineage，中文一般翻译为“数据世系”。数据世系描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。数据世系信息需要留下详细的文档记载。数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。数据世系是数据仓库的元数据中最重要的一部分。这部分元数据的产生位置是在ETL的处理过程中。如果在E... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(2610) 评论(0) 推荐(0)

浅析退化维度

摘要： 在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。退化维度经常会和其他一些维度一起组合... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(5832) 评论(1) 推荐(0)

浅析角色模仿维度

摘要： 在数据仓库领域有一个概念叫Role-playing dimensions，中文一般翻译为“角色模仿维度”。角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(1076) 评论(0) 推荐(0)

浅析切片事实表

摘要： 在数据仓库领域有一个概念叫sliced fact table，中文一般翻译为“切片事实表”。切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(1645) 评论(0) 推荐(0)

浅析事实表（一）

摘要： 在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表（Transaction Grain Fact Table），周期快照粒度事实表（Periodic Snapshot Grain Fa... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(810) 评论(0) 推荐(0)

浅析一致性维度

摘要： 维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为“一致性维度”。一致性维度是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(1666) 评论(0) 推荐(0)

浅析预连接聚集表

摘要： 在数据仓库领域有一个概念叫pre-joined aggregagte table，中文一般翻译为“预连接聚集表”。预连接聚集表是通过对事实表和维度表的联合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实值。通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。典型的预连接聚集表如下例所示的销售事实表，产品名... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(727) 评论(0) 推荐(0)

浅析微型维度

摘要： 维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(1023) 评论(0) 推荐(0)

浅析蜈蚣事实表

摘要： 在数据仓库领域有一个概念叫Centipede fact table，中文一般翻译为“蜈蚣事实表”。蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(1139) 评论(0) 推荐(0)

浅析旋转事实表

摘要： 在数据仓库领域有一个概念叫pivoted fact table，中文一般翻译为“旋转事实表”。旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在S... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(637) 评论(0) 推荐(0)

浅析事实表（二）

摘要： 从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实... 阅读全文

posted @ 2010-08-05 13:55 李梦蛟 阅读(605) 评论(0) 推荐(0)

KDT#3 不要建立部门级的数据集市

摘要： 这个题目一定会给人带来概念上的混淆。市面上大部分关于数据仓库的书中讲述的都是数据集市是部门级的，而数据仓库是企业级的。这里有一个概念需要单独说明一下，这个概念就是数据集市（Data Mart）。关于数据集市的概念还没有统一的定论。前面提到的面向部门级的数据集市是Inmon的CIF架构中的概念。而Kimball的MD架构中数据集市和CIF架构中的数据集市的概念是不一样。这个区别不是一两句话能说清的，... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(482) 评论(0) 推荐(0)

KDT#4 超大维度的变化数据捕获的一种方法

摘要： 在数据仓库的建模中，有一种维度是超大维度，它有可能有100个以上的属性，有百万条以上的记录。例如，有些行业的客户维度。如果源系统能每天提供该表变化的信息当然是一件非常舒服的事情，但是，这通常是不可能的。源系统一般会每天提供一个文件，文件里是客户表的全部信息。这就需要我们做变化数据分析，通过扫描整个文件和上一天文件的差异来进行变化数据捕获。对于一个超大的维度来说，这个比较过程是很麻烦的一件事情。有一... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(378) 评论(0) 推荐(0)

KDT#5 使用代理键的日期维度

摘要： 日期维度是用来描述事实表中与日期有关的属性的。它的粒度应该是每天一条记录。一个典型的日期维度表如下所示：Date_Key（代理键，整型）Date_Type（正常，不知道，未发生等）SQL_Date_Stamp（Date_Type为正常时，否则该值为NULL）Day_Number_in_Month（1…31）Day_Number_in_Year（1…366）Week_Nu... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(489) 评论(0) 推荐(0)

KDT#1 补充 点击流数据仓库的粒度选择

摘要： 对于点击流数据仓库的事实表，通常有三种不同的粒度选择。1． 事实表记录＝每个会话的每个页面一条记录这是一个非常细的级别，基本上满足所有的分析要求，但处理数据可能会花掉大部分的时间和金钱。一个好的建议就是用统计学里的抽样技术，选取1％的数据来进行处理和分析。2． 事实表记录＝每个会话一条记录这个粒度在KDT＃1中已经描述。3． 事实表记录＝每天一条记录这个粒度是一个很粗的粒度。优点很明显，就像聚集事... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(330) 评论(0) 推荐(0)

KDT#2 事实表中的多个时间字段

摘要： 在数据仓库的设计中，我们会看到有些事实表中有很多时间字段。这些时间字段和维度表应该怎样关联是我们要考虑的事情。通常我们有三种粒度的事实表，分别是事务粒度事实表（Transaction Grain），周期快照粒度事实表（Periodic Snapshot Grain）和累计快照粒度事实表（Accumulating Snapshot Grain）。这种多个时间字段的事实表多为累计快照事实表。例如一个事... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(560) 评论(0) 推荐(0)

KDT#1 建立点击流数据仓库的一些指导

摘要： 点击流数据指的是用户在WEB服务器提供的网页中点击事件形成的日志。用户的每一次点击都会生成日志。而对这些用户在网站上点击页面情况及停留时间情况的分析是电子商务等非常关心的内容。对这部分内容建立数据仓库，一般称为点击流数据仓库（Clickstream Data Warehouse）。点击流数据量是巨大的，对于中等规模的商业网站来说，每天一会产生1亿左右的页面点击事件。所以在建立数据仓库时需要在保证分... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(629) 评论(0) 推荐(0)

浅析杂项维度

摘要： 在维度建模的数据仓库中，有一种维度叫Junk Dimension，中文一般翻译为“杂项维度”。杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的指示符或者标志字段。例如：支付类型字段，包括现金和信用卡两种类型，在源系统中它们可能是维护在类型表中，也可能直接保存在交易表中。一张事... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(2062) 评论(0) 推荐(0)

浅析总线架构

摘要： 维度建模的数据仓库中，有一个概念叫Bus Architecture，中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。在多维体系结构（MD）的数据仓库架构中，主导思想是分步建立数据仓库，由数据集市组合成企业的数据仓库。但是... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(1193) 评论(0) 推荐(0)

浅析一致性事实

摘要： 维度建模的数据仓库中，有一个概念叫Conformed Fact，中文一般翻译为“一致性事实”。一致性事实是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性维度（Conformed Dimension）。在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(1537) 评论(0) 推荐(0)

Kimball 设计技巧导读（二）

摘要： Kimball Group每个月会通过email发布一个设计技巧。下面是其中部分设计技巧的整理，因为是根据自己的理解翻译的，肯定会有很多不足之处。其中内容翻译不清的地方可以和我联系，大家共同探讨，或者直接参照原文。Kimball的网站上有2006年及以前的全部原文下载，2007年的也可以通过email订阅。具体方式请参阅Kimball的网站。KDT#51 时间维度表KDT#52 改进数据仓库系统的... 阅读全文

posted @ 2010-08-05 13:54 李梦蛟 阅读(942) 评论(0) 推荐(0)

KDT#8 使用类型二的缓慢变化维

摘要： 通常应对缓慢变化维的解决策略有三种类型，分别是类型一直接更新、类型二增加行、类型三增加列。使用类型二时，当维度表的数据发生变化时，我们会增加一条新记录到维度表中，并用代理键作为主键。本日志要讲的就是使用类型二的缓慢变化维策略可以对历史数据提供逻辑上的分区。使用类型二的策略需要代理键的支持，以产品维度为例，当产品描述变化时，需要增加一条新的记录，用自增的代理键和变化前的记录相区别。而产品编码不会改变... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(570) 评论(0) 推荐(0)

KDT#9 实际处理缓慢变化维时的一个妥协

摘要： 在对已有数据仓库添加新的主题时，需加载的维度表也会存在历史记录的情况，这时，和普通的缓慢变化维的加载方式就会存在着不同。通常缓慢变化维的加载时是增量加载，查找表中只保留最新的代理键和自然键的对应关系。而像新增主题这样的批量加载，查找表中会保留维度变化的历史信息。当批量加载维度表的历史信息时，在查找表中查询代理键的SQL示例如下：Select customer_key from customer_l... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(360) 评论(0) 推荐(0)

KDT#5 补充 使用代理键的日期维度

摘要： 在KDT#5中已经说明，日期维度的关键字应该是一个整型的代理键，而不应该是日期型。更进一步来说，在建立日期维度时关键字应该按日期的顺序来分配顺序的整数，即代理键应该按日期的顺序分配为是1,2,3...N。按日期顺序分配的代理键有着非常大的用途。它使事实表可以基于日期进行物理的分区。按日期对大的事实表进行物理分区是一种很常见的情况，它可以很方便的分离历史数据，而且可以使最新的数据在不影响事实表中其他... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(361) 评论(0) 推荐(0)

KDT#14 事务粒度事实表中某天数据的查询

摘要： 对于事务粒度事实表来说，只有当该天有事务发生时，才会在事实表中出现当天的记录。一个简化的事务粒度事实表如下所示。Date_Key(FK)Account_Key(FK)Transaction_Type_Key(FK)Transcation_Sequence_NumberFinal_FlagAmountBalance表中，Date_key是日期维度表的代理键。Account_key是帐户维度表的代理键... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(454) 评论(0) 推荐(0)

KDT#15 组合使用缓慢变化维技术

摘要： 在数据仓库的项目中对历史信息进行分析时，我们通常使用缓慢变化维的三种处理策略来完成。但是，有时客户的需求是既能用历史维度属性对事实进行分析，又能使用维度当前的属性信息来对整个历史的事实进行分析。这样，标准的三种处理策略都不能很好的满足分析的要求，我们需要组合使用三种处理方式。首先，对于维度属性的变化，我们需要使用TYPE 2来建立一条新的记录捕捉变化信息，这需要生成新的代理键。同时，我们需要使用T... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(338) 评论(0) 推荐(0)

KDT#16 热交换维度

摘要： 热交换维度指在数据仓库中，一个维度有两个或更多个可供选择的版本。也就是说，对于不同的用户，我们不想让他们看到该维度的全部信息，所以我们可以定制该维度的不同版本，而在用户查询时根据当时的需要给用户选择一个适合他的版本。下面是是一个使用热交换维度的例子：一个制造业的企业想把自己的发货事实表提供给他的交易伙伴访问，但是需要对交易伙伴屏蔽掉其他交易伙伴的订单信息。处理的方式是，为每一个伙伴建立一个&ldq... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(570) 评论(0) 推荐(0)

KDT#11 在有缓慢变化维的维度表中统计个数

摘要： 对于有丰富的描述属性的维度表，我们经常会对其统计个数，例如客户表，我们会按各种口径（支付类型、所在地区、性别等）统计其个数。如果是静态的维度表，统计个数是件非常简单的事情，如果是有缓慢变化维的维度表，统计个数时就需要多加小心。在有缓慢变化维的维度表中统计个数，不加小心的话容易统计重复。因为，以客户维度表为例，我们会对同一个客户的不同历史信息保存多条记录。对于统计当前各口径的客户数来说，如果我们很好... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(399) 评论(0) 推荐(0)

KDT#13 可以作为维度表使用的事实表

摘要： 事实表从粒度的角度分为三种，分别是交易粒度事实表、周期快照事实表和累计快照事实表。交易粒度事实表能提供某个确切时刻的描述信息。以银行帐户中保存的客户信息为例来说，代理机构会周期的更新客户的名称、地址、电话号码、客户分类、信用等级、风险等级及其他描述性信息。建立的交易粒度事实表如下所示：变更日期（FK）帐户号（SK）代理（FK）客户信息变更类型（FK）帐户号（NK）名称（文本事实）地址（文本事实）电... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(487) 评论(0) 推荐(0)

KDT#7 使数据仓库项目步入正轨

摘要： 在数据仓库的项目中，常会遇到用户不满意开发的结果，他们会抱怨数据太混乱，查询太慢等问题。这时，我们应该从以下几个方面来检查我们的开发过程。1．项目组是否收集好了用户的需求并把按用户的需求实现数据仓库放在第一位。这个问题是数据仓库项目中最常见的问题。如果项目组把数据或者技术放在第一位，项目很可能会偏离正常的轨道。2．项目组是否采用了数据仓库总线矩阵。总线矩阵是数据仓库项目组最有用的工具。采用总线矩阵... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(325) 评论(0) 推荐(0)

KDT#18 有关出版社的比喻

摘要： 在本Tip中，Kimball描述了数据仓库项目和出版社之间的一个比喻，下面是在数据仓库项目中应该能够做到的一些要点。（出版社的比喻略）了解用户的业务范围、工作职责和计算机能力。描述出用户需要要数据仓库完成的功能。找出能通过使用数据仓库系统完成有效决策的用户。找到潜在的用户，并使他们意识的数据仓库的作用。在数据仓库中首先实现最有效率，最用效果的主题。要尽可能的使用户的界面和应用程序简单好用，最好使用... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(342) 评论(0) 推荐(0)

KDT#6 如何处理关联的维度

摘要： 在我们进行维度建模时，有时两个维度之间会出现关联。例如：产品维度和市场维度。这时，我们通常的处理方式有两个，一个是建立两个独立的维度表，每个维度表外键关联到事实表，另一个是合并成一个超级维度表（Super Dimension）。接下来，我们考虑什么时候该建立独立的维度表，什么时候该建立超级维度表。以产品和市场来说，如果它们是一对一或者多对一的关系的话，建立超级维度是一个合理的选择。建立好的超级维度... 阅读全文

posted @ 2010-08-05 13:53 李梦蛟 阅读(450) 评论(0) 推荐(0)

KDT#31 定义实时分区（一）

摘要： 目前来说，OLTP和数据仓库中数据的时间差距已经缩短到了1天，即24小时。但是常会出现更急迫的需求，需要能在数据仓库中提供近似于实时的数据。这时，我们可以通过在数据仓库前面建立一个实时分区来解决这个问题。通常，实时分区和数据仓库分开建立和管理，并在其中使用不同的更新规则和查询规则。实时分区的需求如下：1．包括上一次更新数据仓库之后所有的业务活动数据。2．和数据仓库在内容和粒度上要能无缝的连接上。3... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(377) 评论(0) 推荐(0)

KDT#27 减小离线时间的一种方法

摘要： 在数据仓库系统中，通常我们会每天迁移新的数据进入数据仓库。一般来说，我们会在凌晨时用户不会使用的某段时间进行数据的迁移，在数据迁移的这段时间，数据仓库处于离线状态。但是对于较大的数据仓库系统，用户可能分布在全国或者全球，用户的时区不一样，工作时间也不同，在我们凌晨时其他地区的用户可能还在工作。这就要求我们要尽量的减小数据仓库的离线时间。有一种方法可以解决这个问题，就是使用分区（partition）... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(315) 评论(0) 推荐(0)

KDT#28 避免数据仓库项目灾难性的故障

摘要： 当数据仓库开始支持企业的各种分析应用，提供近实时的数据时，它已经变成了企业应用中不可缺少的一部分。这时，如何避免数据仓库发生灾难性的故障是至关重要的。通常，灾难性的故障可能由如下原因导致：1．物理硬件的损坏。恐怖袭击或者火灾等其他原因导致建筑和机器全部损坏，会导致数据仓库完全损坏。2．内部人员蓄意破坏。如果内部人员被收买或者有对头企业的人员打入公司内部，会导致数据仓库逻辑或者物理损坏。3．黑客攻击... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(327) 评论(0) 推荐(0)

KDT#24 跨国数据仓库的维度表的设计方法

摘要： 当你在设计跨国数据仓库时，一定会遇到下面几个问题。比如，如何处理多国语言；数据仓库中的哪一部分需要翻译成多国语言；如何处理逐渐增加的语言版本。本日志要面对的就是如何来处理多国语言的问题。对于跨国的分布式的数据仓库来说，用户一般会通过一致性维度交叉探察不同地区的数据仓库。而处理多国语言的问题的关键在于这些一致性维度表，因为这些维度表中保存的属性有用户报表的标签，数据的层级关系和数据的描述。解决多国语... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(438) 评论(0) 推荐(0)

KDT#25 主子表的维度模型设计方法

摘要： 首先对“主子表”这个词进行一下解释，举例来说，对于一个销售单来说，通常业务建模会有两个表，一个是销售主表，记录销售的总体信息；另一个是销售子表，记录销售的每个产品的信息。类似销售主子表这样的应用，在没有想到更恰当的词之前，我暂将其称之为“主子表”。以区别于为不知层深而建立的可以多层的单张“父子表”。在维度建模中，可以将这种&l... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(534) 评论(0) 推荐(0)

KDT#26 建立审计维度表

摘要： 通常，维度表中保存的是企业各种度量的描述信息。我们也可以考虑在添加事实记录时将一些元数据建立成维度表供用户访问，这样的维度表就是审计维度表。审计维度表可以提供如下所示的数据，1．事实数据的来源是哪里。2．是用那个版本的ETL软件进行抽取的。3．生成事实数据的逻辑是怎样的。4．区分某个事实是“不知道”、“不可能”、“已损坏”还是... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(416) 评论(0) 推荐(0)

KDT#21 定义事实表的粒度

摘要： 维度建模中一个非常重要的步骤是定义事实表的粒度。定义了事实表的粒度，则事实表能表达数据的详细程度就确定了。定义粒度的例子如下：1．客户的零售单据上的每个条目。2．保险单上的每个交易。定义好事实表的粒度有很大的用处。第一个用处就是用来确定维度是否与该事实表相关。例如，对于粒度细到医疗单据上条目项的事实表来说，医疗结果是不会作为维度和它进行关联的，因为它们不在同一个粒度上。但是，对于一般的E/R数据模... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(487) 评论(0) 推荐(0)

KDT#22 谈谈客户维度

摘要： 在维度建模的数据仓库中，客户维度通常是最有挑战性的维度。一般来说，客户维度有如下三个特点，记录很多，有可能有百万数量级；属性很多，有可能几十或者上百；缓慢变化，有时变化也很快。对于建立基于Web环境的数据仓库来说，客户维度表中通常有两类客户，一类是没有注册过的访问者，另一类是注册过的客户。未注册的客户是匿名的，有可能和企业有多次业务交易，但是企业并不知道客户的详细信息。尤其是在Web环境中，我们通... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(478) 评论(0) 推荐(0)

KDT#19 保证维度复制的正确

摘要： 建立分布式数据仓库的关键是使用一致性维度。实现一致性维度最简单的办法就是使用完全相同的维度表。一致性维度比较复杂的情况是允许使用维度表的子集。以产品为例，有些部门的分析需求可能只是商标粒度，而不是细到产品粒度。这时需要通过产品维度表来实现商标维度表，而商标维度表要保证是产品维度表完全的子集。这样，商标维度表和产品维度表就是一致性的维度表。使用一致性维度最大的好处就是可以在分布的数据集市中进行交叉探... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(957) 评论(0) 推荐(0)

KDT#20 稀疏事实表和事实维度表

摘要： 事实表一般围绕着度量来建立，当度量产生的时候，事实记录就生成了。度量可以是销售数量、交易流水值、月末节余等数值。如果同时生成多个度量值的话，我们可以在一个事实表中建立多个事实。当我们的事实表中的事实比较多时，有可能多个事实不同时发生，如果同时生成的几率很小，我们称之为稀疏事实表（Sparse Facts）。对于稀疏事实表，通常会在事实中存在大量的NULL值。通常的处理方式是建立“事实维... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(607) 评论(0) 推荐(0)

KDT#17 层级结构助手表

摘要： 层级结构（Hierarchical Structures）是企业中数据库建模中很常见的一种结构，也就是我们常说的“父子表”。通常我们的建模方式是建立成递归的结构。如下例所示：Create table COMPANY{COMPANY_KEY INTEGER NOT NULL,COMPANY_NAME VARCHAR2(50),PARENT_KEY INTEGER};这种结构对... 阅读全文

posted @ 2010-08-05 13:52 李梦蛟 阅读(462) 评论(0) 推荐(0)

KDT#36 关于集中式的考虑

摘要： 在数据仓库领域，集中式（Centralized）是个讨论的很多的概念。物理的集中可以减小管理成本，提高性能。但是我们更应该关注的是数据在逻辑上的集中，即数据的整合及一致性处理。而物理上是集中式的还是分布式的都是可以接受的，需要根据具体情况来定。如果只是物理上进行了集中，而没有进行数据的整合，就好比买了一个大箱子，把所有的杂物放入其中，仍是乱糟糟的一堆垃圾。这时就会出现下面这些情况：1．从相同的数据... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(266) 评论(0) 推荐(0)

KDT#38 谈谈分析应用（一）

摘要： 在数据仓库领域，建立分析应用已经越来越热门。一般来说，分析应用是针对企业绩效分析的一套程序或者处理，它可以指导企业的决策，并且分析的结果是可以复现的。举例来说，一般的分析应用诸如销售绩效评估、客户盈利分析、产品销售途径分析。分析应用需要结合企业的需求、分析应用能让我们更了解企业的绩效情况，并对提高企业的绩效提供支持。从根本上来说，分析应用和基于数据仓库上的决策支持系统没有什么不同。建立分析应用（A... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(344) 评论(0) 推荐(0)

KDT#34 EDW的几个缺点

摘要： EDW是Enterprise Data Warehouse的简写。这里EDW指Inmon的CIF构建方法，EDW架构指的也是CIF架构。本文比较了EDW架构和总线架构的差别，并指出了EDW架构的缺点，当然这是Kimball的观点。1．从逻辑模型上来说，两种构建数据仓库的方法都以为企业建立一致性的数据为基础。总线架构采用一致性维度和一致性事实来进行一致性处理。EDW架构采用高度规范化的E/R模型来保... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(386) 评论(0) 推荐(0)

KDT#35 时间跨度的建模（一）

摘要： 在过去的一些年里，我们看到很多对时间跨度的需求。一般来说，我的事实表中每条记录保存的数据都是在一段时间内不会发生变化的。也就是说，需要的时间跨度可以在任意的时间点开始和结束。有时，我们保存的记录中时间跨度可以很好的连续在一起，但是有时也可能会出现中断的情况，更差的情况下，数据跨度可能会出现重复的情况。这些时间跨度在数据库中都以单条记录的形式进行保存。为了能更形象的表示这些变化，我们来考虑一个例子。... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(455) 评论(0) 推荐(0)

KDT#32 数据仓库设计中的折中处理（三）

摘要： 6．不同种类产品的建模对于像银行、保险等提供金融服务的企业来说，不同的帐户会有不同的度量信息。而不同的客户会查看不同的帐户度量信息。在这样一个大型的零售银行，针对不同的帐户类型会有总数200多种特殊的度量，分散在不同的帐户类型上。这时，直接由所有的属性生成巨大的事实表和维度表是不可取的。而应该先建立一个核心的事实表来保存四到五个对所有帐户都通用的度量字段，如结余等。然后根据不同的帐户类型建立扩展的... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(277) 评论(0) 推荐(0)

KDT#33 使用CRM的度量对客户进行分析

摘要： 在进行客户关系管理（CRM）分析时，通常有三个客户行为分析值，分别是最近访问时间、访问频率和交易数量。最近访问时间指我们和客户最后一次接触的一些信息，包括最后访问时间或者最后一次接触到目前的时间间隔等。访问频率指我们和客户的接触频率。交易数量是我们和客户交互量的度量，例如购买量或者访问站点网页的总量等。在实际构建系统，每一个都需要进行细化。通常这种针对最近访问时间（recency）、访问频率（fr... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(307) 评论(0) 推荐(0)

KDT#32 数据仓库设计中的折中处理（二）

摘要： 3．多币别的数据建模多币别的问题与多时区的问题很相似，处理方法也类似。同样的，我们对币别问题有两个相同的观点。比如说，如果交易发生在一个特定的币别下，我们理所当然的想知道确切的币别信息。但是当我们想进行汇总统计时，多国的币别会给我们带来很大的麻烦。这时，我们的处理方法很处理多时区类似，就是保存两个币别的数据，一个时本地发生交易的类别，另一个是选择的标准币别。我们同时，我们也需要建立一个币别维度表来... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(303) 评论(0) 推荐(0)

KDT#31 定义实时分区（二）

摘要： 2．周期快照粒度实时分区对于周期快照粒度的事实表来说，实时分区相当于该周期内的累计值。即本周期虽然还未结束，但是本周期已内发生的交易的数据已经累计好了。当本周期内发生新的交易时，这个值继续累计，直到本周期结束，写入数据仓库的周期快照事实表中。实时分区中的周期快照事实表也可以全部加载在内存中。应用程序对实时分区中周期快照的查询和交易粒度的查询不太相同，在统计总数值时，需要将实时分区和数据仓库中的相关... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(399) 评论(0) 推荐(0)

KDT#32 数据仓库设计中的折中处理（一）

摘要： 数据仓库设计师的目的是有效的发布企业的数据。这就意味着数据仓库中的数据应该是对最终用户和应用程序来说是非常容易使用的。在数据仓库设计时，我们会采取一些折中处理，如增加数据后台的处理过程、增加数据存储空间，来得到下列好处。1．得到用户容易理解的数据存储结构，这种结构是对称的、可预测的。2．减小了应用程序的复杂度。3．提高查询和报表的性能。好的数据仓库设计师会通过类似的折中处理，使最终用户的使用变得简... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(520) 评论(0) 推荐(0)

KDT#29 对维度表和事实表进行修改

摘要： 尽管在做数据仓库设计时，我们会考虑的很周全，但是对于建立一个数据仓库来说，一定会遇到增加新的数据类型、增加数据关联关系甚至需要增加新的数据源等问题。在这些情况发生时，理想的设计是可以在不影响数据仓库上的应用程序的基础上完成上述功能。当然，在实际工作中，肯定会有些变动我们无法在不影响应用程序的情况下改进设计。这里要说的是维度模型在支持设计的修改方面是很强的，下面列出了一些可以支持修改的情况。1．增加... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(553) 评论(0) 推荐(0)

KDT#30 减小事实表的容量

摘要： 早期的数据仓库构建思想是将所有能得到的数据都放入数据仓库，随着信息的爆炸，数据仓库的尺寸开始变得不可接受。有两种方法可以解决这个问题，一个是数据过滤减少进入数据仓库的数据，另一个就是通过合理的设计减小数据仓库存储空间。本文简单讨论一下第二种方法。在维度建模的设计中，维度表占用的空间相比事实表要小很多，如何减小事实表的容量是采用第二种方法的关键。通常有如下方法可以减小事实表的容量。1． 将所有的自然... 阅读全文

posted @ 2010-08-05 13:51 李梦蛟 阅读(313) 评论(0) 推荐(0)

KDT#35 时间跨度的建模（二）

摘要： 对于一些相对复杂的关于时间跨度的问题如下。· 查询在一个时间跨度中的某个时间点的所有客户。· 查询在一个时间跨度中某个给定客户的最后一个事务处理记录。· 查询在任意个一个指定的时间点的帐户余额信息。在下面的讨论中，我们还假定时间跨度是以天为单位。上面提到的三个问题我们可以通过在事务表中增加时间戳来回答，但是这样的话查询会非常复杂而且效率很低。例如，为了回答... 阅读全文

posted @ 2010-08-05 13:50 李梦蛟 阅读(412) 评论(0) 推荐(0)

KDT#40 分析应用的结构

摘要： 分析应用通常是建立在数据仓库之上，用来支持企业决策的应用。一个好的分析应用通常建立在一个好的分析框架上，用来给用户提供分析的操作，其提供的功能应该远不止标准的报表。这个分析环境应该能给用户提供辅助决策的分析功能，使用户对企业的状况的发展及处境有更清晰的了解，最终能帮他们作出更有洞察力，更全面的决策。分析应用的目的是：· 辅助决策的作用。· 标识并解释企业绩效的异常状况。... 阅读全文

posted @ 2010-08-05 13:50 李梦蛟 阅读(252) 评论(0) 推荐(0)

KDT#39 谈谈合并数据集市

摘要： 维度模型以其高性能和易使用两大特点为分析应用提供了有效的支持。在采用维度模型进行数据仓库架构时，还有两个要点要多为注意，其中一个是总线架构，另一个就是合并数据集市（Consolidated Data Marts）。在MD架构中，通常数据集市的建立是面向业务处理过程的，不同业务处理过程的事实数据很可能会分散在不同的数据集市中。这对于需要跨多个业务处理过程进行分析的应用来说，需要进行交叉探查操作。而交... 阅读全文

posted @ 2010-08-05 13:50 李梦蛟 阅读(321) 评论(0) 推荐(0)