数据模型实用是硬道理

　　大数据时代，各大企业和政府机构都在热火朝天的进行着数据方面的建设，数据在组织中开始成为一种文化，反映在日常就是无论担任何种角色，几乎每个人都能在一定程度上理解数据的价值，甚至或多或少的都能使用一些数据的技术术语交流：“数据模型”可能就是这些术语名词中的一个典型。对于常人而言，“数据模型”可能代表了大数据技术的全部奥秘，提起这个词汇仿佛就已经是大数据专家了。

　　的确，不夸张的说，数据模型对于每一个数据项目的成功都具有关键的意义。对于大数据行业的从业者，“数据模型”无疑是熟悉的不能再熟悉的一个概念。售前人员在宣讲解决方案的时候，“数据模型”是侃晕客户、表现专业性的利器；项目实施期间的数据模型的人员，头戴光环，口吐各种瀑布模型、螺旋模型、3NF模型、贴源模型、雪花模型、星型模型，让人目眩神迷；累成狗的码农，把逻辑模型的翻译成物理表、主外键、各种（1:1）（1:N）（N:M）的关系；数据模型在每个人眼里的作用、位置都不一样。但是本文并不准备详细探讨数据模型的理论知识，更多的是站在项目的角度，站在逻辑模型、物理模型设计的层面，谈一些数据模型设计及使用时的一些关注点。

　　不详细讲理论，但为了统一认识，我们还是要先来看一下数据模型的定义。到底什么是“数据模型”？根据百度百科的解释：数据模型（Data Model）是数据特征的抽象，是数据库管理的教学形式框架，是数据库系统中用以提供信息表示和操作手段的形式构架。数据模型包括数据库数据的结构部分、数据库数据的操作部分和数据库数据的约束条件。

　　一般谈到数据模型分类的时候，会听到概念模型、逻辑模型、物理模型等术语，各自又有比较复杂的设计理论和方法，不是专业选手似乎很难有清晰的认识。笔者提供一个相对通俗易懂的解释：数据模型是保存数据的一套“模具”，把所有的数据，按照“模具”的形状、规格、关系装载起来。“模具”设计的好，数据装载进去，整整齐齐，调理清晰，如同强迫症患者看到一排整齐排列的、对称有序的图片，舒服安心；用数据的时候，如同图书馆借书一样，各种索引、各种分类，让人一目了然，数据清晰明了。“模具”设计的不好，数据到大概也能装的下，但是该填充的空着、该唯一的重复，杂乱无章；用数据的时候，如同拆解一团乱麻，幸运时凭借足够好的耐心还是有可能能找到头绪，但所耗费的时间和资源会非常可观。

　　什么样的数据模型是好的数据模型？不要误会，前面讲“如同强迫症”并非说形式是检验数据模型的第一标准，正相反，评价数据模型优劣，是否好用才是硬道理。数据模型模型设计人员设计的“模具”是否好用，直接关系到码农晚上加班到几点，关系到模型的生命周期（模型设计不好，很容易被码农抛弃、另起炉灶），没有哪个码农愿意抱着一团乱麻找头绪吧？

　　既然实用性是数据模型评价的终极标准，那么在设计时就一定要审视数据模型的应用场景。数据模型只是一个载体，它的最终目的不外乎两个场景，对数据的“保存”、“使用”两个应用场景，也就是联机事务处理OLTP（on-line transaction processing）和联机分析处理OLAP（On-Line Analytical Processing）。模型设计，有着各种各样的设计理论、参考模型、建模方法，但大都有着自己适用的场景，没有一种是放之四海而皆准的，如果有，那一定是方法论，而不是具体方法；所以，模型设计，一定要站在实用的角度上，根据不同的业务场景、使用目的，结合数据量、设备性能、数据质量情况，综合考虑来设计数据的“保存”、“使用”两个场景。

　　“保存”数据的场景，一般都是产生数据的源头，包括各种表单录入、交易流水记录、各种登记等活动。这些活动大部分都是靠人工触发，产生一系列的业务操作逻辑，把各个流程的数据记录下来；如果单纯从“保存数据”的角度来看，对数据模型的业务要求有记录规范、完整、数据不丢失，技术要求有符合3NF范式要求、主外键约束等。大部分的OLTP模型设计人员都是按照录入表单结构，进行数据模型设计，甚至都不会考虑符不符合范式理论；经验多些、专业一点的模型设计人员，会尽量在考虑效率的同时，让数据模型尽量符合3NF的要求，对模型做些优化；如果遇到大并发量，一般也多是倚仗技术人员从分库、分表、索引等技术手段来考虑，进行性能优化，实在难以优化，模型设计人员再考虑通过降范式、重新设计等方法，优化数据模型，用空间换时间。所以，在交易型系统（OLTP）的模型设计和数据记录过程中，经常会有以下情况：

