Normalized (3NF) VS Denormalized(Star Schema) Data warehouse :

what are the benefits of normalized data warehouse (3NF) over the denormalized (Star schema)?
if DW is in the 3NF then is need to create the seprate physical database which contains several data marts( star schema)with physical tables, which feeds to cube or create the views(SSAS data source view) on top of 3NF warehouse of star schema which feeds to
cube?
please explin the pros and cons of 3NF and denormalized DW.
thanks in advance.
Zaim Raza.

Hi Zaim,
Take a look to this diagram:
1) Normally, 3NF schema is typical for ODS layer, which is simply used to fetch data from sources, generalize, prepare, cleanse data for upcoming load to data warehouse.
2) When it comes to DW layer (Data Warehouse), data modelers general challenge is to build historical data silo.
Star schema with slow changing facts and slow changing dimensions are partially suitable.
The DataVault and other similar specialized methods provides, in my opinion, wider possibility and flexibility.
3) Star schema is perfectly suitable for datamarts. SQL Server 2008 and higher contains numerous query analyzer improvements to handle such workload efficiently. SQL Server 2012 introduced column stored indexes, that makes possibility to
create robust star model datamarts with SQL Query performance comparable to MS OLAP.
So, your choice is:
1) Create solid, consistent DW solution
2) Create separate datamarts on top of DW for specific business needs.
3) Create necessary indexes, PK, FK key and statistics (of FK in fact tables) to help sql optimizer as much as possible.
4) Forget about approach of defining SSAS datasource view on top of 3NF (or any other DWH modeling method), since this is the way to performance and maintenance issues in the future.

Similar Messages

Is the OBIEE used to create a data warehouses dynamically?

Management where I work wants to use the OBIEE Administrator to source a 3NF normalized database and create a "virtual data warehouse" in the Business Modeling Mapping layer of OBI Administrator as a Star Schema model is required by OBI Business Model layer. They claim they were told by an Oracle sales rep that the Administrator tool could do this.
Is this possible? As OBI issues only SQL and not PL/SQL how can one "create" dimensions, lookup tables and fact tables dynamically? And even if it could the performance hit to recreate the virtual data warehouse each time a query is issued would be huge.
Having used Prism Warehouse Builder and DataStage in the past to create data warehouses I am aware that one needs a procedural programming language to create and maintain the star schema tables (surrogate key maintenance, controling workflows, maintaining slowly changing dimensions, intermediate lookup tables, etc.). SQL was not meant to do this heavy lifting programming. Afterall, isn't this why Oracle Warehouse Builder and previously Informatica is shipped with OBIEE suite because OBI is not an ETL tool to create dimensional models? One uses an ETL tool to create the dimensional data model for OBI to access and pass along the metadata to OBI Answers.
So is it normal practice to use the Administrator's Business Mapping/Modeling layer for creating a virtual star schema logical tables from physical tables that are 3NF? Or is the tool used to access already denormalized tables in the physical layer that were created using Informatica or OWB or other ETL tool?

I asked an "Expert" in OBIEE. Here are snippets of his response:
"Be aware though that the transformation ability is fairly limited, and
will only really work with data that is very close to a star schema, i.e.
the data can be easily transformed through a couple of denormalizations and
table joins. If your source data is very normalized and cannot easily be
transformed into a star schema, you would need to use a tools such as
Informatica, OWB or similar to extract data from your source systems, load
and then transform it into a data warehouse or data mart and report of of
that. The more that your data needs to be transformed (i.e. the closer it
is to a 3NF model) the more likely it is that you'll need to use an ETL
tool, and a data warehouse or data mart, to host your data."
And in response to my noting the lack of documentation on how to model a 3NF to Star Schema his response was:
"No, you're right, the documentation doesn't really go into "how to" turn a 3NF model into a dimensional model. If you look back to when OBIEE was a Siebel product, the documentation was really aimed at either Siebel consultants or customers who had been on the training, they didn't want customers "off the street" to try and implement OBIEE as it would hit their services revenue. That's where the blog posts we do, things like the Oracle-by-example training courses on OTN and so on come in, otherwise as you say there's little out there on the best way to transform your model - it's mostly passed on "word of mouth" or is built up from experience on working on projects."

Star schema or Snowflake schema

