Data Analysts, Data Trending, Reporting » Operational Databases Vrs Business Intelligence

Star Schema – Fact table a closer look

admin — Wed, 28 Apr 2010 04:29:39 +0000

In this post we are writing more on factt table in star schema because we believe that clear concept of fact table and its creation is critical to understand the difference between OLTP Relational Database’s logical model and then its de-normalization to create Star schema, which have fact table in the centre.

We found some useful writings on fact table its creation and in-depth analyses of the same. Please read these and add more about your view to help other readers to clearly understand the process of denormalization for star schema. Now lets enjoy what has been written about star schema;

The star schema is data modeling technique used to map decision support data into relational database. In effect, the star schema creates near equivalent of multidimensional database schema from the existing relational database. The star Schema was develop because existing relational modeling technique, ER and normalization did not yield database structure that served advance data analysis requirements well.
Star schema yield an easily implemented model for multidimensional data analysis while still preserving the relational structure on which the operation database is built. The basic star schema has four components : facts, dimensions, attributes and attributes hierarchies.[1]

Massive De-normalization: STAR Schema Design

The STAR schema design was first introduced by Dr. Ralph Kimball as an alternative database design for data warehouses. The name STAR comes directly from the design form, where a large fact table resides at the center of the model surrounded by various points, or reference tables.

The basic principle behind the STAR query schema is the introduction of highly redundant data for high performance. With a STAR schema, the designer can simulate the functions of a multidimensional database without having to purchase expensive third-party software. Kimball describes de-normalization as the pre-joining of tables, such that the runtime application does not have to join tables.

At the heart of the STAR schema, the fact table is usually comprised entirely of key values and raw data. A fact table is generally very long and may have millions of rows.

At first glance, it is hard to believe that this representation contains the same data as the fully normalized database. The new fact table will contain one row for each item on each order, resulting in a tremendous amount of redundant key information. Of course, the STAR query schema is going to require far more disk space than the 3NF database.

The STAR schema would most likely be a read-only database due to the widespread redundancy introduced into the model. Also, the widespread redundancy would make updating difficult, if not downright impossible. [2]
Source:
1- By Peter Rob, Carlos Coronel, Keeley Crockett – Database Systems
2- 2- Oracle Data Warehouse Tips by Burleson Consulting

See an Example on this topic

Process From OLTP datamodel to Olap DataModel

admin — Thu, 22 Apr 2010 04:29:28 +0000

This present s an example showing the process to denormalization for dataware house or data mart
Star schema. We researched on this topic in various books and even Microsoft examples they only give sample, but we think it is more important to know how oltp data model is converted in Star schema or olap.
We used Microsoft’s Northwind data model in oltp datamodel, created a query to populate our fact table with measure data i.e unit price quantity and discount alongwith foriegn keys from the related dimensions.
Query code used in DTS with SQL Server 2000 to create new table in Northwind_fact table.
You will notice in fact table that there foreign keys for the dimension tables like Employee, product, region and suppliers. The above picture shows design of OLTP Vrs OLAP. We will eloberat more on this topic from our search and experiance but will appreciate to correct us or add more to make it easier to understand as now days in many job interviews question like data warehousing, datamodeling cocepts asked and so more we discuss the topic more we will be well equiped to tacle the questions as well help for newcommers.
——————————————————————————————————
SELECT dbo.[Order Details].OrderID, dbo.[Order Details].ProductID, dbo.[Order Details].UnitPrice, dbo.[Order Details].Quantity, dbo.[Order Details].Discount,
dbo.Orders.CustomerID, dbo.Orders.EmployeeID, dbo.Orders.OrderDate, dbo.Orders.Freight, dbo.EmployeeTerritories.TerritoryID,
dbo.Territories.RegionID, dbo.Shippers.ShipperID, dbo.Categories.CategoryID, dbo.CustomerCustomerDemo.CustomerTypeID,
dbo.Suppliers.SupplierID
FROM dbo.Employees FULL OUTER JOIN
dbo.EmployeeTerritories FULL OUTER JOIN
dbo.Region FULL OUTER JOIN
dbo.Territories ON dbo.Region.RegionID = dbo.Territories.RegionID ON dbo.EmployeeTerritories.TerritoryID = dbo.Territories.TerritoryID ON
dbo.Employees.EmployeeID = dbo.EmployeeTerritories.EmployeeID FULL OUTER JOIN
dbo.Customers INNER JOIN
dbo.Orders ON dbo.Customers.CustomerID = dbo.Orders.CustomerID FULL OUTER JOIN
dbo.CustomerCustomerDemo ON dbo.Customers.CustomerID = dbo.CustomerCustomerDemo.CustomerID FULL OUTER JOIN
dbo.CustomerDemographics ON dbo.CustomerCustomerDemo.CustomerTypeID = dbo.CustomerDemographics.CustomerTypeID FULL OUTER JOIN
dbo.Shippers ON dbo.Orders.ShipVia = dbo.Shippers.ShipperID ON dbo.Employees.EmployeeID = dbo.Orders.EmployeeID FULL OUTER JOIN
dbo.Categories FULL OUTER JOIN
dbo.[Order Details] FULL OUTER JOIN
dbo.Products ON dbo.[Order Details].ProductID = dbo.Products.ProductID FULL OUTER JOIN
dbo.Suppliers ON dbo.Products.SupplierID = dbo.Suppliers.SupplierID ON dbo.Categories.CategoryID = dbo.Products.CategoryID ON
dbo.Orders.OrderID = dbo.[Order Details].OrderID

Difference between operational databases and Business Intelligence

admin — Sat, 13 Jun 2009 03:18:05 +0000

1- Operational databases are design to remove redundancy, accurate updates and removal of repetitive operations for example deposits, flight reservation. Business intelligence has the goal of business reporting and data analyses.

2- Operational data bases are highly normalized in relational database format to facilitate data update. Business intelligence databases are highly demoralized for fast retrieval and analyses of large amount of data.

3- In operational databases most of the data is raw and stored without any calculations, calculations are usually done when required through queries. In business intelligence large amount of data is pre-calculated or derived to save time when running queries.

The above are few general difference between Business intelligence and operational databases, we are keep researching and will update more.