Data Analysis: Modeling Data in

the Organization

Lecture # 03
SDLC Revisted
Purpose–thorough requirements analysis
Planning and structuring
Deliverable–functional system specifications
Analysis
Analysis

Design

Implementation

Database activity–Thorough
and integrated conceptual Maintenance
data modeling
WHAT ARE BUSINESS
RULES?
• Business rules are derived from policies, procedures, events
functions and other business objects
• They state constraints on the organization
• For example: “ A student may register for a section of a course
only if he or she has successfully completed the prerequisites
for that course”
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
Why data modeling is
important
• Characteristics captured during data modeling are crucial in
design of databases, programs and other system components
• Data rather than process are most complex aspect of modern
IS
• Data tend to be more stable than business process that use
that data.
ER MODEL
• Logical representation of the data for an organization
• Entity relationship diagram is used as graphical representation
for ER model
 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
Sample E-R Diagram (figure 3-1)
<entity><minimum cardinality> <relationship> <maximum
cardinality> <entity>
 Figure 3-2 -- Basic E-R Notation

A special entity
that is also a
relationship

Entity
symbols

Attribute
symbols

Relationship
symbols
Data names and Definitions
• Data objects must be named and defined before
using them in a model. Data names should be :
• Related to business
• Be meaningful
• Be unique
• Be readable
• Be composed of words taken from approved list
• Be repeatable
• Follow a standard syntax
Data definitions
• Explanation of term or fact
• Term is word or phrase having meaning for the business e.g
course, section etc
• Fact is an association between two or more terms. E.g. A
course is module of instruction in particular subject area
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 entities
Figure 3-4

System user System output

Appropriate entities
Entity types vs Entity
instance
• Collection of entities sharing common properties is entity
type. Is always singular

• Single occurrence of an entity type is entity instance

Strong vs Weak entity types
• Strong is the one that exists independently of other
entity types
• Weak is the one whose existence depends on some
other entity type
• Each strong entity has identifier
• Where as weak entity has no existence without
identifying owner or simply owner
• Partial identifier is an attribute of weak entity that
makes weak entity unique when combined with
identifier of its strong entity
Strong vs Weak entity types
Naming & Defining Entity
types
1. Singular noun such as CUSTOMER, STUDENT
2. An entity type name should be specific to the organization.
• CUSTOMER, PURCHASE ORDER, ORDER, CUSTOMER ORDER.
3. An entity type name should be concise, using as few words as
possible
• REGISTRATION for REGISTRATION FOR CLASS
4. An abbreviation, or a short name, should be specified for each
entity type name
Entity type versus Entity
instance contd..
5. Event entity types should be named for the result of the event,
not the activity or process of the event.
• For example,
• the event of a project manager assigning an employee to work on a
project results in an ASSIGNMENT,
• the event of a student contacting his or her faculty advisor seeking some
information is a CONTACT
6. The name used for the same entity type should be the same on
all E-R diagrams on which the entity type appears
Attributes
• An attribute is a property or characteristic of an entity type
that is of interest to the organization.
1. An attribute has a noun name.
• STUDENT Student ID, Student Name, Home Address, Phone Number,
Major
• AUTOMOBILE Vehicle ID, Color, Weight, Horsepower
• EMPLOYEE Employee ID, Employee Name, Payroll Address, Skill
2. Use an initial capital letter followed by lowercase letters
Attributes
• Classifications of attributes:
• Required versus optional attribute
• Simple versus Composite Attribute
• Single-Valued versus Multivalued Attribute
• Stored versus Derived Attributes
• Identifier Attributes
Required versus optional
attributes
• required attributes will be in boldface,
• optional attributes will be in normal font
Simple versus composite
attributes
• Composite attributes
• Some attributes can be broken down into meaningful component
parts.
• NAME: FirstName, LastName etc.
• Addrress: House, Street, City, Province
• A simple (or atomic) attribute is an attribute that cannot be
broken down into smaller components
• Attributes of AUTOMOBILE are simple: Vehicle ID, Color, Weight,
and Horsepower.
Identifiers (Keys)
• Identifier (Key) - An attribute (or combination of attributes)
that uniquely identifies individual instances of an entity type
• Simple Key versus Composite 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
Identifier attribute
 Figure 3-9a – Simple key attribute

The key is underlined

 Figure 3-9b -- Composite key attribute

The key is composed

of two subparts
 Figure 3-8 -- Entity with a multivalued attribute (Skill) and derived attribute
(Years_Employed)

What’s wrong with this?

Multivalued:
Derived
an employee can have
from date employed and current date
more than one skill
Figure 3-19 – an attribute that is both multivalued and composite

