Chapter 2: Data Modeling

This chapter introduces data modeling using the Entity-Relationship (ER) approach. The basic
techniques described are applicable to the development of microcomputer based relational database
applications as well as those who use relational database servers such as MS SQL Server or Oracle.
The aims of this chapter are:

To explain the need for entity-relationship modeling

To explain the terms entity-relationship model, entity-relationship diagram

To define the terms entity type, entity, attribute, attribute value, primary key, relationship,
relationship type

To define the grammar of entity-relationship diagrams

To describe ways of classifying relationship types

To describe the terms unary, binary, ternary, degree, cardinality and optionality with regard to
relationship types

To show how many-many relationship types can be split into one-many relationship types

To give various examples of entity-relationship modeling

Data Modeling Overview

A data model is a conceptual representation of the data structures that are required by a database.
The data structures include the data objects, the associations between data objects, and the rules
which govern operations on the objects. As the name implies, the data model focuses on what data is
required and how it should be organized rather than what operations will be performed on the data. To
use a common analogy, the data model is equivalent to an architect's building plans.
A data model is independent of hardware or software constraints. Rather than try to represent the
data as a database would see it, the data model focuses on representing the data as the user sees it
in the "real world". It serves as a bridge between the concepts that make up real-world events and
processes and the physical representation of those concepts in a database.
Methodology
There are two major methodologies used to create a data model: the Entity-Relationship (ER)
approach and the Object Model. This document uses the Entity-Relationship approach.
Data Modeling In the Context of Database Design
Database design is defined as: "design the logical and physical structure of one or more databases to
accommodate the information needs of the users in an organization for a defined set of applications".
The design process roughly follows five steps:
1.
2.

planning and analysis

conceptual design

3.

logical design

4.

physical design

5.

implementation

The data model is one part of the conceptual design process. The other, typically is the functional
model. The data model focuses on what data should be stored in the database while the functional
model deals with how the data is processed. To put this in the context of the relational database, the

data model is used to design the relational tables. The functional model is used to design the queries
which will access and perform operations on those tables.
Components of A Data Model
The data model gets its inputs from the planning and analysis stage. Here the modeler, along with
analysts, collects information about the requirements of the database by reviewing existing
documentation and interviewing end-users.
The data model has two outputs. The first is an entity-relationship diagram which represents the data
structures in a pictorial form. Because the diagram is easily learned, it is valuable tool to communicate
the model to the end-user. The second component is a data document. This a document that describes
in detail the data objects, relationships, and rules required by the database. The dictionary provides
the detail required by the database developer to construct the physical database.

The Entity-Relationship Model

A data model is a plan for building a database. To be effective, it must be simple enough to
communicate to the end user the data structure required by the database yet detailed enough for the
database design to use to create the physical structure.
The Entity-Relation Model (ER) is the most common method used to build data models for relational
databases. It was originally proposed by Peter in 1976 [Chen76] as a way to unify the network and
relational database views. Simply stated the ER model is a conceptual data model that views the real
world as entities and relationships. A basic component of the model is the Entity-Relationship diagram
which is used to visually represent data objects. Since Chen wrote his paper the model has been
extended and today it is commonly used for database design.
When a relational database is to be designed, an entity-relationship diagram is drawn at an early
stage and developed as the requirements of the database and its processing become better
understood. Drawing an entity-relationship diagram aids understanding of an organization's data
needs and can serve as a schema diagram for the required system's database. A schema diagram is
any diagram that attempts to show the structure of tha data in a database. Nearly all systems analysis
and design methodologies contain entity-relationship diagramming as an important part of the
methodology and nearly all CASE (Computer Aided Software Engineering) tools contain the facility for
drawing entity-relationship diagrams. An entity-relationship diagram could serve as the basis for the
design of the files in a conventional file-based system as well as for a schema diagram in a database
system.
The details of how to draw the diagrams vary slightly from one method to another, but they all have
the same basic elements: entity types, attributes and relationships. These three categories are
considered to be sufficient to model the essentially static data-based parts of any organization's
information processing needs.

