Database Design - Section 5 Instructor Guide

Database Design - Section 5
Instructor Guide
Table of Contents
Database Design - Section 5 ............................................................................................................................1

Lesson 1 - Relationship Transferability .........................................................................................................1
What Will I Learn? ........................................................................................................................................2
Why Learn It? ................................................................................................................................................3
Tell Me / Show Me ........................................................................................................................................4
Try It / Solve It ..............................................................................................................................................7
Lesson 2 - Relationship Types .......................................................................................................................14
What Will I Learn? ........................................................................................................................................15
Why Learn It? ................................................................................................................................................16
Tell Me / Show Me ........................................................................................................................................17
Try It / Solve It ..............................................................................................................................................23
Lesson 3 - Resolving Many-to-Many Relationships ......................................................................................28
What Will I Learn? ........................................................................................................................................29
Why Learn It? ................................................................................................................................................30
Tell Me / Show Me ........................................................................................................................................31
Try It / Solve It ..............................................................................................................................................38
Lesson 4 - Normalization and First Normal Form .........................................................................................42
What Will I Learn? ........................................................................................................................................43
Why Learn It? ................................................................................................................................................44
Tell Me / Show Me ........................................................................................................................................45
Try It / Solve It ..............................................................................................................................................48
Lesson 5 - Review and Quiz 3 .......................................................................................................................51
What Will I Learn? ........................................................................................................................................52
Why Learn It? ................................................................................................................................................53
Tell Me / Show Me ........................................................................................................................................54
Try It / Solve It ..............................................................................................................................................55
Copyright © Oracle, 2004. All rights reserved.

Page i
Lesson 1 - Relationship Transferability
Lesson 1 - Relationship Transferability
Lesson Preparation
None.
What to Watch For
None.
Connections
None.

Page 1
What Will I Learn?
What Will I Learn?

Page 2
Why Learn It?
Why Learn It?

Page 3
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Reiterate that the relationship name must work from both perspectives.
Optionality
Can you have a TYPE that does not classify any SONG? (Yes)
Must every SONG have a TYPE? (Yes)
Cardinality
How many SONGs can be lumped into a TYPE? (One or more)
How many TYPEs can a SONG have? (Just one)
Note: Students may argue that a SONG can be classified by many TYPEs. Agree, but tell them
that the assumption for the DJ model is that although many TYPEs can apply to a SONG, they
want to track the main TYPE.
Transferability
Can a SONG be changed from one TYPE to another TYPE?
(Most likely the answer is yes, unless they have rigid rules about TYPE. Explain that this
demonstrates a transferable relationship.)

Page 4
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Nontransferable relationships are important to note because they usually reflect a business rule
and will have implications when the ERD is implemented as a database -- the foreign key
column cannot be updated.
Assess the understanding of your students as you decide whether or not to discuss this with
them.

Page 5
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Begin a discussion in which you ask students to give other examples where they see a
nontransferable relationship. Other examples of nontransferability that you can suggest:
Should you be allowed to board a plane with a TICKET belonging to some other
PASSENGER?
Would you want anyone to be able to transfer the AUTHORship of your EMAIL?
How would you react if your CREDIT CARD ACCOUNT PRIVILEGES were transferred to
another CUSTOMER?
Do you expect your PLACE IN a concert ticket WAITING LIST to be given away to another
PERSON?
If your friend checks out books from the library and returns them late, would you expect that
the fine be charged to you?
Have students name the relationship between two entities where you would want a
nontransferable relationship e.g. between PATIENT and PRESCRIPTION, between …

Page 6
Try It / Solve It
Try It / Solve It
Try It / Solve It
Some of the M:1 relationships could easily be M:M when modeled over time (such as ROOM
and GUEST, HOTEL and GUEST, EMPLOYEE and DEPARTMENT).
If someone points that out, tell them that we are looking at a single point in time right now, but
we will tackle the time element very soon.

Page 7

Page 8

