sql - 数据库架构规范化违规

标签 sql database database-design

据我所知,以下内容并未违反 1NF 或 2NF。是否因为 LocationID 和 LocationName 未分离到不同的表中而违反了 3NF?

部门(DNum PK、DName、LocationID、LocationName)

最佳答案

您不能仅根据属性名称列表来确定关系是否规范化。真正重要的是应用于这些属性的依赖性。例如,给定以下一组依赖项

F: {DNum}->{LocationID}->{DNum,DName,LocationName}

我们可以说 Department 满足关于 F 的 3NF(因此满足 2NF),因为 DNum 和 LocationID 都应该是 Department 的键,并且除了这些键隐含的函数依赖之外没有其他功能依赖。就规范化而言,主键的选择无关紧要,因为一个关系可能有多个键,并且所有键都同等重要。

或者,给定以下一组依赖项

G: {DNum}->{DName,LocationID,LocationName}, {LocationID}->{LocationName}

Department 关系违反了关于 G 的 3NF,因为 LocationID 是一个非关键决定因素。

关于sql - 数据库架构规范化违规,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42727062/

相关文章:

python - pyodbc - 从 MS Access (MDB) 数据库读取主键

sql - 饮料数据库设计

php - 如何最有效地为许多用户 ID 选择匹配用户 ID 的行/记录?

database - "A parent object will have up to 2 children"之类的规则是否应该在数据库中重复

database - 字符串或枚举

c# - 使用参数化查询时 SQL 查询速度极慢

MySQL:过滤组 View 与内联选择

sql - 从 Postgresql 表中绘制表和关系

mysql - SET() 或请建议合适的设计

mysql - 列表中的 SQL 中缺少哪些值?