Data Modeling for

Business
Intelligence
Lesson 4: Logical Model
Lesson Objectives

On completion of this lesson, you will be able to:

Define logical model
List features of a logical model
Name the transformations required to be done while
converting a conceptual model into a logical model
Identify activities involved in those transformations
Name the types of attributes which do not get converted into
a single column in the logical model
Data modeling tools

2
4.1: Introduction

Introduction to Logical Model

A logical model is produced from a set of well-defined

transformations of the conceptual data model.
The logical data model reflects business information requirements
without considering performance.
If the database is ported to another DBMS supporting a similar
structure, the logical data model can still be used as a baseline for
the new physical data model.

3
4.2: Features of a Logical Model

Characteristics of a Logical Model

Logical model works in an iterative manner.

Its design is independent of database.
It 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.

4
4.3: Requisite Transformations

Transformation Required

While converting a conceptual model into a logical model, following

transformations are required to be performed:

Transformations

Primary Foreign
Table Column
Key Key
Specification Specification
Specification Specification

5
4.3: Table Specification

Activities in Table Specification

In general, each entity class in the conceptual data model becomes

a table in the logical data model and is given a name that
corresponds to that of the source entity class

6
4.4: Types of Relationships

One-to-many and Many-to-one Relationships

An Employee works only for one dept

A Dept has many employees

10
4.4: Types of Relationships

One-to-One Relationship Implementation

A one-to-one relationship can be supported in a relational database

by implementing both entity classes as tables, then using the same
primary key for both.

11
4.4: Types of Relationships

Many-to-Many Relationship

An Employee works in Multiple projects

A project has multiple employees

12
4.4: Types of Relationships

Resolving Many-to-Many Relationship

EMPLOYEE PROJECT

Resolved Many-To-Many Relationship

Belong PROJECT
EMPLOYEE assigned ASSIGNEMENT
to

has

(Association)

Data model should not contain an unresolved many-to-many

relationship

13
4.5: Logical Model an Example

Logical Model: Example

14
Exercise 1

Scenario
Industry: Automobile manufacturing
Company: Millennium Motors
Value chain focus: Sales
Sample business questions:
What are the top 10 selling car models this month?
How do this months top 10 selling models compare to the top 10 over the last six
months?
Show me dealer sales by region by model by day
What is the total number of cars sold by month by dealer by state?
List facts and dimensions

15
Exercise 1 Solution

Facts
Sales revenue
Quantity sold

Dimensions
Model name
Month
Dealer name
Region
State
Date

16
Example Fact Table

Sales Facts
model_key
dealer_key
time_key

revenue
quantity

17
Example Fact Table Records

Sales Facts
time_key model_key dealer_keyrevenue quantity
1 1 1 75840.27 2
1 2 1 152260.37 3
1 3 1 28360.15 1
1 4 1 132675.22 4
1 5 1 43789.45 1
1 1 2 35678.98 1
1 3 2 57864.78 2
1 5 2 92876.67 2

Primary Key Facts

18
Facts

Fully additive
Can be summed across any and all dimensions
Stored in fact table
Time
Examples: revenue, quantity time_key

year
Model
Sales Facts quarter
model_key
model_key month
dealer_key date
brand
category time_key
line
model revenue
quantity

Dealer
dealer_key

region
State city dealer

19
Facts

Semi-additive
Can be summed across most dimensions but not all
Examples: Inventory quantities, account balances, or personnel counts
Anything that measures a level
Must be careful with ad-hoc reporting
Often aggregated across the forbidden dimension by averaging
Time
Model Sales Facts
time_key
model_key model_key
year
brand dealer_key
quarter
category time_key
month
line
date
model inventory

Dealer
dealer_key region
State city dealer

20
Facts

Non-Additive
Cannot be summed across any dimension
All ratios are non-additive
Break down to fully additive components, store them in fact table
Model Sales Facts time_key Time
model_key model_key
dealer_key year
time_key quarter
brand
month
category
revenue date
line
model margin_amt Dealer
dealer_key
region
Margin_rate is non-additive State city
Margin_rate = margin_amt/revenue dealer

21
Unit Amounts

Unit price, Unit cost, etc.

Are numeric, but not measures
Store the extended amounts which are additive
Unit amounts may be useful as dimensions for price point analysis
May store unit values to save space
Factless Fact Table
A fact table with no measures in it
Nothing to measure...
except the convergence of dimensional attributes
Sometimes store a 1 for convenience
Examples: Attendance, Customer Assignments, Coverage

22
Example Dimension Table Records

Dealer Dimension

dealer_key region state city dealer

1 Northeast Massachusetts Boston Honest Ted's
2 Northeast Massachusetts Boston Stoller Co.
3 Southwest Arizona Tucson Wright Motors
12 Southwest California San Diego American
245 Central Illinois Chicago Lugwig Motors

Synthetic Key Attributes

23
Dimension Tables

Characteristics
Hold the dimensional attributes
Usually have a large number of attributes (wide)
Add flags and indicators that make it easy to perform specific types of reports
Have small number of rows in comparison to fact tables (most of the time)
Dont normalize dimension table
Saves very little space
Impacts performance
Can confuse matters when multiple hierarchies exist
A star schema with normalized dimensions is called a "snowflake schema"
Usually advocated by software vendors whose product require snowflake for
performance

24
4.6: Logical Model

Logical Data Design

Feature Conceptual Logical Physical

Entity Names

Entity Relationships

Attributes

Primary Keys

Foreign Keys

Table Names

Column Names

Column Data Types

25
Data modeling TOOLS

ERwin Data Modeler

Sybase PowerDesigner
Database Workbench
MagicDraw
Microsoft SQL Server Management Studio

26
Summary

In this lesson, you have learnt that:

A logical model is produced from a set of well-defined
transformations of the conceptual data model.
While converting a conceptual model into a logical model,
some transformations, such as table and column
specifications, are required to be performed.
Except a few, each attribute of a conceptual model gets
converted into a column in logical model.
Additional columns are needed to support maintenance or
operations-related data.

27
Review Question

Question 1: The design of Logical Model is

dependent on database.
True/False

Question 2: Surrogate /Synthetic Keys are

introduced in the Conceptual Model.
True/False

28