※食用指南：文章内容为'CodeWithMosh'SQL进阶教程系列学习笔记，笔记整理比较粗糙，主要目的自存为主，记录完整的学习过程。（图片超级多，慎看！）
【中字】SQL进阶教程 | 史上最易懂SQL教程！10小时零基础成长SQL大师！！
https://www.bilibili.com/video/BV1UE41147KC/?spm_id_from=333.1007.0.0&vd_source=b287f1f4a1fa54cc438e31a0f87ef4e2
第十二章：设计数据库------PART3
19、PROJECT（1）：FLIGHT BOOKING SYSTEM------项目一航班订票系统
为航班订票系统设计一个数据库
在附件PDF中可以看到这个系统要生成的机票的一个示例
根据这些信息，为系统设计一个数据库
20、PROJECT（1）：CONCEPTUAL MODEL------项目一：概念模型
自己做的：
Mosh答案：
先在实体之间建立一种关系，在逻辑模型的时候再明细它们的关系，都先设定为多对多
先不用管标准化问题，随时可以回来修改，先把基础建对
围绕四个实体建立概念模型
21、PROJECT（1）：LOGICAL MODEL------项目一：逻辑模型
优化元素建立逻辑模型
①实体之间的关系
乘客&机票：一对多
机票&航班：一对多
机场&航班：多对多
修改箭头即可
②添加属性
Flight number有数字和字母，使用字符串
飞行时间最好用分钟来计时，更加直观------飞行分钟
③新增Ariline
航空公司&航班：一对多
舱位&机票：一对多
两个问题：
①机场实体
这种设计可能导致重复的城市、州、国家，是否应该把属性拎出来
减少重复但是数据会变得很零碎，也总需要把三四张表连接到一起，才能查到某个城市的机场，这样的连接会影响应用程序的性能
对设计作**"去"标准化处理**，将经常连接到一起的表，合并成一张表
就不必总是把表连接到一起
结合项目，世界也不会有几百万个机场，也不是每个城市也有机场，数量有限，这里出现的重复不算很大问题
只添加城市和州属性就可以
②机场&航班：多对多关系
关系型数据库中没有多对多关系，只有一对一、一对多
出现多对多的关系，要分解成2组一对多关系
通过一张链接表实现，一张代表两个实体或者两张表之间关系的表
但链接表的问题是：允许一个航班与两个以上的机场有联系。因为链接表可以有多对多的关系（不建议使用）
添加两个属性：起飞机场、到达机场
当我们基于这个逻辑模型建构一个实体模型时
需要为DepartureAirportId（interger）、ArrivalAirportId（interger）这两列添加外键
以上就是基于我们对这个问题的了解所做的逻辑模型，不要把它当作这类问题的最好办法或者唯一办法，++每种解决方案都是有利有弊++
随着越了解这个问题，这个业务领域，模型也会变
（实体模型自行建立）
22、PROJECT（2）：VIDEO RENTAL APPLICATION------项目二：视频租赁应用
应用程序将在一个视频出租商店使用（Vidly）
使用附件PDF，阅读要求，为应用程序设计数据模型
①不同级别的权限给不同的用户：
商店经理：添加/更新/删除电影列表；设置每部电影的库存、每日租金
收银员：对电影清单有一个只读的视图，管理顾客名单、租的电影
②业务方面：
结账：顾客要一部或者多部电影，搜索电话号码查询顾客ID
第一次来的需要在系统中登记全名、电子邮件、电话号码；扫描所要电影，记录在系统中
每部电影有个10位的条形码
归还：如果丢失，收取电影日租金的5倍金额
收银员标记电影丢失，减少库存（重点在库存中的电影数量、收取顾客多少费用）
其他电影收费：天数*每日租金
不定期发优惠券，顾客归还电影时可以带一张优惠券
顾客可能分次归还所租电影
需要能追踪
-- 热门电影
-- 优质顾客
-- 每日/每月/每年收入
23、PROJECT（2）：------CONCEPTUAL MODEL------项目二：概念模型
自己做的：
Mosh答案：
24、PROJECT（2）：------LOGICAL MODEL------项目二：逻辑模型
现在需要考虑存储数据
①权限问题
收银员和店长无法拥有一致的权限集 ，每个用户的权限集不同，++必须确保我们的用户拥有一致的权限++
以上模型对应用来说要求了过高的细节度，更使用与需要完全控制到每个用户权限的应用程序
引入新实体------root
在下次注册新用户时，只需要把用户添加到特定组或身份里，用户就能自动获取身份的所有权限，用户就能够拥有一致的权限集
②管理权限
对电影的管理权限有点太细化，不需要那样的控制度，Permissions这个实体没有必要，只需要知道用户身份
在应用程序中写一个简单的IF语句，如果用户是店长，将开启所有功能；如果是收银员，或许需要隐藏或禁用某些功能
🔺例如在旅行，需要一个房间住一晚，预算100元，假设一个人来，只需要一间简单的房间，一张单人床
刚好现在就有一间房间，有大床、阳台、浴缸、wifi、游戏机，但一晚要500元
你不会为那些不需要的功能多花400元
🔺回到项目，所有未来可能会用上的附加功能，总有人要先为它买单------公司
不要过度设计，不要因为认为必要的功能浪费别人的钱，也是管理复杂性的问题
复杂的设计会一致贯穿于这个应用程序，每次需要修复一个bug或引入一个新功能时，都必须处理这个应用程序设计里不需要的复杂性
③实体关系
租赁&优惠券 ：一次租赁最多可以用一张优惠券，一张优惠券可以用于不同租赁*（优惠券是可空类型）*
租赁&电影：每次租赁只能租一部电影，一部电影可以被租很多次
租赁&顾客：同上
------------TBC