Where to see  dim and fact table names for a cube.

Hello Experts,
Where to see  dim and fact table names for a cube.

Do a wild character search with the cube name (with '*' on both sides of the cube name) in transaction code SE11 or LISTSCHEMA...
For Eg : Cube Name is ZFIN_C111
Goto transaction code SE11
Tables - ZFIN_C111 & then F4 would give you all the associated tables for the InfoCube.

Similar Messages

  • Performance - DIM and FACT tables

    Experts,
    I have performance issues where my DIM tables are bigger than the FACT tables by 50 %.
    Can any one please let me know what should be done in order to solve this issue
    I have already done below steps
    1)Kept the small dimensions together
    2)kept the line item dimensions wherever needed
    3)Grouped related characteristics into one dimension only
    4)Removed high cardinality dimensions
    pls help
    thanks in advance

    Often, not much thought is given to the dissemination of characteristics to dimensions. Dimension tables, however, have a huge impact on InfoCube performance. The star schema design works best when the database can assume minimal records in the dimension tables and larger volumes in the fact table.
    Rationale : -
    Each dimension should be of approximately equal size and that the file size of each dimension should not make up more than 10 percent of the associated fact table. The dimensions must also support growth.
    You should make every attempt to split up the most dynamic characteristics so they do not exist in the same dimension. This ensures that the system does not create too many entries in a dimension table.
    Example : Order data is loaded into BW with the dynamic characteristics customer and material. If these InfoObjects were to be placed together in the same dimension, it poses a problem for the system because a new dimension record would be created each time the combination of customer or material changed. This would make the dimension very large in relation to the fact table.
    When one dimension grows very large in relation to the fact table, it makes it difficult for the database optimizer to choose an efficient path to the data, because the guideline of each dimension having less than 10 percent of the fact table’s records has been violated. This condition of having a large volume of data growth in a dimension is known as “degenerative dimension.”
    In the data modeling phase, it is very important to determine if a dimension table will be degenerated, and then explicitly set it as a line item dimension
    The best way to fix a degenerative dimension is to move the offending characteristics to different dimensions
    Line-item dimensions arise in nearly every case where the granularity of the fact table represents an actual working document like an order number, invoice number, sequence number.. This can only be accomplished if no data is in the InfoCube. If data is present, however, a dump and reload is required. This underscores the point that the data modeling decisions need to be well thought out during the initial implementation to avoid a dump and reload of data.
    Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes
    This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
    Recommendation: -
    Try to limit the number of records in the dimension tables. Use the following guidelines:
    1. If an InfoObject has almost as many distinct values as there are entries in the fact tables, the dimension this InfoObject belongs to should be defined as a line item dimension. If the dimension is defined in this manner, the system will write the data directly to the fact table instead of creating a dimension table that has almost as many entries as the fact table.
    On the other hand, if there are several dimension tables with very few entries (for example, less than 10), these smaller dimensions should be combined into one dimension.
    2. Group related characteristics into one dimension only. Unrelated characteristics can use too much disk space and cause performance problems (for example, 10,000 customers and 10,000 materials may result in 100,000,000 records).
    3. Avoid characteristics with a high granularity, that is, many distinct entries compared with the number of entries in the fact table.
    4. Remove all "High-Cardinality" indicators from the InfoCube definition,generally, a dimension has a high cardinality if the number of dimension entries is 20% (or more) of the number of fact table entries. When in doubt, do not set a dimension with high cardinality
    5.Because it is far better to have many smaller dimensions than a few large dimensions, I suggest you identify the most dynamic characteristics and place them in separate dimensions. The current size of your dimensions can be monitored in relation to the fact table by running report SAP_INFOCUBE_DESIGNS in transaction SE38 for live InfoCubes This shows the size of the fact table and its associated dimension tables. It also shows the ratio percentage of fact to dimension size.
    Hope it Helps
    Chetan
    @CP..

  • Determine the size of Dim and Fact table

    Hi,
    Please some one tell me how do calculate the size of diminsion and fact table
    Please explain me step by step.
    Thanks

    hi
    We have two other ways also
    Try RSRV test: Elementary > dataBase > DataBase Info about InfoProvide Tables
    and You can check out in DB02 tcode Detail Analasys...
    Thanks
    Khaja

  • Dimension Table and Fact Tables

    Hi,
      Is there any way to see the Dimension Table contents and Fact Table Contents.
    For eg:-  I should be able to see the DIM ID and the SID's of a Dimension.

    Well you can see them in SE11, by giving the table name.
    Go to list schema and give the cube name. It will display all the table for that cube. Give the table name in SE11 or SE16 and see the content there.

  • Partition Pruning - Dimension and FACT tables..

    Hi
    I have a DWH environment where we have partitioned the FACT table by a date column. This is RANGE partition. The TIME dimension table joins to the FACT table based on this date. However the end user queries will typically be fired using a different column in the time dimension that will hold more VIEWABLE date values (e.g.) in format MON-YYYY or YYYY-MM etc..
    The query is autogenerated by the viewer tool. The SQL has something like
    select sum(balance), MONTH from fact a, dim_time b
    where a.date = b.date and <-- this the partitioned key in fact
    b.month_year_col = 'Apr-2006' <-- Dimension filter.
    In the above case, Oracle is not doing PARTITION PRUNING. I have 24 period data and in the explain plan i can see it goes to the entire 24 periods. However if i change the query to
    select sum(balance), MONTH from fact a, dim_time b
    where a.date = b.date and <-- this the partitioned key in fact
    b.date = '31-Apr-2006' <-- Dimension filter.
    it does partition pruning. The explain plan shows that i goes to only one partition.
    Any help on this please. I would need the first query to use PARTITION PRUNING.
    Thanks
    bala

    Hi All
    Got it to work with these 3 parameters
    alter system set "_subquery_pruning_enabled" = true
    alter session set "_subquery_pruning_cost_factor"=1;
    alter session set "_subquery_pruning_reduction"=100;
    Thanks for all those who had a look into my question.
    Regards
    bala

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

  • 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

  • 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

  • Want field and table name for RESERVED coloum in MMBE

    Hi ,
            There is a RESERVED coloum in MMBE and     I want this   * RESERVED* coloum  in  MB52   .
           I got to know that Field related to this  RESERVED coloum is BDMNG coming from table RESB .
           To confirm the field and table I checked the value in BDMNG by putting join on MARA and RESB where MATNR = BAUGR.
            But I got  value in BDMNG is 50 and in MMBE it is .228 for that material.
               Please tell me field and table name for RESERVED coloum. and hoe to join MARA and RESB  to get exact result.
    Thanks and Regards,
    Ranu

    Hi,
    Mara-matnr is not equal to Resb-matnr and it shows no record if i do like this.
    But Mara-matnr is equal to Resb-baugr, and it gives me 1 record .But porblem is that i dint get BDMNG field matching with mmbe RESEVERD coloum.

  • Table name for Customer Account Group and created by Data

    Dear Gurus,
    Kindly le t me know the table name having a list of Customer a/c groups and created by data. if there is no such table thn pls let me know the alternatives for fetching the same data.
    Wishes
    Abhishek

    hI
    Go to Se11 and give table name KNA1 and go to display
    you can able to see the Customer AccountGroup field :KTOKD
    Thanks
    Vasu

  • Table Name for Partner Determination Procedure and created by data

    Dear Gurus,
    kindly let me know the table name for a list of "Partner Determination Procedure" and "created by" data under a client.
    if there is no such  table for this, kindly let me know how can i fetch these details.
    Wishes,
    Abhishek

    Hi Abhishek,
    You can get your required information by combining these 2 table by using SQVI
    TPAER where it gives PartnDet.Proc and Part.funct.
    TPAR where it gives Part.funct inforamtion.
    By using these tables i.e. by using Common field Part.funct. - PARVW
    Regards
    Durga Sana

  • Number of Entries in Dimension Tables and Fact Tables

    Hi all,
    is there an easy way to check
    - the number of entries in the dimension tables
    - the number of entries in the fact table?
    Thanks  a lot
    Alex

    Hi Alex,
    If u want to see the content of Dimension table and Fact table for a infocube then just right click on a particular info cube then select manage . Select coneten tab there , form there u can either select Fact table to see the fact table conten or Infocube content to see the Dimensiontable content.
    Regards..

  • 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

  • Dimension table and fact table exists data physically

    Hi experts,
    can anyone plz tell me weather dimension table and fact table exists data physically or not/

    Hi..Sudheer
    SAPu2019s BW is based on "Enhanced Star schema" or "Info Cubes" database design.This database design has a central database table, known as u2018Fact Tableu2019 which is surrounded by associated dimension tables.
    Fact table is surrounded by dimensional tables. Fact table is usually very large, that means it contains
    millions to billions of records.
    These dimension tables doesn't contain data  it contain references to the pointer tables that point to the master data tables which in turn contain Master data objects such as customer, material and destination country stored in BW as Info objects. An InfoObjects can contain single field definitions such as transaction data or complex Customer Master Data that hold attributes, hierarchy and customer texts that are stored in their own tables.
    SID is surrogate ID generated by the system. The SID tables are created when we create a master data IO. In SAP BW star schema, the distinction is made between two self contained areas: Infocube & master data tables/SID tables.
    The master data doesn't reside in the satr schema but resides in separate tables which are shared across all the star schemas in SAP BW. A numer ID is generated which connects the dimension tables of the infocube to that of the master data tables.
    The dimension tables contain the dim ID and SID of a particular IO. Using this SID the attributes and texts of an master data Io is accessed.
    The SID table is connected to the associated master data tables via teh char key.
    Fact table(Transaction data,DIM ID)<>Dimention Table(SID and Dim ID)<->Masterdata table(SID,IO)
    Thanks,
    Abha

  • How to load data to dimensions and fact table is it simialr to sql server

    How to load data to dimensions and fact table in a data ware house environment, is it simialr to sql server, oracle?
    Never migrated or loaded data to datawarehouse server.
    I have an interview and am really confused if they ask anything related to the dataware house side elements.
    Coudl you please if you don't mind provide me some steps and dimension and fact table info, an example only.
    Atleast for my knowledge.
    Thank you very much for the helpful info.

    Some discussions in previous forums should help you
    http://forums.sdn.sap.com/thread.jspa?threadID=2019448
    http://forums.sdn.sap.com/thread.jspa?threadID=1908902
    In the SAP tutorial, you can see a sample example of making fact tables.
    http://help.sap.com/businessobject/product_guides/boexir32SP1/en/xi321_ds_tutorial_en.pdf
    Arun

Maybe you are looking for