Translation of ER Model to Relational Schema

Remember, an ER Model is intended as a description of real-world entities. Although it is

constructed in such a way as to allow easy translation to the relational model, this is not an
entirely trivial process.

The textbook (Connolly and Begg) devotes an entire chapter to this process of
translation, and we spent a couple of sessions in class going over it. Before attempting
the second assignment or completing this part of the project you should re-read chapter
8 (pages 242-267). Chapter 11 (pages 327-351) is a worked example of this process.

The notes below therefore focus on two supplemental areas. One is to summarize the key
points. Another is to point out places where the methodology given in the textbooks differs from
what will be required in this course.

Differences from the Book

 The textbook tells you to redraw your conceptual ERM in a simplified form as a Logical
Data Model. This uses ER notation, but employs only the limited set of conventions that
map directly onto the relational model. Then you can translate this logical data model
directly to a relational schema. You will find this a helpful thing to do – at least for the
parts of the diagram that have to change. However, there is no need to hand in this
logical data model. Just use it for your own convenience.

 What you should hand in is a relational schema in the format used on pages 250 and
251. This looks like the following:

Relation_Name (Attribute_1, Attribute_2, …. Attribute_N)

Primary_Key (Key Attribute_1)  remember, the key may be

compound!

Foreign_Key (Attribute_In_This_Relation) references

Other_Relation. Attribute_In_Other_Table
The Basics

An entity type turns into a table. Give it a sensible name – avoid Oracle reserved
words. Remember that Oracle does not allow spaces in names and is not case sensitive.
Follow a consistent set of conventions.

Each attribute turns into a column in the table. Keep the attribute domains handy
– you will need them later when you implement the schema in Oracle.

The primary key of the entity is the primary key of the table. It can be
composite if required. It can never be null.

There is no such thing as a multi-valued attribute in a relational database.

If you have a multi-valued attribute, take the attribute and turn it into a new entity of its
own. Then make a 1: M relationship between the new entity and the existing one. Then
convert as normal.

Modeling Relationships

This is harder. Remember, to truly represent a relationship you need to make sure that the
appropriate foreign keys are in place in the schema to allow joins between tables.
However, every time you construct a new query involving these tables you will need to
specify the appropriate join conditions.

Even if you define foreign keys, Oracle will not figure out the joins for you. This makes the
relational model very flexible, but also makes queries hard to write for the novice.

 All relationships turn into foreign keys. Some of them also turn into an extra
table. They may also turn into “not null” constraints.

 To represent a 1: M relationship, take the primary key of the table on

the “1” side and insert it as a foreign key into the table on the “M” side.

This is the most basic use of a foreign key. It may make sense to rename the foreign key to
reflect its relationship to the table you are inserting it into.
To represent a 1:1 relationship
You have a choice. Ask yourself whether it makes more sense to leave this as two
separate tables, or to join them together to make one big table.

This will depend on whether records will usually exist in both tables, how data will be
accesses, if joins will be made constantly or only occasionally when data is queried, etc. If
the relationship is mandatory on both sides, there is probably little point in representing it
as two tables.

Assuming you chose to retain two tables for a 1:1 relationship, you must chose which
table will receive the primary key of the other as a foreign key. If the relationship is mandatory
for one entity but not the other, the put foreign key into the table for which participation is
mandatory. If it is mandatory for neither, ask which is more likely to exist or to be queried. Put
the foreign key in the table that will be accessed less frequently – this minimizes the number
of joins required when querying.

If the 1:1 or 1: M relationship is mandatory, you will need a “not null” constraint on the
foreign key. If the foreign key can never be null, this means it must always refer to a row in
the related table – and therefore means that a row cannot exist in this table without a related
row on the other side of the relationship.

A weak entity will have a foreign key as part of its own primary key. If it has a 1:M
relationship with the strong entity that defines it, it will also have a partial key of its own, to tell
it apart from other weak entities associated with the same strong entity. (For example,
different instances of the same flight number). This partial key, together with the primary key
of the defining entity inserted as a foreign key, together make up the primary key of the table
for the weak entity.

There is no direct representation of a M:N relationship in the relational model.

You will need to turn each M:N relationship between two entities into a separate
relation (table) of its own. This relation will usually have as its own primary key the
combination of two foreign keys – each of these will be the primary key of one of the relations
involved in this relationship. (See page 245 for this technique).
If a relationship has attributes then they need to go into a table.
Where to put them depends on the type of the relationship. In a 1:1 or 1:M relationship, put
them the same place the foreign key goes (on the M side in 1:M). In a M:N relationship, put
them in the new table you create for the relationship.

I advise you to avoid n-ary relationships in the first place

(a single relationship including three or more entities). They can usually be better represented
by using an additional entity and a set of binary relationships. Every n-ary relationship so far
handed into me in an exam or assignment has been produced in error! (See page 245-6 for
details). If you had an n-ary relationship on your ERM then follow these steps to simplify
them – then translate the simpler relationships and the new entity as normal.