Converting an ER diagram to relational model

Question

I know how to convert an entity set, relationship, etc. into the relational model but what i wonder is that what should we do when an entire diagram is given? How do we convert it? Do we create a separate table for each relationship, and for each entity set? For example, if we are given the following ER diagram:

My solution to this is like the following:

 //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) )

My questions are:

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.

If my steps are not true or there is something i am missing, please can you write the steps for conversion? Also, what do we do if there is only participation constraint for a relationship, but no key constraint? Do we again create a single table for the related entity set and relationship?

I appreciate any help, i am new to databases and trying to learn this conversion.

Thank you

Answer 1

Hi @bigO I think it is safe to say that your conversion is true and the steps that you have followed are correct. However from an implementation point of view, there may be room for improvement. What you have implemented is more of a logical model than a physical model

It is common practice to add a Surrogate Instance Identifier to a physical table, this is a general requirement for most persistence engines, and as pointed out by @Pieter Geerkens, aids database efficiency. The value of the instance id for example EmployeeId (INT) would be automatically generated by the database on insert. This would also help with the issue that @Pieter Geerkens has pointed out with the SSN. Add the Id as the first column of all your tables, I follow a convention of tablenameId. Make your current primary keys into secondary keys ( the natural key).

Adding the Ids then makes it necessary to implement a DependentPolicy intersection table

DependentPolicyId, (PK)
PolicyId,
DependentId

You may then need to consider as to what is natural key of the Dependent table.

I notice that you have age as an attribute, you should consider whether this the age at the time the policy is created or the actual age of the dependent, I which case you should be using date of birth.

Other ornamentations you could consider are creation and modified dates.

I also generally favor using the singular for a table ie Employee not Employees.

Welcome to the world of data modeling and design.