Basic Constructs of E-R Modeling

Entity Types
An entity type is any type of object that we wish to store data about. Which entity types you decide to
include on your diagram depends on your application. In an accounting application for a business you
would store data about customers, suppliers, products, invoices and payments and if the business
manufactured the products, you would need to store data about materials and production steps. Each
of these would be classified as an entity type because you would want to store data about each one.
In an entity-relationship diagram an entity type is shown as a box. In Fig. 2.1, CUSTOMER is an entity
type. Each entity type is shown once. There may be many entity types in an entity-relationship
diagram. The name of an entity type is singular since it represents a type.

Fig. 2.1 An entity type CUSTOMER and one of its attributes Cus_no
Attributes
The data that we want to keep about each entity within an entity type is contained in attributes. An
attribute is some quality about the entities that we are interested in and want to hold on the database.
In fact we store the value of the attributes on the database. Each entity within the entity type will
have the same set of attributes, but in general different attribute values. For example the value of the
attribute ADDRESS for a customer J. Smith in a CUSTOMER entity type might be '10 Downing St.,
London' whereas the value of the attribute 'address' for another customer J. Major might be '22
Railway Cuttings, Cheam'.
There will be the same number of attributes for each entity within an entity type. That is one of the
characteristics of entity-relationship modelling and relational databases. We store the same type of
facts (attributes) about every entity within the entity type. If you knew that one of your customers
happened to be your cousin, there would be no attribute to store that fact in, unless you wanted to
have a 'cousin-yes-no' attribute, in which case nearly every customer would be a `no', which would be
considered a waste of space.
3.4 Primary Key
Attributes can be shown on the entity-relationship diagram in an oval. In Fig. 3.1, one of the attributes
of the entity type CUSTOMER is shown. It is up to you which attributes you show on the diagram. In
many cases an entity type may have ten or more attributes. There is often not room on the diagram
to show all of the attributes, but you might choose to show an attribute that is used to identify each
entity from all the others in the entity type. This attribute is known as the primary key. In some cases
you might need more than one attribute in the primary key to identify the entities.
In Fig. 2.1, the attribute CUS_NO is shown. Assuming the organization storing the data ensures that
each customer is allocated a different cus_no, that attribute could act as the primary key, since it
identifies each customer; it distinguishes each customer from all the rest. No two customers have the
same value for the attribute cus_no. Some people would say that an attribute is a candidate for being
a primary key because it is `unique'. They mean that no two entities within that entity type can have
the same value of that attribute. In practice it is best not to use that word because it has other
connotations.
As already mentioned, you may need to have a group of attributes to form a primary key, rather than
just one attribute, although the latter is more common. For example if the organization using the
CUSTOMER entity type did not allocate a customer number to its customers, then it might be
necessary to use a composite key, for example one consisting of the attributes SURNAME and
INITIALS together, to distinguish between customers with common surnames such as Smith. Even this
may not be sufficient in some cases.
Apart from serving as an identifier for each entity within an entity type, the primary key also serves as
the method of representing relationships between entities. The primary key becomes a foreign key in
all those entity types to which it is related in a one-one or one-many relationship type.
Relationship Types
The first two major elements of entity-relationship diagrams are entity types and attributes. The final
element is the relationship type. Sometimes, the word 'types' is dropped and relationship types are
called simply 'relationships' but since there is a difference between the terms, one should really use
the term relationship type.
Real-world entities have relationships between them, and relationships between entities on the entityrelationship diagram are shown where appropriate. An entity-relationship diagram consists of a
network of entity types and connecting relationship types. A relationship type is a named association
between entities. Individual entities have individual relationships of the type between them. An
idividual person (entity) occupies (relationship) an individual house (entity). In an entity-relationship
diagram, this is generalized into entity types and relationship types. The entity type PERSON is related
to the entity type HOUSE by the relationship type OCCUPIES. There are lots of individual persons, lots
of individual houses, and lots of individual relationships linking them.
Fig. 2.2 shows a single relationship type 'Received' and its inverse relationship type 'Was_sent_to'
between the two entity types CUSTOMER and INVOICE. It is very important to name all relationship
types. The reader of the diagram must know what the relationship type means and it is up to you the
designer to make the meaning clear from the relationship type name. The direction of both the

