2/13/2016

DATA MODELING

1 -- Asha Jyothi N
 2/13/2016
DATA MODELING OVERVIEW

2
WHAT IS DATA MODEL?

2/13/2016
 Definition: precise description of the data content in a
system

 Types of data models:

1. Conceptual: describes WHAT the system contains
2. Logical: describes HOW the system will be implemented,
regardless of the DBMS
3. Physical: describes HOW the system will be implemented
using a specific DBMS

3
CONCEPTUAL DATA MODEL

2/13/2016
 A conceptual data model identifies the highest-level
relationships between the different entities. Features of
conceptual data model include:
 Includes the important entities and the relationships
among them.
 No attribute is specified.

 No primary key is specified.

4
CONCEPTUAL DATA MODEL

2/13/2016
5
 LOGICAL DATA MODEL
 A logical data model describes the data in as much detail as

2/13/2016
possible, without regard to how they will be physical
implemented in the database. Features of a logical data
model include:
 Includes all entities and relationships among them.
 All attributes for each entity are specified.
 The primary key for each entity is specified.
 Foreign keys (keys identifying the relationship between different
entities) are specified.
 Normalization occurs at this level.

6
 LOGICAL DATA MODEL
 The steps for designing the logical data model are as

2/13/2016
follows:
 Specify primary keys for all entities.
 Find the relationships between different entities.
 Find all attributes for each entity.
 Resolve many-to-many relationships.
 Normalization.

7
LOGICAL DATA MODEL

2/13/2016
8
 PHYSICAL DATA MODEL
 Physical data model represents how the model will be built
in the database. Features of a physical data model include:

2/13/2016
 Specification all tables and columns.
 Foreign keys are used to identify relationships between tables.
 Denormalization may occur based on user requirements.
 Physical considerations may cause the physical data model to be
quite different from the logical data model.
 Physical data model will be different for different RDBMS. For
example, data type for a column may be different between
MySQL and SQL Server.

9
 PHYSICAL DATA MODEL
 The steps for physical data model design are as follows:

2/13/2016
 Convert entities into tables.
 Convert relationships into foreign keys.
 Convert attributes into columns.
 Modify the physical data model based on physical constraints /
requirements.

10
PHYSICAL DATA MODEL

2/13/2016
11
COMPARISON OF MODELS

2/13/2016
Feature Conceptual Logical Physical
Entity Names ✓ ✓  

Entity Relationships ✓ ✓  
Attributes   ✓  

Primary Keys   ✓ ✓

Foreign Keys   ✓ ✓

Table Names     ✓
Column Names     ✓

Column Data Types     ✓

12
ENTITY-RELATIONSHIP MODEL (ERM OR
ER MODEL)

2/13/2016
 The entity-relationship model (or ER model) is a way of
graphically representing the logical relationships of
entities (or objects) in order to create a database. 
 In ER modeling, the structure for a database is portrayed
as a diagram, called an entity-relationship diagram (or
ER diagram), that resembles the graphical breakdown of
a sentence into its grammatical parts.

13
ENTITY

2/13/2016
 An entity can be a real-world object, either animate or
inanimate, 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.

14
ENTITY SET

2/13/2016
 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.

15
 ATTRIBUTE
 Entities are represented by means of their properties,

2/13/2016
called attributes. All attributes have values.
For example, a student entity may have name, class, and
age as attributes.
 There exists a domain or range of values that can be
assigned to attributes.
For example, a student's name cannot be a numeric value. It
has to be alphabetic. A student's age cannot be negative,
etc.

16
 TYPES OF ATTRIBUTE
 Simple attribute − Simple attributes are atomic values,
which cannot be divided further.

2/13/2016
 Composite attribute − Composite attributes are made of
more than one simple attribute.
 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
 Single-value attribute − Single-value attributes contain
single value
 Multi-value attribute − Multi-value attributes may contain
more than one values.

17
ATTRIBUTE - REPRESENTATION

2/13/2016
18
 ENTITY-SET AND KEYS
 Key is an attribute or collection of attributes that uniquely

2/13/2016
identifies an entity among entity set.
For example, the roll_number of a student makes him/her
identifiable among students.
 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. 19
 ENTITY-SET AND KEYS
 Key is an attribute or collection of attributes that uniquely

2/13/2016
identifies an entity among entity set.
For example, the roll number of a student makes him/her
identifiable among students.
 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. 20
RELATIONSHIP
 The association among entities is called a relationship. For

2/13/2016
example, an employee works at a department, a
student enrolls in a course. Here, Works at and Enrolls are
called relationships.

 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.

