CIT3641 - LECTURE NOTES 3

ADVANCED DATABASES
Data Modelling Processes

(Part 2)
Keys in a Database Management System
What are Keys in a Database Management System (DBMS)?

 KEYS in DBMS is an attribute or set of attributes which helps

you to identify a row(tuple) in a relation(table).

 They allow you to find the relation between two tables.

 Keys help you uniquely identify a row in a table by a

combination of one or more columns in that table.

 Key is also helpful for finding unique record or row from the
table.

 Database key is also helpful for finding unique record or row

from the table.

 Example is indicated in the next slide:

In the above-given example, employee ID is a primary key
because it uniquely identifies an employee record.

In this table, no other employee can have the same

employee ID.
Why we need a Key?

Here are some reasons for using SQL key in the DBMS system.

 Keys help you to identify any row of data in a table. In a real-

world application, a table could contain thousands of records.

 Moreover, the records could be duplicated. Keys in RDBMS

ensure that you can uniquely identify a table record despite
these challenges.

 Allows you to establish and / or identify relationships between

entities / tables.

 Help you to enforce identity and integrity in the relationship.

Types of Keys in DBMS (Database Management System)

There are mainly Eight different types of Keys in DBMS and

each key has it’s different functionality:

1. Super Key
2. Primary Key
3. Candidate Key
4. Alternate Key
5. Foreign Key
6. Compound Key
7. Composite Key
8. Surrogate Key
Here are brief explanations of each of the keys commonly used
in a database management system:

1. Super Key
 A super key is a set of one or more attributes that, taken
together, uniquely identify each record within a table.
 It may contain more attributes than necessary to uniquely
identify records, ie a Super key may have additional
attributes that are not needed for unique identification
 A super key has relaxed rules and includes candidate keys,
primary keys, alternate keys and other attributes.
 A super key may contain null values and repeated attributes.
2. Primary Key
 A primary key is a specific type of super key that uniquely
identifies each record in a table.
 It must be unique for each record and cannot contain null
values.
 Primary keys enforce entity integrity and are used to
establish relationships between tables in a relational
database.

3. Candidate Key
 A candidate key is a minimal super key, meaning it is a super
key with the fewest possible attributes necessary to uniquely
identify records.
 In a table, there may be multiple candidate keys from which
one is chosen to be the primary key.
4. Alternate Key
 An alternate key is any candidate key that is not
selected as the primary key.
 It serves as an alternative means of uniquely identifying
records in a table.

5. Foreign Key
 A foreign key is a field in one table that refers to the
primary key in another table.
 It establishes a relationship between the two tables by
enforcing referential integrity, ensuring that values in the
foreign key column match values in the primary key
column of the related table.
6. Compound Key
 A compound key is a primary key composed of two or more
attributes.
 It is possible that each column may not be unique by itself
within the database.
 It is used when no single attribute uniquely identifies records,
but the combination of multiple attributes does.
 It may also be referred as a composite key. The two terms
are often used interchangeably.

7. Composite Key
 Composite key is another term for a compound key, a
primary key composed of multiple attributes.
 The main difference between the two is that attributes that
make a primary key in composite key are usually NOT used
for any other purpose.
 The individual components of a compound key may however
be used for other roles such as foreign keys.
8. Surrogate Key
 A surrogate key is an artificially generated unique identifier
used as the primary key in a table.
 It has no inherent meaning and is typically implemented as
an auto-incrementing integer or a globally unique identifier
(GUID).
 Surrogate keys are normally used when there is no suitable
natural key available; ie when there is no column with
properties of a primary key.
 OR when the natural key is subject to change; such as an
email address.
 OR in the table when the primary key is too big or
complicated.
Primary Key + Alternate Key = Candidate Key
Primary Key Foreign Key

Helps you to uniquely identify a It is a field in the table that is the

record in the table. primary key of another table.

Primary Key never accept null A foreign key may accept

values. multiple null values.

You can ONLY have the single You can have multiple foreign
Primary key in a table. keys in a table.
Entity Representation
One common method to represent an entity is to use entity-
relationship diagrams, where each entity is represented by a
box with two compartments, the first for entity name and the
second for attributes.
You may also come across diagrams that employ ellipses to
represent the attributes belonging to each entity.

