数据模型设计

前言

做数据的人，很多人向往能够做模型，而很多人又对数据模型望而却步，另外就是看到很多在做模型但是一知半解的人。

谈模型需要谈很多内容，所以我把它分成了上中下三部分，希望能基本上谈透彻：

上：以谈什么是模型，以及模型的理解为目标；
中：以谈逻辑数据模型设计方法为主；
下：谈逻辑数据模型在生产系统和在企业级数据平台和分析应用系统的落地策略为主；

（一）、什么是模型。

在IT领域内，有很多模型，而且大家容易把前缀忽略，都叫做模型，导致混淆，而且确实有人概念中只是知道“模型”两个字，而不去细追究到底是什么模型，在此我们首先应该做澄清。IT领域常见的模型包括：

1、业务模型：

属于企业架构领域的范畴，完整的叫法应该是“业务流程模型”，是按照一套方法梳理企业的业务逻辑的过程，梳理的这个过程我们叫做“流程建模”，梳理的产出我们叫做“业务模型”；那么如何通过业务模型还原一个企业的业务呢？

• 每个业务在企业内都是一个完整的业务流程，需要进行流程梳理；
• 流程的每个环节都有一个业务能力定义，即：这个环节是为了完成什么业务任务的；
• 每个业务任务都应该包括：谁，操作什么业务对象，输入，输出，页面表单展示方式，判断 依据和规则，产生什么交易记录，交易是否有金额发生，涉及到的会计核算方法，该业务是否有统计分析的需求，统计口径和指标的定义，是否有关联操作的文档和表单等一系列的内容。这些内容能够完整的反映业务用户子这个操作过程中所有业务要素。

2、数据模型：

数据模型是利用企业业务发生过程中产生的数据，能够还原企业在开展业务过程中的主体对象、关系和行为的关系实体模型（Entity & Relationship）。通俗的解释就是利用关系实体模型能够还原企业的业务主体，业务发生之间逻辑关系。

因此：数据模型应该包括三类数据:

• 主体数据模型：对于企业业务发生过程中的主体、对象（通常就是我们讲的主数据）的定义和描述数据的建模，应该用模型实现其：唯一业务编码、分类管理和属性管理。这类数据的特点就是时点切片都是一个企业当前现状的完整镜像。
• 行为数据模型：记录所有的业务行为发生，可以是流程行为也可以是交易行为；可以和金额相关（涉及到企业的财务核算），也可以和金额不相关（如属性状态修改等）；这类数据的特点就是每笔都有稳定的时间戳，通常按照时间段统计才有意义。
• 关系数据模型：可以是主体自关联关系，可以是主体间关联关系，可以是主体和行为关系，也可以是行为和行为关系。而且因为是关系，必须表达关系的双方是谁，关系类型，以及关系延续的事件。关系可以借助于表的主外键关联关系来建立，也可以借助于独立的关系表来表达。关系可以是1对1（如一个上市公司编码同一个时间只能对应一个企业主体）；可以是1对多（如一卡双待手机在同一时间可以对应两个手机号码）；也可以是多对多关系（如每个学期学生都可以选多门课程，每门课程也有多个学生选择）。

3、分析模型：

通常是指企业为了实现某个领域的分析，将企业基础数据中的某些表提前进行逻辑关联操作，以实现某个主题分析为目标的数据组织方法。

比如说淘宝需要分析女性化妆品的销售分析，把涉及到化妆品的销售行为记录，和客户信息，化妆品供应商信息，品牌、产品、价格定义信息等提前进行关联，如果需要涉及到区域分析、购买人群特征分析等，需要再关联地理信息数据，客户详细特征标签数据等内容。这样就构建了一个分析模型。我有时候也把这个东西叫做语义模型（universe），源自于某些报表分析软件之前实现分析模型的时候，就说我们定义个语义层（universe）吧。

4、挖掘模型：

指数据挖掘建模，针对特定的业务题目，基于数据进行挖掘探索，在诸多数据变量中寻找对于结果有影响的因子，以及这些因子影响最终结果的机制。比如说电信行业的客户流失预警模型，就是通过客户话费变动、套餐选择、最近使用频度、投诉事件等一系列数据中提取有效变量，预测客户的流失概率的一种挖掘模型。

澄清了这几种模型，我们继续深入探讨数据模型：