relationship type and its inverse should be shown to aid clarity and immediate readibility of the
diagram. The tense of the relationship type should also be clear from its name.

Fig. 2.2 Representing a relationship on an entity-relationship diagram.

In the development of a database system, many people will be reading the entity-relationship diagram
and so it should be immediately readable and totally unambiguous. When the database is
implemented, the entity-relationship diagram will continue to be used by application programmers and
query writers. Misinterpretation of the model can result in many lost man-hours going down wrong
tracks.
In Fig. 2.2 what is being 'said' is that customers received invoices and invoices were_sent_to
customers. How many invoices a customer might have received (the maximum number and the
minimum number) and how many customers an invoice might have been sent to, is shown by the
degree of the relationship type. The 'degree' of relationship types is defined below.
Fig. 2.3 is the entity-relationship diagram and information about individual entities and which entity is
linked to which is lost. The reason for this is simply that in a real database there would be hundreds of
customer and invoice entities and it would be impossible to show each one on the entity-relationship
diagram.

Fig. 2.3 Degree of relationship.

Ways of Classifying Relationships Types
A relationship type can be classified by the number of entity types involved, and by the degree of the
relationship type, as is shown in Fig. 3.5. These methods of classifying relationship types are
complementary. To describe a relationship type adequately, you need to say what the name of the
relationship type and its inverse are and their meaning, if not clear from their names and you also
need to declare the entity type or types involved and the degree of the relationship type that links the
entities. We now discuss the latter two items.
The purpose of discussing the number of entity types is to introduce the terms unary relationship
type, binary relationship type, and ternary relationship type, and to give examples of each. The
number of entity types in the relationship type affects the final form of the relational database.
The purpose of discussing the degree of relationship types is to define the relevant terms, to give
examples, and to show the impact that the degree of a relationship type has on the form of the final
implemented relational database.

Fig. 2.4 Ways of classifying relationships.

Number of Entity Types
If a relationship type is between entities in a single entity type then it is called a unary relationship
type. One example is the relationship `friendship' between entities within the entity type PERSON. If a
relationship type is between entities in one entity type and entities in another entity type then it is
called a binary relationship type because two entity types are involved in the relationship type. An
example is the relationship 'Received' in Fig. 2.3 between customers and invoices. It is possible to
model relationship types involving more than two entity types. This relationship type is said to be a
ternary relationship type since three entity types are involved. Examples of unary, binary and ternary
relationship types are shown in Fig. 2.5.

Fig. 2.5 There can be one, two, three or more entity types involved in a relationship.

Removing Ternary relationship types

It is advantageous to remove ternary and higher order relationship types. One reason is that it might
be considered more `natural' to think of entity types having attributes than relationship types having
them. It is in fact always possible to remove these high-order relationship types and replace them with
an entity type. A ternary relationship type is then replaced by an entity type and three binary
relationship types linking it to the entity types which were originally linked by the ternary. A
quartenary relationship type would be replaced by an entity type and four relationship types and so
on.
In Fig. 2.5c the ternary relationship type 'performs' (verb) can be replaced with an entity type
'recommendation' (noun), and a binary relationship between it and each of the entity types
OPERATOR, OPERATION, and PART (three binary relationships in all). It is natural to think about the
attributes of a performance but not so natural to think about the attributes of a relationship type
`performs'. Typical non-key attributes of the PERFORMANCE might be DATE_PERFORMED and STATUS
(whether the recommendation has been approved or not). Another advantage of replacing the ternary
relationship type is that a ternary or higher-order relationship type cannot in any real sense have a
direction.
When the single ternary relationship type has been replaced by three binary relationship types, Each
of the relationships and their inverses can be named, lending considerably more semantic information
to the diagram. Clearly, replacing the ternary has allowed us to convey more semantics about the realworld situation than before.
The general conclusion then is that the only relationship types that should be shown on the entity
relationship diagram should be either unary (involving one entity type) or binary (involving two entity
types).
As stated, the naming of the new entity type and the new relationship types is important.
Inappropriately naming the entity type or omitting or inappropriately naming the relationship types
will lead to misunderstanding and consequent incorrect processing of data (possibly caused by
programmers misunderstanding the `meaning' of the database schema) and incorrect data appearing
on the database. As a general guide entity types should have noun names (e.g.PERFORMANCE) and
relationships should have the form of a verb (e.g. `made' or `concerned' or `was_for').

