1285401 3 er diagramming supplemental material fall2015

14
Supplemental Material on Entity Relationship (ER) Diagramming In this class, we will use the UML (Unified Modeling Language) diagramming method for all assignment work. The UML diagramming method is the method used in your class textbook. You must apply the material in this supplemental document to the ER diagramming assignments in this class. ER Diagram dissection: The simple diagram above has 3 entities and 3 relationship lines. The entities are named “DistributionCenter”, “Car”, and “Staff”. The relationship lines are labeled “isAssigned”, “Uses”, and “Has”. Each relationship line has an arrowhead pointing toward one of the entities in the relationship and pointing away from the other entity in the relationship, thus, each relationship line shows the existence of a relationship between two entities. Each entity has an attribute that represents a primary key. For example, the primary key of the entity “DistributionCenter” is “dCenterNo”. There are three relationship lines, so there are three diagrammed relationships as follows: (1) Distribution Center isAssigned Car, (2) Staff Uses Car, and (3) DistributionCenter Has Staff. Let’s look at the first relationship in detail. Each UML diagrammed relationship can be de-composed into its relationship parts. In the relationship “DistributionCenter isAssigned Car” the relationship arrow provides the directional ordering between the two entities by pointing away from “DistributionCenter” and by pointing toward “Car”. The entity being pointed away from, is the “Parent” entity of the relationship: DistributionCenter. The entity being pointed toward is the “Child” entity of the relationship: Car. The label “isAssigned”, is the “relationship label” of the relationship. Each relationship label describes the function of the relationship. So, we have a parent, a relationship label, and a child. In addition, note that entity names should be expressed in SINGULAR form, for example, “Car” not “Cars”. Note also that a parent entity is sometimes referred to as the “dominant or strong” entity, and the child entity is sometimes referred to as the “subordinate or weak” entity.

Upload: manoj

Post on 19-Feb-2016

219 views

Category:

Documents


0 download

DESCRIPTION

this is the best

TRANSCRIPT

Page 1: 1285401 3 ER Diagramming Supplemental Material Fall2015

Supplemental Material on Entity Relationship (ER) Diagramming

In this class, we will use the UML (Unified Modeling Language) diagramming method for all assignment

work. The UML diagramming method is the method used in your class textbook.

You must apply the material in this supplemental document to the ER diagramming assignments in

this class.

ER Diagram dissection:

The simple diagram above has 3 entities and 3 relationship lines. The entities are named

“DistributionCenter”, “Car”, and “Staff”. The relationship lines are labeled “isAssigned”, “Uses”, and

“Has”. Each relationship line has an arrowhead pointing toward one of the entities in the relationship

and pointing away from the other entity in the relationship, thus, each relationship line shows the

existence of a relationship between two entities. Each entity has an attribute that represents a primary

key. For example, the primary key of the entity “DistributionCenter” is “dCenterNo”.

There are three relationship lines, so there are three diagrammed relationships as follows: (1)

Distribution Center isAssigned Car, (2) Staff Uses Car, and (3) DistributionCenter Has Staff. Let’s look at

the first relationship in detail. Each UML diagrammed relationship can be de-composed into its

relationship parts. In the relationship “DistributionCenter isAssigned Car” the relationship arrow

provides the directional ordering between the two entities by pointing away from “DistributionCenter”

and by pointing toward “Car”. The entity being pointed away from, is the “Parent” entity of the

relationship: DistributionCenter. The entity being pointed toward is the “Child” entity of the

relationship: Car. The label “isAssigned”, is the “relationship label” of the relationship. Each

relationship label describes the function of the relationship. So, we have a parent, a relationship label,

and a child. In addition, note that entity names should be expressed in SINGULAR form, for example,

“Car” not “Cars”. Note also that a parent entity is sometimes referred to as the “dominant or strong”

entity, and the child entity is sometimes referred to as the “subordinate or weak” entity.

Page 2: 1285401 3 ER Diagramming Supplemental Material Fall2015

What about the multiplicity notation in the diagram? Both the “Parent” entity and the “Child” entity

MUST have multiplicity notation in each relationship. Note in the relationship “DistributionCenter

isAssigned Car” that the multiplicity notation for DistributionCenter is “1..1” and the multiplicity

notation for “Car” is “1..*”.