（二）数据模型的分类

我们在讨论数据模型的过程中，又把数据模型按照其从抽象到具体分为三个层次，分别是概念模型、逻辑数据模型和物理数据模型三个层次。

概念模型：是指数据模型的高阶模型，包括数据主题域划分，主题内的核心实体，以及核心实体之间的关系。通常不需要所有的模型实体，也不需要到字段属性层面，核心实体可以包括核心实体的业务主键以及可能和外部产生关联关系的外键即可。也可以有更简化的概念模型，只提炼企业的数据主题，初步利用数据主题构建逻辑关系，反映企业大致的业务逻辑即可。

逻辑数据模型：是基于概念模型的细化，需要完整的补充所有的实体、关系和属性，能够涵盖所有的数据要素，而且能够通过实体和关系体现企业数据的业务逻辑。逻辑数据模型设计过程中的核心方法只有三个：

（1）    有效继承概念模型框架。
（2）    应用好逻辑数据模型设计方法（中篇中我们会重点阐述）。
（3）    充分了解业务以及业务发生产生数据的逻辑。

物理数据模型:  是逻辑数据模型和物理系统结合的产物，是逻辑数据模型按照选择的物理数据库特性以及结合支撑的系统的作业特征（workload），从存储和访问效率层面结合进行的物理化设计。形成可以支撑在该物理数据库具体落地实践的DDL（Data Define Language）。

（三）逻辑数据模型在实践中发展的演进过程

笔者在IT实践过程中，看国内在IT系统建设过程中，对逻辑数据模型的认知，有一个逐步演变的过程。

公元前：（没有逻辑数据模型阶段）基本从系统建设出发，有了业务需求之后，由开发人员在设计功能的同时，设计自身开发实现的数据存储层面进行表结构设计，满足开发需求，部分规范一些的，会构建关系实体模型，再规范一些的会有一些命名规范和评审机制。这个阶段最终的问题模型没有企业级概念，业务逻辑和关系体现的凌乱，模型没有业务可扩展性，导致在不同的业务需求和系统扩展中表结构不断地优化调整为“四不像”，当然也没有企业数据模型的管控策略。

发展前期：（数据仓库逻辑数据模型阶段），国内绝大部分企业接触数据模型都是从数据仓库建设开始，开始有了企业级的视角看待数据，从企业级的业务逻辑分析数据主题、实体之间应该有的关系，从建模策略上开始探讨模型的可扩展性问题。但是这种实践大部分停留在数据仓库建设层面。

发展中期： 有了数据仓库逻辑数据模型概念后，很多企业开始在企业的其他业务系统建设过程中适度借鉴和参考数据仓库模型设计的理念，包括主题，范式等逻辑；开始考虑基于属性的分类和变动频度的存放合理性和有效性；开始关注实体之间应该有的逻辑关系；开始通过关系表存储关系等。（其实在这个过程中笔者也曾经局限性的认为没有企业级逻辑数据模型，逻辑数据模型是针对系统的，但是后来随着自身认知的提升，还是充分感觉到了自身认知的局限性）

成熟阶段： 部分优秀的企业开始尝试构建企业级逻辑数据模型。方法大概分为两类：

（1）    结合企业架构理论，从业务流程模型梳理是最正确的方法，但是耗时长，投入多。
（2）    依托于可以参考的逻辑数据模型方法，从现实发展中逐步提炼和积累，形成，这种做法比较实际。但是需要有具备企业视角的专家和模型构建和管控的策略。

其实从上面两种方法中，我们能够看总结出来在企业级逻辑数据模型构建的过程中相关重点包括：业务架构指导；企业业务流程模型作为输入；业务逻辑数据模型构建的方法；企业逻辑数据模型未来指导基于系统落地的管控策略（通常是指企业逻辑数据模型管理办法，重点是系统建设如何继承和参考企业级逻辑数据模型的原则）。

同时在数据模型设计过程中，开始结合数据标准、主数据管理策略，针对每个核心主题的数据进行详细的业务规范设计（重点是业务定义、分类、属性合理性、公用代码合理性的角度）。

（四）探讨几个核心问题，是大家在模型中常问的：

逻辑数据模型到底用来做什么？

