Please see attachment 

Chapter12 STUDY AID

Page 1 of 3

Chapter 12 up through Section 12.6.3 can be a bit academic; the below summary can be used to help

clarify some of the terms and key points that will be needed in assignments. The chapter is focused on

Entity-Relationship models – in general it tends to add a layer of abstraction to represent more generic

or complex situations then will be assigned in this course.

The chapter uses the term entity type – we can think of that as an entity – which in turn will be a table in

our databases.

The chapter uses the term entity occurrence to be “a uniquely identifiable object of an entity type” – we

can think of that as a row (or record) in a table.

The chapter uses the term relationship type to be a “set of meaningful associations among entity types”

– think of this as describing how the data in one table can be associated with the data in a second table,

starting with a verb – for instance, the textbook refers to a relationship type called “POwns” which

explains that each Business Owner can own 0, 1, or many properties, while each property can be owned

by 0 or 1 Business Owner. Notice that the textbook uses a verb to describe the association and then

proceeds to give examples of how that verb can be applied to the rows in each entity (table).

Don’t worry complex relationships – this course focus on relationships between two entities – or

recursive relationships. Again, it is good to know about composite, and multivalued attributes – but they

will not be used in the assignments. The same can be said for strong and weak entity types.

A critical concept in this chapter is what they refer to as “multiplicity” – the chapter uses the term to be

“the number (or range) of possible occurrences of an entity type that may relate to a single occurrence

of an associated entity type through a particulate relationship”. The textbook than explains that there

can be one-to-one, one-to-many, and many-to-many types of relationships. The text goes on to discuss

how specific rows in one table may be associated with rows in a second table. For instance, one member

of staff may oversee zero properties, one property, or many properties. While is can be interesting and

worthwhile to look at specific rows and see which staff has how many properties, we must design the

database (tables) to provide the maximum flexibility. So, since one member of staff may oversee many

properties we must design for that. We also need to look backwards; that is, we look at the relationship

between 2 entities from each side – for this course we will only be concerned with 2 entities in a

relationship (the textbook refers to this as binary – because there are 2 entities involved). If we look at

the staff and property relationship from the property side, the textbook tells us that each property can

be managed by zero, or one member of staff. We are now ready to take the final step.

But first, let’s provide more readable definitions for one-to-one, one-to-many, and many-to-many.

One-to-One Relationship – a relationship between two entities (tables) in which each occurrence (row)

in the first entity is related one occurrence (row) in the second; and each occurrence (row) of the

second entity is related to one occurrence (row) of the first entity.

One-to-Many Relationship – a relationship between two entities (tables) in which each occurrence

(row) in the first entity is related to zero, one, or many occurrences (rows) in the second; and each

Chapter 12 STUDY AID

Page 2 of 3

occurrence (row) of the second entity is related to at zero or one occurrence (row) of the first entity.

Sometimes this is referred to as a parent/child relationship. Another way of saying this is, one row of the

first table can be related to many rows in the second table; and each row in the second table is related

to at most one row in the first table

Many-to-Many Relationship – a relationship between two entities (tables) in which each occurrence

(row) in each entity (table) can be related to zero, one, or many occurrences (rows) of the other entity

(table). Another way of thinking about this is, each row in the first table can be related to zero, one, or

many rows in the second table, and each row in the second table can be related to zero, one, or many

rows in the first table.

For this course – we will be using one-to-many and many-to-many relationship.

Let’s look at some examples based on the DreamHome database (Connolly, pg. 112):

Chapter 12 STUDY AID

Page 3 of 3

The Branch and Staff entities (tables) have a one-to-many relationship. Each Staff member can be

assigned to zero or one Branch, and each Branch can have zero, one, or many assigned staff members.

The Private Owner and the Property for Rent entities (tables) have a one-to-many relationship. Each

property can be owned by zero, or one owner, and each owner can own zero, one, or many properties.

The Property table has several fields – focus on the ownerNo field for this relationship.

You may notice that in a one-to-many relationship – a value in the primary key field in the first table will

have the same value as that field in the associated rows in the many table.

The Client and Viewing entities (tables) have a many-to-many relationship. One client may view several

properties, and each property can be viewed by several clients. Look at the tables in above figure, the

fields in those tables do not suggest that there is a many-to-many relationship between them! We need

to look at the Viewing table to “see” the many-to-many relationship. The Viewing table has a composite

key – made up of the ClientNo and PropertyNo fields. That is not an accident – that composite key

supports the many-to-many relationship between the Client and Property for Rent entities. If you look at

the above spreadsheet we can see that the Viewing table’s composite key fields can be used to link us

back to each of those tables – and that the client number and property number fields by themselves

have duplicate entries in the Viewing table.

That will always be the case for a many-to-many relationship – we will always need a third table to

support this type of relationship between to other tables (entities).

Bibliography

Connolly, T. M., & Begg, C. E. (2015). Database Systems A Practice Approach to Design, Implementation,

and Management. (6th). Boston: Pearson.