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

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

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
Oracle数据库统计应用结构设计与维护技巧

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

文档评论(0)

fangsheke66 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档