逻辑数据模型用来干什么？一句话就是“企业数据组织的合理性问题”，数据组织的“合理性”如何解释？笔者认为从前后两个角度，前的角度就是如何能保证业务系统在业务变革中扩展性，而不是每次业务新增、优化、调整都带来大量的模型调整；后的角度是有效的数据关联逻辑为后续的管理决策和分析服务提供基础。所以这种合理性的理解应该是“可扩展性”、“业务连接的逻辑正确性”；

逻辑数据模型重要吗？

很重要，无论是对于处于快速业务转型阶段，后续业务需要快速持续发展的企业，还是对于业务具备规模，已经成熟，但是需要管理精细化提升效益的企业。其实这两类分别就从我们说的“可扩展性”和“业务连接的逻辑正确性”角度有各自强烈的诉求。

什么是企业级逻辑数据模型？

站在企业视角，覆盖企业全面业务开展和产生数据角度进行的逻辑数据模型设计，该逻辑数据模型并不是某一个具体的系统模型，但是应该在所有企业系统的基础数据组织层面被继承和参考。对于关注数据资产，把数据作为“第四生产要素”的企业而言，我们企业级需要有统一的业务认知，这个重要性不言而喻。

数据模型和数据标准是什么关系？

一句话“模型解决的是数据组织合理性的问题，标准解决的是业务定义正确性的问题”，如果一个企业的数据要健康，这两个都是重中之重。

模型需要持续性维护和管理？

当然，只要业务持续在变革发展，模型就需要维护和管理。如果我们只是一次性构建逻辑数据模型，后续实践中只去维护物理模型了，那么我们就是倒退回公元前的节奏。

大数据时代还需要数据模型？

客观的说这是大数据刚开始发展的年代经常有些伪专家满嘴喷沫的一句话！

不客气的说：别和我扯蛋“大数据时代不需要数据模型”，你说的要不就是“大数据技术对物理数据模型有了新的支撑方式”；要不就是“企业大数据平台不需要数据仓库建模，可以采用贴源存储或者数据湖的架构”。如果我和你说一句啊“企业业务开展产生的数据没有逻辑关系”，你不也觉得也同样是“瞎扯蛋”？

逻辑数据模型设计

有些行业的逻辑数据模型设计有可以参考的行业模型作为指导。这样就变成了参考行业逻辑数据模型针对自身企业进行客户化的过程了。当然有大量的行业没有行业参考模型作为指导，只能自己掌握逻辑数据模型的设计方法，逐步构建。

需要稍微说一下，什么是行业参考模型。

拿我最熟悉的金融行业，典型的两个行业参考模型分别是Teradata 的FSLDM和IBM的IFW模型体系。两个模型产生的初衷有差别，最后形成的模型形似神似。

Teradata的FSLDM主要是Teradata在长期从事金融行业（银行、证券经纪业务、保险业务）的数据仓库实践过程中，通过对金融数据基于业务的理解和提炼形成的一个行业参考模型。

IBM的IFW是从业务架构的业务流程建模，拆解数据要素，数据主题定义，到利用业务要素作为输入进行逻辑数据模型设计，是更为全面的企业级逻辑数据模型，它的模型分层中的FSDM类似Teradata的FSLDM但是相对比较粗一些。

另外从Teradata的FSLDM的建模核心理念，采用的是核心CAP模型理念，也就是以Customer\Product\Agreement三个主题为核心，以对最终用户提供金融产品和服务的金融营业型机构为目标的。而我们现实实践过程中总有人认为它是全金融行业的，拿去套用在交易所，结算公司之类的基础设施企业，生搬硬套，只能说没有理解一个行业参考模型的初衷和本质。

其实行业模型自身提炼和生成的过程，和我们在没有行业模型参考的情况下构建一个逻辑数据模型的方法雷同，以下我们就重点阐述一下逻辑数据模型构建的方法过程。

第一步：如何提炼数据主题

对于数据主题如何划分，其实没有标准，就像同样是金融行业，FSLDM主要是10大主题，而IBM得模型可以是14个主题。所以所谓主题就是某一类数据的一个集合归类。那么按照什么方法进行集合归类？按照你认为合理的，能够说服别人的方法。哈哈。这个太泛，具体讲可以结合的归类方法有：

