论数据仓库架构前需要考虑的问题.docx资源-CSDN文库

版权申诉

63 浏览量 2022-06-17 06:27:36 上传评论收藏 13KB DOCX 举报

资源推荐

资源详情

资源评论

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

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

方便，扩展是否方便，开发是否方便。

使用:

好的系统首先解决的是使用问题，如果最好的操作人员不满意的话，通常应用效果都会

比较差的，所以很多公司很注重用户场景的设计，我曾经和微软的同事有过一段时间的接触，

发现他们很注重一般企业不注重的问题，比如我们在查询时，选择条件，有的是大于，有的

是小于，有的是大于等于等等，通常这样的情况，在事先没有统一的要求和规定，但是他们

对于每一个用户场景的描述都很清晰，首先按照业务上的应用，其次按照固定的用户习惯.

这就是为什么微软的东西总是被称为傻瓜式的，其实我个人觉得 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 的维护人员，都有换人的时候，他们不懂的可能经常会问，

而我们也会经常去给他们讲解。如果我们还怕麻烦的话，我们可以制作一下简单的，简易的

操作手册或者比较容易理解的视频文件，提供给他们，最好我们把前期维护的内容都记下来，

把问题分类，简单的一点的，比如系统字符的一些设置等等的，都可以写下来，放到网上去，

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余1页未读，立即下载

内容反馈

版权申诉

春哥111

粉丝: 1w+
资源: 5万+

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip