MIS 385/MBA 664
Systems Implementation with DBMS/
Database Management
Dave Salisbury
salisbury@udayton.edu (email)
http://www.davesalisbury.com/ (web site)
Modeling reality


A database must mirror the real world if it is
to answer questions about the real world
Data Modeling is a design technique for
capturing reality
STUDENT
Social_Security_No
Name
Major
Business rules





Statements that define or constrain
some aspect of the business
Assert business structure
Control/influence business behavior
Expressed in terms familiar to end users
Automated through DBMS software
A good business rule is:







Declarative – what, not how
Precise – clear, agreed-upon meaning
Atomic – one statement
Consistent – internally and externally
Expressible – structured, natural language
Distinct – non-redundant
Business-oriented – understood by business
people
The conceptual model (ER diagram)


Representation of structure and constraints of
database independent of software
Mainstream approach to conceptual modeling
is ERD





ease of use
CASE support
entities and relationships are “natural”
No standard notation
Building blocks are entities, attributes,
relationships, and identifiers
E-R model constructs

Entity instance - person, place, object, event, concept
(often corresponds to a row in a table)



Entity Type – collection of entities (often corresponds to a
table)
Attribute - property or characteristic of an entity type
(often corresponds to a field in a table)
Relationship instance – link between entities
(corresponds to primary key-foreign key
equivalencies in related tables)

Relationship type – category of relationship…link between
entity types
Elements of an E-R diagram - Hoffer
Entity
symbols
A special entity that is
also a relationship
Relationship
degrees
specify
number of
entity types
involved
Attribute
symbols
Relationship
symbols
Relationship
cardinalities
specify how
many of
each entity
type is
allowed
Elements of an E-R diagram – Chen*
ENTITY
ATTRIBUTE
RELATIONSHIP
WEAK
ENTITY
MULTIVALUED
ATTRIBUTE
INDENTIFYING
RELATIONSHIP
*Actually somewhat modified Chen.
ASSOCIATIVE
ENTITY
DERIVED
ATTRIBUTE
What should an entity be?

Should be:




An object that will have many instances in the
database
An object that will be composed of multiple
attributes
An object that we are trying to model
Should NOT be:


A user of the database system
An output of the database system (e.g. a report)
Inappropriate/Appropriate Entities
System
user
System output
Inappropriate
entities
Appropriate
entities
Attributes




A discrete data element
Describes an entity (i.e.,
is a characteristic)
Meaningful (for the
system being modeled)
Attributes are the items
of interest to the
organization -- the
things being stored

Customer_Number


Last_Name


Zip


Xenia
State


2425 Jasper Road
City


Dave
Address


Salisbury
First_Name


12345
OH
45385
Phone

937-293-0258
Identifiers (keys)



Identifier (Key) - An attribute (or
combination of attributes) that uniquely
identifies individual instances of an
entity type
Simple Key versus Composite Key
Candidate Key – an attribute that could
be a key…satisfies the requirements for
being a key
Characteristics of Identifiers




Will not change in value
Will not be null
No intelligent identifiers (e.g. containing
locations or people that might change)
Substitute new, simple keys for long,
composite keys
Composite Attributes
An attribute
broken into
component parts
Composite Attributes
An attribute
broken into
component parts
Key attributes
The identifier is boldfaced and underlined
Simple key attribute
The key is underlined
Composite Key
The key is composed
of two subparts
Multi-valued & derived attributes
Multivalued
an employee can have
more than one skill
Derived
from date
employed and
current date
Both multivalued & composite
attribute
This is an example
of time-stamping
Multi-valued & derived attributes
What’s wrong with this?
Derived
from date employed and current date
Multivalued:
an employee can have
more than one skill
Multivalued & composite attribute
This is an
example of timestamping
More on relationships

Relationship Types vs. Relationship Instances


Relationships can have attributes



The relationship type is modeled as the text on the lines
between entity types…the instance is between specific entity
instances
These describe features pertaining to the association
between the entities in the relationship
Two entities can have more than one type of
relationship between them (multiple relationships)
Associative Entity = combination of relationship and
entity

