0% found this document useful (0 votes)
530 views5 pages

Star Schema

A star schema organizes data into fact and dimension tables. Fact tables contain measurable facts like sales and dimensions contain descriptive attributes like date, item, customer. The schema gets its name from its visual representation as points (dimensions) extending from a central fact table. Key advantages are fast query performance, ease of use, and referential integrity between tables. However, some relationships like many-to-many cannot be modeled in a star schema.

Uploaded by

rr4wn7e9nk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
530 views5 pages

Star Schema

A star schema organizes data into fact and dimension tables. Fact tables contain measurable facts like sales and dimensions contain descriptive attributes like date, item, customer. The schema gets its name from its visual representation as points (dimensions) extending from a central fact table. Key advantages are fast query performance, ease of use, and referential integrity between tables. However, some relationships like many-to-many cannot be modeled in a star schema.

Uploaded by

rr4wn7e9nk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

A star schema is the elementary form of a dimensional model, in which data are

organized into facts and dimensions. A fact is an event that is counted or measured,


such as a sale or log in. A dimension includes reference data about the fact, such as
date, item, or customer.

A star schema is a relational schema where a relational schema whose design


represents a multidimensional data model. The star schema is the explicit data
warehouse schema. It is known as star schema because the entity-relationship
diagram of this schemas simulates a star, with points, diverge from a central table.
The center of the schema consists of a large fact table, and the points of the star are
the dimension tables.

Fact Tables
A table in a star schema which contains facts and connected to dimensions. A fact
table has two types of columns: those that include fact and those that are foreign
keys to the dimension table. The primary key of the fact tables is generally a
composite key that is made up of all of its foreign keys.
A fact table might involve either detail level fact or fact that have been aggregated
(fact tables that include aggregated fact are often instead called summary tables). A
fact table generally contains facts with the same level of aggregation.

Dimension Tables
A dimension is an architecture usually composed of one or more hierarchies that
categorize data. If a dimension has not got hierarchies and levels, it is called a flat
dimension or list. The primary keys of each of the dimensions table are part of the
composite primary keys of the fact table. Dimensional attributes help to define the
dimensional value. They are generally descriptive, textual values. Dimensional tables
are usually small in size than fact table.

Fact tables store data about sales while dimension tables data about the geographic
region (markets, cities), clients, products, times, channels.

Characteristics of Star Schema


The star schema is intensely suitable for data warehouse database design because of
the following features:

o It creates a normalized database that can quickly provide query responses.


o It provides a flexible design that can be changed easily or added to throughout the
development cycle, and as the database grows.
o It provides a parallel in design to how end-users typically think of and use the data.
o It reduces the complexity of metadata for both developers and end-users.

Advantages of Star Schema


Star Schemas are easy for end-users and application to understand and navigate.
With a well-designed schema, the customer can instantly analyze large,
multidimensional data sets.

The main advantage of star schemas in a decision-support environment are:


Query Performance
A star schema database has a limited number of table and clear join paths, the query
run faster than they do against OLTP systems. Small single-table queries, frequently
of a dimension table, are almost instantaneous. Large join queries that contain
multiple tables takes only seconds or minutes to run.

In a star schema database design, the dimension is connected only through the
central fact table. When the two-dimension table is used in a query, only one join
path, intersecting the fact tables, exist between those two tables. This design feature
enforces authentic and consistent query results.

Load performance and administration


Structural simplicity also decreases the time required to load large batches of record
into a star schema database. By describing facts and dimensions and separating
them into the various table, the impact of a load structure is reduced. Dimension
table can be populated once and occasionally refreshed. We can add new facts
regularly and selectively by appending records to a fact table.
Built-in referential integrity
A star schema has referential integrity built-in when information is loaded.
Referential integrity is enforced because each data in dimensional tables has a
unique primary key, and all keys in the fact table are legitimate foreign keys drawn
from the dimension table. A record in the fact table which is not related correctly to a
dimension cannot be given the correct key value to be retrieved.

Easily Understood
A star schema is simple to understand and navigate, with dimensions joined only
through the fact table. These joins are more significant to the end-user because they
represent the fundamental relationship between parts of the underlying business.
Customer can also browse dimension table attributes before constructing a query.

Disadvantage of Star Schema


There is some condition which cannot be meet by star schemas like the relationship
between the user, and bank account cannot describe as star schema as the
relationship between them is many to many.

Example: Suppose a star schema is composed of a fact table, SALES, and several


dimension tables connected to it for time, branch, item, and geographic locations.

The TIME table has a column for each day, month, quarter, and year. The ITEM table
has columns for each item_Key, item_name, brand, type, supplier_type. The BRANCH
table has columns for each branch_key, branch_name, branch_type. The LOCATION
table has columns of geographic data, including street, city, state, and country.
In this scenario, the SALES table contains only four columns with IDs from the
dimension tables, TIME, ITEM, BRANCH, and LOCATION, instead of four columns for
time data, four columns for ITEM data, three columns for BRANCH data, and four
columns for LOCATION data. Thus, the size of the fact table is significantly reduced.
When we need to change an item, we need only make a single change in the
dimension table, instead of making many changes in the fact table.

You might also like