我的数据库中已经创建了一些表，现在我需要为这些表绘制ER图。
让我举两个表格的例子：
让我知道表A和表B之间的关系类型是1：1,1：M还是M：M。另外，请告诉我您在达成关系结论时所遵循的步骤顺序。
谢谢， 地塞米松。
答案 0 :(得分：0)
你应该看看这个问题： postgresql-describe-table
实际上，如果没有反面的例子，如果n = m = 1，你就无法知道表格是1：1,1：n还是n：m关系
您可以进行扫描，但确定这种关系的是约束。
如果您没有这些数据，那么您只能用示例演示1：n和n：m，但不能证明1：1不是n：m而没有约束定义。
1：1的关系将如下所示：
PK - PK
这只能是一对一（零或一），因为两个表只能有唯一的密钥，1：n和n：m是不允许的。这必须受某些级别的软件限制，以确保单独表格的PK = PK，或者更常见的是，如果您真的希望1：1数据在同一个表格中存储，标准化。否则，您需要通过事务插入或其他方式确保密钥协调。不建议自动生成密钥。
1：n关系将如下所示：
PK - FK
FK（外键）将其定义为约束到另一个表中的主键，但可以是多重的。
n：m关系将如下所示：
PK - FK | FK - PK
这里有三张桌子。两个带有主键（PK）的规范化表和一个带有FK关系的连接表，用于定义表之间的映射n：m。
当然，所有这些都可能受到使用数据库的代码的限制，因此，表约束是数据模式唯一可靠的定义。
外键必须指向另一个表中的主键，因此您不能拥有FK：FK关系，并且实际上没有数据库定义的PK：PK关系。这必须通过代码进行事务性插入来约束。通常的惯例是按照规范化的数据格式在同一个表中存储PK：PK数据。
好的，那么，添加评论，针对表A和B;所有你可以肯定的是你有主键由pid：identitytype和pid：maritalid组成，如果是这样的话，为了讨论，比如identitytype和maritalid是int，那么你有int：int和int： int，它什么也没告诉你。如果身份类型与婚姻有重叠，那么就没有办法可靠地将它们分开。如果你只是匹配pid，那么你就有了一个N：M关系，因为你有pid：N-pid：M种不同的可能性会导致N：M的关系。
答案 1 :(得分：0)
实体关系模型中的关系与您的想法非常不同。关系不是由外键约束表示的 - 这是旧的网络数据模型，它仅限于二元关系。实体关系模型表示表中实体集之间的n元关系，而不是表之间的关系。
外键约束将一组列的值限制为另一组列的值的子集。它们有效地用于实施实体集（域） - 例如，确保每个person_id列都是表示系统中所有已知人员的列的子集。 FK约束仅在更新期间使用 - 您可以从数据库中删除所有FK，SELECT查询和JOIN将完全像以前一样工作，进一步证明它们不代表关系。
关系是两个或多个实体集之间的关联，每个实体集由合适的密钥表示。关系实例始终记录在表的行中。例如：
驾驶员牌照与人之间的1：1关系将通过将许可证密钥和人员密钥一起作为表的两列来表示，并且两者（单独地）受到唯一约束。这是否在许可证表，人员表或单独的驱动程序许可证表中是实现细节。
汽车与其所有者之间的1：N关系将通过将汽车钥匙和人员钥匙一起作为表的两列来表示，并且在多方面设置的实体受到唯一约束。这通常在记录多方实体属性的表格中实现。
前面的关系非常简单，我们可以对它们进行非规范化，并且不需要在单独的表中记录关系。但是，对于更高的关系，我们需要单独的表：
学生和科目之间的M：N关系将通过将学生密钥和主题密钥组合在一起作为表的两列，以及两者的组合进行唯一约束来表示。
供应商，产品和地区之间的M：N：P关系将通过将供应商密钥，产品密钥和区域密钥一起作为表的三列以及三者唯一约束的组合来表示。
区域，产品和供应商之间的M：N：1关系（唯一的授权）将通过将区域密钥，产品密钥和供应商密钥组合在一起作为表的三列，以及组合区域和产品密钥受到限制。
看模式？
如果该实体集的特征谓词（其必需属性）在不同的表中表示，则关系的每个角色/组件都可以定义外键约束。这意味着单个n元关系可能需要n个不同的FK约束。
从现有表中确定关系的基数：
确定表中表示的实体集。并非所有列都代表实体集 - 有些代表值集，这意味着值本身就是标签或度量。
确定哪些实体集组合被唯一约束在一起。这些是关系的多方面，我们会给它们像M，N，P等变量。
每个其他实体集都依赖于之前的组合，并以基数为1表示。
它并不那么简单。除了实体集之外，表的关键还可以涉及值集。在这些情况下，我们有一个弱实体/识别关系/子类型情况。这些通常是（但不总是）1：N关系，其中子实体的密钥与父实体的密钥部分重叠。
有关详情，请参阅Peter Chen的论文The Entity-Relationship Model - Toward a Unified View of Data。