数据库建模和设计的总结

自己整理目录，然后从网上参考其他资料（因为懒，所以直接COPY过来使用）或者自己补充，感谢他们！！

目录

1、数据库建模的过程：概念模型->逻辑模型->物理模型

2、概念模型：ER模型

2.1、ER的实体

2.2、ER的属性

2.3、ER的关系

3、逻辑模型：对概念模型的进一步细化

3.1、逻辑模型的设计方式——三范式

3.1.1、第一范式

3.1.2、第二范式

3.1.3、第三范式

3.2、其他注意事项

4、物理模型：物理机器的具体实现

---

1、数据库建模的过程：概念模型->逻辑模型->物理模型

        

2、概念模型：ER模型

概念模型的用途:

• 概念模型用于信息世界的建模

• 是现实世界到机器世界的一个中间层次

• 是数据库设计的有力工具

• 数据库设计人员和用户之间进行交流的语言

对概念模型的基本要求:

• 较强的语义表达能力

• 能够方便、直接地表达应用中的各种语义知识

• 简单、清晰、易于用户理解

2.1、ER的实体

客观存在并可相互区别的事物称为实体。可以是具体的人、事、物或抽象的概念。

2.2、ER的属性

数据对象所具有的属性、特性等，例如学生具有姓名、学号、年级等属性。

2.3、ER的关系

现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系。

具体的关系：

1对1（1:1）

1对多（1:N）

多对多（M:N）

具体举例：

完整的E-R举例：

3、逻辑模型：对概念模型的进一步细化

逻辑模型主要包括网状模型、层次模型、关系模型、面向对象模型等，按计算机系统的观点对数据建模，用于DBMS实现。

数据模型由三部分组成：数据结构、数据操作和数据约束。

　　(1)数据结构：数据结构主要描述数据的类型、内容、性质、以及数据之间的联系，是整个数据模型的基础，而针对数据的操作和数据之间的约束都是建立在数据结构的基础上的；

　　(2)数据操作：主要定义了在相应的数据结构上的操作类型和操作方式（数据库中的增删改查等）；

　　(3)数据约束：数据约束主要用来描述数据库中数据结构之间的语法、词义联系以及彼此之间的相互约束和制约关系（如MySQL中使用外键保证数据之间的数据完整性

逻辑数据模型的内容包括所有的实体、实体的属性、实体之间的关系以及每个实体的主键、实体的外键（用于维护数据完整性）。其主要目标是尽可能详细的描述数据，但是并不涉及这些数据的具体物理实现。逻辑数据模型不仅会最终影响数据库的设计方向，并最终会影响到数据库的性能（如主键设计、外键等都会最终影响数据库的查询性能）

3.1、逻辑模型的设计方式——三范式

规范的的数据库是需要满足一些规范的来优化数据数据存储方式。

3.1.1、第一范式

当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求。通俗的讲：数据库表中的所有字段值都是不可分解的原子值。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。

3.1.2、第二范式

如果关系模式R满足第一范式，并且所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。通俗的说：第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键（主键=订单编号+商品编号）相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。

而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可

3.1.3、第三范式

需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关

比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）这样一个表结构，就存在上述关系：学号--> 所在院校 --> (院校地址，院校电话)

这样的表结构，我们应该拆开来，如下。

（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）。

比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。

3.2、其他注意事项

• 字段冗余，业务上的高频率字段可以冗余在其他表上，减少表关联查询。
• 业务上考虑，允许存在传递依赖，满足第二范式，不满足第三范式。目的是防止出现表膨胀，以及业务常用的数据SQL查询次数增加或关联查询。
• 增加一些必要的非业务字段。比如创建时间、更新时间、是否删除、版本号，以及某个业务操作的时间记录、操作人记录等。尽量做到操作可追溯。
• 索引的增加，索引是数据库设计必须要考虑的，增加的规则：表的主键、业务上常用的字段等。
• 表名、字段名、索引名要规范。
  • 表名设计时考虑增加模块的前缀。
  • 字段名设计时字段名可读，保持一致的规则，比如：主键都是XX_ID结尾，时间都是XX_DATE结尾或者XX_AT，操作人、更新人、审核人等都是XX_BY,XX_UID。整个数据库统一规则
  • 索引名规范，比如：IDX_表名_字段名表示对应的索引
• 字段类型要统一。比如主键都是BIGINT类型，字典都是INT类型。
• 增加字典表。考虑业务上的字段是否是枚举类型，如果是枚举类型，尽量使用字典保存数值。好处是：1、数字类型存储更小、过滤更快 2、业务上修改描述时，改动最小
• 数据库层面的外键约束、触发器、存储过程等都尽量不要使用。考虑业务层代码上实现相同的功能。业务层代码上实现的更容易维护、扩展等，后期有效率问题时也更容易通过其他方式解决。

4、物理模型：物理机器的具体实现

物理模型是概念数据模型和逻辑数据模型在计算机中的具体表示。该模型描述了数据在物理存储介质上的具体组织结构，不但与具体的数据库管理系统相关，同时还与具体的操作系统以及硬件有关。

可以通过物理模型直接生成对应数据库的SQL，也在此模型上调整对应数据库特有的内容。比如Oracle的表空间等。