Dimension Table

Dimension table is one that describe the business entities of an enterprise,

represented as hierarchical, categorical information such as time,
departments, locations, and products. Dimension tables are sometimes called
lookup or reference tables.
Location Dimension
In a relational data modeling, for normalization purposes, country lookup, state
lookup, county lookup, and city lookups are not merged as a single table. In a
dimensional data modeling(star schema), these tables would be merged as a
single table called LOCATION DIMENSION for performance and slicing data
requirements. This location dimension helps to compare the sales in one
region with another region. We may see good sales profit in one region and
loss in another region. If it is a loss, the reasons for that may be a new
competitor in that area, or failure of our marketing strategy etc.

What is Star Schema?

Star Schema is a relational database schema for representing multimensional
data. It is the simplest form of data warehouse schema that contains one or
more dimensions and fact tables. It is called a star schema because the entity-
relationship diagram between dimensions and fact tables resembles a star
where one fact table is connected to multiple dimensions. The center of the
star schema consists of a large fact table and it points towards the dimension
tables. The advantage of star schema are slicing down, performance increase
and easy understanding of data.
Steps in designing Star Schema

• Identify a business process for analysis(like sales).

• Identify measures or facts (sales dollar).
• Identify dimensions for facts(product dimension, location dimension, time
dimension, organization dimension).
• List the columns that describe each dimension.(region name, branch
name, region name).
• Determine the lowest level of summary in a fact table(sales dollar).
Fact Table
A table in a star schema that contains facts and connected to dimensions. A
fact table typically has two types of columns: those that contain facts and
those that are foreign keys to dimension tables. The primary key of a fact table
is usually a composite key that is made up of all of its foreign keys.
A fact table might contain either detail level facts or facts that have been
aggregated (fact tables that contain aggregated facts are often instead called
summary tables). A fact table usually contains facts with the same level of
aggregation.
Example of Star Schema: Figure 1.6

In the example figure 1.6, sales fact table is connected to dimensions location,
product, time and organization. It shows that data can be sliced across all
dimensions and again it is possible for the data to be aggregated across
multiple dimensions. "Sales Dollar" in sales fact table can be calculated across
all dimensions independently or in a combined manner which is explained
below.

• Sales Dollar value for a particular product

• Sales Dollar value for a product in a location
• Sales Dollar value for a product in a year within a location
• Sales Dollar value for a product in a year within a location sold or serviced
by an employee

Snowflake Schema
A snowflake schema is a term that describes a star schema structure
normalized through the use of outrigger tables. i.e dimension table hierachies
are broken into simpler tables.
In Snowflake schema, the example diagram shown below has 4 dimension
tables, 4 lookup tables and 1 fact table. The reason is that
hierarchies(category, branch, state, and month) are being broken out of the
dimension tables(PRODUCT, ORGANIZATION, LOCATION, and TIME)
respectively and shown separately. In OLAP, this Snowflake schema approach
increases the number of joins and poor performance in retrieval of data. In few
organizations, they try to normalize the dimension tables to save space. Since
dimension tables hold less space, Snowflake schema approach may be
avoided.

Example of Snowflake Schema: Figure 1.7

Business Intelligence:
Business Intelligence is a technology based on customer and profit oriented
models that reduces operating costs and provide increased profitability by
improving productivity, sales, service and helps to make decision making
capabilities at no time. Business Intelligence Models are based on multi
dimensional analysis and key performance indicators (KPI) of an enterprise.
Business Intelligence applications that are based on Business Intelligence
Models are created by Business Intelligence software which provides the
aggregated details about suppliers, customers, internal activities, business to
business transactions to the managers or whoever needs it to take better
corporate decisions.

What is a Dashboard in Business terms?

A Business Intelligence Dashboard visually represents the key organizational

performance data in a near real time, user friendly manner that can be
understood instantaneously. Technically speaking, a Dashboard is a visual
representation that reflects the Key Performance Indicators(KPIs) of interest for
managerial review and not only that it enables them to drill-down further.
Business Intelligence Dashboard is similar in function to a car dashboard in
that it displays and provides access to the powerful analytical systems and
key performance metrics in a form enabling business executives to analyze
trends and more effectively manage their areas of responsibility

Features of Dashboard:

A typical web based Business Intelligence Dashboard encompasses the

following features:

• Web based Interface: Managers can gain broad visibility into the
real-time key measurements of a business with the help of this multi-
window, intuitive and interactive interface.
• Role Based View: Executives can clearly track their
organization's overall performance against its goals.
• Reports: Configurable, user-level as well as management-level
reports.
• Charting and Graphing: Dashboards are better known for their
easy one-click charts and graphs that gives instant access to complex
solutions.
• Pre-defined Performance Metrics: All the Dashboards are built
with the common pre-defined metrics by default which eases the
business user in tracking the regular yet important performance
metrics.

