Dimension Table Vs Fact Table

What is the main difference in the logic when you create a mapping for a dimension table with that of a fact table in Informatica.

Dimension Table Vs Fact Table

What is the main difference in the logic when you create a mapping for a dimension table with that of a fact table in Informatica.

RE: Dimension Table Vs Fact Table Fact table contains numeric facts. i.e., key performence indicatiors. A dimention table is a primary key foregin key relation to fact tbale.

RE: Dimension Table Vs Fact Table Dimension Table features 1. It provides the context /descriptive information for a fact table measurements. 2. Provides entry points to data. 3. Structure of Dimension - Surrogate key , one or more other fields that compose the natural key (nk) and set of Attributes. 4. Size of Dimension Table is smaller than Fact Table. 5. In a schema more number of dimensions are presented than Fact Table. 6. Surrogate Key is used to prevent the primary key (pk) violation(store historical data). 7. Values of fields are in numeric and text representation. Fact Table features 1. It provides measurement of an enterprise. 2. Measurement is the amount determined by observation. 3. Structure of Fact Table - foreign key (fk), Degenerated Dimension and Measurements. 4. Size of Fact Table is larger than Dimension Table. 5. In a schema less number of Fact Tables observed compared to Dimension Tables. 6. Compose of Degenerate Dimension fields act as Primary Key. 7. Values of the fields always in numeric or integer form.

RE: Dimension Table Vs Fact Table Dimention Table - A pure dimention table is a collection of primary keys Fact Table - A pure fact table is collection of foreign keys.

2RE: Dimension Table Vs Fact Table I think there won't be any logic difference in a mapping to load dimension table & fact table. We can load the dimension table directly but we can't load the fact table first. So, to load the fact table we need to load the dimension table first. Also while loading the fact table we will make a lookup on the dimensioin table, cause the fact table contains the measures/facts & the foreign keys which are primary keys in the dimension tables surrounded to that fact table. We can load the dimension table & fact table in one mapping by using the "Target Load Order/Target Load Plan" in informatica. Example: / Target 1 (Dimension Table) Source - Transformations Target 2 (Fact Table) etc..... Answered On : Aug 7th, 2008 The main difference between dimension and the fact table is that Dimension preserves the historical data (like in case of type2) we will have to use update strategy and other transformations to make that happen but fact will be a direct load with few one or more lookups from the dimension and also since the fact and dimenision has the foriegn key relationship the dimension has to be loaded first before the fact Answered On : Aug 15th, 2008 Login to rate this answer.

Kadhirvelu 3 Answers Member Since Apr-2007 RE: Dimension Table Vs Fact Table

Dimensions are particular angle or perspective that you see the facts i.e aggregates or measures. as mentioned in previous replies, facts cannot be loaded unless until dimensions got loaded. Answered On : Oct 23rd, 2008 Login to rate this answer.

sahan 10 Answers Member Since Jul-2009 RE: Dimension Table Vs Fact Table You can load the dimension table directly, but you cannot load the fact table directly, You need to look up the dimension table, b'coz fact tables contains foreign keys, which are the primary keys in dimension table. You can load the dimensions and facts into one mapping using target load plan. Answered On : Jul 16th, 2009 Login to rate this answer.

Karin Divens Guest Re: Dimension Table Vs Fact Table .. But you are aware of the fact that the Target Load Order is only available if you have different pipelines, right? Answered On : Aug 19th, 2011 Login to rate this answer.

ram_infa 25 Answers Member Since Jul-2011 Re: Dimension Table Vs Fact Table The data in the dimensions table is generally static and descriptive. The fact table contains two columns one is foreign key and the other fact data generally the data in the fact tables contains numeric data Answered On : Sep 7th, 2011 Login to rate this answer.

ram_infa

25 Answers Member Since Jul-2011 Re: Dimension Table Vs Fact Table Difference between dimension and fact tables 1) dimension data is denormalized where as fact table contains normalized data 2)dimension table contains many columns where as fact table contains less columns only 2 in fact 3) the data in the dimension tables are less compared to the data in the fact tables 4) The data in the dimension table is static and descriptive in nature where as the fact table contains numeric and will change regularly 5) dimension tables generally called as lookup or reference table as well. facts tables are the key performance indicators of the business

How would you explain about Informatica Project ?

