Dimension and fact column types

Hi All
I'm studying data ware housing concept and using book Training Kit Exam 70-463 but I'm unable to understand the following topics.
--Column types in Dimension
--Column Types in Fact
I tried to Google these topics but I cannot find any good explanation. If somebody help me out to explain these topics in simple words with an examples then I really appreciate it. thanks
Regards
Muz

Basic rule:
fact tables: Foreign keys and measures (something you can aggregate, so mostly numeric types)
dimension tables: primary key and descriptive attributes (represented mostly by VARCHAR columns, but you can have any type of column). You use them to slice your data (group by).
If you have time to dig into it, I would advice you to read first few chapters of:
The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley. 2013.
ISBN 978-1-118-53080-1.
I recently passed 70-463 and having good understanding of dimensional modeling helps.

Similar Messages

One table containing DIMENSION and FACT columns ... How to make it work?

Guys, i have a question that relates to OBIEE working with a single table containing both fact and dimension columns.
What is the "best" strategy to get this to behave like a star schema? Following are my questions:
- Should i alias each dim set of columns in physical layer
- Should i alias fact set of columns in physical layer
- Join them in the Physical layer and then pretend they are actually two separate structures in business layer?
OR
Something else?
Please share your ideas how to handle this type of situation.
Regards,

You can just duplicate the table in the Business Model and separate the Facts and Dimensions, there is an article about this type of design here..
http://www.rittmanmead.com/2009/11/10/oracle-bi-ee-10-1-3-4-1-single-table-repository-design-part-1/

Add Audit Columns to the Dimension and Fact tables (Created & modified date Time)

Hi All,
I am new to SSIS , I have to Add Audit Columns to the Dimension and Fact tables (Created & modified date Time) of the package.
Please let me know the best and easy way through which I can implement the same.
If possible suggest some real time example or link where I can find the same
Regards,
Vipin jha
Thankx & regards, Vipin jha MCP

You can simply use ALTER TABLE ADD.. syntax to add the columns if the tables already exist.
You can generate a single script for all tables using INFORMATION_SCHEMA.TABLES view
You can make then of NOT NULL type and set the default value to GETDATE()
In addition you can also have a Audit Trail trigger for UPDATE to make sure Modified date gets updated correctly on each update if not passed explicitly.
Please Mark This As Answer if it solved your issue
Please Mark This As Helpful if it helps to solve your issue
Visakh
My MSDN Page
My Personal Blog
My Facebook Page

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.

Many to Many relationship betwee dimension and fact tanle

Hello Gurus,
I have a little question about many to many realtionship between fact and dimension table. The situation is as follows.
Consider there is a fact table F1 and two dimension tables D1 and D2. D1 is joined to F1 with 1 to many relationship. D1 is joined to D2 with again one to many relationship ( Note: D1:D2 = 1:N and D1:F1 = 1:N). I am able to model this by merging D1 and D2 into one dimension table in BMM layer by adding them as logical table sources and creating logical table source join. I have built simple reports and the data returnned is fine. However, I would just like to know what could be the drawbacks of such a model.
We have many other dimesions joined to the fact table and users have access to the answers that means they would could what ever report they feel like. Hence, would just like to know in what cases this model could break which means reports would give wrong data because of a many to many relationship between one of the fact and dimension table.
Thanks in advance.

Hello Copter,
Even I had modeled it by reading this link before. In the situation explained by me dimension D1 is doing the job of table Rules ( as explained in link). The model is fine.
However, my point is to undersatnd in which scenerios this model will break. As already explained, the fact table is joined to various other dimensions, there could be situations in which users select columns from various dimensions and facts randomly.
Hence, which are the scenerios where I might get erroneous counts of meassures. Further, if someone feels this model is correct and would not break in any scenerio then please reply.

Dimension and Fact out of Daily Extract File

