Reg: Fact table and Dimension table in Data Warehousing -

Hi Experts,
I'm not exactly getting the difference between the criteria which decide how to create a Fact table and Dimension table.
This link http://stackoverflow.com/questions/9362854/database-fact-table-and-dimension-table states :
Fact table contains data that can be aggregate.
Measures are aggregated data expressions (e. Sum of costs, Count of calls, ...)
Dimension contains data that is use to generate groups and filters.
This's fine but how does one decide which columns to consider for Fact table and which columns for Dimension table?
Any help is much appreciated.
Pardon me if this's not the correct place for this question. My first question in the new forum.
Thanks and Regards,
Ranit Biswas

ranitB wrote:
But my main doubt was - what is the criteria to differentiate between columns for Fact tables and Dimension tables? How can one decide upon the design?
Columns of a fact table will often be 'scalar' attributes of the 'fact' data item. A dimension table will often be 'compound' attributes of a 'fact'.
Consider employee information. The EMPLOYEE table can be a fact table. It might have scalar attribute columns such as: DATE_HIRED, STATUS, EMPLOYEE_ID, and so on.
Other related information that can't be specified as a single attribute value would often be stored in a 'dimension' table: ADDRESS, PHONE_NUMBER.
Each address requires several columns to define it: ADDRESS1, ADDRESS2, CITY, STATE, ZIP, COUNTRY. And an employee might have several addresses: WORK_ADDRESS, HOME_ADDRESS. That address info would be stored in a 'dimension' table and only the primary key value of the address record would be stored in the EMPLOYEE 'fact' table.
Same with PHONE_NUMBER. Several columns are required to define a phone number and each employee might have several of them. The dimension tables are used to help 'normalize' the data in the employee 'fact' table.
And that EMPLOYEE table might also be a DIMENSION table for other FACT tables. A DEVELOPER table might have an EMPLOYEE_ID column with a value that points to a 'dimension' row in the EMPLOYEE dimension table.