（1）    被描述对象从本质上属于同一类业务主体；
（2）    用来描述它的方法雷同；
（3）    对于个别数据内容比较少的主题，可以把他和在分析中经常有相关性的大主题适度进行合并，因为主题下面还可以有子主题。
（4）    同样如果一个子主题在企业内逐步变得重要，可以做主题的层次提升。

因此主题就是所谓数据实体逻辑归类，没有严格的标准，便于人们从整体上构建对企业数据的理解框架即可。不给一旦定义了则需要稳定，后续可以扩展，尽量减少主题调整，否则影响已经建设的模型的继承性。

谈下一个步骤之前，首先，我回到“前文”讲的内容，主体数据、关系数据、行为数据三种模型；为了讲这个，我们最好实例化看待问题。讲一个“资产”的例子，因为资产是每个企业都有的东西。

通常我们对企业的资产理解，从财务角度讲，至少区分为长期不动产和低值易耗品，如果从业务管理角度讲可以有更多的分类，比如说：长期不动产、车辆、机械设备、低值易耗品、有价证券等。每个企业都有资产管理，而且大部分企业都有资产管理系统支撑资产管理，企业进行资产管理的时候，站在主数据管理的规范化角度考虑可以分为以下几个角度：

• 资产定义：企业自身对资产的定义什么，定义决定了企业资产管理的范畴。
• 资产的分类：通常可以分几大类，两到三个层级，甚至对于某些管理精细化的企业可以有四到五级的分类。比如说：如果企业的有价证券可以是其中一类，但是站在企业的资产流动性和偿还责任管理的角度可以区分为：股票、债券等等。是否需要针对债券再做细分，需要看企业管理的需求。
• 资产的属性信息：企业用来定义、描述、管理每种资产，需要补充的每种资产的属性信息。从这些属性分类的角度：

---- 所有资产都有的信息：包括资产的编号、分类定义、资产的开始持有日期、资产的最后持有日期；资产的计量单位、资产的数量以及资产的估值等等。

---- 某类资产共有的信息：仍然拿有价证券举例，除了整体资产有的属性外，还有有价证券这一类资产的特有属性，包括发行主体，票面价值，发行价格，认购价格等。

---- 如果再往下细分如果到债券这种有价证券，除了有价证券共有属性外，还有债券独有的属性特征，比如说票面利率，债券周期，还本付息方式等等。

以上三类，属于资产的基本定义和描述。产生的数据信息主要包括资产的编码、分类和属性定义。

除此外：从运营流程上，又分为以下几个环节：

资产的登记入册，通常是和资产的采购环节有关系；
资产的定期盘点，通常和企业资产盘点有关系；
资产的减值处理，通常和资产类型以及企业针对这种类别的资产的减值处置的会计核算原则有关系。
资产的估值处理，通常和资产类型以及会计法则要求的针对这类型资产的估值原则有关系；
最后是资产的处置。

这些运营活动环节中产生的数据包括描述资产的状态和资产的数量余额和估值数据，同样也包括这些运行过程中的原始行为数据以及原始行为到会计核算过程中的凭证数据。

除此外还有其他的关系数据如：

资产的来源：资产是通过哪些供应商采购的，如果企业某类资产很密集，需要考虑这类供应商的优劣，就需要持续管理供应商和资产的关系；
资产的使用：如果企业要勤俭节约，考虑不同生产线或者业务单元对低值易耗品的使用，则应该考虑资产和内部组织之间的关系，去考核资产的消耗；
资产的增值：如果是投资类企业，分为不同的投资管理团队，要考核投资管理团队购买不同类型资产的增值保值能力，则需要稳定的管理资产和投资和运营团队之间的关系；
资产的维修保养：如果企业有大量的设备资产，同时又有大量的零备件和物料支撑设备的维修保养，则需要建立不同类型资产内部的自关联管理关系，维系设备资产和物料资产之间的相关性。

诸如以上都是围绕企业的管理诉求需要识别和管理的关系数据信息。以此为例，我们来看下面步骤的开展。

第二步：核心实体建模：

我们以上面探讨的资产为例讲核心实体建模的主要环节：

首先必须明确主数据的业务主键定义，业务主键通常可以用独立编码的方式，通常不建议采用有业务含义的字段拼接的方法（原因我在之前的老兵第一篇中讲过这个问题）。业务主键解决每个资产的唯一识别的问题。

