本文详述了SQL数据库设计的过程，从理解需求、概念建模、逻辑建模到实体建模，涵盖主键、外键、数据库规范化等方面。通过实例介绍了如何处理多对多关系、数据冗余及数据库规范化的重要性，旨在帮助读者掌握如何创建结构良好的数据库。
目录
十三章·上 ：设计数据库 Designing Databases
1. Understand the requirements 理解需求
2. Build a conceptional model 概念建模
4. Build a physical model 实体建模
8. 外键约束 Foreign Key Constraints
9.1. 第一范式 First Normal Form, 1NF
9.3. 第二范式 Second Normal Form, 2NF
9.4. 第三范式 Third Normal Form, 3NF
10.2. 不要对什么都建模 Don't Model the Universe
11. 正向搭建数据库 Forward Engineering a Model
12. 使用数据库同步模型 Synchronizing a Model with a Database
13. 反向搭建数据库 Reverse Engineering a Database
1、航班订票系统 Project Flight Booking System
1.1. 解答：概念模型 Solution Conceptual Model
1.2. 解答：逻辑模型 Solution Logical Model
2、视频租赁应用 Project Video Rental Application
2.1. 解答：概念模型 Solution Conceptual Model
2.2 解答：逻辑模型 Solution Logical Model
十三章·上 ：设计数据库 Designing Databases
1. 介绍 Introduction
之前都是对已有数据库进行查询，这一章学习如何设计和创建数据库（以及表格）。
设计一个结构良好的数据库是需要耗费不少时间和心力的，但这是十分必要的，设计良好的数据库可以快速地查询到想要的数据并且有很好的扩展性（很容易满足新的业务需求），相反，一个设计糟糕的数据库可能需要大量维护且查询又慢又麻烦，Mosh之前的一家公司的数据库就做得很糟糕，有些储存程序有上千行代码而且有些查询执行时间长达数分钟，所以，拥有设计良好的数据库是非常重要的。
这一章将系统性地逐步讲解如何设计一个结构良好的数据库
2. 数据建模 Data Modelling
这一节讲数据建模，即为想要储存进数据库的数据建立模型的过程，其中包含4步：
1. Understand the requirements 理解需求
第1步是理解和分析商业/业务需求，遗憾是很多程序员跳过了这一步就急着去设计数据库里的表和列了，实际上，这一步是最关键的一步，你对问题理解的越透彻，你才越容易找到最合适的解决方案，设计数据库也一样。所以，在动手创建表和列之前，要先完整了解你的业务需求，包括和产品经理、行业专家、从业人员甚至终端用户深入交流以及收集查阅与该问题领域相关的表、文件、应用程序、数据库，以及其他相关的任何信息或资料
2. Build a conceptional model 概念建模
当收集并理解了所有相关信息后，下一步就是为业务创建一个概念性的模型。这一步包括找出/识别/确认（identify）业务中的 实体/事物/概念（entities/things/concepts）以及它们之间的关系。概念模型只是这些概念的一个图形化表达，用来与利益相关方交流和达成共识
3. Build a logical model 逻辑建模
创建好概念模型后，转而创建数据模型（data model）或数据结构（data structure for storing data），即逻辑建模。这一步创建的是不依赖于具体数据库技术的抽象的数据模型，主要是确认所需要的表和列以及大体的数据类型
4. Build a physical model 实体建模
实体建模指的是将逻辑模型在具体某种DBMS上加以实现的过程，相比于逻辑模型，实体模型会确定更多细节，包括各表主键的设定，各列在某一DBMS下特定的具体的数据类型，是否有默认值，是否可为空，还包括储存过程和触发器等对象的创建。总之，实体模型是在某一特定DBMS下对数据模型非常具体的实现
以上就是数据建模的流程
3. 概念模型 Conceptual Models
案例
想要建一个销售在线课程的网站，用户可以注册一项或多项课程，课程可以有诸如 "frontend（前端）" "backend（后端）" 这样的标签
对于一个线上课程网站来说，重要的概念/实体有哪些？很容易想到有学生（student）和课程（course）
我们需要一种将实体及其关系可视化的方法，一种是实体关系图（Entity Relationship, ER），一种是统一建模语言（Unified Modeling Language，UML），这里我们用实体关系图（ER），使用的工具是 http://draw.io
步骤如下：
- 建立学生实体并确定相关属性，如姓名、电子邮件、注册时间
- 建立课程实体并确定相关属性，如课程名、价格、老师、标签
- 建立两个实体间的关系，暂时先用多对多连线（概念模型里只是画好连线，逻辑建模时再考虑连线的类型），加上 enrolls 标签表示两者间的关系是“学生→注册 →课程”
注意
建模是个迭代过程，不可能第一次就建立完美模型，需要在理解需求和模型设计之间不断反复，多次调整。比如这里的学生属性，可以先确定个大概，之后可以根据需要再进行增删修改
小结
概念模型主要是从很高的视角来总览业务需求，识别业务中的实体/事物/概念以及他们彼此间的关系，通常这些实体包括人、事件、地点等
这一步暂不考虑数据类型和具体的DBMS这样的技术细节，只是从概念上总揽全局，目的是和业务人员交流，保持理解一致，避免鸡同鸭讲
4. 逻辑模型 Logical Models
案例
接前面线上课程网站的例子，对概念模型逻辑化的过程如下：
1. 细化实体间关系：
考虑学生和课程的关系，首先这是一种多对多关系（通常意味着需要进一步细化），其次了解到业务上有如下需求：
- 需要记录学生注册特定课程的日期
- 课程价格是变化的，需要记录学生注册某门课程时的特定价格
这些属性相对于学生和课程而言都是一对多关系，不管放在学生还是课程身上都不合适，所以，应该为学生和课程之间的关系，即 注册课程的事件 本身另外设立一个实体 enrollmemt，上面的注册日期和注册价格都应该是这个 enrollment 注册事件 的属性
2. 调整字段并大体确定字段的数据类型：
姓名（name）最好拆分为姓和名 (first_name 和 last_name)，同理，地址应该拆分为省、市、街道等等小的部分，这样方便查询。注意课程里的 tags 标签字段不是一个好的设计，之后讲归一化时再来处理
这里的数据类型只需确定个大概即可，如：是 string，float 而非 VARCHAR, DECIMAL。等到下一步实体模型里再来确定某个DBMS下的具体数据类型
逻辑模型是在概念模型的基础上，在不依赖特定数据库系统的前提下确定数据结构，包括细化实体间的关系（常常要为关系创造新的实体），调整字段设置，确定大体的数据类型。总之，逻辑模型会基本确立数据库中的表、列以及表间关系。
5. 实体模型 Physical Models
实体模型就是逻辑模型在具体DBMS的实现，这里我们用MySQL实现前面线上课程网站的逻辑模型
在 Workbench-file-new model 新建数据库模型，右键 edit 修改数据库名字为 school
上方用 add diagram 作 EER 图，这里 EER 表示 Enhanced Entity Relationship 增强型实体关系图。为三个实体创建三张表，设定表名、字段、具体的数据类型、是否可为空（即是否为必须字段？），是否有默认值（主键设定之后再讲）。有几个注意点：
- 表名：
之前逻辑模型里表名用单数，但这里表名用复数。这只是一种惯例，单复数都行，关键是要保持一致。
如果团队有相关惯例就去遵守它，即便那不够理想，也别去破环惯例，否则沟通和维护成本会大大增加，你需要不断去想该用单数还是复数 - 字段名：
以 enrollments 表为例，注册事件的属性应该是 date日期 和 price价格 而非 enrollment_date注册日期 和 enrollement_price注册价格，不要将表名前缀加上字段上造成不必要的麻烦，保持精简（keep things simple） - 数据类型：
数据类型要根据业务需要来，例如，和业务人员确认后发现课程价格最高是999美元，所以 price价格 就可以设定为 DECIMAL(5,2)，之后如果需求变了了也可以随时更改，不要一上来就设定DECIMAL(9,2)，浪费磁盘，注意尽可能节省空间（keep things small）
小结
实体模型是逻辑模型在特定DBMS上的实现，主要是一些技术上的细化，包括确定字段具体数据类型和性质（能否为空等），设置主键等
6. 主键 Primary Keys
主键就是能唯一标识表中每条记录的字段
设定 students 表的主键：
不管是 first_name 还是 last_name 都不能唯一标识每条记录，它们两个合起来作为联合主键也不行，因为两个人全名相同也是可能的（都叫 Tom Smith）。Email 也不适合作主键，首先太长了，之后需要作为外键复制到其他表会很浪费资源，而且 Email 也可能改变。
总之主键要短，可唯一标识记录，且永不改变。我们增加一个 student_id 作为主键，类型设为 INT（最大可表示2亿，一般足够了，但记得总是根据具体的需求决定），设为主键后自动变为不可为空，另外还要设定 AI（Auto Incremental）自动递增，这样会方便许多，不要担心主键唯一性的问题，最后我们把主键拖到表的第
最低0.47元/天 解锁文章
扫一扫
1534
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
