Вы находитесь на странице: 1из 3

Relational Notation

Relational notation is a process of transforming an E/R diagram into a more friendly and
usable type of daigram that is easily readalbe. This can be done by taking the names of
each table and its attributes and ordering them in a specific order. You always start with
the primary key(s), which are always underlined. Next all other attributes are added. The
only rule for attributes is if it happens to be a foreign key it needs to be underlined with a
dashed line:

Diagram 1

Looking at this E/R diagram to translate this into relational notation it would look like:

AUTHOR (Author_id, Author_lname, Author_fname, Address, City, State, Zip)

Note: the primary key in the table is underlined to show that it is the unique attribute.

Relational Notation:
TITLE (Title_id, Title, Pub_id)

Note: in this example the attribute Pub_id is what is known as a foreign key because it
links to the following table (PUBLISHER) through that attribute. Normally this is
represented by being placed at the end of the attribute list in the relational notation and is
shown with a dashed underline.
By translating E/R diagrams into relational notation it also makes it easy for an individual
to normalize and denormalize any given table in the schema; and if needed it is not very
complicated to restore relational notation back to E/R diagram format.

Relational notation is a shorthand way to represent E/R diagrams. It is a half-way step


between an abstract tool and an implementation specific tool (SQL create table
commands).

In terms of cardinalities, if you have a 1:1 (one-to-one) relationship between two tables
you can place the foreign key on either side when translating to relational notation, but is
dependant upon the context of the scope of what the prolect is requiring.. If you are
presented with a 1:N (one-to-many) relationship between tables foreign keys
always will be on the many side.
When dealing with suptype/supertype, they are considered a special form of a 1:1
therefore foreign key placement is immaterial, due to the fact that subtypes are know as
inheriting everything from a supertype unless other wise noted.