IT应用系统按照功能可以划分为交易系统与分析系统两大类，而数据库在两类系统中均起到极为重要的作用；交易系统的本质在于将流程化的人工处理自动化，以提升生产效率、降低错误率并简化管理的复杂度，其数据库一级应用的核心在于极高的稳定性、强大的处理能力以及巨大的吞吐能力；分析系统的本质在于对历史信息的统计、分析以及对未来业务的适当预测，以准确、全面地衡量企业的生产经营状况，指导企业战略的制定及业务的发展，其数据库一级应用的核心在于巨大的IO处理能力。
    目前商用的分析系统数据库产品主要有Teradata、DB2、Oracle等，并且以此为核心辅以ETL、METADATA、Ad_Hot Query、Report、OLAP、DM等功能共同构成了分析系统的基本框架，而核心数据库的系统模型及处理能力则是决定整个分析系统运行效率及运行状况的关键。
    不同数据库产品的架构及底层实现方式都不尽相同，但是作为分析系统的基本特征及性能要求则使得不同数据库作为分析系统时的系统设计方式及管理优化方法是统一的，这一点在Teradata的开发维护及Oracle的开发测试过程中深有体会。
    以下从两个方面谈谈对分析系统设计原则的看法。
    一、分析系统设计原则1——在系统一级尽量减少IO消耗并提升IO处理能力
    分析系统需要针对大量的历史信息进行统计分析，故而需要巨量的IO操作（中航信现有Teradata系统每日的总IO量为50T左右，高峰时达到1.2GB/s；Oracle测试过程单场景IO总量30T左右，高峰达到1.5BG/s；据悉近期Oracle在北美做的测试IO峰值达到40GB/s），因此合理的系统设计的重点在于尽可能的减少同样应用所消耗的IO量以及提升同样主机处理能力下磁盘的IO量。
    Teradata在数据仓库领域的领先地位来自于其具备核心技术的Bynet模块，其内置的数据重分布算法结合Teradata优秀的数据存储设置有效的减少了访问同样数据下磁盘的IO消耗；而其坚持采用小容量磁盘的策略也使得同样存储空间下Teradata较之其他商用数据库具备更强的IO处理能力；以上优势也使得Teradata在只有其他数据库平台几分之一的cpu及memory的情况下仍然具备最强劲的数据处理能力。
在硬件IO能力已经限定的前提下，如何减少同样应用的IO消耗成为提升分析系统性能的关键，在这一点上无论是Teradata还是Oracle都采用了同样的系统配置方案——压缩、分区、哈希关联；
    1）压缩：Teradata及Oracle的压缩方式不同，但是无疑都是额外消耗CPU的操作，压缩的主要作用一方面节省了存储空间（这对于动辄几TB以至几十TB的磁盘空间需求来说也是很大一笔投资），更重要的是减少了同样应用的IO消耗，这也成为无论Oracle还是Teradata作为数据仓库的必须选项。Teradata的压缩功能早已有之，新的V2R6版本更是对此功能进行了加强——Spool空间中的临时表也开始支持压缩技术；Oracle中的压缩功能更是从8i到11g每一个新版本都在不断加强，而在Oracle测试过程中，对基础表的压缩更是直接减少了一半的存储空间并极大的降低的系统的IO消耗。
    2）分区：分区是任何商用数据仓库的另一大法宝。数据仓库的基本特征使得其存储了数月甚至更长时间的历史数据，但是任何行业的分析性应用大部分并不需要基于所有历史数据，因此在SQL执行时如果能够仅针对大表中的有用部分进行，则可以极大的降低该SQL的IO消耗，而各类调优报告中展示的某某应用经调优后性能提升几十乃至数百倍，相当大部分是与分区相关的优化。在此功能上各大数据库厂商相差不大，但是此处任何厂商的弱微领先都会被拿来作为本产品强于其他数据库产品的重要特性之一。分区的好坏与业务应用密切相关，在Oracle测试中，分区相关的配置是Oracle调优专家放在第一位的工作，同时也是系统优化阶段最耗时的工作。基于中航信Teradata生产系统的测试也充分表明合理的分区带来的性能提升一般是以几倍来衡量的。
    3）哈希关联：与交易系统中的表相比，分析系统中的表大都具有海量条数（动辄数十亿条）及众多字段的特点，同时一条记录信息往往分散在十几个以至几十个表中，因此在各类应用中出现多个超大表之间的关联且关联条件不固定是极为常见的情况。在Oracle数据库中，多表关联有Sort Merge Join、Hash Join、Nested Loop Join等多种方式，无论从理论还是实际测试中都证明Hash Join的方式，特别是对表做了hash散列之后的Hash Join连接可以最大限度的减少表关联时的IO消耗量，是最适合分析系统海量数据处理的关联方式，因此在Oracle测试的过程中，表关联绝大部分采用Hash Join的方式进行，而且由于此种关联方式中索引不起作用，所以也使得测试过程基本没有建立索引。与此相对的是，Teradata系统的表关联只有Hash Join一种方式同时其数据存储也被强制采用Hash散列的方式进行；同时DB2在作为分析系统时与交易系统唯一的配置区别就在于数据的存储改为Hash散列存储模式。
    二、分析系统设计原则2——建立合适、合理的数据模型及处理方式
    任何运转良好的IT系统，其硬件性能总是处于一个相对富裕的状态，因此我们不能够奢求一套系统可以完成所有的交易及分析应用，而应该采用各类应用间松耦合而应用内部高内聚的系统建设方案。具体说来就是各类不同的交易应用尽可能通过中间件平台进行数据交换，而各自的业务处理由不同的独立系统完成；所有的交易系统数据通过中间件平台进入统一的数据存储区（ODS），然后ODS作为一个企业最完整一致的数据源为各类分析系统（数据仓库、分析性CRM、OLAP、DM等）提供数据；此处讲的建立合适、合理的数据模型及处理方式仅指由ODS开始的各类系统的设计。
    对于信息化程度较高的行业，由于交易数据的采集已经规范化并且相关性已经非常密切，所以可以实现ODS与DW的融合，以分区的方式存储长期历史数据，共同作为完整的数据容器为各类数据应用提供完整、一致的数据；根据行业数据应用的特点及企业管理方式的不同，各类专题应用可以直接在DW平台上完成，或者以独立数据集市的方式存在，这部分应用往往具备完备的行业标准并且已经产生出一定的经济效益。
OLAP为分析系统的关键应用，其数据直接来自于DW并且经过一定业务规则的处理，通过特定的服务器以为业务分析人员及企业管理人员提供全方位的生产经营分析支持；但是由于本类应用对使用人员的业务要求较高且需要较好的宽带支持，所以在国内大部分OLAP逐渐退化为报表应用，并且直接作用于DW，从而造成了众多DW系统的性能严重下降等弊病。
    业务经验丰富的分析人员，在DW上执行各类随机查询及数据处理任务，是分析系统中、高级应用的表现；此类应用需要大量的历史数据、丰富业务知识与敏锐分析能力的结合，是分析系统中最重要的应用，是新的行业分析及应用标准的摇篮；但是此类应用也是最有可能危害到整个分析系统性能乃至安全的，特别是在无效的管理下此部分应用会处于一个无序、低效的状态，且一旦沉淀在庞杂的分析系统内部后其负面影响会滚雪球式的变大，直至整个系统的大清理。
    分析系统数据库架构设计一方面与数据库类型相关，但更重要的是需要符合行业特点，只有建立适合行业业务要求的分析系统，才有可能为企业创造出价值。