读DAMA数据管理知识体系指南12数据设计

1. 工具

1.1. 数据建模工具

• 1.1.1. 自动实现数据建模功能的软件

• 1.1.2. 入门级数据建模工具提供基本的绘图功能，以便用户可以轻松创建实体和关系，如数据建模托盘

• 1.1.3. 大多数还支持从数据库到概念模型的逆向工程

• 1.1.4. 更复杂的工具通常支持诸如命名标准验证、拼写检查、存储元数据的位置（如定义和血缘）以及共享（如发布到Web）等功能

1.2. 数据血缘工具

• 1.2.1. 允许捕获和维护数据模型上每个属性的源结构变化的工具

• 1.2.2. 通过这些工具可实现变更影响分析，也就是说，可以使用它们来查看一个系统的变化或系统的一部分中的变化是否对另一个系统产生影响

• 1.2.3. 在数据建模工具、元数据资料库或数据集成工具中也经常获取数据的血缘

1.3. 数据分析工具

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

1.4. 元数据资料库

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

• 1.4.2. 元数据资料库本身应该启用元数据集成和交换

  • 1.4.2.1. 共享元数据比存储元数据更为重要

• 1.4.3. 元数据资料库必须具有便于用户访问的方式，供人们查询存储库的内容

• 1.4.4. 数据建模工具通常自带一个功能有限的资料库

1.5. 数据模型模式

• 1.5.1. 数据模型模式是可重复使用的模型结构，可以在很多场景下被广泛应用

• 1.5.2. 基本模式(Elementary Pattern)是数据建模的“螺母和螺栓"

  • 1.5.2.1. 包括解决多对多关系和构建自引用层次结构的方法

• 1.5.3. 套件模式(Assembly Pattern)是指跨越业务人员和数据建模人员范畴的一套构建块

  • 1.5.3.1. 业务人员可以理解它们——资产、文档、人员和组织等

• 1.5.4. 整合模式(Integration Pattern)提供了以常见方式整合套件模式的框架

1.6. 行业数据模型

• 1.6.1. 行业数据模型是为整个行业预建的数据模型，包括医疗保健、电信、保险、银行、制造业等行业

• 1.6.2. 任何购买的数据模型都需要进行定制以适应组织的特点，因为它是根据其他组织的需求进行设计的

2. 命名约定的最佳实践

2.1. ISO11179元数据注册是一种表示组织中元数据的国际标准，包含与数据标准相关的几个部分，包括命名属性和编写定义

2.2. 数据建模和数据库设计标准是有效满足业务数据需求的指导原则，它们符合企业架构和数据架构的要求​，以确保数据质量标准

2.3. 对每种类型建模对象和数据库对象发布数据模型和数据库命名标准

2.4. 名称应该是唯一的并且尽可能具有描述性

2.5. 逻辑名称对业务用户应具有意义，应尽可能使用完整的单词，并避免使用除最熟悉的缩写之外的单词

• 2.5.1. 逻辑名称通常情况下不允许使用任何的分隔符对单词进行分

2.6. 物理名称必须符合DBMS允许的最大长度，因此必要时将使用缩写

• 2.6.1. 物理名称通常使用下划线作为单词分隔符

2.7. 分类词(Class Word)，即数量、名称和代码等属性名称中的最后一个术语，可用于从表名中区分实体和列名的属性

3. 数据库设计中的最佳实践

3.1. 性能和易用性(Performance and Ease of Use)

• 3.1.1. 确保用户可快速、轻松地访问数据，从而最大限度地提高应用程序和数据的业务价值

3.2. 可重用性(Reusability)

• 3.2.1. 应确保数据库结构在适当的情况下，能够被多个应用重复使用，并且可用于多种目的

• 3.2.2. 避免将数据库、数据结构或数据对象耦合到单个应用程序中

3.3. 完整性(Integrity)

• 3.3.1. 无论语境如何，数据应始终具有有效的业务含义和价值，并且应始终反映业务的有效状态

3.4. 安全性(Security)

• 3.4.1. 应始终及时向授权用户提供真实准确的数据，且仅限授权用户使用

• 3.4.2. 必须满足所有利益相关方（包括客户、业务合作伙伴和政府监管机构）的隐私要求

3.5. 可维护性(Maintainability)

• 3.5.1. 确保创建、存储、维护、使用和处置数据的成本不超过其对组织的价值，以能够产生价值的成本方式执行所有数据工作

• 3.5.2. 确保尽可能快速地响应业务流程和新业务需求的变化

4. 开发数据建模和设计标准

