What is technical advantage 0f having 16 dimension tablefor an fact table

Hi ALL,
  Clarify my doubt.
Regards
DEEPAK

Hi Sudhir,
the limit of 16 key fields comes from the underlying DB ... Most of them do not support more. There is no difference from this point of view using different DBs becauses SAP abstracts the underlying DB BUT does consider their "common" limits, so it's built considering that an ABAP table can't be formed with more than 1 key fields, because some DB don't support this requirement.
As far it concerns the consideration of 248 Chars per Dim ... in a Dimension table there is a surrogate DIMension ID (DIMID) as a key field! Characteristics are "attribute" fields. So this limitation hasn't the same cause.
Hope it's clear
GFV

Similar Messages

  • 3 confirmed Dimensions and 2 fact tables

    Hi experts,
    how can we connect 3 confirmed Dimensions and 2 fact tables without loops and traps please give me a solution

    Hi,
    Dimensions Tables : Dimension tables are typically small, ranging from a few to several thousand rows. Occasionally dimensions can grow fairly large, however. For example, a large credit card company could have a customer dimension with millions of rows. Dimension table structure is typically very lean, for example customer dimension could look like following:
        Customer_key
        Customer_full_name
        Customer_city
        Customer_state
        Customer_country
    Fact Tables :a fact table consists of the measurements, metrics or facts of a business process. It is often located at the centre of a star schema or a snowflake schema, surrounded by dimension tables.
    Fact tables contain keys to dimension tables as well as measurable facts that data analysts would want to examine. For example, a store selling automotive parts might have a fact table recording a sale of each item. The fact table of an educational entity could track credit hours awarded to students. A bakery could have a fact table that records manufacturing of various baked goods.
    Context Versus Alias Overview :
    http://www.dagira.com/2009/07/22/context-versus-alias-overview/
    How to create context :
    http://www.bidw.org/business-objects/universe-design/understanding-context-and-its-use-in-business-objects-universe/
    You can also look on the eFashion universe for more information.
    Thanks,
    Amit

  • How many line item dimensions can a fact table have?

    Hi,
    How many line item dimensions can a fact table have? Is it tht Max of 16 dimensions(13+3) .Does the 16 dimensions include line items dimensions as well .
    Pls reply.
    Thanks
    Praveen

    It includes all dimensios, including line item dimensions.
    If you have line item dimension, pl note you cant assign any other characteristic to that dimension.
    Ravi Thothadri

  • What is correct way to join a start/end date driven dimension to a fact table in data foundation?

    I have a bad universe or a data design issue. 
    Several versions of hierarchies reporting store entities in reporting Fact measures.
    Example of date driven Hierarchy Dimension:   ORG_KEY
                                                                                START_DATE
                                                                                END_DATE
                                                                                STORE_NUMBER
                                                                                ORG_HIERARCHY   
                                                                                CURR_FLG   (Y/N)        
    Fact table  :                                                         ORG_KEY
                                                                                 CALENDAR_KEY
                                                                                 TRANS_DATE
                                                                                 $amount  
    Calendar Dimension:                                            CALENDAR_KEY
                                                                                  DAY_DATE
                                                                                   FY_WEEK          (201452)
                                                                                    FY_PERIOD      (201412)
                                                                                    FY_QUARTER   (201401)
                                                                                     FISCAL_YEAR    (2014)
    Users WISH:
    Wish for store number and org hierarchy to pull as of the last day of each pull without prompt.    The Store(ORG_KEY) as in the fact table; but the ORG_HIERARCHY and other attributes as of the last day they pull.
    Daily (Would be Calendar.Day_Date in Filter) ,
    Week to date (would be Max Calendar.Day_Date for (201452) FY_WEEK  as entered,
    Month to date,
    Year to date, 
    AdHoc queries.  
    My problem is I see how they could manually pull this in Webi.   I have tried everything I know to join to no avail.  I have not gotten @Prompts to work in joins, derived tables, etc.  in the data foundation.  Wonder what is difference between parameter in Data foundation vs. filter in buisness layer.    None of them worked. 
    Please help!   ANY ideas would be appreciated.   .

    {Note that abbrevations in brackets are just for short form further down the answer}
    Join Store Dim (SD) to Transaction Fact (TF) on ORG_KEY=ORG_KEY with 1 to Many cardinality
    Create an alias of Calendar Dim and call it Transaction Date (TD)
    Join TD to TF on TD.CALENDAR_KEY=TF.CALENDAR_KEY with 1 to Many cardinality
    Create a predefined condition in your universe called "Return Yesterday's Transactions" as:
    TD.DAY_DATE = trunc(sysdate-1) <-- That assumes Oracle database; use whatever is correct for yesterday for your RDBMS
    The above predefined condition when added to your data query will return only yesterday's transactions.
    However, if you want to return all the different types of sales, you would need an object for each one. To do that, you'd use a case statement. Again, using Oracle syntax, an example of MTD would be:
    SUM(CASE WHEN trunc(TD.DAY_DATE,'yyyymm') = trunc(sysdate,'yyyymm') THEN TF.amount END)
    If you have any more questions about how this approach would work please shout.
    As an alternative, you could create a time hierarchy and add scope of analysis to your report for it and enable drilling at report level.

  • What is the best practice for creating primary key on fact table?

    what is the best practice for primary key on fact table?
    1. Using composite key
    2. Create a surrogate key
    3. No primary key
    In document, i can only find "From a modeling standpoint, the primary key of the fact table is usually a composite key that is made up of all of its foreign keys."
    http://download.oracle.com/docs/cd/E11882_01/server.112/e16579/logical.htm#i1006423
    I also found a relevant thread states that primary key on fact table is necessary.
    Primary Key on Fact Table.
    But, if no business requires the uniqueness of the records and there is no materilized view, do we still need primary key? is there any other bad affect if there is no primary key on fact table? and any benifits from not creating primary key?

    Well, natural combination of dimensions connected to the fact would be a natural primary key and it would be composite.
    Having an artificial PK might simplify things a bit.
    Having no PK leads to a major mess. Fact should represent a business transaction, or some general event. If you're loading data you want to be able to identify the records that are processed. Also without PK if you forget to make an unique key the access to this fact table will be slow. Plus, having no PK will mean that if you want to used different tools, like Data Modeller in Jbuilder or OWB insert / update functionality it won't function, since there's no PK. Defining a PK for every table is a good practice. Not defining PK is asking for a load of problems, from performance to functionality and data quality.
    Edited by: Cortanamo on 16.12.2010 07:12

  • Conformed dimensions across several fact tables

    Hi, not exactly sure how to phrase my question, so I'll just start babbling and maybe it'll come across. In our OBIEE repository (from BI applications "project analytics"), we have dimensions of CONTRACT, CONTRACT LINE, PROJECT, and TASK (CONTRACT and CONTRACT_LINE really come from a single dimension table, but are different rows and so really can be thought of as coming from two different dim tables). TASKs are really children of projects - but they were broken out into a separate dimension in the data model (no idea why....). Also, in our business, a task can be tied to one and only one contract line.
    Now here's the rub - because TASK is a separate dimension from PROJECT, there is really nothing that relates them except through a fact table. This is a real pain, as it has two limitations:
    1) If a "fact" for that combination of PROJECT / TASK hasn't happened yet, then no row in fact table = nothing that says they are related
    2) Even if you do have a fact for everything - now our query is scanning through a fact table of (in our case) 300+ million rows, just to say which task is tied to which project
    I'd like to solve this by creating a very simple "factless fact" which has columns for CONTRACT, CONTRACT LINE, PROJECT, and TASK, and simply inserts the appropriate surrogate IDs (wids) into this. Thus, instead of a 300+ million row fact table, we should be down to only 400,000 or so task / project / line / contract combos.
    Now here's my question: I have a "combined" subject area that includes a project cost, project revenue, project billing, and in theory this new fact table I'm talking about. I'd want to set the new fact table to be the "implicit" fact - so that if someone just asks a questions like "show me contract lines, and which projects and tasks are assigned to it" - it would go to the new, slim, fast fact table.
    But I'm concerned about what happens when someone then throws in a cost amount, revenue amt, etc. onto the query. I'm assuming that OBIEE will be smart enough to understand it should forget the implicit fact, and start using the "real" facts. Or maybe use all of them including the new fact.
    I'm just trying to see if I can anticipate this causing any issues.
    Thx,
    Scott

    You are correct, the implicit fact will only be used when there isn't any other fact measure defined in your query. Unfortunatelly you can only define an implicit fact per SA, we would love to be able to have more flexibility such as defining them per dimension etc. Another way to "force" OBIEE to select from an specific fact is to select a column from it in your Answers query. You don't to see this column in output so you can hide it. Of course this "hack" is not really very user friendly as it makes adhoc query building much more complex.

  • Relationship between Dimension without linking Fact table

    Hi,
    My question is like I have five dimensions connected to a fact table through primary - foreign key(Composite Key) relationship. Will this referential integrity help if I want some information between two dimension which are not linked directly and I am not
    including any measures from fact table .
    Example: Suppose I have customer, Product and Manufacturer Dimensions all linked to a fact table but  not linked to each other directly  but can I get right result when I want to know what are the manufacturer for each product? or list of
    customers using a particular product. Will the referential integrity work ? since they all are related in fact table.
    regards
    Sanjoy ghosh 

    Hi Sanjoy -
    The answer to your questions depends on your dimensional design and exactly what the fact table represents.  Fact tables naturally capture the intersection of the different dimensions.  This is true whether you physically implement a
    PK - FK relationship in the relational db.  
    In your case, since customer is involved, sounds like a sales transaction fact.  If that's true, you can easily join from customer, through the fact, to the product dimension, to get the list of customers that purchased a particular product.
    For the manufacturer for each product, a sales transaction fact will not necessarily answer this question completely.  Particularly in the case of products that have no sales for a given period, and thus, don't have any fact records to join from manufacturer
    across to product.  If you need to solve this question, you have some other options:
    - flatten the Manufacturer directly into the Product dimension as attribute of the product (probably the simplest approach and allows you to remove a key from the fact)
    - embed the Manufacturer key directly in the Product dimension (if you need the Manufacturer dimension separate for use with other events / facts and more detailed dimensionality - i.e., detailed attributes about the Manufacturer that wouldn't need
    to be flattened onto the product)
    - build a factless fact that captures the products offered by a given manufacturer at a given point in time (perhaps representing various products catalogs and associated dates.  This would allow you to capture rich details about each dimension separately
    and use the factless fact to record)
    Let me know if that helps.
    Brent Greenwood, MS, MCITP, CBIP
    // Please mark correct answers and helpful posts //
    http://brentgreenwood.blogspot.com

  • Problem using same dimension in 2 Fact tables

    Hi,
    I am facing this strange problem with the out-of-box BMM metadata mapping :
    The "Dim_W_GL_ACCOUNT_D" is joined to "Fact_W_GL_OTHER_F" and "Fact_W_GL_BALANCE_F" facts. Both these fact tables have a inner join to "Dim_W_GL_ACCOUNT_D". The change I have made in th BMM is - I added 2 new logical dimensions DimA and DimB and joined these to the above 2 fact tables.
    The O-O-Box "GL Account Balance" Report works fine which has 3 logical columns (GL Account Number, Financial Statement Item, GL Account Category) from the "Dim_W_GL_ACCOUNT_D" and 1 Fact column "Closing Amount" which points to the "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" fact.
    When I add 1 logical column each from my 2 new Dims I created, the report output shows the Fact column "Closing Amount" as $0.0. Upon investigating the log, the query shows it is using the "Fact_W_GL_OTHER_F" instead of "Fact_W_GL_BALANCE_F" fact which has the "Closing Amount" column. I am not sure how. When I drop the logical column "GL Account Number" and keep my 2 new logical columns in the request, the "Closing Amount" is shown correctly. I also saw there is a Dim Hierarchy for "GL Accounts" --- the "GL Account Number" is on a lower level than the "Financial Statement Item" and "GL Account Category" columns from the same logical dimension table which are 1 level higher.
    How do I make the request pull data at the "GL Account Number" level and still have the query fetch data from "Fact_W_GL_BALANCE_F"."BALANCE_GLOBAL1_AMT" (Closing Amount) with my 2 new logical columns included?
    Any help is appreciated. Thanks a bunch.

    The dimensions I added are aliases of their respective W_XXX_D tables and I have the content levels set for the LTS of my Dims (DimA and DimB) at the detail level. One thing I am not able to figure out is why is it going after "W_GL_OTHER_F /* Fact_W_GL_OTHER_F */" when it should go to W_GL_BALANCE_F and W_GL_BALANCE_A.
    The "GL Account Number" is sourced from the W_GL_ACCOUNT_D table and the other columns "Fin Statement Item" (FIN_STMT_ITEM_CODE) and "GL Account Category" (GL_ACCOUNT_CAT_CODE) are sourced from that same table too. But these 2 cols are on a higher level of hierarchy than the "GL Account Number" in the "GL Accounts" Dim-Hierarchy. But, as soon as I remove the "GL Account Number" logical column from the report the closing amounts show fine although the "Fin Statement Item" and "GL Account Category" cols from the W_GL_ACCOUNT_D table remain. Then the query does not show the W_GL_OTHER_F table in the log. Is there something I need to do to this dim-hierarchy?

  • What is the prerequisite for creating two hierarchies from one fact table i

    Hi,
    what is the prerequisite for creating two hierarchies from one a single fact table.
    Rgds,
    Amit

    create global temporary table t1 as select * from trn_ordbase on commit preserve rows;You CANNOT use this syntax.
    http://download-east.oracle.com/docs/cd/B19188_01/doc/B15917/sqcmd.htm
    http://download-east.oracle.com/docs/cd/B19188_01/doc/B15917/glob_tab.gif
    http://download-east.oracle.com/docs/cd/B19188_01/doc/B15917/cre_tabl.gif

  • What are the main advantages of having multiple WLS_FORMS instance servers?

    Hi,
    I know it's possible to deploy multiple instance weblogic forms servers (WLS_FORMS). What are the advantages of having multiple instance of forms server?
    When we deploy forms&reports 11g the configuration process creates WLS_FORMS and WLS_REPORTS. Is there any advantage of having under the same physical server more than one WLS_FORMS server?
    Regards
    Ricardo

    The exact advantages and disadvantages will depend on exactly how you configure your environment. Remember that everything good comes with a price. So for example, you can add additional managed servers to improve scalability, but doing this means consuming more system resources. So although you may now be able to service twice as many users, it may have cost you 1gig of RAM or more (just an example).
    I would recommend taking a look at the documentation as it offers a pretty good high level view of the possible configurations and their advantages. Here is a good starting place:
    http://download.oracle.com/docs/cd/E14571_01/web.1111/e13716/understand_domains.htm
    The complete documentation set for FMw 11.1.1.3 and WLS 10.3.3 can be found here:
    http://download.oracle.com/docs/cd/E14571_01/index.htm

  • What is the advantage of an iCloud mail account?

    I recently updated to iOS 5 on my 64GB iPad 2 +3G. I signed up for iCloud using the same Apple ID I have been using all along.
    I was also able to create a new iCloud mail account using @me.com.  What is the advantage of having this new email account?
    I kind of understand the function of iCloud. It enables me to access the same content via all my iOS devices.  If I have a photo in my iPad 2, for example, iCloud could push that same photo to my iPhone if I had one.  (It is not much use to me now as I have no other devices besides my iPad 2. I guess I could use the computer at the library and access stuff at iCloud.com.)
    The two email accounts I already have are already accessible using other devices.
    I can access the same Yahoo account using my iPad 2, an iPhone, or a computer at the local library. So, why do I really need this iCloud account?
    I have seen postings from others who have had prior Apple IDs, @me.com accounts, and something called MobileMe. My head spins when reading those posts.
    I am new to the Apple world, so luckily I don't have those problems concerning the use of previously established stuff.
    I used the same Apple ID I already had to set up my iCloud, but I used a slightly different variation of that email address to set up the iCloud mail account.
    Was that a mistake? I am now wondering if I should have kept it all the same. It tells you you cannot change the @me.com address once it is established anyway.
    Also, the iPad is considered superior to other tablets because of the wealth of apps available (140,000). Isn't that a little hyped?
    There seem to be a lot of duplicative apps that are not too useful. For example, there are tons of calculator, alarm clock, and reminder apps in the app store.
    Thanks for any insights you can provide.

    "What is the advantage of having this new email account?"
    It is simply an extra email if you wish to use it. You don't have to.
    "Also, the iPad is considered superior to other tablets because of the wealth of apps available (140,000). Isn't that a little hyped?"
    No. It is actually +600,000 apps.
    The 140,000 is iPad specific apps. You can also run iPhone apps and universal apps just fine.
    Sure there are lots of duplicates and a bunch of apps are lame but there are definitely plenty of very good quality apps.

  • One DIMENSION, Two FACT Tables - One WEEKLY grain, one DAILY grain

    All the OBIEE gurus, thanks for checking out this post.
    Background: We have a common DIMENSION referencing two FACT tables having different granularity.
    DIM = Customer Dim
    FACT = Forecasting (Weekly granularity)
    FACT = Sales (Daily granularity)
    There is a need to report from the Customer Dimension table AND access the Forecasting FACT (weekly grain) & Sales FACT (daily grain).
    Example of query is listed below:
    Give me customer = 'ABC' and the forecast and sales for a specific time period.
    What will be the best way to handle something like this? I have seen examples of handing multi-fact table access in OBIEE but the granularity of both the FACT tables is different (weekly vs. daily).
    Any help with an example is greatly appreciated.
    Thanks,
    Sunshine

    Hi.
    This one:
    Joining different level aggregation measures together into a single logical fact table
    http://108obiee.blogspot.com/2009/07/joining-different-level-aggregation.html
    Regards
    Goran
    http://108obiee.blogspot.com

  • Two FACT Tables, Some Common and Non-Common Dimensions

    Hello all, a question i am sure you have faced in the past but still wanted to get your feedback.
    I have a few FACT tables and some dimensions that are shared (common dimensions). Rest of the dimensions are related to one or the other FACT tables.
    What is the best way to present a view where users can pull information from both the FACT tables?
    I am successful in pulling the shared (common) dimensions across BOTH FACT tables having the same grain but this view breaks down when i pull information from one Dimension that has not much to do with the other FACT.
    What is the best way to present this? Should this be broken in three subject areas?
    Subject Area 1 --> Some Dims --> FACT Table A
    Subject Area 2 --> Some Dims --> FACT Table B
    AND
    Subject Area 3 --> ***Only Common Dims*** --> FACT Table A & FACT Table B?
    Your feedback is always appreciated.
    Regards,
    Edited by: user10679130 on Oct 12, 2009 3:27 PM

    Please check the forum first for similar threads/questions.
    Joining two fact tables with different dimensions into single logical table
    http://108obiee.blogspot.com/2009/08/joining-two-fact-tables-with-different.html
    This solution keeps both fact tables in the same subject area in the single logical fact table, with common and not-common dimensions.
    Regards
    Goran
    http://108obiee.blogspot.com

  • Dimension and Fact table have the same grain

    Hi All,
    How can we join a dimension and a fact table if they have the same grain ? In my case it is a contract number.
    Thanks

    Your Impression is right, In terms of Dimensional Modeling. You have to consider this when you are designing your warehouse tables.
    But now if you already have these tables in database, OBIEE does not care how many rows a table have, it just need to know what is fact and what is Dimension and it will generate sql queries based on join conditions.

  • Dimension Table Attributes giving No Fact Table Exists Error

    Hi Experts,
    My OBIEE version is 11.1.1.6.10. There is a presentation table which has columns coming from multiple logical tables. I'm dragging 2 columns into the report which are coming from 2 logical tables.
    The result is displaying. When I checked the query, a fact table is also coming and results are getting effected because of this.
    Could anybody let me know if any idea.

    Hi SriramKarthik,
    Aj (bi007) already gave you the answer on how you can change the implicit fact table, the one you are seeing in your physical query.
    I'm just not sure of what is your question: are you surprised to see a fact table is used in the physical SQL and look for a way to avoid it because, as you say, results are impacted by that implicit fact table? You can't get rid of that table, you can only choose it (the implicit one).
    OBIEE must join in a way or another your 2 dimensions, and in your BMM these dimensions are joined by a fact table, that's why you see it in your query.

Maybe you are looking for