The Degree of a Relationship Type

Cardinality and Optionality
The maximum degree is called cardinality and the minimum degree is called optionality. In another
context the terms 'degree' and 'cardinality' have different meanings. 'Degree' is the term used to
denote the number of attributes in a relation while `cardinality' is the number of tuples in a relation.
Here, we are not talking about relations (database tables) but relationship types, the associations
between database tables and the real world entity types they model.
There are three symbols used to show degree. A circle means zero, a line means one and a crows foot
means many. The cardinality is shown next to the entity type and the optionality (if shown at all) is
shown behind it. Refer to Fig. 3.10(a). In Fig. 3.10(b) the relationship type R has cardinality one-tomany because one A is related by R to many Bs and one B is related (by R's inverse) to one A.
Generally, the degree of a relationship type is described by its cardinality. R would be called a 'onemany' or a 'one-to-many' or a '1 : N' relationship type. To fully describe the degree of a relationship
type however we should also specify its optionality.

Fig. 2.6 Relationship degree.

The optionality of relationship type R in Fig. 2.6(b) is one as shown by the line. This means that the
minimum number of Bs that an A is related to is one. A must be related to at least one B. Considering
the optionality and cardinality of relationship type R together, we can say that one A entity is related
by R to one or more B entities. Another way of describing the optionality of one, is to say that R is a
mandatory relationship type. An A must be related to a B. R's optionality is mandatory. With
optionality, the opposite of 'mandatory' is optional. In Fig. 2.6(b) the inverse of R happens to be
optional, as shown by the circle. The inverse of R is an optional relationship type. This means that one
B might not be related (by the inverse of R) to any A. There may be a B entity not related to any A
entity. Considering the optionality and cardinality of the inverse of R together, we can say that a B
entity is related (by the inverse of R) to zero or one A entities.
Fig. 2.7 summarizes the terminology in another example.

Fig. 2.7 More examples of our relationship terminology.

Deriving a One-Many relationship type

In Fig. 2.8 the procedure for deriving the degree of a relationship type and putting it on the entity
relationship diagram is shown. The example concerns part of a sales ledger system. Customers may
have received zero or more invoices from us. The relationship type is thus called `received' and is
from CUSTOMER to INVOICE. The arrow shows the direction. The minimum number of invoices the
customer has received is zero and thus the `received' relationship type is optional. This is shown by
the zero on the line. The maximum number of invoices the customer may have received is `many'.
This is shown by the crows foot. This is summarized in Fig. 2.8(a). To complete the definition of the
relationship type the next step is to name the inverse relationship type. Clearly if a customer received
an invoice, the invoice was sent to the customer and this is an appropriate name for this inverse
relationship type. Now consider the degree of the inverse relationship type. The minimum number of
customers you would send an invoice to is one; you wouldn't send it to no-one. The optionality is thus
one. The inverse relationship type is mandatory. The maximum number of customers you would send
an invoice to is also one so the cardinality is also one. This is summarized in Fig. 2.8(b). Fig. 2.8(b)
shows the completed relationship.

Fig. 2.8 Deriving a 1:N (one:many) relationship.

