Question of fact table.

Similar Questions

• 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

• 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

• the combination of more than two fact tables

  Hello
  
  I have read many texts on combining made tables but I have not yet find answer to my question.
  
  I have four fact tables I would combine into one. This is something simple, but is anyway it to avoid joins when you query the fact that one?
  
  So I'm waisting my time or is this possible?

  Hello

  I think it's possible. I have not yet tried in my environment, but how about you create several LTS for these facts. I mean you can create several LTS (according to your requests of course however) for each of your facts and some combinations of these.

  So, every time there is that one table of facts to be questioned, BI Server can intelligently pick the correct LTS but don't need to make an unnecessary join between the huge facts.

  I hope this helps.

  Thank you
  Diakité

• Dependence on the data cube on the fact tables?

  Hello
  
  We have a cube that is built based on a table of facts (with prior calculation of 35%)
  
  The fact table has approximately 400 000 records.
  
  Now I don't want to disturb my cubes but wants to move forward and still changing the data in the fact table, which could include the removal of thousands of records.
  
  SO my question here is how dependent are cube on the fact table data.
  
  The cube stores all the data? Can I go ahead and even to truncate (not drop) the fact table?

  The contents of the cube is not changed until it is built again. So, if you do the following

  (A) complete the table of facts
  (B) create the cube fact table
  (C) Truncate table facts

  Then your cube should always contain the data, and you can question him. The content will change only when you

  (D) create the cube again. At this point my previous answer comes into play.

• 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

• 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

  

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

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

• Why do you say that the FACT table is off standard? I just don't understand.

  Why do you say that the FACT table is off standard? I just don't understand.
  
  According to my understanding, normalization is the process of getting rid of redundant. So, the fact table have redundant. So how is it that they say it is off standard.
  
  What dimension tables? They are also OF normailzed?
  
  Can you explain in words simple pls.

  Fact tables are generally standardized.

  Dimensions are usually denormalised because they often contain descriptive and rollup/hierarchical data repeated. Snow flake off a dimension will normalize the data.

  See you soon
  If

• 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

• Limit the rows of the fact Table by using a table Dim - 10 g

  Hello
  
  I'm having some trouble trying to restrict the result to a fact table using a Dim picture (assume that the example below).
  
  -----DIM A-------------------------------FACT B--------------
  ID-Code - Id_Date - Id_Dim - value
  1---ABCD---01-01-2011---1---10
  2---XYZ---02-01-2011---2---20
  3---RST---03-01-2011---1---30
  ----------------------------------04-01-2011-------3------------40
  
  I want to show only the rows where Dim.Code = 'ABCD '. I know on the MDB, I choose the LTS of the fact table and on the content tab, on where clause insert: Dim.Id = 1, but I don't want to be limited by Dim.Id, I want to limit by Dim.Code and who cannot do this way.
  
  What I did on the LTS of the fact table, on the tab general got the fact Table on the mapped tables and I added the table Dim doing a join internal between the fact Table and the Table Dim. This way when I go to the content tab, I can do: Dim.Code = "ABCD" because the tables are attached now.
  
  Is it bad to do? Is there a better way to solve this problem?
  
  Before ask you I can't do it directly on the table of the Sun because this chart Dim is used in other Tables of facts. Creates an alias for the Table Dim and limit there the way forward?
  
  I hope that I was clear, thank you

  The way you do it is correct. If you have only one or two measures, then you could also do it using logical columns with the filter function.

  table of facts, for example:
  value = (unfiltered, do not show in the layer close)
  Value of ABCD = (filter (value using dim code = "ABCD"))

  Then you can expand this without having to create a table of facts for each variation:
  value = (unfiltered, do not show in the layer close)
  Value of ABCD = (filter (value using dim code = "ABCD"))
  Value of XYZ = (filter (value using dim code = "XYZ"))
  First value = (filter (value using dim code = "RST"))

  etc. Contrary to the statements of case, it pushes the return filter logic to the database (you get a where clause clause). Kind regards

  Robert