论数据仓库架构前需要考虑的问题

:

[@more@]

论数据仓库架构前需要考虑的问题

除掉满足需求以外，一个好的数据仓库需要考虑的是使用（应用）是否方便，维护是否方便，扩展是否方便，开发是否方便。

使用:
好的系统首先解决的是使用问题，如果最好的操作人员不满意的话，通常应用效果都会比较差的，所以很多公司很注重用户场景的设计，我曾经和微软的同事有过一段时间的接触，发现他们很注重一般企业不注重的问题，比如我们在查询时，选择条件，有的是大于，有的是小于，有的是大于等于等等，通常这样的情况，在事先没有统一的要求和规定，但是他们对于每一个用户场景的描述都很清晰，首先按照业务上的应用，其次按照固定的用户习惯.这就是为什么微软的东西总是被称为傻瓜式的，其实我个人觉得MS的场景真的可以当作傻瓜式来操作，基本上按照他们给的help就可以学会基本的东西了。说回来，我们BIDW需要这样的吗？回答是肯定的，我们有固定报表，有分析型报表，有图表，ad-hoc，还有KPI等dashboard等等，那么我们有研究过或者指定一些规定来描述吗？什么样的情况需要用固定报表，什么样的需要分析性的，什么样的用线性图，什么样的用柱状图，图和表的排列应该是怎么样的，报表的名字应该怎么取，格式和大小是怎么样，等等等，我想我们BIDW的很多同仁都没有好好的去思考这样的问题，其实如果我们有这样的前台展现的规定，而且执行下去，将来企业就算不断的换维护人员，升级系统，都可以比较方便。

维护：
说到维护，我想很多甲方的同仁都深有感触，维护，我们平时都维护什么了？报表的修改，报表的增加，临时统计老板需要的数据，ETL，系统升级，数据库的清理，历史数据的转接与转存。这就带来我们需要去维护数据库，增加新的表，有的时候我们不清楚原系统的业务逻辑，还要另外来一套表或者报表，一个个的维护人员的更迭，倒是同类型的表很多，同类型的数据很多，比如原来的表叫做T_Sales，现在不清楚逻辑，就吧就够稍微改一下，变成T_Sales_new或者其他的名字，这样的数据库，数据仓库的模型非常非常的多，到了后来大家都是过一天是一天，只要不出问题，到了最后没有办法，又得重新来。如果尽量的避免这样的问题了，我的经验是可以从几个方面去考虑：
1：文档。现在就算比较清晰的文档一般也是在系统开始建设的时候描述的比较清晰，但是一旦开始维护系统了，文档慢慢的也就失去维护的价值了，到了最后，也许和系统的关系就不是很大了，但是我们还是要清楚的描述它，因为就算系统的更迭，以后的维护者还是可以按照最初的文档看出一些道道来，我最近就遇到这样的问题了。感觉文档还是非常的宝贵。一定要清楚的描述原系统的业务范围，源表，ETL还有ODS，DW，report等几者的关系，最好这样的数据能放到数据库里面，而且专门为这些元数据做一些报表，设置一些检查的rule，这样我们就可通过查看report来检查我们是否在更新系统后是否更新了文档，是否更新了元数据。
2：数据字典。我们经常在数据仓库中遇到A B C D这样的字母表示的业务意义，这些东西其实业务人员大多都很清楚的，但是IT的就不一定了，这给我们和业务人员之间的沟通造成了一些不方便，其实这样的类型 代号，一般的企业也只有不到50个类型，通常使用的也只有10-20种，我们可以在建模或者在分析数据的时候，取得这些数据，然后建立一张数据字典，我们的更改删除等操作都可以用数据的状态字段来表示。而且还有很多将来可以直接转化为维表。
3：培训材料。业务人员和IT的维护人员，都有换人的时候，他们不懂的可能经常会问，而我们也会经常去给他们讲解。如果我们还怕麻烦的话，我们可以制作一下简单的，简易的操作手册或者比较容易理解的视频文件，提供给他们，最好我们把前期维护的内容都记下来，把问题分类，简单的一点的，比如系统字符的一些设置等等的，都可以写下来，放到网上去，做一个Q&A,这样可以减少很多的工作量。

扩展：
扩展这个范畴就比较抽象了，我们具体一点的来说，为什么要扩展，就是系统满足不了新的业务要求，业务在变化，管理在变化，我们如何去考虑改变系统去适应这些变化。主要有下面几个方面：
模型：我们无论是关系模型还是多维模型或者混合的模型，我们都需要考虑将来，如果原系统发生变化了，或者说原系统的表结构发生变化了，系统是否很方便的去修改和维护。比如我们的财务系统，会计法或者税法，或者相关的法律发生变化，我们的财务报表就有可能发生变化，那边对于的财务模型是否需要发生变化了，如果要变化，是否可以轻易的修改了。其实我们说到这里，都觉得应该的，但是现在的问题是我们怎么去考虑模型的建设。如果我们在建模的时候有domain（ERWin和powerdesigner都有这个概念）的话，那就最好，我们可以很方便的修改类型。可以方便的修改结构，而且还可以查看系统的一些相关的变化。如果没有domain了，特别是大型的企业，而且业务复杂，一般没有自己的企业数据元，如果数据仓库是纯多维模型的话，我建议我们的ODS采用关系模型去搭建，这样发生变化的时候，我们也不会对DW有太大的影响。
ETL：我个人比较喜欢采用ELT的方式，将数据转换放到SP中，因为可以用一个总的SP去适应所以的ETL，然后在设置一些和功能对应的子SP，这样既可以采用事务去管理，也好通过ETL package的编号去维护。对于一般的insert，delete和update的修改都表容易，特别是异构数据库的之间的数据传递。当时于特殊的ETL，我们可以特殊考虑。
BI，这里的BI其实就是指的是我们最终用户操作的界面，一般都是web的，有report，adhoc，dashboard等等，这里通常都是一些需求的变化。如何的扩展更多的还是要取决于我们的使用平台。最好在设计之前考虑webservice这个功能，因为这个功能是跨平台的，我们可以从不同的系统交互数据。

开发：
最后我们谈谈开发，其实BIDW的开发的难度以此为ETL，data model，report展现。ETL的工作量基本上要占40-60%，而它又在data model之后，所以我们需要考虑的还是在data model怎么样为ETL提供方便，首先我们可以在见表的时候用schema来区分表，用固定的name convertion来标示字段，比如code 用CD，name用NM等等，如果ODS和DW有多层的话，建议用同样的表，同样的名称。这样很多ETL工具在mapping的时候，就可以自动的匹配出来。
对于ETL的开发，我建议在ETL前，先分析ETL流程，然后开发1-2个通用的package，以后就已这连个为模板，不断的copy和修改，这样可以节省很大的工作量。如果能采用package和subpackage的话，那就更好，可以团队写作去开发了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7600305/viewspace-1004306/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/7600305/viewspace-1004306/