This is an
example of time-
stamping
Single-valued Versus Multivalued
Attributes
• For each entity instance, each of the attributes in the figure has one
value.
• there is an attribute that may have more than one value for a given
instance.
• indicate a multivalued attribute with curly brackets around the
attribute
Stored Versus Derived
Attributes
• Some attribute values that are of interest to users can be
calculated or derived from other related attribute values that
are stored in the database.
• indicate a derived attribute with square brackets around the
attribute
• Or some tools use a notation of forward / in front of the
attribute name.
Naming and defining
attributes
• An attribute name is a singular noun or noun phrase
• An attribute name should be unique.
• To make an attribute name unique and for clarity purposes,
each attribute name should follow a standard format.
• Similar attributes of different entity types should use the same
qualifiers and classes such as Faculty Residence City Name
Naming and defining
attributes contd..
• and Student Residence City Name.
• Any aliases, or alternative names, for the attribute can be
specified in the definition, or may be included elsewhere in
documentation
• For a multivalued attribute, the attribute definition should
indicate the maximum
and minimum number of occurrences of an attribute value for an
entity instance.
Naming and defining
attributes contd..
• Read more from the book (Assignment)
Activity-I
• The entity type STUDENT has the following attributes:
• Student Name, Address, Phone, Age, Activity, and No of Years.
Activity represents some campus-based student activity, and No of
Years represents the number of years the student has engaged in
this activity.
• A given student may engage in more than one activity.
• Draw an ERD for this situation. What attribute or attributes did you
designate as the identifier for the STUDENT entity? Why?
Modeling Relationships
• a relationship is an association representing an interaction among
the instances of one or more entity types that is of interest to the
organization.
• a relationship has a verb phrase name.
• Relationships and their characteristics (degree and cardinality)
represent business rules
More on Relationships
• Relationship Types vs. Relationship Instances
• The relationship type is modeled as the diamond and lines
between entity types…the instance is between specific entity
instances
• Relationships can have attributes
• 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
Naming and Defining
Relationships
• A relationship name is a verb phrase (such as Assigned To,
Supplies, or Teaches).
• You should avoid vague names, such as Has or Is Related To.
Use descriptive, powerful verb phrases, often taken from the
action verbs found in the definition of the relationship
• Reading assignment
Attributes On Relationships
• attributes may be associated with a many-to-many (or one-to-
one) relationship called as associative entity
• For example,
• suppose the organization wishes to record the date
(month and year) when an employee completes each
course. This attribute is named Date Completed.
Associative entity
• The associative entity CERTIFICATE is represented with the
rectangle with rounded corners
whether to convert a
relationship to an associative
entity type?
• Following are four conditions that should exist:
1.All the relationships for the participating entity types are
“many” relationships.
2.The resulting associative entity type has independent meaning
to end users and can be identified with a single-attribute
identifier.
whether to convert a
relationship to an associative
entity type? Contd..
3. The associative entity has one or more attributes in addition
to the identifier.
4. The associative entity participates in one or more
relationships independent of the entities related in the
associated relationship.
Degree of Relationships
• Degree of a Relationship is the
number of entity types that
participate in it
• Unary Relationship
• Binary Relationship
• Ternary Relationship
Degree of relationships –

One entity
related to Entities of two
another of the different types Entities of three
same entity related to each different types
type other related to each
other
Degree of Relationship
contd..
• Binary Relationship:
Degree of Relationship
contd..
• Ternary Relationship:
• A ternary relationship is a simultaneous relationship among the
instances of three entity types
Cardinality of Relationships
• One – to – One
• Each entity in the relationship will have exactly one
related entity
• One – to – Many
• An entity on one side of the relationship can have
many related entities, but an entity on the other side
will have a maximum of one related entity
• Many – to – Many
• Entities on both sides of the relationship can have
many related entities on the other side
 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
Cardinality – figure 3-2
Modeling Multiple Relationships
Between Entity Types contd..
Examples of multiple relationships – entities can be related to one
another in more than one way
Figure -- Professors and courses (fixed upon constraint)

Here,max
cardinality
constraint is 4
Figure 3-15: Multivalued
attribute vs. relationship.
Alternative approaches
Figure 3-5: Strong and weak entities

Strong entity Identifying relationship Weak entity

Activity-II
A company has a number of employees. The attributes of EMPLOYEE
include Employee ID ( Naq also has several projects. Attributes of
PROJECT include Project ID (identifier), Project Name, and Start Date. Each
employee may be assigned to one or more projects, or may not be assigned
to a project. A project must have at least one employee assigned and may
have any number of employees assigned. An employee’s billing rate may
vary by project, and the company wishes to record the applicable billing
rate (Billing Rate) for each employee when assigned to a particular project.
Draw ERD for the scenario given. Do you have any associative entities on
your ERD?
‘
• Questions?????????
References
• Chapter 2
• By jeffery A. hoffer 10th Ed.