ARTIFICIAL, COMPOSITE, AND SECONDARY  Each Manufacturer may produce one or

UIDS more Products. Each Product may be

produced by one or more Manufacturers
Purpose  The Catalog Item resolves this M:M
 Unique identifier (UID) is important in Relationship. Item in catalog can be
relational databases. uniquely identified by the manufacturer
 Value or combination of values that number and the product code.
enables user to find that one unique item 
among all the rest.
 Enables to find your record in a file

Simple UIDs vs Composite UIDs

 Simple UID – a single attribute Relationship is not barred because artificial
 Composite UID- combination of attribute UID – catalog number – is created
instead.
Artificial UID
 Don’t occur in the natural world but are Candidate UIDs
created for purposes of identification in  Two or more possible UIDs exist.
a system. Ex: When ordering a product, you will be
 Assigned a unique number to identify assigned a unique customer code and asked to
people: Student Number, Customer ID, enter email address.
etc. Each of these uniquely identifies you, and
 A UID can be both artificial and each could be your UID. These are both
composite. candidate UID.
 Only one of candidate UID is chosen as
UIDs from Barred Relationships the actual UID – Primary ID.
 Sometimes UID is combination of an  The other candidates are – Secondary
attribute and a relationship. ID.

UID from Barred Relationship Intersection Identification: Database vs Real World

Entity  Unique identifiers make it possible for
 The resolution of a M:M relationship us to distinguish one instance of an
often results in barred relationships from entity from another.
the intersection entity to the original  These become primary keys in database.
ones.  Primary key – allows you to access a
specific record in database
Ex: UID of Play List
Item comes from
Event and Song. It is
NORMALIZATION AND FIRST NORMAL FORM
the bars on
relationship that
Purpose
tells you this
 Normalization – used to eliminate
redundancy
Artificial UID Intersection Entity
 One of your goals as a database designer
 Possible for an intersection entity to use
is to “store information in one place and
an artifical attribute as the UID instead
in the best possible place”
of the barred relationshis to the
originating entities
First Normal Form (1NF)
  Goal: Eliminate repeating groups (each redundant and can lead to errors if you
column holds single value) miss updating some records.
 Requires no multi-valued attributes exist.
 To check, validate each attribute has Solution:
single value for each instance of the  Following 2NF, you ensure that the
entity. supplier’s name in one place only. Makes
Ex: One code, one update easier and prevent
name, and one inconsistencies.
address exist for the
school building, but Second Normal Form Bar Relationship
not one classroom The UID for account is a composite UID from
barred relationship consisting of Account
CLASSROOM number and Bank number
is not its own
entity. Both Is balance a property of Account number,
entities are in Bank Number, or
First Normal Form. both? Is date opened
a property of
 If an attribute is multi-valued, create an Account number,
additional entity and relate it to the Bank number, or both?
original entity with a 1:M relationship
Second Normal Form Violation
The attribute bank location has been added. Is
SECOND NORMAL FORM (2NF) bank location a property of Account Number,
 Goal: remove partial dependencies bank number, or both?
 Helps organize data to avoid redundancy
and inconsistencies It Is a property of Bank number only
 Builds on First Normal Form, which and is thus misplaced. This is a violation of
ensures that each table has a unique Second Normal Form.
identifier (UID) and that each column
contains only single values.

Key Idea:
 Every information in a table must depend
on the entire unique identifier (UID), not If the bank location is changed, every account
just part of it. at the bank would need to be updated.
 If the UID is made up of multiple
columns, all other columns must depend Another ex:
on the entire combination, not just one The attributes duration
part. and event date are
misplaced. Duration
Why important? depends solely on song,
 You have a table that stores info about and event date depends
products and suppliers. If the supplier’s solely on event. Violation
name is stored multiple times, and the of Second Normal Form
supplier’s name changes, you’d have to
update it in many places. This is
THIRD NORMAL FORM
  Goal: Eliminate transitive dependencies Ex: A billboard is an advertising space that can
 Rule of Third Normal Form (3NF) states feature a movie, a product, or a public
that no non-UID attribute can be announcement. May contain advertising
dependent on another non-UID attribute. about only one of these at a time.
 3NF prohibits transitive dependencies. A
transitive dependency exists when any
attribute in an entity is dependent on any
other non-UID attribute in that entity