Can any one please tell me how to explain Data warehouse project in interview and from where to start and end. what to explain completely in it(data warehouse project), how much hast to explain from it(dw project) and what is architecture of it and data flow and construction of dw project or data warehouse.what is data warehouse methodology ,types of dw methodology, most using dw methodology in companies right now and project plan of dw, types of Project plan.SRS of DW. High level documents and low level documents details also. what is end to end project.is it necessary using of UNIX in data warehouse or not.sample documents of dw methodology,project plan,HLL and LLD documents.

Teradata Interview Questions Business Objects Interview Questions Cognos Interview Questions Informatica Interview Questions Crystal Enterprise Suite Interview Questions Actuate Interview Questions Ab Initio Interview Questions Data Stage Interview Questions SAS Interview Questions Micro Strategy Interview Questions ETL Interview Questions Data Warehouse General Interview Questions

Fact table - insert / update strategy

Asked by browse | posted Jan 16, 2008 | Replies (10)

Hi,We have a fact table mapping, for which the source is a flat file of say approximately 75K rows - this is a monthly load but the source provider may release the second file in the same month if there are errors in the first file. Business requirement is such that we cannot wait till we get the second file which means as soon as we get a file it has to be loaded into the fact table. And when we get the second file, all the records from the first file can comfortably be replaced with that of the records from the second file based on the dt column. To implement this update, problem is we don't have natural keys in the data. What options do we have to achieve this ?Also, in general - what are the strategies we can implement to avoid duplicate records in the fact table (if a workflow runs again by mistake)Thanks

Fact table - insert / update strategy

Reply from Suter | posted Jan 16, 2008 | Replies (10) That's strange that you have to load (possibly) invalid data to DW. If both files are the same (in rows count and order) and differ only by fact values, you can create an extra copy of the fact table before first file load. Then load first file to the original fact table and later load second file to fact copy. Then replace original with copy. But that might be not efficient approach for a large table.

Fact table - insert / update strategy

Asked by browse | posted Jan 16, 2008 | Replies (10)

Hi,We have a fact table mapping, for which the source is a flat file of say approximately 75K rows - this is a monthly load but the source provider may release the second file in the same month if there are errors in the first file. Business requirement is such that we cannot wait till we get the second file which means as soon as we get a file it has to be loaded into the fact table. And when we get the second file, all the records from the first file can comfortably be replaced with that of the records from the second file based on the dt column. To implement this update, problem is we don't have natural keys in the data. What options do we have to achieve this ?Also, in general - what are the strategies we can implement to avoid duplicate records in the fact table (if a workflow runs again by mistake)Thanks

Popular White Paper On This

We have a fact table mapping, for which the source is a flat file of say approximately 75K rows - this is a monthly load but the source provider may release the second file in the same month if there are errors in the first file. Business requirement is such that we cannot wait till we get the second file which means as soon as we get a file it has to be loaded into the fact table. And when we get the second file, all the records from the first file can comfortably be replaced with that of the records from the second file based on the dt column. To implement this update, problem is we don't have natural keys in the data. What options do we have to do to achieve this ? Also, in general - what are the strategies we can implement to avoid duplicate records in the fact table (if a workflow runs again by mistake)

Thanks for the valuable input from all of you. Yes, the table is partitioned on monthly basis and we are deleting the last partition if the snapshot_dt in the source and target matches.

Fact table - insert / update strategy

Reply from Siva P | posted Jan 18, 2008 | Replies (10) I think you can create your own key for this.... cant u use the combination of all dimension keys to identify a unique record in your fact table ?? by this you can identify whether an incoming record is an insert of update...

Fact table - insert / update strategy

Reply from palaniappan chidambaram | posted Jan 18, 2008 | Replies (10) Well deleting might turn to be a risky task, probably you can use an ODS(if you have that flexiblity) , which can be refreshed monthly and use batch_id/date and load_id/date and try to retrofit using this. By this way you dont lose info and could account for the changes in that month. But if you know the grain of your fact, i mean the composite primary key(or candidate key) then you can use that to do lookup right. If your flat file has that info then do take them and lookup on target otherwise do transformations to get it to that level and do lookup on target.

Hi, Maybe you could try to partition your fact table on monthly basis and then truncate last partition before loading second file?

Hi Palani, It includes all dimension keys. Problem is there is no natural key in this table to use lookup and update

strategy. As an alternative, I am thinking of using a PRE-SQL to delete the rows from the fact table where the SNAPSHOT_DT matches with the source file SNAPSHOT_DT and insert the rows from the second file after the deletion is complete. But not sure how safe this approach is and also, to delete some 70 K + rows from a fact table that has millions of records - how efficient it is performance wise. Any ideas ? Thanks