Hi Gurus,
I have following dimensions and fact table. let me know can I go ahead with star schema and snowflake schema while building the cube.
1. Country's table
2. workgroup table --> each country have N number of work groups
3. user table---> each workgroup have N number of users.
4. time table.
5. fact table.

This is a similar thread that discusses on the design approach of star vs normalized tables
https://social.technet.microsoft.com/Forums/sqlserver/en-US/7bf4ca30-a1bc-415d-97e6-ce0ac3137b53/normalized-3nf-vs-denormalizedstar-schema-data-warehouse-?forum=sqldatawarehousing
In my experience majority of cases I've some across is also star schema for data marts where tables will be more denormalized rather than applying priciples of normalization. And I believe so far as its through SSAS cubes that you exposes the OLAP model
it would be much easier to implement relationships using a denormalised approach.
What you may do is to have a normalised datawarehouse if you want and then built the datamarts over it using denormalised tables (star schema) for the cube.
Please Mark This As Answer if it solved your issue
Please Vote This As Helpful if it helps to solve your issue
Visakh
My Wiki User Page
My MSDN Page
My Personal Blog
My Facebook Page

Why do we need SSIS and star schema of Data Warehouse?

If SSAS in MOLAP mode stores data, what is the application of SSIS and why do we need a Data Warehouse and the ETL process of SSIS?
I have a SQL Server OLTP database. I am using SSIS to transfer my SQL Server data from OLTP database to a Data Warehouse database that contains fact and dimension tables.
After that I want to create cubes using SSAS form Data Warehouse data.
I know that MOLAP stores data. Do I need any Data warehouse with Fact and Dimension tables?
Is not it better to avoid creating Data warehouse and create cubes directly from OLTP database?

Another thing to note is data stored in transactional system may not always be in end user consumable format for ex. we may use bit fields/flags to represent some details in OLTP as storage required ius minimum but presenting them as is would not make any
sense to user as they would not know what each bit value represents. In such cases we apply some transformations and convert data into useful information for users to understand. This is also in the warehouse so that information in warehouse can directly be
used for reporting. Also in many cases the report will merge data from multiple source systems so merging it on the fly in report would be tedious and would have hit on report server. In comparison bringing them onto common layer (warehouse) and prebuilding
aggregates would be benefitial for the report performance.
I think (not sure) we join tables in SSAS queries and calculate aggregations in it.
I think SSAS stores these values and joined tables and we do not need to evaluates those values again and this behavior is like a Data Warehouse.
Is not it?
So if I do not need historical data, Can I avoid creating Data Warehouse?
On the backend SSAS uses queries only to extract the data
B/w I was not explaining on SSAS. I was explaining on what happens inside datawarehouse which is a relational database by itself. SSAS is used to built cube (OLAP structures) on top of datawarehouse. star schema is easier for defining relationships
and buidling aggregations inside SSAS as its simple and requires minimal lookups to be performed. Also data would be held at lowest granularity level which can easily be aggregated to required levels inside OLAP cubes. Cube processing is very resource
intensive and using OLTP system would really have a huge impact on processing performance as its nnot denormalized and also doing tranformation etc on the fly adds up to complexity. Precreating a layer (data warehouse) having data in required format would
make cube processing easier and simpler as it has to just cross join tables and aggregate data based on relationships defined and level needed inside the cube.
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Question for integration star and snow flake schema in data warehouse

Dear Reader,
I facing a problem like that
I have two data warehouse, one use star schema, other use snow flake schema. I would like to integrate both of them into one data warehouse. What is the strategy should these two data warehouse adopt in order to integrate int one data warehouse?
Should I scrap both data warehouse and build a new one instead, or scrap one of them and use the other?
What factors should be considered in order for me to more easily resolve the differences between the two data warehouses.
Please advise. Thank you very much.

Hi Mallis,
This is a very broad question and the answer depends on so many factors. Please go through the following articles to get an
understanding of what the differences are when to use which.
When do you use a star schema and when to use a snowflake schema -
http://www.information-management.com/news/10000243-1.html
Star vs Snowflake Schemas – what’s your belief? –
http://www.networkworld.com/community/blog/star-vs-snowflake-schemas-%E2%80%93-what%E2%80%99s-your-belie
Hope this helps!

