数据库设计
- 1. 【面向对象设计】根据设计范式对【课程对象】逻辑建模
- 2. 【面向对象设计】根据设计范式对【课程列表对象】逻辑建模
- 3. 【面向对象设计】根据设计范式对【用户对象】逻辑建模
1. 【面向对象设计】根据设计范式对【课程对象】逻辑建模
前面我们分析过，课程对象包括属性有课程的主标题，方向，分类，难度，最新课程，最热课程，时长，简介，人数，需知，讲师的昵称，讲师的职位，课程的图片，综合评分，课程的内容实用性，简单易懂的程度以及逻辑清晰的程度 所进行的评分。
那么这些属性跟第三范式我们需要怎么来存储？
我们首先可以把课程对象拆分成课程表，那么前面已经分析过了课程表可以使用课程的主标题来作为业务主键来使用。
那么我们来看一下哪些属性是和课程主标题，也就是主键存在直接依赖关系的呢？
前面已经说过了，课程的技术方向，技术分类以及课程的难度，这几个属性都是直接从课程表的业务主键，课程的标题相依赖的。
那么课程是否是最新的属性，实际上我们可以通过课程的上线时间来计算得出，而业务上可以规定上线多长时间内的课程，我们就可以定为最新的课程。
所以我们这里使用上线时间属性来代替是否为最新的属性，
同样最热属性，也可以根据学习人数来计算得出，只要按学习人数来排序，学习人数越高，它的热度也就越高。
那么接下来时长和简介也是同主键，课程主标题直接相关的，而下面的学习人数我们的表中已经有了，
那么学习需知和收获同样可以和主键相关，也可以放到课程表中。
接下来的讲师昵称和讲师职位，我们在设计的第三范式中已经分析过了，需要提出来单独建立一个讲师表，当然了讲师表中还会有其他的属性，这个我们下面再分析讲师对象的时候再继续加入。
另外由于课程和讲师之间存在着这种一对一的关系，所以我们需要把讲师表的主键，讲师昵称也加入到课程表中，后面的课程图片没有什么好说的，肯定是直接放到课程表中是没有问题的。
接下来综合评分，内容实用性，简单易懂的程度以及逻辑是否清晰，这4个属性对于课程的来说，每个用户对课程的评分的是一个平均的分数，也是同课程相关的，所以我们也可以直接放到课程表的主表中来进行存储。
另外对于方向，分类和难度，这几个属性虽然是和课程相关的，但是如果只是存储在课程表中的话，还是会出现前面所说的这种数据的更新，插入和删除异常，所以我们需要几个单独的表来存储这些属性。
2. 【面向对象设计】根据设计范式对【课程列表对象】逻辑建模
课程方向表，它用于记录所有课程的方向，无论该课程方向下是否存在课程，这个表中都可以有记录，并且课程方向表的业务主键，就是我们在课程主表中所记录的课程方向的名称字段。
接下来还有课程分类表，课程分类表是用于记录课程的分类信息的，是不是微服务，是不是区块链以太坊人工智能机器学习这些，这些都是课程的分类。
同样无论我们现在是否有这些分类的课程，那么在课程分类表中都可以对这些分类来进行维护，那么和课程方向表类似的，我们仍然需要使用在课程主表中出现过的属性分类名称来作为这个表的主键。
最后一个表就是课程的难度表，这个表是用于维护课程的难度分级的，表明一门课程是入门级的，初级的中级还是高级的课程。
同样我们使用课程难度的名称这一列来作为表的业务主键。
接下来我们继续来看课程列表这个对象实体要如何来存储。
那么前面我们分析了课程列表这个对象所具有的属性，主要的包括课程的章节的名称，课程的小节的名称，课程章节的说明，小节的时长，小节的URL，小节的视频格式这些。
我们先来看，用一张课程章节表是否可以存储下这些所有的属性。
很显然如果要在这些属性中选择一个业务主键的话，那么只能使用章节名称和小节名称来作为联合的主键，才能保证主键的唯一性。
我们继续往下看，章节说明其实只从课程的章节名具有依赖关系，同时后面的小节时长，小节的视频的URL和小节的视频的格式，也只跟小节名具有依赖关系。
所以如果把这些属性放在一张表中，显然是不满足第二范式的，那么表中的非主键列必须对全部的主键列既有依赖关系的要求，所以我们就不能把这些字段全部放在一个表中了。
那么我们要怎么来拆分？我们上面分析了课程列表对象的业务主键，它是一个联合主键，而联合主键中的每一个属性又都有同其相互依赖的属性，所以我们可以把这两个联合主键拆分开，把不同于主键属性相依赖的属性单独放在一个表中。
那么具体来说就是把课程的章节名和课程的章节的说明独立出来，这样就形成了一张课程的章节表。
此时有了课程列表 和 课程章节表。
同时为了保存课程表中同课程章节表之间的关联关系，我们还要一张从课程章节表以及课程表之间的关联表，这张表只有两个属性，就是课程表的主键和章节表的主键，分别就是课程的主标题和章节的名称。
同样我们把剩下的几个属性，小节的名称和小节的URL以及小节视频的格式都存储到了小节表中，这里我们可以使用小节名称来作为主键，并且为了保存小节同课程章节之间的关联关系，我们同样需要一张课程的小节表与章节表之间的关联关系表，这个表中就包括了课程表的主键，课程主标题和课程章节表的主键，章节的名称以及小节表的主键，小节的名称。
那么通过以上几步，我们就确定了课程列表的逻辑的存储方式，并且保证了这种设计是符合数据库一个设计范式的要求的。
3. 【面向对象设计】根据设计范式对【用户对象】逻辑建模
对象实体应该怎么来存储，才能符合数据库设计范式的要求。
那么在讲师实体中包括了讲师的昵称，讲师的说明，讲师的性别，讲师所在的省和市，讲师的职位以及讲师的一些扩展的说明，经验，积分，讲师所关注的人数以及讲师的粉丝人数这些属性。
同样我们先找到讲师实际中可以作为主键使用的属性，显然了这个讲师的昵称是可以唯一标识出讲师表中每一行记录的，所以很适合作为业务主键来使用，并且这是一个单属性值的主键，因此天生就已经符合了第二范式的要求。
那么接下来我们再来看其他属性之间是否存在着依赖关系。我们可以看到其他几个属性值也完全是从讲师昵称相依赖的，所以讲师实际的所有属性都可以存放到一张讲师表中，并且可以使用讲师昵称来作为讲师表的主键。
并且大家如果还记得的话，我们在前面分析课程属性时候也拆分出了一个讲师表，并且那个角色表中只包含了讲师昵称和讲师的职位两个属性，我们可以看到这两个属性也已经包含在了我们现在的讲师表中了。
那么还有一个跟讲师对象类似的对象实体，对象也就是用户实体了。所以我们下面先跳过其他的实体对象来看一下，用户实体的属性应该如何存储。
我们可以看到用户实体和讲师实体的属性十分的类似，那么在用户实体中，同样包括了用户的昵称以及用户的登录密码，用户的说明，用户的性别，用户所在的省市以及用户的职位，说明，经验积分，用户所关注的人数以及被关注的粉丝的人数这些属性。
同样我们可以使用用户昵称来标识我们的每一个用户，这时就要求我们的用户表中的用户昵称它是不能重复的。并且我们可以发现在用户实体中其他的属性如用户的密码，用户的说明，用户的性别等其他属性也都是从用户昵称相互依赖的，所以我们也同样可以直接把所有的用户属性都存储在一张用户表中，同样用户表中我们可以使用用户昵称来作为我们的业务主键来使用。
