1.引言

  数据建模是发现、分析和确定数据需求的过程，用一种称为数据模型的精确形式表示和传递这些数据需求。建模过程中要求组织发现并记录数据组合的方式。数据常见的模式: 关系模式、多维模式、面向对象模式、 事实模式、时间序列模式和NoSQL模式。按照描述详细程度的不同，每种模式又可以分为3层模型：概念模型、逻辑模型和物理模型。每种模型都包含一系列组件，如实体、关系、事实、键和属性。

图5-1 语境关系图：数据建模和设计

1.1 业务驱动因素

  数据模型对于有效的数据管理至关重要，如：

• 1）提供有关数据的通用词汇表。
• 2）获取、记录组织内数据和系统的详细信息。
• 3）在项目中作为主要的交流沟通工具。
• 4）提供了应用定制、整合，甚至替换的起点

1.2 目标和原则

   数据建模的目标是确认和记录不同视角对数据需求的理解，从而使应用程序与当前和未来的业务需求更加紧密地结合起来，并为成功完成广泛的数据应用和管理活动奠定基础，如主数据管理和数据治理计划。数据模型是元数据的一种重要形式。确认和记录不同视角的理解有助于：

• 1. 格式化
  • 数据模型是对数据结构和数据关系的简洁定义。
  • 能够评估当前或者理想情况下业务规则对数据的影响情况。
  • 格式化的定义赋予数据规范的结构，减少在访问和保存数据时发生异常的概率。
• 2. 范围定义
  • 数据模型可以帮助解释数据上下文的边界，以及购买的应用程序包、项目、方案或实施的现有系统。
• 3. 知识保留记录
  • 数据模型通过以书面的形式获取知识来保存系统或项目的企业信息。
  • 数据模型可被重复利用，可以帮助业务专业人员、项目经理、分析师、建模师和开发人员了解环境中的数 据结构。

1.3 基本概念

1.3.1 数据建模和数据模型

  数据建模最常用在系统开发与系统维护的工作环境中，也称为系统开发生命周期(SDLC)。数据建模可以用于更广泛的领域(如业务和数据架构、主数据管理和数据治理计划)，其直接的结果不是在数据库，而是对组织数据的理解。

  模型是现实中事物的一种表征或者想要创造事物的一种模式。一个模型可以包含一个或多个图表。模型图可以使人们通过标准化的符号快速领会其内容。数据模型描述了组织已经理解或者未来需要的数据。 数据模型包含一组带有文本标签的符号，这些符号试图以可视化方式展现数据需求并将其传递给数据建模人员，以获得一组特别的数据。这些数据大小不一，小到仅可以用于一个项目，大到可以用于整个组织。模型是一种文档形式，用于记录数据需求和建模过程产生的数据定义。数据模型是用来将数据需求从业务传递到IT，以及在IT内部从分析师、建模师和架构师到数据库设计人员和开发人员的主要媒介。

1.3.2 建模的数据类型

  在任何既定组织中适合于建模的数据类型反映了组织或项目需要数据模型的优先级。可以对下列4种主要类型的数据进行建模:

• 1. 类别信息（Category Information）。用于对事物进行分类和分配事物类型的数据。eg: 按颜色分类、型号、大小分类的产品。
• 2. 资源信息（Resource Information）。实施操作流程所需资源的基本数据。eg: 产品、客户、供应商等。在IT专业人员定义中，资源实体有时被称为参考数据。
• 3. 业务事件信息（Business Event Information）。在操作过程中创建的数据。eg: 客户订单、供应商发票、现金提取和业务会议等。在IT专业人员定义中，事件实体有时被称为交易性业务数据。
• 4. 详细交易信息（Detail Transaction Information）。详细的交易信息可以通过销售系统（商店或在线应用）、社交媒体系统、其他互联网那个交互以及机器上的传感器生成。

1.3.3 数据模型组件

  不同类型的数据模型采用不同的约定符号来表示数据。大多数数据模型包含的组件: 实体、关系、属性和域。

① 实体

  在数据建模概念里，实体是一个组织收集信息的载体。一个实体可以被认为是一些基本问题的答案——谁、什么、何时、何地、为什么、怎么办或这些问题的综合。表5-1定义并给出了常用实体类别的例子。

表5-1 常用的实体类别

