Dimension or fact value

Scenario:
Got two dimension (time and organization) linked to a fact table with sickniss facts by persons.
Now i want to add the info 'age class' (like 10-20 year, 21 -30 year.... )
Where to add the new info? Into the fact table or crate a new dimension with one level? I think is must been a new dimension cause, i use it to group the data in the fact table and i won't use it to count the 'age class'. An the other side a one level dimension looks a little bit 'stupid'.
Am i right?
Hope to hear some ideas..... tnx in advanced.

I'd probably, split "Person" out to a dimension and make AGE_GRP an attribute therof (and a type-II change triggering attribute to boot), or a separate dimension.
I can forsee lots of other person-related attributes being things that you might eventually want to filter disease facts on (age / gender / height / weight / ethnicity / job / etc).
Mike

Similar Messages

  • How to get all rows/cols in pivot even if fact values are not available

    If I have a a result set and then pivot on it then only the side/top labels appear for items with fact values. Is there any way to achieve the following :
    Result Set gives the following pivot table
    Area1 Area3
    country 1 100 10
    country 3 200 20
    If there any way to ensure that pivot shows all row and column values and then fills in 0 for the missing facts ?
    ie.
    Area1 Area2 Area3
    Country1 100 0 10
    Country2 0 0 0
    Country3 200 0 20
    hope this makes sense. Basically I have a static format Excel report that the information is exported to and sometimes at the beginning of the month the daily report does not show all rows.
    Thanks
    Kevin

    outer join your dimensions to the facts so that all the dimensions are there

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

  • Dimension and Fact out of Daily Extract File

    Hi Folks,
              We have a third party vendor which provides us with a daily extract of data in an excel file with about 40 columns. Some of the columns are a typical detail info like "State Name", "Payer
    Name" etc. and some are numerical columns like "Billing rate", "Amount Paid" etc.
    Now for long term reporting I want to setup a proper datawarehouse with Dimension and Fact Tables. The issue is that the third party vendor is not giving us access to the database source of these excel extracts.  So, If I want to design a Dimension
    like Dim_Payer, I have only those Payer which are available in the daily excel extract file. 
    I was thinking of doing a reverse ETL process to load Dimension and Fact Table. So I read the daily excel extract file for unique Payer names and then load the Dimension table with unique keys for Payer. Going forward I only add new Payers. I then load the
    Fact tables with these keys.
    Let me know if my approach has any issues.
    Thanks!

    The approach looks fine.
    What you could do is to have a SSIS package using data flow task. In it use a excel source and have a set of lookup tasks to see if payer, state etc exists and link the no match output to OLEDB destinations to insert missing values to the table. Finally
    have a data flow task to insert data to fact table after having lookups with relevant dimensions to get the reference ids.
    Please Mark This As Answer if it solved your issue
    Please Vote This As Helpful if it helps to solve your issue
    Visakh
    My Wiki User Page
    My MSDN Page
    My Personal Blog
    My Facebook Page

  • How to create surrogate key in dimension without unique value

    Hi, I have a dimension where there is no column with unique value. I want to add a surrogate key to replace the existing primary key which is derived from concatenating 3 columns(e.g. 'A'||'B'||'C'). I'm thinking of using sequence. But this won't allow me to link the dimension to fact table. How do I come up with surrogate key under this situation? Thanks. ~Tracy

    I'm actually trying to accomplish something similar myself.
    In my sources I've got two sorts of customers, ones that are directly reported, and ones whose information is provided with sales records (this is stored in module ODS).
    Of course identification is different, but in the datamart (module DWH) I'm sort of forced to use an equivalent way of loading (due to the way it first used to work). To accelerate lookups on dimensions, I copy the ODS surrogate key to DWH dimensions, but this does not work for the 'inbuilt' customers because they do not have a surrogate key in the ODS.
    They DO have means of unique identification, and at first I thought I could concatenate these (also 3) columns to use as identification code. Unfortunately this is VARCHAR2, where the surrogate key is (naturally) NUMBER.
    So now it looks like I'm forced to first build a table in ODS especially for these 'inbuilt' customers and assign a surrogate key (by sequence) to it, this way it conforms to how 'normal' customers are loaded into DWH.
    I guess you'll have to pull of the same trick, i.e. create a table with either only the 'translation' of D-code to a surrogate key or all information that is fed into the dimension, which then can be used as a lookup or as complete source when loading data into your datamart.
    Good luck, Patrick

  • Modelling Time Dimension with Fact Table containing Start Date and End Date

    Hi Gurus,
    I have a time dimension with Year till Date. I have a fact table which consists of Start Date, End Date, Person ID, Department ID.
    How do i design Time dimension with fact table the below scenario
    In the dashboard i have start Month and End month as prompts.
    In the report i need to display Count(Person ID) > Start Date and < End Date along the trend.
    For instance, i have selected Jan-2009 as start date and Apr-2009 as End Date, then i need to display Count(Person ID) of Jan-2009, Feb2009, Mar-2009 andApr-2009.
    I Can not connect Time dimension with only Start Date or only with End Date to get the trend along the months.
    Please advice on the issue which i am having.

    Hi,
    Thanks for the response, Infact i tried using Complex join in physical layer. I have considered Time table joined with Fact table, and used >= and took and alias of the Time table and joined fact table using <=. When coming to BMM, i am not knowing how do i design this as if i merge the both the time dimensiona and its alias into single table, values will not be correct and if i make them as seperate columns. i can not show the trend as both are different columns.
    Can you please let know where i am going wrong.
    Thanks

  • 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

  • One Dimension with Facts at different levels

    I currently have a single dimension with 5 levels. I have two fact tables that both connect to the dimension table but at different levels.
    For example. If we have a Dimension Country -> Region -> City and then two fact tables. One that has facts at the Region level and one that has facts at the City level.
    Is there a way to be able to have an answer that contains facts from both fact tables. So if there was a fact from City and the Region level? Everything I seem to try does not work. Would I have to create an additional aggregate table that aggregates the City level data up to the Region? Or is there a way to show the data at the lowest level and show either nulls or duplicate values for the additional records.
    Any help is greatly appreciated

    This has helped a little. I am now getting values from both levels. However, because i am summing the two values. The value from the upper level is now summing duplicate values. For example.
    Value 1 on its own
    Level1 Level 2 Level 3 Value 1
    1234 10 10 13.05
    1234 20 10 70.00
    1234 20 20 70.00
    1234 30 10 105.00
    1234 30 20 105.00
    Value 2 on its own
    Level1 Level 2 Level 3 Value 2
    1234 10 10 0.50
    1234 20 10 2.00
    1234 20 20 2.00
    1234 30 10 3.00
    1234 30 20 3.00
    What I am getting
    Level1 Level 2 Level 3 Value 1 Value 2
    1234 10 10 13.05 0.50
    1234 20 10 140.00 2.00
    1234 20 20 140.00 2.00
    1234 30 10 210.00 3.00
    1234 30 20 210.00 3.00
    Desired Outcome
    Level1 Level 2 Level 3 Value 1 Value 2
    1234 10 10 13.05 0.50
    1234 20 10 70.00 2.00
    1234 20 20 70.00 2.00
    1234 30 10 105.00 3.00
    1234 30 20 105.00 3.00
    Now, the problem with this is that Value 1 is a fact at Level 2 and Value 2 is a fact at Level 3. I have one dimension table and two fact tables. The join between the fact table for Value two and the dimension table is the same as the join between the dimension table and Value 1 only it is missing the last level of detail.
    I have then set the logical table source content tabs for each fact table to the corresponding levels.
    I thought this would be enough but i still don't get the desired result. I am not sure if this is possible with one dimension table.
    Any ideas would be greatly appreciated.
    Edited by: user10800227 on Jan 11, 2010 12:43 PM

  • OWB Newbie - Joining Dimensions to Fact Tables

    Hello Forum,
    This may seem like a simple question, but the documentation is so lacking that I can't seem to find the answer to "how does the tool" work.
    I am creating a simple data mart starting with a star schema and choosing a deployment option of ROLAP.
    When using the OWB Tool to create dimensions and fact tables, do you need to define your primary business key (coming from your source system) in each fact table for each dimension that will join to that fact table? I am assuming yes, at least at the lowest leaf level of the dimension hierarchy in this case Store_ID. How else would you be able to correctly join a particular sales order record to the store that it was sold in? a simple query that we know our users will execute for reporting purposes. To make myself clear here is a simple example:
    Dimension = Store
    Hierarchy = Store ----> Sales Territory ---->Region ----->Country
    Attributes = Store ID (primary business key), Store_Name, Sales_Territory_ID, Sales_Territory_Description, Store_Manager_Name, Store_Location etc.,
    Cube or Fact Table = Sales Orders
    Measures = sale_price, quantity, drop_ship_cost, sales_tax, etc.,
    Do I also need to create an attribute for Store ID so that when I load each sales order record into the fact table along with it comes it's proper Store ID?
    I understand how the tool uses the surrogate key and business identifier to create a foreign key look-up from dimension to fact table and pull in the correct store description (i.e. name) but unless you have the Store ID as part of the sales record being loaded into the fact table I don't see how the you can traverse the table and join a sales order to it's proper store?
    Can someone who is farther along in the process or has more experience with other components of the tool confirm my assumption or set me straight on how the tool accomplishes this?
    thanks
    monalisa

    Hi Monalisa, I'll reply assuming your using OWB 10gR2.
    First off, for each of the dimensions, you'll define a business key (as you noted below). Then, when you define the cube object, you'll tell it which dimensions you are using, along with the measures you will be storing.
    When you drop a "cube" object into a map, it will show the measures, but it will replace the dimensions with their natural keys. I.e. in your example below, if your sales order cube had ONLY the store dimension, then the cube object will show up in a mapping with the measures of sales_price, quantity, drop_ship_cost, etc., but instead of showing the dimension for store, it will instead show the natural key Store_ID. When you map your data to load (which should be by store_id), OWB will automagically look up the proper dimension keys and do everything else for you.
    Hope this helps!
    Scott

  • Many to Many relationship betwee dimension and fact tanle

    Hello Gurus,
    I have a little question about many to many realtionship between fact and dimension table. The situation is as follows.
    Consider there is a fact table F1 and two dimension tables D1 and D2. D1 is joined to F1 with 1 to many relationship. D1 is joined to D2 with again one to many relationship ( Note: D1:D2 = 1:N and D1:F1 = 1:N). I am able to model this by merging D1 and D2 into one dimension table in BMM layer by adding them as logical table sources and creating logical table source join. I have built simple reports and the data returnned is fine. However, I would just like to know what could be the drawbacks of such a model.
    We have many other dimesions joined to the fact table and users have access to the answers that means they would could what ever report they feel like. Hence, would just like to know in what cases this model could break which means reports would give wrong data because of a many to many relationship between one of the fact and dimension table.
    Thanks in advance.

    Hello Copter,
    Even I had modeled it by reading this link before. In the situation explained by me dimension D1 is doing the job of table Rules ( as explained in link). The model is fine.
    However, my point is to undersatnd in which scenerios this model will break. As already explained, the fact table is joined to various other dimensions, there could be situations in which users select columns from various dimensions and facts randomly.
    Hence, which are the scenerios where I might get erroneous counts of meassures. Further, if someone feels this model is correct and would not break in any scenerio then please reply.

  • 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

  • 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

  • Using Method UPDATE_CONTRACT_OBJECT to Update Facts Value

    Hello,
    I'm using method  UPDATE_CONTRACT_OBJECT to update Fact Values.
    I want to update the content of IT_FACTS-BAPI_CTRACPSOBJECT_FACTS-VALUE_GENERIC  from the FormBundel Header SYS_FORM_BUNDEL_HEADER-PERIOD_KEY.
    After generating the funtion, my mapping is modify by the generation program to T_FACTS-BAPI_CTRACPSOBJECT_FACTS-VALUE_GENERIC = CURRENT_DATE.
    This generates an error message in the method due to existing controls in BAPI_CTRACPSOBJECT_CHANGE.
    There is any way that I could avoid the generation programme to overwrite the mapping? I just want to transfer the value of the period (4 Characters-Ex: 2014) to VALUE_GENERIC?
    Thank you in advance
    Regards
    Carlos

    Hello Tobias,
    More details here, I'm using BRFplus action UPDATE_CONTRACT_OBJECT. Working in Tax Revenue Management.
    Regards
    Carlos

  • Dimensions and facts related to all BI Apps Financials Star Schemas

    I am kind of new to BI Apps and was wondering whether there is a list of tables/dimension names/ facts that constitute each star schema in Financial Analytics?
    I know there are star schemas like AP Aging, AR Aging, AP Transactions, AR Transactions and so on.
    How do I get the OBAW dimension and fact table names that are in each of these star schemas?
    Oracle BI Apps presentations take me only to the business name of the dimensions and does not give me the original dimension name used in OBAW.
    Thanks in advance!

    Hi Sid
    I am in Data Model Reference that you have mentioned. All the star schemas over here are pictures and are not searchable. Also, the ppt that Oracle gave us just says AP Aging as the fact name and I dont know how I can find the fact table corresponding to that.
    If someone can point me for that piece of work, I will go though the star schema pictures in the documentation and find relevant dimensions and facts.
    Is there any naming convention that we can use like W_APAging_F table or something like that??
    Thanks in advance !
    Edited by: user566193 on Jan 21, 2010 2:43 PM

Maybe you are looking for