Note that the notation “1..1” means “one and only one”. Multiplicity between the entities in the

relationship is expressed in the format “x..y” for each entity. The value of “x” represents the minimum

multiplicity and the value of “y” represents the maximum multiplicity. For your ER diagramming in this

class, the “parent” entity (the relationship arrow points away from the parent entity), will typically have

a multiplicity of “1..1”. This multiplicity of “1..1” requires us to look at the relationship from the point of

view of a single occurrence of the parent entity. In our relationship “DistributionCenter isAssigned Car”,

we interpret the relationship from the point of view of a single Distribution Center even though there

may be many distribution centers. We want to show the relationship multiplicity as it pertains to a

single distribution center. The “relationship label” of the relationship should express the relationship

from the point of view of a single occurrence of the “Parent” entity. Thus, the relationship label

“isAssigned” is based on the relationship between one Distribution Center and the many Cars assigned

to one Distribution Center. Again, we know the parent of the relationship because the relationship

arrow always points away from the parent entity and toward the child entity.

The notation “0..1” indicates optionality with an “x” value of zero in the “x..y” format. A parent entity

may be optional, but is typically not optional, so the parent entity will usually not have a notation of

“0..1”. If you have a parent entity expressed with a multiplicity of “0..1”, you need to confirm that the

parent entity in the relationship can be optional. A “Child” entity can be either optional or mandatory.

Again, a “Parent” entity is typically mandatory.

By applying the above discussion regarding parent entities, child entities, relationship labels, and entity

multiplicity, we can describe the relationships in the entire ER diagram as follows:

Each distribution center is assigned one or more cars. Each car is assigned to a single distribution

center.

Each distribution center has one or more staff. Each staff is associated with a single distribution center.

Each staff may or may not use one car. Each car is used by a single staff.

So here are the general ER diagramming guidelines for this class:

1.Each relationship always has two entities. In the data modeling we will perform in this class, you can

never have more than two entities in a diagrammed relationship. When a relationship has two entities,

it is called a relationship of “degree two”. A relationship of “degree two” is also called a “binary”

relationship. It is possible to have a complex relationship with more than two entities, but we will not

be diagramming complex relationships in this class.

Page 3: 1285401 3 ER Diagramming Supplemental Material Fall2015

2.Each entity has a name expressed in singular form (use “Car”, not “Cars”).

3.Each entity must have a primary key (PK). Many times, an entity will have one or more foreign keys

(FK). A foreign key must be a PK or PPK (partial primary key) or AK (alternate key) of a related entity and

there must be a relationship line between the two entities whenever there is a foreign key.

4.Each entity will typically have other various non-key attributes. A non-key attribute in a database

system is an attribute that is not a PK, a PPK, or an FK in any of the entities.

5.Each relationship line will have a relationship label that expresses the relationship function from the

point of view of a single occurrence of the parent entity.

6.Each relationship label will have an arrow pointing away from the parent entity and toward the child

entity.

7.The parent entity will typically have a multiplicity notation of “1..1” (or “0..1” if the parent entity is

optional in the relationship).

8.The parent entity will typically be mandatory in the relationship, not optional.

9.The child entity must have multiplicity notation from the point of view of a single occurrence of the

parent entity.

10.The child entity can be optional.

11.Do not use special characters or embedded spaces in entity names, relationship labels, primary key

names, foreign key names, or entity attribute names. Names should be expressed in singular form. The

first letter of entity names and relationship names should be capitalized. The first letter of attribute

names should not be capitalized.

12.There is no such multiplicity notation as “*..*” or “*..0”

Illustrative Example

Consider a relationship between Student and Class. Typically, students take several classes

each semester and, typically, classes contain several students, so the multiplicity would be many

students to many classes, and many classes to many students, right? The UML data modeling

approach requires that you express a relationship's multiplicity as a single "occurrence".

The direction (or point of view) of the relationship is important in determining a single occurrence. If

the direction of the relationship multiplicity is from Student to Class, then we want the multiplicity

Page 4: 1285401 3 ER Diagramming Supplemental Material Fall2015

notation to represent a single occurrence of Student. If the point of view of the relationship is from

Class to Student, then we want the multiplicity notation to represent a single occurrence of Class. In

representing Student as the point of view of the relationship, we get the following model:

Student --------enrollsIn---------> 1..* Class