Hi Folks,
We have a third party vendor which provides us with a daily extract of data in an excel file with about 40 columns. Some of the columns are a typical detail info like "State Name", "Payer
Name" etc. and some are numerical columns like "Billing rate", "Amount Paid" etc.
Now for long term reporting I want to setup a proper datawarehouse with Dimension and Fact Tables. The issue is that the third party vendor is not giving us access to the database source of these excel extracts. So, If I want to design a Dimension
like Dim_Payer, I have only those Payer which are available in the daily excel extract file.
I was thinking of doing a reverse ETL process to load Dimension and Fact Table. So I read the daily excel extract file for unique Payer names and then load the Dimension table with unique keys for Payer. Going forward I only add new Payers. I then load the
Fact tables with these keys.
Let me know if my approach has any issues.
Thanks!

The approach looks fine.
What you could do is to have a SSIS package using data flow task. In it use a excel source and have a set of lookup tasks to see if payer, state etc exists and link the no match output to OLEDB destinations to insert missing values to the table. Finally
have a data flow task to insert data to fact table after having lookups with relevant dimensions to get the reference ids.
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

Improve Performance of Dimension and Fact table

Hi All,
Can any one explain me the steps how to improve performance of Dimension and Fact table.
Thanks in advace....
redd

Hi!
There is much to be said about performance in general, but I will try to answer your specific question regarding fact and dimension tables.
First of all try to compress as many requests as possible in the fact table and do that regularily.
Partition your compressed fact table physically based on for example 0CALMONTH. In the infocube maintenance, in the Extras menu, choose partitioning.
Partition your cube logically into several smaller cubes based on for example 0CALYEAR. Combine the cubes with a multiprovider.
Use constants on infocube level (Extras->Structure Specific Infoobject properties) and/or restrictions on specific cubes in your multiprovider queries if needed.
Create aggregates of subsets of your characteristics based on your query design. Use the debug option in RSRT to investigate which objects you need to include.
To investigate the size of the dimension tables, first use the test in transaction RSRV (Database Information about InfoProvider Tables). It will tell you the relative sizes of your dimensions in comparison to your fact table. Then go to transaction DB02 and conduct a detailed analysis on the large dimension tables. You can choose "table columns" in the detailed analysis screen to see the number of distinct values in each column (characteristic). You also need to understand the "business logic" behind these objects. The ones that have low cardinality, that is relate to each other shoule be located together. With this information at hand you can understand which objects contribute the most to the size of the dimension and separate the dimension.
Use line item dimension where applicable, but use the "high cardinality" option with extreme care.
Generate database statistics regularily using process chains or (if you use Oracle) schedule BRCONNECT runs using transaction DB13.
Good luck!
Kind Regards
Andreas

Loading dimensions and facts (Please verify the design is correct)

Hi,
I am very new to OWB and Datawarehousing, please find the following approach and let me know if its correct or not.
I have the following source tables,
1. Sales -->store_id,Product_id,Sales_date_Time,Unit_sales,Amount_sales
2. Product--> Product_id,Product_name,Product_category_id
3. Product_Category --> pc_id , pc_name
4. Stores -->store_id,store_name,city_id
5 City --> city_id , state
The above tables are normalized,
Now i have created Dimensions , and Fact (Please check whether its correct or not)
1 . Product_Dimension ->Product_key, product_id,product_name,pc_id,pc_name
2. Time_Dimension --> Time_key, ...Can be loaded from the Excel sheet provided (This is what people do here in my company)
3. Stores_Dimension --> Store_key,store_id,store_name,city_id,state
4. Sales_fact -->Product_key,time_key,store_key,Unit_sales,Amount_sales,sales_date
If the above design is correct, then i will create the following mappings
1. Map_Product --> loading product and product_Category from source
2. Map_Time --> loading thru SQLLDR directly
3. Map_Stores --> loading stores and city from source
Once the above mappings completed ( loading all the dimensions)
map_sales_fact --> loading from map_product, map_time, map_stores...
But if here if you closely observe Sales_Fact table, it has columns like unit_sales,amount_sales and sales_date. How do i load these as i dont have them in any dimensions,
Please help , please reply me if you need any clarifications.
Regards,
Ashoka BL
+919880890405