The relationships that exist between two entities can be

categorised according to the following:
 one-to-one
 one-to-many
 many-to-many
In some cases, for simplicity, the attributes are omitted in the
entity diagram.
One-to-one relationships between two entities

In a concert hall, each ticket holder has a seat for a single

performance (the seat number will appear on the ticket).

Only one person can sit in one seat at each performance;

the relationship between a member of the audience and a
seat is therefore one-to-one.

Each seat in the concert hall can be sold to one person

only for a particular performance; the relationship between
the seat and the member of the audience with a ticket for
that seat is also one-to-one.
Relationships between entities can be shown in a variety
of diagrammatic formats.

The common format is to represent each relationship as a

line.

The style of the line shows the type of relationship being

represented.

Here, in order to represent a one-to-one relationship, a

single straight line is used between the two entities.
The overall relationship between ticket holders and seats is
one-to-one for each performance.

The entity-relationship diagram above shows the one-to-one link

between a ticket holder and a concert hall seat.

In an orchestra (pronounced as okistra), each individual will play

one type of musical instrument; for example, a person who
plays a violin will not play a trumpet.

The relationship is one-to-one from a member of the orchestra

to a type of instrument.
One-to-many relationships between two entities

An orchestra will have more than one musician playing a

particular type of instrument; for example, it is likely that there
will be several members of the orchestra each playing a violin.

The relationship is therefore one-to-many from a type of musical

instrument to a member of the orchestra.
The entity-relationship diagram shows that there is a one-to-
many relationship between musical instrument types and
members of the orchestra.

The 'crows foot' link shows that there may be more than one
member of the orchestra for each type of musical instrument.

Many-to-many relationships between two entities

An individual may attend a series of concerts during each

season as a member of the audience; the relationship between
an individual and the concerts is one-to-many.
Many ticket holders will attend each concert; the relationship
between a concert and members of the audience is also one-to-
many.

As the relationship is one-to-many on both sides of the

relationship, the relationship that exists between the two entities
can be described as many-to-many.
The entity-relationship diagram above has a 'crows foot'
connection at each end, illustrating that there is a many-to-
many relationship between ticket holders and concert
performances, as one ticket holder may attend many
performances, and each performance is likely to have many
ticket holders present.

As it is difficult to implement a many-to-many relationship in a

database system, we may need to decompose a many-to-many
relationship into two (or more) one-to-many relationships.

Here, we might say that there is a one-to-many relationship

between a ticket holder and a ticket (each ticket holder may
have several tickets, but each ticket will be held by only one
person).
We could also identify a one-to-many relationship between a
concert performance and a ticket (each ticket for a particular
seat will be for only one performance, but there will be many
performances each with a ticket for that seat).

This allows us to represent the many-to-many relationship

between ticket holder and concert performance.

Two one-to-many relationships involving a new entity called

Ticket For Seat.

This new structure can then be implemented within a Relational

database system.
Recursive Relationships

The relationships we have seen so far have all been between

two entities; this does not have to be the case all the time.

It is possible for an entity to have a relationship with itself; for

example, an entity Staff could have a relationship with itself, as
one member of staff could supervise other staff.

This is known as a recursive or involute relationship, and would

be represented in an entity-relationship diagram as shown
below.
Recursive relationships
StaffID Surname FirstName SupervisorID

22 Phiri Tasila

55 Mulenga Mary 22

76 Moonga Mutinta 22

How can a table with a Recursive Relationship be created?

Recursive Relationships

Staff (StaffID, Surname, FirstName, SupervisorID)

Primary Key StaffID
Foreign Key SupervisorID references Staff(StaffID)

CREATE TABLE Staff (

StaffID INT,
Surname VARCHAR(20),
FirstName VARCHAR(20),
SupervisorID INT,
PRIMARY KEY (StaffID),
FOREIGN KEY (SupervisorID) REFERENCES Staff(StaffID)
);
 Mandatory

and

Optional Relationships
We can extend the entity-relationship model by declaring that
some relationships are mandatory, whereas others are optional.

In a mandatory relationship, every instance of one entity must

participate in a relationship with another entity.

In an optional relationship, any instance of one entity might

