OBIEE - multiple fact Tables

Hello

I have a case.

I have three tables:

1 XX_PERIODS_D

2 XX_ORDERS_F

3 XX_SHIPMENTS_F

XX_PERIODS_D a column PERIOD_CODE

XX_ORDERS_F a column PERIOD_CODE

XX_SHIPMENTS_F a column PERIOD_CODE

XX_PERIODS_D.PERIOD_CODE joined with XX_ORDERS_F.PERIOD_CODE

XX_PERIODS_D.PERIOD_CODE joined with XX_SHIPMENTS_F.PERIOD_CODE

RPD is OK

Analysis Log Queries return results that are OK

Analysis shows the results are bad for XX_SHIPMENTS_F tbal

pic1.png

Hello

I fixed my self,

I created only once the fact table by the application using as start logic diagram and it's corrected now.

Thanks @.

Tags: Business Intelligence

Similar Questions

  • OBIEE report with multiple fact tables

    I want to build a report so that it will be have.

    Attribute columns in the dimension D1, D2, D3 tables.

    Measure the columns of the tables of facts F1, F2.

    F1 and F2 are attached with D1, while only F1 joined with D2 and D3.

    When I build this report and run, I see the correct data of F1 but get no matter what value of F2 that the query is not the column measure F2.

    Please help solve this problem.

    This is the point: why haven't you installation of hierarchies for D2 and D3 (when you say logic dimension, I assume that you mean the logical hierarchy as dimensionless, as if there is no D2 and D3)?

    To be able to say OBIEE how manage the absence of joins between D2 - F2 and F2 - D3 you need of them set at grand total level hierarchies and required parameters for the F2 values can be shown next to the F1, D1, D2, D3.

    PS: I assume that your report is D1, D2, D3, F1 and F2, otherwise what to talk of D2 and D3 in the first post?

  • several "logical joins" between a fact table and a dimension table

    It seems that cannot create multiple "logical joins" between a fact table and the table of a dimension in OBIEE with Administration Oracle BI tool. For example, whereas a business model with a dimension table TIMES and has made the table containing the value of START_TIME and END_TIME, we want to create separate logical joins BOTH done for the START_TIMEs and the END_TIMEs? Of course, underlying foreign keys can be created, but as far as I can tell the Administration Oracle BI tool does not support this. The solution would be to reproduce the table in TIME, but it's ugly.
    I'm looking for another approach.

    Try this. Create an alias of two for the TIME dimension (beginning & end) in the physical layer, then remove foreign key to the 'Parent' time dimension. Create the foreign key in the physical layer for new aliases, then create complex joins in the MDB layer for new aliases as well. This will allow you to present the two dates within the same table in the presentation layer. Not a more elegant solution, but it works.

  • How to include the total number of table one fact in another fact table to calculate the percentage

    I have a fact table in the grain of each document created in any organization, say the 1st table of facts. I have another table of facts (2nd fact table) seen those documents which are considered by different commentators. grain of this second fact table is so each review, even if I document in both IDs the fact table.

    Now, I want to calculate the percentage return documents reviewed. For this I need to divide count separate from the document of performance by the total performance document. Now this document of total performance can be obtained from the 1st table of facts, but I don't get how to bring this indictment in the 2nd table of facts to show the percentage.

    Please let me know if there is no ambiguity in my question, because I'm a starter in OBIEE.

    Thank you very much.

    then you can set new logical column with two columns of fact in the formula

  • Index bitmap for FKs on fact tables

    Hi all

    We have a database of DWH (Star Dimesions and the tables schema) running with OBIEE 11 g (11.1.1.1.6) on the oracle 11 g (11.2.0.1) database. I read in one of the best practical paper, creating index Bitmap on the Fks of all fact tables will help performance.

    I created indexes for the less than 2500 separate keys, but we have 2 dimesions tables where there are great number of records (size 14 g and 10 g). Can I go ahead and create indexes of bitmap for 2 tables establishments (mainly account_key and customer_keys are the columns)?

    Worried about creating index bitmap for large tables where they could affect the ETL process.

    Ref: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-dw-best-practies-11g11-2008-09-132076.pdf (page 20)

    Help, please.

    Thank you and best regards,
    Anand.

    >
    I created indexes for the less than 2500 separate keys, but we have 2 dimesions tables where there are great number of records (size 14 g and 10 g). Can I go ahead and create indexes of bitmap for 2 tables as well
    . . .
    Worried about creating index bitmap for large tables where they could affect the ETL process.
    >
    You put the cart before the horse!

    Don't create index unless you have a reason documented for them.

    Why did you choose the index bitmap for cardinality less than 2500? Perhaps based on a long-standing myth, but discredited on the cardinality?

    See also Richard Foote two articles where he explodes the myths about bitmap indexes and considerations of cardinality
    http://richardfoote.WordPress.com/2010/02/18/myth-bitmap-indexes-with-high-distinct-columns-blow-out/
    http://richardfoote.WordPress.com/2010/03/03/1196/

    Re your concern about the tables with the 'large' number of records and affecting ETL.

    You are right to be concerned about these issues, but you need to document your particular situation taking into account the architecture.

    The fact tables and dimension tables can have a large number of records. If using the bitmap index is indicated, then the most records are most effective, they will be.

    ETL is affected because the DML (INSERT, UPDATE, DELETE) operations on the tables with bitmap indexes can have serious performance because of the involved serialization issues. Updated single bitmap of a column value (e.g., am ' to 'F' gender) requires that the two index bitmap blocks must be blocked until the update is complete. An index of stored bitmap ranges ROWID (rowid min - max rowid) that can span many, many files. The "range" of ROWID is locked in order to change a value.

    To change: 'follow her' rowid beach so that a row is locked and ID should be removed from the range by turning off the bit. Change to the 'F', the rowid id range 'F' must be found, locked and the bit set that corresponds to this rowid. No another row with ROWID in the range cannot be changed, because it is a transaction in the series. If the range includes 1000 lines and they all need changed it takes 1000 series.

    For anything other that a very small number of documents the bitmap index would be deleted and rebuilt after the ETL operations. That is why the data warehouse designs try to minimize update and implement insertions and deletions using partitioning when possible; Adding a new day by adding a new partition.

    There is also a big difference between a bitmap index and a bitmap join index. The white paper you quoted does not really indicate what type are used or recommended.

    Learn more about the difference - see Using Bitmap indexes in data warehouses in the doc of Data Warehousing
    http://docs.Oracle.com/CD/B28359_01/server.111/b28313/indexes.htm

  • Two filters in two dimensions without constraining the fact table

    Hi all

    does anyone know how to avoid the factual constraint when you create a report with two filters on different dimensions?

    I have a fact table big with more than 10 million lines. In the starmodel is the customer of the dimension and the products. I create a filter on the customer atrribute 'Status' and set to 'active '. Now I add the "Product Type" column of the dimension 'Product' in the filter section. When I want to choose a value OBIEE executes a select statement in the fact table. So I have to wait very long to select a value. Is it possible to say OBIEE only to select the dimension table without joining the fact table?

    Thank you much in advance.

    Kind regards
    Stefan

    Use is implied.

    Create a table of facts of the DUMMY and make also implied made for this dimension column. It will solve the problem.
    http://obiee11gqna.blogspot.com/2011/01/implicit-fact-column-in-OBIEE.html

    Published by: MK on January 17, 2012 07:08

    Published by: MK on January 17, 2012 07:08

  • the fact table measures

    Hello

    Can I have measurements of the fact in the business layer table?
    I use obiee 11g.

    as if I had a fact table where I have a user I applied the rule of distinct count aggregation.
    Now, I would like to add a lower function as count (distinct (lower (username)).
    But he becomes as a measure with fx with the name and not the usual yellow color.

    Wanted to know if its good practices?

    Thank you

    Hello

    You have two columns of measure.

    with the lower function
    other no less function.

    For your information: separate are case-sensitive. It will show the difference between 'A' and 'a '.

    Kind regards
    Lacouture.

    Published by: Rey July 7, 2011 14:41

  • Report showing not given when adding more measures 1 fact table

    Hi all

    I have the 1 dimension table and 2 fact tables. I'm trying to generate a report of all of these attributes. The dimension table is joined to the two tables. When I get columns of tables Dim and fact 1, the report is generated according to the needs. Now, when I add metrics of fact 2, 1 of fact data disappear and all fields are empty. How the two tables of data?

    Thank you

    Hello
    combine two facts into one using multiple LTS. This will show the SNOWFLAKE in the STAR patterns. and now you can easily get data both made n dim. Hope you understand what I said. Try this and post msg always if you face any pblm.

    Published by: Chauvin on January 18, 2011 22:19

  • Calc problem with fact table measure used in the bridge table model

    Hi all

    I have problems with the calculation of a measure of table done since I used it as part of a calculation in a bridge table relation.

    A table of facts, PROJECT_FACT, I had a column (PROJECT_COST) whose default aggregate is SUM. Whenever PROJECT_COST was used with any dimension, the appropriate aggregation was made at appropriate levels. But, no more. One of the relationships that project_fact is a dimension, called PROJECT.

    PROJECT_FACT contains details of employees, and every day they worked on a project. So for one day, employee, Joe, could have a PROJECT_COST $ 80 to 123 project, the next day, Joe might have $40 PROJECT_COST for the same project.

    Dimension table, PROJECT, contains details of the project.

    A new feature has been added to the software - several customers can now be charged to a PROJECT, where as before, that a single client has been charged.
    This fresh percentage collapse is in a new table - PROJECT_BRIDGE. PROJECT_BRIDGE has the project, CUSTOMER_ID, will BILL_PCT. BILL_PCT always add up to 1.

    Thus, the bridge table might look like...
    CUSTOMER_ID BILL_PCT PROJECT
    123 100.20
    123 200.30
    123 300.50
    456 400 1.00
    678 400 1.00

    Where to project 123, is a breakdown for multiple clients (. 20,.30.50.)

    Let's say in PROJECT_FACT, if you had to sum up all the PROJECT_COST for project = 123, you get $1000.


    Here are the steps I followed:

    -In the physical layer, PROJECT_FACT has a 1:M with PROJECT_BRIDGE and PROJECT_BRIDGE (a 1:M) PROJECT.
    PROJECT_FACT = > PROJECT_BRIDGE < = PROJECT

    -In the logical layer, PROJECT has a 1:M with PROJECT_FACT.
    PROJECT = > PROJECT_FACT

    -Logical fact table source is mapped to the bridge table, PROJECT_BRIDGE, so now he has several tables, it is mapped (PROJECT_FACT & PROJECT_BRIDGE). They are defined for an INTERNAL join.
    -J' created a measure of calculation, MULT_CUST_COST, using physical columns, which calculates the sum of the PROJECT_COST X the amount of the percentage in the bridge table. It looks like: $ (PROJECT_FACT. PROJECT_COST * PROJECT_BRIDGE. BILL_PCT)
    -J' put MULT_CUST_COST in the presentation layer.

    We still want the old PROJECT_COST autour until it happened gradually, it is therefore in the presentation layer as well.


    Well, I had a request with only project, MULT_CUST_COST (the new calculation) and PROJECT_COST (the original). I expect:

    PROJECT_COST MULT_CUST_COST PROJECT
    123. $1000 $1000

    I'm getting this for MULT_CUST_COST, however, for PROJECT_COST, it's triple the value (perhaps because there are quantities of 3 percent?)...

    PROJECT_COST MULT_CUST_COST PROJECT
    123 $1000 (correct) $3000 (incorrect, it's been tripled)

    If I had to watch the SQL, you should:
    SELECT SUM (PROJECT_COST),
    SUM (PROJECT_FACT. PROJECT_COST * PROJECT_BRIDGE. BILL_PCT),
    PROJECT
    Of...
    PROJECT GROUP


    PROJECT_COST used to work properly at a table of bridge of modeling.
    Any ideas on what I got wrong?

    Thank you!

    Hello

    Phew, what a long question!

    If I understand correctly, I think the problem is with your old measure of cost, or rather that combines with you a new one in the same request. If you think about it, your request as explained above will bring back 3 rows from the database, that's why your old measure of cost is multiplied. I think that if you took it out of the query, your bridge table would work properly for the only new measure?

    I would consider the migration of your historical data in the bridge table model so that you have one type of query. For historical data, each would have a single row in the bridge with a 1.0 BILL_PCT.

    Good luck

    Paul
    http://total-bi.com

  • Understand the fact Tables

    Hello

    I'm new to OBIEE, I created several dimensions but am a bit confused with the measures, and the fact tables. I have a table of facts already populated in the database that contains the dimension by each dimension keys, 3 measures. There are a few additional columns (agreement_code, agreement_type, schedule_number). These additional columns do not bind to the dimensions. These columns must be included in the table of facts within the layer of OBIEE BM or could be deleted. My question is the fact table should contain only measures or can it be other columns not aggregated.

    Thank you

    Hello

    If you take certain columns actually that depends on the requirements of the company. If you think that these columns will be used in the reports, then you should take these columns in the data warehouse.

    Should not that only columns of measure should go in fact. You can take these columns not aggregated in your fact. But as a best practice, always try to move the columns not aggregated to your dimension. If you can't, as a last resort to it in fact.

    Thank you
    Sandeep

  • Combine data sources with different granularity in the same fact table?

    I have two operating tables 'Incident (157 columns)' and 'unit (70 Colums) '. For all the "incidents" happening there could be one or more records in the table of the 'unit '.

    As part of my design of data mart, I have merged the tables in one "makes the incident (227 columns)" and insert records from two tables with a join condition between them [incident. IN_NUM = Unit.IN_NUM].

    Is this correct, is my question? or am I mix data sources with different granularity in the same fact table. Appreciate your help.

    Best regards
    Bees

    Bees,
    Are the measures of the 'Incident', repeated during an incident given, in more than one record in the table of the unit? If so, then the sum (indicent.measure) will give an incorrect result?

    What is there to merge physically tables set outside OBIEE? With OBIEE you might have a table of 'facts' logic to present the user with report, which from tables separated units and Incidents and would stop the occurrence of incorrect aggregations. A common piece of modeling in the same way would be arrested in OBIEE headers and lines of command, quite common to have a logical fact 'orders' which contained the two header orders and order line, this translates into the Incidents-> relationship of units.

    To do what I mentioned, is relatively simple, you need a "Dim - Incident" at two levels, unit, mapp and Incident unique identifiers as keys to level and then use these levels to define the content of the levels correctly in your 2 tables logic sources logic "done", IE the LTS Incidents at incident level LTS units as level of units.

    Hope this helps, let us know if you get stuck.
    See you soon
    Alastair

  • How to migrate data from a source to multiple targets (tables)?

    How to migrate data from a source to multiple targets (tables)? Describe the General steps, please or point me to a tutorial

    Yes, a table in a mapping element can be source and target at the same time (i.e. a target can be reused as a source for the rest of the map on the right side of the table).

    Don't forget to check the order of loading (in the property map), to ensure that the reused as source is loaded before the final table target table.

    I tested it and it works. However, the documentation is not said in the link I gave you above:

    "Each element of data store that has entries but no exits in the logical diagram is considered a target."

    Usually, I tend not to do. I am in favour of a Divide and Conquer approach and try to have my mapping as simple as possible. It is easier to debug and maintain.

  • Help! Logical physical Table table - imported as fact table

    I am trying to create a logical table. When I drag the alias of the physical layer in the MDB, logic is created with the sign #. I think that it indicates as a fact table. I can't create a logical dimension of this table. How can I make the table come in a logic instead of a fact?

    Thank you for your help.

    1 > drag the physical Table in MDB. It will create a logical fact table in MDB Test for example.

    2 > duplicate this logical fact table. Another fact logical Test #1 table will be created.

    3 > select Test / Test No. 1 logical tables, and then right-click and select model for Business diagram.

    4 > create a new logical join between the Test and the Test #1 in MDB. Make sure that this Test: Test #1 cardinality is 1:M.

    5 > This will make the Test as a logical dimension table. Double-click the logical size Test table, go to the tab key and create a primary key.

  • How to create a logical fact table in a layer MDB?

    Hello

    I have 3 Dimension table - 2 are in a schema and the last is another schema. Using this 3 dimension tables, I need to create a logical fact table.
    So, my question is if we can create this table made by joining these 3 dimension table that are 2 different schema s?

    Thank you

    Hi Kuldip,
    Business is never a problem.

    Presentation layer is used to group similar business lines tables.
    It's just for users to understand or requirrment.

    You can use different domain tables to create a report. However the MDB and the physical joins is given in the tables to the RPD. It is compulsory to join tables in MDB layer and the physical layer to be used in the analysis.

    Hope that clarifies.

    A course if you think perticular table is used in the object anaother are, so you must add this table to the domain of the RPD. (Which makes sense)

    Mark if it is correct,

    Bachelot

  • How to remove the fact Table

    Hi all

    If I have to restart my fact table on the same day, more than once a day, and he had already stored in it, I want to remove these lines and reload the fact with the current date. I want to create a procedure and include it in the package, the process must check the current_timestamp and if the lines with the date and if there is then it should delete it. Please let me know how I can do this. I am running SQL Server - 2008.

    Thanks for your time and your help.

    You should have to date in your primary key (ex: in a varchar as YYYYMMDD format).

    Then you have 2 ways to implement:

    create an ODI procedure that will remove all data where this date = today. Perform this procedure before your interface.
    * or change your IKM: Add a step that will erase the data in the target table if date = today.

Maybe you are looking for