Efficiency of data warehouse sql and star/snowflake schema

Hi,
We are using 11.2.0.3 and need to improve query performance of reports. data warehouse star/snowflake schema
In addition to indexing, partitioning having star_transformation enabled etc I am condisriing impact of the following on query performance.
central fact (over a billion rows) joins to a dimesnion customer ( few hundred thousand rows) which in turn joined to latest version of the dimesnion ( whichhas circa 30,000 rows).
The table with few hundred thousand rows (customer dimesnion) must alwsys be queried as data stored aganist the version of customer applicable at the time - we just query latest_customer as users want to see
latest version of customer attributes to stop data being fragemented across several rows in the report.
Considering if would be more efficient to create a dimenson which is the equivalent of customer but also stores the latest version of the customer attributes on the on row - this would mean customer dimensuion would have far more columns but queries would could avoid additional lookup of this 30k row table.
Thoughts are - would this be a material benefit?
At monent users would query latest_customer to say get all customers belonging to a certain multiple chain.
If change as above then they would query directly the customer dimension with few hundred thousand rows.
Thoughts?
Thanks

We are using 11.2.0.3 and need to improve query performance of reports. data warehouse star/snowflake schema
That is NOT a realistic or even meaningful goal.
And until you identify and document an actual PROBLEM or specific goal you should not even be considering possible solutions.
Anything you do to improve one report might degrade the performance of several other reports.
You need to start over and gather information about WHAT Oracle is doing for the reports now, HOW that work is being done and capture metrics that validate how the reports are currently performing.
Your first step should be to document the performance you are getting now for each report.
The second step would be to identify which of those reports is a possible target for tuning.
The third step is to prioritize the reports: which is most important to tune, which is next, etc.
Then you need to generate the execution plans for those reports to identify EXACTLY how Oracle is executing the queries now.
At this point you should have enough information to know what your possible options are.
So then you create a prioritized list of options. The top of the list should be additions to what you already have.
1. New indexes - regular or bitmapped (if appropriate)
2. Dropping indexes that aren't being used.
3. Report-ready summary tables or Materializeds views.
IMHO modifying your basic architecture should be your LAST resort and undertaken only if you can't solve your (unstated) problem using solutions that have less impact and risk.

How to convert database in 3NF to Star schema

Hi
Can anyone help me out to convert the database in 3NF to Star schema so that it can be used for Business Intelligence.
Our Application will be populating the database in normal 3NF form which may be difficult for the intelligence to generate queries from it. From the documents given, i saw that only star schema containing dimensions table and fact table is simpler to generate reports. Is there any tool that would convert the schema from 3NF to star schema?
Regards
S. Kokila

Hi,
I do not know any tools that would do this for you. You can apply a certain logic to create your dimensions and facts, but decisions will have to be taken along the way.
You need to know the basis of database design for datawarehousing. A few good books and articles are available on the subject.
Bonne lecture!

Injecting data into a star schema from a flat staging table

I'm trying to work out a best approach for getting data from a very flat staging table and then loading it into a star schema - I take a row from a table with for example 50 different attributes about a person and then load these into a host of different tables, including linking tables.
One of the attibutes in the staging table will be an instruction to either insert the person and their new data, or update a person and some component of their data or maybe even to terminate a persons records.
I plan to use PL/SQL but I'm not sure on the best approach.
The staging table data will be loaded every 10 minutes and will contain about 300 updates.
I'm not sure if I should just select the staging records into a cursor then insert into the various tables?
Has anyone got any working examples based on a similar experience?
I can provide a working example if required.