A word of warning is useful here. In order to obtain the correct degree for a relationship type (one-one
or one-many or many-many) you must ask two questions. Both questions must begin with the word
`one'. In the present case (Fig. 3.13), the two questions you would ask when drawing in the
relationship line and deciding on its degree would be:
Question 1: One customer received how many invoices?
Answer: Zero or more.
Question 2: One invoice was sent to how many customers?
Answer: One.
This warning is based on observations of many student database designers getting the degree of
relationship types wrong. The usual cause of error is only asking one question and not starting with
the word 'one'. For example a student might say (incorrectly): 'Many customers receive many invoices'
(which is true) and wrongly conclude that the relationship type is many-many. The second most
common source of error is either to fail to name the relationship type and say something like
'Customer to Invoice is one-to-many' (which is meaningless) or give the relationship type an
inappropriate name.

Deriving a Many-Many relationship type

Fig. 2.9 gives an example of a many-many relationship type being derived.

Fig. 2.9 Deriving a M:N (many-many) relationship.

The two questions you have to ask to correctly derive the degree of this relationship (and the
answers) are:
Question 1: One customer purchased how many product types?
Answer: One or more.
Question 2: One product type was purchased by how many customers?
Answer: Zero or more.
Note that the entity type has been called PRODUCT TYPE rather than PRODUCT which might mean an
individual piece that the customer has bought. In that case the cardinality of 'was_purchased_by'
would be one not many because an individual piece can of course only go to one customer. This point
is another common source of error: the tendency to call one item (e.g. an individual 4" paintbrush) a
product and the whole product type (or 'line') (e.g. the 4" paintbrush product type) a product. You
should make the meaning clear from the name you give the entity type.
We have assumed here that every customer on the database has purchased at least one product;
hence the mandatory optionality of `purchased'. If this were not true in the situation under study then
a zero would appear instead. The zero optionality of 'was_purchased_by' is due to our assumption that
a product type might as yet have had no purchases at all.
In practice it is wise to replace many-many relationship types such as this with a set (often two) of
one-many relationship types and a set (often one) of new, previously hidden entity types. This is
covered in a later section in this chapter.

Deriving a One-One relationship type

Fig. 2.10 gives an example of a one-one relationship type being derived. It concerns a person and his
or her birth certificate. We assume that everyone has one and that a certificate registers the birth of
one person only.

Fig. 2.10 Deriving a 1:1 (one:one) relationship.

Question 1: How many birth certificates has a person?
Answer: One.
Question 2: How many persons is a birth certificate owned by?
Answer: One.
Where there is a one-one relationship type we have the option of merging the two entity types. The
birth certificate attributes may be considered as attributes of the person and placed in the person
entity type. The birth certificate entity type would then be removed. There are two reasons for not
doing this. Firstly, the majority of processing involving PERSON records might not involve any or many
of the BIRTH_CERTIFICATE attributes. The BIRTH CERTIFICATE attributes might only be subject to
very specific processes which are rarely executed. The second reason for not merging might be that
the BIRTH CERTIFICATE entity type has relationship types to other entity types that the PERSON entity
type does not have. The two entity types have different relationship types to other entity types.

Resolve Many-To-Many Relationships

Many-to-many relationships cannot be used in the data model because they cannot be represented by
the relational model. Therefore, many-to-many relationships must be resolved early in the modeling
process. The strategy for resolving many-to-many relationship is to replace the relationship with an
association entity and then relate the two original entities to the association entity. This strategy is
demonstrated below Figure 2.11 (a) shows the many-to-many relationship:
Employees may be assigned to many projects.
Each project must have assigned to it more than one employee.
In addition to the implementation problem, this relationship presents other problems. Suppose we
wanted to record information about employee assignments such as who assigned them, the start date
of the assignment, and the finish date for the assignment. Given the present relationship, these
attributes could not be represented in either EMPLOYEE or PROJECT without repeating information.
The first step is to convert the relationship assigned to to a new entity we will call ASSIGNMENT.
Then the original entities, EMPLOYEE and PROJECT, are related to this new entity preserving the
cardinality and optionality of the original relationships. The solution is shown in Figure 1B.

Figure 2.11: Resolution of a Many-To-Many Relationship

