目录
-
- 写在最前
- 一、 强实体与弱实体的定义
-
- 1. 强实体
- 2. 弱实体
-
- 百度百科中的解释
- 《数据库系统课程》中的解释
- 总结起来
- 二、 关于定义的几个疑惑
-
-
- 什么叫“依赖”？
- 先有鸡还是先有蛋？
- 为什么要定义弱实体？
- 什么时候需要定义弱实体？
- 总结起来，以上四个问题其实是一个问题：
-
- 三、 唯有实践，方出真知
-
-
- 教务系统数据库设计（一）
- 培训公司数据库设计
- 教务系统数据库设计（二）
-
- 四、 对强实体与弱实体的总结
写在最前
数据库设计是困难的，其原因之一就在于我们很难去完全把握实体的定义。是不是实体、该不该定义实体是一直困扰数据库初学者的问题，强实体、弱实体的概念同样难以理解。
我一直深受强实体、弱实体概念的困扰，百度百科中的定义不能很好地解决我的困惑，一路学习过来，自己对强实体、弱实体的理解越来越深入，因此写下这篇文章与大家分享自己对强实体与弱实体的一些体会。如果觉得有帮助，请点赞鼓励！
一、 强实体与弱实体的定义
1. 强实体
其实例的存在不依赖于任何其他实体类型的实例；有自己独立的主键，唯一性地标识它的每个实例。
2. 弱实体
百度百科中的解释
一个实体对于另一个实体（一般为强实体，也可以是依赖于其他强实体的弱实体）具有很强的依赖联系，而且该实体主键的一部分或全部从其强实体（或者对应的弱实体依赖的强实体）中获得，则称该实体为弱实体。
《数据库系统课程》中的解释
其实例的存在依赖于其它实体类型的实例；其主键包括它所依赖的实体类型的主键。
总结起来
百度百科中的解释和课程中的解释都是在强调两点：
第一点：依赖，弱实体应该依赖于强实体；
第二点：主键，弱实体的主键应该是组合主键（其他实体的主键组成的）。
二、 关于定义的几个疑惑
但定义中有几个地方令我不解，我相信初学者多少也会遇到同样的问题。我总结了四点：
什么叫“依赖”？
以教务系统数据库为例，如果没有学校，那么学院不再是学院，学生不再是学生，课程更将不复存在，所以这些实体都依赖于其他实体，因此这些都是弱实体？但我们知道，学院、学生一般都作为强实体。因此，定义中的“依赖”指的是什么呢？
先有鸡还是先有蛋？
是因为一个实体的主键包括其他实体的主键而使该实体成为了弱实体，还是因为一个实体是弱实体，所以它的主键必须包括其他实体的主键？
这是一个先鸡（弱实体）还是先蛋（组合主键）的问题。
为什么要定义弱实体？
我们知道，弱实体对于另一个实体具有很强的依赖联系，似乎并不是“真实”存在的事物，那么为什么我们还会有弱实体的概念，而不是直接认为实体就是强实体呢？
什么时候需要定义弱实体？
有时候弱实体就是需求中的实体，只是它依赖于其他实体，有时候关系也可以认为是弱实体，有时候出于设计的需要我们也会定义弱实体，那么何时需要定义弱实体？
总结起来，以上四个问题其实是一个问题：
怎样正确地理解强实体与弱实体的含义？
三、 唯有实践，方出真知
有很多事情是很难想明白的，但经过几次数据库设计实战，我发现自己或多或少地定义了一些弱实体。我选取了三个典型的例子：
教务系统数据库设计（一）
之后我会专门写一篇博客介绍教务系统数据库的设计过程，这里选取其中一个比较典型的部分。业务需求是这样的：
一周有七天，每一天有11节。
上面这句话中涉及到了几个实体？很简单吧，三个实体：周、天、节。那么它们是强实体还是弱实体呢？不好说，但是我们可以确定，概念数据模型的设计应该是这个样子：
需要勾选“Dependent”。首先回答一个问题：为什么不能是下面这个样子？
Day的主键应该是dayOfWeek，如果不用“Dependent”将Day的主键改为weekNum+dayOfWeek，我们的Day表格中只能有七行记录，也就是说对于某一个星期一，我们无法区分这是第几周的星期一！同样的道理，如果Section的主键仅仅为sectionNum，那么我们根本无法区分这一节课是哪一天的课！教务系统要有排课、选课功能，只知道第1节，但不知道是哪一天的第一节，这肯定是不可以的。
因此，当我们想要找到某一节时，需要同时指定那一周、星期几、哪一节。比方说我可以把《数据库设计》这门课安排在第一周星期一三四节。
在这个例子中，三个实体都是需求中明明白白告诉我们的实体，但我们将Day与Section都作为了弱实体，因为强实体的Day与Section根本无法满足需求。
培训公司数据库设计
业务需求是这样的：
每位学生每期只能参加一门课程。
言外之意，公司有很多课程。我们只分析“每位学生每期只能参加一门课程”这一需求，发现涉及到两个实体：学生、课程。所以我们或许会想当然地这样去设计数据库：
一个课程可以由多个学生选择，一个学生只可以选择一门课程。发现问题了吗？业务需求里不是说一个学生只能参加一门课程，而是说一个学生在一期只能参加一门课程！这么设计数据库是在断人家财路。因此，我们必须考虑“每期课程”这个概念：
看样子似乎是没问题了，但是数据库设计是不可能这么容易就没问题的。我们把每期课程都作为一个记录，那么对于课程的信息，比方说课程名称、价格、介绍，每开一期课就要向数据库中存一行记录，因此我们的数据库会出现大量冗余（也就是说不满足数据库第二范式）。因此，我们应该这样去设计数据库：
看到了吗？这里的“Record”是一个弱实体，它的主键是“学期主键+学生主键”，代表学生参加课程这一行为，抽象成为了弱实体。为什么要用学期表的主键和学生表的主键呢？因为一个学生、一个学期，那么就只能参加一门课程了，所以根据主键唯一标识每行记录的原则，应该这样去选取。课程表的主键成为了Record表的外键，课程表与Record表之间存在一对多关系。
在这个例子中，学生、课程是业务需求描述中显而易见的实体，“期”也可以认为是比较明显的实体，但“参加”这个动词在我们的数据库中便成为了“参加记录” ，也就是Record实体。
教务系统数据库设计（二）
这一部分的业务需求是这样的：
老师授课。
似乎业务需求很简单，但事实上，多位老师可以独立上同一门课，也可以共同上同一门课。一位老师可以参与多门课的授课。真实的教务系统的确是这个样子的。一般，像马原、高数等课程是多位老师独立授课，专业核心课大多是多位老师共同为同一班级授课。那么数据库要怎样设计呢？
像这样吗？老师、课程之间建立多对多关系？不难发现，这样的多对多联系无法区分上面所说的两种授课情况。也就是说，我们必须引入第三个表，才有可能实现业务需求，两张表格是行不通的。我是这样设计的：
在课程表与老师表之间，引入了新的一张表格——排课表。一个课程可以安排多次排课，一个排课就对应一个独立的授课安排，可以由一位老师完成，也可以由多位老师完成。那么像马原授课这种多位老师独立授课的情况该如何解决呢？在排课表中，认为不同老师的马原课是同一课程（引用Course表中同一记录的主键作为外键），但是它们是不同的排课（ArangeNo不同，可能一个是1，另一个是2）。也正因如此，排课表的主键是组合主键（课程编号+排课编号，如CS163、1）。
这个例子中，需求中并没有提“排课”这一实体，这个实体完全是我们为了满足需求而定义的，甚至它和课程表在概念上还有点关系。注意到了吗，这里的“关系”就是弱实体概念中所说的“依赖”！
四、 对强实体与弱实体的总结
- 区别弱实体与强实体的关键在于主键，“依赖”的实质是主键之间的关系。所以归根到底，就一个主键之间是否有关系、主键是否是组合主键的问题。
- 弱实体与强实体可以相互转换，没有绝对意义上的强与弱。既然区别弱实体与强实体的关键在于主键，那么一个同样意义的表，当我给它一个编号作为主键，那么它就不是弱实体，而如果我令它的主键是组合主键，它就是弱实体。就像刚刚，我们说排课表的主键是组合主键（课程编号+排课编号，如CS163、1），所以它是弱实体，那么如果我定义排课编号是“CS16301”，而不再是“1”，那么它的主键（排课编号）就不再需要课程编号，它就成为了强实体。
- 弱实体也可以依赖于弱实体。就像第一个例子中的Session，它依赖于Day，Day就是一个弱实体。
- 弱实体与它所依赖的实体之间的关系只能是1：1或n：1。也就是说，一个弱实体实例不可能依赖于同一实体的多个实例。这个其实很好理解，因为如果弱实体实例A依赖于实例B，那么A的主键要包括B的主键，所以A当然不可以依赖于很多个B。
-
业务需求决定弱实体的定义，分三种情况：
情况一、 业务需求中明确的弱实体
情况二、 业务需求中隐含的弱实体
情况三、 业务需求中无、但为实现业务需求不得不定义的弱实体
如果觉得这篇文章对你有帮助，请给博主点个赞！