Database 数据库的BCNF和4NF

Database 数据库的BCNF和4NF,database,database-normalization,bcnf,Database,Database Normalization,Bcnf,所以我从这3个表开始,被告知将它们修改为BCNF和4NF: 私人会议(培训师、电话、电子邮件、费用、客户姓氏、, ClientFirstName、ClientPhone、clientmail、日期、时间) 俱乐部会员(客户编号、客户姓氏、客户姓氏、, 客户电话、客户邮件、会员类型、结束日期、街道、城市、, 州(邮编) 课程(课程名称、培训师、开始日期、结束日期、成本) *还建议使用一个新表来跟踪客户、订阅的课程和支付的金额,同时仍将所有内容保存在BCNF和4NF中 ===============

所以我从这3个表开始,被告知将它们修改为BCNF和4NF:

私人会议(培训师、电话、电子邮件、费用、客户姓氏、, ClientFirstName、ClientPhone、clientmail、日期、时间)

俱乐部会员(客户编号、客户姓氏、客户姓氏、, 客户电话、客户邮件、会员类型、结束日期、街道、城市、, 州(邮编)

课程(课程名称、培训师、开始日期、结束日期、成本)

*还建议使用一个新表来跟踪客户、订阅的课程和支付的金额,同时仍将所有内容保存在BCNF和4NF中

=================================================================

所以,我将它们转换为这7个表,以尝试遵守BCNF和4NF。问题是……这一点正确吗?如果每个确定项都是一个候选键,那么BCNF的定义就满足了,看起来它们是。如果4NF不包含多值依赖项,我相信它是满意的……并且我尝试分离表,这样它们就不会

教练 培训师会议 客户信息 会员地址 会员信息 俱乐部级 班级注册 有关建议模式的最新版本(第11版) 由于模式将被修改,因此很难将答案与当前版本的模式保持同步。在回顾任何给定答案时,请记住这一点

班级注册包含“总班级”和“总付费”字段,这两个字段不合适。该表应仅为键,除非成员可以协商该类的每类费用(折扣)与标价(在这种情况下需要“已支付费用”)属性。必要时应计算总数,或将其存储在独立于特定类别的单独表格中

会员信息和会员地址获取了两列ID,这很混乱。第二个应该在每个表中标记为Client ID(这样更合理)。现在出现的问题是“会员信息和客户信息之间以及会员地址和客户信息之间的关系的基数是多少?”对于地址,会员是否可以在不知道地址的情况下存在?一个成员可以有两个或多个地址吗?如果这两个问题的答案都是“是”,那么设计就可以了。如果回答为“否”,则不清楚您是否同时需要客户信息和会员地址。与会员信息和客户信息类似

培训师课程有两个ID字段。第二个可能是客户ID,但它还需要一个培训师ID来识别哪个培训师运行了该课程

建议方案的原始版本(第6版) 或建议模式的“接近原始”版本

您显然没有创建无损失分解,因为缺少“class name”元素

类别费用表在原始表中没有对应项

目前尚不清楚Trainer表是否与原始表相符,尽管我同意大多数领域的观点。不过,这里的费用属性放错了位置

Train Session表缺少属性,不管您如何切分。如果它是为了代表私人会议,那么您将丢失培训师ID、客户ID和费用。如果它是公共(俱乐部)会话的通用,那么您需要一个记录私人会话的表

会员信息、客户信息和会员信息三元组混淆和/或混淆。如果没有关于数据库应该如何处理信息的补充信息,就很难知道最好推荐什么。成员信息表最好命名为Address。“成员资格信息”表与“客户机信息”表没有连接,因此成员资格与地址关联,而与人关联(而人与地址不关联)

我想俱乐部的座位还可以


课程是存在的,由培训师授课,但没有人被记录为去上课。

为什么
TRAIN\u SESSION
包含
TrainerFirstName
TrainerLastName
?(俱乐部课程也是如此)我觉得它不是2nf,因为我太傻了,把我之前做的复制错了。当然,这只适用于这两个人。其他任何事情都是..或是一个错误,而我看不出
CLASS\u费用的意义。首先,原始表不会对这些数据建模-您是否应该向原始模型添加新概念?其次,您不应该直接存储聚合数据(AmountofClassesTaken、TotalAmountPaid),而应该为Class_Member_注册(ClassID、MemberID)建模,并对这些记录求和以获得总数。啊,对不起,我忘了添加,我们还应该建议一个新表来跟踪客户端、订阅的类,以及支付的金额,同时仍保留BCNF和4NF中的所有内容。不过,我喜欢复合键的想法:D@user2503165-所以我的评论的第二部分仍然有效-你不是在模拟哪些成员参加了哪些课程。我回去做了一系列编辑,尽管我很有可能把事情搞得更糟。使用不同的表格(客户信息、会员地址和会员信息)的想法是分离一些多值依赖性…但我没有提到的是,为了进行私人教练课程,你必须是俱乐部的成员,但这只是一个附加选项。俱乐部设施(又名课程)也需要会员资格,但我认为私人课程和设施课程是不同的。或者换句话说,当一个人注册成为俱乐部的成员时,他们有两条路可以走。他们可以在自己的时间以象征性的费用雇佣一名独立的私人教练(培训师课程)……或者他们可以参加俱乐部提供的课程,也可以以其他费用雇佣同一名教练(俱乐部课程)。我知道,我很高兴
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