这个MEMBER-BOOKING-COURT设计是否为第3范式？

Question

我是一名学生，也是数据库设计的新手。我有这个要求：

这是我的答案（主键是粗体）：

会员（会员编号，会员名字，会员姓氏）

预订（会员编号+法院编号，预订日期，预订时间）

COURT（会员编号+法院编号，期限，付款）

我的解决方案是否处于第3范式？ 会员编号+法院编号是否为COURT表格制作了合适的复合键？

会员编号+法院编号已经是BOOKING的关键，我认为这是一个弱势实体。我选择会员号码+法院号码作为COURT表的复合键的原因是法院号码可以重复，因此它不能成为表格的一个非常好的主键。

Answer 1

没有

考虑唯一标识＆＃34; court＆＃34;的内容。并且＆＃34; court＆＃34;的每个属性需要依赖于密钥，整个密钥以及密钥。

我认为＆＃34; court＆＃34;就像＆＃34;法院号码＆＃34;。

和＆＃34;法庭＆＃34;没有持续时间...＆＃34;预订＆＃34;有持续时间。 A＆＃34;法院＆＃34;没有付款，＆＃34;预订＆＃34;有付款。

对于＆＃34;预订＆＃34;，我认为你没有有效的候选人密钥。

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

为了帮助强制执行，您可能需要对元组(member_number,booking_date,booking_time)进行唯一约束。也许这是＆＃34;预订＆＃34;的候选键。

（为了全面执行＆＃34;一次一个法院＆＃34;规则，除了这个独特的限制外，还会涉及一些额外的逻辑。防止会员Sally在星期六上午10点预订法庭2小时和上午11点（同一个星期六）的另一个法院一个小时。独特的限制本身不会阻止莎莉从上午11点到中午预订两个法院。）

另一种（或另外的）解释是＆＃34;法院＆＃34;可以＆＃34;预订＆＃34; 最多在给定时间的一个成员。这表明对(court_number,booking_date,booking_time)元组的预订实体有一个独特的约束。

同样，同样的问题是重叠时段，不同的开始时间，但持续时间足够长，以至于它与另一个预订重叠。再一次，我们不希望允许一个单一的法庭＆＃34;从上午10点预订2小时，也在上午11点预订1小时。

向数据所有者/系统所有者阐明这些类型的要求是＆＃34;建模＆＃34;会话，它生成实体关系图（ERD）作为发现过程的工件。

我们希望数据拥有者通过提出适当的问题来澄清要求......

＆＃34;预订＆＃34;

的最短持续时间和最长持续时间是多长？

单个法院的两次预订可以重叠吗？ （上午10点2小时，上午11点1小时）

会员是否可以在周二，周四和周六预订（＆＃34;预订＆＃34;）法院？

等

我们要小心，我们在数据模型中构建的约束是硬性和快速的规则，真正的约束，这些都是真实的。而且不只是＆＃34;嗯，大部分时间都是如此。但史蒂文斯医生，我们让他预定两个。＆＃34;