Hi,
first of all, there is no need for the column sales_date in your fact table. Use the time_id for date reference.
In your dimensions, use surrogate keys that are generated in your dwh. Do not use ids from your source as surrogate keys!
You may use the ids from the source as business keys, if the names are not unique.
Load your fact table from source table sales. Join all dimensions to get the surrogate keys of product, store and time.
Write the surrogate dim keys into the fact table along with unit_sales and amount_sales.
Regards,
Carsten.

Needed - BW data model and list of Dimensions and Fact table from BW

Dear Friends,
Can somebody please share SAP BW DATA MODEL (LOGICAL) and share the list of DIMENSION and FACT tables exist in BW?
I don't have access to SAP or SAP BW and I am building data-mart and SAP FI/CO will be the source.
Thank you very much in advance.
Regards,
Nitin
Edited by: Nitin Baradia on Apr 5, 2010 9:08 AM

Let me rephrase.
I got an EarlyWatch that said my dimensions on one of cube were too big. I ran SAP_INFOCUBE_DESIGNS in SE38 in my development box and that confirmed it.
So, I redesigned the cube, reactivated it and reloaded it. I then ran SAP_INFOCUBE_DESIGNS again. The cube doesn't even show up on it. I suspect I have to trigger something in BW to make it populate for that cube. How do I make that happen manually?
Thanks.
Dave

Dimensions and facts related to all BI Apps Financials Star Schemas

I am kind of new to BI Apps and was wondering whether there is a list of tables/dimension names/ facts that constitute each star schema in Financial Analytics?
I know there are star schemas like AP Aging, AR Aging, AP Transactions, AR Transactions and so on.
How do I get the OBAW dimension and fact table names that are in each of these star schemas?
Oracle BI Apps presentations take me only to the business name of the dimensions and does not give me the original dimension name used in OBAW.
Thanks in advance!

Hi Sid
I am in Data Model Reference that you have mentioned. All the star schemas over here are pictures and are not searchable. Also, the ppt that Oracle gave us just says AP Aging as the fact name and I dont know how I can find the fact table corresponding to that.
If someone can point me for that piece of work, I will go though the star schema pictures in the documentation and find relevant dimensions and facts.
Is there any naming convention that we can use like W_APAging_F table or something like that??
Thanks in advance !
Edited by: user566193 on Jan 21, 2010 2:43 PM

How to load data to dimensions and fact table is it simialr to sql server

How to load data to dimensions and fact table in a data ware house environment, is it simialr to sql server, oracle?
Never migrated or loaded data to datawarehouse server.
I have an interview and am really confused if they ask anything related to the dataware house side elements.
Coudl you please if you don't mind provide me some steps and dimension and fact table info, an example only.
Atleast for my knowledge.
Thank you very much for the helpful info.

Some discussions in previous forums should help you
http://forums.sdn.sap.com/thread.jspa?threadID=2019448
http://forums.sdn.sap.com/thread.jspa?threadID=1908902
In the SAP tutorial, you can see a sample example of making fact tables.
http://help.sap.com/businessobject/product_guides/boexir32SP1/en/xi321_ds_tutorial_en.pdf
Arun

Create Dimension and Fact Table

I Am Ramana I am new to OBIEE recently i started.
CAn any one explain what is Fact table and Dimension table and how Create Dimension and Fact Table

Ramana, don't open multiple instances of the same question...
Starting with OBIEE

Fact - dimension and Fact Join

Hi ,
I have a issue in OBIEE 11g here ,
I am trying to query two columns from 2 different fact tables F1 and F2
the join between these tables is F1 - D - F2 , where D is the confirmed dimension.
so when i am querying for
f1.c1 , d.c1 , f2.c1 , its throwing me up with error
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14020] None of the fact tables are compatible with the query request
Can you please help me with this issue , am i doing the correct join ??, can we query two columns from two diff fact tables?
Thanks in advance.

