3nf mysql表_mysql – 如何将这些表规范化为3NF

本文探讨了兽医诊所的数据库设计,要求所有表满足3NF。内容涉及不同表如员工、约会、患者、产品销售等,以及它们存在的传递依赖和重复信息问题。作者指出3NF关键在于消除传递依赖,并给出了一些改进建议,如合并冗余表、调整表结构以减少数据冗余。
摘要由CSDN通过智能技术生成

作为家庭作业的一部分,我被要求根据案例研究创建表格,所有表格必须是3NF.然而,我已经尝试并试图了解3NF,但我只是没有掌握它,并希望得到一些帮助.

案例研究的要求是针对兽医诊所:

>允许宠物预约进行预约

>记录宠物治疗

>记录哪位兽医进行了治疗

>记录企业销售的商品,以提供允许企业生产供应商采购的库存清单的信息

有需要:记录所有销售情况

到目前为止,我有以下表格:

员工:

| staff_ID | firstName | lastName | gender | address_ID | contactNumber | partTimeOrFullTime | salary |

员工地址表:

| address_ID | staff_ID | number | street | city | county | postalCode |

兽医表:

| staff_ID | appointment_ID |

vet_nurse:

| staff_ID | appointment_ID |

约会表:

| appointment_ID | customer_ID | staff_ID | patient_ID | date | time |

initial_appointment表:

| appointment_ID | customer_ID | patient_ID | diagnosis | treatment |

followUp_appointment:

| appointment_ID | customer_ID | patient_ID | diagnosis | treatment |

患者:

| patient_ID | customer_ID | animal_type | gender | weight | height | previous_Appointments | previous_Treatment |

产品:

| product_ID | name | product_Category | animal | price | quantity_Available | reOrder_Level |

product_sold:

| sale_ID | product_ID | sale_Date |

供应商:

| supplier_ID | product_ID | contactNumber | email |

suppliers_address:

| supplierAddress_ID | supplier_ID | doorNumber | street | city | town | postalCode |

库存:

| name | product_ID | quantity_Available | price |

谢谢!

解决方法:

由于以下两个原因,我不会给你一个确切的答案:1)我懒得过滤掉所有的文字.在那里,我说了. 2)你什么都学不会.

第三种正常形式是关于没有传递性功能依赖性.换句话说,如果A确定B,其中B不确定A,而B确定C,则您具有传递依赖性,因此B和C可以放入它们自己的表中.

您的集合中的示例可以是包含城市,州和邮政编码的表格.在现实世界中,zipcode可用于确定城市和州.也许你可以有一个单独的表,其中包含zipcode,而city和state是另外两个属性.这可以是传递依赖,因为地址ID – >邮政编码和邮编 – >城市,正如我所说.

另一个要记住的重要事项:如果任何事实出现两次,你可以更正常化.例如,[city A,State B,ZipCode C]可能会出现多次,因为我确定你有多个来自同一地区的人.

编辑

看了之后再编辑它我发现了更多要评论的内容,但由于这是一项任务,我会给你时间思考它,并在几天或更长时间内回来重新审视它,如果你仍然很好奇.

编辑2

我将逐桌给你建议,但会尝试限制这些只是推动正确的方向.

工作人员 – 没有传递给我的传递依赖,其中的所有内容都由主键决定,这很好.

staff_address – 为什么你有staff_id专栏?这不是一个好主意.另外 – 你已经提到了与地址的传递依赖关系.

vet和vet_nurse – 这些表具有完全相同的列,为什么有两个表?当然有一种方法可以使用.

约会表 – 初始约会和跟进具有相同的列.同样,应该有一种方法可以让它们成为一体.我将给你一个关于约会表的直接建议:把日期和时间作为一列aptDate,并给它DATETIME值类型.

patient – customer_ID值在患者表中,那么为什么它应该在其他人中?此外,以前的约会和以前的治疗将很难在数据库内跟踪.一旦开始输入数据,您应该会看到.

产品 – 就像现在一样,它似乎并不太糟糕,但我将在稍后讨论一些问题.

product_sold – sale_ID是唯一的吗?如果是,一次销售中可以销售多少产品?这个表肯定没有正常化.

供应商 – 供应商可以提供多少种产品?这是您如何更改产品表的提示.

suppliers_address – 与postalCode相同的问题.另外,为什么suppliers_address指向供应商?

库存 – 您是否已经在产品表中跟踪所有这些字段(价格除外)?

这些都是我看到的潜在问题,但我不能凭良心给你解决你的任务.但是,如果这是您在标准化数据库中的第一次尝试,那就完全不错了.

标签:mysql,database,normalization,normalize,3nf

来源: https://codeday.me/bug/20190708/1402992.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值