Notice that the schema changes the semantics of the original relation to
employees may be given assignments to projects
and projects must be done by more than one employee assignment.
Transform Complex Relationships into Binary Relationships
Complex relationships are classified as ternary, an association among three entities, or n-ary, an
association among more than three, where n is the number of entities involved. For example, Figure
2.12 shows the relationship
Employees can use different skills on any one or more projects.
Each project uses many employees with various skills.
Complex relationships cannot be directly implemented in the relational model so they should be
resolved early in the modeling process. The strategy for resolving complex relationships is similar to
resolving many-to-many relationships.

Figure 2.12: Transforming a Complex Relationship

Eliminate redundant relationships

A redundant relationship is a relationship between two entities that is equivalent in meaning to
another relationship between those same two entities that may pass through an intermediate entity.
For example, Figure 2.13 shows a redundant relationship between DEPARTMENT and WORKSTATION.
This relationship provides the same information as the relationships DEPARTMENT has EMPLOYEES and
EMPLOYEEs assigned WORKSTATION. Figure 3B shows the solution which is to remove the redundant
relationship DEPARTMENT assigned WORKSTATIONS.
Figure 2.13: Removing A Redundant Relationship

Adding Attributes to the Model

Primary and Foreign Keys
Primary and foreign keys are the most basic components on which relational theory is based. Primary
keys enforce entity integrity by uniquely identifying entity instances. Foreign keys enforce referential
integrity by completing an association between two entities. The next step in building the basic data
model to
1.
2.

identify and define the primary key attributes for each entity
validate primary keys and relationships

3.

migrate the primary keys to establish foreign keys

Define Primary Key Attributes

Attributes are data items that describe an entity. An attribute instance is a single value of an attribute
for an instance of an entity. For example, Name and hire date are attributes of the entity EMPLOYEE.
"Jane Hathaway" and "3 March 1989" are instances of the attributes name and hire date.
The primary key is an attribute or a set of attributes that uniquely identify a specific instance of an
entity. Every entity in the data model must have a primary key whose values uniquely identify
instances of the entity.
To qualify as a primary key for an entity, an attribute must have the following properties:

it must have a non-null value for each instance of the entity

the value must be unique for each instance of an entity

the values must not change or become null during the life of each entity instance

In some instances, an entity will have more than one attribute that can serve as a primary key. Any
key or minimum set of keys that could be a primary key is called a candidate key. Once candidate
keys are identified, choose one, and only one, primary key for each entity. Choose the identifier most
commonly used by the user as long as it conforms to the properties listed above. Candidate keys
which are not chosen as the primary key are known as alternate keys.
An example of an entity that could have several possible primary keys is Employee. Let's assume that
for each employee in an organization there are three candidate keys: Employee ID, Social Security
Number, and Name.
Name is the least desirable candidate. While it might work for a small department where it would be
unlikely that two people would have exactly the same name, it would not work for a large organization
that had hundreds or thousands of employees. Moreover, there is the possibility that an employee's
name could change because of marriage. Employee ID would be a good candidate as long as each
employee were assigned a unique identifier at the time of hire. Social Security would work best since
every employee is required to have one before being hired.
Composite Keys
Sometimes it requires more than one attribute to uniquely identify an entity. A primary key that made
up of more than one attribute is known as a composite key. Figure 2.15 shows an example of a
composite key. Each instance of the entity Work can be uniquely identified only by a composite key
composed of Employee ID and Project ID.
Figure 2.15: Example of Composite Key
WORK

Employee ID

Project ID Hours_Worked

01

01

200

01

02

120

02

01

50

02

03

120

03

03

100

03

04

200

Artificial Keys
An artificial key is one that has no meaning to the business or organization. Artificial keys are
permitted when 1) no attribute has all the primary key properties, or 2) the primary key is large and
complex.
Primary Key Migration
Dependent entities, entities that depend on the existence of another entity for their identification,
inherit the entire primary key from the parent entity. Every entity within a generalization hierarchy
inherits the primary key of the root generic entity.
Define Key Attributes
Once the keys have been identified for the model, it is time to name and define the attributes that
have been used as keys.