其次按照资产的分类构建一个核心主数据信息的层次状分类结构。通常我们把这个方法叫做父子类或者父子表的方法。父类（根节点）代表所有资产；下面第一层实体按照资产分类第一层建设；下面第二层实体按照资产分类第三层建设；以次类推，这种父子类建设的方法特点和优点集中体现：

• 完整体现企业管理视角对主数据的分类管理；
• 父节点和子节点的所有业务主键是一致的，便于数据关联查询；
• 父节点中保留所有资产的共有属性，子节点中只保留本类资产的个性化属性，这样如果要获取每个资产的全部属性信息，就需要从子节点关联到父节点进行操作。这种关联虽然造成了一些访问上的困难，但是也带来了非常大的好处，集中体现在模型的稳定性层面：(1)不会因为不同资产的属性管理差异大，如果都放在一张资产表中，会遇到数据库管理中大量的“稀疏矩阵”的问题。浪费存储，以及浪费访问过程中的IO操作。(2)父节点因为管理共享属性，相对稳定，由子节点属性相对个性化易变，保留适度弹性。(3)都是基于主键的关联访问，没有大的性能问题。

第三步：实体属性的模型设计方法

有了基础实体框架，管理了主体的编码和分类，那么所有的主体的属性的管理就有两种方法：

第一种方法就是用宽表，在主表中不断的增加字段，去管理每类主体的所有属性。
第二种方法就是用窄表，在主表外建立分类的属性存储表，而且对同一类型的属性，采用编码的方式，“横”转“竖”，采用属性编码+属性值的方法转换为窄表存储。

通常在逻辑建模的过程中，为了概念的逻辑框架清晰度，建议采用分类窄表的方法进行属性的存储。

而在物理模型实现的过程中，需要区分生产系统、数据平台系统、数据应用系统，结合某种类型属性的数量，属性的变更频繁度，属性在访问过程中的关联性，以及某类属性是否数量经常发生变化等问题结合起来进行物理化设计考虑。（在后续我会详细讲解这部分的物理化策略）

第四步：关系表的建立

关系数据我们之前已经说了，不单独建立主题，因此关系的保存在模型设计过程中就采用两种方法：

第一种方法：利用主外键关联关系，不建立独立关系表进行存储。
第二种方法：采用独立的关系表存储，关系表主键就应该是A主体、B主体、关系类型、关系开始时间、关系结束时间。除了这个外可能有少量的关系涉及到的属性。

那么什么样的关系用第一种方法，什么关系用第二种方法？简单判断就是如果关系简单而且就是一种，这样的情况下就用主外键关联就可以了。如果关系多样性，变化快，历史需要保留当然只有第二种方法合适。

第五步：事件类数据建模策略

在事件类数据建模的过程中，我们需要考虑的问题需要有两个：

• （1）    事件分类的清晰，明确定义每个事件真实的业务含义。但是事件通常在企业内不需要考虑一个分类树状结构，就是针对不同类型事件的平行罗列。
• （2）    事件之间的关联性识别：重点考虑基于一个完整的业务操作流程，分解为多个业务操作步骤，产生多笔事件类数据。所以需要通过流水号加上交易类型能够识别事件之间的关联逻辑。而且稳定的保存。本质上这个内容属于关系数据层面应该关注的内容。

如果我们再谈一步，如何规范化事件类数据的逻辑模型，重点是识别和规范化定义每类型事件的核心数据要素，这个属于事件类数据标准化定义的范畴，我们就不做详细的阐述了。

另外在“老兵一篇中”，我也提到了，在很多开发人员设计过程中，将主表和某些事件信息设计在同一张表中。这种从模型设计层面是要严格杜绝的。某些主体的属性信息，可以记录在事件类表中，作为事件类的一些辅助理解信息，但是我们要知道随着历史，主表的属性变化是否需要同步回事件类信息？绝对不可以。因此可以在事件类表中保留的主属性，只有是和该操作动作直接修改相关的属性，记录其经过这个动作的变动过程，以及和这个属性变化判断相关的参照属性。

从1-5步这四个步骤，简单的做个不恰当的比喻，我们组装一个人。第1步：把一个人，理解为大卸八块的东西，脑袋，胳膊，躯干等等。第2步：构建每个大组件的骨架子搭起来。第3步：在骨头上把肉填满。第4步：把各个模块组装在一起形成一个完整的人。第5步：填充内部血、液、气的运化机制，然后记录流动的行为。这样就成了一个完整的人。想想这个例子实在不好。但是比较形象。

