Upload
manoj
View
219
Download
0
Tags:
Embed Size (px)
DESCRIPTION
this is the best
Citation preview
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.
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.
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
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.
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.
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.
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.
Modeling Attributes
End of Supplemental Material
Complex ER Diagram
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.
Normalization Example