Page 9
Try It / Solve It
Try It / Solve It
Try It / Solve It
Some of the M:1 relationships could easily be M:M when modeled over time (such as ROOM
and GUEST, HOTEL and GUEST, EMPLOYEE and DEPARTMENT).
If someone points that out, tell them that we are looking at a single point in time right now, but
we will tackle the time element very soon.

Page 10
Try It / Solve It
Try It / Solve It
Try It / Solve It
This is meant to bring the students up to date on what has been modeled for Global Fast Foods
ERD so far.
It will also help students who did not arrive at an accurate solution for the previous activity on
Global Fast Foods.

Page 11
Try It / Solve It
Try It / Solve It
Try It / Solve It

Page 12

Page 13
Lesson 2 - Relationship Types
Lesson 2 - Relationship Types
Lesson Preparation
None.
What to Watch For
None.
Connections
Explore the DJ model and point out the relationships between MUSIC and TYPE, EVENT and
THEME, MUSIC and EVENT (this one is M:M), PARTNER and EVENT (this one is M:M).

Page 14
What Will I Learn?
What Will I Learn?
What Will I Learn?

As in any successful business, the goal is to produce the best product possible.
In this lesson, your goal as a data-model designer is to produce the best design possible.
An understanding of the different types of relationships is essential.

Page 15
Why Learn It?
Why Learn It?
Why Learn It?

Emphasize that getting the relationships right, asking the right questions to get them right, is
crucial to modeling the business properly. Mistakes that are made now are much easier to
correct at this stage than when the system is being built. (You might say to students, this is why
they pay you the big bucks -- to think of things that the client takes for granted or forgets!)

Page 16
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
The example given (mandatory on the many side, optional on the one side) is the most
common. However, you may want to discuss other variations briefly, or just have them for
your own background knowledge:
Mandatory at both ends:
This type of relationship typically models entities that cannot exist without each other. This
usually represents an ideal situation (we cannot have ORDER ITEMs without ORDERs!). This
is hard to implement in the physical database because it causes the “chicken and egg” problem
(explain in detail).

Page 17
Mandatory on the one side, optional on the many side:
This is rarely used. You will see it only when the relationship expresses that an entity instance
exists only when it is a nonempty set, and where the elements of the set can exist
independently. In the example below, a MUSICIAN may be part of one BAND. According to
the model, a BAND is of no interest if it is empty. How can you have a BAND without
MUSICIANs?

Page 18
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Remind students that we have seen examples of these already. In the next lesson, we will learn
to resolve them.

Page 19
Tell Me / Show Me
Tell Me / Show Me

Page 20
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Mandatory 1:1
A 1:1 relationship, mandatory at both ends, tightly connects two entities: when you create an
instance of one entity, there must be exactly one dedicated instance for the other
simultaneously; for example, entity PERSON and entity BIRTH.
Each PERSON must be the result of one and only one BIRTH.
Each BIRTH must result in one and only one PERSON.
This leads to the question why you want to make a distinction between the two entities
anyway. The only acceptable answer is: only if there is a business need, such as keeping birth
records separate from person records. Note that someone may point out that the above
relationship does not apply to twins, triplets, etc. Point out that those are considered multiple
births (one birth per baby!).

Page 21
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
On the left side, if a person lives in town A, which is in country B, then we can conclude that
the person lives in country B.
However, on the right side, the relationship is nonderivable : “born in/the birthplace of.” Just
because a person lives in town A, which is in country B, does not automatically mean that the
person was born in country B.

Page 22
Try It / Solve It
Try It / Solve It
Try It / Solve It
You can use existing clubs in your school as an example. If they don’t belong to a department,
ask the students which academic department they “could” belong to, if that was a business rule.
See if majority of the class has modeled the M:M relationship correctly. You may want to call
attention to it, and say that they will learn more about it in the next lesson.

Page 23
Assessment:

Page 24
Try It / Solve It
Try It / Solve It
Try It / Solve It
This is meant to bring the students up to date on what has been modeled for the Global Fast
Foods ERD so far. It will also help students who did not arrive at an accurate solution for the
previous activity on Global Fast Foods.