There is no standard method for representing primary keys in ER diagrams. For this document, the
name of the primary key followed by the notation (PK) is written inside the entity box. An example is
shown below.
Figure 2.16: Entities with Key Attributes

Validate Keys and Relationships

Basic rules governing the identification and migration of primary keys are:

Every entity in the data model shall have a primary key whose values uniquely identify entity
instances.

The primary key attribute cannot be optional (i.e., have null values).

The primary key cannot have repeating values. That is, the attribute may not have more than
one value at a time for a given entity instance is prohibited. This is known as the No Repeat
Rule.

Entities with compound primary keys cannot be split into multiple entities with simpler primary
keys. This is called the Smallest Key Rule.

Two entities may not have identical primary keys with the exception of entities within
generalization hierarchies.

The entire primary key must migrate from parent entities to child entities and from supertype,
generic entities, to subtypes, category entities.

Foreign Keys
A foreign key is an attribute that completes a relationship by identifying the parent entity. Foreign
keys provide a method for maintaining integrity in the data (called referential integrity) and for
navigating between different instances of an entity. Every relationship in the model must be supported
by a foreign key.
Identifying Foreign Keys
Every dependent and category (subtype) entity in the model must have a foreign key for each
relationship in which it participates. Foreign keys are formed in dependent and subtype entities by
migrating the entire primary key from the parent or generic entity. If the primary key is composite, it
may not be split.
Foreign Key Ownership
Foreign key attributes are not considered to be owned by the entities to which they migrate, because
they are reflections of attributes in the parent entities. Thus, each attribute in an entity is either
owned by that entity or belongs to a foreign key in that entity.
If the primary key of a child entity contains all the attributes in a foreign key, the child entity is said to
be "identifier dependent" on the parent entity, and the relationship is called an "identifying
relationship." If any attributes in a foreign key do not belong to the child's primary key, the child is not
identifier dependent on the parent, and the relationship is called "non identifying."

Diagramming Foreign Keys

Foreign keys attributes are indicated by the notation (FK) beside them. An example is shown in Figure
2.16 above.
Summary
Primary and foreign keys are the most basic components on which relational theory is based. Each
entity must have a attribute or attributes, the primary key, whose values uniquely identify each
instance of the entity. Every child entity must have an attribute, the foreign key, which completes the
association with the parent entity.

Non-key Attributes
Non-key attributes describe the entities to which they belong. In this section, we discuss the rules for
assigning non-key attributes to entities and how to handle multivalued attributes.
Relate attributes to entities
Non-key attributes can be in only one entity. Unlike key attributes, non-key attributes never migrate,
and exist in only one entity. from parent to child entities.
The process of relating attributes to the entities begins by the modeler, with the assistance of the endusers, placing attributes with the entities that they appear to describe. You should record your
decisions in the entity attribute matrix discussed in the previous section. Once this is completed, the
assignments are validated by the formal method of normalization.
Before beginning formal normalization, the rule is to place non-key attributes in entities where the
value of the primary key determines the values of the attributes. In general, entities with the same
primary key should be combined into one entity. Some other guidelines for relating attributes to
entities are given below.
Parent-Child Relationships

With parent-child relationships, place attributes in the parent entity where it makes sense to
do so (as long as the attribute is dependent upon the primary key)

If a parent entity has no non-key attributes, combine the parent and child entities.

Multivalued Attributes
If an attribute is dependent upon the primary key but is multivalued, has more than one value for a
particular value of the key), reclassify the attribute as a new child entity. If the multivalued attribute is
unique within the new entity, it becomes the primary key. If not, migrate the primary key from the
original, now parent, entity.
For example, assume an entity called PROJECT with the attributes Proj_ID (the key), Proj_Name,
Task_ID, Task_Name

Figure 2.17
PROJECT

Proj_ID

Proj_Name Task_ID Task_Name

01

01

Analysis

01

02

Design

01

03

Programming

01

04

Tuning

02

01

Analysis

