将ER图转换为关系模型

Question

我知道如何将实体集，关系等转换为关系模型，但我想知道当给出整个图时我们应该怎么做？我们如何转换它？我们是否为每个关系和每个实体集创建一个单独的表？例如，如果给出以下ER图：

我对此的解决方案如下：

 //this part includes the purchaser relationship and policies entity set

CREATE TABLE  Policies (
  policyid  INTEGER,
  cost  REAL,
  ssn  CHAR(11)  NOT NULL,
  PRIMARY KEY (policyid).
  FOREIGN KEY (ssn) REFERENCES Employees,
  ON DELETE CASCADE)


 //this part includes the dependents weak entity set and beneficiary relationship

 CREATE TABLE Dependents (
  pname  CHAR(20),
  age  INTEGER,
  policyid  INTEGER,
  PRIMARY KEY (pname, policyid).
  FOREIGN KEY (policyid) REFERENCES Policies,
  ON DELETE CASCADE)


 //This part includes Employees entity set

 CREATE TABLE Employees(
   ssn Char(11),
   name char (20),
   lot INTEGER,
   PRIMARY KEY (ssn) )

我的问题是：

1)Is my conversion true?
2)What are the steps for converting a complete diagram into relational model. 
Here are the steps that i follow, is it true?
    -I first look whether there are any weak entities or key constraints. If there
     are one of them, then i create a single table for this entity set and the related        
     relationship. (Dependents with beneficiary, and policies with purchaser in my case)
    -I create a separate table for the entity sets, which do not have any participation  
     or key constraints. (Employees in my case)
    -If there are relationships with no constraints, I create separate table for them.
    -So, in conclusion, every relationship and entity set in the diagram are included 
     in a table.

如果我的步骤不正确或者我缺少某些东西，请你写下转换步骤吗？另外，如果关系只有参与约束，但没有关键约束，我们该怎么办？我们是否再次为相关实体集和关系创建一个表？

我感谢任何帮助，我是数据库的新手，并试图学习这种转换。

谢谢

Answer 1

您好@bigO我认为可以肯定地说您的转换是正确的，并且您遵循的步骤是正确的。但是从实施的角度来看，可能还有改进的余地。您实施的更多是逻辑模型而不是物理模型

通常的做法是将代理实例标识符添加到物理表中，这是大多数持久性引擎的一般要求，正如@Pieter Geerkens所指出的那样，有助于数据库效率。例如EmployeeId（INT）的实例id的值将由插入时的数据库自动生成。这也有助于解决@Pieter Geerkens在SSN中指出的问题。将Id添加为所有表的第一列，我遵循 tablename Id的约定。将当前主键设为辅助键（自然键）。

添加ID然后需要实现DependentPolicy交集表

DependentPolicyId, (PK)
PolicyId,
DependentId

然后，您可能需要考虑Dependent表的自然键是什么。

我注意到您将年龄作为属性，您应该考虑这是政策创建时的年龄还是受抚养人的实际年龄，我应该使用出生日期。

您可以考虑的其他装饰是创建和修改日期。

我也普遍赞成将单数用于表格，即雇员而不是雇员。

欢迎来到数据建模和设计的世界。