Page 25
Try It / Solve It
Try It / Solve It
Try It / Solve It
Assessment:
Point out how the scenario clarifies the M:M relationship between FOOD ITEM and ORDER.
We also add a new entity called FREQUENT DINER CARD. There is no need to model
CUSTOMER because we record customer information on the card. Someone may also ask,
“What if one customer places an order for a group of people, but each person in the group has a
frequent-diner card?” In this case, the discount applies to the total order, and the order gets
tracked under the one frequent-diner card.
Some students may not model a MENU entity, and some may decide that it is necessary. Both
are valid. It is not clear right now that there is more than one menu. When we discuss arcs, they
will get additional information that there are two menus.

Page 26

Page 27
Lesson 3 - Resolving Many-to-Many Relationships
Lesson 3 - Resolving Many-to-Many Relationships
Lesson Preparation
None.
What to Watch For
None.
Connections
Recall the DJ model and draw the entities EVENT and SONG. Point out the M:M relationship;
read the ERDish if it clarifies things. Resolve the M:M. Have the students name this
intersection entity (PLAY LIST ITEM?)
Verify this in the DJ model ERD.

Page 28
What Will I Learn?
What Will I Learn?

Page 29
Why Learn It?
Why Learn It?
Why Learn It?

Draw a M:M relationship between STUDENT and CLASS. Point out that each student may
attend one or more classes and each class may be attended by one or more students. Where do
we store the grade that a student gets in a class?
If we put a grade attribute in STUDENT, how do we know which class it’s for? If we put it in
CLASS, how do we know which student got the grade?

Page 30
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
A question of duets may come up, where there is more than one ARTIST performing a SONG.
You can say that the DJ business partners have decided to just track one ARTIST (probably the
bigger name). If both performers are equally popular, then it becomes tricky.
For now, you can congratulate them for finding a valid limitation in the model -- ask how they
would revise it, given what they’ve learned so far.
Possible answers: have a separate entity for ARTIST with a M:M relationship to SONG.

Page 31
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
If we put the status attribute in EVENT, how do we know which PARTNER worked on the
event? If the status is “called client to confirm meeting,” who is meeting with the CLIENT --
the event manager, the DJ?
If we put the status attribute in PARTNER, how do we know which EVENT the status is
referring to?

Page 32
Tell Me / Show Me
Tell Me / Show Me

Page 33
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
When explaining the UID of an intersection entity, it may help to show data examples. For
EVENT and PARTNER, it may help to write out the data of JOB ASSIGNMENT, and point
out that the combination of EVENT identifier and EMPLOYEE identifier uniquely identifies a
job.
If the modeler decides that it is the combination of UIDs of the originating relationships that
will serve as the primary UID of the intersection entity, then the relationships are drawn with
the bars to represent this. However, it is important to realize that in some cases, the modeler
may decide to create an “artificial UID” for the intersection entity. In this case, the
relationships are not barred. The artificial UID may be the best option if the UIDs of the
originating entities are composite (made up of two or more attributes). Creating an artificial
UID may just be a simpler choice.

Page 34
Tell Me / Show Me
Tell Me / Show Me

Page 35
Tell Me / Show Me
Tell Me / Show Me

Page 36
Tell Me / Show Me
Tell Me / Show Me

Page 37
Try It / Solve It
Try It / Solve It
Try It / Solve It
Some intersection entities will look “empty,” and this can confuse the students. Point out that
this doesn’t mean that there are no attributes. There is at least a UID for this entity, and it is a
combination of the UIDs of the originating entities. In the ERD, we don’t put the same
attribute in two different places, so we represent this with the bar.

Page 38

Page 39
Try It / Solve It
Try It / Solve It
Try It / Solve It
This is meant to bring the students up to date on what has been modeled for the Global Fast
Foods ERD so far.
It will also help students who did not arrive at an accurate solution for the previous activity on
Global Fast Foods.