分类	定义	示例
谁(who)	相关的人或者组织。即业务对谁重要? "谁"通常泛指的一个参与者或角色。例如:客户或供应商。人员或组织可以有多个角色, 也可以包含在多个参与方中	员工, 病人,玩家,嫌疑人,供应商,学生
什么(what)	为相关企业提供服务。它通常指的是组织的产出或提供的服务。即为什么对企业是重要的? 类别, 类型等属性非常重要	产品,服务,原料,成品,课程,歌曲,照片
何时(when)	和企业相关的的日历或时间间隔。即什么时候经营	日期,月,季度,年,学期,财政周期,分钟,出发时间
何地(where)	企业相关的地点。地点可以指实际的地方或者电子场所, 即业务在哪里进行	网址,IP地址,发货地址
为什么(why)	企业相关的事件或者交易。这些事件使业务得以维持, 即业务什么要运行	下订单,退货,投诉,取款,存款,表扬,查询,贸易,索赔
怎么办(how)	和企业相关的事件记录。这些事件提供事件发生的证据, 如记录订单事件的购买订单, 即如何知道事件发生了	发货单,合同,协议,账户,购买单,装箱单,贸易确认书
度量(measurement)	关于时间、地点和对象的技术、总和等	销售数量,项目数,付款金额,余额

• 1. 实体的别名 通用术语“实体”可以使用其他名称表示。最常见的是使用“实体类型”代表一类事物。Jane是Employee类型, Jane是实体，Employee是实体类型。普遍的表示方法: “实体”表示Employee，用“实体实例”（Entity Instance）表示Jane。实体实例是特定实体的具体化或取值。
  表5-2 实体、实体类型和实体实例

  用法	实体	实体类型	实体实例
  常识用法	Jane	Employee
  推荐用法	Employee		Jane

  实体别名（Entity Aliases）也会根据模型抽象程度不同而有所不同。概念模型中的实体称为概念(Concept)或术语(Term)，逻辑模型中的实体被称为实体(Entity), 物理模型中实体的称为表(Table)。

• 2. 实体的图形表示

  在数据模型中，通常采用矩形（或带有圆边的矩形）代表实体，矩形的中间是实体的名称，如图5-2所示。图中有三个实体：学生(Student)、课程(Course) 和讲师 (Instructor)。

• 3. 实体的定义

  实体的定义具备3个基本特征: 清晰（Clarity）、准确（Accuracy）、完整（Completeness）。

② 关系

  关系（Relationship）是实体之间的关联（Chen，1976）。关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互以及物理实体之间的约束。

• 1. 关系的别名

  关系的别名（Relationship Aliases）根据模型不同而变化。关系别名也可以根据模型抽象程度而有所不同。在概念和逻辑级别上的关系就被称 为“关系”，但是在物理级别上的关系可能会采用其他名称表示，如“约 束”或“引用”等，这主要取决于具体的数据库技术。

• 2. 关系的图形表示

  关系在数据建模图上通常显示为线条。图5-3是一个用信息工程法表示关系的示例。
  

  学生（Student）和课程（Course）之间的关系描述了学生可以参加课程的规则。讲师（Instructor）和课程（Course）之间的关系描述了讲师可以教授课程的规则。线上的符号（称为基数）以精确的语法说明了规则。关系通过关系数据库中的外键来表示，在非关系型数据库中通过边界或链接来表示。

• 3. 关系的基数

  在两个实体之间的关系中，基数（Cardinality）说明了一个实体（实体实例）和其他实体参与建立关系的数量。 基数由出现在关系线两端的符号表示。数据规则是通过基数指定来强制执行的。对于基数而言，只能选择0、1或多（“多”的意思是超过“1”个）。关系的每一方都可以有0、1或多的任意组合。指定0或1表示关系中是否需要实体实例。1个或多个表示给定关系中参与的实例数量。在图5-3中可以看出学生与课程之间的业务规则为:

  • 1. 每名学生可以选择一门或者多门课程
  • 2. 每门课程可以被一名或者多名学生选择
  • 3. 关系的元数(关系中涉及实体的数量) 常见的有一元关系、二元关系以及三元关系
