Example of Fact table dataloading

Hi Experts
I'm looking to get  an example of data loading in fact table that will help me to understand fact table concept . Really appreciate if someone provide my mentioned stuff. Thanks
Regards
Muz

Thanks for the link and its really useful and specific but as suggested I need to work with dimension as well so if somebody send me link for data loading dimension and then use these dimension to load data in fact then I really appreciate it.
Hi Muzokh,
You can download very good ETL package samples as well as the DW database tables definition script from the Tools and Utilities of the book - The Microsoft Data Warehouse Toolkit 2nd Edition written by Kimball:
http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/ 
The samples of Chapter 7 should be useful for you.
Regards,
Mike Yin
TechNet Community Support

Similar Messages

  • Logical level in Fact tables - best practice

    Hi all,
    I am currently working on a complex OBIEE project/solution where I am going straight to the production tables, so the fact (and dimension) tables are pretty complex since I am using more sources in the logical tables to increase performance. Anyway, what I am many times struggling with is the Logical Levels (in Content tab) where the level of each dimension is to be set. In a star schema (one-to-many) this is pretty straight forward and easy to set up, but when the Business Model (and physical model) gets more complex I sometimes struggle with the aggregates - to get them work/appear with different dimensions. (Using the menu "More" - "Get levels" does not allways give the best solution......far from). I have some combinations of left- and right outer join as well, making it even more complicated for the BI server.
    For instance - I have about 10-12 different dimensions - should all of them allways be connected to each fact table? Either on Detail or Total level. I can see the use of the logical levels when using aggregate fact tables (on quarter, month etc.), but is it better just to skip the logical level setup when no aggregate tables are used? Sometimes it seems like that is the easiest approach...
    Does anyone have a best practice concerning this issue? I have googled for this but I haven't found anything good yet. Any ideas/articles are highly appreciated.

    Hi User,
    For instance - I have about 10-12 different dimensions - should all of them always be connected to each fact table? Either on Detail or Total level.It not necessary to connect to all dimensions completely based on the report that you are creating ,but as a best practice we should maintain all at Detail level only,when you are mentioning any join conditions in physical layer
    for example for the sales table if u want to report at ProductDimension.ProductnameLevel then u should use detail level else total level(at Product,employee level)
    Get Levels. (Available only for fact tables) Changes aggregation content. If joins do not exist between fact table sources and dimension table sources (for example, if the same physical table is in both sources), the aggregation content determined by the administration tool will not include the aggregation content of this dimension.
    Source admin guide(get level definition)
    thanks,
    Saichand.v

  • Parent member values in Fact tables

    Hello,
    I want to understand something, as far as I know, we can only send data to base level members, right ?
    Then how come we find rows of data that have parent member values in the Fact tables ? (assuming we do not play manually with the database of course), I thought that this can be due to an import with the data manager, can this be right ?

    nilanjan chatterjee wrote:
    Hi,
    >
    > The data for the parent members should be available in the SQL tables.
    > For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
    >
    > Hope this helps.
    I guess you meant should not, right ?

  • Content Tab: None of the fact tables are compatible with the query request

    Hi All,
    **One thing I am not clear yet of all my years with OBIEE is working with the content tab in BMM.**
    I have made a rpd the joins in physical layer as shown below:
    https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056545119428530
    And the BMM layer as:
    https://picasaweb.google.com/114804305606242416264/OBIEEError#5663056519553812930
    Error I am getting when i run a request from the 3 columns from the selected 3 tables is:
    Dim - Comment Code Details
    Fact - Complaint
    Dim - Service Details
    Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14020] None of the fact tables are compatible with the query request Sr Num:[DAggr(Fact - Complaint.Sr Num by [ Dim - Service Details.Sr Cat Type Cd, Dim - Comment Code Details.Cmtcode name] )]. (HY000).
    I get no error for consistency.. I read everywhere and I know i need to set the appropriate aggregation levels in the various dims and facts LTS properties to help OBIEE understanding our model, but how to do that.. how do i decide... how should I approach, what should be the aggregation level, what details.
    When i click More button i see different options: Copy, Copy From, Get Levels, Check Level, what do these mean.
    Aggregation Content, group by - Logical Level or Column which one should i choose and how should I decide.
    Can anyone explain the Content Tab in details and from scratch with some example and why we get these errors.... I know many people who are well versed with many other things related to RPD but this. A little efforts of explaining from you guys will really be appreciated.
    Thanks in advance,
    Dev

    Hi Deepak,
    Option 1:
    My tables in physical layer are joined as below:
    D1--> F1 <--D2--> F2 <--D3
    Same way i model it in BMM
    D1--> F1 <-- D2--> F2 <--D3
    Here D1 is non Conformed Dimension for F2 and D3 is non Conformed dim for F1. Later create Dimensional hierarchies, I tried setting up the content levels
    I go Sources>content tab of Fact F1 I set
    Dimensions----------- Logical level
    D1---------------------- D1 Detail
    D2---------------------- D2 Detail
    D3---------------------- D3 Total
    then, I go Sources>content tab of Fact F2 I set
    Dimensions----------- Logical level
    D1---------------------- D1 Total
    D2---------------------- D2 Detail
    D3---------------------- D3 Detail
    Then, I also go in all the dimensions and set their content levels to Details, but it still gives me errors not sure where I am going wrong in setting the content levels.
    I need to know whether the way I have modeled it in BMM is right,
    Option 2:
    I can combine the two facts in a single Logical Fact or the above design should also work.
    (F1&F2)<--D1, D2 , D3 joined separately using complex logical joins.
    what will be the content tab details?
    Thanks,
    Dev

  • No Message: Write to Fact table.

    Hi ALL,
    Source: ECC 6
    Target: BI 7.3
    We are Transferring 2LIS_13_VDITM Datasource---->> 0SD_CO3 Infocube .
    After Data Replication ,
    1. Data Transferred to PSA .
    2. During Transformation Creation Manuel Mapping is performed . Activated .
    3. During DTP Creation Only Following Warning Messages Occur , Status s not Transferred to Green .
    Data is not coming Cube , No Error Messages. (Totally 29000 Records have to transfer to BI Cube)
    Warning Messages are,
    1.No Message: Write to Fact table.
    2.No Message:Infocube Update Completed .
    What is the Problem?

    Hi,
    Have you set the Industroy sector before uploading the set up tables?
    For more information refer the note: 353042
    Summary
    Symptom
    Fields BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG, etc. of DataSources 2LIS_02_SCL, 2LIS_02_ITM, 2LIS_03_BF, 2LIS_03_UM, 2LIS_40_REVAL are not filled.
    This may lead to the following:
    The system does not perform any update into an InfoCube (for example: 0RT_C*, 0PUR_C01, 0CP_PURC1 and so on), even though data arrives in BW.
    This occurs with the following InfoSources:
    2LIS_02_SCL, 2LIS_02_ITM
    2LIS_03_BF, 2LIS_03_UM
    2LIS_40_REVAL
    With some restriction, this symptom also occurs with the following InfoSources if they are used in connection with retail or consumer products. (InfoCube: 0RT_* or 0CP_* ).
    2LIS_11_VAITM, 2LIS_12_VCITM, 2LIS_13_VDITM
    Other terms
    0PROCESSKEY, PROCESSKEY, 0RT_C01, 0RT_C02, 0RT_C03, 0RT_C04, BWBRTWR, BWGEO, BWGEOO, BWGVP, BWGVO, BWNETWR, BWMNG
    Reason and Prerequisites
    The process key (0PROCESSKEY and 0BWAPPLNM) of the InfoSources has not been filled. As a result, no key figures are updated because of the update routine of the participating InfoCube and along with it no records are inserted into the InfoCube. In each update routine, the system checks the content of the PROCESSKEY. If this field has no contents, then no data is written into the InfoCube because of the IF condition in the update rules.
    Solution
    So that you can work in the above mentioned InfoSources, you MUST activate the determination of the process key. This is done with the help of Transaction MCB_ which you can find in the OLTP IMG for BW (Transaction SBIW) in your attached R/3 source system.
    Here you can choose your industry sector. 'Standard' and 'Consumer products' are for R/3 standard customers, whereas 'Retail' is intended for customers with R/3 Retail only.
    You can display the characteristics of the process key (R/3 field BWVORG, BW field 0PROCESSKEY) by using Transaction MCB0.
    If you have already set up historical data (for example for testing purposes) by using the setup transactions (Statistical Setup Programs) (for example: Purchasing: Tx OLI3BW, material movements: OLI1BW) into the provided setup tables (for example: MC02M_0SCLSETUP, MC03BF0SETUP), you unfortunately have to delete this data (Tx LBWG). After you have chosen the industry sector by using  MCB_, perform the setup again, so that the system fills a valid transaction key for each data record generated. Then load this data into your connected BW by using 'Full update' or 'Initialization of the delta process'. Check, whether the system updates data into the involved InfoCubes now.
    If all this is not successful, please see Note 315880, and set the application indicator 'BW' to active using Transaction 'BF11'.
    Related notes:
    157317 --> You MUST make sure that this note is relevant for you.
    352344 -> Process key + reversals in Inventory Management
              (Consulting note).
    Regards,
    Anil Kumar Sharma .P

  • Transaction data can be loaded into the Fact table without loading the

    Transaction data can be loaded into the Fact table without loading the corresponding master data (Example : Sales analysis transaction data can be loaded without populating any of its  dimension’s master data)
    a.     True
    b.     False

    Hi Kutti,
    True - You need to select the option in the infopackage - alwyas load even if no master data exists.
    Bye
    Dinesh

  • "Select" Physical table as LTS for a Fact table

    Hi,
    I am very new to OBIEE, still in the learning phase.
    Scenario 1:
    I have a "Select" Physical table which is joined (inner join) to a Fact table in the Physical layer. I have other dimensions joined to this fact table.
    In BMM, I created a logical table for the fact table with 2 Logical Table Sources (the fact table & the select physical table). No errors in the consistency check.
    When I create an analysis with columns from the fact table and the select table, I don't see any data for the select table column.
    Scenario 2:
    In this scenario, I created an inner join between "Select" physical table and a Dimension table instead of the Fact table.
    In BMM, I created a logical table for the dimension table with 2 Logical Table Sources (the dimension table & the select physical table). No errors in the consistency check.
    When I create an analysis with columns from the dimension table and the select table, I see data for all the columns.
    What am I missing here? Why is it not working in first scenario?
    Any help is greatly appreciated.
    Thanks,
    SP

    Hi,
    If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
    1. Create dimensional hierarchies for all dimensions.
    2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
    When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
    Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
    Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
    So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
    So, I request you to try these settings and let me know if it works.
    Thank you,
    Dhar

  • 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.

  • Issue with Multiple LTS for a fact table and filters

    Hello,
    I am facing an issue with obiee 10g.
    In my model, I have a huge FACT table F1 (partitioned and indexed). The average response time for the queries, which targeted it, was ~30-60 seconds, which was not really convincing our end user.
    So, we decided to create a materialized view, which removes some dimensions that are not used by default, but might be used if the end user adds some filters. I added the Materialized view in the Physical Layer and in the corresponding Logical Table Source.
    I then tried to see if it works, but I was a bit surprised by the result. Indeed,
    -> If the report does not reference a truncated dimension, it targets the materialized view. -> Perfect
    -> If the report does reference a truncated dimension in the columns, it targets the Fact Table. -> Perfect
    -> If the report does reference a truncated dimension in the Filters, it targets the materialized view. For this reason, the filter is never resolved and no join on the dimension table is applied, whereas it exists in logical SQL generated. -> Ko.
    A suggestion could be to add the filters into the columns, but I am not satisfied by this response because it will never use the materialized view in that case.
    An other suggestion could be to use query rewrite, but I 'd like to have the full control on the generation of the queries.
    Does someone know if the filters are not evaluated to determine which LTS to use? How can I force this evaluation?
    Regards,

    Hi,
    If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
    1. Create dimensional hierarchies for all dimensions.
    2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
    When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
    Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
    Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
    So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
    So, I request you to try these settings and let me know if it works.
    Thank you,
    Dhar

  • 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.

  • How to combine multiple fact tables and dimensions in one worksheet?

    Hello Forum,
    I am encountering a reporting problem when trying to create a worksheet that uses more than one cube/fact table and common dimensions. I have used Oracle Warehouse Builder 10Gr2 to design and deploy a pretty simple ROLAP data mart. We are using Discoverer Plus for OLAP as our reporting tool. We have 5 dimension tables using a star schema and 3 fact tables, when I create the worksheet I bring in our sales measure from our sales item table and then Store_Name from my Stores Dimension and then day from my time dimension, everything looks good at the stage, we're just trying to get a sum of all sales for that store on that day. Then I bring in a measure from our advertising cost table and a join window pops up asking which join to use, if I choose either the Store or the Time dimension I get correct data for the first fact table (sales) and grossly incorrect data for the ad cost measure from the second fact table (advertsing costs)...... any help would be appreciated

    You have encountered one of the key limitations of Discoverer... which I complained about to the Discoverer product manager at OpenWorld in 2001....
    Anyhow, to get around this, you are going to have to deal with it either in the database, (views, materialized views, tables), or within the admin tool by creating a custom folder.
    Discoverer also calls this the "fan trap", but never really had a solution to the problem. [The solution only worked is you joined to one and only one dimension!]
    What you want (using Sales_Fact and Inventory_Fact as an example) is to join Sales to Time, Store, and Product, and save that result. Then join Inventory to Time, Store, and Product, save that result, then do a double outer join between the two intermediate temporary tables in order to calculate something useful like inventory turns by store and product line.
    This is also known a "multipass SQL", and is supported by some (but not many) other tools.
    So, to accomplish this with Discoverer, you'll either need to create a view, or table, or materialized view that has already put Sales and Inventory into a single (virtual?) fact table. Alternatively you can write the SQL for how to do this linkage (don't forget to handle missing data), and use the Discoverer admin tool to create a custom folder that uses your SQL.
    Hope this helps!

  • How to create a ROLAP Cube that has two fact tables.

    I want to know if it is possible to create a ROLAP Cube with two fact tables.
    Suppose that I have these two star schemas:
    The first star schema has only a measure and a time dimension. The time dimension has three levels (Year -> Month -> Day)
    The second star schema has the same measure of the first schema and a time dimension. In this schema the time dimension has only two levels (Year -> Month). The values of the measure of this schema come from the first schema, this is, the value of the measure for a defined year and month results of the sum of all fact values of the first schema, that have the same year and month.
    I want to know if is possible to create a ROLAP cube that can get the information of the two star schemas, according to the level that the user are consulting.
    For example, if the user consults the cube with "OracleBI Spreadsheet Add-In", and if the user is consulting the first two levels (Year and Month), then the ROLAP cube would get the information of the second star schema.
    But if the user does a drill down in a month to get information of the days, then the ROLAP cube would get the information of the first star schema.
    Is it possible to do this?
    Regards,
    Rui Torres

    I'm not exactly sure what you want to do. Sorry if I get this wrong.
    You have two fact tables, one with data values at the day, month and year levels and a second fact table with data values at just the month and year levels. If this is the case, in the CWM2 APIs or OWB Paris, you would create a view that joins the two tables together and then map this view to the ROLAP cube.
    For CWM2 details, please refer to the Oracle OLAP Reference.

  • How to set db schema in fact tables

    Hi!
    I have one mapping with one table(table1) pointing to one fact table (fact1).
    This fact table has two dimensions located in two different schemas. I already deployed those dimensions and tables and its ok.
    My problem is: when I open the mapping editor and ask to generate the mapping to create the package to populate the fact table,
    I can see why I can not deploy it (PL/SQL: ORA-00942: table or view does not exist).
    My query is: SELECT (fields) FROM schema.table1, table2 ,table3 WHERE....
    I cant set the schema property from my table (table1), but I cant´t do the same with the table2 and table3 (both tables related to dimensions). i don´t have this option!
    I don´t understand why this happen because both dimensions are ok. They are in two different modules and the locations are ok too.
    I understand that the mapping needs the dimension keys to populated the fact table, but I really don´t know how to set this schema property. If i can´t do that,
    i don´t know how to "fix" this problem. If a can´t set this schema property, how can I deploy this mapping whitout this???!!!!
    I´m using the 10.2 version.
    Thanks o lot!!!!!!!!!!!

    This is what really happens in my example.
    Look the "Generation Results" :
    SELECT
    /*+ ORDERED NO_MERGE("INGRP1") */
    "TEMP_TABLE"."Value1" "Value1",
    "TEMP_TABLE"."Value2" "Value2",
    "DIMENSION1"."ID" "ID",
    "DIMENSION2"."ID" "ID"
    FROM
    "SCHEMA"."TEMP_TABLE" "TEMP_TABLE", -> I CANT SET THIS schema
    "DIMENSION1" "DIMENSION1", -> i can´t do the same here
    "DIMENSION2" "DIMENSION2" -> i can´t do the same here
    WHERE
    ( "DIMENSION1"."DIMENSION_KEY" = "DIMENSION1"."ID" ) AND
    ( "DIMENSION1"."ID" IS NOT NULL ) AND
    ( "DIMENSION2"."DIMENSION_KEY" = "DIMENSION2"."ID" ) AND
    ( "DIMENSION2"."ID" IS NOT NULL ) AND
    ( "DIMENSION1"."key" = "TEMP_TABLE"."key" ) AND
    ( "DIMENSION2"."key" = "TEMP_TABLE"."key" )
    I already tried to use 3 DB-Modules but I have the same problem. :o(
    I don´t know what to do!!!!!!!

  • Few dimension values used in FACT tables.

    Hello all,
    We are trying to know if somebody faced this issue earlier. We have dimension tables containing 5 million records, but the fact table uses hardly 30k of these dimension values. The fact table contains 350 million records, so is there any way to improve the performance of the query in such a scenario, where hardly 20% of dimension values are actually used by the FACT tables.
    Thanks and Regards,
    Upendra

    nilanjan chatterjee wrote:
    Hi,
    >
    > The data for the parent members should be available in the SQL tables.
    > For example, 2011.TOTAL is parent member. You should not have any data for this member in your database. If it is there, it might have come somehow (may be an import). But this is not right. You might want to remove these records. But be sure that you dont delete the records for the base level members.
    >
    > Hope this helps.
    I guess you meant should not, right ?

  • Fact table design advice

    Good Morning All,
     I'm working on developing a cube that measure's budget and actual cost for a customer that I'm working with. We have serveral dimensions that comes into play:
    Organization - this dimension defines the various internal departments at the customer location where each department sets a budget or actual cost for each month.
    DateTimePeriod - this dimension defines the transaction date when the budget or actual cost was recorded. This dimension contains year, quarter, month and day columns.
    Expense Item - this dimension defines a specific expense item that a budget and actual cost is assigned too such as rent, utility, software licences,etc...
    Cost Type - this dimension defines if the cost within the fact table is a budget or actual cost.
    Within my fact table I store primary key fields values for each of the dimension table listed above. Included with this table is a cost column that represents the budget or actual cost. The problem that I'm having is....The budget cost and actual cost are seperate
    records...For example, I have one record that has the budget cost and then I have another record that has the actual cost....
    My feeling is that the budget and cost records should be store on same record instead of seperate records. Also I would like note we're using PerformancePoint to surface the cube data to the client and both the budget and cost needs to drill down to the
    month level only for phase 1. I have a feeling that the customer would want in the in future to measure down to the day level...
    So my question is....What is a better design:
    Keeping the actual and budget costs within a fact table on seperate rows using the Cost Type dimension to identify if the cost is a budget cost or an actual cost or....
    Keeping the actual and budget costs within a fact table on the same row and removing the need for a Cost Type dimension......
    Please help...
    Make sure you mark my reply as the answer if it had solved your request. Brandon M. Hunter MCTS - SharePoint 2010 Configuration

    Why? Wouldn't be easier if I make a database change and add the budget and actual cost on the same row??What would be the advantage or disadvantage to your approach???
    As per my experience, there could be more than one version of a budget value. Initially we start with budget for an account, and then have the actual for the same account for the same period. If we 100% sure that we get only these two versions (Budget and
    Actual) then upto a certain point, two columns implementation is fine. What if the budget is revised, how do you hold it, adding another column? What if you need to maintain a forecast value for same account, same period, create another column for that? Considering
    all accounting and budgeting scenario, I still suggest to have multiple rows for all these versions (or scenario, or cost type). Again, refer AdventureWorksDW for seeing this implementation.
    Since you are going to build a cube from this, you can easily view accounts recorded like this (which is mostly viewed by business users when analysing accounts). It is an advantage too.
    In terms of disadvantages, I see only one disadvantage which is storage cost.
    Dinesh Priyankara
    http://dinesql.blogspot.com/
    Please use Mark as answer (Or Propose as answer) or Vote as helpful if the post is useful.

Maybe you are looking for

  • Checkboxes in PDF output (on AIX)

    All, I've been through many of the posts on Checkboxes and many of them seem to concern the same issue (I'm getting the tiny diamond shapes instead of the square boxes we all expect as a 'standard' checkbox), however I have a complicating factor in t

  • What are the different functions used in sap script?

    Hi, What are the different functions used in sap script? What are the parameters used in each Function? Regards, Mahesh

  • Can't download apps from ovi store

    Hi, i have a nokia 5530 xm i had some corrupted music files in my music library so i made a back up-file on the computer and erased everything on the memorycard Then i loaded all the stuff back on the memorycard. But then almost all my apps were gone

  • .MOV won't play on QT 7.x

    .mov and .avi files used to play fine on QT. But somewhere along the way with the QT upgrades they now don't. The video is almost stop-action now. However, .mpg play flawlessly. I do not understand why .mov, which is the QT format, can't be played on

  • Burst handshaking mode timin diagram

    I am using the 6533 card in the burst-handshaking input mode.Clock signal and data signal triggering the daq-card are sychronised and alighned .Looking in the timing diagrams of the manual, a "setup time from input data valid to PCLK", t_dis, of 4 na