哪种数据仓库架构最成功

”的争论一直没有休止，这个问题同时也是企业在建立DW时需要决策的关键问题。Bill Inmon的集线器架构/企业信息工厂架构（Hub and Spoke / CIF – Corporate Information Factory）与Ralph Kimball的数据集市/数据仓库总线架构（Data Mart Bus Architecture/Data Warehouse Bus Architecture）则是DW架构的争论焦点。但是，这些争论一直无法形成统一的结论。到底哪种DW架构最好，不同的BI/DW从业者在不同的项目中，面对不同企业的不同情况时，往往持有不同的说法。2005 年，Thilini Ariyachandra 与Hugh Watson针对DW架构做了一个深入的调查，调查题目为“哪种数据仓库最成功？”，受访者由454位曾在各种不同规模的企业（绝大多数是美国企业）中参与了DW规划与实施的人员组成，受访者根据DW应用实际情况及经验体会做出回答。为了合理设计调查问卷，在调查问卷中合理设置调查对象（参与调查的DW架构）和评判标准（影响DW架构选择的因素及判断DW架构成功的因素等）等内容，Watson和Ariyachandra邀请了20位专家组成专家组设计调查问卷及判断标准等，这20位专家包括了DW领域的两位先驱——赫赫有名的Bill Inmon和Ralph Kimball。因此我们可以认为这份调查的结果是权威可信的。

可以

生产数据库升级是一个比较痛苦的工作。要升级到新的结构，还要保证原有的数据不受影响。

1）准备一个和生产数据库同一版本的模板数据库。如果可以直接拿到生产数据库的备份最好。如果不行，就自己产生一些模拟数据，最重要的是保证各种特征的数据都有，尽量保证所有的表都有数据。备份一份准备好的模板数据库，留待以后的测试。

2）安装新的软件，生成新的数据库。

3）利用工具比较两个数据库的schema，生成升级的脚本。这样工作手工做可能是非常恐怖的事。

4）分析和验证工具生成的升级脚本。主要工作是看看在字段发生改变的表里，数据的转换是否正确，增加字段的表里，添加的默认值是否合适。然后，逐段运行脚本，检查脚本运行是否能够通过，同时，转换是否正确。一定不要什么都不管，从头到尾运行。注意，经常存盘和备份，保证不丢失修改。

5）用一个干净的模板数据库，重新运行完整的脚本。用schem比较工具查看是否所有的修改都做好了。

6）如果没问题，使用数据库的数据比较工具，比较数据。主要两个工作，所有的配置数据和系统预置数据是否一致。已有的生产数据有没有被破坏。选择需要升级的部分数据，生成升级脚本。

7）利用升级脚本逐段测试，验证。

8）一次运行整个脚本，进行测试，验证。

9）重新用一个新的模板库，进行两个脚本的验证。

10）如果没有问题了，进行全面的功能测试。发现问题的时候，修改脚本重新测试。

一定要注意的问题：

1）数据库中的所有constraint一定要有名称。没有名称，数据安装的时候会自动生成一个带随机数ID的名字，只会造成每个机器的升级脚本都不一致。没有办法做标准的升级脚本。

2）如果使用SQL server，Redgate SQL toolbelt是一个很好用的比较工具。

3）把脚本分成schema升级和数据升级，会节约和多时间，提高脚本的可维护性。

4）一定要保证真正读懂了数据升级脚本。

目前国内外常用的金融数据库的主要优点是：商品化的数据库管理系统以关系型数据库为主导产品，技术比较成熟。

金融数据除了具有数据的一般特性外，还具有自身的一些特性：

（1）广泛性。由于金融机构在国民经济中处于特殊地位，它与全社会各个经济细胞和微观主体都有着密切的联系，因此必须面向全社会广泛获取数据，这就使得金融数据的涵盖范围非常广泛。

（2）综合性。金融数据作为国民经济的综合部门，直接面向国民经济各行各业，为全社会的各群体提供金融服务。通过这些服务尤其是资金服务，可以汇集起反映国民经济运行的综合数据，因此金融数据具有很强的综合性。

金融数据库分类：

按照金融业务活动划分，可以将金融数据分为银行业务数据、证券业务数据、保险业务数据以及信托、咨询等方面的数据，其中银行业务数据又包括信贷、会计、储蓄、结算、利率等方面的数据。

证券业务数据又包括行情、委托、成交、资金市场供求以及上市公司经营状态等方面的数据；保险业务数据又包括投保、理赔、投资等方面的数据。这些数据都从某一侧面反映了金融活动的特征、规律和运行状况。

IT 技术分析

当我们优化一个系统时 有时发现一种情况就是自己修改SQL 索引以及分区是不能解决性能问题的 这时你要考虑业务逻辑优化和表设计的重构 这两点的确和设计结合的很紧密

业务逻辑优化

结合实际 我们先谈谈业务逻辑优化

案例一

我们的系统一个文档模块 客户点击时很慢 通过性能分析 是点击是去查询数据库 这时系统是通过Hibernate来两步处理

计算该类型的文档数量总数

显示最新文档的前 篇文档

这时显示第二步的时间是很快的 只取 条记录 但是计算该类型的所有总数很慢 系统的这时的输入是很大的(计算该类型的全部文档 可能有几万篇数据) 输出就一条总数 这时因为业务逻辑复杂 即使建立索引 分区等等速度也是无法提高 因为不能真正做到索引覆盖和分区消除

客户是点一下要等十几秒是不能容忍的 这时可能输入数据量很大下 数据库很可能采用的是hash联结 而且并发用户一大 数据库服务器压力很大

这时常规的优化方法是没有效果的 这时我们也发现 客户其实对以前比较老的数据是不关心的 一般只是对近期的数据比较感兴趣 所有我们就在查询时默认设定半年的时间 然后在时间上设定聚集索引 并默认在此时间上排序 使其使用合并联结 减少输入数据量 结果速度有明显的提升

案例二

我们在优化一个客户系统时 碰到一种情况 在客户的一选择功能时 客户点击一下选择相关数据 这时页面要要几分钟才能出来 客户很不满意 这时修改sql和索引都没有办法 他的输入的数据量也很大 和上面一下也要计算总数和取最新前几条数据

这时我们在查询是关联了人员 通过调查 发现客户只对和自己相关的数据感兴趣 也只是查询自己相关的数据 所以这时在sql语句里增加用户id这条限制 同时在增加userid的索引 这样一来 速度就大大提高

总结

当然以上两个案例 是从输入入手 减少输入和输出的数据量 主要优化业务逻辑 达到优化系统 当然有些情况要和客户确认和说服他们 有时他们不一定都认可 这时要说明这样做的目的 相信他们也会理解

表设计优化

表设计 在我们开发系统时已经确定 好的设计的确能大大提高性能 我们在优化系统时 碰到一个比较麻烦的问题

原文 数据库重构(一) 字段合并

这条sql是判断 个维度 一个用户id 一个机构id 一个岗位id 还有级别判断和是否公共 sql语句里有 个 or 组成查询 表数据一大就表扫描 性能很差 但业务要求和系统要求这样判断 即使在表中这五个字段都建索引 速度也不会快 太多 OR 了 SQL Server 查询分析器无法优化

这时由于设计时 用户id 机构id 岗位id为 个只有一个有数据 所以将这 个字段合并 较少 Or 语句 让数据库能使用索引

总结

lishixinzhi/Article/program/SQL/201311/16321

以上就是关于哪种数据仓库架构最成功全部的内容，包括:哪种数据仓库架构最成功、业务生产系统数据库升级可以作业么、目前国内外常用的金融数据库的主要优点是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！