ImageVerifierCode 换一换
格式:DOCX , 页数:18 ,大小:907.99KB ,
资源ID:238744      下载积分:15 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/238744.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(数据架构设计指导书.docx)为本站会员(b****1)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

数据架构设计指导书.docx

1、数据架构设计指导书(版本号 V1.0)朗新科技(中国)有限公司2013年06月更改履历版本号修改编号更改时间更改的图表和章节号更改简要描述更改人批准人V1.02013-6-15王全义郑德炳注:更改人除形成初稿,以后每次修改在未批准确认前均需采用修订的方式进行修改。数据架构设计指导书目录1编写目的32适用范围33数据架构设计原则34数据架构设计34.1企业业务数据分类44.1.1按数据格式划分44.1.2按数据参照程度划分44.1.3按数据采集频道划分44.1.4按使用性质划分44.2数据主题域54.2.1数据主题域视图54.2.2数据主题域关系视图64.3概念数据模型 概念数据模型主要由最佳实

2、践和业务需求作为驱动因素高阶的数据模型,定义了重要的业务领域概念(即数据主题域)和彼此的关系,由核心的数据实体或其集合,以及实体间的关联关系组成。概念数据模型独立于信息系统存在,不涉及信息在系统中的表示。74.3.1概念模型视图74.3.2数据流转视图84.4逻辑数据模型84.4.1逻辑数据模型视图84.4.2数据分布视图94.5物理数据模型104.5.1物理模型视图104.6数据库详细设计114.6.1数据基础设计114.6.2常用参数114.6.3主要模式114.6.4表空间规划及存储容量估算124.6.5历史表124.6.6表分区134.6.7DBLINK144.6.8同义词144.6.

3、9主键144.6.10索引154.6.11约束154.6.12修改标志时间戳154.6.13LOB字段154.6.14冗余字段设计15161 编写目的为了提高数据架构设计能力、规范软件设计流程、加强架构管控力度,提高软件安全特制定本规范。此文档描述了数据架构设计等。2 适用范围适用于数据架构设计人员。3 数据架构设计原则数据资产化原则:将数据作为公司具有价值的无形资产来管理,统一认识,加强数据资产认责管理,保障数据资产的价值发挥。数据共享性原则:避免数据孤岛的建设和数据私有化,加强数据在公司各级单位、各个业务领域间的共享。营造及时、准确的共享数据环境,完善数据管控机制,确保数据共享符合信息安全

4、要求。数据可用性原则:建立标准化、多样化的数据资产获取渠道和访问方式。加强数据质量管理,增强用户使用数据的信心,有效支撑各类分析应用建设。数据认责原则:针对不同的数据资产指定权威的数据拥有者、质量责任者、日常管理维护者等角色,建立配套的数据管控机制和评价考核体系,确保数据认责工作的有效开展。数据标准化原则:在公司全局范围内建立通用的数据标准,包括业务数据标准,主数据标准,元数据标准等,避免数据的二义性,促进数据共享和利用。数据安全性原则:定义数据安全级别,建立数据安全控制过程,保证数据被合理的访问、共享和发布,避免未经授权的数据操作,满足监管单位和公司业务经营对数据安全的要求。4 数据架构设计

5、数据架构设计主要解决:存在哪些数据资源、如何管理数据资源、解析业务信息的数据模型是什么、面向交易、交换和分析的数据模型是什么、信息在流程间、数据在功能间如何流转等问题。数据架构设计主要内容:数据主题域设计、概念数据模型设计、逻辑数据模型设计、物理数据模型设计等。4.1 企业业务数据分类4.1.1 按数据格式划分结构化数据:方便用数据库的二维表结构来逻辑表达实现的数据,数据结构字段含义确定,清晰。例如:客户信息、用电记录等。是挖掘数据价值的主要对象。非结构化数据:很难按照一个概念去处理的无结构性的数据。例如文本、多媒体数据等。其数据利用技术相对于结构化数据起步晚,是未来数据应用的一个发展方向。4

6、.1.2 按数据参照程度划分主数据:用于描述企业核心业务实体/对象的基本业务数据,它在企业内长期存在并且被重复应用于多个业务部门和信息系统,是最容易产生数据一致性问题的一类数据,需要单独的管控机制对其进行管理。非主数据:相对于主数据,其它的参照度低的、存在周期短的非核心实体/对象数据可认为是非主数据。4.1.3 按数据采集频道划分非实时数据:相对于实时数据,其它的企业经营过程中产生的,由业务人员通过应用系统输入的数据都可认为是非实时数据实时数据:主要是由一些传感器设备以自动化的方式采集的秒级、毫秒级的数据,例如电网运行数据、设备状态数据等。这些数据的特点是数据内容简单,但数据量很大。4.1.4

7、 按使用性质划分分析性数据:用于支持日常报表、查询、分析等决策需求的数据。共享数据:来自某个业务系统,在业务部门之间、业务系统之间重复使用的数据4.2 数据主题域数据主题域由业务信息按照其业务耦合程度聚合而成的高阶数据主题群,一般与业务域有着紧密的对应关系。例如:财务、物资、生产等。数据主题域通过数据主题域视图和数据主题域关系视图来体现。4.2.1 数据主题域视图展现数据域和数据主题,并定义数据主题对业务域的支撑关系。例图如下:4.2.2 数据主题域关系视图展现数据主题域之间的逻辑关系。一般分为一级数据主题域关系视图和二级数据主题域关系视图,二级是一级的细化。一级数据主题域关系视图如下:二级数

