Modeling Data Objects

1
 LO1 Identify Entities and Relationships
1.1 Understanding and analyzing business operations
Entity Types, Entity Sets, Attributes and Keys
ER Model Overview
ER model describes data in terms of:
– Entities and entity sets
– Objects
– Relationships and relationship sets
– Connections between objects
– Attributes
– Properties that characterize or describe entities or
relationships

2
Entity
• An entity can be a real-world object that can be easily
identifiable.
• For example, in a school database, students, teachers, classes,
and courses offered can be considered as entities. All these
entities have some attributes or properties that give them their
identity.
• An entity set is a collection of similar types of entities. An entity
set may contain entities with attribute sharing similar values. For
example, a Students set may contain all the students of a school;
likewise a Teachers set may contain all the teachers of a school
from all faculties. Entity sets need not be disjoint.
• ER model defines entity sets, not individual entities
Attributes
• Entities are represented by means of their properties, called
attributes. All attributes have values. For example, a student
entity may have name, class, and age as attributes. 3
Types of Attributes
• Simple attribute − Simple attributes are atomic values, which cannot be
divided further. For example, a student's phone number is an atomic
value of 10 digits.
• Composite attribute − Composite attributes are made of more than one
simple attribute. For example, a student's complete name may have
first_name and last_name.
• Derived attribute − Derived attributes are the attributes that do not exist
in the physical database, but their values are derived from other
attributes present in the database. For example, age can be derived from
data_of_birth.
• Single-value attribute − Single-value attributes contain single value. For
example − Social_Security_Number.
• Multi-value attribute − Multi-value attributes may contain more than
one values. For example, a person can have more than one phone
number, email_address, etc.

4
Entity, Entity Type, Entity Set –
• An Entity may be an object with a physical
existence – a particular person, car, house,
or employee – or it may be an object with
a conceptual existence – a company, a job,
or a university course.
• An Entity is an object of Entity Type and
set of all entities is called as entity set.
e.g.; E1 is an entity having Entity Type
Student and set of all students is called
Entity Set. In ER diagram, Entity Type is
represented as:
5
Keys
• Super Key − A set of attributes (one or more)
that collectively identifies an entity in an
entity set.
• Candidate Key − A minimal super key is called
a candidate key. An entity set may have more
than one candidate key.
• Primary Key − A primary key is one of the
candidate keys chosen by the database
designer to uniquely identify the entity set.
6
Relationship
• The association among entities is called a relationship. For
example, an employee works_at a department, a student enrolls
in a course. Here, Works_at and Enrolls are called relationships.
Relationship Set
• A set of relationships of similar type is called a relationship set.
Like entities, a relationship too can have attributes. These
attributes are called descriptive attributes.
Degree of Relationship
• The number of participating entities in a relationship defines the
degree of the relationship.
• Binary = degree 2
• Ternary = degree 3
• n-ary = degree

7
 Degree of Relationship
• The degree of a relationship is the number of
entity types that participate(associate) in a
relationship.
• By seeing an E-R diagram, we can simply tell
the degree of a relationship i.e. the number of
an entity type that is connected to a
relationship is the degree of that
relationship.

8
9
 Unary (degree 1)
• A unary relationship exists when both the
participating entity type are the same. When
such a relationship is present we say that the
degree of relationship is 1.

10
 Binary (degree 2)
• A binary relationship exists when exactly two
entity type participates. When such a
relationship is present we say that the degree is
2. This is the most common degree of
relationship. It is easy to deal with such
relationship as these can be easily converted
into relational tables.

11
 Ternary(degree 3)
• A ternary relationship exists when exactly three entity type participates.
• When such a relationship is present we say that the degree is 3. As the number of
entity increases in the relationship, it becomes complex to convert them into
relational tables.

12
 N-ary (n degree)
• An N-ary relationship exists when ‘n’ number of entities are participating.
So, any number of entities can participate in a relationship. There is no
limitation to the maximum number of entities that can participate. But,
relations with a higher degree are not common. This is because the
conversion of higher degree relations to relational tables gets complex.

13
Mapping Cardinalities
• Cardinality defines the number of entities in
one entity set, which can be associated with
the number of entities of other set via
relationship set.
– One-to-one − One entity from entity set A can be
associated with at most one entity of entity set B
and vice versa.

14
• One-to-many − One entity from entity set A can be associated
with more than one entities of entity set B however an entity
from entity set B, can be associated with at most one entity.

• Many-to-one − More than one entities from entity set A can

be associated with at most one entity of entity set B, however
an entity from entity set B can be associated with more than
one entity from entity set A.

15
• Many-to-many − One entity from A can be
associated with more than one entity from B
and vice versa.

16
Relationships:
• Can have more than one relationship between
entities.

• Can have recursive relationships and can indicate

roles for clarity.

• A relationship can also have attributes.

17
Participation Constraints
• Total Participation − Each entity is involved in the
relationship. Total participation is represented by
double lines.
• Partial participation − Not all entities are involved in
the relationship. Partial participation is represented by
single lines.
• E.g. not every person owns a house

