Assignment Week5 Database Exercise
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.