8、据主题域关系视图如下:4.3 概念数据模型 概念数据模型主要由最佳实践和业务需求作为驱动因素高阶的数据模型,定义了重要的业务领域概念(即数据主题域)和彼此的关系,由核心的数据实体或其集合,以及实体间的关联关系组成。概念数据模型独立于信息系统存在,不涉及信息在系统中的表示。概念模型应该抓住一个重点,即表达重要业务概念及业务概念之间的关系;解决并只解决需要在全国范围内统一规范的核心的业务问题;只是反映了业务对数据的需求,包容多种物理实现方式,除非该种物理实现方式不满足业务的需求。概念数据模型一般由概念数据模型视图和数据流转视图组成。4.3.1 概念模型视图展现数据主题域之下的数据实体,并展现数据实

9、体之间的关联关系。4.3.2 数据流转视图展现数据实体所分布到的应用,并展示数据在应用间的流转。例图如下:4.4 逻辑数据模型逻辑数据模型对概念数据模型的进一步分解和细化,描述实体、属性以及实体关系,通用的字段类型、长度和主外键关系等做了定义,设计时一般遵从“第三范式”以达到最小的数据冗余。逻辑模型的设计由最佳实践和业务需求、数据资源规划、现有业务应用数据模型等作为驱动因素逻辑数据模型由逻辑数据模型视图和数据分布视图组成4.4.1 逻辑数据模型视图对数据实体的分解细化,对数据实体的属性、属性类型、长度和主外键关系等做了定义,遵从“第三范式”以达到最小的数据冗余。 4.4.2 数据分布视图展现数

10、据实体所分布到的功能,并定义在功能中的操作(CRUD) 数据分布视图如下:CRUD如下:4.5 物理数据模型物理数据模型描述数据模型的细节,需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素,并对数据冗余与性能进行平衡,必须确定数据库平台和应用程序的架构。物理数据模型的设计由数据库/数据仓库系统平台和性能调整优化要求作为驱动因素。4.5.1 物理模型视图描述数据模型的细节,需要考虑所使用的数据库产品、对应的字段类型、长度、索引等因素,并对数据冗余与性能进行平衡。 物理模型视图例图如下:4.6 数据库详细设计4.6.1 数据基础设计数据库类型:Oracle数据库版本:11.2.0.3或

11、11.2.0.4数据库SID:sqadb1、sqadb2数据库名: sqldb语言:AMERICAN_AMERICA数据库字符集(NLS_CHARACTERSET):UTF8国家区域字符集(NLS_NCHAR_CHARACTERSET):UTF84.6.2 常用参数NLS_LENGTH_SEMANTICS = CHAR说明:此参数需要设置后重启方可生效。4.6.3 主要模式设计规划数据库schemas,主要用于客户端或外部系统访问数据库。具体设计例子如下: 模式名英文内容描述权限需求对象类型默认空间默认索引表空间工作流用户sotower用于保存工作流数据由普华提供由普华提供DATA_SOTOW

12、ERIDX_SOTOWER权限、组织bpm用于保存权限组织由普华提供由普华提供DATA_BMPIDX_BPM4.6.4 表空间规划及存储容量估算根据业务情况与各物理表设计字段长度,评估运行周期1年内产生的数据量。数据域数据表空间容量估算(GB)索引表空间容量估算(GB)客户档案DATA_CUS70280IDX_CUS105-420服务体系/用能分析/营销市场/系统支持DATA_EESMP40IDX_ EESMP60用能采集DATA_EIC7300IDX_EIC14600工作流DATA_SOTOWER0.5IDX_SOTOWER0.5组织、权限DATA_BPM0.5IDX_BPM0.5接口用户D

13、ATA_API0.5IDX_API0.54.6.5 历史表所有非档案数据表在系统设计之初就需要考滤历史数据的使用。历史表设计必须在需求分析阶段确定下来,并在数据模型设计得以体现。在线数据保留在在线系统中的当前表中,保留业务经常使用的数据。历史数据保留在历史系统中的历史表中,保留当前业务不被使用的数据,将这部数据从在线系统中迁出可以在线系统库维持在稳定的大小,提高在线库的性能和可靠性,提高当前表中的查询速度。对于有时间特征的流水业务数据必须进行归档,归档周期由具体业务需求决定。如果数据量巨大,可根据业务需求缩短归档时间周期。对于没有明显时间特征的旧数据,可按业务需要标准进行判断之后加以归档,如果数据状态、标识等,归档实体表中尽可能增加时间属性。本系统中对于流程已走完的工单数据,在呼叫接入平台、呼叫服务业务支持系统数据库中,咨询、报修类数据保留3个月,其它数据保留6个月,咨询、报修类数据保留3个月以前的数据和其它个月以前的数据将迁移历史库中。呼叫接入平台与呼叫服务业务支持系统共用同一个历史库。历史表结构必须为时间分区结构(特殊情况除外),字段结构与在线表相同,历史表名与在线表名保持一致。序号主题域历史表实体名称历史表表名(与基表表名相同)历史表分区方案历史表数模变更需求4.6.6 表分区尽可能不

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1