摘要：在网上有看到过Websphere Portal 6.0和cognos8集成的文章，但是没有看到自己开发的门户和cognos的集成，这两者还是有较大的区别的。我们公司的BI就是采用的自己开发BI门户集成cognos报表的方式的，今天来和大家分享一下企业自己定制开发的门户（技术不限，.net或java都行）与cognos报表的集成的经验。集成分成页面级集成和API级别的集成，页面集成的含义就是直接通过...
阅读全文
摘要：数据仓库架构1．企业的数据仓库已经从50GB增长到了1TB。它最初仅有50个用户，而现在已增长到300个用户。系统的响应慢得吓人，用户怨声载道，DBA在数据仓库的扩展和性能方面遇到的极大的困难。所有的新需求都被置之不理。所有的一切都是由于最初的架构引起的，这个架构只考虑了50G空间和50个用户。而目前架构中的任何变化都将是高代价和破坏性的。面对这种局面，数据仓库设计师应该如何处理？2．一家企业内有...
阅读全文
摘要：性能1．一家企业把一个较大的财务、培训和实现责任都托付给一个软件产品。但是这个软件产品目前的性能出现了问题，几乎不能运转了。面对这种局面，这家企业应该做些什么呢？2．一家企业的数据仓库中数据量的增长比它的源系统数据量增长快得多。硬件的成本已经超出了预算，而且眼前没有停止的迹象。管理层很担心，并提出了两个较难回答的问题。这个数据仓库该不该比源系统数据增长得更快？如果不，数据仓库经理能够采用什么样的措...
阅读全文
摘要：数据质量1．一个数据质量分析师正在试图分析一个数据仓库之中数据的质量状况。这个数据仓库的数据量非常的大，数据质量分析师准备用抽样的方式进行分析。但是他不知道需要抽样多少数据，如何抽样，以及如何向用户解释抽样分析的结果是准确的。这位数据质量分析师应该如何来进行工作呢？2．一个电信公司有一个含有14TB数据的数据仓库。这家公司估计到，该数据中有10TB以上的数据可能是冗余的。这家公司没有命名约束，其中...
阅读全文
摘要：数据整合1．一家拥有650个经销商的汽车制造公司，有3个独立的经销管理系统，这650个经销商都有自己的数据库。这家企业应该如何来收集、清理并整合这些数据呢？2．一家企业为了保证企业内数据的一致性，委任了一名数据管理经理为整个企业创建一个统一的企业数据模型。但是，企业内有两个项目正准备开工，而且两个项目经理都不愿意等企业数据模型的建成。没有企业数据模型的情况下，建立的信息系统很难和企业内的其他系统进...
阅读全文
摘要：工具与供应商1．一个非盈利性企业正准备建立一个数据仓库，来跟踪他们全体成员的活动。这样一个大的项目需要一个需求建议书，其中会有筛选供应商的资料等内容。但是，企业的高级管理人员不希望这个需求建议书影响他们的进度。面对这种局面，企业应该采取什么样的对策？2．一家企业的数据仓库建好之后，发现经过培训的用户只有5％的人经常使用。而没有使用的人员对查询和报表制作工具不满意，因此不使用数据仓库。面对这种局面，...
阅读全文
摘要：安全1．一个企业建立了一个数据仓库系统，用来分析企业的部门及产品相关盈利能力。数据仓库实现不久，项目经理被CFO叫到办公室，被要求解释为什么一位职位低下的金融分析师能够在数据仓库中查看详细的工资记录，这些数据在公司中只有副总裁才可以访问。显然，这个数据仓库中没有建立安全计划。面对这种局面，这家企业怎么才能扭转这种局面呢？2．一位数据仓库咨询人员告诉一家企业，他们必须考虑数据仓库内的安全问题，并应该...
阅读全文
摘要：数据仓库标准1．一家企业要建设一个数据仓库，但是这家企业的工作人员没有数据仓库的使用经验，对数据仓库建设方法学也一无所知。数据仓库项目经理应该如何做，才能让用户相信在一个数据仓库项目中使用一种方法学是必要的呢？2．一家银行为它的业务数据库环境制订了非常严格的数据库管理标准。这些DBA强调，必须要像设计和管理OLTP环境一样管理这个数据仓库环境。数据仓库经理怎样做，才能使这些DBA认识到这个标准不适...
阅读全文
摘要：团队问题1．企业IT部门一个非常聪明、工作努力的人极想从他喜爱的供应商那里获得一个β版本，用于数据仓库的实现。如果他不能得偿所愿，他要么离开，要么不再支持这个项目。项目经理应该如何来应付这种局面？2．管理层给项目经理一个这样的团队，其中的成员既无技能、也无热情，是其他项目经理不想留在自己团队中的人员。面对这种局面，项目经理应该如何应付？3．管理层希望数据仓库团队中的每个人都相处融洽，但是...
阅读全文
摘要：项目规划与进度安排1．企业高管层不了解数据仓库项目为什么会花费那么多的时间。他们认为目前的计划和工作量经过了夸张，所以他们要求能有更具体化的依据来支持评估的工作量。项目经理应该如何应付这种情况。2．IT团队曾多次错过完成期限而得到了较坏的名声。这次，项目经理向老板承诺了一个不切实际的最终期限。高管层也向项目经理明确宣布，他在公司的声誉及饭碗就取决于该时间表。项目经理该如何应对这种局面。3．项目经理...
阅读全文
摘要：组织与职员配备问题整理1．数据仓库经理认为自己的团队应该对CIO负责，但是，一个强有力的应用软件开发经理认为数据仓库的最终目的是要交付用户使用，数据仓库团队应该向他负责。数据仓库经理应该向谁负责？应该如何来应付这种局面？2．一家公司采用矩阵管理方式。项目经理手下没有专职的DBA，只能依靠DBA经理在需要时提供DBA。但是在需要DBA时，DBA未必总有空闲的。项目经理正要开始另一个项目，她应该作些什...
阅读全文
摘要：用户问题1．企业内各业务部门的系统之间不是集成的，那些业务主管想让他们的数据进入数据仓库中，而且他们都想马上就能实现。而数据仓库经理只能逐个的满足他们的要求，要避免引起业务主管的愤怒，也要避免他们开发自己的数据仓库，数据仓库经理应该如何来处理这种局面？2．企业的IT部门雇佣了一名咨询人员来开发一个数据仓库，但是该企业的业务部门不支持这个项目。IT部门告诉这名咨询人员继续工作，即使业务部门计划赶他走...
阅读全文
摘要：项目需求问题整理1．数据仓库项目已经开发了6个月的时间，在项目的开发过程中，数据仓库团队发现业务源系统正在被重写，业务系统在不断的变化，一个新的系统开发出来预计只有8个月的寿命。数据仓库团队应该如何应付这种情况？2．源系统和数据仓库系统同期建设。但是源系统在不断的变化中，而且源系统的开发团队没有将变化告知数据仓库团队，数据仓库团队在测试过程中出现故障才发现这些变化。这种没有告知有可能是故意的。数据...
阅读全文
摘要：数据仓库成本论证与预算1．企业有“禁止解雇”政策，管理层对工作效率的提高和成本的节约不是很关心。项目经理该如何对数据仓库及其相关工具的成本进行论证？2．企业高级管理层成立了一个委员会，希望委员会能论证用于数据仓库及其工具的任何支出都是合理的。但是委员会只能从软收益来论证，企业该如何来处理这种情况？3．大型零售企业的信息总监认为本企业需要一个数据仓库，但是企业的财务总监对建立...
阅读全文
摘要：项目管理问题整理1．企业经历过两次失败的数据仓库建设，现在是第三次，人们普遍认为这次也将会失败。项目经理应该作些什么来消除人们对数据仓库的消极看法？2．企业的业务系统方，即OLTP方的工作人员对数据仓库方不配合，比如对数据仓库的源数据申请置之不理。项目经理应该如何来应付这种情况？3．企业的管理层变动较频繁，支持数据仓库的企业领导可能会离开，面对这种情况，项目经理应该如何应付？4．企业雇佣一家咨询公...
阅读全文
摘要：本部分内容整理于Sid Adelman的著作Impossible Data Warehouse Situations。其中的问题都是从业人员在工作中经历的实际问题。这些问题同样也可以作为数据仓库项目经理的面试问题。这些问题很多没有固定的答案，不同的人会有不同的想法。重要的是在看到这些问题时能有一些自己的想法。1．项目管理2．项目需求3．成本论证与预算4．组织与职员配备5．用户问题6．团队问题7．项...
阅读全文
摘要：Describe the architecture options for implementing real-time ETL.简述在架构实时ETL时的可以选择的架构部件。答：在建立数据仓库时，ETL通常都采用批处理的方式，一般来说是每天的夜间进行跑批。随着数据仓库技术的逐步成熟，企业对数据仓库的时间延迟有了更高的要求，也就出现了目前常说的实时ETL（Real-Time ETL）。实时ETL是数...
阅读全文
摘要：Explain the different real-time approaches and how they can be applied in different business scenarios.简述几种不同的实时ETL实现方法以及它们的适用范围。答：实时数据仓库在目前来说还不是很成熟，成功案例也比较少，下面列举了一些实时数据仓库架构的实现方法。1．EII ONLY使用EII技术来代替实...
阅读全文
摘要：Outline some challenges faced by real-time ETL and describe how to overcome them.简述实时ETL的一些难点及其解决办法。答：实时ETL的引入给数据仓库的建设带来了很多新的问题和挑战，下面列举了一些问题，其中有些问题有具体的解决办法，有些只能在实际情况下去斟酌。1．连续的ETL处理对系统可靠性提出更高的要求。2．离散快照...
阅读全文
摘要：What steps do you take to determine the bottleneck of a slow running ETL process?如果ETL进程运行较慢，需要分哪几步去找到ETL系统的瓶颈问题。答：ETL系统遇到性能问题，运行很慢是一件较常见的事情，这时要做的是逐步找到系统的瓶颈在哪里。首先要确定是由CPU、内存、I/O和网络等产生的瓶颈，还是由ETL处理过程产生的...
阅读全文
摘要：Describe how to estimate the load time of a large ETL job.简述如何评估大型ETL数据加载时间。答：评估一个大型的ETL的数据加载时间是一件很复杂的事情。数据加载分为两类，一类是初次加载，另一类是增量加载。在数据仓库正式投入使用时，需要进行一次初次加载，而这次初次加载需要的时间一般较难预料。在数据仓库的日常使用和维护中，每天需要对数据仓库进行...
阅读全文
摘要：Offer techniques for sharing business and technical metadata.简述共享业务元数据和技术元数据的方法。答：为了能共享各种元数据，在数据仓库的构建过程中必须要有一些元数据标准，并在实际开发中遵守这些标准。这些标准包括元数据命名规则、存储规则及共享规则等内容。有关元数据标准的内容可以参看公共仓库元模型（Common Warehouse Meta...
阅读全文
摘要：State the primary types of tables found in a data warehouse and the order which they must be loaded to enforce referential integrity.简述数据仓库中的表的基本类型，以及为了保证引用完整性该以什么样的顺序对它们进行加载。答：数据仓库中的表的基本类型有维度表、事实表、子维...
阅读全文
摘要：What are the characteristics of the four levels of the ETL support model?简述ETL技术支持工作的四个级别的特点。答：数据仓库上线后，ETL组需要为保证ETL工作的正常运行提供技术支持。通常这种技术支持工作分为四个级别。1．第一级别的技术支持通常是电话支持人员，属于技术支持服务窗口（Help Desk）类型。如果数据迁移出现错...
阅读全文
摘要：Describe the different types of ETL metadata and provide examples of each.举例说明各种ETL过程中的元数据。答：元数据是ETL项目组面对的一个非常重要的主题，对于整个数据仓库项目也是非常重要的一部分。对于元数据的分类和使用没有很确定的定义。通常来说，我们可以把元数据分为三类，分别为业务元数据（Business Metadat...
阅读全文
摘要：Share acceptable mechanisms for capturing operational metadata.简述获取操作型元数据的方法。答：操作型元数据（Operational Metadata），也就是过程处理元数据，记录的是ETL过程中数据迁移情况，如上次迁移日期，加载的记录数等信息。这部分元数据在ETL加载失败时会非常重要。一般来说，对于使用ETL工具的数据加载，像迁移调度...
阅读全文
摘要：How are bridge tables delivered to classify groups of dimension records associated to a single fact?简述桥接表是如何将维度表和事实表进行关联的？答：桥接表（Bridge Table）是维度建模中的一类比较特殊的表。在数据仓库的建模时，会遇到具有层次结构的维度表，对于这样的表有一种建模方式是建立父子表...
阅读全文
摘要：How does late arriving data affect dimensions and facts? Share techniques for handling each.迟到的数据对事实表和维度表有什么影响？怎样来处理这个问题？答：迟到的数据分为两种，一种是迟到的事实表数据，另一种是迟到的维度表数据。对于迟到的事实记录，我们可以插入到相应的事实表中。在插入的同时，还需要做一些处理。首...
阅读全文
摘要：Explain the three basic delivery steps for conformed dimensions.简述对一致性维度的三种基本的交付步骤。答：数据整合的关键就是生成一致性维度，再通过一致性维度将来自不同数据源的事实数据合并到一起，供分析使用。通常来说，生成一致性维度有如下三个步骤：1.标准化（Standardizing）标准化的目的是使不同数据源的数据编码方式，数据格式...
阅读全文
摘要：Name the three fundamental fact grains and describe an ETL approach for each.简述三种基本事实表，并说明ETL的过程中如何处理它们。答：事实表从粒度的角色来划分可以分为三类，分别是交易粒度事实表（Transaction Grain）、周期快照粒度事实表（Periodic Snapshot）和累计快照粒度事实表（Accumu...
阅读全文
摘要：Why do dates require special treatment during the ETL process?为什么在ETL的过程中需要对日期进行特殊处理？答：在数据仓库的项目中，分析是主导需求，而基于日期和时间的分析更是占了很大的比重。而在操作型源系统中，日期通常都是SQL的DATETIME型的。如果在分析时，使用SQL对这种类型的字段临时处理会出现一些问题，如效率很差，不同的用户...
阅读全文
摘要：How can data quality be quantified in the data warehouse?如何来量化数据仓库中的数据质量？答：在数据仓库项目中，通常通过不规则数据的检测工作（Anomaly Detection）来量化源系统的数据质量。除非成立专门的数据质量调查项目组，否则这个工作应该由ETL项目组完成。通常可以采用分组SQL来检查数据是否符合域的定义规则。对于数据量小的表，...
阅读全文
摘要：What are surrogate keys? Explain how the surrogate key pipeline works.什么是代理键？简述代理键替换管道如何工作。答：在维度表的迁移过程中，有一种处理方式是使用无意义的整型值分配给维度记录并作为维度记录的主键，这些作为主键的整型值称为代理键（Surrogate Key）。使用代理键有很多好处，如隔离数据仓库与操作环境，历史记录的保...
阅读全文
摘要：What are the four broad categories of data quality checks? Provide an implementation technique for each.数据质量检查的四大类是什么？为每类提供一种实现技术。答：数据质量检查是ETL工作中非常重要的一步，主要关注一下四个方面。1．正确性检查（Corret）检查数据值及其描述是否真实的反映了客观事务...
阅读全文
摘要：At which stage of the ETL should data be profiled?简述应该在ETL的哪个步骤来实现概况分析？答：数据概况分析是对源数据内容的概况进行分析，应该在项目的开始后尽早完成，它会对设计和实现有很大的影响。在完成需求收集后就应该立即开始数据概况分析。数据概况分析不光是对源系统的数据概况的定量描述，而且为ETL系统中需要建立的错误事件事实表（Error Eve...
阅读全文
摘要：What are the essential deliverables of the data quality portion of ETL?ETL项目中的数据质量部分核心的交付物有那些？答：ETL项目中数据质量部分的核心的交付物主要有下面三个：1．数据概况分析结果数据概况分析结果是对源系统的数据状况的分析产物，包括如源系统中有多少个表，每个表有多少字段，其中多少为空，表间的外键关系是否存在等反映...
阅读全文
摘要：Explain the pros and cons of communicating with databases natively versus ODBC.简述直接连接数据库和使用ODBC连接数据库进行通讯的优缺点。答：通常连接数据库的方式分为两类，一类是直接连接，另一类是通过ODBC连接。直接连接的方式主要是通过COBOL、PL/SQL、Transact-SQL等方式连接数据库。这种方式的优点...
阅读全文
摘要：Describe three change data capture (CDC) practices and the pros and cons of each.简述出三种变化数据捕获技术及其优缺点。答：变化数据捕获（CDC）技术是ETL工作中的重点和难点，通常需要在增量抽取时完成。实现变化数据捕获时最理想的是找到源系统的DBA。如果不能找到，就需要ETL项目组自己进行检测数据的变化。下面是一些常...
阅读全文
摘要：What is the best approach for handling ERP source data?从ERP源系统中抽取数据最好的方法是什么？答：ERP系统的产生是为了解决企业内异构数据的整合。这个问题也是数据仓库系统面临的主要问题。ERP的解决方案是将企业内的各个应用（包括销售、会计、人力资源、库存和产品等）建立在相同的平台和相同的应用框架下，即在应用操作层将企业内的数据进行了一致性处...
阅读全文
摘要：When should data be set to disk for safekeeping during the ETL?简述ETL过程中哪个步骤应该出于安全的考虑将数据写到磁盘上？答：Staging的意思就是将数据写到磁盘上。出于安全及ETL能方便重新开始，在数据准备区（Staging Area）中的每个步骤中都应该将数据写到磁盘上，即生成文本文件或者将建立关系表保存数据，而不应该以数据不落...
阅读全文
摘要：Describe techniques for extracting from heterogeneous data sources.简述异构数据源中的数据抽取技术。答：在数据仓库项目中，需要抽取的数据经常来自不同的数据源，它们的逻辑结构和物理结构都可能不同，即称之为异构数据源。在对异构数据源进行整合抽取时，我们需要做的事情依次是标识出所有的源系统，对源系统进行概况分析，定义数据匹配逻辑，建立筛选...
阅读全文
摘要：What are the permissible data structures for the data staging area? Briefly describe the pros and cons of each.在数据准备区中允许使用的数据结构有哪些？各有什么优缺点？答：1．固定格式的文本文件。（Flat File）Flat File指的是一种保存在系统上的一种文本文件格式，它以类似数据...
阅读全文
摘要：How is the system-of-record determined?如何确定起始来源数据？答：这个问题的关键是理解什么是System-of-Record。System-of-Record和数据仓库领域内的其他很多概念一样，不同的人对它有不同的定义。在Kimball的体系中，System-of-Record是指最初产生数据的地方，即数据的起始来源。在较大的企业内，数据会被冗余的保存在不同的...
阅读全文
摘要：What are the four basic Data Flow steps of an ETL process?在ETL过程中四个基本的过程分别是什么？答：Kimball数据仓库构建方法中，ETL的过程和传统的实现方法有一些不同，主要分为四个阶段，分别是抽取（extract）、清洗（clean）、一致性处理（comform）和交付（delivery），简称为ECCD。1．抽取阶段的主要任务是：...
阅读全文
摘要：What is a logical data mapping and what does it mean to the ETL team?什么是逻辑数据映射？它对ETL项目组的作用是什么？答：逻辑数据映射（Logical Data Map）用来描述源系统的数据定义、目标数据仓库的模型以及将源系统的数据转换到数据仓库中需要做操作和处理方式的说明文档，通常以表格或Excel的格式保存如下的信息：目标表...
阅读全文
摘要：What are the primary goals of the data discovery phase of the data warehouse project?在数据仓库项目中，数据探索阶段的主要目的是什么？答：在逻辑数据映射进行之前，需要首先对所有的源系统进行分析。对源系统的分析通常包括两个阶段，一个是数据探索阶段（Data Discovery Phase），另一个是异常数据检测阶段。...
阅读全文
摘要：本部分的题目来自Kimball的ETL Toolkit著作，原著未直接给出答案。这里的中文题目和答案是我参考其原著按自己的理解整理而来的，仅供参考。对于其中不确切的地方，欢迎大家一起沟通。有兴趣的朋友可以直接阅读原著。分析1．什么是逻辑数据映射？它对ETL项目组的作用是什么？2．在数据仓库项目中，数据探索阶段的主要目的是什么？3．如何确定起始来源数据？架构4．在ETL过程中四个基本的过程分别是什么...
阅读全文
摘要：The 38 Subsystems of ETL By Ralph Kimball, 2004年4月 建立一个成功的数据仓库系统，依靠的是最佳实践而不是直觉。 三个简单的字母，E-T-L，很容易的让大家忽视了38个ETL子系统在数据仓库建设中的重要性。 抽取-转换-加载（ETL）系统，或者非正式的称为“后台系统”，在建立整个数据仓库系统中占据了70的工作量和时间。但是这还不...
阅读全文
摘要：今天快下班的时候，有一大学同学发过来一个excel，里面有54个数字，他问我能不能从这54个数字中找出n个数字，加起来刚好等于70708。刚开始就琢磨着用遍历算法来解决问题，想着想着感觉太晕了，复杂度太高了。灵感突然来袭，这不是在学校里面学过的典型的背包问题么，看来大学里面也不是什么都没有学到哈。知道了问题的出处，事情就好办了，下面直接上代码。如下是结果：6192.22 1623.22 3138....
阅读全文
摘要：Building Custom Tools for the DW/BI System市场上有大量的工具帮我们来建立DW/BI系统、把信息交付给业务用户。这些工具的种类也很多，它们包括关系型数据库管理系统、OLAP数据库管理系统、ETL工具、数据挖掘工具、查询工具、报表工具，以及BI门户工具等等。那么在这么多的工具中，定制工具起什么样的作用呢？我们看到的大部分定制工具都是用来支持后台操作的，如元数据...
阅读全文
摘要：Think Like A Software Development Manager对很多企业来说，广大的用户通过BI应用来使用DW/BI系统。这些BI应用包括标准报表，分析应用，仪表盘和操作型BI等内容。这些应用提供了一个结构化的、参数驱动的、相对简单的方法给用户，用户通过这些方法可以得到他们需要的信息。在“KDT#91 DW/BI系统的营销”之中，我们描述了BI应用作为D...
阅读全文
摘要：Marketing the DW/BI System技术人员一般都远离营销工作。当有人说“你一定是营销团队的”时，就是在说这种情况。这主要是因为我们不理解营销到底是什么，为什么它非常重要。在本技巧中，我们首先回顾一下营销的经典概念，接着展示我们怎么将其应用到DW/BI系统中。如果把营销看作为培训可能会更好一些。营销人员将产品的功能和特色讲解给客户。营销的名声不好，因为它常习...
阅读全文
摘要：Marketing the DW/BI System3.位置对于消费品，位置是显而易见的：产品必须放到储藏架上，客户才会买它。对于我们来说，位置意味着我们的客户能在需要的时候找到他们需要的信息。也就是说，我们需要为BI应用建立导航结构，这样用户才能方便的使用。而且一些有用的功能也需要提供，例如搜索功能、报表元数据的描述和分类功能、个性化设置功能等。这部分内容可以参见“KDT#58 BI...
阅读全文
摘要：通常事实表的粒度直接来自源系统的交易表，但也有时我们会根据需要产生更细粒度的事实数据。这样的情况主要是当需要把事实表中的事实转化为事实维度时发生，例如事实表中的多个事实类型相似但事实的数量可能会增加时。在下面列出的一些情况下，我们可以考虑将为事实表添加新的事实维度，来减小事实表中事实的数量。1．事实表中事实过多时。一般来说，当一个事实表中的事实在三十个左右比较正常，如果到一百个左右就过多了。2．如...
阅读全文
摘要：在很多实施数据仓库的企业里，客户和产品都会有上百万条记录。数据量过大，导致数据的加载和查询都会面临很大的问题。不过处理器和内存技术的大幅度进步很大的解决了这个问题。那么，现在对我们来说，多大的维度表是比较危险的呢？这时该如何处理呢？对于一个大型的银行来说，可能会有3千万个帐户，如果每个帐户有20个字段来进行描述，每个字段为10个字节。这样，帐户维度表就会有6GB的数据。3千万条记录的维度表对于MO...
阅读全文
摘要：通常我们用TYPE2的缓慢变化维策略来处理维度表的历史信息问题。有时，客户会提出下面这样的问题：我们每个月有多少个新增客户？类似这样需要对维度表的数据变化进行分析的需求，使用标准的TYPE2策略处理起来会比较麻烦。这时，我们可以在维度表中添加一个变化原因列（RowChangeReason）。简单的处理方式，我们可以使用两个字节的缩写来标识变化原因。例如，新建列为 ’NW’，...
阅读全文
摘要：在数据仓库的建模中，代理键通常是建立在维度表中的。那么在事实表中如何呢？在建立逻辑模型时，事实表中显然是没必要建立代理键的，但是到了物理模型，在某些特定的情况下是可以考虑建立代理键。代理键一般是无意义的整型值，做为维度表的主键，它的分配过程一般是顺序的。代理键可以很好的隔离源系统的数据变化，对数据仓库中的查询性能也能起到很好的作用。在事实表中，主键一般定义为维度外键的子集，通常几个维度外键即可实现...
阅读全文
摘要：很多人对维度建模有一个误解，认为维度建模是为了管理和战略分析的需要而建立的汇总数据。事实上，这是一种错误的观点。维度建模应该保存最细的原子粒度的数据。这样才能满足用户的不确定的需求。出于性能的考虑，数据库管理员要建立一些汇总事实表（也称聚集事实表，Aggregated Fact Table）。这类表每一条记录保存的是选定的几个维度及在这几个维度上汇总的事实值。这些表可以是物理表，也可以是物化视图（...
阅读全文
摘要：在数据迁移的过程中，可能会遇到由于各种原因而迟到的维度记录。它们有可能是比事实记录晚到的维度记录，也可能是维度属性变化了但是延迟提交给数据仓库的维度记录。对于迟到的维度记录有几种处理策略。第一种方案是，ETL系统可以在事实记录相关的维度记录到了之后再将该事实记录迁移入数据仓库中。这样做的缺点是，事实表的记录可能会不完全。第二种方案是在维度表中建立一条“未知”的维度记录，对于...
阅读全文
摘要：确定数据建模时的命名是一件麻烦的事，因为不同的人对同样的事情有不同的理解。下面通过三个步骤来完成命名的过程。前两步一般是在模型给业务用户看之前。第三步是业务用户看过并理解了模型之后。1．准备阶段首先，建模人员需要掌握公司或者团队内的命名规则，如果没有的话，需要建立一套。建模时，需要先根据实际情况定下数据项的名称，这些名称需要简洁、能描述清除事物并且是唯一的。通常字段的名称包括如下三部分：Prime...
阅读全文
摘要：采用Kimball开发方法构建数据仓库系统，关注于业务处理过程是至关重要的一步。业务处理过程是维度建模的数据仓库的基础单元。对应一个业务处理过程至少可以建立一个事实表，所以标识业务处理过程的时候也就标识了需要建立的事实表。对一个业务处理过程建立多个事实表是很常见的。当业务处理过程中涉及不同种类的产品时经常需要建立多个相似的事实表。通过描述事实表的粒度，我们可以判断是否正确的标识出了业务处理过程。如...
阅读全文
摘要：敏捷开发方法是一套开发方法学，包括极限编程（XP）、SCRUM、自适应软件开发等，特点是迭代开发、降低风险、在短期内提高新的功能。和传统的开发方法相比，敏捷开发方法通常称为“轻量级开发方法”。Kimball开发方法和敏捷开发方法有很多相似之处。1．最主要的目标都关注于满足用户的需求。2．重视与用户的合作，尤其是与业务代表的关系。3．都注重与用户面对面的交流，注重用户的反馈。...
阅读全文
摘要：遵从Kimball的MD架构来建立数据仓库时，设计维度模型的过程通常包括四个步骤，分别是选择业务处理过程、选择粒度、选择维度和选择事实。在这个过程中，选择业务处理过程是Kimball非常强调的一步。业务处理过程（Business Process）指的是组织中的存在的业务活动，在这个业务活动中可以产生或者收集到数据。在维度建模过程中，我们要关注于这些产生数据的业务处理过程，而不应该关注于业务处理部门...
阅读全文
摘要：在我们构建DW/BI系统时，如何来规划架构是非常重要的一步。我们是选择将系统建立在关系数据库中，还是建立在多维数据库中，还是关系数据库和多维数据库中都进行建立。在建立的多维数据库后，是否还有必要将多维模型建立在关系数据中？这些都是在架构数据仓库时首先要考虑的问题。通常的建议是关系数据库和多维数据库都需要。目前，直接建立多维数据库也是可以实现数据仓库的，直接在交易系统中ETL数据到多维数据库中。但是...
阅读全文
摘要：通常在一个组织中，DW项目组和BI项目组是分开的两个项目组。其中DW项目组，即数据仓库项目组，主要负责后台数据仓库的建模、数据的整合等功能的实现；而BI项目组，即商业智能项目组，主要负责前台数据展现、报表、OLAP及数据挖掘等功能的实现。而很多组织过分的划分了这两个项目组，使DW项目组和BI项目组沟通过少，前后台脱节。这其实是一件很危险的事情。对数据仓库和商业智能来说，最关键的都是用户的需求。在数...
阅读全文
摘要：在建立和维护数据仓库系统时，不论你的ETL系统是采用ETL工具开发的还是自己手工开发的，对整个ETL系统的每一步做好详细记录都是至关重要的一份工作。随着时间的推移，建好的数据仓库也在不断发展，ETL系统也需要逐步改变，为了能尽快的适应新的情况的变化，完善的文档对快速理解系统的架构和实现的细节能起到非常大的作用。ETL工具也可以自动做一些文档记录，但是对于维护一个数据仓库的良好运转来说，这是远远不够...
阅读全文
摘要：交叉探查（Drill Across）指查询多个事实表并将结果合并成一个结果集的查询操作。下面是一个查询销售实际值和预测值的例子。通常的BI工具都支持交叉探查操作。SELECT Act.Customer, Act.Year, Act.Month, Actual_Amount, Fcst.Forecast_AmountFROM--子查询"Act"返回实际值 (SELECT Customer_Name ...
阅读全文
摘要：在数据仓库中，事实表和维度表的数据通常都是同时到来的，我们根据维度记录的不同情况会对事实表中的维度外键进行如下的处理：1．如果维度记录是个新的，我们分配一个新的代理键给这个记录。2．如果维度记录是以前的修改版，我们用TYPE 2的缓慢变化维度处理策略来处理，即生成新的代理键，生成新的维度记录。3．如果维度记录是以前就有的，我们就使用以前的维度键。对于迟来的事实记录，我们需要在维度表中进行搜索，确定...
阅读全文
摘要：一个数据仓库或者商业智能系统是否成功，依赖于企业是否可以从中得到有价值的信息。企业为用户提供BI门户，用户通过BI门户来访问企业数据仓库或者商业智能系统中的信息。很多时候，BI门户的主页关注于数据仓库中的历史信息、加载过程的当前状态等内容。这些都是很有意义的信息，但是这些并不是BI用户最渴望得到的信息。BI门户是用户访问数据仓库的入口，它必须能满足用户最重要的需求。对BI门户的页面有两个基本的要求...
阅读全文
摘要：数据概况（Data Profiling）是大部分数据仓库的建立者都会忽略或误解的一部分内容。很多人会认为数据概况是ETL系统建立之后的数据不规则检验。事实上，数据概况是对源数据内容的概况分析，这个分析应该在需求收集之后就开始。概况分析从小的方面来说包括计算数据量的大小、检验数据的基数关系等，从大的方面来说包括任何判断数据是否满足需求的方法。数据概况的分析一般可以通过如下分析来完成。对于字段，主要分...
阅读全文
摘要：如果要处理的维度表很大，有一百个以上的维度属性，按上述方法进行当前信息和历史信息保存的话就会变得很麻烦。在这种情况下，我们可以考虑将维度表的自然键添加到事实表中作为外键。这样，事实表上就会有两种相似但是完全不同的方式和维度表进行关联。第一个是使用代理键与维度表进行关联，可以使用TYPE 2的技术对维度属性的历史信息进行分析，即使用事实表加载时对应的维度属性对事实数据进行分析。第二个是使用自然键与维...
阅读全文
摘要：在维度建模中，我们经常会遇到一些文本型的事实，它们通常是一些标识信息、属性或者描述信息。这些字段看似属于事实表中的事实，但是它们又不是键、度量事实或者退化维度。通常，不太建议将这些文本事实字段建立到事实表中，而应该在维度表中给它们找到适当的位置。当遇到文本型的事实时，我们首先要考虑的应该是这个事实是否属于某个维度表。例如，客户类型标识出每个客户的一个值，应该属于客户维度表。如果事实不属于已存在的任...
阅读全文
摘要：在维度建模时，我们会尽力在维度表中添加描述性的字段。我们在维度表中添加的描述性的属性越多，用户在进行分析和出报表时就会越灵活。在大型的客户维度表中尤其如此。在进行维度建模时，我们不应该将一些业务逻辑留给分析工具去完成。比如一些经过业务逻辑处理才能得到的派生数据，应该在ETL层就完成，这样才能保证数据的一致性，无论使用任何工具都可以。如果这步在分析工具中完成，不同人有可能会建立起不同的业务逻辑，导致...
阅读全文
摘要：在数据仓库系统中，维度属性的变化是不可避免的，通常我们会用缓慢变化维的三类处理策略来解决这个问题。也就是类型一，覆盖原属性。类型二，添加新的维度行。类型三，添加新的维度列。当维度的属性发生变化时，客户除了要求能用当前值对历史事实信息进行分析外，经常会要求能以历史上的属性分类信息对事实进行分析。随着大家对商业智能的了解和期望程度，这种分析需求变得越来越多。二十年前（Kimball的二十年前），大家对...
阅读全文
摘要：4．尽量保持测试环境和生产环境相同，如果要节省硬件环境的开支的话，建议先减小存储的容量，在历史数据的子集上进行测试。接下来可以减少处理器的个数。如果还需要缩减的话，最后减小内存的大小。但是硬件环境的缩减，会对查询性能产生巨大的影响。也就是说，如果在测试环境减少了数据范围、处理器或者内存，运行情况会和正式环境有很大的不同。开发环境也应该尽量和测试环境、生产环境相同。5．对于像部署一个新的数据集市、添...
阅读全文
摘要：8．在数据仓库项目组中应该有专门的人员管理系统中使用的各种工具产品及程序，负责监控其升级和维护。当报表工具或者数据库等产品有新的补丁或者版本提供时，首先需要评估升级或者打补丁对系统的重要程度，确定需要升级后也需要经过培训和测试后才可以发布到生产环境。如果升级太超前的话，可能会为产品的bug等付出代价。升级时的操作步骤一定要书写清楚并按顺序完成。操作步骤文档要保证每一步都尽量详细。可以事先定义好操作...
阅读全文
摘要：有时，事实表中的日期比一天要细，会详细到时分秒，而且用户可能会对时分秒进行查询，如果我们将日期维度的粒度细到秒级，日期维度表中的记录就会变的太多。这时，我们有两种建模方法来处理这个问题。一种方法是，在事实表除了保存日期维度的外键（代理键）以外，还将这个日期当作一个事实保存在事实表中，保存成SQL的DataTime型。这样，如果用户需要更精确的查询的话，可以查询这个DataTime型的字段。另一种方...
阅读全文
摘要：数据仓库系统开发完成后进入维护阶段。从实际情况来看，尽管数据仓库系统的维护要求不像业务系统那样有24×7的维护要求，但是大多数的数据仓库系统维护工作不如业务系统的维护工作完成的好。事实上，维护数据仓库系统的正常运转和维护其他业务系统没有很大的区别，都需要做好遵从实践标准，为故障和灾难做好计划等内容。下面是做好维护工作的一些比较基本的建议。1．首先要做的是需要提供服务的级别与用户进行协商...
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用关系数据保存维度模型的缺点1．对于非常复杂的分析和应用来说，SQL是一种很可怕的语言。2．SQL不能像OLAP那样对各个维度来说是对称的。3．尽管有很多调优的功能，但是性能还是很容易变差。
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用OLAP保存维度模型的优点1．一般来说，如果Cube设计的正确的话，性能要比使用关系数据保存强很多。而且和使用关系数据库比，在调优上可以省很多力气。2．与使用关系数据库相比，分析能力要强大很多。例如，在面对复杂的层级...
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日维度模型保存在关系数据库中还是OLAP中在维度建模的数据仓库之中，是使用关系数据库来保存数据还是使用OLAP Cube来保存数据是一个需要数据仓库架构师作出选择的问题。在本文中列举了两种可选方式的34条优点和缺点，供大家...
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用关系数据保存维度模型的优点1．关系数据库大部分都是由独立的供应商提供的，维度模型数据的加载很容易实现。但是，如果加载时使用命令行脚本或者类似PL/SQL类似的私有代码来完成的话，加载过程不是很轻便。2．所有的主流DB...
阅读全文
摘要：在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。代理关键字的称呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificia...
阅读全文
摘要：在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾...
阅读全文
摘要：在数据仓库领域有一个概念叫Iceberg query，中文一般翻译为“冰山查询”。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。以销售数据为例，你想产生这样的一个顾客－商品对的列表，这些顾客购买商品的数量达到3件或更多。这可以用下面的冰山查询表示：Select P.cust_ID, P.item_ID, SUM(P.qty)From Pur...
阅读全文
摘要：在数据仓库领域有一个概念叫Oper Mart，中文一般翻译为“操作集市”。操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储（ODS）。它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。一个操作集市应该有如下特征：1．操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。2．操作集市中的数据和ODS中的数据同步更新。3．操作集市以多维...
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日使用OLAP保存维度模型的缺点1．OLAP最大的缺点的是它是私有的，每个供应商之间没有共同的标准。2．不要期待从一个供应商的OLAP方案转换到另一个供应商的OLAP方案。如果需要转换的话，基本上要抛弃开发中的一切从头开始...
阅读全文
摘要：在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常...
阅读全文
摘要：在维度建模的数据仓库中，有一种操作叫Drill Across ，中文一般翻译为“交叉探查”。鉴于经验的局限，在这里我只能进行一下浅显的分析。在基于总线架构（Bus Architecture）的维度建模中，大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度&rdq...
阅读全文
摘要：在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。第一类非事实型事实表是用来跟踪事件的事实表。例如...
阅读全文
摘要：在数据仓库领域有一个概念叫merged fact table，或者consolidated fact table，中文一般都翻译为“合并事实表”。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法，合并的事实要保证在相同的粒度。这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术，可以避免性能...
阅读全文
摘要：维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。处...
阅读全文
摘要：维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为“一致性维度”。一致性维度是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是...
阅读全文
摘要：在数据仓库领域有一个概念叫pre-joined aggregagte table，中文一般翻译为“预连接聚集表”。预连接聚集表是通过对事实表和维度表的联合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实值。通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。典型的预连接聚集表如下例所示的销售事实表，产品名...
阅读全文
摘要：维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE...
阅读全文
摘要：在数据仓库领域有一个概念叫Centipede fact table，中文一般翻译为“蜈蚣事实表”。蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层...
阅读全文
摘要：在数据仓库领域有一个概念叫pivoted fact table，中文一般翻译为“旋转事实表”。旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在S...
阅读全文
摘要：从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实...
阅读全文
摘要：数据仓库中有一个概念叫做Data Lineage，中文一般翻译为“数据世系”。数据世系描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。数据世系信息需要留下详细的文档记载。数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。数据世系是数据仓库的元数据中最重要的一部分。这部分元数据的产生位置是在ETL的处理过程中。如果在E...
阅读全文
摘要：在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。退化维度经常会和其他一些维度一起组合...
阅读全文
摘要：在数据仓库领域有一个概念叫Role-playing dimensions，中文一般翻译为“角色模仿维度”。角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段...
阅读全文
摘要：在数据仓库领域有一个概念叫sliced fact table，中文一般翻译为“切片事实表”。切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的...
阅读全文
摘要：在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表（Transaction Grain Fact Table），周期快照粒度事实表（Periodic Snapshot Grain Fa...
阅读全文
摘要：这个题目一定会给人带来概念上的混淆。市面上大部分关于数据仓库的书中讲述的都是数据集市是部门级的，而数据仓库是企业级的。这里有一个概念需要单独说明一下，这个概念就是数据集市（Data Mart）。关于数据集市的概念还没有统一的定论。前面提到的面向部门级的数据集市是Inmon的CIF架构中的概念。而Kimball的MD架构中数据集市和CIF架构中的数据集市的概念是不一样。这个区别不是一两句话能说清的，...
阅读全文
摘要：在数据仓库的建模中，有一种维度是超大维度，它有可能有100个以上的属性，有百万条以上的记录。例如，有些行业的客户维度。如果源系统能每天提供该表变化的信息当然是一件非常舒服的事情，但是，这通常是不可能的。源系统一般会每天提供一个文件，文件里是客户表的全部信息。这就需要我们做变化数据分析，通过扫描整个文件和上一天文件的差异来进行变化数据捕获。对于一个超大的维度来说，这个比较过程是很麻烦的一件事情。有一...
阅读全文
摘要：日期维度是用来描述事实表中与日期有关的属性的。它的粒度应该是每天一条记录。一个典型的日期维度表如下所示：Date_Key（代理键，整型）Date_Type（正常，不知道，未发生等）SQL_Date_Stamp（Date_Type为正常时，否则该值为NULL）Day_Number_in_Month（1…31）Day_Number_in_Year（1…366）Week_Nu...
阅读全文
摘要：对于点击流数据仓库的事实表，通常有三种不同的粒度选择。1． 事实表记录＝每个会话的每个页面一条记录这是一个非常细的级别，基本上满足所有的分析要求，但处理数据可能会花掉大部分的时间和金钱。一个好的建议就是用统计学里的抽样技术，选取1％的数据来进行处理和分析。2． 事实表记录＝每个会话一条记录这个粒度在KDT＃1中已经描述。3． 事实表记录＝每天一条记录这个粒度是一个很粗的粒度。优点很明显，就像聚集事...
阅读全文
摘要：在数据仓库的设计中，我们会看到有些事实表中有很多时间字段。这些时间字段和维度表应该怎样关联是我们要考虑的事情。通常我们有三种粒度的事实表，分别是事务粒度事实表（Transaction Grain），周期快照粒度事实表（Periodic Snapshot Grain）和累计快照粒度事实表（Accumulating Snapshot Grain）。这种多个时间字段的事实表多为累计快照事实表。例如一个事...
阅读全文
摘要：点击流数据指的是用户在WEB服务器提供的网页中点击事件形成的日志。用户的每一次点击都会生成日志。而对这些用户在网站上点击页面情况及停留时间情况的分析是电子商务等非常关心的内容。对这部分内容建立数据仓库，一般称为点击流数据仓库（Clickstream Data Warehouse）。点击流数据量是巨大的，对于中等规模的商业网站来说，每天一会产生1亿左右的页面点击事件。所以在建立数据仓库时需要在保证分...
阅读全文
摘要：在维度建模的数据仓库中，有一种维度叫Junk Dimension，中文一般翻译为“杂项维度”。杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的指示符或者标志字段。例如：支付类型字段，包括现金和信用卡两种类型，在源系统中它们可能是维护在类型表中，也可能直接保存在交易表中。一张事...
阅读全文
摘要：Kimball Group每个月会通过email发布一个设计技巧。下面是其中部分设计技巧的整理，因为是根据自己的理解翻译的，肯定会有很多不足之处。其中内容翻译不清的地方可以和我联系，大家共同探讨，或者直接参照原文。Kimball的网站上有2006年及以前的全部原文下载，2007年的也可以通过email订阅。具体方式请参阅Kimball的网站。KDT#51 时间维度表KDT#52 改进数据仓库系统的...
阅读全文
摘要：维度建模的数据仓库中，有一个概念叫Bus Architecture，中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。在多维体系结构（MD）的数据仓库架构中，主导思想是分步建立数据仓库，由数据集市组合成企业的数据仓库。但是...
阅读全文
摘要：维度建模的数据仓库中，有一个概念叫Conformed Fact，中文一般翻译为“一致性事实”。一致性事实是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性维度（Conformed Dimension）。在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建...
阅读全文
摘要：在本Tip中，Kimball描述了数据仓库项目和出版社之间的一个比喻，下面是在数据仓库项目中应该能够做到的一些要点。（出版社的比喻略）了解用户的业务范围、工作职责和计算机能力。描述出用户需要要数据仓库完成的功能。找出能通过使用数据仓库系统完成有效决策的用户。找到潜在的用户，并使他们意识的数据仓库的作用。在数据仓库中首先实现最有效率，最用效果的主题。要尽可能的使用户的界面和应用程序简单好用，最好使用...
阅读全文
摘要：对于事务粒度事实表来说，只有当该天有事务发生时，才会在事实表中出现当天的记录。一个简化的事务粒度事实表如下所示。Date_Key(FK)Account_Key(FK)Transaction_Type_Key(FK)Transcation_Sequence_NumberFinal_FlagAmountBalance表中，Date_key是日期维度表的代理键。Account_key是帐户维度表的代理键...
阅读全文
摘要：在数据仓库的项目中对历史信息进行分析时，我们通常使用缓慢变化维的三种处理策略来完成。但是，有时客户的需求是既能用历史维度属性对事实进行分析，又能使用维度当前的属性信息来对整个历史的事实进行分析。这样，标准的三种处理策略都不能很好的满足分析的要求，我们需要组合使用三种处理方式。首先，对于维度属性的变化，我们需要使用TYPE 2来建立一条新的记录捕捉变化信息，这需要生成新的代理键。同时，我们需要使用T...
阅读全文
摘要：热交换维度指在数据仓库中，一个维度有两个或更多个可供选择的版本。也就是说，对于不同的用户，我们不想让他们看到该维度的全部信息，所以我们可以定制该维度的不同版本，而在用户查询时根据当时的需要给用户选择一个适合他的版本。下面是是一个使用热交换维度的例子：一个制造业的企业想把自己的发货事实表提供给他的交易伙伴访问，但是需要对交易伙伴屏蔽掉其他交易伙伴的订单信息。处理的方式是，为每一个伙伴建立一个&ldq...
阅读全文
摘要：对于有丰富的描述属性的维度表，我们经常会对其统计个数，例如客户表，我们会按各种口径（支付类型、所在地区、性别等）统计其个数。如果是静态的维度表，统计个数是件非常简单的事情，如果是有缓慢变化维的维度表，统计个数时就需要多加小心。在有缓慢变化维的维度表中统计个数，不加小心的话容易统计重复。因为，以客户维度表为例，我们会对同一个客户的不同历史信息保存多条记录。对于统计当前各口径的客户数来说，如果我们很好...
阅读全文
摘要：事实表从粒度的角度分为三种，分别是交易粒度事实表、周期快照事实表和累计快照事实表。交易粒度事实表能提供某个确切时刻的描述信息。以银行帐户中保存的客户信息为例来说，代理机构会周期的更新客户的名称、地址、电话号码、客户分类、信用等级、风险等级及其他描述性信息。建立的交易粒度事实表如下所示：变更日期（FK）帐户号（SK）代理（FK）客户信息变更类型（FK）帐户号（NK）名称（文本事实）地址（文本事实）电...
阅读全文
摘要：在数据仓库的项目中，常会遇到用户不满意开发的结果，他们会抱怨数据太混乱，查询太慢等问题。这时，我们应该从以下几个方面来检查我们的开发过程。1．项目组是否收集好了用户的需求并把按用户的需求实现数据仓库放在第一位。这个问题是数据仓库项目中最常见的问题。如果项目组把数据或者技术放在第一位，项目很可能会偏离正常的轨道。2．项目组是否采用了数据仓库总线矩阵。总线矩阵是数据仓库项目组最有用的工具。采用总线矩阵...
阅读全文
摘要：通常应对缓慢变化维的解决策略有三种类型，分别是类型一直接更新、类型二增加行、类型三增加列。使用类型二时，当维度表的数据发生变化时，我们会增加一条新记录到维度表中，并用代理键作为主键。本日志要讲的就是使用类型二的缓慢变化维策略可以对历史数据提供逻辑上的分区。使用类型二的策略需要代理键的支持，以产品维度为例，当产品描述变化时，需要增加一条新的记录，用自增的代理键和变化前的记录相区别。而产品编码不会改变...
阅读全文
摘要：在对已有数据仓库添加新的主题时，需加载的维度表也会存在历史记录的情况，这时，和普通的缓慢变化维的加载方式就会存在着不同。通常缓慢变化维的加载时是增量加载，查找表中只保留最新的代理键和自然键的对应关系。而像新增主题这样的批量加载，查找表中会保留维度变化的历史信息。当批量加载维度表的历史信息时，在查找表中查询代理键的SQL示例如下：Select customer_key from customer_l...
阅读全文
摘要：在KDT#5中已经说明，日期维度的关键字应该是一个整型的代理键，而不应该是日期型。更进一步来说，在建立日期维度时关键字应该按日期的顺序来分配顺序的整数，即代理键应该按日期的顺序分配为是1,2,3...N。按日期顺序分配的代理键有着非常大的用途。它使事实表可以基于日期进行物理的分区。按日期对大的事实表进行物理分区是一种很常见的情况，它可以很方便的分离历史数据，而且可以使最新的数据在不影响事实表中其他...
阅读全文
摘要：在我们进行维度建模时，有时两个维度之间会出现关联。例如：产品维度和市场维度。这时，我们通常的处理方式有两个，一个是建立两个独立的维度表，每个维度表外键关联到事实表，另一个是合并成一个超级维度表（Super Dimension）。接下来，我们考虑什么时候该建立独立的维度表，什么时候该建立超级维度表。以产品和市场来说，如果它们是一对一或者多对一的关系的话，建立超级维度是一个合理的选择。建立好的超级维度...
阅读全文
摘要：目前来说，OLTP和数据仓库中数据的时间差距已经缩短到了1天，即24小时。但是常会出现更急迫的需求，需要能在数据仓库中提供近似于实时的数据。这时，我们可以通过在数据仓库前面建立一个实时分区来解决这个问题。通常，实时分区和数据仓库分开建立和管理，并在其中使用不同的更新规则和查询规则。实时分区的需求如下：1．包括上一次更新数据仓库之后所有的业务活动数据。2．和数据仓库在内容和粒度上要能无缝的连接上。3...
阅读全文
摘要：在数据仓库系统中，通常我们会每天迁移新的数据进入数据仓库。一般来说，我们会在凌晨时用户不会使用的某段时间进行数据的迁移，在数据迁移的这段时间，数据仓库处于离线状态。但是对于较大的数据仓库系统，用户可能分布在全国或者全球，用户的时区不一样，工作时间也不同，在我们凌晨时其他地区的用户可能还在工作。这就要求我们要尽量的减小数据仓库的离线时间。有一种方法可以解决这个问题，就是使用分区（partition）...
阅读全文
摘要：当数据仓库开始支持企业的各种分析应用，提供近实时的数据时，它已经变成了企业应用中不可缺少的一部分。这时，如何避免数据仓库发生灾难性的故障是至关重要的。通常，灾难性的故障可能由如下原因导致：1．物理硬件的损坏。恐怖袭击或者火灾等其他原因导致建筑和机器全部损坏，会导致数据仓库完全损坏。2．内部人员蓄意破坏。如果内部人员被收买或者有对头企业的人员打入公司内部，会导致数据仓库逻辑或者物理损坏。3．黑客攻击...
阅读全文
摘要：当你在设计跨国数据仓库时，一定会遇到下面几个问题。比如，如何处理多国语言；数据仓库中的哪一部分需要翻译成多国语言；如何处理逐渐增加的语言版本。本日志要面对的就是如何来处理多国语言的问题。对于跨国的分布式的数据仓库来说，用户一般会通过一致性维度交叉探察不同地区的数据仓库。而处理多国语言的问题的关键在于这些一致性维度表，因为这些维度表中保存的属性有用户报表的标签，数据的层级关系和数据的描述。解决多国语...
阅读全文
摘要：首先对“主子表”这个词进行一下解释，举例来说，对于一个销售单来说，通常业务建模会有两个表，一个是销售主表，记录销售的总体信息；另一个是销售子表，记录销售的每个产品的信息。类似销售主子表这样的应用，在没有想到更恰当的词之前，我暂将其称之为“主子表”。以区别于为不知层深而建立的可以多层的单张“父子表”。在维度建模中，可以将这种&l...
阅读全文
摘要：通常，维度表中保存的是企业各种度量的描述信息。我们也可以考虑在添加事实记录时将一些元数据建立成维度表供用户访问，这样的维度表就是审计维度表。审计维度表可以提供如下所示的数据，1．事实数据的来源是哪里。2．是用那个版本的ETL软件进行抽取的。3．生成事实数据的逻辑是怎样的。4．区分某个事实是“不知道”、“不可能”、“已损坏”还是...
阅读全文
摘要：维度建模中一个非常重要的步骤是定义事实表的粒度。定义了事实表的粒度，则事实表能表达数据的详细程度就确定了。定义粒度的例子如下：1．客户的零售单据上的每个条目。2．保险单上的每个交易。定义好事实表的粒度有很大的用处。第一个用处就是用来确定维度是否与该事实表相关。例如，对于粒度细到医疗单据上条目项的事实表来说，医疗结果是不会作为维度和它进行关联的，因为它们不在同一个粒度上。但是，对于一般的E/R数据模...
阅读全文
摘要：在维度建模的数据仓库中，客户维度通常是最有挑战性的维度。一般来说，客户维度有如下三个特点，记录很多，有可能有百万数量级；属性很多，有可能几十或者上百；缓慢变化，有时变化也很快。对于建立基于Web环境的数据仓库来说，客户维度表中通常有两类客户，一类是没有注册过的访问者，另一类是注册过的客户。未注册的客户是匿名的，有可能和企业有多次业务交易，但是企业并不知道客户的详细信息。尤其是在Web环境中，我们通...
阅读全文
摘要：建立分布式数据仓库的关键是使用一致性维度。实现一致性维度最简单的办法就是使用完全相同的维度表。一致性维度比较复杂的情况是允许使用维度表的子集。以产品为例，有些部门的分析需求可能只是商标粒度，而不是细到产品粒度。这时需要通过产品维度表来实现商标维度表，而商标维度表要保证是产品维度表完全的子集。这样，商标维度表和产品维度表就是一致性的维度表。使用一致性维度最大的好处就是可以在分布的数据集市中进行交叉探...
阅读全文
摘要：事实表一般围绕着度量来建立，当度量产生的时候，事实记录就生成了。度量可以是销售数量、交易流水值、月末节余等数值。如果同时生成多个度量值的话，我们可以在一个事实表中建立多个事实。当我们的事实表中的事实比较多时，有可能多个事实不同时发生，如果同时生成的几率很小，我们称之为稀疏事实表（Sparse Facts）。对于稀疏事实表，通常会在事实中存在大量的NULL值。通常的处理方式是建立“事实维...
阅读全文
摘要：层级结构（Hierarchical Structures）是企业中数据库建模中很常见的一种结构，也就是我们常说的“父子表”。通常我们的建模方式是建立成递归的结构。如下例所示：Create table COMPANY{COMPANY_KEY INTEGER NOT NULL,COMPANY_NAME VARCHAR2(50),PARENT_KEY INTEGER};这种结构对...
阅读全文
摘要：在数据仓库领域，集中式（Centralized）是个讨论的很多的概念。物理的集中可以减小管理成本，提高性能。但是我们更应该关注的是数据在逻辑上的集中，即数据的整合及一致性处理。而物理上是集中式的还是分布式的都是可以接受的，需要根据具体情况来定。如果只是物理上进行了集中，而没有进行数据的整合，就好比买了一个大箱子，把所有的杂物放入其中，仍是乱糟糟的一堆垃圾。这时就会出现下面这些情况：1．从相同的数据...
阅读全文
摘要：在数据仓库领域，建立分析应用已经越来越热门。一般来说，分析应用是针对企业绩效分析的一套程序或者处理，它可以指导企业的决策，并且分析的结果是可以复现的。举例来说，一般的分析应用诸如销售绩效评估、客户盈利分析、产品销售途径分析。分析应用需要结合企业的需求、分析应用能让我们更了解企业的绩效情况，并对提高企业的绩效提供支持。从根本上来说，分析应用和基于数据仓库上的决策支持系统没有什么不同。建立分析应用（A...
阅读全文
摘要：EDW是Enterprise Data Warehouse的简写。这里EDW指Inmon的CIF构建方法，EDW架构指的也是CIF架构。本文比较了EDW架构和总线架构的差别，并指出了EDW架构的缺点，当然这是Kimball的观点。1．从逻辑模型上来说，两种构建数据仓库的方法都以为企业建立一致性的数据为基础。总线架构采用一致性维度和一致性事实来进行一致性处理。EDW架构采用高度规范化的E/R模型来保...
阅读全文
摘要：在过去的一些年里，我们看到很多对时间跨度的需求。一般来说，我的事实表中每条记录保存的数据都是在一段时间内不会发生变化的。也就是说，需要的时间跨度可以在任意的时间点开始和结束。有时，我们保存的记录中时间跨度可以很好的连续在一起，但是有时也可能会出现中断的情况，更差的情况下，数据跨度可能会出现重复的情况。这些时间跨度在数据库中都以单条记录的形式进行保存。为了能更形象的表示这些变化，我们来考虑一个例子。...
阅读全文
摘要：6．不同种类产品的建模对于像银行、保险等提供金融服务的企业来说，不同的帐户会有不同的度量信息。而不同的客户会查看不同的帐户度量信息。在这样一个大型的零售银行，针对不同的帐户类型会有总数200多种特殊的度量，分散在不同的帐户类型上。这时，直接由所有的属性生成巨大的事实表和维度表是不可取的。而应该先建立一个核心的事实表来保存四到五个对所有帐户都通用的度量字段，如结余等。然后根据不同的帐户类型建立扩展的...
阅读全文
摘要：在进行客户关系管理（CRM）分析时，通常有三个客户行为分析值，分别是最近访问时间、访问频率和交易数量。最近访问时间指我们和客户最后一次接触的一些信息，包括最后访问时间或者最后一次接触到目前的时间间隔等。访问频率指我们和客户的接触频率。交易数量是我们和客户交互量的度量，例如购买量或者访问站点网页的总量等。在实际构建系统，每一个都需要进行细化。通常这种针对最近访问时间（recency）、访问频率（fr...
阅读全文
摘要：3．多币别的数据建模多币别的问题与多时区的问题很相似，处理方法也类似。同样的，我们对币别问题有两个相同的观点。比如说，如果交易发生在一个特定的币别下，我们理所当然的想知道确切的币别信息。但是当我们想进行汇总统计时，多国的币别会给我们带来很大的麻烦。这时，我们的处理方法很处理多时区类似，就是保存两个币别的数据，一个时本地发生交易的类别，另一个是选择的标准币别。我们同时，我们也需要建立一个币别维度表来...
阅读全文
摘要：2．周期快照粒度实时分区对于周期快照粒度的事实表来说，实时分区相当于该周期内的累计值。即本周期虽然还未结束，但是本周期已内发生的交易的数据已经累计好了。当本周期内发生新的交易时，这个值继续累计，直到本周期结束，写入数据仓库的周期快照事实表中。实时分区中的周期快照事实表也可以全部加载在内存中。应用程序对实时分区中周期快照的查询和交易粒度的查询不太相同，在统计总数值时，需要将实时分区和数据仓库中的相关...
阅读全文
摘要：数据仓库设计师的目的是有效的发布企业的数据。这就意味着数据仓库中的数据应该是对最终用户和应用程序来说是非常容易使用的。在数据仓库设计时，我们会采取一些折中处理，如增加数据后台的处理过程、增加数据存储空间，来得到下列好处。1．得到用户容易理解的数据存储结构，这种结构是对称的、可预测的。2．减小了应用程序的复杂度。3．提高查询和报表的性能。好的数据仓库设计师会通过类似的折中处理，使最终用户的使用变得简...
阅读全文
摘要：尽管在做数据仓库设计时，我们会考虑的很周全，但是对于建立一个数据仓库来说，一定会遇到增加新的数据类型、增加数据关联关系甚至需要增加新的数据源等问题。在这些情况发生时，理想的设计是可以在不影响数据仓库上的应用程序的基础上完成上述功能。当然，在实际工作中，肯定会有些变动我们无法在不影响应用程序的情况下改进设计。这里要说的是维度模型在支持设计的修改方面是很强的，下面列出了一些可以支持修改的情况。1．增加...
阅读全文
摘要：早期的数据仓库构建思想是将所有能得到的数据都放入数据仓库，随着信息的爆炸，数据仓库的尺寸开始变得不可接受。有两种方法可以解决这个问题，一个是数据过滤减少进入数据仓库的数据，另一个就是通过合理的设计减小数据仓库存储空间。本文简单讨论一下第二种方法。在维度建模的设计中，维度表占用的空间相比事实表要小很多，如何减小事实表的容量是采用第二种方法的关键。通常有如下方法可以减小事实表的容量。1． 将所有的自然...
阅读全文
摘要：在我们设计维度模型时，经常会遇到一些标志字段或者状态字段。这些字段虽然和关键的维度表的关系不大，但是对于分析来说还是很重要的，不能直接删除。对于这些字段的设计通常有三种方法，第一种方法是把它们设计成文本事实，第二种方法是把它们设计成独立的小维度表，第三种方法是把它们合并成杂项维度。杂项维度的设计方法是将多个标志字段或者状态字段组合成一个维度，这些字段之间最好是没有关联关系。这样的维度不是必须的，但...
阅读全文
摘要：关系数据库中都支持空值（NULL）来表示数据不存在。但是在数据仓库中，一般不建议继续保留这些空值。下面介绍维度建模中的三种处理空值的策略。1．事实表的外键为空值。这种情况出现的原因主要有两个，一个是在数据抽取时外键值还不知道，另一个是在源系统中外键值丢失。这时，引用完整性遭到了破坏。第一种情况通常出现在累计快照事实表中，因为有些事件还没有发生，所以对应的时间不存在。这时，保留空值作为外键是不可取的...
阅读全文
摘要：在进行数据仓库建模时，有一些功能可以在数据访问工具中实现。例如，文本描述内容替换、计算项的生成等功能。但是这样做并不是一个好主意，我们更应该关注的是使用数据仓库的架构和模型来实现这些功能。这些灵活的、丰富的、描述性的信息，我们应该把它建立在维度模型中。如果利用数据访问（展现）工具来实现这些功能，业务规则也就嵌入在这些数据访问工具的元数据中。这样，建立的数据仓库系统就会过于依赖于数据访问工具。不同的...
阅读全文
摘要：我们已经熟悉在数据仓库的架构中采用总线矩阵来实现。总线矩阵标识了企业的核心业务处理过程和维度之间的关联关系。在矩阵中，业务处理过程以行的形式出现，维度以列的形式出现，交叉点标识出维度和业务处理过程是否关联。总线矩阵提供了数据仓库的一个高层的视角。在这个基础上，我们可以进一步细化矩阵中的业务处理过程。每一个业务处理过程可能对应一个或者多个事实表。我们可以改变矩阵中的粒度或详细的程度，使矩阵的每一行代...
阅读全文
摘要：一般来说，累计快照事实表和周期快照事实表是两类有很大区别的事实表，当我们在一个数据源上建立一张事实表时，我们必须在其中作出选择。周期快照事实表记录的是重复的可预测到的时间间隔的事实，例如帐户月结余事实表，用来记录每个月末的帐户结余信息。一般周期快照的数据会按报表需要的周期进行记录，比较适合周期长一些的情况。而累计快照适用于较短周期，有着明确的开始和结束状态的过程，如一个订单执行的过程，并记录过程中...
阅读全文
摘要：累计快照事实表的这种最简单的实现方法中没有给出保留中间点的历史信息的方法，如订单本身的变化。至少有三种方法可以用来捕获这种中间的状态的变化：1．在诸如月末等的固定时间间隔对累计快照再进行快照处理，即联合使用周期快照和累计快照技术。这种累计快照的周期快照事实表应该被建立为单独的事实表，可以降低应用的复杂性。在这样建立的快照表中，好处是在订单存活期间，每个月可以得到这个订单变化的一条记录，坏处是只能在...
阅读全文
摘要：下面列出的事情有助于我们建立分析应用：1．理解分析应用的定义，包括企业的战略决策方向和财政方向的驱动力等。2．以辅助决策支持做为建立分析应用的目标，功能上需要超过简单的报表系统，能给决策者提供直接的帮助。3．把握住用户的需求，还包括企业的角色、职责和期望等内容。4．确定必要的用来支持决策的维度模型需求（包括事实表、需要计算的度量、维度表、维度属性、粒度和聚集策略等内容）。5．详细的了解分析应用产品...
阅读全文
摘要：维度模型以其高性能和易使用两大特点为分析应用提供了有效的支持。在采用维度模型进行数据仓库架构时，还有两个要点要多为注意，其中一个是总线架构，另一个就是合并数据集市（Consolidated Data Marts）。在MD架构中，通常数据集市的建立是面向业务处理过程的，不同业务处理过程的事实数据很可能会分散在不同的数据集市中。这对于需要跨多个业务处理过程进行分析的应用来说，需要进行交叉探查操作。而交...
阅读全文
摘要：分析应用通常是建立在数据仓库之上，用来支持企业决策的应用。一个好的分析应用通常建立在一个好的分析框架上，用来给用户提供分析的操作，其提供的功能应该远不止标准的报表。这个分析环境应该能给用户提供辅助决策的分析功能，使用户对企业的状况的发展及处境有更清晰的了解，最终能帮他们作出更有洞察力，更全面的决策。分析应用的目的是：· 辅助决策的作用。· 标识并解释企业绩效的异常状况。...
阅读全文
摘要：对于一些相对复杂的关于时间跨度的问题如下。· 查询在一个时间跨度中的某个时间点的所有客户。· 查询在一个时间跨度中某个给定客户的最后一个事务处理记录。· 查询在任意个一个指定的时间点的帐户余额信息。在下面的讨论中，我们还假定时间跨度是以天为单位。上面提到的三个问题我们可以通过在事务表中增加时间戳来回答，但是这样的话查询会非常复杂而且效率很低。例如，为了回答...
阅读全文
摘要：我们用非事实型事实表来记录维度之间的多对多关系，但是关系上没有数字或者文本的事实。非事实型事实表一般用来记录事件或者范围信息。常见的例子如：标识产品的促销范围；记录学生出席或者注册事件等。在本TIP中我们用非事实型事实表来补充缓慢变化维的处理策略。对于一个大型的B2C企业来说，会有上千万的客户。对于这种大型的客户表，需要跟踪客户的变化情况，我们可以采用TYPE 2的缓慢变化维策略来进行应对。例如，...
阅读全文
摘要：有两种方法来建立杂项维度。第一种方法是事先生成杂项维度的所有记录，即对几个属性的每一种组合都生成一条记录。第二种方法是在ETL过程中遇到新的属性组合时生成记录。如果杂项维度表中的记录数相对来说较少的话，我们可以采用第一种事先生成记录的方法。如果记录数相对来说较多的话，我们可以采用第二种在数据迁移时创建使用到的杂项维度记录的方法。最近（Kimball）遇到的一个医疗的方面的杂项维度表，理论上应该有超...
阅读全文
摘要：数据仓库领域广泛流传着自底向上（bottom-up）和自顶向下（top-down）来架构数据仓库的争论。通常，我们称Inmon的先建立集中的EDW，然后在EDW上建立应用的架构方式为自顶向下的架构方式；称Kimball的先根据需求建立数据集市，然后由所有的数据集市组合称数据仓库的架构方式为自底向上的架构方式。事实上，自底向上并不能准确的表达Kimball的架构思想。自底向上容易让人误解为建立数据集...
阅读全文
摘要：在维度建模的数据仓库，我们经常可以看到退化维度（Degenerate Dimension）。退化维度是事实表中的维度，由于与退化维度相关的属性在其他的分析维度表中都被建立了，所以我们不必建立物理的退化维度表，这也是称为退化维度的原因。当我们的事实表中的粒度是单个交易时，通常都会产生退化维度，如订单中的订单号，发票中的发票号等。退化维度对事实表数据的分组有着非常重要的作用。例如：销售单编号可以将同一...
阅读全文
摘要：企业的战略目标指企业的战略方向，即企业的关注点。企业的业务处理过程是企业内部的业务流程，也是数据仓库的数据基础。战略目标是企业范围内的计划，通常由企业执行层决定，一般是明确的，如12个月到18个月实现财务上收入多少等。理解企业的战略目标对建立基于数据仓库的分析应用是非常重要的一点，它给分析应用指出了方向。而企业内的业务处理过程是企业内部的流程，相对企业的战略目标是低一层的，如订单、装运、发票、付款...
阅读全文
摘要：Kimball Group每个月会通过email发布一个设计技巧。下面是其中部分设计技巧的整理，因为是根据自己的理解翻译的，肯定会有很多不足之处。对其中内容翻译不清的地方可以和我联系，大家共同探讨，或者直接参照原文。Kimball的网站上有2006年及以前的全部原文下载，2007年的也可以通过email订阅。具体方式请参阅Kimball的网站。KDT#1 建立点击流数据仓库的一些指导KDT#1补充...
阅读全文
摘要：下面列出的数据仓库中常见的概念的简单解释，按中文字母排序。冰山查询――iceberg query操作集市――oper mart操作数据存储――operational data store代理关键字－－surrogate key多值维度――multivalue dimension非事实型事实表――factless fact table合并事实表－－consolidated/ merged fact ...
阅读全文
摘要：Dimensional Relational vs. OLAP: The Final Deployment Conundrumby Ralph Kimball,2007年4月27日在维度建模的数据仓库之中，是使用关系数据库来保存数据还是使用OLAP Cube来保存数据是一个需要数据仓库架构师作出选择的问题。本文是Kimall先生对此问题的阐释，文中列举了两种可选方式的34条优点和缺点，供大家参考。...
阅读全文
摘要：一个和操作数据存储（ODS）常混淆的概念就是数据准备区（Data Staging Area）。很多人把供数据迁移的数据准备区称为ODS。事实上，ODS和Staging Area有着较为明显的不同。ODS和数据准备区最大的区别就是，ODS是支持用户访问的，而数据准备区是不支持用户访问的。数据准备区包括一组数据迁移的程序和为了清洗数据而建立一组表结构及表中的数据。数据准备区是介于源系统和数据仓库之间的...
阅读全文
摘要：Inmon在给ODS下了定义之后，进一步把ODS分成了四类。根据数据到达ODS的时间间隔，即数据从操作型系统生成开始到数据到达ODS为止的时间长短，ODS分为Class I、Class II、Class III和Class IV四类。Class I的ODS指时间间隔为秒级，即对用户来说，ODS是个透明的部件，操作型系统业务发生后，数据立刻就可以在ODS中看到。这类ODS事实上是很难实现的。秒级的数...
阅读全文
摘要：在数据仓库架构中有一种部件叫Operational Data Store（ODS），中文一般翻译为“操作数据存储”。操作数据存储在通常的数据仓库架构中都是一个可选的部件，它和数据仓库起到互相补充的作用。最早给ODS下定义的应该是数据仓库之父Inmon。他的定义是，操作数据存储（ODS）是面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企业综合的、集成...
阅读全文
摘要：到了2006年，Inmon提出了他的下一代数据仓库架构－－DW2.0，并在该架构中提出了虚拟操作数据存储（Virtual Operational Data Store，VODS）的概念。在DW2.0中，VODS是在EDW之外的一个部件，它和EDW中的交互区（Interactive Sector）是互补的关系。VODS是为某些特定的查询而准备的一种架构方式，它面对的查询需求是一次性的（One Tim...
阅读全文
摘要：Class I的ODS是实时数据仓库的一种实现方式。Class II和Class III的ODS是比较通常的ODS实现方式。Class IV的ODS非常有用的一类ODS实现方式。在Class IV的ODS中，最为常见的记录就是从数据仓库中总结出来的概况数据（Profile Record）。概况数据是数据情况的大纲。以客户为例，可以总结的概况数据如下：每月买衣服的件数，每周的销售量，每年会看两次眼科...
阅读全文
摘要：操作数据存储是一个有较大争议的数据仓库部门，本日志是去年对操作数据存储的情况的一些整理。从目前的情况来看，操作数据存储的发展方向就是实时数据仓库。1．Inmon对操作数据存储的定义2．四类操作数据存储简介3．第四类操作数据存储的例子4．DW2.0中的虚拟操作数据存储5．Kimball对操作数据存储的定义6．操作数据存储和数据准备区的区别7．个人对操作数据存储的观点本日志整理于Inmon和Kimba...
阅读全文
摘要：下面谈谈个人对操作数据存储（ODS）的一些观点。首先要谈的是ODS的位置和作用。ODS应该位于源系统和数据仓库之间的一个独立部件，它的作用是给用户提供一些在源系统和数据仓库系统都不适合完成的功能。置于ODS应该对用户提供什么样的功能，我觉得没必要过于死板，可以根据自己的需要来定。ODS应该是面向主题的。这一点我觉得是有必要的，ODS名称中虽然有操作两个字，但是它的目的主要还是查询和分析。所以面向主...
阅读全文
摘要：Kimball对操作数据存储的定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支持事务系统。Kimball也认可Inmon对ODS的分类，但是他认为ODS应该以星型结构来进行建模。虽然Kimball对操作数据存储（ODS）的定义和Inmon基本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。Kimball认为ODS在两种情况下是需要的：第一种情况是提供操...
阅读全文
摘要：最近在读《精通web Analytics》，做了一点笔记以便记忆。电子邮件营销的目的：1） 获取客户（寻找新的客户）；2） 增加的最终销售（挖掘已有的客户，进行重复销售）；3） 保持力（通过特殊的程序、电子邮件的增值信息和特价来留住客户）；4） 标准的通信（比如订单信息）。电子邮件营销过程的重要步骤1） 定义销售目标，以及电子邮件如何达到这些目标；2） 确定电子邮件营销的核心标准（什么、为什么、怎...
阅读全文
