Relational Notation Edit
Relational notation is a process of transforming an E/R diagram into a more friendly and usable type of diagram that is easily readable. 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 commonly notated with the underscore, Next all other attributes are added. The only rule for attributes is if it happens to be a foreign key it needs to be underscored with a dotted line:
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.
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.
PUBLISHER (Pub_id, Pub_name, City)
AUTHOR_TITLE (Author_id, Title_id)
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.
One of the best advantages of relational notation format is the ease to go from an E/R diagram to an English format of notation rather easily. What this means is, it very easy to turn an E/R diagram into something easily readable and useable, and still capture table names, composite keys, primary keys, foreign keys, and all attributes.. Relational notation is also a great refference point when creating tables in a SQL type program. Relational notion still allows a user or designer an easy way to transfer dependencies and re-create composite keys in a graphical interface if so desired. It is also has an accepted format, which once learned, can be applied to any table structure.
One disadvantage of the relational notation is lack of visual descriptiveness. Essentially, tables created by relationships and tables themselves lose a visual format to model them. This can however be an advantage too though.