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

Similar Messages

Load data from dimensions to fact table

Hi,
I have 10 dimension tables and one fact table. now i want to load data in to fact table from dimensions table. how i can do that.
Regards,
joy

To elaborate on "Mallee"'s answer, it's not good practice to load dimensional data into a fact table.
I guess what you mean is how to refer to dimensions when loading a fact table.
Simply refer to dimensions using lookups on the necessary dimensions, the lookup needs to be on the natural key you have that links facts to dimensions. Don't forget to use the dimension's surrogate key though when populating the fact table's foreign key columns pointing at the dimensions.
Hope this helps.
Cheers, Patrick

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

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

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.

How to load data from a flat file which is there in the application server

HI All,
how to load data from a flat file which is there in the application server..

Hi,
Firstly you will need to place the file(s) in the AL11 path. Then in your infopackage in "Extraction" tab you need to select "Application Server" option. Then you need to specify the path as well as the exact file you want to load by using the browsing button.
If your file name keeps changing on a daily basis i.e. name_ddmmyyyy.csv, then in the Extraction tab you have the option to write an ABAP routine that generates the file name. Here you will need to append sy-datum to "name" and then append ".csv" to generate complete filename.
Please let me know if this is helpful or if you need any more inputs.
Thanks & Regards,
Nishant Tatkar.

Dimension and Fact table have the same grain

Hi All,
How can we join a dimension and a fact table if they have the same grain ? In my case it is a contract number.
Thanks

Your Impression is right, In terms of Dimensional Modeling. You have to consider this when you are designing your warehouse tables.
But now if you already have these tables in database, OBIEE does not care how many rows a table have, it just need to know what is fact and what is Dimension and it will generate sql queries based on join conditions.

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

Size of the DImension and Fact table.

Hi,
I have an info cube, now to decide weather i need to make use of line item or high cardinality .....i need to check or compare the size of the dimension table along with the size of the fact table.
Where do i get this information.
Please help.
Thanks,
Jay.

Hi Friend,
For each infocube you will see Rows and ratio for all the dimension tables and Fact table.
Rows indicate the number of rows in that Dimension or Fact table.
Ratio indicates the number of rows in that table divided by number of rows in the fact table.
As a standard the ratio of rows in Dimension table to rows in fact table should not be more than 10%.
If it is more than you will see it in red colour in this report and you can think of redesigning that particular dimension.
Regards
Hemant Khemani

How to join Dimensions and Fact Tables in OBIEE

Hi All,
I need to create report which need to get the information from two fact tables and 7 dimensions. The granularity is not same in both the fact tables. One fact table is having common keys between all the dimension tables and second fact table have only two dimension keys but with different names. My requirement is to create the report by taking the measures from both the fact tables.
I have created joins between the second fact table and two dimension tables in physical and BMM layer and also set the highest level for all other dimension tables in the LTS of second fact table. when am creating report by taking the measures from both the fact tables, data is not getting for the measure which taken from the second fact table. Please advice me how to get the data for the measure which taken from the second fact table.
Thanks in Advancec !!

You have to use the level-base measure capabilities.
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/level_based_measure_calculations
For all measures of the second fact table with the lowest grain (with two dimension keys), set for all dimension where you don't have any key the logical level to the "All" or "Total".
And UNSET the highest level of the LTS for the second fact table.
Success
Nico

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

Question about extending dimension and fact tables

We have our data warehouse completely loaded with several years of historical data. We now want to extend one of our dimension tables by performing a type 1 customization to add an additional column to that dimension table.
Is there a way for the ETL to update all of the historical records in the dimension table by filling in the data for the new column? Assume that we made the necessary changes in the database and updated the ETL mapping accordingly. We want to avoid having to truncate the table or doing a full load again -- even just for that table and the corresponding facts.

Remove the last refresh date for the table in the DAC repository...that will force an ujpdate of the whole table without you needing to reload everything.
Oh yeah and you're in the wrong forum: Business Intelligence Applications
C.

One to One relationship between Dimensions and Fact Tables

Hi,
Not a real Discoverer question, but seeing as there is such a huge pool of talent here, I thought I'd ask anyway...
Is the concept of having a one to one join between a Dimension and a Fact Table an Acceptable Thing (tm). I'm not talking about a degenerate dimension, as the Dimension would hold additional attributes.
It's something I'm trying to get my head around and would appreciate any viewpoints.
Thanks,
Andy

Hi Andy,
There is of course no distinction in SQL between 1-1 and 1-n joins, but in your database design you would avoid denormalizing data into a dimension table if it was only ever used once.
From a Discoverer perspective setting the join to 1-1 controls how aggregate queries are constructed. Normally, if you have a master-detail 1-n relationship and you aggregate items in both tables then you will get an incorrect result for the master table because the number of rows are multipled by the n detail records. Similarily if you have 2 detail tables in the query and you aggregate items in a detail table you will get incorrect results. Discoverer recognises these situations and raises an error.
Setting the join as 1-1 tells Discoverer that it will get the correct results in these situations and therefore no error is raised. So it is perfectly acceptable to set the joins as 1-1 as long as you know the implications.
Hope that helps,
Rod West

Dimension and Fact table Ratios

Hi All,
I have loaded some test data into my Cube and executed the program "SAP_INFOCUBE_DESIGNS" to get the ratios of Dimension tables to Fact table. I found that 1 dimension is almost equal to the fact table. but, as far as my knowledge, a dimension table should not exceed 30% of the fact table, please correct me if I am wrong.
To decrease the size of the dimension table, I have created another dimension and included some of the chars, from the bigger dimension, in it. I have loaded the data again and ran the program again. But, the program result is still showing the same as previous i.e the ratio has not been changed and even the newly added dimension is not being showed. Do I need to refresh something to get the new ratios?
Thanks,
RPK.

Hi Paolo,
I tried as you suggested but unfortunately no luck. Below are the steps I performed.
RC on the cube->Manage->Performance tab->Click on "Refresh Statistics".
I also tried:
RC on the cube->Manage->Performance tab->Click on "Create Statistics(Btch)".
What could be wrong?
Thanks,
RPK.

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

Similar Messages

Maybe you are looking for