将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指出，这有助于提高数据库效率。 实例ID的值（例如EmployeeId（INT））将由数据库在插入时自动生成。 这也有助于解决@Pieter Geerkens在SSN中指出的问题。 Id. 将Id添加为所有表的第一列，我遵循 Id的约定。 将当前的主键转换为辅助键（自然键）。

然后添加Id，则有必要实现DependentPolicy相交表

DependentPolicyId, (PK)
PolicyId,
DependentId

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

我注意到您已将年龄作为属性，您应该考虑是创建保单时的年龄还是受抚养人的实际年龄，在这种情况下，您应该使用出生日期。

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

我通常也喜欢在表中使用单数形式，即“雇员”而不是“雇员”。

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