ETL Process:
ETL, an acronym for 'Extraction, Transformation and Loading' is a collection
of processes associated with extracting the source data, transforming that
data and finally loading that data into a data warehouse. Before loading the
required into data warehouse, it should be transformed in order to meet the
needs of the data warehouse. This transformation involves several
processes like data cleansing, data profiling, data type conversion, validating
for referential integrity, performing aggregation if needed, denormalization
and normalization.

Data Warehouse:

Data warehouse is a centralized repository where all the information for

analysis is kept in an organization. This is the data collected from variant
sources for the purpose of analytical processing and reporting. This data is
non-volatile and a data warehouse is built on a dimensional data model.
From this data warehouse, data can be extracted for reporting needs with
the help of query tools or many data marts can be built based on subject
area requirements.

Data Mart:

Data Mart is subject oriented, basically a sub-set of data warehouse, built for
the purpose of analyzing a particular line of business or department. It holds
the data specific to a particular subject area like sales, purchase etc. Data
marts can be of derived from a data warehouse or built for the sole purpose
of BI directly from the source and like data warehouse, data marts are also
constructed from dimensional data models.

Dimensional Modeling:

Dimensional Model comprises a fact table and many dimension tables and is
used for calculating summarized data. Since Business Intelligence reports
are used in measuring the facts(aggregates) across multiple dimensions,
dimensional data modeling is the prefered modeling technique in a BI
environment. A Fact table contains various measures or facts like sales
amount, loan amount etc., whereas a Dimension table describes the
particular entity like time, state etc., based on which the required facts are
measured

What is OLAP?
OLAP, an acronym for 'Online Analytical Processing' is a technique by which
the data sourced from a data warehouse or data mart is visualized and
summarized to provide perspective multidimensional view across multiple
dimensions. Generally OLAP refers to OLAP Tools(e.g Cognos, Business
Objects etc.,) that help to accomplish these tasks. Since data warehouse is
designed using a dimensional data model, data is represented in the form of
data cubes enabling us to aggregate facts, slice and dice across several
dimensions. OLAP tools provide options to drill-down the data from one
hierarchy to another hierarchy.

For example sales amount can be calculated for a particular year or it can be
drilled down to its next hierarchies like month, week, day etc. In the same
way, data can be rolled up for summarization from product to product group,
product group to product sub-class then from product sub-class to product
class. Thus with this cube structure, data can be viewed from multiple points
providing the data analysts, a greater insight into data.

===============

Relational Data Modeling is used in OLTP systems which are transaction

oriented and Dimensional Data Modeling is used in OLAP systems which are
analytical based. In a data warehouse environment, staging area is designed
on OLTP concepts, since data has to be normalized, cleansed and profiled
before loaded into a data warehouse or data mart. In OLTP environment,
lookups are stored as independent tables in detail whereas these
independent tables are merged as a single dimension in an OLAP
environment like data warehouse.

Materialized views

Materialized views are a data warehousing/decision support system tool that

can increase by many orders of magnitude the speed of queries that access
a large number of records. In basic terms, they allow a user to query
potentially terabytes of detail data in seconds. They accomplish this by
transparently using pre-computed summarizations and joins of data. These
pre-computed summaries would typically be very small compared to the
original source data.

There is one mandatory INIT.ORA parameter necessary for materialized views

to function, this is the COMPATIBLE parameter. The value of COMPATIBLE
should be set to 8.1.0, or above, in order for query rewrites to be functional. If
this value is not set appropriately, query rewrite will not be invoked.

There are two other relevant parameters that may be set at either the system-
level via the INIT.ORA file, or the session-level via the ALTER SESSION
command.

o QUERY_REWRITE_ENABLED

Unless the value of this parameter is set to TRUE, query rewrites will not take
place. The default value is FALSE.

o QUERY REWRITE INTEGRITY

This parameter controls how Oracle rewrites queries and may

be set to one of three values:

ENFORCED - Queries will be rewritten using only constraints and rules that
are enforced and guaranteed by Oracle. There are mechanisms by which we
can tell Oracle about other inferred relationships, and this would allow for more
queries to be rewritten, but since Oracle does not enforce those relationships,
it would not make use of these facts at this level.

TRUSTED - Queries will be rewritten using the constraints that are enforced by
Oracle, as well as any relationships existing in the data that we have told
Oracle about, but are not enforced by the database.

STALE TOLERATED - Queries will be rewritten to use materialized views even

if Oracle knows the data contained in the materialized view is ' stale ' (out-of-
sync with the details). This might be useful in an environment where the
summary tables are refreshed on a recurring basis, not on commit, and a
slightly out-of-sync answer is acceptable.

The needed privileges are as follows:

1. CREATE SESSION
2. CREATE TABLE
3. CREATE MATERIALIZED VIEW
4. QUERY REWRITE