The database has some elements that make SQL a tad harder to use?
For example:
CREATE TABLE staging
(person_id NUMBER(10) NOT NULL ,
title VARCHAR2(15) NULL ,
initials VARCHAR2(5) NULL ,
forename VARCHAR2(30) NULL ,
middle_name VARCHAR2(30) NULL ,
surname VARCHAR2(50) NULL,
dial_number VARCHAR2(30) NULL,
Is_Contactable CHAR(1) NULL);
INSERT INTO staging
(person_id, title, initials, forename, middle_name, surname, dial_number)
VALUES ('12345', 'Mr', 'NULL', 'Joe', NULL, 'Bloggs', '0117512345','Y')
CREATE TABLE person
(person_id NUMBER(10) NOT NULL ,
title VARCHAR2(15) NULL ,
initials VARCHAR2(5) NULL ,
forename VARCHAR2(30) NULL ,
middle_name VARCHAR2(30) NULL ,
surname VARCHAR2(50) NULL);
CREATE UNIQUE INDEX XPKPerson ON Person
(Person_ID ASC);
ALTER TABLE Person
ADD CONSTRAINT XPKPerson PRIMARY KEY (Person_ID);
CREATE TABLE person_comm
(person_id NUMBER(10) NOT NULL ,
comm_type_id NUMBER(10) NOT NULL ,
comm_id NUMBER(10) NOT NULL );
CREATE UNIQUE INDEX XPKPerson_Comm ON Person_Comm
(Person_ID ASC,Comm_Type_ID ASC,Comm_ID ASC);
ALTER TABLE Person_Comm
ADD CONSTRAINT XPKPerson_Comm PRIMARY KEY (Person_ID,Comm_Type_ID,Comm_ID);
CREATE TABLE person_comm_preference
(person_id NUMBER(10) NOT NULL ,
comm_type_id NUMBER(10) NOT NULL
Is_Contactable CHAR(1) NULL);
CREATE UNIQUE INDEX XPKPerson_Comm_Preference ON Person_Comm_Preference
(Person_ID ASC,Comm_Type_ID ASC);
ALTER TABLE Person_Comm_Preference
ADD CONSTRAINT XPKPerson_Comm_Preference PRIMARY KEY (Person_ID,Comm_Type_ID);
CREATE TABLE comm_type
comm_type_id NUMBER(10) NOT NULL ,
NAME VARCHAR2(25) NULL ,
description VARCHAR2(100) NULL ,
comm_table_name VARCHAR2(50) NULL);
CREATE UNIQUE INDEX XPKComm_Type ON Comm_Type
(Comm_Type_ID ASC);
ALTER TABLE Comm_Type
ADD CONSTRAINT XPKComm_Type PRIMARY KEY (Comm_Type_ID);
insert into comm_type (comm_type_id, NAME, description, comm_table_name) values ('23456','HOME PHONE','Home Phone Number','PHONE');
CREATE TABLE phone
(phone_id NUMBER(10) NOT NULL ,
dial_number VARCHAR2(30) NULL);
Take the record from Staging then update:
'person'
'Person_Comm_Preference' Based on a comm_type of 'HOME_PHONE'
'person_comm' Derived from 'Person' and 'Person_Comm_Preference'
Then update 'Phone' with the number based on a link derived from 'Phone' which is made up of Person_Comm Primary_Key where 'Comm_ID' (part of that composite key)
relates to the Phone table Primary_Key which is Phone_ID.
Does you head hurt as much as mine?

Star schema for a uploaded data sheet

Hi All gurus,
I am new to this tech . I have a requirement like this , I have to prepare the star schema for this data sheet as below .
REPORT_DATE     PREPARED_BY     Units On-time     Units Late     Non-Critical On-time     Non-Critical Lates      Non-Critical DK On-time     Non-Critical DK Lates
2011 -01     Team1     1
2011-02     Team1
2011-03     Team1
2011 -01     Team2
2011-02     Team2                         7     1
2011-03     Team2                              4 5
2011 -01     Team3
2011-02     Team3
2011-03     Team3     1                         3
(Take blank fields as zeros)
Note : There are 3 report date types 2011-01,02,03 and three teams team 1,2,3 as text data and all others columns contain number data .
I am given Time as dimensional table containing the Report Date and Whole sheet as Data table . So how to define the relationship for this in Physical and BMM ?
I am thinking to make Time as Dimensional Table and the whole table(as Data) as a fact table in the Physical layer . And then in the BMM , I want to carve out a Logical Dimension called Group from the Data Physical Table and then make Group and Time as dimensional Table and Data as Fact table .
Is this approach is correct ? please suggest me and if have any better Idea ,then please note down what are the tables to be taken as Dimension and Fact table in both physical and BMM . Your help willl be appreciated ,so thanks in advance . You can also advice for any change in no of Physical tables in the Physical schema design ..

Your' s suggestion utterly anticipated ..

