前段时间笔者写了一篇关于企业级数据模型设计的文章，具体请参看《企业级数据模型设计方法论探讨》。在该文中笔者主要探讨了企业级数据模型的基本定义以及模型设计的方法和要点。那么，当我们采用“自顶向下”业务需求驱动，结合“自底向上”数据现状驱动相结合的方法论，同步参考业界参考模型、借鉴行业最佳实践经验设计出一个数据模型之后，应该有哪些通用的质量维度来评价数据模型设计成果的优劣性呢？笔者近日恰好读了《DATA MODELING ESSENTIALS 3rd Edition》中一节“What Makes a Good Data Model”，基本上回答了笔者的疑问，感觉很有必要结合笔者本人对数据模型的设计经验和深度思考，解读其中一些要点作为数据模型质量的评价标准供读者参考。为了便于阐述数据模型质量评价标准，本文引入书中一个简单的保险系统数据模型作为示例，如下表所示：
数据模型设计质量评价标准
1、完整性
当我们设计出一个数据模型后，客户可能的第一反应就是，“你这个模型到底全不全”？客户提到的“全”，转换成术语就是完整性。那么我们该如何来评价一个数据模型“全不全”呢？由于在很多情况下，信息系统模型或者数据仓库模型的设计成果往往是阶段性的，特别是数据仓库模型，由于公司各源系统的数据入仓，往往要经历数年时间，数据仓库模型设计也是在这个过程中逐步完善的，那么在数据模型最终完成之前的中间阶段，该如何来评价数据模型的完整性呢？
我们所说的完整性，并非是指模型要覆盖系统或公司范围内的全部数据，而是指是否能够支撑一个完整的业务场景，包含一个完整的业务场景中所需的全部数据。而这个业务场景也是客户业务需求的主要来源，由于客户在描述业务需求时，可能存在失真、信息丢失等情况，并未完全反映出业务场景当中的全部信息，模型设计师应深度挖掘客户需求背后的业务场景信息，将业务场景当中所有信息在模型中体现出来，从而表现出模型的完整性。
例如，上述的保险系统模型当中，客户表中缺少一列“职业/occupation”，因为客户职业是保险销售中非常重要的信息；另外，还缺少一张表用于记录保险费用支付信息，这是保险系统能够发挥业务价值的非常重要的信息。如果在模型设计时，存在类似这种丢失、遗漏重要业务信息的情况，则表明模型是不完整的。
2、非冗余性
     冗余性是指相同或类似含义的数据在模型中出现多次，它的对立面也称为“唯一性”。数据冗余带来的负面影响，不仅会增加数据存储的空间，更严重的后果是会导致数据的不一致。例如，上述的保险系统模型当中，策略表中“佣金率/Commission Rate”列中存在大量的相同取值；客户表中“年龄/Age”相对于“出生日期/Birth Date”，含义似乎有些相似，通过系统日期减去出生日期，就能得出客户的年龄，这两个字段在同一张表中出现，“年龄/Age”列就显得有些多余。此外，如果我们需要新增一张表“保险代理人表/insuranceagents”也有年龄和出生日期。假设某个人既是客户，也是保险代理人，那么同一个人，在不同的表中出现，并在不同的场景中进行维护，就会有可能产生不一致。
根据上述的信息，数据冗余产生的原因可以总结出以下几点：
（1）数据库表设计未能达到三范式要求，没有消除传递依赖；例如，策略表中“佣金率/Commission Rate”列可由“策略类型/Policy Type”列确定；“年龄/Age”列可由“出生日期/Birth Date”列确定，两张表都存在传递依赖；
（2）数据库表的抽象度不够。例如，如果新增一张“保险代理人表/insurance agents”，那么他的姓名、性别、出生日期等基本信息也需要保存和维护，但是，如果当一个人同时既是客户，又是保险代理人时，他的信息就是在不同的表中保存两次，且有可能会不一致。在这种情况下，只有在客户、保险代理人这两种角色之上再抽象出一张“自然人”信息表，用于存储这些属于自然人的基本信息，而客户表、保险代理人表只存储与之相关的特色信息，才能从根本上消除数据冗余，确保数据的一致性。
3、业务相关度
上一篇文章中笔者提到过，数据模型是对业务规则的承载，也就是说，数据模型是与业务高度相关的成果物。数据模型设计应充分考虑业务场景中的关键业务规则，这些业务规则在后续的系统设计、实现中才能承接下来，否则就可能会导致遗漏关键业务信息，而与业务场景不符。
例如，上述的保险系统模型策略表中，存在一条业务规则：每一个“策略编号/Policy Number”只能属于唯一的“客户编号/Customer Number”，系统的用户和开发人员都不能违反这条业务规则。如果我们在数据模型设计当中，就考虑到这条业务规则，就能很好的约束后续的系统设计与开发工作，从而在源头就开始保证数据质量。如果遗漏了这条关键业务规则，那么将会很难纠正后续系统的设计和开发成果，因为系统已经上线了，系统所有的设计和开发都没有遵循这条关键业务规则，系统改造也会非常困难。
4、数据的可重用性
 客户在提需求时，通常会存在一定的局限性，可能只会关注、或者要求满足当时特定的某个应用需求。那么，在模型设计过程中，除了支撑客户提出的应用需求以外，还要考虑数据的可重用性，因为很可能会出现依赖这些数据的其它潜在的应用需求或用户。例如，保险公司可能一开始只是想记录一些策略数据用于支撑账单支付功能。但是，销售部门可能会使用策略数据计算佣金、市场部门可能会使用这些数据了解人口统计信息、监管部门需要做统计汇总。但是，所有这些需求很难在一开始就能提前全部想到，如果数据完全不能重用，那么就只能有以下两个选择：
