这是第三种形式的会员预订-法庭设计吗？

Question

我是一名学生，刚开始从事数据库设计。我有个要求：

​

​

这是我的答案(主键用粗体表示)：

会员(会员编号，会员姓名，会员姓)

预订(会员号码+法庭编号，预订日期，预订时间)

法庭(会员号码+法庭编号，期限，付款)

我的解是第三种形式了吗？成员编号+法院编号是否为法庭表制作了适当的组合键？

会员号码+法院编号已经是预订的关键，我认为这是一个薄弱的实体。我之所以选择成员号+法院号作为法院表的复合键，是因为可以重复法院编号，因此它不能成为表的很好的主键。

Answer 1

不是的。

想一想什么才是唯一的“法庭”。而“法庭”的每一个属性都需要依赖于关键，整个关键，除了关键，什么都不需要。

我认为“法庭”的候选钥匙应该是“法庭号码”。

而“法庭”没有持续时间..。“预订”是有期限的。“法庭”没有付款，“预订”有付款。

对于“预订”，我不认为你有一个有效的候选密钥。

这取决于对“一次只有一个法院”规则/约束的解释/澄清。在我看来，这条规则是说，在某一特定日期和时间，一名议员最多可保留一个法庭。也就是说，会员可以在星期三下午三时预约法庭，星期六上午十点预约法庭.但是，一名成员不能在星期六上午10点预定两个法庭。

为了帮助执行这一点，您可能希望在元组(member_number,booking_date,booking_time)上有一个唯一的约束。也许那是“预订”的候选钥匙。

(为了充分执行“一次一个法院”的规则，除了这一独特的限制外，还会涉及一些额外的逻辑。以防止议员莎莉在星期六上午十时预约法庭两小时，并于上午十一时(同一星期六)预订另一间法庭一小时。这一独特的限制本身并不能阻止莎莉从上午11点到中午被预定两个法庭。)

另一种(或额外的)解释是，“法院”最多可由一名成员在给定时间“预约”。这表明对预订实体有一个独特的限制.在(court_number,booking_date,booking_time)元组上。

同样，同样的问题与重叠的时期，不同的开始时间，但持续时间足够长，它重叠的另一个预订。再说一遍，我们不想让一个“法庭”从上午10点起预订2小时，也不允许在上午11点预定1小时。

与数据所有者/系统所有者澄清这些类型的需求是“建模”会话的目的，这些会话生成一个实体关系图(ERD)，作为发现过程的工件。

我们将要求数据所有者通过提出适当的问题来澄清需求.

“预订”的最短时间和最长时间分别是多少？

一个法庭的两个预订会重叠吗？(上午10时2小时，上午11时1小时)

是否允许会员在星期二、星期四和星期六预定法庭？

等。

我们要小心，我们在数据模型中构建的约束是硬规则和快速规则，真正的约束，这些约束一直都是真实的。不仅仅是“嗯，大多数时候都是这样的。但是史蒂文斯医生，我们让他订了两本书。”