BW Star Scheme & Multi dimensional Data Modelling

Hi BW Experts,
Can any one please let me know when i have to check in help.sap or serivices.sap
for detailed info on BW Star Scheema and Multi dimensional Data Modelling and how it is used in BW.
Please update me where i have to check for this info
Thanks

hi...
star schema..
Please check the threads below..
Differences between Star Schema and extended Star Schem
What is the difference between Fact tables F & E?
Invalid characters erros
mdm..
http://help.sap.com/bp_biv133/documentation/Multi-dimensional_modeling_EN.doc
hope this helps,...

Master data sharing using ext. star schema

Hi,
I have undetrstood the concept of extended star schema.
I understand,
One of the advantages of extended star schema is, that the master data can be shared, meaning, since the master data is stored separately, other star schema's can also share this master data provided it is of the same relevance( with same infoobjects used in this star schema).
Confirm if my understanding is right and if right,
Any idea or suggestion how to demonstrate this ?
Points will be given for good answers.
thanks.
bwlearner

Hey,
If u could map this with programming.
MASTER DATA Tables are like GLOBAL declaration and InfoCubes (Fact Tables) are like LOCAL declaration. Any number of IncoCubes can access one particular Master Data Table.
Assume Sales data coming from 5 regions. Here 0CUSTOMER & its attributes will update the same Master Data Table. The data fields will be stored in the Infocube. So all the 5 InfoCubes access the same Master Data tables using the Dimension & SID tables.
Clear ?
Best Regards....
Sankar Kumar
+91 98403 47141

Data warehouse database


Today I came across one very interesting question


"Data Warehouse can be only deployed in relation database."


Above statement is true or false.


If we see it simply without any complication or may be go back 7-8 years it's answer may be false as I find out after doing research on it


"A data warehouse can be normalized or denormalized. It can be a relational database, multidimensional database, flat file, hierarchical database, object database, etc. Data warehouse data often gets changed. And data warehouses often focus on a specific activity or entity." Larry Greenfield


The data warehouse is normally (but does not have to be) a relational database. It must be organized to hold information in a structure that best supports not only query and reporting, but also advanced analysis techniques, like data mining. Most data warehouses hold information for at least 1 year and sometimes can reach half century, depending on the business/operations data retention requirement. As a result these databases can become very large.en.wikipedia.org


But I think when we look into the complication of designing and functionality which we are expecting from a data warehouse today and plus the concept which use when designing the data warehouse structure like star scheme, snow flake etc., I think it cannot be done in any other type of database which don't follow the relation database concept. We may call it multidimensional database or ORDBMS and we may talk about cubes, measures, dimension and so on but from the base it has to follows the relation database.


Let me know if anybody has anything to say about it.

 
Regards,
 
Raj 
www.oraclebrains.com<a>
 POWERED by the people, to the people and for the people WHERE ORACLE IS PASSION.

Thanks Justin!
 
I agree with you the concept exist before the relational database was invented. Last time I know they call it EIS then they name it MIS and now data warehouse. But what I am taking about is modern data warehouse technique, If you really think that any other type of database can support it without following relational database concept. Let me know which one?
 
I am still searching for my answers and have discuss with lot of people, but when I asked them have they seen any implementation of data warehouse without using relational database, the answer that I get is always negative. 
Raj 
www.oraclebrains.com<a>
 POWERED by the people, to the people and for the people WHERE ORACLE IS PASSION.

Differences between operational systems data modeling and data warehouse da

Hello Everyone,
Can anybody help me understand the differences between operational systems data modeling and data warehouse data modeling>
Thanks

Hello A S!
What you mean is the difference between modelling after normal form like in operational systems (OLTP) e. g. 3NF and modelling a InfoCube in a data warehouse (OLAP)?
While in a OLTP you want to have data tables free of redundance and ready for transactions meaning writing and reading few records often, in an OLAP-system you need to read a lot of data for every query you do on a database. Often in an OLAP-system you aggregate these amounts of data.
Therefore you use another principle for these database scheme. This is called star schema. This means that you have one central table (called fact table) which holds the key figures and have keys to another tables with characteristics. These other tables are called dimension tables. They hold combinations of the characteristics. Normally you design it that your dimensions are small, so the access on the data is more efficent.
the star scheme in SAP BI is a little more complex than explained here but it follows the same concept.
Best regards,
Peter