（1）提出新需求，做新设计，但这些新需求、新设计与之前的需求、设计的相似度会比较高，导致模型臃肿；
（2）重新进行整体性设计，推到重来！
因此，为了避免出现上述情况，应该在模型设计时，就应尽量避免数据模型与具体某个应用需求绑定得过紧，造成紧耦合，设计过程中尽可能的保持数据模型的中立性。
5、稳定性和灵活性
由于应用需求可能会频繁发生一些较小的变化，但数据模型在支撑前端应用需求时，很难快速、同步保持一致。因为此时，模型很可能已经设计完成了，模型设计工作已经结束了，那么此时数据模型的稳定性，是检验数据模型质量优劣性的重要标准之一。
模型的稳定性，并非是指模型完全不发生任何变化，而是指数据模型能够在不需要做结构性变动的情况下，就能从容应对业务需求这些细微的变化。例如：无需模型设计人员参与，只需业务人员增加某个字段的取值范围，无需变动表结构，就能够支撑起一个之前未曾考虑到新业务。
灵活性与稳定性的目的是相同的，都是为了快速响应需求变化。他们之间的区别在于稳定性要求模型只需调整字段的取值范围，无需变动表结构，就能响应需求变化。灵活性则是要求只需对现有表结构做一些很小的改动，就能响应需求变化。例如，在现有某个表中增加一个新字段，或者修改一个预留的字段，就能支撑一个新的应用场景，无需进行系统改造。
模型的稳定性和灵活性之所以很重要，是因为市场竞争非常激烈，公司高层在应对这些挑战时，往往需要对之前的竞争策略做一些细微的调整，例如，快速开发一个新产品，并迅速推向市场。这就需要业务系统能够快速响应这些应用需求，在尽可能短的时间、最小的代价去适应新变化。如果模型的稳定性不足、灵活性不够，无法支撑任何细微的需求变动，都得重新对系统进行改造，那么很可能就会丧失市场机会，影响公司的长远发展。
6、可读性
前面我们提到过，数据模型是业务人员、技术人员、模型设计师等各种利益相关者进行沟通的媒介、也是企业内部与外部进行交流的纽带。这就需要数据模型具备很强的可沟通能力，表现在以下两个方面：
（1）在业务人员角度，表和字段的命名是否反映出基本的业务概念，并能使用户和业务专家可以很熟悉地进行验证和确认，而不是一些晦涩难懂的技术语言；因为业务人员作为模型设计成果的最终使用者，模型质量的高低，业务人员最有发言权。
（2）在技术人员角度，他们是否能够正确的理解、并解释这些反映业务含义的表和字段？因为后续系统的设计、开发都依赖于技术人员对模型设计成果的充分理解的基础之上，因而，技术人员同样具有评判模型质量高低的发言权。
那么影响模型的可读性的主要因素有哪些呢？主要包括以下因素：
（1）复杂度高。对于一些非专业人员，对表的数量的容忍程度是有限的，通常只有几十张。如果在同一个图形化界面中超过100张， 这已经超过了他的极限，使得模型不可读、不直观。此时，应考虑将模型进行分领域设计，每个域维持在30~40张表左右，并保持模型结构的直观性、可读性。
（2）新概念。在某些情况下，为了保持模型稳定性、降低其复杂度，需要在一些很常见的、很通用的表中增加一些新数据，以便支撑更多的业务需求。但这对于业务专家或技术人员很可能一时难以理解，影响其可读性。
（3）陌生的业务术语。这是由于模型设计师为了在表和字段命名时为了保持逻辑上的严谨性，而不得不使用一些陌生的业务术语。而不是去使用那些虽然熟悉的、但是存在歧义或依赖上下文语境的业务术语。
体会与结论
上述提到的六个评价标准，是笔者认为的评价数据模型质量的最重要的标准。但是这些评价标准之间可能存在一些冲突。例如：模型的业务相关度高，考虑了太多现有的业务规则，很可能会影响模型的稳定性和灵活性；模型的可读性高，很可能难以支持数据的可重用性，为了让各方更容易理解模型，很可能使用一些特定业务的命名术语，在一定程度上影响数据的可重用性，无法在多个场景中使用。
因此，在设计数据模型时，应当考虑保持这些评价标准的相对平衡，整体来说，完整性要求的优先级最高，这直接影响数据模型是否能支撑当前应用场景的全部信息；非冗余性要求之一高度抽象性，也很重要，因为这会导致数据的不一致，从源头就造成数据不一致的隐患。其余的评价标准，则应充分考虑客户当前的紧迫诉求，适当调高与其诉求相近的评价标准的优先级。