4.1. 数据分析人员和设计人员作为信息消费者（具有数据业务需求的人）和数据生产者之间的中介，他们必须平衡信息消费者的数据使用要求和数据生产者的应用要求

4.2. 数据专业人员还必须平衡短期商业利益和长期商业利益的关系

4.3. 数据模型和数据库设计应该是企业短期需求和长期需求之间的合理平衡

4.4. 标准数据建模和数据库设计可交付成果的列表和描

4.5. 适用于所有数据模型对象的标准名称、可接受的缩写和非常用单词的缩写规则列表

4.6. 所有数据模型对象的标准命名格式列表，包括属性和分类词

4.7. 用于创建和维护这些可交付成果的标准方法的列表和说明

4.8. 数据建模和数据库设计角色和职责的列表和描述

4.9. 数据建模和数据库设计中捕获的所有元数据属性的列表和描述，包括业务元数据和技术元数据

4.10. 元数据质量期望和要求

4.11. 如何使用数据建模工具的指南

4.12. 准备和领导设计评审的指南

4.13. 数据模型版本控制指南

4.14. 禁止或需要避免的事项列表

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

5.1. 项目团队应对概念数据模型、逻辑数据模型和物理数据库设计进行需求评审和设计评审

5.2. 组建具有不同背景、技能、期望和意见的不同领域的专家小组对数据模型和数据库设计进行评审

5.3. 参与者必须能够讨论不同的观点，并最终达成小组共识，不存在任何个人冲突，因为所有参与者都有共同的目标，即推广最实用、表现最好、最可用的设计

5.4. 如果审查没有通过，建模人员必须通过修改以解决评审小组提出的所有问题

5.5. 如果存在建模人员无法自行解决的问题，应该将问题反馈给系统所有者并寻求最终解决办法

6. 管理数据模型版本与集成

6.1. 对数据模型和其他设计规范需要谨慎的变更控制，就像需求规范和其他SDLC可交付成果一样

6.2. 每个变更都应该予以记录

• 6.2.1. 为什么(Why)项目或情况需要变更

• 6.2.2. 变更对象(What)以及如何(How)更改，包括添加了哪些表，修改或删除了哪些列等

• 6.2.3. 变更批准的时间(When)以及将此变更应用于模型的时间（不一定在系统中实施更改）​

• 6.2.4. 谁(Who)做出了变更

• 6.2.5. 谁(Who)做出了变更

7. 度量指标

7.1. 模型多大程度上反映了业务需求？

• 7.1.1. 要确保数据模型代表需求

7.2. 模型的完整性如何？

• 7.2.1. 需求的完整性

  • 7.2.1.1. 需求的完整性意味着已经提出的每个需求都应在模型中得到满足

  • 7.2.1.2. 意味着数据模型只包含被要求的内容而没有额外的内容

  • 7.2.1.3. 在模型设计时也需要考虑在不久的将来因业务的变化而能够很容易地向模型中追加内容，这部分设计在审查过程中也会被注意和考虑

  • 7.2.1.4. 如果建模人员在模型中设计了从未被要求的内容，那么该项目可能变得难以交付

  • 7.2.1.5. 要考虑包含未来需求增加所引发的可能成本

• 7.2.2. 元数据的完整性

  • 7.2.2.1. 指模型周围的所有描述性信息也要完整

7.3. 模型与模式的匹配度是多少？

• 7.3.1. 确保正在审查模型的具象级别（概念模型、逻辑模型或物理模型）和模式（关系、维度、NoSQL）与该类型模型的定义相匹配

7.4. 模型的结构如何？

• 7.4.1. 验证用于构建模型的设计实践，以确保最终可以从数据模型构建数据库

7.5. 模型的通用性如何？

• 7.5.1. 评审模型的扩展性或者抽象程度

7.6. 模型遵循命名标准的情况如何？

• 7.6.1. 确保数据模型采用正确且一致的命名标准

• 7.6.2. 术语还包括正确的拼写和缩写要求

  • 7.6.2.1. 风格意味着外观，如大写或驼峰拼写等内容

7.7. 模型的可读性如何？

• 7.7.1. 确保数据模型易于阅读

7.8. 模型的定义如何？

• 7.8.1. 确保定义清晰、完整和准确

7.9. 模型与企业数据架构的一致性如何？

• 7.9.1. 确认数据模型中的结构能否在更加广泛和一致的环境中应用，以便在组织中可以使用一套统一的术语和模型结构

• 7.9.2. 主要评审出现在数据模型中的术语和结构与组织中的相关数据模型中出现的结构是否保持一致

7.10. 与元数据的匹配程度如何？

• 7.10.1. 确认存储在模型结构中的数据和实际数据是一致的