• 4. 外键

  外键（Foreign Key）通常用在物理数据建模中表示关系，在逻辑数据建模中，有时也用这种方法表示关系。如图5-9所示。注册(Registration)包含两个外键: 学生(Student) 的学号(Student Number)和课程(Course)的课程编号(Course Code)。外键体现在关系中的“多”的一边的实体，即子实体中。学生(Student) 和课程(Course)为父实体, 注册(Registration)为子实体。

图5-9 外键

③ 属性

  属性（Attribute）是一种定义、描述或度量实体某方面的性质。实体中属性的物理展现为表、视图、文档、图形或文件中的列、字段、标记或节点等。

• 1. 属性的图形表示

  在数据模型中，属性通常在实体矩形内的列表中描述, 在图 5-9 中, 其中实体学生(Student) 的属性包含 学号(Student Number)、姓(Student First Name)、名(Student Last Name)、生日(Student Birth Date)。

• 2. 标识符

  标识符（Identifiers）也称为键，是唯一标识实体实例的一个或多个属性的集合。根据键的结构(单一键、组合键、复合键、代理键)和功能(候选键、主键、备用键)分类。

④ 域

  在数据建模中，域（Domain）代表某一属性可被赋予的全部可能取值。域提供了一种将属性特征标准化的方法。eg: 日期域，包含了所有可能的日期，可以适用于任何逻辑数据模型或是物理数据模型中日期属性, 如: 聘用员工的日期、收到订单的日期、提交声明的日期、课程开始的日期。

• 域中所有的值都为有效的值, 不在域中的值被称为无效的值。可以用附加的规则对域进行限制，这些限制规则被称为约束。
• 域定义的方式: 数据类型(Data Type)、数据格式(Data Format)、列表(List)、范围(Range)、基于规则(Rule-Based)。

1.3.4 数据建模的方法

  常见的6种数据建模方法是关系建模、维度建模、面向对象建模、基于事实建模、基于时间建模和非关系型建模。

表5-2 建模方法和表示法

建模方法	表示法
关系(Relational)	信息工程(IE)、信息建模集成定义(IDEF1X)、巴克符号(Barker Notation)、陈氏符号(Chen)
维度(Dimensional)	维度(Dimensional)
面向对象(Object-Oriented)	统一建模语言(UML)
基于事实(Fact-Based)	对象角色建模(ORM2)、完全面向交流的信息建模(FCO-IM)
基于时间(Time-Based)	数据拱顶模型(Data Vault)、锚建模(Anchor Modeling)
非关系(No-SQL)	文档(Document)、列(Column)、图(Grpah)、键值(Key-Value)

1.关系建模(ER建模)

  关系模型设计的目的是精确地表达业务数据，消除冗余。最常见的是信息工程法，该方法采用三叉线（俗称“鸭掌模型”）来表示基数。

2.维度建模

  在维度模型中，数据组织的方式是为了优化海量数据的查询和分析。与此对应的是，操作型系统支持事务的处理，为优化单个事务快速处理而生。维度数据模型专注于特定业务流程的业务问题，图5-13中展示的是用维度模型分析招生情况。

图5-12 维度模型的轴表示法

  根据学生所在的区域(Zone)、学校名称(School)、学期(Semester)以及学生是否接受财政资助(Financial Aid)来查看招生信息。导航可以从一个区域(Zone)上升到地区(Region)和国家(Country)，从学期(Semester)上升到学年(Year)，从学校名称(Name)上升到学校等级(Level)。关系和维度数据模型都基于同样的业务过程,不同点在于关系代表的含义不同。在关系模型中，关系连线表示业务规则; 而在维度模型中，实体之间的连线表示用于说明业务问题的导航路径。

• 事实表 事实表中的行对应于特定的数值型度量值, eg 金额、交易量以及个数等。
• 维度表 维度表主要包含文字描述, 事实表的入口点或者链接, 通常高度反范式, 占总数据的10%。
• 雪花模型与星型模型(以雪花和星星的图形去理解)
• 粒度 事实表中单行数据的含义或描述
• 一致性维度 基于整个组织考虑构建
• 一致性事实 跨多个数据集市的标准化术语

3.面向对象

  统一建模语言（UML）是一种图形风格的建模语言。UML根据数据库的不同有着不同种类的表示法（类模型）。下图体现了UML类模型的特点：