18
• Weak Entity Type and Identifying Relationship:
As discussed before, an entity type has a key attribute which uniquely
identifies each entity in the entity set. But there exists some entity type
for which key attribute can’t be defined. These are called Weak Entity
type.
• For example, A company may store the information of dependants
(Parents, Children, Spouse) of an Employee. But the dependents don’t
have existence without the employee. So Dependent will be weak
entity type and Employee will be Identifying Entity type for Dependant.
• A weak entity type is represented by a double rectangle. The
participation of weak entity type is always total. The relationship
between weak entity type and its identifying strong entity type is called
identifying relationship and it is represented by double diamond.

19
• Weak entity is depend on strong entity to ensure the
existence of weak entity. Like strong entity, weak entity does
not have any primary key, It has partial discriminator key.
Weak entity is represented by double rectangle. The relation
between one strong and one weak entity is represented by
double diamond.
• Weak entities are represented with double rectangular box
in the ER Diagram and the identifying relationships are
represented with double diamond. Partial Key attributes are
represented with dotted lines.

20
21
Example-1:
In the below ER Diagram, ‘Payment’ is the weak
entity. ‘Loan Payment’ is the identifying
relationship and ‘Payment Number’ is the partial
key. Primary Key of the Loan along with the partial
key would be used to identify the records.

22
ER-Diagram Symbols

23
1.2 Identify the Scope of the System
1.2.1 Database
What is DB Scope?
• DB Scope is a tool for developers, used to view and edit databases,
application information blocks, and saved and unsaved preferences.
• DB Scope uses the concept of "layouts" for your application's databases.
You create a layout that describes the format of each of your databases. 
• A good database is one that is simple to understand and well planned.
The database doesn't have redundant tables. One can use ERD's (Entity-
Relationship Diagrams) .
• If you have good database then
– Easy to locate the data or information in no time.
– No redundant data.
– No repetition.
– More security. Like if one is accessing or changing the data other cannot change
the same data at that time.
– Table references (keys like : Primary and foreign keys) are easy to maintain.
24
1.2.2. Application
• To determine the boundaries of an application
system, it is important to examine the application
system from both functional and technical
perspectives.  A single application system will
normally have the following characteristics:
– Consistent user interface design with and application
behavior
– Common architecture (e.g. program language,
program design)
– Shared application system components (e.g. visual
objects, programs, database tables)
25
Define System Scope
•  Since system size is a measure of the magnitude of all
components of a system that are within the current scope, the
system scope should be documented in the project plan before
the system size is estimated.   
• The scope must be a complete definition encompassing all
types of requirements:
– The external business requirements are generally the most obvious
requirements and for which the definition of scope is the easiest.  
– The system design may imply requirements that are not specified.   
– Other components are often implied but not clearly defined, such as,
performance, interfaces, operations and implementation.

26
Clarify System Boundaries
• In addition to the scope, it is important that the
system boundaries are clearly understood
before the system size is estimated.  The
boundaries identify where the system to be
sized starts and ends.  
• There are two primary reasons to exclude
something from the sizing:
– The component is another team's responsibility.   
– The component is assumed to be already
implemented.  
27
1.3 Reviewing business rules to determine impact
Over view of business rules
• Use business rules to control the behavior of a business practice.
 What is a business rule?
• A business rule is anything that imposes structure upon or controls the
behavior of a business practice. A rule can enforce business policy, establish
common guidelines within an organization, or control access in a business
environment.
• Business Rules are an important component of the database. Along with
contributing to overall data integrity, Business Rules impose integrity
constraints that are specific to the organization.
When to use a business rule
• Some typical uses for business rules are as follows:
– Determining current interest rates
– Calculating discounts for products
– Calculating sales tax
– Determining special groups such as senior citizens or preferred customers

28
29
30
 LO2 Develop Normalization
2.1 Introduction to Normalization
Normalization: Definitions
• Normalization is a method used to validate and improve a
logical design so that it satisfies certain constraints that avoid
unnecessary duplication of data. The process of
decomposing relations with anomalies to produces smaller,
well-structured relations.
• Formal process of decomposing relations with anomalies to
produce smaller, well-structured and stable relations
• Primarily a tool to validate and improve a logical design so
that it satisfies certain constraints that avoid unnecessary
duplication of data

31
 Well-Structured Relations
• A relation that contains minimal data redundancy and
allows users to insert, delete, and update rows without
causing data inconsistencies.
• Goal is to avoid (minimize) anomalies :
– Insertion Anomaly – adding new rows forces user to create
duplicate data
– Deletion Anomaly – deleting a row may cause loss of other data
representing completely different facts.
– Modification Anomaly – changing data in a row forces changes
to other rows because of duplication.
• General rule of thumb: a table should not pertain to more
than one entity type
32
• Question – Is this a relation? Answer – Yes: unique rows and no multivalued
attributes
• Question – What’s the primary key? Answer – Composite: EmpID, CourseTitle

33
 Anomalies in this Table