21
RELATIONSHIP CARDINALITY
E1 E2
One-to-One

2/13/2016
1:1

E2
One-to-Many E1

1:M

Many-to-Many E2
E1

M:N 22
 RELATIONSHIP CARDINALITY
 The number of Entity Instances involved in the Relationship Instances Grouping in a
Relationship Type.

2/13/2016
 Three Forms of Cardinality

1. One-to-one (1:1)
DEPARTMENT has MANAGER
Each DEPARTMENT has one and only one MANAGER
Each MANAGER manages one and only one DEPARTMENT

2. One-to-many (1:m)
CUSTOMER places ORDER
Each CUSTOMER sometimes (95%) place one or more ORDERs
Each ORDER always is placed by exactly one CUSTOMER

3. Many-to-many (m:n)
INSTRUCTOR teaches COURSE
Each INSTRUCTION teaches zero, one, or more COURSEs
Each COURSE is taught by one or more INSTRUCTORs 23
ER DIAGRAM

2/13/2016
24
DATABASE NORMALIZATION
 The main goal of Database Normalization is to
restructure the logical data model of a database to:

2/13/2016
 Eliminate redundancy

 Organize data efficiently

 Reduce the potential for data anomalies.

25
 DATA ANOMALIES
 Data anomalies are inconsistencies in the data stored in a
database as a result of an operation such as update,

2/13/2016
insertion, and/or deletion.

 Such inconsistencies may arise when have a particular

record stored in multiple locations and not all of the copies
are updated.

 We can prevent such anomalies by implementing 7

different level of normalization called Normal Forms (NF)

 We’ll only look at the first three. 

26
BRIEF HISTORY/OVERVIEW
 Database Normalization was first proposed by Edgar F.

2/13/2016
Codd.

 Codd defined the first three Normal Forms, which

we’ll look into, of the 7 known Normal Forms.

 In order to do normalization we must know what the

requirements are for each of the three Normal Forms
that we’ll go over.

 One of the key requirements to remember is that

Normal Forms are progressive. That is, in order to
have 3rd NF we must have 2nd NF and in order to have
2nd NF we must have 1st NF. 27
1ST NORMAL FORM REQUIREMENTS

2/13/2016
 The requirements to satisfy the 1st NF:

 Each table has a primary key: minimal set of attributes

which can uniquely identify a record
 The values in each column of a table are atomic (No multi-
value attributes allowed).
 There are no repeating groups: two columns do not store
similar information in the same table.

28
1ST NORMAL FORM EXAMPLE
Un-normalized Students table:

Student# AdvID AdvName AdvRoom Class1 Class2

123 123A James 555 102-8 104-9
124 123B Smith 467 209-0 102-8

Normalized Students table:

Student# AdvID AdvName AdvRoom Class#
123 123A James 555 102-8
123 123A James 555 104-9
124 123B Smith 467 209-0
124 123B
2/13/2016 Smith 467 102-829
2ND NORMAL FORM
THE REQUIREMENTS

2/13/2016
 The requirements to satisfy the 2nd NF:
 Allrequirements for 1st NF must be met.
 Redundant data across multiple rows of a table must be
moved to a separate table.
 The resulting tables must be related to each other by use of foreign
key.

30
2ND NORMAL FORM EXAMPLE
Students table
Student# AdvID AdvName AdvRoom
123 123A James 555
124 123B Smith 467

Registration table
Student# Class#
123 102-8
123 104-9
124 209-0
124 2/13/2016 102-8 31
3RD NORMAL FORM
THE REQUIREMENTS

2/13/2016
 The requirements to satisfy the 3rd NF:
 Allrequirements for 2nd NF must be met.
 Eliminate fields that do not depend on the primary key;
 That is, any field that is dependent not only on the primary key but
also on another field must be moved to another table.

32
 3RD NORMAL FORM EXAMPLE
Students table:
Student# AdvID AdvName AdvRoom
123 123A James 555
124 123B Smith 467

Student table: Advisor table:

Student# AdvID AdvID AdvName AdvRoom
123 123A 123A James 555
124 123B 123B Smith 467
2/13/2016 33
3 NORMAL FORM EXAMPLE
CONT
Students table: Registration table:
Student# AdvID Student# Class#
123 123A 123 102-8
123 104-9
124 123B
124 209-0
124 102-8

Advisor table:
AdvID AdvName AdvRoom
123A James 555
123B Smith
2/13/2016 467 34
 2/13/2016
QUESTIONS?

35