数据模型的目的在于可视化呈现、设计业务/系统的数据交互/存储的结构和方式，识别实体及其属性、关系，方便业务人员和技术人员沟通和承接。数据结构按照信息细节度和技术性划分概念模型(Conceptual Data Model)、逻辑模型(Logical Data Model)和物理模型(Physical Data Model)，抽象程度依次降低，技术性质依次增强，适用对象从业务人员转向技术人员。

理论上讲，概念模型和逻辑模型一般给领导、业务看；从实际经验来，技术人员一般拿建模工具直接做物理模型，这些工具也可以展现数据的关系模型，完稿时生成和导出DDL(Data Definition Language，数据定义语言，主要是CREATE)并建立库表。同时，一般的数据库客户端都具备数据库的逆向实体关系图生成能力，也就是从既有的数据库中反向生成物理模型。

三种数据模型比较

三种数据模型

模型	概念模型	逻辑模型	物理模型
面向人员	业务	业务	技术
目的	识别业务实体及关系	丰富补充以建立物理模型	建立数据库的库表
实体名称	√	√	×
实体关系	√	√	×
实体属性	可选但不完整	有但不完整	×
描述语言	业务意义	业务意义	技术意义
数据库相关	×	×	√
表及其列	×	×	√
列及其数据类型和约束	×	×	√
主键和外键	×	×	√
索引和存储过程等	×	×	可选
数据元素	业务元素	更多业务元素	业务元素+技术元素

概念模型和逻辑模型都是业务用语，而物理模型是用技术实现的方式来表达业务意义，具有比如varchar(256)、更新时间(update_time)等数据类型及长度的约束、技术配套字段。其中概念模型和逻辑模型之间的界限比较模糊，主要体现在数据丰富度上，实际操作时不用太纠结。

实体关系区分一对一、一对多和多对多，以及之间的业务动作，在面向对象(Object Oriented)和实体关系(Entity Relationship，E-R)这两种建模技术中可以体现业务动作和数量关系，其他建模技术不好体现。

五种数据建模方式

数据建模(Data Modeling)技术与用于系统软件架构设计的UML(Unified Modeling Language，统一建模语言)可以相提并论。其包含五种数据建模方式或者叫数据模型种类，分别为层级(Hierarchical)、网状(Network)、面向对象(Object Oriented)、实体关系(Entity Relationship)、关系(Rational)。其中的面向对象数据模型和UML的用例图有点像。而实体关系图和关系图是最常用的方式，前者可用于系统软件的概要设计阶段，后这可用于详细设计阶段。

备注：E-R图(Entiry Relationship Digram，ERD，实体关系图)日常使用、称呼上包括了关系模型(Rational)和实体关系模型(Entity Relationship)两种方式，也可能泛指了以上5种方式，甚至更偏向于关系模型。这里不纠结。我的理解是，这五种建模方式都可以用来做概念模型，不一定能或者适合做逻辑模型，只有关系模型能用来做物理模型(全文针对关系数据库RDBMS来说)。

1、层级 

这里借图，表达的是一个概念模型，局限比较多，如只能一对一或者一对多，有点像二叉树。

2、网状

 这里借图，表达的是一个概念模型，虽然解决了不能多对多的问题，但是数据量大的时候这个图就非常庞大，不易读。

3、面向对象

这里借图，表达的是一个概念模型，但可以体现业务动作和数量关系，不过是站在一个业务对象的视角来画图，对象多了估计整个图就不好画、不好看了。

4、实体关系

这里借图，表达的是一个逻辑模型，很好的体现了实体及其业务动作、数量关系。其中矩形表示实体，圆圈表示实体属性，菱形表示实体之间的关系，关系连线上的数字就是数量关系。一对一用1表示，一对多用1:M表示，多对多用N:M表示。反过头来看看，如果实体和属性太多，整个图就会五颜六色、枝繁叶茂、群魔乱舞，不过用实体关系图非常适合做概念模型和逻辑模型。