Strategy in Data Warehouse Table Structure

I'm building a relational data warehouse, and there are two approaches that seem almost interchangeable to me, despite being quite different from each other.
The first approach is rather simple. I have a "User" table with a bunch of foreign keys, and then I have a bunch of other tables containing user attributes. One table for "department," another for "payroll type,"
another for "primary location," and so on for 20 different user attributes.
The second approach, instead of using 20+ tables, combines this down into far fewer. I would have an "Attribute Type" table and "Attribute" table. These two, in conjunction with a bridge table, could accommodate as many
attributes as necessary within three tables. If the business wants to track a new "user-related" attribute, I don't need any new tables. I would simply add the new attribute into the "Attribute Type" table as, say, "attribute
21," and begin tracking it. All the work could be done without ever adding new tables or columns.
Both approaches seem to maintain (at least) 3NF. Is one approach better in certain circumstances, and the other approach more appropriate at other times? Any insight is appreciated!
BrainE

Hi Brian,
The second approach with three tables is not really good here. Query Optimizer in SQL Server has a few enhancements for Star/Snowflake schemas in DW environment and 3-table schema would not be able to benefit from them. It would be also harder to maintain,
load data and query. Finally, your attributes could have different data types, which you need to store.
I would suggest to go with first solution (multiple dimensions table) and follow a few extra rules:
Avoid nullable attributes
Choose attribute data types as narrow as possible
Avoid string attributes. If needed create separate dimension tables for them
Use columnstore indexes and
Upgrade to SQL Server 2014 if it is all possible - there are multiple enhancementsin batch-mode processing there
Thank you!
Dmitri V. Korotkevitch (MVP, MCM, MCPD)
My blog: http://aboutsqlserver.com

Foreign keys in SCD2 dimensions and fact tables in data warehouse

Hello.
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.

>
I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
1 1 XXX 01.01.2000 01.01.2002 0
2 1 YYX 02.01.2002 01.01.2004 1
3 2 SYX 02.01.2002 1
4 3 AYX 02.01.2002 01.01.2004 0
5 3 YYZ 02.01.2004 1
On this table there are relations from other dimension and fact table.
Need I create foreign keys for relation?
>
Are you still designing your system? Why did you choose NOT to use a Star schema? Star schema's are simpler and have some performance benefits over snowflakes. Although there may be some data redundancy that is usually not an issue for data warehouse systems since any DML is usually well-managed and normalization is often sacrificed for better performance.
Only YOU can determine what foreign keys you need. Generally you will create foreign keys between any child table and its parent table and those need to be created on a primary key or unique key value.
>
And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.
>
I have no idea what that means. There isn't any way to tell from just the DDL for one dimension table that you provided.
It is not clear if you are saying that your fact table will have a direct relationship to the star-flake dimension tables or only link to them through the top-level dimensions.
Some types of snowflakes do nothing more than normalize a dimension table to eliminate redundancy. For those types the dimension table is, in a sense, a 'mini' fact table and the other normalized tables become its children. The fact table only has a relation to the main dimension table; any data needed from the dimensions 'child' tables is obtained by joining them to their 'parent'.
Other snowflake types have the main fact table having relations to one or more of the dimensions 'child' tables. That complicates the maintenance of the fact table since any change to the dimension 'child' table impacts the fact table also. It is not recommended to use that type of snowflake.
See the 'Snowflake Schemas' section of the Data Warehousing Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28313/schemas.htm
>
Snowflake Schemas
The snowflake schema is a more complex data warehouse model than a star schema, and is a type of star schema. It is called a snowflake schema because the diagram of the schema resembles a snowflake.
Snowflake schemas normalize dimensions to eliminate redundancy. That is, the dimension data has been grouped into multiple tables instead of one large table. For example, a product dimension table in a star schema might be normalized into a products table, a product_category table, and a product_manufacturer table in a snowflake schema. While this saves space, it increases the number of dimension tables and requires more foreign key joins. The result is more complex queries and reduced query performance. Figure 19-3 presents a graphical representation of a snowflake schema.

Normalized (3NF) VS Denormalized(Star Schema) Data warehouse :

Similar Messages

Maybe you are looking for