确定超级密钥
Determining Super Key
Today's Court Bookings
- Each row in the table represents a court booking at a tennis club that has one hard court (Court 1) and one grass court (Court 2)
- A booking is defined by its Court and the period for which the Court is reserved
- Additionally, each booking has a Rate Type associated with it. There are four distinct rate types:
- SAVER, for Court 1 bookings made by members
- STANDARD, for Court 1 bookings made by non-members
- PREMIUM-A, for Court 2 bookings made by members
- PREMIUM-B, for Court 2 bookings made by non-members
The table's superkeys are:
- S1 = {Court, Start Time}
- S2 = {Court, End Time}
- S3 = {Rate Type, Start Time}
- S4 = {Rate Type, End Time}
- S5 = {Court, Start Time, End Time}
- S6 = {Rate Type, Start Time, End Time}
- S7 = {Court, Rate Type, Start Time}
- S8 = {Court, Rate Type, End Time}
- ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey
Note that even though in the above table Start Time and End Time
attributes have no duplicate values for each of them, we still have to
admit that in some other days two different bookings on court 1 and
court 2 could start at the same time or end at the same time. This is
the reason why {Start Time} and {End Time} cannot be considered as the
table's superkeys.
S1 = {Court, Start Time} 是个超级密钥吗？
比如说，在第 1 天，一位会员预定了从 11:00 到 12:00 的球场 1，而在第二天，一位非会员预定了从 11:00 到 [=23= 的球场 1 ].
table 中的记录将是
{1,11:00,12:00, SAVER} 和 {1,11:00,12:00, STANDARD}
很明显 S1 = {Court, Start Time}，不是超级键。还是我错了？
这个例子是一个糟糕的选择，因为要理解 table 应该持有的内容涉及未说明的，但常识性的假设。它希望您看到 table 仅一天 - "Today"-- 并推断在任何一天都不会有重叠预订。即，一个法院的开始结束时间段不会与同一法院的另一个时间段重叠。 （文中提到了不同的日子，它们表示不同的 table 值；但对于示例来说，不同的值是否必须在不同的日子并不重要。）
这也是一个糟糕的选择，尤其是对于 3NF 和 BCNF。当然，它受制于与 3NF 与 BCNF 相关的某些 FD（功能依赖项）及其关联的 JD（连接依赖项）。但是预订的非重叠是与 3NF 与 BCNF 无关的单独约束。
Say on day 1, a member books court 1 from 11:00 to 12:00, and on day 2, a non member books court 1 from 11:00 to 12:00.
当我们说一个table值"satisfies"一个约束（例如FD）或"is subject to" 约束或 "has" 约束或约束 "holds in" a table value 我们的意思是该值使约束为真。当我们对 table 变量（基础 table）这样说时，我们的意思是每个数据库状态下的变量值都是如此。对于这个 table，描述 "Today" 当前的预订情况，任何特定的预订情况都大约是一天——今天。因此，报价中涉及不同日期的重叠与约束无关。同样，无论预订如何变化，同一天不同时间的每个 table 值都将满足约束条件。
在那些情况下，对于 table 的任何状态，指定的四组列是 CK（候选键）：
- S1 = {球场，开始时间}
- S2 = {法庭，结束时间}
- S3 = {费率类型，开始时间}
- S4 = {费率类型，结束时间}
因为 预订不重叠，每个列集的子行值在这些列下都是唯一的。所以他们是超级钥匙。由于这对于每个更小的子集都是正确的，因此它们是 CK。由于没有其他列集为真，因此没有其他 CK。由于超级键的每个超集都是一个超级键，因此列出的其他集合是其他（非 CK）超级键。
PS 该条目的 talk page 中有几个部分是关于 Tennis/Booking 示例和页面上的混淆。该页面还有其他糟糕的例子。例如，它将非 BCNF 3NF 设计重组为 BCNF 设计，但不是通过标准无损分解到原始投影（连接回它）。 （它引入了一个新专栏。）例如，它然后还讨论了保留依赖关系，但这只有在分解为原始投影时才有意义。
Today's Court Bookings
- Each row in the table represents a court booking at a tennis club that has one hard court (Court 1) and one grass court (Court 2)
- A booking is defined by its Court and the period for which the Court is reserved
- Additionally, each booking has a Rate Type associated with it. There are four distinct rate types:
- SAVER, for Court 1 bookings made by members
- STANDARD, for Court 1 bookings made by non-members
- PREMIUM-A, for Court 2 bookings made by members
- PREMIUM-B, for Court 2 bookings made by non-members
The table's superkeys are:
- S1 = {Court, Start Time}
- S2 = {Court, End Time}
- S3 = {Rate Type, Start Time}
- S4 = {Rate Type, End Time}
- S5 = {Court, Start Time, End Time}
- S6 = {Rate Type, Start Time, End Time}
- S7 = {Court, Rate Type, Start Time}
- S8 = {Court, Rate Type, End Time}
- ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey
Note that even though in the above table Start Time and End Time attributes have no duplicate values for each of them, we still have to admit that in some other days two different bookings on court 1 and court 2 could start at the same time or end at the same time. This is the reason why {Start Time} and {End Time} cannot be considered as the table's superkeys.
S1 = {Court, Start Time} 是个超级密钥吗？
比如说，在第 1 天，一位会员预定了从 11:00 到 12:00 的球场 1，而在第二天，一位非会员预定了从 11:00 到 [=23= 的球场 1 ].
table 中的记录将是 {1,11:00,12:00, SAVER} 和 {1,11:00,12:00, STANDARD}
很明显 S1 = {Court, Start Time}，不是超级键。还是我错了？
这个例子是一个糟糕的选择，因为要理解 table 应该持有的内容涉及未说明的，但常识性的假设。它希望您看到 table 仅一天 - "Today"-- 并推断在任何一天都不会有重叠预订。即，一个法院的开始结束时间段不会与同一法院的另一个时间段重叠。 （文中提到了不同的日子，它们表示不同的 table 值；但对于示例来说，不同的值是否必须在不同的日子并不重要。）
这也是一个糟糕的选择，尤其是对于 3NF 和 BCNF。当然，它受制于与 3NF 与 BCNF 相关的某些 FD（功能依赖项）及其关联的 JD（连接依赖项）。但是预订的非重叠是与 3NF 与 BCNF 无关的单独约束。
Say on day 1, a member books court 1 from 11:00 to 12:00, and on day 2, a non member books court 1 from 11:00 to 12:00.
当我们说一个table值"satisfies"一个约束（例如FD）或"is subject to" 约束或 "has" 约束或约束 "holds in" a table value 我们的意思是该值使约束为真。当我们对 table 变量（基础 table）这样说时，我们的意思是每个数据库状态下的变量值都是如此。对于这个 table，描述 "Today" 当前的预订情况，任何特定的预订情况都大约是一天——今天。因此，报价中涉及不同日期的重叠与约束无关。同样，无论预订如何变化，同一天不同时间的每个 table 值都将满足约束条件。
在那些情况下，对于 table 的任何状态，指定的四组列是 CK（候选键）：
- S1 = {球场，开始时间}
- S2 = {法庭，结束时间}
- S3 = {费率类型，开始时间}
- S4 = {费率类型，结束时间}
因为 预订不重叠，每个列集的子行值在这些列下都是唯一的。所以他们是超级钥匙。由于这对于每个更小的子集都是正确的，因此它们是 CK。由于没有其他列集为真，因此没有其他 CK。由于超级键的每个超集都是一个超级键，因此列出的其他集合是其他（非 CK）超级键。
PS 该条目的 talk page 中有几个部分是关于 Tennis/Booking 示例和页面上的混淆。该页面还有其他糟糕的例子。例如，它将非 BCNF 3NF 设计重组为 BCNF 设计，但不是通过标准无损分解到原始投影（连接回它）。 （它引入了一个新专栏。）例如，它然后还讨论了保留依赖关系，但这只有在分解为原始投影时才有意义。