participate in a relationship with another entity, but this is not
compulsory.

Participation condition / membership class

The participation condition defines whether it is mandatory or
optional for an entity to participate in a relationship.

This is also known as the membership class of a relationship.

As there are two kinds of participation conditions (mandatory
and optional),

and

that most entities are involved in binary relationships,

It leads us to four main types of membership relationships, as

follows:

1. Mandatory for both entities

2. Mandatory for one entity, optional for the other
3. Optional for one entity, mandatory for the other
4. Optional for both entities
It might be tempting to think that options 2 and 3 are the same,
but it is important to recognise the difference, particularly when
thinking about whether the relationship is one-to-one, one-to-
many or many-to-many.

A useful analogy is to think of a bank, with customers who have

savings accounts and loans.

It may be the bank's policy that any customer must have a

savings account before they are eligible to receive a loan, but
not all customers who have savings accounts will require a loan.

We can examine how these different types of membership

classes can be used to reflect the policies of allocating staff
within departments.
We would expect any member of staff in an organisation to work
in a given department, but what happens if a new department is
created, or a new member of staff joins?

If we look at each combination in turn, we can see four (4)

possibilities as indicated below:

Mandatory for both entities: A member of staff must be

assigned to a given department, and any department must have
staff. There can be no unassigned staff, and it is not possible to
have an 'empty' department.

Mandatory for one entity, optional for the other: Any

member of staff must be attached to a department, but it is
possible for a department to have no staff allocated.
Optional for one entity, mandatory for the other: A member
of staff does not have to be placed in a department, but all
departments must have at least one member of staff.

Optional for both entities: A member of staff might be

assigned to work in a department, but this is not compulsory. A
department might, or might not, have staff allocated to work
within it.

We can elaborate the standard entity-relationship notation with

a solid circle to indicate a mandatory entity, and a hollow circle
for an optional entity (think of the hollow circle like 'o' for
optional).