More on this later
Relationship types and instances
Relationship type
Relationship
instances
Relationship degree
One entity
related to another
of the same
entity type
Entities of two
different types
related to each
other
Entities of three
different types
related to each
other
Relationship degree
Unary – related to
same entity type
Binary – two different
entity types
Ternary – three
different
entity types
Cardinality Constraints


Cardinality Constraints - the number of
instances of one entity that can or must
be associated with each instance of
another entity.
Minimum Cardinality



If zero, then optional
If one or more, then mandatory
Maximum Cardinality

The maximum number
Relationship cardinality notation
Mandatory one
Mandatory many
Optional one
Optional many
Relationship cardinality notation
Mandatory one
Mandatory many
Optional one
Optional many
Unary
Unary
Binary
Binary
Binary relationship with an attribute
Here, the date completed attribute pertains specifically to the
employee’s completion of a course…it is an attribute of the
relationship
Ternary relationship (w/ attributes)
(Relationships can have attributes of their own)
Ternary relationship (w/ attributes)
(Relationships can have attributes of their own)
Hierarchical Relationships


Occur frequently
Model as multiple 1:M relationships
Firm
Division
Dept
Strong vs. weak entities &
identifying relationships

Strong entities




Weak entity






exist independently of other types of entities
own unique identifier
identifier underlined with single-line
dependent on a strong entity (identifying owner)
cannot exist on its own
no a unique identifier (only a partial identifier)
Partial identifier underlined with double-line
Entity box has double line
Identifying relationship

links strong entities to weak entities
Strong & weak entities
Identifying relationship
Strong entity
Weak entity
Strong & weak entities
Weak entity
Strong entity
Identifying relationship
Associative entities



It’s an entity – it has attributes
AND it’s a relationship – it links entities together
When should a relationship with attributes instead be
an associative entity?





All relationships for the associative entity should be many
The associative entity could have meaning independent of
the other entities
The associative entity preferably has a unique identifier, and
should also have other attributes
The associative may be participating in other relationships
other than the entities of the associated relationship
Ternary relationships should be converted to associative
entities (p 112-113)
Associative entity
Associative entity is like a relationship with an attribute, but it is
also considered to be an entity in its own right.
Associative entity
Associative entity involves a rectangle with a diamond inside.
Note that the many-to-many cardinality symbols face toward the
associative entity and not toward the other entities
Associative Entity
This could just be a relationship with
attributes…it’s a judgment call
Associative Entity
This is the Bill of Materials laid out a different
way. It could just be a relationship with
attributes…it’s a judgment call
Ternary as Associative Entity
Ternary as Associative Entity
Mandatory cardinalities
A patient history is
recorded for one and
only one patient
A patient must have recorded
at least one history, and can
have many
1 optional many, 1 mandatory many
A project must be
assigned to at least one
employee, and may be
assigned to many
An employee can be
assigned to any number
of projects, or may not be
assigned to any at all
Optional Cardinality
A person is is
married to at most
one other person,
or may not be
married at all
Multiple relationships
(entities can be related to one another in more than one way)
Entities can be related to one another in more than one way
Multiple relationships
(entities can be related to one another in more than one way)
Employees and departments
Professors & courses
(fixed upon constraint)
Here, min
cardinality
constraint is 2
Professors & courses
(fixed upon constraint)
Here,max
cardinality
constraint is
4
Multivalued attribute vs. relationship
simple
composite
Multivalued attribute vs. relationship
Sample E-R Diagram
(Figure 3-1)
Sample E-R Diagram
(Similar to figure 3-1 with different notation)
Pine Valley Furniture
Pine Valley Furniture
Modified Chen notation used in an
earlier edition of our textbook
Different notation
CUSTOMER
ORDER
* Customer ID
Customer name
* Order ID
Order Date
Third style of notation
Customer ID
CUSTOMER
Customer name
1
SUBMITS
M
Order ID
ORDER
Order date
Oracle notation
CUSTOMER
#Customer_ID
*Customer Name
ORDER
#Order_ID
*Order Date
Access Notation