Hi All,
Thanks for your responses , I have tried creating hierarchy dimension and assgned levels to the fact sources but i still see the error
and
Combining 2 facts will resolve the issue but its not the case here as each fact table has about 25 dimensions connected to it , but there are only 2 confirmed dimensions between both facts and the problem here is user wants to see both the fact tables in the same subject area
I have been trying but unable to get the solution.
Can you guys please suggested any other way of achiving this task
Thanks a lot

Simple Design Analysis Question before designing dimensions and facts

Hi I have a simple question ... (I think its simple)
Suppose that i have the following staging table with the following columns:
Student_Name | RollNo | Test_Date | Subject-Taken
with data such as
Kevin |123|12-4-2010|Physics
now suppose that I want to design a cube on the basis of the above table so that I can succesfully get the result of a query such as
List the names of all those students who took the test b/w 12-4-2010 to 12-5-2010 of the Subject Physics
Here what i need to know what dimensions/Levels would u set and what would be our fact?
I think that one dimension would be time ( but i am not sure how i would accommodate and handle duration... any idea )
would it be wise to make each column a dimension ??? for example the student_nanme a dimension and details of the student its attributes??
Anyways the main thing is what bothers me is looking at the query we see that we are required 3 things the name of the student , the TestDate and subject taken so if i make the 3 columns the dimension i am still not sure that i would be able to acomodate the query properly...any ideas on how to approach and handle these situations
Edited by: Johnacandy on Dec 14, 2010 9:26 AM

ScoobySi wrote:
Yes I mean Time dimension, however in a DW you will have many Time dimensions, instead of creating a physical object for each you use a ROLE. If you edit a dimension in OWB you'll see that you can specify a ROLE on the first tab.
Thanks for the great explaination... could you explain the process of roles a little more that will really save me some time... furthermore u stated
+ "instead of creating a physical object for each you use a ROLE" +
The way i create dimensions is right clicking dimensions and selecting dimension.... for a standard dimension
however incase of a time dimension i use a wizard... I am still a bit confused about "Physical objects" ... Id really really appreciated it if you can clarify this up...
as discussed before one dimension would be Student and other would be subject
and 3rd one would be TEST_DATE with role ?? and should that be a time_dimension or a standard dimension with a role defined ???

Filling of Dimension and Fact tables

Hello every one,
Basically from the training guide from net. I have come to know that when you make Dimenions or facts you put every column to the source as seperate level e.g 'emp_no' column from the source will be a level in OWB and will convert into 'id and emp_no'. Now the problem arises that how can i populate them both when data will come in emp_no from source, should i link a sequence with every level's IDs.
I am pretty much confuse and then at the time of making OLAP Cube, will i call the IDs of every level or what. Please guide me.
Thanks
Mustafa Ali Qizilbash
[email protected]

Dimension level can have more than one attribute (except ID), so if you have a customer dimension, and customer is at the lowest levelof your hierarchy, this level can have multiple attributes like first_name, last_name, address, age etc. On the next hierarchy level you can have, for example, customer_type, where you will have customer_type_id and again multiple level attributes (customer_type_name, income_bracket etc.).
For OLAP you indeed have to have a unique id across all the levels (you cannot have a customer_id that is identical with a customer_type_id). You can achieve this for example by loading each level id in a separate mapping ssequentially from the same sequence (this would not be particularly efficient, but can be acceptable in some cases) or by having one sequence per level. These sequences start with different numbers and you take care that the sequence numbers they generate will never overlap. For example you can have a cust_s sequence that populates the customer_id, and you know that you will probably never ever have more that 100 thousands customers. In this case, this sequence will start with 1. As for the customer_type_id, you can have the sequence cust_type_s that starts with 10 million and progresses from there (always take some slack in these cases). This way the values generated by cust_s and cust_type_s will (probably) never overlap.
Regards:
Igor

Dimension and fact column types

Similar Messages

Maybe you are looking for