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

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

ID:59320717

大小:15.00 KB

页数:2页

时间:2020-09-05

论数据仓库架构前需要考虑的问题.doc_第1页
论数据仓库架构前需要考虑的问题.doc_第2页
资源描述:

《论数据仓库架构前需要考虑的问题.doc》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、论数据仓库架构前需要考虑的问题除掉满足需求以外,一个好的数据仓库需要考虑的是使用(应用)是否方便,维护是否方便,扩展是否方便,开发是否方便。使用:好的系统首先解决的是使用问题,如果最好的操作人员不满意的话,通常应用效果都会比较差的,所以很多公司很注重用户场景的设计,我曾经和微软的同事有过一段时间的接触,发现他们很注重一般企业不注重的问题,比如我们在查询时,选择条件,有的是大于,有的是小于,有的是大于等于等等,通常这样的情况,在事先没有统一的要求和规定,但是他们对于每一个用户场景的描述都很清晰,首先按照业务上的应用,其次按照固定的用户习惯.这就是为什么微软的东西总是被称为傻瓜式的,

2、其实我个人觉得MS的场景真的可以当作傻瓜式来操作,基本上按照他们给的help就可以学会基本的东西了。说回来,我们BIDW需要这样的吗?回答是肯定的,我们有固定报表,有分析型报表,有图表,ad-hoc,还有KPI等dashboard等等,那么我们有研究过或者指定一些规定来描述吗?什么样的情况需要用固定报表,什么样的需要分析性的,什么样的用线性图,什么样的用柱状图,图和表的排列应该是怎么样的,报表的名字应该怎么取,格式和大小是怎么样,等等等,我想我们BIDW的很多同仁都没有好好的去思考这样的问题,其实如果我们有这样的前台展现的规定,而且执行下去,将来企业就算不断的换维护人员,升级系统

3、,都可以比较方便。维护:说到维护,我想很多甲方的同仁都深有感触,维护,我们平时都维护什么了?报表的修改,报表的增加,临时统计老板需要的数据,ETL,系统升级,数据库的清理,历史数据的转接与转存。这就带来我们需要去维护数据库,增加新的表,有的时候我们不清楚原系统的业务逻辑,还要另外来一套表或者报表,一个个的维护人员的更迭,倒是同类型的表很多,同类型的数据很多,比如原来的表叫做T_Sales,现在不清楚逻辑,就吧就够稍微改一下,变成T_Sales_new或者其他的名字,这样的数据库,数据仓库的模型非常非常的多,到了后来大家都是过一天是一天,只要不出问题,到了最后没有办法,又得重新来。

4、如果尽量的避免这样的问题了,我的经验是可以从几个方面去考虑:1:文档。现在就算比较清晰的文档一般也是在系统开始建设的时候描述的比较清晰,但是一旦开始维护系统了,文档慢慢的也就失去维护的价值了,到了最后,也许和系统的关系就不是很大了,但是我们还是要清楚的描述它,因为就算系统的更迭,以后的维护者还是可以按照最初的文档看出一些道道来,我最近就遇到这样的问题了。感觉文档还是非常的宝贵。一定要清楚的描述原系统的业务范围,源表,ETL还有ODS,DW,report等几者的关系,最好这样的数据能放到数据库里面,而且专门为这些元数据做一些报表,设置一些检查的rule,这样我们就可通过查看repo

5、rt来检查我们是否在更新系统后是否更新了文档,是否更新了元数据。2:数据字典。我们经常在数据仓库中遇到ABCD这样的字母表示的业务意义,这些东西其实业务人员大多都很清楚的,但是IT的就不一定了,这给我们和业务人员之间的沟通造成了一些不方便,其实这样的类型代号,一般的企业也只有不到50个类型,通常使用的也只有10-20种,我们可以在建模或者在分析数据的时候,取得这些数据,然后建立一张数据字典,我们的更改删除等操作都可以用数据的状态字段来表示。而且还有很多将来可以直接转化为维表。3:培训材料。业务人员和IT的维护人员,都有换人的时候,他们不懂的可能经常会问,而我们也会经常去给他们讲解

6、。如果我们还怕麻烦的话,我们可以制作一下简单的,简易的操作手册或者比较容易理解的视频文件,提供给他们,最好我们把前期维护的内容都记下来,把问题分类,简单的一点的,比如系统字符的一些设置等等的,都可以写下来,放到网上去,做一个Q&A,这样可以减少很多的工作量。扩展:扩展这个范畴就比较抽象了,我们具体一点的来说,为什么要扩展,就是系统满足不了新的业务要求,业务在变化,管理在变化,我们如何去考虑改变系统去适应这些变化。主要有下面几个方面:模型:我们无论是关系模型还是多维模型或者混合的模型,我们都需要考虑将来,如果原系统发生变化了,或者说原系统的表结构发生变化了,系统是否很方便的去修改和

7、维护。比如我们的财务系统,会计法或者税法,或者相关的法律发生变化,我们的财务报表就有可能发生变化,那边对于的财务模型是否需要发生变化了,如果要变化,是否可以轻易的修改了。其实我们说到这里,都觉得应该的,但是现在的问题是我们怎么去考虑模型的建设。如果我们在建模的时候有domain(ERWin和powerdesigner都有这个概念)的话,那就最好,我们可以很方便的修改类型。可以方便的修改结构,而且还可以查看系统的一些相关的变化。如果没有domain了,特别是大型的企业,而且业务复杂

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。