(You may find alternative notations in other texts - for example,

a solid line to represent a mandatory entity, and a dotted line to
indicate an optional entity.
The use of a graphical technique enables us to represent the
membership class or participation condition of an entity and a
relationship in an entity-relationship diagram.

We will now explore these possibilities using a performer,

agents and bookings scenario as an example, but
experimenting with different rules to see what effect they have
on the design of the database. Supposing to start with, we have
the following situation.

There are a number of performers who are booked by agents to

appear at different venues.

Performers are paid a fee for each booking, and agents earn
commission on the fee paid to each performer.

We will now consider relationships of different kinds between

these entities.
One-to-one relationships

and

participation conditions
1. Both ends mandatory
It might be the case that each performer has only one agent,
and that all bookings for any one performer must be made by
one agent, and that agent may only make bookings for that one
performer.

The relationship is one-to-one, and both entities must

participate in the relationship.

The solid circle at each end of the relationship shows that the
relationship is mandatory in both directions; each performer
must have an agent, and each agent must deal with one
performer.
2. One end mandatory, other end optional:
It might be possible for agents to make bookings that do not
involve performers; for example, a venue might be booked for
an art exhibition. Each performer, however, must have an agent,
although an agent does not have to make a booking on behalf
of a performer.

The solid circle at the performer end of the relationship

illustrates that a performer must be associated with an agent.
The hollow circle at the agent end of the relationship shows that
an agent could be associated with a performer, but that this is
not compulsory. Each performer must have an agent, but not all
agents represent performers.
3. One end optional, other end mandatory:
It might be possible for performers to make bookings themselves,
without using an agent. In this case, one performer might have an
agent, and that agent will make bookings for that performer. On the
other hand, a different performer might elect to make their own
bookings, and will not be represented by an agent. All agents must
represent a performer, but not all performers will be represented by
agents. The relationship is optional for the performer, but mandatory
for the agent, as shown in the diagram below.

The solid circle at the agent end of the relationship shows each agent
must be associated with a performer. The hollow circle at the
performer end of the relationship indicates that a performer could be
represented by an agent, but that this is not compulsory. Each agent
must deal with only one performer, but each performer does not have
to have an agent.
4. Both ends optional:
Another possibility is that agents may make bookings that do
not involve performers; for example, a venue might be booked
for an art exhibition.

In addition, performers may make bookings themselves, or

might have bookings made by an agent, but if a performer has
an agent, there must be a one-to-one relationship between
them. This relationship is optional for both entities.

The hollow circles show that there is an optional relationship

between a performer and an agent; if there is a relationship, it
will be one-to-one, but it is not compulsory either for the
performer or for the agent.
One-to-many relationships

and

participation conditions
It might be the case that a performer has only one agent, and
that all bookings for any one performer must be made by one
agent, although any agent may make bookings for more than
one performer.

1. Both ends mandatory:

A performer must have one or more bookings; each booking
must involve one performer.

The membership class is mandatory for both entities, as shown

by the solid circle.

In this case, it is not possible for a booking to be made for an

event that does not involve a performer (for example, a booking
could not be for an exhibition).
2. One end mandatory, other end optional:

A performer must have one or more bookings, but a booking

might not involve a performer (e.g. a booking might be for an
exhibition, not a performer).

The solid circle shows the compulsory nature of the relationship

for a performer; all performers must have bookings.

The hollow circle shows that it is optional for a booking to

involve a performer.

This means that a performer must have a booking, but that a

booking need not have a performer.
3. One end optional, other end mandatory:

A performer might have one or more bookings; each booking

must involve one performer.

The membership class is mandatory for a booking, but

optional for a performer.

This means that it would not be possible for a booking to be

for an exhibition, as all bookings must involve a performer.

On the other hand, it is not compulsory for a performer to

have a booking.
4. Both ends optional:

A performer might have one or more bookings; a booking might

be associated with a performer.

In this case, a booking could be for an exhibition as it is optional

for a booking to involve a performer, as indicated by the hollow
circle.

A performer might decline to accept any bookings; this is

acceptable, as it is optional for a performer to have a booking
(shown by the hollow circle).
Many-to-many relationships

and

participation conditions
We could say that there is a many-to-many relationship
between performers and agents, with each agent making
bookings for many performers, and each performer having
bookings made by many agents.

We know that we need to decompose many-to-many

relationships into (usually) two one-to-many relationships, but
we can still consider what these many-to-many relationships
would look like before this decomposition has taken place.

We will see later that many-to-many relationships can be

converted into relations either after they have been
decomposed, or directly from the many-to-many relationship.

The result of the conversion into relations will be the same in

either case.
1. Both ends mandatory:

An example here might be where each performer must be

represented by one or more agents, and each agent is required
to make bookings for a number of performers.

There is a many-to-many relationship between the two entities,

in which both entities must participate.

Agents are not allowed to make bookings for events that do not
involve performers (such as conferences or exhibitions).

Performers must have bookings made by agents, and are not

allowed to make their own bookings.
2. One end mandatory, other end optional:

In this example, it is still necessary for performers to be

represented by a number of agents, but the agents now have
more flexibility as they do not have to make bookings for
performers.

There is a many-to-many relationship between the two entities;

one must participate, but it is optional for the other entity.
3. One end optional, other end mandatory:

Here, performers have the flexibility to make their own

bookings, or to have bookings made by one or more agents.

Agents are required to make bookings for performers, and may

not make arrangements for any other kind of event.

There is a many-to-many relationship between the two entities;

it is optional for one to participate, but participation is mandatory
for the other entity.
4. Both ends optional
Here, performers and agents are both allowed a degree of
flexibility.

Performers may make their own bookings, or may have agents

make bookings for them.

Agents are permitted to make bookings for a number of

performers, and also have the ability to make other kinds of
bookings where performers are not required.

There is a many-to-many relationship between the two entities;

participation is optional for both entities.
These many-to-many relationships are likely to be decomposed
into one-to-many relationships.

The mandatory/optional nature of the relationship must be

preserved when this happens.
 Weak

and

Strong Entities
A weak entity set is one whose existence is dependent on the
existence of a strong entity set; also called the identifying entity
set.

We may also say that an entity set that does not have a primary
key of its own is referred to as a weak entity set.

The relationship must be many-to-one from weak to identifying

entity.

Participation of the weak entity set in the relationship must be

mandatory.

The primary key of a weak entity is the primary key of the

identifying entity set + the partial key of the weak entity set.
Example: Many payments are made on a loan
 Payments do not exist without a loan.
 Multiple loans will each have a first, second payment and
so on. So, each payment is only unique in the context of
the loan which it is paying off.

The weak entity is commonly represented by two boxes.

The payment is a weak entity; its existence is dependent on the

loan entity.
 Common Problems

with

entity-relationship (ER) models

In this section we examine two common problems that may
arise when creating an ER model.

These problems are referred to as connection traps, and

normally occur due to a misinterpretation of the meaning of
certain relationships.

We examine two main types of connection traps, called fan

traps and chasm traps,

and

illustrate how to identify and resolve such problems in ER

models.
Fan traps

These occur when a model represents a relationship between

entity types, but the pathway between certain entity
occurrences is ambiguous. Look at the model below.

The above model looks okay at first glance, but it has a pitfall.

The model says a faculty has many departments and many

staff.

Although the model seems to capture all the necessary

information, it is difficult to know which department staff are
affiliated to.
To find out the departments the staff belong to, we will start from
the staff entity.

Through the relationship between staff and faculty, we are able

to easily identify the faculties staff belong to.

From the faculty, it is difficult to know the exact department

because one faculty is associated with many departments.

 Replace Faculty by Campus

 Examine the model below
Examine and discuss the Models below

Replace Faculty by Campus

Replace Dept by School
 FAN TRAPS – THE PROBLEM

0...* 1 1 1...*
Staff Campus Department
 FAN TRAPS
Campus
ID
Campus Name

C1
- London
1 Campus
C2 Lagos

C3 Cairo

In which Department does Eric work?

Staff Name Campus ID Department Name Campus ID
ID (FK) ID (FK)
S1 Eric C2
D1 Humanities C1
Hudso
n D2 Computing C2
S2 Sandra C1
Smith D3 Maths C2
S3 Malia C1
Shah
Staff Department
 FAN TRAPS – THE SOLUTION

1...* 1 1...* 1
Staff Department Campus
 Campus Campus Name
ID
C1FAN London
TRAPS
Campus
C2 -2
Lagos

C3 Cairo

We now know in which department Eric works

Staff Name Department ID
ID (FK)
Department Name Campus ID
S1 Eric D3 ID (FK)
Hudson D1 Humaniti C1
S2 Sandra D1 es
Smith D2 Computin C2
S3 Malia D1 g
Shah D3 Maths C2
Department
Staff
Chasm traps

These occur when a model suggests the existence of a

relationship between entity types, but the pathway does not
exist between certain entity occurrences.

The model represents the facts that a faculty has many

departments and each department may have zero or many staff.

We can clearly note that, not all departments have staff and not
all staff belong to a department.

Examples of such staff in a university can include the secretary

of the dean. He/she does not belong to any department.
It's difficult to answer the question, “which faculty does the dean’s
secretary belong to?”, as the secretary to the dean does not belong to
any department.

We remove the chasm trap by adding an extra relationship from staff

to faculty.
 CHASM TRAP – THE PROBLEM

1 1...* 0...1 0...*

Branch Staff Property

• A branch has many staff members who manage

properties, but not all properties are managed by a
member of staff, and not all staff manage
properties.
 CHASM TRAP - 1
Branch Branch
ID Name
Branch Which Branch manages
1 Ilford
‘Hill House’?
2 Redbridge

Staff Name Branch

ID ID (FK) Property
S1 Davinda 1
Property Propert Staff ID
Staff S2 Roberta 1 ID y Name (FK)
S3 Eddie 2 P1 Yap S1
Mansions
P2 Hill
House
P2 Usher S2
House
 CHASM TRAP – THE SOLUTION

1 1...* Staff 0...1 0...*

Property
Branch
1 0...*
 CHASM TRAP - 2
Branch Branch We now know which
ID Name
Branch Branch manages ‘Hill
1 Ilford

2 Redbridge
House’

Staff ID Name Branch

ID (FK)
Property
S1 Davinda 1 Prope Propert Staff Branc
Staff rty ID y Name ID (FK) h ID
S2 Roberta 1 (FK)
S3 Eddie 2 P1 Yap S1 1
Mansion
s
P2 Hill 2
House
P2 Usher S2 2
House
QUESTIONS