文章来源：https://ask.hellobi.com/blog/rayshawn/2982
数据模型的要求
1.要直观的模拟真实世界
2.容易被人理解
3.便于计算实现
一、低质量建模
Steve Hoberman的《Data Model Scorecard》一书中详细罗列了低质量建模的十宗罪
1. 没有准确的捕获到需求
这个属于数据建模最大的问题。通常由于需求调研不完备，需求理解不充分，项目前期缺乏足够的沟通，以及数据调研准备不足、后期测试不充分等原因引起。在系统真正使用时，发现有些需求功能无法满足，造成表结构的大幅调整。
举例一个简单的例子，某集团公司有30个分公司和子公司，以一个公司为试点部署一套系统，而其中需要设计一张员工表，该表的设置为Employee 员工编号为主键，而在上线推广时发现问题，就是该集团公司其中有几个分公司的HR系统由于历史原因，员工编号与其他公司不是同一套系统，会造成员工编号存在重复的现象，这样就不得不修改主键，以及后面使用到该表的程序都需要大幅修改。这只是一个简单的例子，类似这种例子比比皆是。
2. 数据模型不完整
数据模型不完整分为两种情况，一种是设计时对需求把握不准确，造成数据模型缺少一些相关的表，无法完全覆盖需求，这个其实就是上面的例子1。还有一种情况是元数据不完整，我们这里强调的是这个。比如，对于column的constraints的限制，例如参照完整性的定义，比如是否为空。再比如某个Column的default值，是否有设置。另外就是表的描述，字段含义的描述等信息，是否提供。你很难想象下游系统去理解一个完全没有表定义，字段含义定义的有多痛苦。
3. 各层模型与其扮演角色不匹配
数据模型分为概念模型，逻辑模型和物理模型，每一层的模型的使命不同。概念模型是为了确定范围以及奠定基础，逻辑模型是为了厘清数据之间的关系并且勾勒理想状态下的数据结构，物理模型是为了性能，安全以及开发的方便构建的适应真实情况的模型，每一层的目的均不相同，很多data modeler不做概念模型和逻辑模型，直接一步到位到物理模型，或者每层的结构没有遵从该层设计的本意。
4. 数据库结构不合理
这个就好比，你画一个房子的设计图，每个房间都得有门，这一类设计的基本常识。比如，一个表通常都得有主键，主键又一定不能为空，之类。相同的两个字段，在不同表中需要保持一致，如column name, 字段长度等等。
5. 抽象化不够，造成模型不灵活；又或过于抽象化，带来程序开发的困难
这个部分很重要，一个数据模型的是否能够承受未来的变化，很大程度上都取决于抽象化的程度。这个有点像动物的分类，门纲目科属种，无论飞禽走兽都可以抽象称为动物，而动物中又分脊索动物门，软体动物门等，在脊索动物门下又可以分为哺乳纲，哺乳纲又分草食目肉食目杂食目。每一类都有向上的抽象，所涵盖范围都更为广泛。数据模型也是一样的道理，至于建到门纲目科属种哪一层，实在取决于当下的需求以及未来可能的扩展。
6. 没有或者不遵循命名规范
这个我们见的很多了，老外的项目这方面就好很多，国内的项目千奇百怪，用汉语拼音命名的都比比皆是，这里我就不举例子了，未来会有单独的大篇幅的课程讲命名规范。
7. 缺少数据模型的定义和描述
这个覆盖率可能超过90%，我接触过的很多项目都没有数据模型或者数据模型和真实数据库里面的内容就是俩东西，字段的含义表的含义基本靠猜，如果恰好数据模型又犯了6的错误，更是猜无可猜。
8. 数据模型可读性差
嗯，这个有意思，见过直接用DDL管理模型的，也见过用Excel管理的，还见过用Word管理的。没有ER图的，数据字典基本为空的，这种例子比比皆是。
9. 元数据与数据不匹配
这个问题也很常见，比如表/字段乱起名字，再比如最开始某表/某字段具备一种含义，而开发过程中发现用这表/字段还能干点别的类似的事，然后为了从前的程序不修改，表名和字段名也不改了，直接应用。比如，原来的表是客户，起名叫CUSTOMER, 里面记录CUSTOMER ID，Name，地址，电话等等，然后发现有的时候，我们的供应商需要的字段差不多，本来应该建个表叫VENDOR，结果为了图省事直接用CUSTOMER表，并且模型里面也不加解释，之类。
10. 数据模型与企业标准不一致
二 、 低质量数据模型，会给企业带来哪些影响
这个问题是企业信息管理存在的普遍问题，也是哪怕是很多好的Data Modeler也犯的错误，就是以项目视角出发，
按照自己的习惯进行模型设计。而企业，（指甲方），在这方面通常也没有标准化的流程和政策来控制，
因此造成整个企业都是各个项目有各个项目的标准，但缺乏企业级的标准，这也是数据质量问题的根源之一。
由于低质量的数据模型的原因，会给企业带来哪些影响呢？
1. 就是大量修改和重做
尤其是我们提到的没有准确捕获到需求的这种错误。
2. 重复建设
这个指的是，由于低质量的数据模型，造成系统很难可持续的发展，当需要添加新功能时，很难在原有系统基础上添加，只能重做。
3. 知识丢失
模型文档不完备，比如前面提到的缺乏定义之类的问题。这些知识都当时封存在Data Modeler的脑子里，有个经典的段子：三个月之内只有我知道，三个月之后只有上帝知道。而数据仓库项目又经常是经年累月的长期的过程，项目里面的人来的来走的走，知识没法传承。
4. 模型难以理解，下游开发困难
假设你弄一套千八百张表的数据库，然后还不给说明书，你让下游的Data Mart的设计者，报表等应用的设计者怎么进行开发？
5. 高成本
上面说的这些，都会带来高成本，包括项目周期的延长，包括人员的培训，包括开发的周期，错误的增加等等。
6. 数据质量低下
同时呢，这也是数据质量低下的主要原因之一，比如你数据仓库这一层模型做的质量低下，你就很难保证下游的Data Mart会正确的使用。也就难保证基于其的报表的数据是正确的。
7. 新业务无法展开
比如你新建一个数据应用，基于主数据的，而主数据的数据质量一塌糊涂，是不是你这个新应用就没法做起来啊。
等等