• 1）与ER图相似，但ER中没有操作（Operation）或方法部分。
• 2）在ER图中，与操作最为接近概念的是存储过程。
• 3）属性类型（如日期、分钟）是用程序编程语言的数据类型表示的，而不是物理数据库数据类型来表示。
• 4）默认值可以在符号中有选择的显示。
• 5）访问数据是通过类的公开接口。

4.基于事实

  基于事实的模型不使用属性，通过表示对象（实体和值）之间的精确关系来减少直观或专家判断的需求。

5.基于时间

  当数据值必须按照时间顺序与特定时间值相关联时，需要用到基于时间的建模(Time-Based)。

6.非关系型数据库

  非关系型数据库（NoSQL）是基于非关系技术构建的数据库的统称。

1.3.5 数据模型级别

  1975年，美国国家标准协会的标准规划与需求委员会(SPARC)发布了数据库管理的三重模式是： 概念模式(Conceptual) 、 外模式(External) 、内模式(Internal)。在具体的项目中, 概念数据建模和逻辑数据建模是需求规划和分析活动的一部分，而物理数据建模属于设计活动。

1) 概念数据模型(CDM)

• 用一系列相关主题域的集合来描述概要数据需求。

• 概念数据模型包含: 给定的领域和职能中基础和关键的业务实体, 实体与实体之间关系的描述

• 下面是关系建模与维度建模中的概念数据模型

每所学校(School)有若干个学生(Student)，每个学生只来自一所学校。此外，每个学生可提交若干个申请(Application)，每一个申请只能由一个学生提交。

2) 逻辑数据模型(LDM)

• 详细描述数据需求, 通常用于支持特定用法的语境中（如应用需求）。

• 逻辑数据模型不受任何技术或特定实施条件的约束。

• 逻辑数据模型通常是从概念数据模型扩展而来。

• 在关系逻辑数据模型中，通过添加属性来扩展概念数据模型。属性通过应用规范化技术被分配给实体，如图5-20所示。每个属性和它所在实体的主键之间都有非常强的关系。
  

• 关系型逻辑数据模型捕获业务流程的规则，而维度型逻辑数据模型捕获业务问题以确定业务流程的运行状况和性能。
  

  ​

3) 物理数据模型(PDM)

• 描述了一种详细的技术解决方案，通常以逻辑数据模型为基础，与某一类系统硬件、软件和网络工具相匹配。

• 由于物理数据模型受实现技术约束，因此常常通过对结构进行组合(逆范式化)来提高检索性能，类似上面例子中的学生和学校。
  

4) 其他概念

• 规范模型 物理模型的一个变种，用于描述系统之间的数据移动。该模型描述了在系统之间作为数据报或消息传递的数据结构。
• 视图
  • 虚拟表, 提供了一种从多张包含或引用实际属性的表中查看数据的方法。
  • 实例化(通常称为“物化”)视图在预定的时间运行。
  • 视图用于简化查询、控制数据访问和重命名列，而不会由于逆规范化而导致引用完整性的冗余和丢失。
• 分区
  • 分区（Partitioning）是指拆分表的过程。
  • 执行分区是为了方便存档和提高检索性能。
  • 分区可以是垂直的(按列分组)，也可以是水平的(按行分组)。
• 逆规范化
  • 将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。
  • 逆规范化有意将一个属性放在多个位置。
  • 逆规范化目的是提高性能。

1.3.6 规范化

  规范化 (Normalization) 是运用规则将复杂的业务转化为规范的数据结构的过程。范式化的基本目标是保证每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性。

• 规范化规则根据主键和外键整理属性。
• 每个级别由一个独立的范式组成，并且每个相继级别不需要包含以前的级别。范式的层次包括：第一范式（1NF）、2）第二范式（2NF）、3）第三范式（3NF）、4）Boyce / Codd范式（BCNF）、5）第四范式（4NF）、6）第五范式（5NF）。

1.3.7 抽象化

  抽象化（Abstraction）就是将细节移除，这样可以在更广泛的情况下扩展适用性，同时保留概念或主题的重要和本质属性。抽象包括泛化(Generalization)和特化(Specialization)。泛化将实体的公共属性和关系分组为超类(Supertype)实体，而特化将实体中的区分属性分离为子类(Subtype)实体。

2.活动

