Oracle数据库统计应用的结构设计与维护技巧

【摘要】针对大型数据库应用系统在使用过程中保留的海量应用数据，文章基于oracle数据库，采用“分解范式”的方法设计统计表中包含了用户隶属关系的冗长数据，避免了历史信息存储与隶属关系实时变更产生的数据不一致问题，同时也阻止了非法用户、非法数据对数据库的破坏，进而使这些应用数据除了为应用系统服务之外，变成一种更为有用的新资源，提高了关系型数据库的效率。

【关键词】Oracle数据库；表结构设计；统计

1.引言

Oracle数据库是采用Internet计算模式的倡导者之一，在数据库领域一直处于领先地位，是世界上使用最为广泛的数据系统之一，具有兼容性、可移植性、可联结性、高生产率和开放性等特点。大型的应用系统往往要求面向企业或部门，以数据为中心组织数据，减少数据的冗余，提供更高的数据共享能力；同时要求程序和数据具有较高的独立性，当数据的逻辑结构改变时，不涉及数据的物理结构，也不影响应用程序，以降低应用程序研制与维护的费用。因此大型应用程序往往选择Oracle数据库作为存储应用数据的数据结构。事实证明，在处理海量数据、瞬间入库等方面，Oracle数据库成为众多大型关系型应用系统的首选。

2.需求分析

结合实例通过对比，解析数据库早期设计对统计应用的影响。应用程序产生的应用数据具有以下特点：

应用数据由用户产生；

用户按管理级别、管理层次分为两类用户：A类、B类。其中，A类分为数个大区；

每个大区包含数个单位；

每个单位包含数个用户；

应用过程中用户的隶属关系肯能发生改变（即可能在特定时间脱离原本隶属的单位、大区、甚至是类别，而改为隶属于其他单位、大区、类别；或者同时隶属于两个以上上级单位），应用过程中可能产生新的用户、单位、大区，但不会新增类别；

应用数据按时间标识依次入库；

应用数据按服务功能划分为三大功能：UseType1、UseType2、UseType3。

生成报表的需求：

查询当前用户总数；

查询当前使用总数；

按区域对比显示三大服务的使用次数、用户数；

按服务功能显示某大区内部单位的用户使用次数、用户数；

指定部分用户，显示三大服务的使用次数。

3.根据系统数据应用设计数据库模型

按照应用系统的要求，数据备案速度为首要考虑因素。按应用程序产生的原始格式，以最简化形式入库，简化了应用系统程序员的逻辑设计。如表1所示。

4.根据统计需求设计关系模型

考虑到按使用总量统计的因素，保留依赖用户标识的应用数据1、应用数据2等，便于按应用数据排序，并将应用产生的费用、质量评估回执等项吸纳入一个表中。如表2所示。

考虑到按用户总量统计的因素，将用户信息从应用数据备案表中提取出来作为一个独立的表。将其隶属关系分解出来。解决了历史信息存储与隶属关系实时变更产生的数据不一致问题。见表3。

按第二范式，将大区的描述提取出来作为一个独立的表。解决了大区描述信息实时变更产生的历史数据与现实数据不一致的问题。见表4。

按第三范式，将单位隶属关系及描述提取出来作为一个独立的表。解决了单位描述信息时变更产生的历史数据与现实数据不一致的问题，以及历史信息存储与隶属关系实时变更产生的数据不一致问题。见表5。

统计中按用户隶属类别分为两类，每类所包含区域在全国范围不超100个，划分应用数据备案表表名后缀编号，使得后缀编号为100～200的表名为A区、后缀编号为200～300的表名为B区。

统计中按应用数据所属服务功能分为三类，划分应用数据备案表表名第二后缀名称，使得第二后缀名称为服务功能名称缩写。

基于上述两项约定，将大区编号作为横坐标，服务类别作为纵坐标，即可确定大区内用户指定服务的应用情况，利用图表显示工具，基于单表，即可完成需求分析中的区域统计。

5.制定统计策略

根据应用数据所属服务功能建立三个统计过程中的第一过程临时表。见表6～表8。