　　1、用代理键做主键的情况较多；

　　2、一张代码表，保存所有不同业务含义的代码；

　　3、模型设计不满足范式要求，可能存在一些完全一样、且业务上合理的重复数据；

　　4、可以对历史数据的任何字段进行update，包括对主键的update；

　　5、为了保证业务扩展时，数据模型的稳定，设计一些“万能”表，把业务逻辑嵌在代码里，if 字段值=A，then…. Else….;

　　虽然站在“数据保存、流程记录"的OLTP类业务场景来思考，以上的情况，既不会影响业务处理过程，也不会影响数据的记录与存储，似乎问题不大，但是，如果我们站在“数据使用"的OLAP类业务场景来看，以上这些都会对数据统计、分析产生严重影响，更甚者会产生严重的数据质量问题，这种数据模型的设计方式，会让数据统计变的极其复杂、困难，甚至是一种灾难。

　　数据平台、仓库、集市、报表类项目，则是典型的站在“数据使用”角度来看数据的OLAP场景。当这类项目的模型设计人员面对以“保存数据“为主要目标来设计的OLTP系统的各种模型时，吐槽不断，各种抓狂，一边批判模型设计人员的“不专业”，一边不得不扎进这些“难用”的数据里，进行各种“抽丝剥茧”一样的数据探索：

　　1.重新梳理各种主外键关系，做业务主键梳理；

　　2.添加日期字段保存交易流水，想尽办法处理历史上的重复流水记录；

　　3.不断的处理各种由于对主键update导致的开链、断链问题；

　　4.把一张代码表拆成N张；

　　5.把"四不像“、“二义性”的字段，拆分成N个不同业务含义的字段；

　　......

　　这些都是OLAP项目的“模型设计”人员在做数据调研分析的时候，必然会碰到的问题，他们一边吐槽，一边遵循着“使用数据”方便的理念、遵循着数据仓库、集市、报表类项目的建模套路来设计模型：他们使用范式建模法、参考3NF的行业经典模型（例如：TD的FS-LDM、IBM的FSDM）设计出屏蔽下游变化的“完美”模型，各种实体、关系表、历史表，错综复杂，保存着全量历史数据；他们也根据应用需要、利用维度建模法，设计出各种星型模型、雪花模型，以支撑业务报表、数据集市、共性加工等数据要求。但是下面这些问题经常会困扰着模型设计：

　　1. 数据量太大导致3NF的关系表成为性能瓶颈，需要进行复杂的性能优化、数据模型降范式；

　　2. 被售前顾问拿来强调屏蔽下游变化的完美3NF模型，在上游系统变化的时候，保持下游应用模型稳定的代价巨大，非浸淫多年3NF模型设计的专业人员根本无法理解模型、无力处理上游数据模型的复杂拆分工作；

　　3.庞大、复杂的3NF模型是否适合数据量小、业务形态少、科技力量薄弱的城商行、农商行的数据平台建设？一期项目完成之后，复杂的3NF模型丢给行里刚毕业两年的运维人员时，运维人员能否快速理解、快速接手运维？

　　4.在大数据体系下，对多表关联本就存在短板的各种组件，3NF模型还适用么，3NF的表关联会不会成为性能瓶颈？

　　5.大数据体系里键值对的存储方式下，什么样的建模方法更合适、更能发挥优势？

　　以上这些都是数据模型人员需要考虑和面对的。

　　随着OLAP的应用越来越多，各种应用实践的成熟度也越来越高，尤其是大数据时代新技术体系的不断发展，已经不再是“一套3NF行业模型打底、维度建模构建应用”通吃OLAP应用的时代了。新的业务场景、新的大数据技术应用，要求数据建模人员既要懂业务使用场景、又要懂技术实现特点，才能设计出符合项目要求、业务应用和技术特色的“个性化”模型；同样，传统数据建模、开发过程中更多充当码农角色、主要进行逻辑模型到物理模型实现、"搬运"数据的技术人员，也需要更多的与数据建模人员交互，对模型设计人员提供更多的技术支撑，才能真正理解模型设计人员的模型设计思路，将结合业务场景与技术特色的实用模型进行更好的落地。

　　小结：数据模型本身没有对与错之分，只有好用与否的问题。理论永远是理论，实际的模型落地、使用，需要结合业务场景、技术路线、设备性能、运维管理等多方面的因素，综合考虑模型的实用性，才能让数据模型在满足业务需要的同时，能有更长的生命周期。