5、关系

 这里借图，表达的是一个物理模型，业务对象名已经更换为表名(英文)，属性更改为了列(英文)，且列有字符类型、长度，有主键、外键，根据建模工具功能还可以添加索引等元素。这里的实体数量关系使用了特别的符号，具体见下图的解释。关系模型有个缺点，就是不能表达业务动作，不过在做技术落地实现的时候，业务逻辑可以体现，不用在数据层面体现。再说数据库客户端可以正向逆向生成库表和关系模型图，这个让DBA、开发很喜欢，也是最常用的数据建模方式。

三种数据模型示例

通过上面的五种数据建模方式的配图，可以看到三种数据模型的样子。

数据建模工具举例

数据建模工具非常多，只要是能画上面的图的任何工具都可以，比如Powerpoint也可以拿来画实体关系图，不过类似用记事本写代码，没有那边边界。数据建模有非常多的专业工具，一般的流程图软件支持实体关系图、UML图等，但用来形成物理模型的关系模型需要更加专业的工具，它们可以导出生成SQL语句(DDL)。下面就列举些关系模型的建模工具。

• PowerDesigner（收费）
• erwin（收费）
• PDMan（开源）

参考文档

What Is Data Modeling – Conceptual, Logical, Physical Models

Data Modeling: Conceptual vs Logical vs Physical Data Model

Data Modelling: Conceptual, Logical, Physical Data Model Types

What Are Conceptual, Logical, and Physical Data Models?

数据模型

数据模型是由数据结构、数据操作和数据完整性约束条件组成的。（所有的数据模型从这三类要素进行研究）

1）数据结构：

数据结构描述数据库的组成对象以及对象之间的联系。

2）数据库操作：
数据操作是指对数据库中各种对象的实例允许执行的操作集合，包括操作及有关操作规则。

3）数据库完整性约束条件：
数据的完整性约束条件是一组完整的规则。

数据模型按不同的应用层次分成三种类型：分别是概念数据模型、逻辑数据模型、物理数据模型。

1、概念模型（Conceptual Data Model）：是一种面向用户、面向客观世界的模型，主要用来描述世界的概念化结构，它是数据库的设计人员在设计的初始阶段。

2、逻辑模型（Logical Data Model）：是一种面向数据库系统的模型，是具体的DBMS所支持的数据模型。

3、物理模型（Physical Data Model）：是一种面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。
 

概念模型（是什么？）

基本概念：

（1）实体（entity）：客观存在并可相互区别的实物称为实体。

        实体可以是具体的人、事、物，也可以是抽象的概念或联系，例如：一个职工、一个学生等是实体。
（2）属性（attribute）：实体所具有的某一个特性称为属性。

        一个实体可以由若干个属性来刻画。一个学生实体可以由学生号、姓名、出生年月等，属性组合（2019001，张三，男，19940505）即表征了一个学生。
（3）码（key）：唯一标识实体的属性集称为码。

        例如学号是学生实体的码。
（4）实体型（entity type）：具有相同属性的实体必然具有相同的特征和性质。

        用实体名及其属性名来抽象和刻画同类实体，称为实体型，如学生（学生号、姓名、出生年月）就是一个实体型
（5）实体集（entity set）：同一类型实体的集合称为实体集。

        例如全体学生就是一个实体集。
（6）联系（relationship）：实体之间的联系是指不同实体集之间的联系。

单个实体内部的联系也有一对一、一对多、多对多的关系

一对一：实体集A中每一个实体，实体集B中至多有一个（也可以没有）实体与之联系，反之亦然，则实体集A与实体集B具有一对一关系。

独生子女家庭是一个实体，一个爸爸有一个孩子，一个孩子也有一个爸爸

一对多：实体集A中每一个实体，实体集B中有n个实体（n>=0）与之联系，反之，实体B中的每一个实体，实体集A中至多只有一个实体与之联系，则实体A与B有一对多联系。

员工是一个实体，员工中存在着领导与被领导的关系。一个具有领导地位的员工可以领到多个员工，而普通员工只能被一个员工领导

多对多：实体集A中每一个实体，实体集B中有n个实体（n>=0）与之联系，反之，实体B中的每一个实体，实体集A中也有M个实体，则实体A与实体B具有多对多联系。

例如：

1、零件是一个实体，零件中有大零件和小零件。一个大零件可以有很多小零件来构成，一个小零件也可以构成许多种类型的大零件。

