项目一：国家开发银行信用风险管理系统I期
项目简介（功能与用途）：
信用风险管理系统是在国家开发银行的业务分析管理系统之一。I期主要是以新巴塞尔协议的两元评审为基础构建的模型分析系统。功能主要包括信用等级的评审、债项等级的评审、客户关系分析以及客户违约与损失分析等内容。本系统是建立在数据仓库之上的模型系统。
项目难点与解决方案：
本项目的难点之一是信用评级标准过于复杂。首先评级标准根据行业的不同分为50多类，各类的标准都不相同。其次，财务指标是评级标准中的关键要素，而企业性质的不同也导致财务信息的不同。如何能灵活的建立财务报表、财务指标、财务公式计算和评级标准是本项目的难点。
项目中，我们采用的是模板的建模方式来解决的这个问题。
1）财务科目的定义采用模板形式，用户可以灵活的定义各类财务模板的科目项。
2）财务指标也采用了模板的形式，用户可以在已有财务科目项中定义企业的关键财务指标，并完成财务公式的定义，系统会根据定义的公式计算每个企业的财务指标。
3）评级标准也是灵活定制的模板形式，用户可以自由定制不同的评级标准，进行评分卡打分。
4）评级标准中的定量分析部分在定义评级标准的分项时可以直接与前面计算过的财务指标相关联，即用户录入完财务信息后，评分卡中的定量部分可以直接打出分值。
实践证明，采用模板的建模方式完成评级标准在实现上过于复杂，投入了大量的人力和物力，但是效果还是比较明显，可以适应国开行的各类评级标准及其变化。
（具体的数据库建模略。）
项目成功与失败的经验归纳：
1． 数据仓库之上的模型系统的架构问题
对于一些模型系统，系统中会有用户的参与并生成相关的数据，但是它和通常的操作型系统有着较大的不同，因为它的数据来源于数据仓库。对于这样的系统，架构时应该独立于数据仓库，从数据仓库中取数据，分析的结果应该再次ETL入数据仓库中供其他系统使用。
2． 外部接口，按时间保留数据
对于一个项目来说，确定外部的接口是首先要考虑的问题。对于需要从别的系统读取数据的系统，按时间保留好接口数据是至关重要的一步，在将来出现问题时，责任会比较清晰。保存接口数据的方法可以是保存在表中、保存在文件中或者保存在备份中。
3． 添加历史表，保留删除数据
如果在设计初期，没有考虑逻辑删除数据，而是直接物理删除数据，到了后期由于各方压力需要保留历史记录。可以考虑建立一种历史表，包含原表所有字段，并添加删除人和删除时间。在原表中发生删除操作时，通过触发器或者应用程序将被删除记录保存到历史表中，然后在原表中物理删除。但是这只是不得已的情况下采用的办法，正确的做法应该在建模初期尽可能全的理解用户的需求。
4． 操作人和操作时间
对于操作人和操作时间，需要更新的表最后都建立，这对于以后系统使用过程中出现问题可以提供一些线索，责任的问题在项目中及工作中是尤为重要的一个问题。
5． 依赖关系与强制关系的选择
依赖关系（Dependency）和强制关系（Mandatory）是做CDM时比较相似的两个一对多关系类型。依赖关系比强制关系的要求更高一些，在生成PDM时依赖关系中会做另一个表中的复合主键之一，而强制关系中只做普通的外键。
在下面的两种情况中一般使用强制关系：
与之相关联的表的主键比较多，并且关联几层子表，如果主表主键到子表做复合主键，到下几层的子表时，子表的主键会非常的多。这是可以考虑子表建立自己的主键，关系定为强制关系。
只作普通的外键，并且有可能为空时，选择强制关系。
其他时一般选择依赖关系，即主表主键做子表复合主键之一。
6． 调试性能时看执行计划和建立合理的索引是关键
在进行数据库性能调优时，看执行计划是非常关键的一步。通过执行计划的结果来调整索引策略是性能调优最有效的方法。尽管这一点看起来非常普通，但是在真正出问题时往往注意不到这一点。
你在项目中岗位与贡献：
项目组成员保持在10人左右，持续时间为一年左右。本人在项目初期任系统设计师，负责系统的设计，在项目后期任技术经理职务，负责项目中技术架构设计和核心模块的开发工作，并协助项目经理的工作。
项目二：国家开发银行信用风险管理系统II期
项目简介（功能与用途）：
信用风险管理系统是在国家开发银行的业务分析管理系统之一。II期是在I期的基础上，根据新巴塞尔资本协议计算PD（违约概率）、LGD（违约损失率）、EAD（风险暴露）、M（有效期限）、EL（预期损失）、EC（经济资本）、RAROC（风险加权的投资回报率）等风险指标，并对其进行多维分析、预警及考核。系统的目标是形成国开行特有的信用风险分析与量化模型方法，对国开行的信用风险进行动态、实时的监控与管理，建立一套完善的信用风险管理机制。
项目难点与解决方法：
项目的难点之一是风险指标的测算。风险指标的测算涉及到全行数据，计算量大，计算公式及计算过程复杂。
项目中，我们采用存储过程和函数的组合巧妙的解决了这个问题。
1）数据准备区的灵活建模，以满足方便、准确为第一目的。
2）常用功能的计算公式采用函数的形式来进行复用。
3）正态函数和反正态函数等一些复杂函数采用查表的方式，即建立物理表来保存函数值，使用时直接查询。
4）对于涉及数据的计算过程采用存储过程来完成计算。
实践证明，所有的计算过程采用存储过程和函数完成，比使用嵌入式的C语言开发要简单，运行效率也要高。
（具体程序略。）
项目成功与失败的经验归纳：
1． 明确模型系统的辅助分析功能
对于建立在数据仓库之上的分析系统、模型系统应该以辅助分析做为自己的目的。以项目中的预警模型为例，在设计时，预警阈值的设置要和预警阈值的建议值的产生要分开，由用户自己参考系统计算出的建议值来决定应该设置的阈值。除了责任的问题外，分开对于系统的灵活性也有好处，我们可以不断添加新的算法，或优化原有算法来产生不同的建议值。
2． 充分利用数据准备区中的临时表
对于计算量很多或者迁移很复杂的系统，我们要充分的利用好数据准备区。数据准备区是不对用户提供接口的区域，所以这里的建模可以非常灵活，只要对迁移或计算有用，我们就可以建立相应的临时表，并在处理结束后删除掉临时表中的数据。
3． 有关聚集的处理
聚集对于数据仓库系统有着至关重要的作用，它可以大大的提供系统的查询效率。在Oracle中处理聚集的方法是建立物化视图。建立好的物化视图可以像索引一样，在用户不需了解的情况下发挥它的强大作用。
4． 派生数据的保存问题
在数据仓库系统中，通过计算得到的事实数据应该物理的保存在表中。这样做可以很好的保证数据的一致性，避免用户计算出错的可能性，而付出的存储代价相对可能的错误来说可以忽略。对于百分比等非加性数值，应该将分子和分母都保存在表中，这样可以计算合计值的比率。
5． 关联维度的处理问题
在维度建模时，经常会出现维度间有关联的情况。这时有两种处理方法，一种是建立两个独立的维度，另一种是建立一个超级维度。通常，我们要考虑的是维度间的关系是否固定，是否是多对多关系，是否不发生变化。如果两个维度的关系比较固定、并且不是多对多关系，也比较稳定，这时可以考虑建立成一个超级维度，否则最好建立成两个独立的维度。
6． 合并事实表取代交叉探查
交叉探察（Drill Across）操作的效率比较低，应该尽量用合并事实表取代交叉探察。合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事实。属于建立在多个事实表之上的派生事实表。合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。
7． 维度建模中空值的处理策略
在维度建模中，要少保留NULL值。通常的处理方法是，对于事实表的外键为空的情况，应该在维度表中建立相应的记录来表示，如日期维度表中“还未发生”记录。对于维度表中的属性值为空的情况，我们应该写入“未知”等内容，因为维度表中的属性会成为报表的标题，这样的处理可以让用户更清晰的了解实际情况。对于事实表中的事实为空的情况，可以将空值保留下来，因为大多数的数据库系统都能对空值很好的处理聚集函数，如SUM，MAX，MIN，COUNT，AVG。
你在项目中岗位与贡献：
项目组成员保持在10人左右，开发时间大约是一年左右。本人在本项目任技术经理职务，负责项目中技术架构设计和核心模块的开发，并协助项目经理的工作。
项目三：广西乔丰公司决策支持系统
项目简介（功能与用途）：
广西侨丰公司是一家以钢材销售为主营行业的商贸流通企业，在全国各大城市都有他们的部门和子公司。决策支持系统（Decision Support System）是一个基于数据仓库架构的分析系统，数据的来源是侨丰公司在各地的进销存系统。
项目难点与解决方法：
本项目的难点之一是变化数据捕获问题。在项目的各个源系统中，表中没有时间戳，而且变化比较频繁，对于像发货表中的发货量这样的字段在填写后也有可能修改，导致数据仓库中的事实表数据发生变化。
项目中，我们采用了基于触发器的变化数据捕获方法解决了这个问题。处理的方法是
1）在操作型源系统中建立存储变化数据的表。
2）在业务表中的Insert、Update和Delete操作上建立触发器，并将变化的数据写入前面建立的表中。
3）在迁移程序中将变化的数据抽取出来。
4）将变化的数据按不同的策略更新到数据仓库中。
实践证明，采用基于触发器的变化数据捕获办法可以很好的完成需要的功能，但是对源系统的性能产生了一定的影响，是一种不太推荐的方法。
项目成功与失败的经验归纳：
1． 有关主子表的建模问题
对于像合同主表、合同子表这样的主子表来说，进行维度建模时，有两种选择。一种是在两个粒度上分别建立事实表，即合同事实表和合同分列项事实表。另一种是只建立最低粒度的事实表，将高粒度的事实数据分派到低粒度的事实表中，分派的规则和用户共同确定。在项目中，我们采用了第一种方法，事实证明，这种方法弊端很多，后续的分析中两个事实表用起来都不好用。所以，对于该类问题，建议采用第二种方法。
2． 有关父子表的建模问题
对于层数已知的父子表建模时，可以考虑每层建立成一个字段。对于层数未知的父子表，只能建立成递归关系的父子表，这时可以考虑采用支架维度来简化查询。
3． 雪花模型是否有必要
在维度建模中，雪花模型是一种不推荐的建模方式。雪花模型的好处是节省空间、对维度表的维护也要简单一些。但是雪花模型使数据的访问变得复杂，性能比星型模型也要差很多，维度表节省的空间很少。所以，不建议采用雪花模型，除非在能讲出很充分理由的时候，如对支架维度的处理等。
4． 触发器的使用要谨慎
对于触发器的使用要谨慎，最好采用具有相同功能的其他办法。触发器对数据操作的性能的影响较大，而且给调试程序带来麻烦。所以建议尽量少的采用触发器技术，如果采用的话，要做好文档记录，标注好触发器的建立时间、功能和目的等内容。
5． 代理关键字的必要性
在项目的初期，对于是否采用代理关键字存在过争论，争论的结果采用的代理键，最终的结果证明这个选择是完全正确的。代理关键字给数据迁移带来了一些麻烦。但是它的好处也很明显，首先整型外键连接性能很好，其次对于一些非常规的维度如“日期未定”等可以增加记录来处理，更重要的一点是代理关键字可以使用TYPE 2的缓慢变化维技术来记录维度表的历史变化信息。
6． 基于触发器的变化数据捕获方法
基于触发器的变化数据捕获方法从实现上来说比较灵活，适用面也比较广。但是由于需要对源系统进行操作，对源系统影响较大，所以建议在没有别的选择时再考虑这种方法。而一种基于DBMS的变化数据捕获方法正在逐渐流行起来。以Oralce为例，它的CDC技术通过DBMS的日志来进行变化数据捕获，而不对操作型系统产生影响，是未来变化数据捕获的发展趋势。
7． 关于时间戳的问题
时间戳对于变化数据捕获有着重要的作用，所以建议在建立操作型系统时，能给每个表建立一个时间戳。
8． 关于元数据的管理
由于在项目中没有采用集中的元数据管理，导致项目后期人员变化对项目的影响较大。建议在数据仓库项目中，采用专门的元数据管理工具来进行元数据的管理。因为数据仓库是一个长期的过程，好的元数据管理对数据仓库的建设是很重要的。
你在项目中岗位与贡献：
项目组成员前后共有8人左右，项目持续时间大约是十个月左右。本人在本项目中的职责是数据仓库架构师，负责数据仓库的架构、数据仓库的建模，并协助项目经理带领工程师完成ETL及前段展现程序的开发。
项目四：台湾明基公司主管信息系统
项目简介（功能与用途）：
主管信息系统（Executive Information System，EIS）是台湾明基公司一个基于数据仓库架构的分析系统，面向的用户是企业的高级管理人员。系统的目的是为高层主管提供企业内部数据，协助高层主管做规划、分析，支持高层主管进行决策。
项目难点与解决方法：
本项目的难点之一是对数据迁移程序的错误处理问题。数据迁移过程中可能会出现各种问题，而一个健壮的迁移程序应该能合理的处理好各种问题，使数据迁移能尽可能多的成功完成。
项目中，我们对数据迁移程序运行中的问题进行了如下的处理，
1）首先要对源系统进行完善的数据概况分析，了解源系统的数据状况。
2）建立错误日志表，用来记录各种可能出现的数据问题和迁移问题。
3）对于缺失数据的问题，记录入错误日志表，由人工后续处理。
3）对可能出现的错误进行分类，对影响不大的小问题，可以直接跳过去，记录入错误日志表，人工后续处理。
4）对于较大的问题，记录好日志，由人工在第二天检查日志表，解决错误问题后重新启动迁移程序。
实践证明，我们对迁移程序的处理能较好的完成迁移工作。但是对于一些较大问题，仍需要人工来查看日志、发现问题并解决。
项目成功与失败的经验归纳：
1． 源数据质量检查
在进行数据迁移之前，源数据的概况分析是很重要的一步。通过概况分析我们可以掌握源系统的数据质量情况能否满足项目的需求，以及在数据迁移时需要注意的问题。
数据概况的分析一般可以通过如下分析来完成。对于字段，主要分析它们的数据定义和域定义，特别要注意有多少行记录包含空值，有多少行记录违反域约束等内容。对于表，主要分析表内字段间的关系和表间的主外键约束，特别是有多少可以做键的字段有重复值，外键约束有多少已经不起作用等内容。数据概况分析还包括用自定义的程序去检验复杂的业务逻辑是否满足。
2． 使用工具还是手工写代码
对于ETL架构师来说首先要决定的事情就是数据迁移使用工具还是自己手工编写。使用数据迁移工具可以很好处理负载的均衡，可以有较完善的元数据保存策略，可以有相对简单的调度策略，使整个数据迁移过程的开发变得简化。手工编写代码的方式则比较灵活，不受工具提供功能的限制。目前来说，各厂商的数据迁移工具已经开发的比较完善，对于数据仓库项目建议首先考虑采用数据迁移工具。由于本项目是在2000年左右开发的，当时好的迁移工具还很少，项目组是选择手工编码来实现数据迁移的，效果还算比较理想。
3． 数据准备区中保留数据
在数据准备区中保留数据备份有很多好处，首先当数据迁移由于某种原因中断时，ETL组可以控制迁移程序重新启动，不受源数据的影响。另外，数据准备区是与最终用户无关的一个区域，DBA一定要做好权限的控制。数据准备区最好是在单独机器上来实现。
4． 加载数据时Update和Insert分离
在大批量的数据加载时，考虑到效率的问题，应该先将需要Update的数据和需要Insert的数据进行分离。现在有的DBMS提供merge的操作可以由DBMS来区分是Update操作还是Insert操作，但是效率也很低，数据量小时可以考虑采用，用法比较简单。当数据加载量大时，分离不同的操作是首要的选择。
5． 加载数据时处理索引的策略
在数据加载中，索引的存在会对效率产生很大的影响，通常的处理过程如下：1）分离更新和插入操作。2）Drop掉对更新没有帮助的索引。3）加载需要更新的记录。4）Drop掉其他所有索引。5）加载需要插入的记录。6）重建所有索引。
6． 加载数据时处理数据库日志的策略
在数据迁移的整个过程中，迁移每一步的成功失败都由ETL项目组来进行控制，所以这时数据库本身的日志功能就失去了原有的作用，而且会对迁移的性能产生影响，所以在数据迁移过程中可以考虑关闭DBMS的日志功能。
你在项目中岗位与贡献：
项目组成员共有7人左右，台湾有2人左右做系统设计，大陆有5人左右做开发工作，项目持续时间近一年。本人在项目初期主要负责后台数据迁移程序的开发，后期作为大陆方的项目负责人带领组员完成迁移程序开发、Cube的定制及前段展现程序的开发等工作。
项目简介（功能与用途）：
信用风险管理系统是在国家开发银行的业务分析管理系统之一。I期主要是以新巴塞尔协议的两元评审为基础构建的模型分析系统。功能主要包括信用等级的评审、债项等级的评审、客户关系分析以及客户违约与损失分析等内容。本系统是建立在数据仓库之上的模型系统。
项目难点与解决方案：
本项目的难点之一是信用评级标准过于复杂。首先评级标准根据行业的不同分为50多类，各类的标准都不相同。其次，财务指标是评级标准中的关键要素，而企业性质的不同也导致财务信息的不同。如何能灵活的建立财务报表、财务指标、财务公式计算和评级标准是本项目的难点。
项目中，我们采用的是模板的建模方式来解决的这个问题。
1）财务科目的定义采用模板形式，用户可以灵活的定义各类财务模板的科目项。
2）财务指标也采用了模板的形式，用户可以在已有财务科目项中定义企业的关键财务指标，并完成财务公式的定义，系统会根据定义的公式计算每个企业的财务指标。
3）评级标准也是灵活定制的模板形式，用户可以自由定制不同的评级标准，进行评分卡打分。
4）评级标准中的定量分析部分在定义评级标准的分项时可以直接与前面计算过的财务指标相关联，即用户录入完财务信息后，评分卡中的定量部分可以直接打出分值。
实践证明，采用模板的建模方式完成评级标准在实现上过于复杂，投入了大量的人力和物力，但是效果还是比较明显，可以适应国开行的各类评级标准及其变化。
（具体的数据库建模略。）
项目成功与失败的经验归纳：
1． 数据仓库之上的模型系统的架构问题
对于一些模型系统，系统中会有用户的参与并生成相关的数据，但是它和通常的操作型系统有着较大的不同，因为它的数据来源于数据仓库。对于这样的系统，架构时应该独立于数据仓库，从数据仓库中取数据，分析的结果应该再次ETL入数据仓库中供其他系统使用。
2． 外部接口，按时间保留数据
对于一个项目来说，确定外部的接口是首先要考虑的问题。对于需要从别的系统读取数据的系统，按时间保留好接口数据是至关重要的一步，在将来出现问题时，责任会比较清晰。保存接口数据的方法可以是保存在表中、保存在文件中或者保存在备份中。
3． 添加历史表，保留删除数据
如果在设计初期，没有考虑逻辑删除数据，而是直接物理删除数据，到了后期由于各方压力需要保留历史记录。可以考虑建立一种历史表，包含原表所有字段，并添加删除人和删除时间。在原表中发生删除操作时，通过触发器或者应用程序将被删除记录保存到历史表中，然后在原表中物理删除。但是这只是不得已的情况下采用的办法，正确的做法应该在建模初期尽可能全的理解用户的需求。
4． 操作人和操作时间
对于操作人和操作时间，需要更新的表最后都建立，这对于以后系统使用过程中出现问题可以提供一些线索，责任的问题在项目中及工作中是尤为重要的一个问题。
5． 依赖关系与强制关系的选择
依赖关系（Dependency）和强制关系（Mandatory）是做CDM时比较相似的两个一对多关系类型。依赖关系比强制关系的要求更高一些，在生成PDM时依赖关系中会做另一个表中的复合主键之一，而强制关系中只做普通的外键。
在下面的两种情况中一般使用强制关系：
与之相关联的表的主键比较多，并且关联几层子表，如果主表主键到子表做复合主键，到下几层的子表时，子表的主键会非常的多。这是可以考虑子表建立自己的主键，关系定为强制关系。
只作普通的外键，并且有可能为空时，选择强制关系。
其他时一般选择依赖关系，即主表主键做子表复合主键之一。
6． 调试性能时看执行计划和建立合理的索引是关键
在进行数据库性能调优时，看执行计划是非常关键的一步。通过执行计划的结果来调整索引策略是性能调优最有效的方法。尽管这一点看起来非常普通，但是在真正出问题时往往注意不到这一点。
你在项目中岗位与贡献：
项目组成员保持在10人左右，持续时间为一年左右。本人在项目初期任系统设计师，负责系统的设计，在项目后期任技术经理职务，负责项目中技术架构设计和核心模块的开发工作，并协助项目经理的工作。
项目二：国家开发银行信用风险管理系统II期
项目简介（功能与用途）：
信用风险管理系统是在国家开发银行的业务分析管理系统之一。II期是在I期的基础上，根据新巴塞尔资本协议计算PD（违约概率）、LGD（违约损失率）、EAD（风险暴露）、M（有效期限）、EL（预期损失）、EC（经济资本）、RAROC（风险加权的投资回报率）等风险指标，并对其进行多维分析、预警及考核。系统的目标是形成国开行特有的信用风险分析与量化模型方法，对国开行的信用风险进行动态、实时的监控与管理，建立一套完善的信用风险管理机制。
项目难点与解决方法：
项目的难点之一是风险指标的测算。风险指标的测算涉及到全行数据，计算量大，计算公式及计算过程复杂。
项目中，我们采用存储过程和函数的组合巧妙的解决了这个问题。
1）数据准备区的灵活建模，以满足方便、准确为第一目的。
2）常用功能的计算公式采用函数的形式来进行复用。
3）正态函数和反正态函数等一些复杂函数采用查表的方式，即建立物理表来保存函数值，使用时直接查询。
4）对于涉及数据的计算过程采用存储过程来完成计算。
实践证明，所有的计算过程采用存储过程和函数完成，比使用嵌入式的C语言开发要简单，运行效率也要高。
（具体程序略。）
项目成功与失败的经验归纳：
1． 明确模型系统的辅助分析功能
对于建立在数据仓库之上的分析系统、模型系统应该以辅助分析做为自己的目的。以项目中的预警模型为例，在设计时，预警阈值的设置要和预警阈值的建议值的产生要分开，由用户自己参考系统计算出的建议值来决定应该设置的阈值。除了责任的问题外，分开对于系统的灵活性也有好处，我们可以不断添加新的算法，或优化原有算法来产生不同的建议值。
2． 充分利用数据准备区中的临时表
对于计算量很多或者迁移很复杂的系统，我们要充分的利用好数据准备区。数据准备区是不对用户提供接口的区域，所以这里的建模可以非常灵活，只要对迁移或计算有用，我们就可以建立相应的临时表，并在处理结束后删除掉临时表中的数据。
3． 有关聚集的处理
聚集对于数据仓库系统有着至关重要的作用，它可以大大的提供系统的查询效率。在Oracle中处理聚集的方法是建立物化视图。建立好的物化视图可以像索引一样，在用户不需了解的情况下发挥它的强大作用。
4． 派生数据的保存问题
在数据仓库系统中，通过计算得到的事实数据应该物理的保存在表中。这样做可以很好的保证数据的一致性，避免用户计算出错的可能性，而付出的存储代价相对可能的错误来说可以忽略。对于百分比等非加性数值，应该将分子和分母都保存在表中，这样可以计算合计值的比率。
5． 关联维度的处理问题
在维度建模时，经常会出现维度间有关联的情况。这时有两种处理方法，一种是建立两个独立的维度，另一种是建立一个超级维度。通常，我们要考虑的是维度间的关系是否固定，是否是多对多关系，是否不发生变化。如果两个维度的关系比较固定、并且不是多对多关系，也比较稳定，这时可以考虑建立成一个超级维度，否则最好建立成两个独立的维度。
6． 合并事实表取代交叉探查
交叉探察（Drill Across）操作的效率比较低，应该尽量用合并事实表取代交叉探察。合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事实。属于建立在多个事实表之上的派生事实表。合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。
7． 维度建模中空值的处理策略
在维度建模中，要少保留NULL值。通常的处理方法是，对于事实表的外键为空的情况，应该在维度表中建立相应的记录来表示，如日期维度表中“还未发生”记录。对于维度表中的属性值为空的情况，我们应该写入“未知”等内容，因为维度表中的属性会成为报表的标题，这样的处理可以让用户更清晰的了解实际情况。对于事实表中的事实为空的情况，可以将空值保留下来，因为大多数的数据库系统都能对空值很好的处理聚集函数，如SUM，MAX，MIN，COUNT，AVG。
你在项目中岗位与贡献：
项目组成员保持在10人左右，开发时间大约是一年左右。本人在本项目任技术经理职务，负责项目中技术架构设计和核心模块的开发，并协助项目经理的工作。
项目三：广西乔丰公司决策支持系统
项目简介（功能与用途）：
广西侨丰公司是一家以钢材销售为主营行业的商贸流通企业，在全国各大城市都有他们的部门和子公司。决策支持系统（Decision Support System）是一个基于数据仓库架构的分析系统，数据的来源是侨丰公司在各地的进销存系统。
项目难点与解决方法：
本项目的难点之一是变化数据捕获问题。在项目的各个源系统中，表中没有时间戳，而且变化比较频繁，对于像发货表中的发货量这样的字段在填写后也有可能修改，导致数据仓库中的事实表数据发生变化。
项目中，我们采用了基于触发器的变化数据捕获方法解决了这个问题。处理的方法是
1）在操作型源系统中建立存储变化数据的表。
2）在业务表中的Insert、Update和Delete操作上建立触发器，并将变化的数据写入前面建立的表中。
3）在迁移程序中将变化的数据抽取出来。
4）将变化的数据按不同的策略更新到数据仓库中。
实践证明，采用基于触发器的变化数据捕获办法可以很好的完成需要的功能，但是对源系统的性能产生了一定的影响，是一种不太推荐的方法。
项目成功与失败的经验归纳：
1． 有关主子表的建模问题
对于像合同主表、合同子表这样的主子表来说，进行维度建模时，有两种选择。一种是在两个粒度上分别建立事实表，即合同事实表和合同分列项事实表。另一种是只建立最低粒度的事实表，将高粒度的事实数据分派到低粒度的事实表中，分派的规则和用户共同确定。在项目中，我们采用了第一种方法，事实证明，这种方法弊端很多，后续的分析中两个事实表用起来都不好用。所以，对于该类问题，建议采用第二种方法。
2． 有关父子表的建模问题
对于层数已知的父子表建模时，可以考虑每层建立成一个字段。对于层数未知的父子表，只能建立成递归关系的父子表，这时可以考虑采用支架维度来简化查询。
3． 雪花模型是否有必要
在维度建模中，雪花模型是一种不推荐的建模方式。雪花模型的好处是节省空间、对维度表的维护也要简单一些。但是雪花模型使数据的访问变得复杂，性能比星型模型也要差很多，维度表节省的空间很少。所以，不建议采用雪花模型，除非在能讲出很充分理由的时候，如对支架维度的处理等。
4． 触发器的使用要谨慎
对于触发器的使用要谨慎，最好采用具有相同功能的其他办法。触发器对数据操作的性能的影响较大，而且给调试程序带来麻烦。所以建议尽量少的采用触发器技术，如果采用的话，要做好文档记录，标注好触发器的建立时间、功能和目的等内容。
5． 代理关键字的必要性
在项目的初期，对于是否采用代理关键字存在过争论，争论的结果采用的代理键，最终的结果证明这个选择是完全正确的。代理关键字给数据迁移带来了一些麻烦。但是它的好处也很明显，首先整型外键连接性能很好，其次对于一些非常规的维度如“日期未定”等可以增加记录来处理，更重要的一点是代理关键字可以使用TYPE 2的缓慢变化维技术来记录维度表的历史变化信息。
6． 基于触发器的变化数据捕获方法
基于触发器的变化数据捕获方法从实现上来说比较灵活，适用面也比较广。但是由于需要对源系统进行操作，对源系统影响较大，所以建议在没有别的选择时再考虑这种方法。而一种基于DBMS的变化数据捕获方法正在逐渐流行起来。以Oralce为例，它的CDC技术通过DBMS的日志来进行变化数据捕获，而不对操作型系统产生影响，是未来变化数据捕获的发展趋势。
7． 关于时间戳的问题
时间戳对于变化数据捕获有着重要的作用，所以建议在建立操作型系统时，能给每个表建立一个时间戳。
8． 关于元数据的管理
由于在项目中没有采用集中的元数据管理，导致项目后期人员变化对项目的影响较大。建议在数据仓库项目中，采用专门的元数据管理工具来进行元数据的管理。因为数据仓库是一个长期的过程，好的元数据管理对数据仓库的建设是很重要的。
你在项目中岗位与贡献：
项目组成员前后共有8人左右，项目持续时间大约是十个月左右。本人在本项目中的职责是数据仓库架构师，负责数据仓库的架构、数据仓库的建模，并协助项目经理带领工程师完成ETL及前段展现程序的开发。
项目四：台湾明基公司主管信息系统
项目简介（功能与用途）：
主管信息系统（Executive Information System，EIS）是台湾明基公司一个基于数据仓库架构的分析系统，面向的用户是企业的高级管理人员。系统的目的是为高层主管提供企业内部数据，协助高层主管做规划、分析，支持高层主管进行决策。
项目难点与解决方法：
本项目的难点之一是对数据迁移程序的错误处理问题。数据迁移过程中可能会出现各种问题，而一个健壮的迁移程序应该能合理的处理好各种问题，使数据迁移能尽可能多的成功完成。
项目中，我们对数据迁移程序运行中的问题进行了如下的处理，
1）首先要对源系统进行完善的数据概况分析，了解源系统的数据状况。
2）建立错误日志表，用来记录各种可能出现的数据问题和迁移问题。
3）对于缺失数据的问题，记录入错误日志表，由人工后续处理。
3）对可能出现的错误进行分类，对影响不大的小问题，可以直接跳过去，记录入错误日志表，人工后续处理。
4）对于较大的问题，记录好日志，由人工在第二天检查日志表，解决错误问题后重新启动迁移程序。
实践证明，我们对迁移程序的处理能较好的完成迁移工作。但是对于一些较大问题，仍需要人工来查看日志、发现问题并解决。
项目成功与失败的经验归纳：
1． 源数据质量检查
在进行数据迁移之前，源数据的概况分析是很重要的一步。通过概况分析我们可以掌握源系统的数据质量情况能否满足项目的需求，以及在数据迁移时需要注意的问题。
数据概况的分析一般可以通过如下分析来完成。对于字段，主要分析它们的数据定义和域定义，特别要注意有多少行记录包含空值，有多少行记录违反域约束等内容。对于表，主要分析表内字段间的关系和表间的主外键约束，特别是有多少可以做键的字段有重复值，外键约束有多少已经不起作用等内容。数据概况分析还包括用自定义的程序去检验复杂的业务逻辑是否满足。
2． 使用工具还是手工写代码
对于ETL架构师来说首先要决定的事情就是数据迁移使用工具还是自己手工编写。使用数据迁移工具可以很好处理负载的均衡，可以有较完善的元数据保存策略，可以有相对简单的调度策略，使整个数据迁移过程的开发变得简化。手工编写代码的方式则比较灵活，不受工具提供功能的限制。目前来说，各厂商的数据迁移工具已经开发的比较完善，对于数据仓库项目建议首先考虑采用数据迁移工具。由于本项目是在2000年左右开发的，当时好的迁移工具还很少，项目组是选择手工编码来实现数据迁移的，效果还算比较理想。
3． 数据准备区中保留数据
在数据准备区中保留数据备份有很多好处，首先当数据迁移由于某种原因中断时，ETL组可以控制迁移程序重新启动，不受源数据的影响。另外，数据准备区是与最终用户无关的一个区域，DBA一定要做好权限的控制。数据准备区最好是在单独机器上来实现。
4． 加载数据时Update和Insert分离
在大批量的数据加载时，考虑到效率的问题，应该先将需要Update的数据和需要Insert的数据进行分离。现在有的DBMS提供merge的操作可以由DBMS来区分是Update操作还是Insert操作，但是效率也很低，数据量小时可以考虑采用，用法比较简单。当数据加载量大时，分离不同的操作是首要的选择。
5． 加载数据时处理索引的策略
在数据加载中，索引的存在会对效率产生很大的影响，通常的处理过程如下：1）分离更新和插入操作。2）Drop掉对更新没有帮助的索引。3）加载需要更新的记录。4）Drop掉其他所有索引。5）加载需要插入的记录。6）重建所有索引。
6． 加载数据时处理数据库日志的策略
在数据迁移的整个过程中，迁移每一步的成功失败都由ETL项目组来进行控制，所以这时数据库本身的日志功能就失去了原有的作用，而且会对迁移的性能产生影响，所以在数据迁移过程中可以考虑关闭DBMS的日志功能。
你在项目中岗位与贡献：
项目组成员共有7人左右，台湾有2人左右做系统设计，大陆有5人左右做开发工作，项目持续时间近一年。本人在项目初期主要负责后台数据迁移程序的开发，后期作为大陆方的项目负责人带领组员完成迁移程序开发、Cube的定制及前段展现程序的开发等工作。
2567
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
