sql - Converting an ER diagram to relational model -

i know how convert entity set, relationship, etc. relational model wonder should when entire diagram given? how convert it? create separate table each relationship, , each entity set? example, if given following er diagram:

my solution following:

 //this part includes purchaser relationship , 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 dependents weak entity set , 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 conversion true? 2)what steps converting complete diagram relational model.  here steps follow, true?     -i first whether there weak entities or key constraints. if there      1 of them, create single table entity set , related              relationship. (dependents beneficiary, , policies purchaser in case)     -i create separate table entity sets, not have participation        or key constraints. (employees in case)     -if there relationships no constraints, create separate table them.     -so, in conclusion, every relationship , entity set in diagram included       in table. 

if steps not true or there missing, please can write steps conversion? also, if there participation constraint relationship, no key constraint? again create single table related entity set , relationship?

i appreciate help, new databases , trying learn conversion.

thank you

hi @bigo think safe conversion true , steps have followed correct. implementation point of view, there may room improvement. have implemented more of logical model physical model

it common practice add surrogate instance identifier physical table, general requirement persistence engines, , pointed out @pieter geerkens, aids database efficiency. value of instance id example employeeid (int) automatically generated database on insert. issue @pieter geerkens has pointed out ssn. add id first column of tables, follow convention of tablenameid. make current primary keys secondary keys ( natural key).

adding ids makes necessary implement dependentpolicy intersection table

dependentpolicyid, (pk) policyid, dependentid 

you may need consider natural key of dependent table.

i notice have age attribute, should consider whether age @ time policy created or actual age of dependent, case should using date of birth.

other ornamentations consider creation , modified dates.

i favor using singular table ie employee not employees.

welcome world of data modeling , design.