2.1 规划数据建模

  数据建模工作交付成果包括以下4个方面内容：图表（Diagram）、定义（Definitions）、争议和悬而未决的问题（Issues and Outstanding Questions）、血缘关系（Lineage）。

2.1.1 图表

  一个数据模型包含若干个图表，图表是一种以精确的方式描述需求的形式。需求可以描述不同详细程度的层级(如概念、逻辑或物理模型)、采用的数据模型(关系、维度、对象、基于 事实的、基于时间的或NoSQL)，以及实例中采用的表示方法(如信息工程、统一建模语言、对象角色建模等)。

2.1.2 定义

  实体、属性和关系的定义对于维护数据模型的精度至关重要

2.1.3 争议和悬而未决的问题

  通常数据建模工作交付的文档应包含当前的议题和未解决的问题。例如，对于一个学生模型而言，比较突出的问题可能是：如果一个学生 离开学校后又返回，那么这种情况是为他分配新的学号，还是保留原来的学号？

2.1.4 血缘关系

  血缘关系是指数据从哪里来，经过什么样的加工，变成了什么样的结果的脉络关系。一般而言，血缘关系会以来源/目标映射的形式呈现，这样就可以了解到源系统的属性以及它们如何被迁移至目标系统。血缘关系还可以在同一建模过程中，追踪数据模型层级。

2.2 建立数据模型

  在建模过程中，首先要研究现有的数据模型和数据库，参考已发布的建模标准和数据标准，搜集和考虑随时提出新的数据要求，在此基础上建模人员设计数据模型初稿；然后再与业务专家和业务分析师确认及讨论模型设计是否符合业务规则要求，同时提出修改建议；最后由建模人员进行修改。如此反复进行，直至没有任何问题为止。

2.2.1 正向工程

  正向工程是指从需求开始构建新应用程序的过程。

2.2.1.1 概念数据模型建模

创建概念数据模型建模涉及的以下步骤:

2.2.1.2 逻辑数据模型建模

  逻辑数据模型补充了概念模型的需求细节。

2.2.1.2 物理数据模型建模

  逻辑数据模型需要进行修改和调整以形成物理数据模型，并使得最终的设计在存储应用程序中运行良好。

2.2.2 逆向工程

  逆向工程是记录现有数据库的过程。物理数据建模通常是第一步，以了解现有系统的技术设计；逻辑数据建模是第二步，以记录现有系统满足业务的解决方案；概念数据建模是第三步，用于记录现有系统中的范围和关键术语。

2.3 审核数据模型

  通过持续改进实践来控制模型质量, 诸如价值实现时间、支持成本和数据模型质量验证器(如数据模型记分卡)等技术都可用于评估模型的正确性、完整性和一致性。

2.4 维护数据模型

  数据模型需要保持最新的状态。需求或业务流程发生变化时，都需要对数据模型进行更新。

3.工具

3.1 数据建模工具

  数据建模工具是自动实现数据建模功能的软件。更复杂的数据建模工具支持从概念模型到逻辑模型，从逻辑模 型到物理模型，从物理模型到数据库结构转换的正向工程，允许生成数据库数据定义语言（DDL）。大多数还支持从数据库到概念模型的逆向 工程。

3.2 数据血缘工具

  数据血缘工具是允许捕获和维护数据模型上每个属性的源结构变化的工具。通过数据血缘工具查看一个系统的变化或系统的一部分中的变化是否对另一个系统产生影响。例如，属性总销售额可能来自多个应用程序，需要计算才能填充—血缘工具将存储此信息。

3.3 数据分析工具

  数据分析工具可以帮助探索数据内容，根据当前的元数据进行验证、识别数据质量和现有数据工件（如逻辑和物理模型、DDL和模型描述）的缺陷。

3.4 元数据资料库

  元数据资料库是一款软件工具，用于存储有关数据模型的描述性信息，包括图表和附带的文本（如定义）以及通过其他工具和流程（软件开发工具、BPM工具、系统目录等）导入的元数据。

3.5 数据模型模式

  数据模型模式是可重复使用的模型结构，可以在很多场景下被广泛应用。有组件、套件和整合数据模型模式。

