数据建模入门：概念模型-逻辑模型-物理模型-三层到底差在哪

今天讨论的是数据建模的”纵向”一一也就是说,数据建模要建成什么样才算到位?DAMA把模型分成三层一一概念、逻辑、物理,这个让我想到了数据库的设计模式,也是三层。我印象中好像是外模式、概念模式、内模式这三层,对应过来就是:外模式(用户看到的视图)≈概念模型,概念模式(整体的逻辑结构)≈逻辑模型,内模式(物理存储)≈物理模型。不过这个类比不一定完全准确,知道有这么回事就行。我刚开始看到这三个词的时候,以为是纵向展开的,但认真看完,DAMA给这三层的对应特别好记:-逻辑模型说"系统做什么"今天把这三层拆开,看看每一层该怎么画、给谁看、解决什么问题。一、概念数据模型:给业务看的"全景地图"概念模型是三层里最顶层、最抽象的,作用是用业务语言描述核心业务它长什么样?很简单：只有实体和关系，没有属性、没有主键、没有数这个教育系统的例子刚好戳中我，我平时就在跟这些字段打交道。说白了，它就是简化版的ER图——只画实体和关系，不画属性。你可以理解为：概念模型是ER图的"草图",逻辑模型才是完整的ER图。这让我想起前面曾说的，业务和技术对同一个指标理解都能差出天际，概念模型干的就是先把这事儿拉齐的活。设计要点：交付物：一张或多张实体关系图+核心术语定义表二、逻辑数据模型：给架构师看的"详细设计图"逻辑模型是在概念模型基础上进一步细化的，作用是详细描述业务数据学生有哪些属性(学号、姓名、出生日期、入学年份),主键是什么(学号),和其他实体的关系具体是什么(一个学生选修多门课，一门课被多个学生选修，多对多)。逻辑模型还有个重要活叫规范化，通常要做到第三范式(3NF)。3NF我在前面的文章里有专门提过，原来它就归在逻辑模型这一层——目的就是消除数据冗余，保证每个属性只在一个地方出现，避免数据不一致。下的还是候选键)·明确关系基数和元数(一对一、一对多、多对多)·做规范化，通常到3NF交付物：详细的实体关系图(含属性和键)+属性定义字典+业务规则说明三、物理数据模型：给开发人员看的"施工蓝图"物理模型是三层里最底层、最具体的，作用是把逻辑模型转化成能在具底层是Oracle、MySQL、MongoDB还是HBase,最终的物理模型也就是说，物理模型要根据采用的软件或应用不同而呈现不同的形式。物理模型要干的活，我一个一个说：1.解决逻辑抽象逻辑模型里可能会有一些抽象关系，比如"老师和学生都是人"这种继承关系。但在物理表里，没有"继承"这种东西，你得想办法把它转化成实际的表结构。常见的做法有两种：一种是合并成一张大表(把所有类型的公共属性和特有属性放一起),一种是拆成多张表(公共属性一张表，特有属性各自一张表)。指定表名、列名、数据类型、长度、是否允许空值、默认值等。表名列名通常用英文或缩写，因为数据库对命名长度有限制。比如逻辑模型里的"学生姓名",到了物理模型可能就变成stu_name3.指定代理键篇就记住了——建表默认先加自增ID,现在才知道它真正落地是在物理举个例子：学生的学号虽然是唯一的，但学号可能会变(比如转学后重新编号),所以物理表里通常再加一个自增ID作为真正的物理主键，4.逆规范化5.建索引和分区根据查询模式设计索引策略，对大表做水平或垂直分区。索引就是给数据建目录，查得快；分区就是把大表切成小块，管理起来更方便。设计要点：·选合适的数据类型和长度·考虑索引策略、分区策略据字典四、三层的关系与落地顺序三层不是各自独立的，是逐层细化的过程：概念模型→逻辑模型→物理模型→数据库落地顺序：先有概念，再有逻辑，最后物理。概念和逻辑属于需求分析阶段，物理属于设计阶段。但现实里很多项目会跳过概念模型，直接从逻辑甚至物理开始。我得承认，我之前做小程序就是直接从建表(物理层)干起的，跳了前面两层。现在回头看，难怪后来字段越加越乱、业务方一看表结构就懵——没有概念模型对齐认知，后期业务和技术理解偏差，返工是迟早的事。正向工程：从需求开始，依次建概念、逻辑、物理，最后生成数据库。最规范，适合新系统开发。逆向工程：从现有数据库反向生成物理、逻辑、概念模型。适合文档缺失的老系统改造。五、关系模型vs维度模型的三层对比不过，有看书的大家可能会发现，书中在每一层中都放了关系模型和维度模型两种图。这是因为两种建模思路会贯穿概念、逻辑、物理三层，我画了一张对比表，一目了然：模型实体+关系，比如"学生选修课程”事件+维度，比如"销售事实围绕时间、产品、客户"模型规范化到3NF,消除冗余事实表+维度表，允许适度冗余模型多张关联表，外键约束一张大事实表+若干维度表，星型或雪花结构换句话说，从概念层开始，你就要想清楚：这套模型将来是给事务系统用(走关系),还是给分析系统用(走维度)。这个选择会影响后面两如果还是不确定怎么选，回到第⑤篇和第⑥篇的六、补充几个你可能想问的点Q1:这三层一定要全部做吗?不一定。小项目、简单业务，直接从逻辑甚至物理开始也问题不大。但业务越复杂、涉及角色越多，跳过概念模型的哪怕不正式画图，至少在脑子里过一遍"核心业务概念有哪些、它们之间什么关系”,再开始建表。Q2:概念模型和逻辑模型能不能合并?Q3:物理模型做完就结束了吗