• Insertion – can’t enter a new employee without having the
employee take a class.
• Deletion – if we remove employee 140, we lose information
about the existence of a Tax Acc class .
• Modification – giving a salary increase to employee 100
forces us to update multiple records .
Why do these anomalies exist?
• Because there are two themes (entity types – what are
they?) in this one relation (two themes, entity types, were
combined). This results in duplication, and an unnecessary
dependency between the entities

34
 First Normal Form (1NF)
• Only atomic attributes (simple, single-value)
• A primary key has been identified
• Every relation is in 1NF by definition
• 1NF example:

35
 Functional Dependencies
• Functional Dependency: The value of one attribute
(the determinant) determines the value of another
attribute.
• A→B reads “Attribute B is functionally dependent on
A”.
• A→B means if two rows have same value of A they
necessarily have same value of B.
• FDs are determined by semantics: You can’t say that a
FD exists just by looking at data. But can say whether
it does not exist by looking at data.
36
• Quick Check

• Id →Name?
• Age → Gender?
• Name → Id?
• Name, Age →Id?

37
Functional Dependencies and Keys
• Functional Dependency: The value of one
attribute (the determinant) determines the value
of another attribute.
• Candidate Key :
– Attribute that uniquely identifies a row in a relation
– Could be a combination of (non-redundant) attributes
– Each non-key field is functionally dependent on every
candidate key

38
• Representing Functional Dependencies (cont.)

• EmpID → __________________
• EmpID, CourseTitle → __________________

39
 Practice Exercise

1. Convert this table to a relation (named PART SUPPLIER) in 1NF

2. Draw a relational schema for PART SUPPLIER and show the
functional dependencies. Identify a candidate key.
3. Identify each of the following: an insert anomaly, a delete
anomaly, and a modification anomaly.

40
Second Normal Form (2NF)
• 1NF PLUS every non-key attribute is fully
functionally dependent on the ENTIRE
primary key
• Every non-key attribute must be defined by
the entire key, not by only part of the key
• No partial functional dependencies

41
• Functional Dependencies in Student

• Can represent FDs with arrows as above, or

– StudentId →StuName,
– CourseId → CourseName
– StudentId,CourseId → Grade (and StuName,
CourseName)
• Any partial FDs ?
– Therefore, NOT in 2nd Normal Form!!
42
• How do we convert the partial dependencies
into normal ones ? By breaking into more
tables.

• Becomes … (notice above arrows mean

functional dependency, below they mean FK
constraints)

43
 Exercise

• List all FDs

• Eliminate partial FDs, if any

44
 Third Normal Form
• 2NF and no transitive dependencies
• A transitive dependency is when a non-key
attribute depends on another non-key
attribute
• Note: This is called transitive, because the
primary key is a determinant for another
attribute, which in turn is a determinant for a
third attribute

45
 3NF Example

• Classroom → Capacity TRANSITIVE

• Any partial FDs? NO
• Any transitive FDs? YES !
• How do we eliminate it?
• By breaking into its own table

46
 3NF Normalization

• Exercise

•  Partial FDs? Eliminate, if any.

•  Transitive FDs? Eliminate, if any.

47
 Practice Exercise

1. Develop a diagram that shows the functional dependencies

in the SHIPMENT relation.
2. In what normal form is SHIPMENT? Why?
3. Convert SHIPMENT to 3NF if necessary. Show the resulting
table(s) with the sample data presented in SHIPMENT.
48
• Boyce-Codd Normal form (BCNF)
– Slight difference with 3NF
– To be in 3NF but not in BNF, needs two composite
candidate keys, with one attribute of one key
depending on one attribute of the other
– Not very common
– If a table contains only one candidate key, the 3NF
and the BCNF are equivalent.

49
 BCNF Example
• Assume that
• For each subject, each student is taught by one Instructor
• Each Instructor teaches only one subject
• Each subject is taught by several Instructors

BCNF: Decompose into (Instructor, Course) and (Student, Instructor)

50
 BCNF
• Boyce-Codd normal form (BCNF):- A relation is
in BCNF, if and only if, every determinant is a
candidate key.
• The difference between 3NF and BCNF is that
for a functional dependency A → B, 3NF allows
this dependency in a relation if B is a primary-
key attribute and A is not a candidate key,
whereas BCNF insists that for this dependency
to remain in a relation, A must be a candidate
key.
51
 LO3 Validate Data Model using
Normalization
3.1 Validating the Data Model
• Even when you have completed your data model it may not
completely reflect the system being developed. You need to
review your business rules once more to see if you have created
an accurate picture.
• Look at the example data model answer for the Painting Hire
system. The normalization process resulted in an entity called
Portfolio, with a key of Artist No, Painting No).
• Therefore, the current data model needs reviewing to prevent
multiple artists being associated with the same painting.
• This has been achieved in the revised data model. The entity
Portfolio has been deleted and replaced by a foreign key of Artist
No in the Painting entity.

52
3.4 Submitting final approval to client
• This Final Design Approval form must be submitted by
an authorized representative prior to the release of the
final project. For web development, the final design
approval form is required prior to the coding /
development stage.

53