所以我开始使用这3个表并被告知将它们修改为BCNF和4NF:
PRIVATE_SESSION(培训师,电话,电子邮件,费用,ClientLastName, ClientFirstName,ClientPhone,ClientEmail,Date,Time)
CLUB_MEMBERSHIP(ClientNumber,ClientLastName,ClientFirstName, ClientPhone,ClientEmail,MembershipType,EndingDate,Street,City, 州,邮编)
CLASS(ClassName,Trainer,StartDate,EndDate,Cost)
*还建议一个新表来跟踪客户,订阅的类和支付的金额,同时仍保留BCNF和4NF中的所有内容
=============================================== ==================
所以,我把它们变成了这7个表,试图遵守BCNF和4NF。问题是......这甚至远程正确吗?如果每个确定符都是候选键,则满足BCNF的定义,它看起来像它们。 4NF如果它不包含多值依赖项我感到满意......我试图将表分开以便它们不会
ID (primary key),
TrainerLastName,
TrainerFirstName,
TrainerEmail,
TrainerPhone
ID (primary key),
ID (foreign key from CLIENT_INFO.ID)
TrainingStartTime,
TrainingStartDate,
TrainingFee
ID (primary key),
ClientLastName,
ClientFirstName,
ClientPhone,
ClientEmail,
ID (primary key),
ID (foreign key to CLIENT_INFO.ID),
State,
City,
Street,
Zip
ID (primary key),
ID (foreign key to CLIENT_INFO.ID),
MembershipType,
MembershipStartDate,
MembershipEndDate
ID (primary key),
TrainerID (foreign key to TRAINER.ID),
ClassName,
ClassStartDate,
ClassEndDate,
ClassCost
(ClassID, MemberID) composite primary keys
TotalClasses,
TotalPaid
答案 0 :(得分:0)
由于架构将被修改,因此很难将答案与当前版本的架构保持同步。在回顾任何给定答案时请记住这一点。
班级注册具有不适合的总类和总付费字段。该表应该是仅限密钥的,除非成员可以与列表价格(在这种情况下需要“付费”)属性相比,为班级协商每班费用(折扣)。总计应在必要时计算,或存储在独立于特定类别的单独表格中。
会员资格信息和会员地址已经获得了两个名为ID的列,这令人困惑。据推测,第二个应该在每个表中标记为客户ID(这将更合理)。现在出现的问题是“会员信息和客户信息之间以及会员地址和客户信息之间关系的基数是什么?”对于地址,成员是否可以在不知道地址的情况下存在?会员可以有两个或更多地址吗?如果其中任何一个的答案都是“是”,那么设计就可以了。如果答案为“否”,则不清楚您是否需要客户信息和会员地址。与会员信息和客户信息类似。
培训师会话有两个ID字段。第二个可能是客户端ID,但它还需要一个培训师ID来识别哪个培训师运行会话。
或建议架构的“接近原始版本”。
由于缺少“类名”元素,您显然没有创建非损失分解。
Class Expense表在原始表中没有对应物。
目前尚不清楚Trainer表是否符合原始表的保证,但我同意大多数字段。但费用属性在这里放错了地方。
列车会话表缺少属性,或多或少但是你切片和切块。如果它代表私人会话,那么您将缺少培训师ID和客户ID和费用。如果它是公共(俱乐部)会话的通用,那么你需要一个记录私人会话的桌子。
会员信息,客户信息和会员信息的三元组混淆和/或混淆。如果没有关于数据库如何处理信息的补充信息,很难知道什么是最好的推荐。 “成员信息”表可能更好地命名为“地址”。会员资格信息表与客户信息表没有任何关联,因此会员资格与地址相关联,但与人不相关(人与地址无关)。
我认为俱乐部班级表是好的。
课程存在并由培训师讲授,但没有人记录为上课。