除了这些基本的方法和步骤外，我们在关注逻辑数据模型的过程中，还有一些需要重点关注的问题。

（1）哪些是必须在逻辑数据模型层面考虑的问题？而哪些其实是物理模型层面考虑的问题？

逻辑数据模型应该考虑的就是数据的业务逻辑组织，不应该考虑任何物理落地的特性，不要受制约于物理落地的特性而扭曲了业务逻辑。

（2）企业级逻辑数据模型对每个系统的逻辑模型设计的参考意义和参考方法。

企业级的逻辑数据模型是企业数据按照企业统一业务逻辑的数据有效组织方法。每个系统都应该继承的是主体分类，核心实体框架，主数据的业务编码规则，数据之间的关联关系。而属性的摆放，层次的缩减在考虑不同类型物理化的过程中可以商榷，后续物理化的过程中我会详细讲解。

（3）谈谈逻辑数据模型持续性管理的策略。

敢于去做企业数据模型的企业，都应该具备持续维护企业数据模型的独立的岗位职能。而对于系统级别的逻辑数据模型，个人建议在每个大版本改造的过程中，需要更新维护逻辑数据模型。做的更好的应该是维护逻辑数据模型和物理数据模型之间持续演变的关系。

（4）逻辑数据模型和企业级数据标准体系的耦合使用。

一句话定义：数据模型决定的是数据存储有效性的问题，而数据标准是数据定义的正确性的问题。一个决定了馕的规格，一个决定的里边填充肉的质量。

物理模型设计

分析类系统从逻辑数据模型设计到物理模型设计需要考虑的步骤三种考虑包括以下内容：

第一种考虑：为了提高效率的降范式考虑，其种策略包括：

• 1：减少逻辑分层：我们逻辑数据模型设计中谈到的主数据分类，采用父子类树状结构模型的策略，但是如果分层过多在访问过程种涉及到的关联操作会增加，所以通常物理模型实现过程中，2-3层比较合适，所以需要考虑在物理实现过程中减少层次，重点是把子节点的属性上升到父节点中。
• 2：属性重新调整：之前我们说属性表，可以分类存储，但是在现实过程中会存在某种属性过多，某些属性过少；某种属性更新频率很高，某种属性更新频率很低；某种属性访问频度很高；某种属性访问频度很低的问题。属性过多按照窄表存储策略，会导致表中记录数很多，对于分析系统就会影响批量处理的更新操作效率。因此在物理化的过程中，可以进行属性表的调整，某种属性过多的表可以按照更新频度和访问频度进行分拆控制；而某种属性过少的表也可以把属性进行合并存储。
• 3：增加适度冗余：如果我们把属性都按照单独分类，窄表存储的策略，确实可以保障扩展性，但是我们在现实访问的过程中，又发现某几类重要的属性，经常被一起访问。如果这些数据行被分不到了不同的属性子表中，则经常需要大规模的关联操作。这种情况下就需要把这些经常被关联访问的属性放在同一个物理表中，但是为了保证原来的属性维护，需要两边冗余存储。
• 4：关系表分表：对于某两类主体涉及到很多关系类型的时候，如果导致数据表过大，在加载和访问过程中造成效率的影响可以将关系表进行分拆，区分不同的关系类型，保存在不同的物理表中实现，这种分表也可以按照关系类型结合访问更新频率来考虑。

第二种考虑：物理化设计考虑，其中策略包括：

• 1：Hash主索引的选择：兼顾两个问题考虑，第一个考虑是用来作为Hash的主索引是否能够保证数据的平均分布，第二考虑，主索引是否有业务含义，在关联访问过程中经常用来作为关联键值使用。
• 2：分区的选择：通常为了进一步缩小数据检索范围，大部分分布式数据库都提供了分区存储策略，所以可以选择一个字段作为分区索引的选择，通常日期字段被选择为主，比如交易数据，通常选择交易日期作为分区字段，可以按照月，也可以按照日，按照日分区过多，分区过多并不是很好的策略。
• 3：其他索引的选择：在分布式数据库中可以增加其他索引类型，其实其他索引主要就是采用空间换取时间的策略了。这个可以根据每个数据库的特性，以及这个数据表是否经常按照其他非主索引机制进行访问的频度来灵活考虑。
• 4：数值压缩：目前的大部分数据库都提供了压缩技术，包括表压缩、列压缩、多值压缩等等，可以根据数据库特性和具体的字段情况选择压缩策略。
• 5：逻辑上的主外键关联关系是否在物理数据库中考虑？答案是不建议，因为基于数据库的强制性的主外键关联约束控制，会增加数据在批量加载过程中的负担。所以通常这种控制约束是在物理数据库实现的，而是通过加载程序的业务逻辑控制和数据质量检查等手段来保障的。