• 基本模式（Elementary Pattern）是数据建模的“螺母和螺栓”。它们包括解决多对多关系和构建自引用层次结构的方法。
• 套件模式（Assembly Pattern）是指跨越业务人员和数据建模人员范畴的一套构建块。
• 整合模式（Integration Pattern）提供了以常见方式整合套件模式的框架。

3.6 行业数据模型

  行业数据模型是为整个行业预建的数据模型，包括医疗保健、电信、保险、银行、制造业等行业。任何购买的数据模型都需要进行定制以适应组织的特点，因为它是根据其他组织的需求进行设计的。

4.方法

4.1 命名约定的最佳实践

  ISO11179元数据注册是一种表示组织中元数据的国际标准，包含与数据标准相关的几个部分，包括命名属性和编写定义。数据建模和数据库设计标准是有效满足业务数据需求的指导原则，它们符合企业架构和数据架构的要求，以确保数据质量标准。名称应该是唯一的并且尽可能具有描述性。命名标准应该尽量减少跨环境的名称变化。名称不应受其特定环境影响，如测试、QA或生产环境。分类词（Class Word），即数量、名称和代码等属性名称中的最后一个术语，可用于从表名中区分实体和列名的属性。物理名称必须符合DBMS允许的最 大长度，因此必要时将使用缩写。逻辑名称通常情况下不允许使用任何的分隔符对单词进行分隔，但物理名称通常使用下划线作为单词分隔 符。

4.2 数据库设计中的最佳实践

  在设计和构建数据库时，DBA应牢记以下PRISM设计原则：1）性能和易用性、2）可重用性、 3）完整性、4）安全性、5）可维护性

5.数据建模和设计治理

5.1 数据建模和设计质量管理

5.1.1 开发数据建模和设计标准

  数据建模和数据库设计标准提供了满足业务数据需求、符合企业和数据架构标准以及确保数据质量的指导原则。数据建模和数据库设计标准应包括以下内容：

• 1）标准数据建模和数据库设计可交付成果的列表和描述。
• 2）适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表。
• 3）所有数据模型对象的标准命名格式列表，包括属性和分类词。
• 4）用于创建和维护这些可交付成果的标准方法的列表和说明。
• 5）数据建模和数据库设计角色和职责的列表和描述。
• 6）数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据。
• 7）元数据质量期望和要求。
• 8）如何使用数据建模工具的指南。
• 9）准备和领导设计评审的指南。
• 10）数据模型版本控制指南。
• 11）禁止或需要避免的事项列表。

5.1.2 评审数据模型以及数据库设计质量

  项目团队应对概念数据模型、逻辑数据模型和物理数据库设计进行需求评审和设计评审。审查会议的议程应包括审查启动模型（如有）的 项目、对模型所做的更改、考虑和拒绝的任何其他选项以及新模型在多大程度上符合现有的建模或架构标准。如果审查没有通过，建模人员必须通过修改以解决评审小组提出的所有问题。如果存在建模人员无法自行解决的问题，应该将问题反馈给系统所有者并寻求最终解决办法。

5.1.3 管理数据模型版本与集成

对数据模型的每个变更都应该予以记录，包括：

• 1）为什么（Why）项目或情况需要变更。
• 2）变更对象（What）以及如何（How）更改，包括添加了哪些 表，修改或删除了哪些列等。
• 3）变更批准的时间（When）以及将此变更应用于模型的时间（不一定在系统中实施更改）。
• 4）谁（Who）做出了变更。
• 5）进行变更的位置（Where）在哪些模型中。

5.2 度量指标

使用数据模型计分卡，提供了对模型质量的总体评估方法，并明确指出了针对模型的改进方案。

表5-4 数据模型计分卡

序号	类别	总分数	模型分数	%	注释
1	模型多大程度上反映了业务需求	15
2	模型的完整性如何	15
3	模型与模式的匹配度是多少	10
4	模型的结构如何	15
5	模型的通用性如何	10
6	模型遵循命名标准的情况如何	5
7	模型的可读性如何	5
8	模型的定义如何	10
9	模型与企业数据架构的一致性如何	5
10	与元数据的匹配程度如何	10
	总分	100

  “模型分数”列包含评审员对特定模型满足评分标准的评估，最高分数是总分数列中显示的值。例如，评审人员可能会在“模型多大程度上 反映了业务需求”这一项打10分。“百分比”列显示该项得分占该项总分 数的比例。例如，改下模型得10分，该百分比列的值为 66.7%（10/15）。注释列应记录更详细解释分数的信息或记录修复模型所需的操作项。最后一行包含该模型获得的总分数，即每行的总和。各个类别的简要描述如下：

