我有一个关于规范化的问题，关于我的情景的正常形式。我有几个具有相同字段的表 - 名称地址1，地址2，邮政编码和电话号码;
Client [id, instructor id, name, address, postcode, phone, practical, theory]
Staff [id, office id, name, job, address, postcode, phone]
Registration id, name, address, postcode, phone]
Office [id, manager id, address, postcode, phone]
是否存在任何正常形式将它们分隔成类似的东西......
Client [id, instructor id, details_id, practical, theory]
Staff [id, office id, details_id, phone]
Registration [id, details_id]
Office [id, manager id, details_id]
Details [id, full_name, address1, address2, postcode, phone_no]
不确定规范化是否会起作用，但这只是一个想法......
答案 0 :(得分：1)
在多个表中放置具有相同含义的列与规范化无关。它与数据库设计的不同形式原则有关。 Chris Date称之为The Principle of Orthogonal Design或POOD。
据我所知，POOD背后的形式逻辑还没有像普通形式那样深入研究或被广泛接受。这是观察，而不是批评。
答案 1 :(得分：-1)
我将讨论第三范式，因为它通常被引用为归一化的合理水平，尽管大约有十种范式。本质上，第三NF意味着表中的任何形式（范式）都不能真正处理关系（表），而不是整个数据库，它只依赖于键。我通常将其视为删除所有候选键，就好像您拥有一个候选键以及实际键一样，然后属性在功能上依赖于该键以外的其他东西。
就地址问题而言，拥有潜在重要的实体（例如包含在另一个实体的表中的地址）意味着该地址变得可传递地依赖于客户（例如您的情况）。这意味着该地址仅在客户端幸存时幸存。
那当然不一定是一件坏事，这取决于您是否需要客户（如果没有客户）。
如果是这种情况，那么该地址实际上会失去其作为实体的状态，并成为值对象。假设您有一个Order表，并且想要保存它的发送地址，那么在Order表中保存该地址就可以了。如果您以这种方式考虑地址，那么一件关键的事情就是它变得不可变，它永远都不会改变，发送给订单的地址将始终是相同的，因为它已经发生并且是事实，所以它永远不会改变。 / p>
比方说，您需要存储客户的地址以及工作地址，现在您最终会遇到这样的情况，即客户表中需要更多列，到哪都结束了！出于理智和整洁的考虑，这导致了实际的选择，因此，您创建的地址表可以保留常规格式，也可以仅仅是为了整洁，这取决于您要对新创建的Address实体执行的操作。 / p>
为了使表更易于管理而将其从表中移出通常会导致一对一的关系，而在客户表中或从客户表中移出的形式通常是相同的。
出于正确的原因，需要一些练习来移动内容，但是值得一试。