企业数据模型设计方法论探讨Word文件下载.docx
《企业数据模型设计方法论探讨Word文件下载.docx》由会员分享，可在线阅读，更多相关《企业数据模型设计方法论探讨Word文件下载.docx（10页珍藏版）》请在冰豆网上搜索。
企业级数据模型定义
2.1
模型基本定义
企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企
业业务的视角，对企业全部数据（包括生产数据和消费数据）全貌性、整体性
描述。
企业级数据模型是业务人员和
IT
人员进行沟通的媒介、也是企业内部与
外部进行交流的纽带。
企业级数据模型是一种建设蓝图，它识别了企业内部跨功能、跨部门、跨
组织的共享或冗余数据，为系统的规划、设计和实施提供一种可视化方式和支
撑框架，是企业内部所有应用系统数据模型设计的起点，如
ODS、EDW
等系统的
设计开发，有助于促进数据整合、消除数据孤岛和遗留系统保持一致。
企业级数据模型是一个数据集成定义，它不依赖于企业内部某个具体的系
统或应用，也跟数据的物理实现无关（包括数据如何获取、如何存储、如何处
理以及如何访问）。
2.2
模型结构
企业级数据模型可分解为三个层级：
主题域模型、概念模型和逻辑模型。
三个层次模型逐级扩展。
企业级数据模型的创建更是一种艺术而非一门科学，
应集中企业的集体智慧，共同推进企业级数据模型的不断完善。
2.2.1
主题域模型
企业主题域模型在企业级数据模型中处于第一层次，其覆盖原则是“有需
求才覆盖”，一个企业的平均主题域数量通常在
10~20
之间。
Ø
主题域模型内涵
●
主题（Subject）是在较高层次上将企业的数据进行综合、归类和分
析利用的抽象概念，每一个主题通常对应一个宏观的业务分析领域。
主题域是对某个主题进行分析后确定的主题边界。
典型的主题域包
括参与人、产品、协议等。
主题域模型处于企业级数据模型的顶层，是针对企业关键业务领域、
业务概念的分类方法和框架。
主题域模型特征
看似简单的主题域模型实际上凝聚了企业内部中高层管理者的共识，
因而需要耗费较长时间进行充分的沟通和交流；
主题域模型的价值在于企业内部对业务的理解深度，以及体现企业
内部各方达成的协议。
2.2.2
概念模型
企业概念模型在企业级数据模型中处于第二层次，将每个主题域进一步细
分为“概念”，通常每个主题域包括
个“概念”。
企业概念模型由概念以
及概念之间的关联关系组成。
概念内涵
“概念”是对主题域、主题域范围的进一步定义和细化
；
“概念”描述了企业生产和消费的核心业务信息，独立于具体的实
现问题和细节
“概念”应基于企业的主要业务，应由企业主要业务驱动“概念”
定义；
“概念”的要点在于表现企业重要的业务视角，而不是数据量的大
小；
“概念”还需考虑行业的适用性，如包括供应商、合作伙伴以及外
部引用数据的概念。
概念模型特征
概念模型是一种高阶数据模型，以实体—关系（Entity-
RelationShip，简称
E-R）理论为基础，通过主题域形式描述概念化
的结构；
概念模型是对主题域模型的进一步细化。
概念模型定义了企业内主要业务实体及实体间的业务关系。
概念模型不描述业务实体的数据属性
实体之间可能存在多对多关系，不对数据进行范式化处理。
2.2.3
逻辑模型
企业逻辑模型在企业级数据模型中处于第三层次，并将每个概念进一步细
分为“逻辑实体”。
企业逻辑模型由逻辑实体、业务主键、关联关系和重要属性
组成。
逻辑模型特征
逻辑模型是对概念模型的进一步分解和细化
，通过关键数据属性描
述更多业务细节
逻辑模型描述实体、属性以及实体关系
逻辑模型只包含关键数据属性，而不是全部实体和全部属性。
关键
数据属性是指那些如果缺失而导致企业无法正常运转的属性，但这
种判断通常是非常主观的决定。
设计时一般遵从“第三范式”，以求达到最小的数据冗余，维护数据
的完整性和可扩展性
检查数据模型是否符合第三范式要求，有如下
三条检验标准：
✓
主键是唯一的，不具有多义性
。
每个非主属性必须完全依赖于整个主键，而非主键的一部分
关系模式中不存在传递依赖
逻辑模型独立于具体技术，是
人员和业务人员沟通的工具
2.3
企业级数据模型的业务价值
企业信息化建设的目的是通过运用信息化技术来提高企业的生产、运营效
率，降低运营风险和经营成本，从而增加企业盈利和持续经营的能力。
企业级
数据模型定义了企业信息化体系的数据标准，是企业内部各应用系统能够实现
相互协作、共享数据的前提，是企业信息化建设成功的必要条件，它的业务价
值体现在以下几个方面：
提升数据质量。
企业现有系统在与企业级数据模型映射过程中，能够暴
露系统之间数据的差异性、内在的冗余数据，可以将许多潜在的数据质
量问题在正式实施之前予以暴露、并解决。
理清数据所有权。
通过将跨业务、跨组织边界的企业数据之间的关联关
系、依赖关系进行识别、并文档化，企业级数据模型可以作为数据所有
权管理工具，支持“共享”数据所有权的概念。
增强系统的可扩展性。
企业级数据模型支持可扩展性的数据架构，基于
战略业务视角，独立于具体的技术实现，支持可扩展性。
能以很小的
变更代价适用不断变化的环境。
整合行业数据。
企业级数据模型吸收了企业外部视角，结合行业数据集
成框架，提高了企业的行业数据适用性，从而提升了企业共享行业公用
数据的能力，如客户、位置、供应商等基础数据。
企业也可以与相关行
业或合作伙伴共享数据。
整合套装应用软件。
通过将套装应用软件映射到企业级数据模型中，提
升了企业级数据模型在企业内部的匹配度，并能识别出套装应用软件和
遗留系统之间的集成点，通过打包产品提供一致性、高质量的数据流转
地图。
2.4
企业级数据模型与应用系统数据模型间关系
企业级数据模型是企业内部所有应用系统数据模型设计的起点。
企业级数
据模型与应用系统数据模型之间的关系表现在以下三个方面：
企业级数据模型是企业内所有应用系统的基础数据模型。
在构建企业数
据存储架构（ODS、DW、数据集市和应用）之前，首先要基于企业级数
据模型中的企业逻辑模型创建一个应用级逻辑模型，而该模型是企业逻
辑模型的子集，因此，企业逻辑模型是所有数据存储架构的基础模型。
数据架构框架。
企业级数据模型为企业数据设计和数据存储提供了一个
数据架构框架，以支撑数据质量、可扩展性和完整性。
业务数据需求和
数据源（遗留系统）为企业的数据设计提供“装修材料”。
这些“装修
材料”以属性的形式“填充”到企业逻辑模型框架中。
数据“粘合剂”。
企业级数据模型为企业提供了一个数据集成框架，
所有的应用级逻辑模型都可以被映射到企业逻辑模型中，企业级数据
模型就像“胶水”，将企业内部所有数据连接在一起，包括套装应用软
件。
3
企业级数据模型设计
3.1
模型设计方法
企业级数据模型设计可采用“业务需求驱动自顶向下”和“基于现状驱动
自底向上”相结合模式，参照业界参考模型、行业最佳实践，共同形成数据模
型。
从业务需求驱动入手自顶向下，参照业界参考模型、行业最佳实践搭建数
据模型整体框架
通过现状调研获取企业内部业务流程、设计文档、系统模型、接口规范等
现状信息，现状驱动自底向上，细化和完善数据模型的设计
3.2
模型设计要点
本文不讨论企业级数据模型设计的具体细节，只讨论建模过程中的关键步
骤和要点。
企业级数据模型设计总体可分为四个步骤：
前期准备、主题域模型
设计、概念模型设计、逻辑模型设计。
3.2.1
前期准备
在企业内部，涉及多个业务部门，对于一个业务问题通常会有多个不同的
观点和看法，每个相关人员需要理解和沟通各自的观点和看法。
为了阐明和沟
通我们的观点，我们需要理顺企业内部所有核心术语定义以及术语定义的关系，
形成一个精确的和公认的术语词典表。
因此，在构建企业级数据模型之前，需
要在企业范围内统一业务术语，在后续建模过程中给相关人员提供一个沟通的
基础。
3.2.2
主题域模型设计
主题域模型设计凝聚了企业内部中高层管理者的共识，是企业内部各方相
互妥协后达成的协议。
主题域模型设计过程中注意以下几个要点：
设计依据
设计依据来源于三个方面：
立足需求和现状、行业最佳实践和业界理论支
撑。
立足需求和现状。
基于企业业务整体发展的需求以及行业监管要求，
在企业范围内开展业务调研、信息调研获取企业的当前现状信息，
作为主题域模型设计的输入信息。
行业最佳实践。
借鉴国际、国内本行业相关企业的实践经验以及相
关工作成果。
了解相关企业在数据建模过程中所取得的成就和经验
教训，确保企业在建模过程中少走弯路。
业界理论支撑。
参考业界通用数据模型设计思路，推动业界参考模
型产品的客户化处理。
通常，每个行业都会有本行业的参考模型，
例如：
金融行业典型的参考模型包括
TD
FS-LDM
和
IBM
FSDM
模型；
通信行业典型参考模型包括
NGOSS-SID
模型。
关键要点
设计过程需要整个企业内部各个部门的广泛参与
，有助于形成合力、
达成共识。
业务专家的深度参与和亲临指导，有助于识别、理解组织架构和业
务功能；
主题域的定义和命名过程很重要，它有助于覆盖企业的重要业务主
题，避免重大遗漏；
主题域名称应该清晰、简洁、易于理解
3.2.3
概念模型设计
概念模型设计是从企业角度出发，采用“自上而下”的开发模式。
不局限
于某个特定业务领域或应用。
概念模型设计过程中注意以下几个要点：
两个关键步骤
识别各主题域下的关键实体，对关键实体再进行细分类。
识别关键实体及其分类之间的关联关系。
建立概念模型过程中必须得到业务领域专家和业务负责人的指导，
并由业务用户提供模型的应用需求。
模型设计师完成初步设计以后，需通过多轮会议，由业务领域专家、
相关主题域的专家验证本主题域概念是否符合要求；
会议过程中，概念模型初稿暴露出的概念重叠、冲突或其它关注的
问题都将应记录下来，由模型设计师继续调整模型，概念模型的最
终成稿通常需经历多轮迭代，迭代次数取决于概念模型的复杂程度
和发现问题的数量。
3.2.4
逻辑模型设计
逻辑模型基于概念模型进行扩展，包括扩充逻辑实体、提取关键数据属性、
业务规则、值域填充到逻辑模型当中，它是业务人员、IT
人员用来发现、记录
和沟通业务的详细“蓝图”。
逻辑模型设计过程中注意以下几个要点：
逻辑模型承载着企业数据标准。
通过逻辑模型中的实体、关键属性等可
以有效地承载数据标准的内容，并传递到应用系统模型设计中。
逻辑模型承载着业务数据规则。
基数规则。
定义与两个实体间关系相关的某个实体的实例数
量。
譬如下图表示“一个客户可以在银行有多个存款账号，最多有
一张白金理财卡”。
基数规则有“一对一、一对多、多对多”三种类
参照性规则。
为确保正确有效的数值所定义的规则。
譬如下
图表示“存款不能没有存款客户，必须要有一个存款人。
逻辑模型承载着企业数据质量规则，通过逻辑模型，可以了解数据质量
要求，提前数据质量的管控或检测，做到提前预防不合规的数据提交给
下游数据使用者
针对前页的业务数据规则，可以对系统中数据进行如下质量规则的
检查。
检查是否存在持有多张（大于
张）白金理财卡的客
户；
检查是否存在没有存款人的存款帐户存在。
结合逻辑模型中实体属性的域定义的格式、取值范围等，在系统模
型设计时继承该实体属性的质量检测管控，防止不合乎标准的数据
进入系统。
模型设计师创建逻辑模型的初始版本，通过工作会议的形式，由业
务领域专家进一步验证逻辑模型的完整性和准确性
逻辑模型的设计过程需要多轮迭代，迭代次数取决于实体概念的数
量、业务的复杂程度或者发现问题的数量。
4
心得体会与总结
本人先后参与了金融数据模型、征信数据模型等多个大型企业的数据模型
设计项目，具有扎实的理论基础和丰富的数据模型设计实践经验。
通过总结项
目期间的经验和教训，分享建模过程中的心得体会，希望对大家能有所帮助。
企业级数据模型设计应以“自顶向下”方法为主，应通过中高层访谈、
规划研读等方式，充分理解公司发展战略目标、业务规划和信息化规划，
以便站在企业整体业务视角上，洞察企业数据的全貌性和整体性；
在模型设计工作开始之前，应首先推动在企业范围内形成统一的业务术
语词典，统一业务术语定义，“磨刀不误砍柴工”，各部门业务人员有了
共同的沟通基础，在后续的模型设计工作中就可以起着事半功倍的效果；
主题域模型设计中，对于企业一级主题域的划分，并不是一定要按照本
企业的主营业务分类作为划分依据，而是从数据模型知识更容易传播、
共享的角度，参照本行业参考模型进行一级主题域划分，这样更利于吸
收企业外部视角、整合行业数据。
概念模型设计需要业务领域专家的深度参与和业务负责人的亲临指导，
模型成果才能紧贴企业实际需要，符合企业要求。
业界参考模型和行业
最佳实践，都只是参照物，业务需求才是模型设计工作的主要驱动力。
通过业务领域专家的深度参与，才能获知本企业在该业务领域最关注的
核心概念及分类，才能梳理出核心概念及分类之间的关联关系。
业务负
责人则是对设计成果的进一步完善和确认。
逻辑模型涉及到业务细节问题，同样离不开业务人员的深度参与。
需要
着重指出的是，逻辑模型是一种通用模型，模型设计师在面对大量的数
据库设计文档、系统模型、接口规范时，应根据设计经验提炼出所需要
的主要实体、关键属性、业务规则，以便对概念模型进行进一步细化和
分解。
过程比结果更重要。
通过建模工作，大家一起去讨论、交流和学习建模
方法论、业务知识，共同推进模型设计工作的完善和改进，这本身就比
模型交付结果更重要。
因为在这个过程中，员工得到了成长，彼此之间
增强了信任，为下一步的合作奠定基础。
企业级数据模型的建设不是一劳永逸的，需要持续不断的进行维护和改
进。
模型成果交付以后，并非静止不动，而是需要由专人持续不断的改
进和完善。
升级会员 