Page 40
Try It / Solve It
Try It / Solve It
Try It / Solve It
Assessment:

Page 41
Lesson 4 - Normalization and First Normal Form
Lesson 4 - Normalization and First Normal Form
Lesson Preparation
Normalization can be a difficult concept to learn. At the very basic level, it just seems like
common sense -- make sure you don’t store the same data twice in the model, and that you
store data in the correct place. However, the rules of normalization are formal statements that
can involve complex language.
This course discusses the first three rules of normalization. You should be aware that there are
more. Normalization can go from First Normal Form (1NF) all the way to Fifth Normal Form
(5NF) and beyond (6NF and 7NF are mostly academic exercises). For most business models,
3NF is enough.
What to Watch For
None.
Connections
Go through the entities in the DJ model ERD and make sure it follows the 1NF rule.

Page 42
What Will I Learn?
What Will I Learn?
What Will I Learn?

Normalization is a very formal term that can be intimidating to some students. Explain that
although normalization is derived from complex mathematical rules, the data modeler’s goal is
to eliminate redundancy.
Note: In this lesson we are looking at 1NF. 2NF and 3NF will be discussed in later lessons.
This helps the students to think of normalization as just another part of the data-modeling
process, as opposed to a subject of its own.

Page 43
Why Learn It?
Why Learn It?

Page 44
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
Another way to look at the rule of First Normal Form is: “One value per attribute.”

Page 45
Tell Me / Show Me
Tell Me / Show Me
Tell Me / Show Me
(1) This is an unnormalized version of the client attribute in the DJ model. There are many
events that can be associated with a client. The event attribute is misplaced because it is
multivalued.
(2) A SHOPPING MALL has more than one store. Store is an attribute with multiple values
and should not be in the SHOPPING MALL entity.
(3) A TEAM has several players, so the player attribute has multiple values.

Page 46
Tell Me / Show Me
Tell Me / Show Me

Page 47
Try It / Solve It
Try It / Solve It
Try It / Solve It
Give them some guidance on how to start checking for First Normal Form: go through each
entity and examine its attributes. For each attribute, ask the question: Is there one value for this
attribute, or can it have multiple values? If there are multiple values, you have found a 1NF
violation. Determine how to correct it.
Student is already in First Normal Form.

Page 48

Page 49
Try It / Solve It
Try It / Solve It
Try It / Solve It
Ask your students what it means if you find an attribute that can have multiple values for one
instance of the entity? Give an example, such as BUILDING with an attribute called
classroom.
If an attribute can have multiple values for one instance of the entity, then it means an entity is
missing.

Page 50
Lesson 5 - Review and Quiz 3
Lesson 5 - Review and Quiz 3
Lesson Preparation
Review lesson content for fifteen minutes before you administer the quiz. This is a good time
to answer questions, clarify recently learned concepts and terminology, and go over some of
the practice solutions from previous lessons.
What to Watch For
None.
Connections
No connections for this lesson.

Page 51
What Will I Learn?
What Will I Learn?

Page 52
Why Learn It?
Why Learn It?

Page 53
Tell Me / Show Me
Tell Me / Show Me

Page 54
Try It / Solve It
Try It / Solve It
Try It / Solve It
Allow 20 minutes for the quiz and 10 minutes for assessment/discussion afterward.
Assessment:
You may want to encourage students to retake the quiz until they achieve a passing score. Or
you may prefer to allow only one attempt at the quiz.
Have students work in small groups to review what they missed on the quiz. Based on what
types of questions they missed, have students write out the rules (e.g., rules for subtypes). Have
a member from each group present a summary back to the class about what areas their group
can improve.

Page 55

Page 56

Database Design - Section 5 Instructor Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Database Design - Section 5 Instructor Guide

Загружено:

Авторское право:

Доступные форматы

Database Design - Section 5

Database Design - Section 5 ............................................................................................................................1

Copyright © Oracle, 2004. All rights reserved.