【发布时间】：2021-04-13 06:58:50
【问题描述】：
我有这张表，我想在 3NF 中为其设计表结构。
Patient ID Name Address Mobile DOB Clinic Consultant Appointment Cancelled
01 John 1 Road 0777 10/10/1992 FRAC1 Dr Test 01/01/2021 Yes
02 Tony 2 Road 0789 10/09/1995 EYE01 Dr Test two 02/02/2021
我已将其分成三个单独的表格：
病床
- 患者编号
- 姓名
- 地址
- 手机
- 出生日期
临床表
- 诊所
- 顾问
预约表
- 约会 ID (PK)
- 患者 ID (FK)
- 诊所 (FK)
- 顾问
- 预约
- 已取消
我做对了吗？我正在为大学的数据模型作业做练习。
【问题讨论】：
-
我怀疑您需要多考虑一下您的“诊所”表。您的“诊所”表应该为同一诊所有多行（但对于可能在该诊所工作的每个不同的顾问），这是否正确？同样，同一个顾问是否有可能在不止一个诊所看病人？这些问题应该推动您做出有关数据结构的决策
-
您好 Craig，谢谢，每个诊所可能有不止一位顾问。顾问将只在一个诊所工作。这将如何改变我的结构？感谢您的帮助。
-
思考 3NF 的关键原则。想想您对患者的决定——为什么会有一个带有特定 ID（这将是患者密钥）的“患者”表？您认为诊所或顾问与患者相比有何不同，这意味着诊所和顾问不会有自己的“关键”表格？如果您不认为诊所和顾问需要他们自己的“关键”表格，为什么不呢？
-
谢谢，我已在您的建议中添加了为诊所和顾问提供单独表格的建议。据我所知，在预约表中，我将预约 ID 作为主键和以下外键： Patient_ID（外键 - 患者信息表）诊所 ID（外键 - 诊所表） Consultant_ID（外键 - 顾问表）以及约会日期。理论上这准确吗？
-
这确实更有意义。根据@Gordon Linoff 的建议，剩下的唯一事情是您是否有一张桌子来维持诊所和顾问之间的关系。您之前说过，顾问只会在一个诊所工作....所以，除了表格结构之外，还考虑到一个用于创建约会的应用程序，您将如何向应用程序展示用户 - 预约时特定诊所的可用顾问列表？包含这种关系的表在这方面会很有用
标签： sql database data-modeling