【发布时间】:2016-05-14 07:48:41
【问题描述】:
这个房间的主人把房间租给了游客和访问该地区几天并需要一个地方度过几天的人。每位客人都需要进行预订,并且只有一个房间可用。 所以我想出了这个实体关系图,指示所有实体和关系。
问题 我想知道预订实体是否需要两个外键? 此外,ER 图的整体设计是否正确到可接受的水平,包括键和属性?
【问题讨论】:
这个房间的主人把房间租给了游客和访问该地区几天并需要一个地方度过几天的人。每位客人都需要进行预订,并且只有一个房间可用。 所以我想出了这个实体关系图,指示所有实体和关系。
问题 我想知道预订实体是否需要两个外键? 此外,ER 图的整体设计是否正确到可接受的水平,包括键和属性?
【问题讨论】:
您的模型存在一些问题:
每个业主只能拥有一个房间。在现实世界中,业主可以拥有许多房间。即使目前您想要一个双射关系,我建议您将该关系从 Owner 表中取出,以防您以后想更改它。
每个房间只有一个客户。如果在现实世界中,房间可以在不同的预订期间容纳不同的客户。从 Room 表中删除与客户端的关系。
每个客户只有一次预订。在现实世界中,客户可以随着时间的推移进行不同的预订。从 Client 表中删除与 booking 的关系。
Booking_ID 听起来像是预订的代理键。为什么客户端是主键的一部分?我认为它应该是一个非主属性,并表明它将在图中已经描述的外键约束中。
Booking 对 Room_ID 有外键约束,但您的图表没有描述它。
Payment 表中的Payment_ID 处于外键约束中,但听起来像是该表的代理键。我认为 Booking 表中的 Payment_ID 以及 Payment 中的 Booking_ID 应该是受约束的。
付款表的用途是什么?它看起来是多余的,即使不是,您也可以将这些功能依赖项移到 Bookings 表中,然后可以消除 Payment_ID。
如果您从 Booking 表中删除 Payment_ID,您仍然会有两个处于外键约束中的键。
【讨论】: