Identify Common Data

Structures
IBM Cognos 8 BI

2008 IBM Corporation

Objectives
At the end of this module, you should be able to :
examine the characteristics of operational
databases and databases designed for reporting
examine relationships and cardinality
identify different data traps
examine OLAP data sources
Examine the Role of an IBM Cognos 8
Metadata Model
An IBM Cognos 8 metadata model provides a business
presentation view of an organizations data sources.
BI users use the model to analyze and report on their data
sources.
Reporting Layer

IBM Cognos 8 Metadata Model

Relational Files Other

Cubes
Distinguish Between Operational and
Reporting Databases
Relational databases are typically either:
Operational Reporting
Customer Sales Product
Type Area Line Sales
1..1 1..1 1..1 Rep
1..1
1..n 1..n 1..n
0..n

Customer Sales Product 1..1 Order 1..1

Rep Type Customer 0..n Fact 0..n Product
1..1 1..1 1..1
0..n
1..n 1..n 1..1

Order Product
1..n
Header Date
1..1 1..1
1..n

Order
Detail 1..n
Identify Features of an Operational Database
Operational databases:
are designed to maximize accuracy and minimize
redundancy
are optimized for writing and updating data rather
than reading data
often result in monolithic designs with multiple
joins
Large queries can perform slowly.
Identify Issues with Operational Databases
Show all customer types Customer Sales Product
that bought from a product Type Area Line
1..1 1..1 1..1
line. 1..n 1..n 1..n

The query must check data Customer Sales

Rep
Product
Type
in seven tables before 1..1 1..1 1..1

returning a result set.

0..n 1..n

Order Product
0..n
Header
1..1 1..1
1..n

Order
Detail 0..n

Query requires 7 tables

Examine Reporting Databases
(Star Schema Design)
Transactional data is stored in a fact table
Reference data is stored in separate dimension tables
Sales
Rep
1..1
0..n

Customer
1..1 Order 1..1
0..n Fact 0..n Product
0..n
1..1

Date

Query only requires 3 tables

Create a Star Schema
Collapse the relationships to form dimensions
(perspectives). Customer Sales Product
Type Area Line
1..1 1..1 1..1

1..n 1..n 1..n

Sales Product
Customer Rep Type
1..1 1..1 1..1
Sales
Rep 0..n 1..n

1..1 Order
0..n
0..n
Header Product
1..1 Order 1..1 1..1 1..1
Customer 0..n Fact 0..n Product 1..n

0..n
1..1 Order
Detail 0..n

Date
Examine Operational Data
Data is normalized
Product Line Table Product Type Table Product Table

PL# PL_Desc PL# PT# PT_Desc PT# Prod# Prod_Desc

a Classic Tents a 1 Pup Tents 1 101 1 Sleeper
b Moose Boots a 2 Family Tents 1 102 2 Sleeper
2 rows b 11 Child Boots 2 201 4 Sleeper
b 12 Adult Boots 2 203 6 Sleeper
4 rows 11 1101 Wet Proof
12 1102 Hikers+
6 rows
Before collapsing into a star schema dimension
Examine Reporting Data
Data is de-normalized
Product Dimension Table

PL# PL_Desc PT# PT_Desc Prod# Prod_Desc

A Classic Tents 1 Pup Tents 101 1 Sleeper
A Classic Tents 1 Pup Tents 102 2 Sleeper
A Classic Tents 2 Family Tents 201 4 Sleeper
A Classic Tents 2 Family Tents 203 6 Sleeper
B Moose Boots 11 Child Boots 1101 Wet Proof
B Moose Boots 12 Adult Boots 1102 Hikers
6 rows

After collapsing into a star schema dimension

Examine Fact Tables
Fact tables contain the (usually additive) values by
which a company measures itself:
Standard Selling Price - not additive
Sale Amount - additive

Dimension Tables
Fact Table Product

Sales Revenue
Measures Quantity
. Customer
Product Key
Foreign Keys Customer Key
Time Key Time
Examine Dimension Tables
Dimension tables provide descriptive information.
Dimension tables may be conformed so that they
are applicable to multiple fact tables across the
business. Dimension Dimension
Product Warehouse
Fact Fact
Sales Inventory

Dimension Dimension
Customer Time

Conformed Dimensions
Identify Issues with a Star Schema
Data is only as current as the last data load.
Structural issues:
the distinct count problem
very large dimension tables
snowflakes
Fact issues:
different levels of granularity (detail) in fact tables
Define Relationships
Specify how data in one table is linked to data in
another table.
Relationships are implied in the physical data
(modeler explicitly declares these relationships)
Modeler formulates the reality of the business by
configuring the relationships
Examine Relationships: Cardinality
1..1 Security One-to-One: One employee
Employee
1..1 Number holds exactly one security
number.

One-to-Many: Each order

Order 1..1 Order
Header 1..n Details header must have one or more
order details.

Many-to-Many: Each part may

1..n be provided by many
Part Supplier
1..n suppliers, and each supplier
may provide many parts.
Examine Relationships:
Optional vs. Mandatory
Relationships may be mandatory or optional.
For example, a product may exist even if it has not
been ordered, but an order must refer to at least
one existing product.
It is important to determine if certain relationships
are optional.
For example, is there a reporting requirement to
list sales representatives who have sold nothing?
Examine Relationships: Data Traps
There are four basic data traps:
chasm trap (many-to-many relationship)
transitive relationship trap (more than one path
between two tables)
connection trap (an optional path through
different entities)
fan trap (multiple one-to-many relationships that
fan out from a single table)
Examine Chasm Traps
Many-to-many relationship
Structure cannot record and maintain data (it lets
the information fall into a chasm)
Not incorrect when designing at a high level (it just
does not show all the necessary details)

Which suppliers
1..n
Supplier Part provide which
1..n
specific parts?
Examine Transitive Relationships
Exists if there is more than one path between two
tables

1..1
Customer 0..n
Order

1..1 1..1 Can an order exist

Can a customer without an order
1..n
exist without an detail?
order detail? 0..n Order
Detail

Which relationship is redundant: the one

between Customer and Order Detail, or the one
between Order and Order Detail?
Examine Fan Traps
Identified by multiple one-to-many relationships that
fan out from a single table

1..1 1..1
Division

1..n 1..n

Branch Employee

Is there a direct relationship between Branch and Employee?

Examine Connection Traps
Is there an optional path through different entities?
There must be a reliable path through all truly related
entities

What is the relationship between Branch and Employee?

If an employee does not work for a branch, do they

work for a division?

1..1 1..1
Division 1..n
Branch 1..n
Employee

1..1 1..n

???
Examine OLAP Data Structures
Products
Order Methods Camping Equipment

Golf Equipment
Fax Cell
Dimension
Outdoor Protection
Telephone
Mountaineering
Members Mail Equipment

E-Mail Personal Accessories

Jan Feb ... Web

Q1 Q2 ...
2005 2006 ... Start End
April 1 June 30
Time
Attributes
Hierarchy/Levels 2005 Q1 Q2 Q3 Q4
Identify Data Access Strategies
Consider using a cube to analyze data sets that are
not prohibitively large.
Consider creating a star schema to improve
performance over an operational system.
If you need to access live data, you may have no
choice but to go with an operational system.
Summary
At the end of this module, you should be able to :
examine the characteristics of operational
databases and databases designed for reporting
examine relationships and cardinality
identify different data traps
examine OLAP data sources