Fact Table Limitations

Hello Gurus,
Can you please tell me why fact table has total column limitation as 256 and why a dimension table has 16 characteristics limitation?
And in Oracle or in DB2 limits are more than this then what is the advantage of using SAP BW/BI?
Thank you in advance
Lili

Hi..
The size of a block depends on the PAGESIZE and the EXTENTSIZE of the tablespace. The standard PAGESIZE of the fact-table tablespace with the assigned data class DFACT is 16K. Up to Release SAP BW 3.5, the default EXTENTSIZE value was 16. As of Release SAP NetWeaver 2004s the new default EXTENTSIZE value is 2.
With an EXTENTSIZE of 2 and a PAGESIZE of 16K the memory area is calculated as 2 x 16K = 32K, this is reserved for each block.
The width of a data record depends on the number of dimensions and the number of key figures in the InfoCube. A dimension key field uses 4 bytes and a decimal key figure uses 9 bytes. If, for example an InfoCube has 3 standard dimensions, 7 customer dimensions and 30 decimal key figures, a data record needs 10 x 4 bytes + 30 x 9 bytes = 310 bytes. In a 32K block, 32768 bytes / 310 bytes could write 105 data records
Hopes this helps..

Similar Messages

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

  • Essbase answers - None of the fact tables are compatible with the query request "member"

    Hi,
    I have modelled an Essbase database into the repository.
    If I pull the measure, period and year dimension in and filter on the year (member) and display the year (member) along with the period (alias) and measure it errors with =>
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14020] None of the fact tables are compatible with the query request Fiscal Year.Fiscal Year Code. (HY000)
    However, all other things being equal if I change the year displayed to the alias then it works.
    Anyone tell me why??
    Is there a limitation that Essbase brings through that you cannot view what you filter on?
    thanks,
    Robert.

    Hi
    i have done the content level setting in each of the table, D1,F1 and F2(LTS), now i am getting the following error..
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 15018] Incorrectly defined logical table source (for fact table Gl Sets Of Books) does not contain mapping for [Code Combinations.Code Combinations.Affiliate, GL Balances.GL Balances.Currency Code, GL Balances.GL Balances.PTD_Balance, Gl Sets Of Books.Gl Sets Of Books .SoB Name]. (HY000)
    Gl Balances : D1
    Code Commbination: F1
    Gl Sets Of Books : F2
    I have checked the joins in physical and BMM layer..all are fine..

  • Related column of a fact table - SSAS Tabular

    Hi,
    I'm developing a SSAS Tabular model using a SQL Server 2012 SP 1 installation.
    For a fact table I've created some calculated columns using the DAX RELATED function. These columns not are hidden to client tools. When I deploy the project and I open an Excel workbook in order to connect the SSAS Tabular cube, in the field list I cannot
    see the calculated columns by RELATED function.
    For me, this in an issue and not a normal behaviour.
    Any suggests to me, please? Many thanks

    Hi Pscorca,
    Generally, if we create a calculated column on SQL Server tabular model database on SSMS, and then go to Model-> Process -> Process All and finish the data processing. Then when we connect the database in EXCEL, the calculated column will appear on
    the Excel. In your scenario, you cannot see the calculated columns. It’s strange behavior. However we cannot give you the detail reason for this issue base on the limited information.  Please refer to the link below which describe the detail steps about
    create a calculated column, then check whether if you missing any step when creating calculated column.
    Add Calculated Column and Measures to Tabular Model
    If the issue persists, please elaborate your production environment and the steps to create the calculated column, so that we can make further analysis.
    Regards,
    Charlie Liao
    TechNet Community Support

  • Use of time series functions with horizontally fragmented fact tables

    Hi Guys,
    in OBIEE 10g it wasn't possible to use time series functions [AGO, TO_DATE] on horizontally fragmented fact tables. This was due to be fixed in 11g.
    Has this been fixed? Has somebody used this new functionality? What the the limitations?
    Tkx
    Emil

    Hello,
    Can you give us some examples for "horizontally fragmented fact tables", we can tell you whether we can do that or not?
    Thanks,

  • Joins with multiple fact tables

    Hi Experts,
    i have one doubt in joins
    we have two dimensions D1 and D2,
    D1 is having A1 and A2 columns
    D2 is having B1 and B2 columns
    two facts F1 and F2 these are joined like D1 to F1 D1 to F2 and D2 to F1, D2 to F2
    D1----->F1
    D1------>F2
    D2-------->F1
    D2-------->F2
    if i selected A1 and B1 in a request from which FACT table will get the data and why can you please explain
    please help me
    reg,
    Jell

    Hi All,
    I have a similar requirement where I have 4 multiple fact tables and we can't combine all those facts into one single fact table. In that case how can a query work with multiple common and uncommon dimensions and measures from multiple fact tables, if it doesn't work that way - can you please explain how can we expect a query to work with multiple fact tables.
    For eg: D1– Dim
    D2 – Dim
    D3 – Dim
    D4 – Dim
    F1 –Fact
    F2 – Fact
    F3 – Fact
    D1 -> F1
    D2 -> F1,F2
    D3 -> F2
    D4 -> F1, F3
    In this case if we want to query from D1,D2,D3, F1, F2 or D1,D2,D3,D4,F1,F2,F3. Kindly please explain how it can be modeled in BMM or what are the limitations. I have done with two fact tables in past and didn't had issues but this is kind of a vast implementation. Your help is appreciated.

  • Snapshot Dimension & Fact tables

    We are currently designing a logical multidimensional model from an OLTP tables.Dimension tables have monthly snapshot because some of or all the attributes might change on monthly basis.The same situation for the fact table has monthly snapshot.
    I know that according to Kimball's modeling, the attributes for dimensions should be implemented using mini-dimensions and put combination key as a foreign key in the fact table but this step needs an ETL job to handle mini-dimension and other fact table.However, in our situation and according to scope limitation,there is no time to design separate ETL to handle mini-dimension.
    An example for our records:
    Customer:
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr20
    Installments
    Installment_ID
    Cust_ID
    Month_ID
    Attr1
    Attr2
    Attr3
    Attr5
    Measure1
    Measure2
    Measure3
    Measure4
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?

    Xerox wrote:
    So, Installments table contains attributes as well as measures so what is the suitable consideration and the suitable OBIEE logical BM design ,should we consider Installments table as fact or should we divide it into dimension and fact tables ?You already give the answer yourself: you should create an Installment dimension and a Installment fact table, using the same physical table as logical table source. The logical dimension should only contain the attributes, the logical fact should only contain measures.

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

  • Fact Table with multi billion records.

    Hi ---> Is it advisable to build hierarchies around 3 billion record table Fact table and still growing in OBIEE..I know we can use oracle OLAP Tool and DB and other additional infrastructure will do it. But tryiing to look for a better way with the existing tools and hardware... Please let know the possibilities using obiee..yes I am aware of aggregate tables, materialized views etc.., it takes time to implement and view which is most optimal...
    Edited by: user007009 on Apr 11, 2013 5:49 PM

    Is it advisable to build hierarchies around 3 billion record table Fact tableIs it warehouse table or OLTP table treating as fact table? if it is ware house table then in BI we create hierarchy on dimension table but not on fact! or else you are using a fact table as both fact and dim then it can be but you have to mention as dim instead of fact.
    I dont think there is a limitation, its all how you see the data. I dont think you create a report to show 1 or 2Billion records at once.
    If you didnt convince try to check with Oracle with SR.
    If helps mark
    Thanks
    BTW: You havent mentioned about time period for that 3 billion records! if it is over a period of time then BI can take care of its source using fragmentation.
    Edited by: Srini VEERAVALLI on Apr 12, 2013 7:26 AM

  • More than one fact tables...

    Hi.
    I have tried OLAP until now with only one fact table.
    But now I have more than one. To start i added one more.
    I am always using SOLVED LEVEL...LOWEST LEVEL.
    I am always receiving the following error when creating the cube with this measures:
    "exact fetch returns more than requested number of rows"
    What shall I look for when dealing with more than one fact table?
    Thanks.
    ODDS
    :: ... and still have a very poor performance ...

    1.
    Well ... I saw the global star schema and we have two fact tables there!!!
    Do I have to build different cubes for each fact table always?
    2.
    I have built cubes, created a java client and a jsp client.
    Performance is much better in JSP using the AppServer(sure!).
    The power of the JSP client is more limited i presume.
    I wonder if I can do things such setCellEditing for a crosstab in both.
    3.
    Some aggregation questions:
    Everytime I create a cube using CWM2 and also a AW using AWM wizards with that cube I have one aggregation plan by default that processes everything online.
    After that I create and deploy my own aggregation plan.
    My question is: If I don't want to aggregate anything!??! I want to see, for instance, in BiBeans the lowest level values only. And everything at the top levels empty.
    I am missing something 'cause I still have everything aggregated !!!
    Thanks.
    ODDS

  • Size of dimention table  fact table ratio  question..

    Hey Guys !!!
    I have  very basic question regarding the ratio of size of dimention table and fact table..
    its mentioned that the ratio of dim table / fact table  sizes should not be greater than 1:20 for performance reasons .. thats OK..
    now lets say if i have fact table with customer dim_id ,some other dimention ids , and revenue (KF) .. with 1 million records ..
    so ideally my customer dimention table should not have more than  200,000 recods (.ie 200,000 different customers ).
    doesnt this put limitation on number of customers in a cube ?
    if so, how do we handle this ?
    please correct me if i am wrong  in interpreting the concept of dimension table.
    thanks in advance
    swapnil

    Hi ASRao ,
    thanks  for replying ...
    you said exactlly what i know  ..
    sorry i didnt put my question in correct prespective ...
    whay i meant was...
    lets say  , i need to have more than specified (1:20 ) number records in dimension table ,it will definately hamper my reporting performance ...
    so, is there any solution to handle this kind of problem ?
    like how would i maintain my efficiency of reporting in this case ?
    thanks in advance

  • ETL for loading Fact tables

    Hi all
    I have a fundamental question regarding loading records into the Fact tables. As you know we always load Dimensions before loading Facts. In our data model, for most of the Fact tables we have a special Dimension that has got the basic attributes in it, along with the source key of the records which are valid in terms of our data warehouse. The source of the Fact table includes the source tables which are involved in loading the Dimension as well.
    For example for Student Fact table we have a Student Dimension which is loaded before Student Fact, hence has got the most recent changes (source key of the records which are to be loaded into DW). Now my question is that which options below are more appropriate in loading Student Fact table.
    Option 1 -  Load Student Fact table using the same source tables that are used in loading records into Student Dimension, ignoring the similar logic has been applied already in Dimension to get valid records from Source and do it again in Fact job.
    Option 2 -  Inner Join the Student Dimension in the Student Fact ETL job, so it limits the number of source records (coming from Source System) to the validated records which we are interested to load into DW. This option makes loading the Fact table faster, as by contributing the Dimension in loading its corresponding Fact, we don't have to get all records from the source and validate them against the rules again (as it has been done in the Dimension job and now we can use the validated record IDs in Fact job).
    As we are new building jobs for a dimensional model, I thought it would be good to ask your opinions and your experience
    Thanks in advance,
    Tootia

    I don't see any problem with re-using your "which students do we care about?" logic and rules by borrowing the list of students from the dimension table. You can join to it, or do a lookup() into it and then filter-out nulls (assuming you return a null on a no-match), or use a Validation transform with the "Exists in table" option -- which to use is question of style & performance -- any would work.  Indeed, when migrating data into SAP using iDocs, I use a similar idea, always joining the iDoc base segment "map" table to the load of any child segment table to "automatically" filter-out any child segment records not present in the base, re-using the selection logic as you suggest, which then only needs to be built in the base segment. Keeps things tidy.
    Best wishes,
    Jeff Prenevost
    Data Services Practice Manager
    itelligence

  • General Question: should Fact Table use virtual column?

    Hi,
    I have read several articles about 11g's Virtual Column feature and it all looks very good. But I just want to know
    - Whether virtual column is also good for Fact table or not?
    - Is it recommedated?
    - Is there a 'limit' or 'recommedation'regarding how many virtual columns I should use in a table?
    Thanks

    In an OLTP system, the number of virtual columns is self-limiting because there aren't that many simple ways to combine the columns in a single table using simple expressions. In a data warehouse, there are likely a lot more expressions that you might want to compute, so you would have to be careful as oracletune points out if expressions can change over time assuming that you want the version of the computation that was in force at the time the row was written to be used.
    There really isn't a rule of thumb. It's a lot like asking how many indexes a table should have-- the only answer is to do a cost-benefit analysis on each potential index/ virtual column to determine if the benefits outweigh the cost. A virtual column allows you to avoid computing an expression when you are inserting a value but requires that you compute it at query time. If a row is queried millions of times, written once, and never updated, that probably isn't a great trade-off. If a row is queried a few times and updated a bunch, avoiding the computations is probably worthwhile. If you need to store the value and you have an OLTP system, the ability to ensure that you never have stale computations is great.
    Justin

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

Maybe you are looking for