Modeling Data in the Organization

WEEK-2

Modern Database Management

12th Edition
Jeffrey A. Hoffer, V. Ramesh, Heikki Topi
ER Models
Business Rules

• Are statements that define or constrain some aspect of the

business
• Are derived from policies, procedures, events, functions
• Assert business structure
• Control/influence business behavior
• Are expressed in terms familiar to end users
• Are automated through DBMS software

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

3
Business Rules

• Data don’t explain business, business rules do

• Descriptions of policies, procedures, or principles within a
specific organization
– Apply to any organization that stores and uses data to
generate information
– A pilot should not fly more than 14 hours a day
• Description of operations to create/enforce actions within an
organization’s environment
– Must be in writing and kept up to date
– Must be easy to understand and widely disseminated
• Describe characteristics of data as viewed by the company

30/07/2021
4
 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

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

5
ER Model Components

• The ER model is well-suited to data modelling for

databases.
• ER modelling is based on three concepts:
• Entities, that is, things.
• Attributes, that is, properties of things
• Relationships, that is, associations or interactions between
entities.
• It is fairly abstract and it can be explained fairly easily
• ER models are readily translated to relations.
• ER models (or ER schemas) are represented by ER diagrams

7/30/21
6
 ER Model Components- Other
definitions
• Entities:
• Entity–person, place, object, event, concept

• Relationships:
• Relationship–link between entities
• Relationship type–category of relationship…link between entity
types

• Attributes:
• Properties or characteristics of an entity or relationship type (often
corresponds to a field in a table)

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

7
 An Entity

• 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)

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

8
Types of Entities

Strong entity
• exists independently of other types of entities
• has its own unique identifier known as primary identifier
• Note: please do not use the term ’Primary Key’ here

Weak entity
• depends on a strong entity to exist.
• doesn’t have its own primary identifier

Associative entities
• to be discussed later

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

9
Example of a weak identity and its identifying relationship

Strong entity Weak entity

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

10
 Attributes

• Attribute–property or characteristic of an entity or relationship

type
• Classifications of attributes:
• Required versus Optional Attributes
• Simple versus Composite Attribute
• Single-Valued versus Multivalued Attribute
• Stored versus Derived Attributes
• Identifier Attributes

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

11
Required vs. Optional Attributes

Required – must have a value for Optional – may not have a value
every entity (or relationship) for every entity (or relationship)
instance with which it is associated instance with which it is associated
12
 Simple vs. Composite Attributes

• Composite attribute – An attribute that has meaningful

component parts (attributes)

The address is
broken into
component parts

A composite attribute

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

13
 Multi-valued and Derived Attributes
Multivalued – may take on more than Derived – values can be calculated from
one value for a given entity (or related attribute values (not physically
relationship) instance stored in the database)

Entity with multivalued attribute (Skill) and derived attribute (Years

Employed)

Multivalued Derived
an employee can Calculated
have more than one from date
skill employed
and current
date

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

14
Identifier Attributes

• Identifier attribute- an attribute (or combination of attributes)

that uniquely identifies individual instances of an entity type

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

15
Suggestions for Identifiers
• Choose Identifiers that
• Will not change in value
• Will not be null
• Avoid intelligent identifiers (e.g., containing locations or people
that might change)
• Substitute new, simple keys for long, composite keys

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

16
 Naming Attributes
• Name should be a singular noun or noun phrase
• Name should be unique
• Name should follow a standard format
• e.g. Entity name |Attribute name
• Similar attributes of different entity types should use the same
qualifiers and classes

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

17
 Relationships
• A relationship is modeled as lines between entities
• Relationships can have attributes (in many-many
relationships)
• 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

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

18
 Relationship types and instances

Relationship
example

Relationship
instances
with
instances of
entities

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

19
Degree of Relationships

• Degree of a relationship is the number of entity types that

participate in it
• Unary Relationship
• Binary Relationship
• Ternary Relationship

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

20
 Degree of relationships – from Figure 2-2

One entity Three or

related to Two entities
more related
itself related to each
other to each other

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

21
 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

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

22
Examples of Unary relationships

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

23
Examples of Binary relationships

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

24
 Examples of Ternary relationship

Note: a relationship can have attributes of its own

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING
25
 Cardinality & Constraints
• Cardinality Constraints—the number of instances of one entity that
can or must be associated with each instance of another entity
• Cardinality
• The maximum number in a relationship (will be either one/many)
• Constraints
• The minimum number in a relationship (will be either zero/one)
• Zero means optional
• One means mandatory

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

26
 Associative Entities

• An entity–has attributes
• A relationship–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 entity may participate in other relationships other
than the entities of the associated relationship
• Ternary relationships should be converted to associative entities

I FACULTY OF SCIENCE I DEPARTMENT OF COMPUTING

27
 References

• Elmasri and Navathe, “Fundamentals of Database Systems, Chapters 1 & 2”,

Pearson, 2014.
• Modern Database Management 12th Edition, Jeff Hoffer, Ramesh
Venkataraman, Heikki Topi , 2016
• Coronel, C., & Morris, S. (2015). Database systems: Design, implementation,
and management (11th edition [student edition].). Stamford, Conn.: Cengage
Learning.

ITEC800 - Week 5 28