数据架构设计指导书
Company Document number：WUUT-WUUY-WBBGB-BWYTT-1982GT
数据架构设计指导书
（版本号）
朗新科技（中国）有限公司
2013年06月
更改履历
注：更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修改。
目录
1编写目的
为了提高数据架构设计能力、规范软件设计流程、加强架构管控力度，提高软件安全特制定本规范。此文档描述了数据架构设计等。
2适用范围
适用于数据架构设计人员。
3数据架构设计原则
数据资产化原则：将数据作为公司具有价值的无形资产来管理，统一认识，加强数据资产认责管理，保障数据资产的价值发挥。
数据共享性原则：避免数据孤岛的建设和数据私有化，加强数据在公司各级单位、各个业务领域间的共享。营造及时、准确的共享数据环境，完善数据管控机制，确保数据共享符合信息安全要求。
数据可用性原则：建立标准化、多样化的数据资产获取渠道和访问方式。加强数据质量管理，增强用户使用数据的信心，有效支撑各类分析应用建设。
数据认责原则：针对不同的数据资产指定权威的数据拥有者、质量责任者、日常管理维护者等角色，建立配套的数据管控机制和评价考核体系，确保数据认责工作的有效开展。
数据标准化原则：在公司全局范围内建立通用的数据标准，包括业务数据标准，主数据标准，元数据标准等，避免数据的二义性，促进数据共享和利用。
数据安全性原则：定义数据安全级别，建立数据安全控制过程，保证数据被合理的访问、共享和发布，避免未经授权的数据操作，满足监管单位和公司业务经营对数据安全的要求。
4数据架构设计
数据架构设计主要解决：存在哪些数据资源、如何管理数据资源、解析业务信息的数据模型是什么、面向交易、交换和分析的数据模型是什么、信息在流程间、数据在功能间如何流转等问题。
数据架构设计主要内容：数据主题域设计、概念数据模型设计、逻辑数据模型设计、物理数据模型设计等。
4.1企业业务数据分类
4.1.1按数据格式划分
结构化数据：方便用数据库的二维表结构来逻辑表达实现的数据，数据结构字段含义确定，清晰。例如：客户信息、用电记录等。是挖掘数据价值的主要对象。
非结构化数据：很难按照一个概念去处理的无结构性的数据。例如文本、多媒体数据等。其数据利用技术相对于结构化数据起步晚，是未来数据应用的一个发展方向。
4.1.2按数据参照程度划分
主数据：用于描述企业核心业务实体/对象的基本业务数据，它在企业内长期存在并且被重复应用于多个业务部门和信息系统，是最容易产生数据一致性问题的一类数据，需要单独的管控机制对其进行管理。
非主数据：相对于主数据，其它的参照度低的、存在周期短的非核心实体/对象数据可认为是非主数据。
4.1.3按数据采集频道划分
非实时数据：相对于实时数据，其它的企业经营过程中产生的，由业务人员通过应用系统输入的数据都可认为是非实时数据
实时数据：主要是由一些传感器设备以自动化的方式采集的秒级、毫秒级的数据，例如电网运行数据、设备状态数据等。这些数据的特点是数据内容简单，但数据量很大。
4.1.4按使用性质划分
分析性数据：用于支持日常报表、查询、分析等决策需求的数据。
共享数据：来自某个业务系统，在业务部门之间、业务系统之间重复使用的数据
4.2数据主题域
数据主题域由业务信息按照其业务耦合程度聚合而成的高阶数据主题群，一般与业务域有着紧密的对应关系。例如：财务、物资、生产等。
数据主题域通过数据主题域视图和数据主题域关系视图来体现。
4.2.1数据主题域视图
展现数据域和数据主题，并定义数据主题对业务域的支撑关系。例图如下：
4.2.2数据主题域关系视图
展现数据主题域之间的逻辑关系。一般分为一级数据主题域关系视图和二级数据主题域关系视图，二级是一级的细化。
一级数据主题域关系视图如下：
二级数据主题域关系视图如下：
4.3概念数据模型
4.4概念数据模型主要由最佳实践和业务需求作为驱动因素高阶的数据模型，定义了重要的业务领域概念（即数据主题域）和彼此的关系，由核心的数据实体或其集合，以及实体间的关联关系组成。概念数据模型独立于信息系统存在，不涉及信息在系统中的表示。
概念模型应该抓住一个重点，即表达重要业务概念及业务概念之间的关系；解决并只解决需要在全国范围内统一规范的核心的业务问题；只是反映了业务对数据的需求，包容多种物理实现方式，除非该种物理实现方式不满足业务的需求。
概念数据模型一般由概念数据模型视图和数据流转视图组成。
4.4.1概念模型视图
展现数据主题域之下的数据实体，并展现数据实体之间的关联关系。
4.4.2数据流转视图
展现数据实体所分布到的应用，并展示数据在应用间的流转。
例图如下：
4.5逻辑数据模型
逻辑数据模型对概念数据模型的进一步分解和细化，描述实体、属性以及实体关系，通用的字段类型、长度和主外键关系等做了定义，设计时一般遵从“第三范式”以达到最小的数据冗余。逻辑模型的设计由最佳实践和业务需求、数据资源规划、现有业务应用数据模型等作为驱动因素
逻辑数据模型由逻辑数据模型视图和数据分布视图组成
4.5.1逻辑数据模型视图
对数据实体的分解细化，对数据实体的属性、属性类型、长度和主外键关系等做了定义，遵从“第三范式”以达到最小的数据冗余。
4.5.2数据分布视图
展现数据实体所分布到的功能，并定义在功能中的操作（CRUD）
数据分布视图如下：
CRUD如下：
4.6物理数据模型
物理数据模型描述数据模型的细节，需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素，并对数据冗余与性能进行平衡，必须确定数据库平台和应用程序的架构。物理数据模型的设计由数据库/数据仓库系统平台和性能调整优化要求作为驱动因素。
4.6.1物理模型视图
描述数据模型的细节，需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素，并对数据冗余与性能进行平衡。
物理模型视图例图如下：
4.7数据库详细设计
4.7.1数据基础设计
数据库类型：Oracle
数据库SID：sqadb1、sqadb2
数据库名： sqldb
语言：AMERICAN_AMERICA
数据库字符集(NLS_CHARACTERSET)：UTF8
国家区域字符集(NLS_NCHAR_CHARACTERSET)：UTF8
4.7.2常用参数
NLS_LENGTH_SEMANTICS = CHAR
说明：此参数需要设置后重启方可生效。
4.7.3主要模式
设计规划数据库schemas，主要用于客户端或外部系统访问数据库。具体设计例子如下：
4.7.4表空间规划及存储容量估算
根据业务情况与各物理表设计字段长度，评估运行周期1年内产生的数据量。
4.7.5历史表
所有非档案数据表在系统设计之初就需要考滤历史数据的使用。历史表设计必须在需求分析阶段确定下来，并在数据模型设计得以体现。
在线数据保留在在线系统中的当前表中，保留业务经常使用的数据。历史数据保留在历史系统中的历史表中，保留当前业务不被使用的数据，将这部数据从在线系统中迁出可以在线系统库维持在稳定的大小，提高在线库的性能和可靠性，提高当前表中的查询速度。
对于有时间特征的流水业务数据必须进行归档，归档周期由具体业务需求决定。如果数据量巨大，可根据业务需求缩短归档时间周期。对于没有明显时间特征的旧数据，可按业务需要标准进行判断之后加以归档，如果数据状态、标识等，归档实体表中尽可能增加时间属性。
本系统中对于流程已走完的工单数据，在呼叫接入平台、呼叫服务业务支持系统数据库中，咨询、报修类数据保留3个月，其它数据保留6个月，咨询、报修类数据保留3个月以前的数据和其它６个月以前的数据将迁移历史库中。呼叫接入平台与呼叫服务业务支持系统共用同一个历史库。
历史表结构必须为时间分区结构（特殊情况除外），字段结构与在线表相同，历史表名与在线表名保持一致。
4.7.6表分区
尽可能不采用二级分区；
每个分区的记录数应对于数据量较大的表，为提高系统性能，方便业务数据管理必须进行相应的分区处理，分区策略可选择一级、二级分区，分区字段由相应的数据分布特征或业务需求来定。
1.分区的依据
记录数超过2000万的表需要考滤为该表做分区；
2.分区字段的选择
分区字段优先考滤最有可能作为查询条件的字段；
尽可能不要使用TIMESTAMP类型的字段，这在我们当前的营销业务的其它系统中最常出现，并且已经被证明，非常影响性能，如果需要这类字段作为分区条件，那么需要在表中添加一个新的字段，作为前面的TIMESTAMP类型的字段的冗余，字段类型为varchar2型，并以这个新的字段作为分区字段；
3.分区数量的考滤
表的分区数据不宜太多，以住在营销系统中我们常采用二级分区的方法，导致表的分区数据太多，一保持在100-500万之间；
4.禁止使用pmax分区
在创建分区表时不可以创建pmax分区，创建pmax分区将导致后续分区扩展变得非常困难，在营销系统中我们吃尽了这方面的苦头，不能再犯这类的错；
5.数据归档或迁移的考滤
表分区的创建还要充份考滤便于后续数据的归档和迁移，如某张表在线数据只保留6个月，归档表只保留6个月前至1年前之间的数据，历史表保留1
年以前的数据。那么在表分区规划时就要考滤这张表的数据归档迁移方式，要能以最快速度，最小代价，最低影响在线系统的方式将数据归当、迁移出去。
6.对于数据量巨大且无明显数据分布特征可采用HASH分区。
7.制定分区表需要开发设计与开发DBA共同讨论，分区命名遵循P+分区值的原则。子分区遵循P+主分区值+‘_’+P+子分区值的原则。
如：单位分区 P3340101、年月分区P201001、单位年月组合分区P
3340101_ P201001
注意：范围分区时分区名应大于分区值上界。
在总部系统中由于数据较小暂不考虑分区。
4.7.7DBLINK
由于目标客户使用的硬件资源各不相同，要求我们在设计之时，不得不考虑未来多种部署模式，多种部署模式中，有存在跨数据库访问的情况，因此规划数据链。注意：尽量不要使用DBLINK来访问外部数据库。
4.7.8同义词
引入同义词是为了解决程序部署灵活性的要求。将开发人员程序调整工作量降到最低的情况下，来满足程序的灵活部署。同意义与表同名
4.7.9主键
1.尽可能采用具有实际意义的列去创建主键；
2.如果需要采用多列来创建主键，那么列应控制在2个以内；
3.尽可能不采用序列去生成主键列值的方法，通过序列生成的列值，在我们应用中很少有实际用途，而且实践证明这种方法在极端情况下很容易引发性能问题；
4.7.10索引
对于表中常用于作为查询关键字、关联条件，且数据离散度较高的字段，必须创建索引。
原则上一张表的索引:
1、选择性较高的字段
2、作为数据访问条件与关联条件
4.7.11约束
本文所提及的约束通常只主键约束，系统中禁止利用数据库底层约束机制来处理或代替业务层面的业务数据一致性、完整性、规范性约束，包括使用触发器进行处理。
禁止ID字段及作为主键约束。
4.7.12修改标志时间戳
除业务中间表和过程表之外，每个表都须设计数据更新记录字段(DML_STAT)，比如“120918U”表示本条记录做过UPDATE操作。
4.7.13LOB字段
尽量弃用LOB字段定义，LOB字段在后续使用中非常不便，并且性能不佳。
4.7.14冗余字段设计
尽可增加表的冗余字段，从营销系统的运行情况来看，在没有冗余的情况下，查询某些记录需要关联更多的表，关联的表越多，SQL的执行计划就越差，引起争用的可能就越高。从营销系统的运行情况来看，在表缺少冗余的情况下，性能下降非常严重。
在本项目中，尽可能增加必要冗余字段的思想已在数模设计中一直灌输，因此数模设计中已有效实施了字段冗余，后续无需调整。