一段时间以来，我一直在努力弄清楚这一点。例如，假设您有一个人。一个人的属性是他或她的社会安全号码，对吗？但一个人也has有一个社会安全号码。因此，在 ER 图中，您可以为 绘制一个方框，为 绘制一个方框person，ssid然后用菱形连接它们，has。或者，您可以画一个圆，ssid，然后将它连接到一个person方框。
不过，这不仅仅适用于ssid。可以用具体的东西来画，比如汽车、宠物或电话号码，也可以用概念性的东西来画，比如电话号码、友谊或心情。那么，我在哪里画线呢？设计的目的只是为了让一切都写在纸上并且看起来不错，还是我应该使用指南？
一个经验法则是，如果它是“物理的”（具体而不是抽象的），那么它就是一个实体，否则它就是一个属性。
ER 建模的另一个经验法则是，表要么对实体建模，要么对实体之间的关系建模，但绝不会同时对两者建模。可以有其他类型的表，当然例如有时将所有相同类型的属性（例如颜色）放在一个表中是有益的，称为查找表（即既不是实体表也不是关系表但仍然是有效和有用）。
有两种方式来看待这个问题，一种是非正式的方式，另一种是正式的、理论上的方式。
非正式的方式：
如果您的系统对某些东西如此感兴趣以至于您想记录它的属性，那么它可能属于它自己的表。
如果您唯一关心社会安全号码的是它包含的数字（即号码是什么），那么最好将此号码建模为其他事物（例如 PERSON）的属性。
另一方面，如果您的系统关心与 SSID 相关的其他事实，例如发布时间、发布它的办公室以及您可能知道和关心 SSID 的任何其他信息，那么您可能想要拆分您知道的所有内容关于 SSID 到它自己的表中，然后将该表与 PERSON 相关联。
正式方式：
如果规范化规则要求您将关于 SSID 的多个事实（属性）拆分为一个单独的关系（表）——其中社会安全号码是主键，那么 SSID 是一个框而不是一个圆。
具体来说，如果您有仅依赖于 SSID 的属性，那么您可能希望从 PERSON 表中删除这些属性，因为它们对 PERSON 的 ID 仅具有传递依赖性，因此 3NF 要求将这些属性删除到单独的表中。