Fact Finding Techniques and Multiplicity Constraint

Directions (Complete Part A and Part B below)
Part A
1. Complete Question 11.4 AND explain how you would apply 3 of those techniques if you were
asked to collect information regarding how to improve the learning management system we
use in this class.
2. Your submission should include:
1. Description of each fact-finding technique
2. Identify the advantages and disadvantages of each
3. Explain how you would apply 3 of the techniques to improve the LMS used by APUS

Question 11.4:
A database developer normally uses several fact-finding techniques during a single database project.
The five most commonly used techniques are examining documentation, interviewing, observing the
business in operation, conducting research, and using questionnaires. Describe each fact-finding
technique and identify the advantages and disadvantages of each
Part B
1. Complete Question 12.4
2. Describe the relationship that exists between the PrivateOwner entity (table) and the
PropertyForRent entity (table) in the DreamHome database used in our textbook. (Tables are
below)
3. HINT – review the Chapter 12 Study Aid (attached) and the Table Relationships – Multiplicity
topic (please see it pasted below database tables if needed for reference, but not necessary)
Question 12.4:
Describe what the multiplicity constraint represents for a relationship type.

DreamHome Database

Characterizing Table (Entity) Relationships – One-to-Many, Many-to-Many:
Relationship characterization – an association between entities (tables); this association is created
by linking a field in the first table to a field in the second table (be careful – in the case of many-to-
many relationships this link is established through a third table). For one-to-many relationships, the
field in the first table is normally the primary key in the first table, and the field in the second table is
called a foreign key.
We assess the relationship between 2 tables by reviewing whether a single row in the first table can
be associated with zero, one, or many rows in the second table – and – vice versa. This association
may depend on the direction and is often (usually) not the same in both directions.
This association in each direction is referred to as a multiplicity – we need to review this in both
directions before characterizing the “table” relationship.
We will focus on one-to-many and many-to-many table relationships.
One-to-Many Relationship – a relationship between two entities (tables) in which each occurrence
(row) of the first entity is related to many occurrences (rows) of the second; and each occurrence
(row) of the second entity is related to at most 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) of each entity (table) can be related to 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.
Examples:
A) Part – Supplier: IF we decided that each part could be provided by ONE supplier, then we would
have a one-to-many relationship. Each part could be provided by ONE supplier. On the other hand,
each supplier could provide many different parts. Notice that we consider the association between
rows in the tables in each direction.
Part – Supplier: IF we decided that each part could be supplied by many suppliers, then we would
have a many-to-many relationship. Each part could be provided by many suppliers, and each supplier
could provide many different parts.
B) Books and Authors – can a book be written by more than one author – yes. Can an author write
more than one book – yes. This is a many-to-many relationship.
C) Customer and Sales Rep
(assume each customer can have one sales representative and each sales representative can have
only one customer). The would be a one-to-one relationship.

(assume each customer will be assigned only one sales representative). Each customer can have one
sales representative, but each sales representative can have many customers. This is a one-to-many
relationship.
(assume we have a multinational company – we now allow each customer to have more than one
sales representative and each sales representative may be assigned to more than one customer). This
would be a many-to-many relationship.
As we learn more about database design – we will see that a one-to-many relationship will require
two tables. We include a foreign key field in the second table that links to the primary key (or
candidate key) in the first table. A many-to-many relationship will require three tables – the third
table will be used to link the records in the other two tables. There may also be fields that must be
stored in the third table – because those fields on dependent on the composite key in the third table.
For example, if we have multiple suppliers of the same part – and each supplier could charge us a
different cost – where would we store that cost?