Similar Messages

  • Fact Table and Dimension Tables

    Hi Experts, I'm creating custom InfoCubes for data coming from non-SAP source systems. I have two InfoCubes. Tha data is coming from like 10 tables. I have 10 DataSources created fo this and the data will be consolidated in Standard DSO before it will flow into 2 InfoCubes.
    Now client wants to know before how much data will be there in InfoCubes in Fact table nad Dimension tables in both the InfoCubes. I have the total size of all the 10 tables from the sources given to me by the DBA. I wan not sure how I can convert that info for Fact table and Dimension table as I have not yet created these Infocubes.
    Please help me with this on how I should address this.

    hi,
    The exact data will be hard to give however you can reach at a round figure in your case.
    You are consolidating the data from the tables that means that there is relation between the tables. Arrive at a rough figure based on the relation and the activity you are performing while consolidating the data of the tables.
    For example, let us say we want to combine data for sales order and deliveries in a DSO.
    Let Sales order has 1000 records and Delivery has 2000 records. Both the tables have a common link (Sales Order).In DSO you are combining the data that means the data will be at the most granular level consist of Delivery data, so the maximum no of records which the consolidated DSO can have is 2000.
    regards,
    Arvind.

  • Fact table and dimension table

    what is the difference b/w fact table and dimension table

    A fact table contains numeric values and also contain composite key(i.e collection of foreign key) e.g.. sales and profit. Typically has two types of columns: those that contain facts and those that are foreign keys to dimension  tables.
    Dimension tables, also known as lookup or reference tables, contain the relatively static data in the warehouse. It contains character values E.g Customer_name,Customer_city.
    Dimension tables store the information you normally use to contain queries. Dimension tables are usually textual and descriptive and you can use them as the row headers of the result set.
    Rachna

  • Where can we see Fact Table And Dimension Table in DataWarehouse Workbench?

    Hai Experts
    where can we see Fact Table And Dimension Table in DataWarehouse Workbench?
    Best Regards
    nvnkmr12

    Hi
    Refer the link below and you will get a comprehensive explanation of how data is stored and modeled in BI. If explains fact table, dimension table, SID table, P and Q , X and Y tables.
    http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/6ce7b0a4-0b01-0010-52ac-a6e813c35a84
    Cheers
    Umesh

  • Oracle Data Compression on SID tables and Dimension Tables

    Hello Community,
    We have had great success with Oracle compression on ODS tables that are no longer loaded.
    We'd now like to move on to other types of BW tables that are very large.
    OSS Note 701235 provides answers to questions concerning the possible use of Oracle compression together with SAP BW.
    But the Note does not give suggestions for (or against) Oracle compression on SID tables or Dimension tables.
    I believe both table types would exhibit the same behaviour : mostly inserts of new SID IDs and new DIM IDs, but few updates to existing SID or Dimension records.  If this is true, then both are good candidates for oracle compression. 
    Do you also agree that this is the typical behaviour for SID tables and dimension tables ?  And that these types of tables are good candidates for Oracle compression in a large BW system ?
    Thanks kindly!
    Keith Helfrich

    Hi all,
    Although this is an old thread I stumbled on during my own investigations I can provide some answers to your questions.
    Table candidates for compression are found by these criteria
           - Table size big enough?
           - Long lifetime of object planned ?
          - No or only rare structural changes for the table   ?
          - u201EUpdateu201C rate low : is your data mostly kind of u201Cread onlyu201D ?
    --               for the wideley used rolling window partition techniques of
                      tables in BW this is not a problem: mostly INSERTu2019s in the
                     current partition not affecting other partitions
    BW tables that can benefit from compression (see SAP notes 105047,701235)
           - PSA tables with data that must be saved for a longer time
           - ODS change log (no Updates of old data, only Inserts of new data)
           - u201Ehistoricalu201C cubes wich get no changes in table structure anymore
    Limitations
             - normal Insert or Update statements are stored ALWAYS in uncompressed
                    format and must be compressed separately ( <= Oracle10g )
             - Slight CPU overhead of compression, butu2026
             --      CPU consumption is more than compensated by doing less I/O as
                   for Bulk loads or parallel processing
             --      SAP BW transformations took a significant amount of CPU for
                       overall load-time into cubes caused by the application server not
                       the database
              - Table must have not more than 255 fields
              - Adding columns with an initial value or dropping columns require
                   uncompression of the complete table (strongest limitation)
    Consider all this above and you can decide that tables that going through UPDATE's are
    not good candidates for compression or tables that can change it's structure (like
    Fact- or DIM tables) .
    Now, my questions to you:
    Wich Oracle version do you use?
    Wich tool do you use for  Oracle compression?
    BRspace (can you give an example ?)
    ALTER ... MOVE COMPRESS
    bye
    yk

  • To find the size of the fact table and dimension table

    Hi experts,
    Can anyone plz tell me if i want to find size of the fact table and size of the dimension table to find cardinality and line item do we first build statistics then find size by transaction DB02 or any other method we have?
    Thanks in advance

    Hi ,
    Please go to Tcode DB02 >Space>Table and Indexes.Give your table name or pattern (like /BIC/F* for gettinf all the Fact tables)
    .This will give you sizes of all the table.
    Also if you want to get list like TOP 30 Fact tables and Dimension Table.Please use TCode ST14, this will give a desired output with all the required details.
    -Vikram

  • Can anyone tell what are the fact tables and dimension tables available in banking domian

    what are the fact and dimension tables available in banking domain.
    maximum how many fact and dimension tables we can keep in the banking project

    Hi Srikanth Korrapati,
    Please have a look on this book
    The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling By Ralph Kimball & Margy Ross.
    Here is the below link completely about the Banking Case Study from DW Toolkit.
    The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling - Banking Case Study
    Hope this will help you out
    Regards,
    Akhileshkiran.

  • How to resolve many fact tables and Dimensions tables

    Hi,
    The scenario is we have many facts and dimension tables. Based on some conditions one measure from one fact will be divided by another fact measure. I have encoutered with many errors like " Unable to navigate .... " ? How to resolve these errors and reduce many to few ? ( I assume creating logical tables, but is there any other alternatives ? )
    thanks
    Suresh

    Suresh,
    I assume that you know how to create a single logical fact from n-physical facts, ie only if the fact tables are related. Then join all the conformed dimensions to this single Logical table using a join in the Business Model layer. Remember to set the mappings in the LTS. All if you have any hierarchies please set the aggregation level for those.
    - Red

  • Sizeof fact table and dimension table

    Hi Experts ,
    Can you tell me how to measure the size of dimension table and fact tables and how to find the ratio of size of dimension table to the size of fact table.
    Thanks in advance,
    Thanks and Regards
    Ram Kommineni

    Hi,
    The ratio of size of fact table to dimension table is ideally should be 10:1. That means the size of the dimension tables should be 10% of the size of the fact table. This serves better in terms of performance.
    Whenever you load any cube, you can easily find out the number of records in fact table (E and F table) and the dimension tables. Based on that statistics you can determine the ratio of size in fact and dimension tables.
    Hope this info helps you.
    Regards,
    Yogesh.

  • Multiple Fact Tables and Dimension Tables

    I have been having some problems trying to model the data from Oracle E-Business Suite maintenance. I will try to give the best description of how the data is held in the tables. The structure is such that a work order can have multiple operations and an operation can have multiple resources as well. I believe the problem comes in the fact that an operation doesn't necessarily need to have a resource. I could not attach an image so I have written out an example below. I am not saying this is right or that it works, but just to give you an idea of what I am thinking. The full dimension would be Organization -> WorkOrder -> Operation -> Resource. Now, the fact tables all hold factual data for the three different levels, with the facts being at each corresponding level. This causes an obvious problem in combining the tables into one large fact table through the ETL process.
    Can anyone tell me if they think this can be done? Am I way off? I am sure that there is a solution as there always is but I have been killing myself trying to figure this one out. I currently have the entire solution in different Business Models. I would like however to be able to compare facts from multiple areas such as the Work Order level and the Resource level.
    Any help is greatly appreciated. I realize that the solution may also require additional work on the ETL side so I am open to any and all suggestions.
    Thank you in advance for anyones time. :)
    Dimension Tables
    WorkOrder_D
    Operation_D
    Resource_D
    Organization_D
    Fact Tables
    WorkOrder_F
    Operation_F
    Resource_F
    Joins
    WorkOrder_D -> Operation_D
    Operation_D -> Resource_D
    WorkOrder_D -> WorkOrder_F
    Operation_D -> Operation_F
    Resource_D -> Resource_F
    Organization_D -> WorkOrder_D
    Organization_D -> Operation_D
    Organization_D -> Resource_D

    Hi,
    Currently the dimension table is taken as a simple logical table in rpd as it does not have have any levels or hierarchy.
    Its a flat dimension. Can you guide me how can I implement a flat dimension in OBIEE? Because this dimension is taken as simple logical table
    I am not able to set appropriate level for fac tables. This dimension does not appear in the list of dimensions.

  • Fact's and dimension tables

    Hi Friend's
    I joined institute to learn OBIEE one of my institute mate has asked me one question that is.
    What will be the Fact and Dimesion tables for Financial projects, please tell me min 6 to 7 tables..
    Regard's
    Anusha

    Hi,
    That depends on the scope and needs.
    I usually have:
    - Account dim
    - Market dim
    - Scenario
    - Year
    - Time
    Then depending on your needsyou might want to add products, etc.

  • How to identify fact and dimension tables

    Hi ,
    We are having the list of parent child relation info for each database tables. Based upon the parent child tables ,needs to identify which table is fact ,which table is dimension .Could you please help me how to identify the fact table and dimensions tables ?
    Thanks in advance

    Hi,
    Refer this link........
    http://www.oraclebidwh.com/2007/12/fact-dimension-tables-in-obiee/
    Please mark if it helps you.......

  • Facts and Dimension tables.

    We have around 6 facts tables and 10 dimensions tables. The ER diagram shows the fact tables are joined. Now how do I arrange these tables in order to form a star schema? Any suggestions?

    You should make Joins (foreign keys) between fact tables and dimensions tables on Physical Layer of Administration Tool. The cardinality should be 1 to N, being 1 in table dimension and N in the fact table.
    Right click on one element of physical layer, and select 'physical diagram' -> 'Object(s) and all joins'. Then appears all tables. To define foreign keys, select icon 'new foreign keys', first select dimension table and second click over fact table to make a cardinality 1:N.
    Good luck,
    Regards.
    Edited by: Hammett81 on Jul 21, 2010 11:14 PM
    Edited by: Hammett81 on Jul 21, 2010 11:22 PM

  • What is FACT table and FLAT table?

    Hello,
             Kindly tell me what is mean by FACT table and FLAT table and how it is use in the BI system ?also tell me can i see these table in the system ?if yes then please tell me the procedure to see the content of the FACT and FLAT table.   And also tell me about the SID table and how to see it.

    Cube consists of Fact tables and Dimension tables.
    The structure of these tables are "Flat".
    Cube consists of two factables... 'F' - Fact table and 'E' - Fact table.
    The naming convention will be..
    /BIC/F<..Cube name..>   for F Fact table
    /BIC/E<..Cube name..>   for E Fact table
    Eg: for cube "EMPLOYEE" the names are..
    /BIC/FEMPLOYEE
    /BIC/EEMPLOYEE
    The dimention tables have naming convention..
    /BIC/D....
    You can check these tables in SE11 or you can use the transaction LISTSCHEMA and then provide the Cube name.
    SID's tables are used to link the master data with the dimention tables.

  • Best practice when FACT and DIMENSION table are the same

    Hi,
    In my physical model I have some tables that are both fact and dimension table, i.e. in the BMM they are of course separated into Fact and Dim source (2 different units) and it works fine. But I can see that there will be trouble when having more fact tables and I e.g. have a Period dimension pointing to all the different fact tables (different sources).
    Seems like the best solution to this is to have an alias of the fact/transaction table and have 2 "copies" of the transaction table (one for fact and one for dimension table) in the physical layer. Only bad thing is that there will then allways be 2 lookups in the same table when fetching data from the dimension and the fact table.
    This is not built on a datawarehouse - so the architecture is thereby more complex. Hope this was understandable (trying to make a short story of it).
    Any best practice on this? Or other suggestions.

    Id recommend creation of a view in the database. if its an oracle DB, materialised views would be a huge performance benefit. you just need to make sure that the MVs are updated when the source is updated.
    -Domnic

Maybe you are looking for