对于这种简单的联系表，最佳的关系数据库结构是什么？

Question

1-消息属于名称，名称属于电子邮件，电子邮件属于电话号码

2-邮件属于电子邮件，电子邮件属于姓名，姓名属于电话号码

3-许多邮件可以指向单个电子邮件以及姓名和电话号码。 消息属于电子邮件，消息属于名称，消息属于电话号码。

或者有没有更好的结构可以满足规范化要求。 这样做的目的是存储数据，以便电话呼叫者以后可以通过电子邮件和电话号码与联系的人联系。

Answer 1

您没有正确表达自己的要求。因此，我们无法提供精确的解决方案。

实体

考虑entities，而不是考虑列和字段。您尝试在数据库和应用程序中跟踪的现实情况是什么。

如果为兽医执业制定约会计划系统，则您有多个实体：客户，动物，医生，医疗助手，约会/访问。

如果您的跟踪员工进行交流，则您有Employee和Message。

属性

在标识了实体之后，您标识了attributes。您希望在数据库和应用程序中跟踪每个实体的哪些方面？例如，您的员工具有身高和头发颜色作为属性，但是这两个与您的消息传递应用程序无关。另一方面，每个员工都有作为属性的沟通渠道，例如，可能具有电子邮件地址，办公电话和个人移动电话。同样，您必须询问要跟踪的对象。

关系和基数

如果您要查找员工的电子邮件地址或电话，但在不考虑通信方式的情况下跟踪消息，则我们有两个表。这种关系是，每个雇员可以有零个，一个或多个消息，并且每个消息必须恰好有一个雇员。表之间相关行的这种量化被正式称为cardinality。

相当于ASCII-art crows-feet，相当于我的ERD diagramming：

  

[员工] -1 ----- 0-1-<[消息]

关于那些表上的列：

• 当前名称，当前电子邮件地址和当前办公室电话分机号都是employee表上的属性（列）。
• message表具有一列content。

键

employee表还必须具有primary key列。主键通常是identity column（整数的自动递增序列）或UUID。

message表作为墙壁带有一个主键列。此外，message表必须具有foreign key列。外键列包含向其发送消息的员工的主键的值。