database design - section 5 - oracle...

Database Design - Section 5 Instructor Guide

Copyright © Oracle, 2004. All rights reserved.

Database Design - Section 5 Page i

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


Database Design - Section 5 Page 1

Lesson 1 - Relationship Transferability

Lesson 1 - Relationship Transferability

Lesson Preparation

None. What to Watch For

None. Connections

None.



What Will I Learn?

What Will I Learn?



Why Learn It?

Why Learn It?



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.)



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.



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 …



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.



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.



Try It / Solve It

Try It / Solve It

Try It / Solve It



Lesson 2 - Relationship Types

Lesson 2 - Relationship Types

Lesson Preparation


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).



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.



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!)



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).



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?



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.



Tell Me / Show Me

Tell Me / Show Me



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!).



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.



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.



Assessment:



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.



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.



Lesson 3 - Resolving Many-to-Many Relationships

Lesson 3 - Resolving Many-to-Many Relationships

Lesson Preparation


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.



What Will I Learn?

What Will I Learn?



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?



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.



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?



Tell Me / Show Me

Tell Me / Show Me



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.



Tell Me / Show Me

Tell Me / Show Me



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.



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.



Try It / Solve It

Try It / Solve It

Try It / Solve It

Assessment:



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.



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.



Why Learn It?

Why Learn It?



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.”



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.



Tell Me / Show Me

Tell Me / Show Me



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.



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.



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.



What Will I Learn?

What Will I Learn?



Why Learn It?

Why Learn It?



Tell Me / Show Me

Tell Me / Show Me



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.

database design - section 5 - oracle...

Documents