我有一个关于规范化的问题，关于我的场景的规范形式是什么级别。我有几个表具有相同的字段-名称address1，address2，邮政编码和电话号码；
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]
不确定标准化是否可以那样工作，但这只是一个想法...
在多个表中放入具有相同含义的列与规范化无关。它与数据库设计的另一种形式化原则有关。克里斯·戴特（Chris Date）称其为The Principle of Orthogonal Design或POOD。
据我所知，关于POOD的形式逻辑尚未像普通形式那样得到深入研究或广泛接受。这是一个观察，而不是批评。
我将讨论第三范式，因为它通常被引用为归一化的合理水平，尽管大约有十种范式。本质上，第3 NF表示表中的任何形式（范式）都不能真正处理关系（表），而不是整个数据库，它只依赖于键。我通常将其视为删除所有候选键，就好像您拥有候选键以及实际键一样，然后属性在功能上依赖于除键之外的其他内容。
就地址问题而言，在表中包含一个可能重要的实体，例如另一个实体的表中的地址意味着该地址成为可传递的依赖者，例如您的客户。这意味着该地址仅在客户端幸存时幸存。
这当然不一定是一件坏事，它取决于您是否需要地址（如果没有客户。）>
如果是这种情况，那么实际上该地址本身就失去了作为实体的状态，并成为一个值对象。假设您有一个Order表，并且想要保存它的发送地址，然后在Order表中保存该地址就可以了。如果您以这种方式考虑地址，那么一件关键的事情就是它变得不可变，它永远不会改变，发送给订单的地址将始终是相同的，因为它已经发生并且是事实，所以它永远不会改变。 >
假设您需要存储客户的地址以及工作地址，现在您最终会遇到这样的情况，即客户表中需要更多的列，到此结束！出于理智和整洁的考虑，这导致了实际的选择，因此您创建的地址表可以保留常规格式，也可以仅仅是为了整洁，这取决于您要对新创建的Address实体执行的操作。 >
为了使表更易于管理而将其从表中移出通常会导致一对一的关系，而在客户表中或在客户机表中，正常形式很可能是相同的。
出于正确的原因，需要一些练习来移动东西，但是值得擅长。