2、一门课程有若干个学生选修，而一个学生同时选修多门课程，则课程实体与学生实体具有多对多联系。

三个实体内部的联系 （实体型之间的多对多联系和三个实体型两两之间的多对多联系）

实体型之间的多对多联系：供应商、项目、零件之间的关系。

一个供应商可以供给多个项目多种零件，每个项目可以使用多个供应商供应的零件，每种零件可以有多个不同的供应商供给。但是项目和零件之间没有联系。就是有一种联系、三种相关

三个实体型两两之间的多对多联系：银行、贷款、存款之间的关系。

一个银行可以为许多人提供贷款服务和存款服务，一个人也可以到多个银行贷款和存款。但是存款和贷款可以以私人借贷的联系存在。就是有三种联系。
 

概念模型是对信息世界的建模，实体——联系方法（Entity—Relationship approach）：

E-R模型用矩形框表示现实世界中的实体，用菱形框表示实体间的联系，用椭圆框表示实体和联系的属性，对于作为实体标识符的属性，在属性名下画一条横线

实体与相应的属性之间，联系与相应的属性之间用线段连接

联系与其涉及的实体之间也用线段连接，同时在线段旁标注联系的类型（1:1  ,  1：n  ,  m:n）
 

逻辑模型（做什么？）

逻辑模型就是要将概念模型具体化，就是要实现概念模型所描述的东西，需要哪些具体的功能，处理哪些具体的信息，是对概念模型的进一步细化。

　　以销售业务为例：“客户”信息基本上要包括：

        单位名称，联系人，联系电话，地址等属性；“商品”信息基本上要包括：名称，类型，规格，单价等属性；

        “定单”信息基本上要包括：日期和时间属性。并且“定单”要与“客户”，“业务员”和“商品”明细关联。

　　系统需要建立几个数据表：业务员信息表，客户信息表，商品信息表，定单表。

　　系统要包括几个功能：业务员信息维护，客户信息维护，商品信息维护，建立销售定单 。

常用的逻辑模型有层次模型，网状模型和关系模型三种。

（1）层次模型（倒转的树）（被淘汰，现少用）

1）有一个节点没有父节点，这个节点即根节点。

2）其他节点有且仅有一个父节点。

缺点：不能直接表示多对多的实体联系，必须分解为几个一对多的联系才能表示出来

（2）网状模型（被淘汰，现少用）

1）可以有一个以上的节点无父节点。

2）至少有一个节点有多于一个的父节点。

（3）关系模型（现在用）

关系模型是用二维表格来表示实体及其相互之间的关系，每个二维表称为一个关系。每个关系均有一个名字，称为关系名。

重点研究了关系模型的

数据结构：实体与实体之间的联系都用关系来表示，而关系就是一张规范化的二维表，关系模型中的数据项不能再分，不能出现表套表的情况

数据操作：查找（）、插入（insert）、删除（）、修改（）

完整性约束条件：（三类完整性）

实体完整性、参照完整性、用户定义的完整性

物理模型（怎么做？）

　　物理模型是对真实数据库的描述。

        如关系数据库中的一些对象为表、视图、字段、数据类型、长度、主键、外键、索引、约束、是否可为空、默认值。

　　在具体的物理介质上实现出来。如：数据库使用SQL Server 2000，这样就可以编写具体的SQL脚本在数据库服务器上将数据库建立起来。其中包括业务员信息表，客户信息表，商品信息表，定单表。

数据独立性研究的就是：应用程序与数据（数据逻辑独立性和数据物理独立性）的独立关系

数据库系统（DBS）>  数据库（DB）> 数据库管理系统

 

概念模型向逻辑模型的转换

1.实体的转换

2. 联系的转换

1:1联系的转换

1:n联系转换

n:m联系的转换

注意：
之前在创建表的时候，存在很多的外键，导致很多的级联删除，导致删除这个，需要删除另外一个表中的数据，而另外一个表中的数据删除会出现问题，导致不能删除，各种限制，今天看见了阿里巴巴开发手册（2022-02-27），恍然大悟：

强烈建议不使用外键，在应用层可以解决外键的问题。