Ex:
Does information about the
store where you bought the
CD belong in the same
entity? Each feature has its own characteristics or
attributes. Exclusive OR – returns true value if
If the store address changed, one, but not both, of its operands is true.
you would have to change the information on
all the CDs that were bought at that store. Representing Exclusive OR Relationships in
the ERD
Store address is dependent on CD number,  Arcs – way to represent mutually
which is the UID of CD entity. So this entity is exclusive relationships (Exclusive OR)
in 1NF and 2NF. - Belongs to one entity
- Not all relationships of an entity need
But store address is also dependent on store to be included in an arc
name, which is a non-UID attribute. - Entity may have several arcs
- Should always consist of relationships
of the same optionality
- All relationships in an arc must me
mandatory or all must be optional
Ex: Each event must be held at one Private
Home or one Public Space, but not BOTH
ARCS
 In data modeling, help designers clarify
an exclusive OR across relationships. The
more explicitly you can define the client’s
requirements, the more accurate is the
implementation.

Constraint
- restriction on which attribute value
and which relationships are allowed.
 May refer to a single attribute of an
entity, or to relationships between
entities.

Exclusive OR Relationship
 Mutually exclusive relationships Arcs, Supertypes, and Subtypes
(Exclusive OR relations) often exist
 Arcs can sometimes be drawn as  M:M Recursive relationship
supertypes or subtypes  Each Component may be a part of one or
more Components.
 Each Component may be made up of one
or more Components.

MODELING HISTORICAL DATA

 Businesses need to track historical data
to find trends and patterns that are basis
for business innovations or process
HIERARCHIES AND RECURSIVE improvements.
RELATIONSHIPS Ex: Rental history of movie. It tells managers
which movies are popular and which should
Relationships in an Organizational Chart be moved to the back shelf.
 Organizational Chart – represented by
this data model Data Overtime Ex:
Organization needs to keep data about
employee’s salaries. All employees are paid
weekly Initially, Employee entity was modeled

Additional requirements now specify that the

Hierarchy vs Recursive Relationship
organization needs to keep a historical record
 On the left
of how and when employees’ salaries have
is
changed during their employment.
hierarchical
structure
To model salary changes over time, add a
 On the right
Salary History entity
is recursive
relationship

UID of Salary History is the related Employee

id and the salary start date.

PRESENTATION OF THE ERD TO THE CLIENT

 Presentation should be organized and
well prepared. Assign roles and MODELING CHANGE: PRICE
responsibilities to different group Purpose
members for each part of the  Historical prices are important when
presentation. looking for trends, determining the
 Use Simple Vocabulary – not use appreciation or depreciation value of
technical terms with client such as UID, items, or getting a refund for an item
attribute, or entity purchased in the past at a previous price.

MODELING CHANGE: TIME Importance of Price Change

Purpose  Changes in price are important
 Time plays a role in many business consideration when modeling business
models. requirements:
 Historical data is often used by Ex: Stock Market – price change by the
businesses to find trends that can point second and you are watching the reader
the way to more efficient ways of doing board, wondering when to buy and when to
business. sell.
 Modeling time in a business allows such
data to be captured.  Price of products change over time.

Time-related Constraints Model Historical Price

 Shift “End  The model shown
Time” must be tracks the historical price of a
later than shift product
“Start Time”
 Shift times
may not
overlap.
 Start time for a shift may be updated to a
later time, unless the shift has already
begun.
Tracking Price Changes
Conditional Non-transferability  Business need to keep record of price
 You prolly would not allow shift to be change.
reassigned to another volunteer or
another booth, unless shift had not yet
started.
 Non Transferability – shift assignment
cannot be changed to another booth or
volunteer
 Nontransferable relationships are
represented by a diamond in the ERD.
 Conditional non-transferability – shift Journaling
assignment CAN SOMETIMES be changed - When a system allows user to modify
– in this case, if the shift has not yet or remove
started. These relationships cannot be information.
represented in the diagram but must still - Usually consists
be documented. of both the
 modified value and the information
about who did the modification and
when it was done.

DRAWING CONVENTIONS FOR READABILITY Generic model Benefits:

The bigger and more complicated ERD gets,  Flexibility – reduce the need to change
the more challenging it becomes to lay out data structures in the future.
pieces in a clear and readable format.  Readability – reduce the number of
entities dramatically
High volume entities those that would contain
highest number of instances compared to Cost of generic model
another instance  Increased complexity in both data model
and application program
High volume entities are often the “central” or  Decreased performance
more important entities in ERD. They will have
the highest number of relationships to other
entities.

Clarity is Key
High volume entities are not always the most
important.
Clarity and Readability are the main criteria.

Space is Needed
Readability takes space and is subject to taste.
Use of white space helps clarify an ERD

Use Sub-Diagrams
When you have
very large diagram,
it may also help to
break it up into
smaller diagrams of
functionally related
entities.

GENERIC MODELING
Purpose
 Generic models – reduce the number of
entities in a diagram and provide a lot of
flexibility in unstable situations where
business requirements change often.