• 1）模型多大程度上反映了业务需求？要确保数据模型代表需求。
• 2）模型的完整性如何？这里的完整性具有两个方面的要求：需求的完整性和元数据的完整性。
• 3）模型与模式的匹配度是多少？确保正在审查模型的具象级别和模型与该类型模型的定义相匹配。
• 4）模型的结构如何？验证用于构建模型的设计实践，以确保最终可以从数据模型构建数据库。
• 5）模型的通用性如何？评审模型的扩展性或者抽象程度。
• 6）模型遵循命名标准的情况如何？确保数据模型采用正确且一致的命名标准。
• 7）模型的可读性如何？确保数据模型易于阅读。
• 8）模型的定义如何？确保定义清晰、完整和准确。
• 9）模型与企业数据架构的一致性如何？确认数据模型中的结构能否在更加广泛和一致的环境中应用，以便在组织中可以使用一套统一的术语和模型结构。
• 10）与元数据的匹配程度如何？确认存储在模型结构中的数据和实际数据是一致的。

6.总结

• 数据建模的定义: 发现、分析和确定数据需求的过程, 用数据模型的精确形式表示和传递这些数据需求。常见6中数据模型: 关系模式、多维模式、面向对象模式、事实模式、时间序列模式、NoSQL模式。根据描述详细成都不同, 分为: 概念模型、逻辑模型以及物理模型。
• 业务驱动因素: 1) 提供有关数据的通用词汇表 2) 获取、记录组织内数据和系统的详细信息。 3）在项目中作为主要的交流沟通工具。4）提供了应用定制、整合，甚至替换的起点。
• 数据建模与设计的目标: 确认并记录不同视角对需求的理解, 确保应用程序更符合当前和未来业务的业务需求, 为更多数据应用或数据管理奠定基础, 例如主数据管理和数据治理项目。
• 数据建模与设计的活动: 1. 规划数据建模 2.建立数据模型(概念、逻辑、物理模型) 3.审核数据模型 4.维护数据模型
• 输入: 现有的数据模型和数据库。数据标准、数据集、初始数据需求、原始数据需求、数据架构、企业分类法。交付成果: 概念、逻辑、物理数据模型。
• 方法: 命名规范、数据库设计规范、数据库类型选择。
• 工具: 数据建模工具、数据血缘工具、数据分析工具、元数据资料库、数据模型模式(基本模式、套件模式、整合模式)、行业数据模型。
• 度量指标: 数据模型校验指标。
• 不同视角理解数据的好处:
  • 1) 格式化 简洁定义, 规范结构, 防止异常
  • 2) 范围定义 帮助解释数据上下文的边界
  • 3) 知识保留记录 为未来提供原始记录, 助于更好的理解组织等, 助于理解变更带来的影响。
  • 数据建模(系统开发生命周期(SDLC))的直接结果在于对数据的理解。数据模型是现实中事物的一种表征或者想要创造事物的一种模式。数据模型描述了组织已经理解或者未来需要的数据。
• 数据建模的数据类型: 1) 类别信息(类别数据, eg:颜色) 2) 资源信息(参考数据) 3) 业务事件信息(交易性业务数据 eg:客户订单) 4) 详细交易信息(明细数据,可用来聚合计算)
• 数据模型组件: 实体、关系、属性、域
• 实体(Entity): 在数据建模里, 实体是一个组织收集信息的载体。
  • 名词: 谁、什么、何时、何地、为什么、怎么办、度量, 一般用矩形代表, 矩形中间是实体名称。
  • 实体别名因模型类型不同而不同: 关系模型-实体, 维度模型-维度和事实表; 概念模型-概念/术语, 逻辑模型-实体, 物理模型-表
  • 实体的定义具有清晰、准确、完整三个特征。
• 关系(Relationship): 实体之间的关联。
  • 关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互、物理实体之间的约束。
  • 关系在维度模型中使用“导航路径”，在概念和逻辑级别上用“关系”，在物理上使用“约束“、”引用“。 关系在数据建模图上表现为线条。
  • 关系基数: 表明一个实体与其他实体参与建立关系的数量。有“0、1、多”。
  • 关系元数: 关系中涉及实体的数目。一元关系、二元关系、三元关系。