这三个过程临时表由过程负责更新维护。有两个原因使得使用过程是能够获得性能益处。首先，复杂的业务规则的处理，可以放在数据库中并由服务器执行。在客户服务器或三级应用中，把复杂应用的处理，从应用（客户端）转移到数据库（服务器），可以极大地提高性能；其次，由于数据代码被存贮在数据库中且为静态，可以从重复使用数据库中的相同查询获益。系统全局区（SGA）中的共享SQL区储存可执行命令执行后的分析版本。从而当一个过程被再次执行时，它将能够利用上一次执行的分析操作来提高过程的执行性能。此外，借助于把业务规则集中到数据库中，可以在生成建立应用的过程中节省时间并简化维护过程。

过程1：count_1_temp_pro

以1为步进单位，遍历表名第2后缀为UseType的A区100个表，遍历表名第2后缀为UseType1的B区100个表，完成临时表UseType1的插入工作。同理插入UseType2、UseType3的两表数据。

5.1 大类统计

对区域统计表中大区号为100～200的各服务功能使用字段和服务功能用户总量字段加和得到A区按服务功能分类的统计；对区域统计表中大区号为200～300的各服务功能使用总量字段和服务功能用户总量字段加和得到B区按服务功能分类的统计。对大区数据的整体统计，即表的总数。所以不带条件的count比带条件的统计查询要快。

5.2 区域统计

建立区域统计临时表（见表9）：并初始化表中大区数据，使得包含200个大区初始信息。

基于过程1，建立过程2：count_2_UseType_pro

遍历第1过程三个临时表统计产生并更新统计数据到第2过程临时表。

该临时表以大区名称为横坐标、任意列为纵坐标，可以对比区域统计的数据完成需求分析中按区域对比显示三大服务的使用次数、用户数的功能。

5.3 单位统计

建立单位统计临时表（见表10）。

基于过程1，建立过程3：count_3_Unit_pro

遍历第1过程三个临时表统计产生并更新统计数据到第3过程临时表。完成需求分析中按服务功能显示某大区内部单位的用户使用次数、用户数的功能。

5.4 用户统计

指定部分用户，选取并统计过程1更新维护的临时表。之所以遍历过程1更新维护的临时表，而不遍历应用数据备案表，过程1更新维护的临时表面向对象为用户，而应用数据备案表面向对象为应用数据，对于用户的使用统计，前者的时间复杂度为n（用户数），后者的时间复杂度为n·m（使用总量）。即对指定的用户群进行统计，前者只需检索1遍1更新维护的临时表，而后者需对每一个指定用户执行1遍检索相同的应用数据备案表。

6.结束语

Oracle认可关系模型的精华和本质部分，甚至到了遵从Codd规则的程度，但同时它也提供了工具，允许开发者对规范化、引用完整性、过程语言访问、非集合面向的处理和其他异类技术作出自己的决策。在现实世界中，需考虑实际数据、实际用户和对性能与易于使用性的实际需求，Oracle的灵活性是成功的基础。

为了提高统计性能，本文利用一种有效途径，即“分解范式”的方法设计统计表中包含了用户隶属关系的冗长数据。当用户隶属关系发生变更时，在应用程序中维护隶属关系表中对应的用户信息，当插入数据时判定用户的隶属关系，如果产生了新的单位，则由应用程序负责将新单位的描述、单位隶属关系加入单位表中，这样做的好处是避免了历史信息存储与隶属关系实时变更产生的数据不一致问题，同时也阻止了非法用户、非法数据对数据库的破坏。合理设计表结构，与在表结构设计基础上开发的统计工具相结合，才能满足现实世界的需求，提高关系型数据库的效率。

参考文献

[1]王行言.Oracle数据库应用开发基础[M].北京：清华大学出版社，2003.

[2]腾永昌.Database Administration Oracle9i/10g数据库系统管理[M].北京：清华大学出版社，2005.

[3]George Koch，Kevin Loney.梅刚等译.Oracle8：The Complete Reference[M].北京：机械工业出版社，1998.

[4]Scott Urman.译友翻译组译.Oracle8 PL/SQL Progamming[M].北京：机械工业出版社，1998.