第三种考虑：作业处理逻辑考虑，其中策略包括：

在其他项目实践过程中，为了解决一个目标表来自于多张原表加工的作业控制，翻牌机制灵活性、作业回退、部分数据修复以及后续元数据精细化管理的问题，开始尝试在每张表中增加ETL物理控制字段，标准作业名称和数据来源的方法。确实ETL作业逻辑控制的灵活性和后续的元数据管理的灵活性提供了很好的基础。

生产系统的模型物理化策略是如何考虑？我们沿着这两类系统的作业类型差异化就可以找到答案。

• 1：生产系统的物理表，首先需要解决的是单笔数据增删改查的效率，所以采用B树索引策略，因此主键的选择一定沿着访问这个表的最主要的业务检索机制来设定。
• 2：生产系统在逐笔数据操作的过程中，每次的增删改查尽量希望针对一张业务主数据表进行操作，因此针对这张主表需要囊括各种类型属性信息，这就出现了过去我们看到很多系统中单个主表的存储字段动辄100-200个的局面。这种针对业务发生频度不高，性能压力不大的企业来说，没什么大的问题。而对于业务量很大，访问量很大的系统中的企业来说，那么我们需要考虑的是满足80%单笔增删改查操作过程中，需要访问，更新的属性包括哪些，这些属性需要集中在一张表中进行存储即可，而其他信息仍然可以参考逻辑数据模型设计。而这种2/8原则的区分策略减少单条记录的存储空间，可以更多利用内存的技术去缓存，提高作业处理效率。
• 3：对于主数据的分类分层存储策略，大部分生产系统最多采用两层架构，如果分类很少甚至可以直接将根节点逻辑化，根节点直接下沉到二级分类表的策略。
• 4：如果（3）和（2）结合使用，则会出现某些子分类的主数据属性对于另外一些子分类不适用的问题，而出现稀疏矩阵，即使在生产类系统中，我们也需要平衡稀疏矩阵的稀疏度，过度的稀疏仍然需要属性结合更新和访问频度进行拆表设计，减少频繁的主表操作过程中的负担。
• 5：生产系统中的关系保留策略，没有非但的必要性，通常不采用关系表保存策略，而是直接记录在主表中，作为主外键关系来保存。这种保存策略通常不保存多种关系。如果确实关系类型很多，可以在主表中通过主外键关联来保存后，其他关系采用关系表存储。其实这种策略在分析系统采用冗余策略的过程中也是一样可以做的。

另外还有其他一些针对生产业务系统设计过程中的规范化考虑，因为我在老兵第一篇中就提及了，不重复赘述。

最后我们探讨大数据平台下的物理建模策略优化。

针对大数据平台当前的技术特性，因为存储成本低，复杂关联操作能力有待提升的情况下，我们采用大数据平台建模策略就是空间换取时间的策略。具体考虑可以包括：

继续增加字段冗余，保证经常被关联访问到的字段信息在一张表中存储。
尽量做到按照业务分类的表分拆，某数据表中尽量只保留某种业务或者某种类型的数据主数据相关内容，减少字段的多义性，减少字段在被访问过程中需要关联识别的过程。
尽量做到中间结果和最终加工结果的物理存储，用空间直接换取访问效率。
对于数据量不大，更新频度和访问频度都很高的主数据信息表，甚至可以采用镜像累加的存储策略，而不采用历史拉链表的存储策略。
如果是采用Hbase的存储，因为是列存储策略，可以继续提高稀疏矩阵的稀疏度。
还有许多空间换取性能的策略，仍然要解决和数据的业务逻辑，数据更新策略、访问策略进行优化设计。

至此，针对数据新兵的模型入门篇，告一段落。