Data Warehousing Concepts

Showing Questions 1 - 3 of 3 Questions
Sort by: 
 | 
Jump to Page:
  •  

    What are non-additive facts?

    Star Read Best Answer

    Editorial / Best Answer

    Answered by: Praveen

    • Aug 15th, 2005


    # Additive: Additive facts are facts that can be summed up through all of the dimensions in the fact table. 
    # Semi-Additive: Semi-additive facts are facts that can be summed up for some of the dimensions in the fact table, but not the others. 
    # Non-Additive: Non-additive facts are facts that cannot be summed up for any of the dimensions present in the fact table.

    cognos_anu

    • Jun 20th, 2017

    The facts which cannot be summed up across any dimension.
    for e.g. Percentage, temperature

    Srikant

    • Nov 20th, 2016

    Please give me a fact table where I cannot add the percentage. Especially if the percentage is calculated for that particular fact table. Are we saying that percentages stored in the fact table might ...

  •  

    To check the target table for data quality?

    My target table has loaded with 10000 records from source table.
    Now, I want to verify the target table whether it has been loaded with correct data or it has any junk values

    How do I test the above scenario.
    As we can conclude that we cant check each and every record because of huge quantity.

    Anu Sharma

    • Apr 25th, 2016

    First check the count of source and target
    Then select first table minus second table and then we come to know if there is no record coming then values are loaded properly and if there are records appearing after executing the minus query then the records are not uploaded in the target table.

    surendra

    • Jul 9th, 2014

    HI...
    Write the Source query according the Business Logic ,write the target query for the same,export the two queries i.e is source and target to excel and with the help of open source tool db solo are beyond compare tool you can compare field to field and same the count too.

  •  

    How do we maintain Primary key in Fact Table ?

    Is there any option other than Surrogate key or concatenated key?

    Star Read Best Answer

    Editorial / Best Answer

    ravikiranrali  

    • Member Since May-2008 | May 9th, 2009


    Two main reasons to generate and maintain a surrogate key on DW side:


    1. If your DW has multiple sources for a dimension or fact, the PK ID fields can have same values from different sources. The only way you can handle this is by maintaining the composite primary key on these columns. Now lets imagine that you have some 10 dimensions in a subject area, you would expect to have only 10 keys in the Fact, but by having the composite keys you would endup creating 20 or more keys on the fact. This would inturn adversely affect your query performance.

    2. Another case, suppose some data migration activities take place on the source side -- which is quite possible if the source system platform is changed or your company acquiered another company and integrating the data etc -- if the source side architect decides to change the PK field value itself of a table in source, then your DW would see this as a new record and insert it and this would result in data inconsistency /discrepency between the source and DW and it could be a nightmare to fix the issue. By having a separate surrogate key on DW side that is generated based on the grain of the source table (not on the IDs), you are immune to any such PK value changes on the source side.