Task_ID and Task_Name have multiple values for the key attribute. The solution is to create a new
entity, let's call it TASK and make it a child of PROJECT. Move Task_ID and Task_Name from PROJECT
to TASK. Since neither attribute uniquely identifies a task, the final step would be to migrate Proj_ID
to TASK.
Attributes That Describe Relations
In some cases, it appears that an attribute describes a relationship rather than an entity (in the Chen
notation of ER diagrams this is permissible). For example,
a MEMBER borrows BOOKS.
Possible attributes are the date the books were checked out and when they are due. Typically, such a
situation will occur with a many-to-many relationship and the solution is the same. Reclassify the
relationship as a new entity which is a child to both original entities. In some methodologies, the
newly created is called an associative entity. See Figure 2.18 for an example of an converting a
relationship into an associative entity.

EXERCISES/ASSIGNMENTS:

Exercise 1 - CARS
Identify all entity types, attributes, relationship types and their degrees in the following case. Hence
draw an entity-relationship diagram.
An organization makes many models of cars, where a model is characterized by a name and a suffix
(such as GL or XL which indicates the degree of luxury) and an engine size.
Each model is made up from many parts and each part may be used in the manufacture of more than
one model. Each part has a description and an id code. Each model of car is produced at just one of
the firm's factories, which are located in London, Birmingham, Bristol, Wolverhampton and Manchester
- one in each city. A factory produces many models of car and many types of part although each type
of part is produced at one factory only.

Exercise 2 - STUDENTS AND COURSES (Similar to Exercise 2)

Draw an entity-relationship diagram for the following scenario, stating any assumptions you find it
necessary to make, and showing unknown cardinalities and optionalities using question marks on the
relationship line. Show also the attributes explicitly mentioned in the scenario and underline any you
consider suitable candidates for being primary keys.
It is required to keep the following information on students, courses and subcourses. Each student has
a name, identification number, home address, term address, and a number of qualifications for which
the subject (e.g. maths), grade (e.g. C) and level (e.g. `A' level) are recorded. Each student is
registered for one course where each course has a name (e.g. Information Systems) and an
identification number. Record is kept of the number of students registered for each course.
Each course is divided into subcourses where a subcourse may be part of more than one course.
Information on subcourses includes the name, identification number and the number of students
taking the course.

Exercise 3 - MORTGAGES
Draw an entity-relationship diagram for the following. Produce also a list of questions you would have
to have answered in order to complete the model.
In a case study of this kind, and in particular in exam questions, there is not usually the space to
completely specify a problem. Remember also that not all the information given in a case study of this
type is necessarily relevant. Some information, while relevant to the organization concerned, might
not be relevant as far as database design is concerned.
Members of a friendly society invest money in any one of the society's branches. A member may hold
a number of investment accounts. Each investment account is associated with the branch where it was
opened, but money may be paid in or withdrawn at any branch. For each account, the member holds
an account book to record all transactions. A member may also have one mortgage account. All
mortgage accounts are associated with the Head Office. Payments may be transferred from any
investment account into the mortgage account.

Refrerences
Batini, C., S. Ceri, S. Kant, and B. Navathe. Conceptual Database Design: An Entity Relational
Approach. The Benjamin/Cummings Publishing Company, 1991.

Date, C. J. An Introduction to Database Systems, 5th ed. Addison-Wesley, 1990.

Fleming, Candace C. and Barbara von Halle. Handbook of Relational Database Design. Addison-Wesley,
1989.
Kroenke, David. Database Processing, 2nd ed. Science Research Associates, 1983.
Martin, James. Information Engineering. Prentice-Hall, 1989.
Reingruber, Michael C. and William W. Gregory. The Data Modeling Handbook: A Best-Practice
Approach to Building Quality Data Models. John Wiley & Sons, Inc., 1994.
Simsion, Graeme. Data Modeling Essentials: Analysis, Design, and Innovation. International Thompson
Computer Press, 1994.
Teory, Toby J. Database Modeling & Design: The Basic Principles, 2nd ed.. Morgan Kaufmann
Publishers, Inc., 1994