数据架构设计指导书
数据架构设计指导书
（版本号 V1.0）
朗新科技（中国）有限公司2013年06月
更改履历
版本号修改编
号
更改时间
更改的
图表和章
节号
更改简要
描述
更改
人
批准
人
V1.0 2013-6-15 王全
义郑德炳
注：更改人除形成初稿，以后每次修改在未批准确认前均需采用修订的方式进行修改。
..................................................
.............................................. 目录
1 编写目的333
2 适用范围333
3 数据架构设计原则 333
4 数据架构设计444
4.1 企业业务数据分类 444
4.1.1 按数据格式划分 (444)
4.1.2 按数据参照程度划分 (444)
4.1.3 按数据采集频道划分 (555)
4.1.4 按使用性质划分 (555)
4.2 数据主题域 555
4.2.1 数据主题域视图 (555)
4.2.2 数据主题域关系视图 (666)
4.3 概念数据模型概念数据模型主要由最佳实践和业务需求作为驱动因素高阶的数据模型，定义了重要的业务领域概念（即数据主题域）和彼此的关系，由核心的数据实体或其集合，以及实体间的关联关系组成。概念数据模型独立于信息系统存在，不涉及信息在系统中的表示。 777
4.3.1 概念模型视图 (888)
4.3.2 数据流转视图 (999)
4.4 逻辑数据模型101010
4.4.1 逻辑数据模型视图 (101010)
4.4.2 数据分布视图 (111111)
4.5 物理数据模型121212
4.5.1 物理模型视图 (131313)
4.6 数据库详细设计131313
4.6.1 数据基础设计 (131313)
4.6.2 常用参数 (141414)
4.6.3 主要模式 (141414)
4.6.4 表空间规划及存储容量估算 (141414)
4.6.5 历史表 (151515)
4.6.6 表分区 (161616)
4.6.7 DBLINK (181818)
4.6.8 同义词 (191919)
4.6.9 主键 (191919)
4.6.10 索引 (202020)
4.6.11 约束 (202020)
4.6.12 修改标志时间戳 (202020)
4.6.13 LOB字段 (202020)
4.6.14 冗余字段设计 (212121)
编写目的
为了提高数据架构设计能力、规范软件设计流程、加强架构管控力度，提高软件安全特制定本规范。此文档描述了数据架构设计等。
适用范围
适用于数据架构设计人员。
数据架构设计原则
数据资产化原则：将数据作为公司具有价值的无形资产来管理，统一认识，加强数据资产认责管理，保障数据资产的价值发挥。
数据共享性原则：避免数据孤岛的建设和数据私有化，加强数据在公司各级单位、各个业务领域间的共享。营造及时、准确的共享数据环境，完善数据管控机制，确保数据共享符合信息安全要求。
数据可用性原则：建立标准化、多样化的数据资产获取渠道和访问方式。加强数据质量管理，增强用户使用数据的信心，有效支撑各类分析应用建设。
数据认责原则：针对不同的数据资产指定权威的数据拥有者、质量责任者、日常管理维护者等角色，建立配套的数据管控机制和评价考核体系，确保数据认责工作的有效开展。
数据标准化原则：在公司全局范围内建立通用的数据标准，包括业务数据标准，主数据标准，元数据标准等，避免数据的二
义性，促进数据共享和利用。
数据安全性原则：定义数据安全级别，建立数据安全控制过程，保证数据被合理的访问、共享和发布，避免未经授权的数据操作，满足监管单位和公司业务经营对数据安全的要求。
数据架构设计
数据架构设计主要解决：存在哪些数据资源、如何管理数据资源、解析业务信息的数据模型是什么、面向交易、交换和分析的数据模型是什么、信息在流程间、数据在功能间如何流转等问题。
数据架构设计主要内容：数据主题域设计、概念数据模型设计、逻辑数据模型设计、物理数据模型设计等。
企业业务数据分类
按数据格式划分
结构化数据：方便用数据库的二维表结构来逻辑表达实现的数据，数据结构字段含义确定，清晰。例如：客户信息、用电记录等。是挖掘数据价值的主要对象。
非结构化数据：很难按照一个概念去处理的无结构性的数据。例如文本、多媒体数据等。其数据利用技术相对于结构化数据起步晚，是未来数据应用的一个发展方向。
按数据参照程度划分
主数据：用于描述企业核心业务实体/对象的基本业务数据，它在企业内长期存在并且被重复应用于多个业务部门和信息系
统，是最容易产生数据一致性问题的一类数据，需要单独的管控机制对其进行管理。
非主数据：相对于主数据，其它的参照度低的、存在周期短的非核心实体/对象数据可认为是非主数据。
按数据采集频道划分
非实时数据：相对于实时数据，其它的企业经营过程中产生的，由业务人员通过应用系统输入的数据都可认为是非实时数据实时数据：主要是由一些传感器设备以自动化的方式采集的秒级、毫秒级的数据，例如电网运行数据、设备状态数据等。这些数据的特点是数据内容简单，但数据量很大。
按使用性质划分
分析性数据：用于支持日常报表、查询、分析等决策需求的数据。
共享数据：来自某个业务系统，在业务部门之间、业务系统之间重复使用的数据
数据主题域
数据主题域由业务信息按照其业务耦合程度聚合而成的高阶数据主题群，一般与业务域有着紧密的对应关系。例如：财务、物资、生产等。
数据主题域通过数据主题域视图和数据主题域关系视图来体现。
数据主题域视图
展现数据域和数据主题，并定义数据主题对业务域的支撑关系。例图如下：
数据主题域关系视图
展现数据主题域之间的逻辑关系。一般分为一级数据主题域关系视图和二级数据主题域关系视图，二级是一级的细化。
一级数据主题域关系视图如下：
二级数据主题域关系视图如下：
客户档案
电动汽车运营
客户服务
营销账务
费用查询
重要客户服务能效管理
服务跟踪重要客户服务
互动服务
电能产品资产台账电池管理
电动汽车服务
物资配送
充值卡
充值卡配送
能效服务
网站服务
客户
物资资产
产品
概念数据模型
概念数据模型主要由最佳实践和业务需求作为驱动因素高阶的数据模型，定义了重要的业务领域概念（即数据主题域）和彼
此的关系，由核心的数据实体或其集合，以及实体间的关联关系组成。概念数据模型独立于信息系统存在，不涉及信息在系统中的表示。
概念模型应该抓住一个重点，即表达重要业务概念及业务概念之间的关系；解决并只解决需要在全国范围内统一规范的核心的业务问题；只是反映了业务对数据的需求，包容多种物理实现方式，除非该种物理实现方式不满足业务的需求。
概念数据模型一般由概念数据模型视图和数据流转视图组成。概念模型视图
展现数据主题域之下的数据实体，并展现数据实体之间的关联关系。
数据流转视图
展现数据实体所分布到的应用，并展示数据在应用间的流转。
例图如下：
业务应用服务
应用服务层
数据存储存-生产数据库
应用接口
省(市)公司
业务应用服务
应用服务层
应用接口
公司总部
ETL
公司总部供电服务品质评价应用省(市)公司供电服务品质评价应用ETL ETL
第三方系统
第三方系统
公司总部客服系统
95598智能互动网站
短信平台95598系统营销系统用电信息采集系统
生产管理系统
中间数据区
业务数据区
中间数据区
业务数据区
总部客服查询库总部客服报表库Group by
Group by
数据存储存-生产数据库
逻辑数据模型
逻辑数据模型对概念数据模型的进一步分解和细化，描述实体、属性以及实体关系，通用的字段类型、长度和主外键关系等做了定义，设计时一般遵从“第三范式”以达到最小的数据冗余。逻辑模型的设计由最佳实践和业务需求、数据资源规划、现有业务应用数据模型等作为驱动因素
逻辑数据模型由逻辑数据模型视图和数据分布视图组成 逻辑数据模型视图
对数据实体的分解细化，对数据实体的属性、属性类型、长度和主外键关系等做了定义，遵从“第三范式”以达到最小的数
据冗余。
数据分布视图
展现数据实体所分布到的功能，并定义在功能中的操作（CRUD）数据分布视图如下：
省（市）公司
结构化数据存储中间数据存储区业务数据存储区
非结构化数据存储
轻度汇总数据
流程数据（95598、业扩）分析指标数据
公司总部
分析指标数据
轻度汇总数据
95598流程数据各类文本式报告/报表各类知识类文档
指标数据
分析数据
因子数据
第三方调查数据
评价数据各类文本式报告/报表各类知识类文档
指标数据
分析数据
因子数据
第三方调查数据评价数据
CRUD 如下：
物理数据模型
物理数据模型描述数据模型的细节，需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素，并对数据冗余与性能进行平衡，必须确定数据库平台和应用程序的架构。物理数
据模型的设计由数据库/数据仓库系统平台和性能调整优化要求作为驱动因素。
物理模型视图
描述数据模型的细节，需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素，并对数据冗余与性能进行平衡。
物理模型视图例图如下：
数据库详细设计
数据基础设计
数据库类型：Oracle
数据库版本：11.2.0.3或11.2.0.4
数据库SID：sqadb1、sqadb2
数据库名： sqldb
语言：AMERICAN_AMERICA
数据库字符集(NLS_CHARACTERSET)：UTF8
国家区域字符集(NLS_NCHAR_CHARACTERSET)：UTF8
常用参数
NLS_LENGTH_SEMANTICS = CHAR
说明：此参数需要设置后重启方可生效。
主要模式
设计规划数据库schemas，主要用于客户端或外部系统访问数据库。具体设计例子如下：
模式
名英文
内容描
述
权限需求
对象类
型
默认空间
默认索
引表空
间
工作
流用户sotow
er
用于保
存工作
流数据
由普华提
供
由普华
提供
DATA_SOT
OWER
IDX_SOT
OWER
权
限、组织bpm
用于保
存权限
组织
由普华提
供
由普华
提供
DATA_BMP IDX_BPM
表空间规划及存储容量估算
根据业务情况与各物理表设计字段长度，评估运行周期1年内产生的数据量。
数据域数据表空容量估算索引表空间容量估算
间(GB)(GB)客户档案DATA_CUS70~280IDX_CUS105-420
服务体系/用能分析/营销市场/系统支持DATA_EESM
P
40IDX_ EESMP60
用能采集DATA_EIC7300IDX_EIC14600
工作流DATA_SOTO
WER 0.5IDX_SOTOWE
R
0.5
组织、权限DATA_BPM0.5IDX_BPM0.5
接口用户DATA_API0.5IDX_API0.5
历史表
所有非档案数据表在系统设计之初就需要考滤历史数据的使用。历史表设计必须在需求分析阶段确定下来，并在数据模型设计得以体现。
在线数据保留在在线系统中的当前表中，保留业务经常使用的数据。历史数据保留在历史系统中的历史表中，保留当前业务不被使用的数据，将这部数据从在线系统中迁出可以在线系统库维持在稳定的大小，提高在线库的性能和可靠性，提高当前表中的查询速度。
对于有时间特征的流水业务数据必须进行归档，归档周期由
具体业务需求决定。如果数据量巨大，可根据业务需求缩短归档时间周期。对于没有明显时间特征的旧数据，可按业务需要标准进行判断之后加以归档，如果数据状态、标识等，归档实体表中尽可能增加时间属性。
本系统中对于流程已走完的工单数据，在呼叫接入平台、呼叫服务业务支持系统数据库中，咨询、报修类数据保留3个月，其它数据保留6个月，咨询、报修类数据保留3个月以前的数据和其它６个月以前的数据将迁移历史库中。呼叫接入平台与呼叫服务业务支持系统共用同一个历史库。
历史表结构必须为时间分区结构（特殊情况除外），字段结构与在线表相同，历史表名与在线表名保持一致。
序号主题
域
历史
表实
体名
称
历史表表
名（与基
表表名相
同）
历史表分区方
案
历史表数模变
更需求
表分区
尽可能不采用二级分区；
每个分区的记录数应对于数据量较大的表，为提高系统性能，方便业务数据管理必须进行相应的分区处理，分区策略可选择一级、二级分区，分区字段由相应的数据分布特征或业务需求来定。
1.分区的依据
记录数超过2000万的表需要考滤为该表做分区；
2.分区字段的选择
分区字段优先考滤最有可能作为查询条件的字段；
尽可能不要使用TIMESTAMP类型的字段，这在我们当前的营销业务的其它系统中最常出现，并且已经被证明，非常影响性能，如果需要这类字段作为分区条件，那么需要在表中添加一个新的字段，作为前面的TIMESTAMP类型的字段的冗余，字段类型为varchar2型，并以这个新的字段作为分区字段；
3.分区数量的考滤
表的分区数据不宜太多，以住在营销系统中我们常采用二级分区的方法，导致表的分区数据太多，一保持在100-500万之间；
4.禁止使用pmax分区
在创建分区表时不可以创建pmax分区，创建pmax分区将导致后续分区扩展变得非常困难，在营销系统中我们吃尽了这方面的苦头，不能再犯这类的错；
5.数据归档或迁移的考滤
表分区的创建还要充份考滤便于后续数据的归档和迁移，如某张表在线数据只保留6个月，归档表只保留6个月前至1年前之间的数据，历史表保留1年以前的数据。那么在表分区规划时就要考滤这张表的数据归档迁移方式，要能以最快速度，最小代价，最低影响在线系统的方式将数据归当、迁移出去。