In English, this says that each Student enrolls in one or more Classes.

If the point of view of the relationship that we want to represent is from Class to Student, then

we get the following model:

Class ---------contains--------> 1..* Student

In English, this says that each Class has one or more Students.

Putting both of these points of view together in a single relationship diagram, we have the following:

Student 1..* -------enrollsIn------ > 1..* Class

In English, this says that each Student enrolls in one or more Classes, and each Class has one or more

Students.

Page 5: 1285401 3 ER Diagramming Supplemental Material Fall2015
Page 6: 1285401 3 ER Diagramming Supplemental Material Fall2015

Primary Keys (PKs)

The basic guideline – all occurrences of an entity (all rows in a table) must be identifiable by a unique

value. The unique value can be a single attribute in the entity, or a composite of two or more attributes

in the entity. This unique value is called a primary key, abbreviated as “PK” in UML notation.

Do not use attributes that contain proper names as values for PKs. Attributes containing proper names such as “Smith” or “New York City” are a very poor choice for PKs due to duplicates, spelling errors, embedded spaces, and special characters. Attributes with unique numeric values are best for PKs such as employeeNumber, accountNumber, invoiceNumber, licenseTag, etc. Try to avoid using attributes with a serial number assignment as a PK, example 001, 002, 003, 004. Instead of an “artificial” PK, try to find an existing attribute with a natural unique numeric value to serve as a PK. When you cannot find a single attribute to serve as a PK, try combining two or more attributes to form a unique “composite” PK, for example, (doctorNumber, apptDate, apptTime). Consider the following model: EntityA 1..1 -------has------ > 1..1 EntityB This model says that each occurrence of EntityA has a related single occurrence of EntityB, AND this model says that each occurrence of EntityB has a related single occurrence of EntityA. When you have a relationship between entities with this multiplicity, there is a possibility that both entities can use a common attribute in each entity as a PK.

Page 7: 1285401 3 ER Diagramming Supplemental Material Fall2015

Foreign Keys (FKs)

The general guideline – for each relationship line that touches an entity, the entity should have an attribute(s) that is a foreign key (FK) that references a PK, PPK, or AK of the opposite entity in the relationship. This FK attribute provides a value that can be used to access the entity at the opposite side of the relationship line.

Page 8: 1285401 3 ER Diagramming Supplemental Material Fall2015

Normalization The general guideline – a non-key attribute (an attribute that is not a PK or an FK) can appear in one and only one entity in a database system. Attributes serving as PKs and/or FKs can appear in many entities. For example, a non-key attribute such as CustSalesVolume, should only appear in one entity in a database system (probably the Customer entity). All other entities that need to access the value in the CustSalesVolume attribute should have a relationship line with the Customer entity and a FK attribute that references the PK of the Customer Entity.

Page 9: 1285401 3 ER Diagramming Supplemental Material Fall2015

Modeling Attributes

End of Supplemental Material

Page 10: 1285401 3 ER Diagramming Supplemental Material Fall2015

Complex ER Diagram

Page 11: 1285401 3 ER Diagramming Supplemental Material Fall2015

Assignment 3

Convert this single table below to an equivalent collection of tables that are in third normal form (3NF).

Your solution should include all non-key attributes for each table and all PKs and FKs. Non-key

attributes can only appear in one table of your exam solution.

INVOICE (INVOICE_NUMBER CUSTOMER_NUMBER, LAST, FIRST, STREET, CITY, STATE,

ZIP_CODE, INVOICE_DATE, (PART_NUMBER, PART_DESCRIPTION, UNIT_PRICE,

NUMBER_SHIPPED))

This table contains invoice information for a company that sells auto parts. For each invoice (identified by

the invoice number) there will be a single customer. The customer's number, name, and address appear on

the invoice as well as the invoice date. Also, there may be several different auto parts appearing on each

invoice. For each part that appears, the Part Number, Part Description, Unit Price, and Number Shipped

will be displayed. The unit price and part description are from the master part table. The master part table

is a complete list of all the auto parts that the company sells. The master part table must be one of the

tables in your solution.

Page 12: 1285401 3 ER Diagramming Supplemental Material Fall2015

Normalization Example

Page 13: 1285401 3 ER Diagramming Supplemental Material Fall2015
Page 14: 1285401 3 ER Diagramming Supplemental Material Fall2015