【软件设计师-从小白到大牛】下午题基础篇：第二章 数据库设计

前言

​
本系列文章为观看b站视频以及b站up主@zst_2001系列视频所做的笔记，感谢相关博主的分享。如有侵权，立即删除。
视频链接：视频链接（注：文章中有关图片、以及网友的相关评论与总结等内容未标明出处均出自该视频，感谢大家的分享！）
b站up主页：b站up

章节提要

一、数据库设计过程

• ER模型：是实体联系模型，跟DBMS无关，也就是跟具体的数据库管理系统没有关系。
• 概念结构设计：完成ER模型的建模工作。

二、E-R模型

• 一对一：联系可以合并到任何一边。
• 一对多：联系可以合并到多的那边。
• 多对多：联系只能作为一个单独的关系模式。

三、答题技巧

问题一

问题一的题目一般是补充缺失的联系。
做题方法：根据需求描述中的文字（…个…属于/有…个…），判断实体间联系类型，从而补充E-R图中的联系。

• 弱实体：
  （注：下图来自前言中up主视频）
• 子实体：
  （注：下图来自前言中up主视频）
  
  （注：下图来自前言中up主视频）
  
• 实体与实体之间不能直接相连，需通过联系。两个实体与其联系（或更多）整体作为一个聚合实体，也就是特殊的实体。
• 无法确定联系时可以根据关系模式进行判断。

问题二/三

问题二/三的题目一般是补充关系模式中的属性，以及主键与外键的考察。
做题方法：首先根据需求描述中文字（…信息包括…）来检查关系模式中是否有缺失，然后再根据完整性约束来对关系模式进行检查，从而补充关系模式中的属性；一般（…号）为一个关系模式的主键，如果两个实体之间有联系，要考虑关系模式的转换，根据关系模式的转换原则来判断主、外键。

• 若题目中存在“不同的A具有不同的B”，说明A能推导出B（即A->B）。
• 在需求分析中存在的，而在逻辑结构设计阶段关系模式中不存在的，逻辑结构阶段的关系模式中需要补上。然后再考虑联系的转换而导致增加的属性。
  （注：下图来自希赛网）
  
  （注：下图来自希赛网）
  
• 三个及以上实体之间的关系也是像多对多联系一样转换为一个单独的关系模式（转换方法也类似，将与联系相关的实体的码放入关系模式中，再加上联系本身的属性即可，该关系模式的主键为加入的所有的实体的主键的组合）。填缺少属性时不需要考虑该关系的合并问题。
• 外键：该属性不是该关系模式的码（主键），而是其他关系的码（主键）。
• 关系模式中主键有下划线，外键有下划虚线。
• 完整性约束关系（即求 主键与外键，可以写文字也可以在属性下划线（主键下划线，外键下划虚线））。
• 判断主、外键时，需求分析结果 中有说明的优先依靠需求分析结果中 “唯一标识” 来判断主键、外键等；不要想当然，有时题目给出的关系模式并不完整，可能没有多对多联系转换成的独立关系模式。
• 组合主键中的任一其它关系中的主键，单独拎出来就是外键。

问题三/四

问题三/四的题目一般属于拓展类型题型，一般是增加一个实体后在原有E-R图中补充联系、并且给出相应的关系模式。

• 为E-R图新增实体时，要考虑 新增实体的主键 是什么，以及 新增实体中可能添加的联系转换后的某方实体的主键。
• 添加属性时，是用椭圆，然后连接到实体上。
• 若题目中说某个实体与某个实体不存在直接联系，则说明这两个实体之间不需要补充联系。

四、案例分析

1、案例1

正确答案：
1）员工：部门 = n:1、 客户:客房 = 1:n、 客房:客户= 1:m
2）注：这里将权限视为两种，管理人员权限和服务人员权限

3）员工号、部门号
客房号
身份证号
岗位
身份证号、客房号
4）缺点：数据冗余，优点：减少连接 查询时间少。

2、案例2

正确答案：
1）
2）a）商场编号、b）部门编号、c）员工编号
主键分别为：部门编号、员工编号、员工编号
外键分别为：商场编号、部门编号、员工编号
3）紧急联系人、员工：紧急联系人=n：1
紧急联系人（员工编号、紧急联系人姓名、紧急联系人联系电话）