• 属性: 定义、描述或度量实体某个方面的性质。属性可能包含域。
• 域: 某一属性可被赋予的全部可能取值。
  • 域中所有的值都为有效的值。不在域中的值被称为无效的值。属性中不应当含有其指定的域以外的值。
• 建模方法: 关系建模、维度建模、面向对象建模、基于事实建模、基于时间建模和非关系型建模。
• 关系模型设计的目的 精确的表达业务数据，消除冗余。常见的是 信息工程法
• 维度建模为了优化海量数据的查询和分析。
• 事实表：事实表中的行对应于特定的数值型度量值，如金额。
• 维度表：表示业务的重要对象，主要包含文字描述。
• 数据模型的级别: 1 概念模型 2 外模式 3 内模式
• 概念数据模型(CDM) 用一系列相关主题域的集合来描述概要数据需求。概念数据模型仅包括给定的领域和职能中基础和关键的业务实体，同时也给出实体和实体之间关系的描述。
• 逻辑数据模型(LDM) 对数据需求的详细描述，通常用于支持特定用法的语境中（如应用需求）。
• 物理数据模型(PDM) 描述一种详细的技术解决方案，通常以逻辑模型为基础，与某一类硬件、软件和网络工具相匹配，与特定的技术有关。
• 逆规范化: 将符合范式规则的逻辑数据模型经过慎重考虑后，转换成一些带冗余数据的物理表。逆规范化的原因:
  • ① 提前组合来自多个其他表的数据，以避免代价高昂的运行时连接。
  • ② 创建更小的、预先过滤的数据副本，以减少昂贵的运行时计算和/或大型表的扫描。
  • ③ 预先计算和存储昂贵的数据计算结果，以避免运行时系统资源竞争。
• 规范化: 运用规则将复杂的业务转化为规范的数据结构的过程。目标是保证每个属性只在一个位置出现，以消除冗余或冗余导致的不一致性。常见的范式: 第一范式 、第二范式、第三范式。
• 数据建模活动
  • 【活动 1】规划数据建模 交付物 : 图表、定义、争议和悬而未决的问题、血缘关系
  • 【活动 2】建立数据模型
    • 正向工程(概念-逻辑-物理), 逆向工程(物理-逻辑-概念) 数据建模是一个不断迭代的过程。
    • 概念建模: 1.选择模型类型 --> 2.选择表示方法 --> 3.完成初始概念模型 --> 4.收集组织中最高级的概念(名词) --> 5.收集与这些概念有关的活动(动词) --> 6.合并企业术语 --> 7.获取签署
    • 逻辑建模: 1.分析信息需求 --> 2.分析现有文档 --> 3.添加关联实体 --> 4. 添加属性 – > 5.指定域 --> 6.指定键
    • 物理建模: 1. 解决逻辑抽象 --> 2. 添加属性细节 --> 3. 添加参考数据 --> 4. 指定代理键 --> 5.逆规范化 --> 6. 建立索引 --> 7. 分区 --> 8. 创建视图
  • 【活动 3】审核数据模型 通过技术手段评估模型的正确性、完整性、一致性。
  • 【活动 4】维护数据模型 保持模型处于最新状态
• 工具: 数据建模工具、数据血缘工具、数据分析工具、元数据资料库、数据模型模式、行业数据模型。
• 方法:
  • 1. 命令约定的最佳实践
    • 名称应该是唯一的并且尽可能具有描述性。
    • 逻辑名称对业务用户应具有意义，应尽可能使用完整的单词
    • 物理名称符合 DBMS 允许的长度，必要时使用缩写。
  • 2. 数据库设计中的最佳实践-PRISM设计原则
    • 性能和易用性、可重用性、完整性、安全性、可维护性
• 数据建模和设计质量管理 数据模型和数据库设计应是组织短期需求和长期需求之间的合理平衡。
• 管理数据模型版本与集成： 需要以时间线记录变更内容，每个变更都应记录，包括：Why/What/How/When/Who/Where。
• 度量指标：使用数据模型计分卡，提供了对模型质量的总体评估方法，并明确指出了针对模型的改进方案。