"I want to display data from AL_FACT_ENG_EBOM and AL_FACT_ENG_EBOM_LEVEL_ZERO same column is available in both the tables.." Do you mean IF available ... what happens if it is in BOTH tables for the same dimensional intersection? Are the tables at the same grain? You have a lot of modelling considerations to work out ...…

Since cost doesn't change you can set the aggregation on cost specific to status_date dimension as being LAST ... then the cost returned is only the most recent for any given order. Also set it to SUM for all other dimensions. ^ the above is predicated on you having modeled the data correctly to support the use

You can't ... BUT you can query Apache Spark and show BIPublisher content on your dashboards https://www.cdata.com/kb/tech/spark-jdbc-obiee.rst

If I recall correctly there was a bug with 12c and horizontal scaling ... you might need an SR with Oracle to get the specifics to be able to complete the task.

I don't see anything on Competency Center for a comparable 12c version ....

does cost change based on status? if not - you really want the average across orders but only for the most recent status ... then you have the concept of distinct without the shortcut of distinct.

You can leave the snowflake at the physical layer and model the logical layer as a star (which obiee requires to function). So you can have the logical dimension with 4 tables as logical table sources then join that logical dimension to your fact. You'd see the snowflaking in the physical SQL sent back to the DB, but…

a properly designed calendar/date dimension will allow you to do canonical time based calculations. User picks a date or a range and the ago representations are all automatically done: WAGO, MAGO, PAGO, QAGO, YAGO ... and the variances and % changes. Think about setting yourself up for future success now. Doing these…

A properly formed calendar/date dimension is what I've counseled in the past (to you and others) ... do you really want to have to go through this EVERY time you want another time series measure? Build it right ONCE - use it properly MANY TIMES.

why does your image show a separate logical fact but your case statement is reflecting another logical fact?

yes - that's another viable option to have a Revenue Month that represents the MM-YYYY of each date in the month. I've always said a well formed calendar/date dimension is 101 fundamental and pays for itself minutes after deployment!

Targeting a specific row is counter-productive to analysis ... if this is what the requirements are then OBIEE is a very expensive excel option. Go back to excel and hide the row or delete it.r Analytically what you have is an outlier ... so you need to statistically account for it (and others like it) or allow the user to…

in reality you are wanting to show all the days from the same month and year, correct? in your filters you'd want something like: Year(date_column) = Year(prompted_date) AND Month(date_column) = Month (prompted_date)

Using your support identifier go check out Doc ID 1559666.1 in Oracle Support.

Use a prompt to let the user set a range for acceptable Revenues ...

What about a level based measure pinned at Product total content level?

No ...

I understand that ... but ramming it into the original table is what has caused you the issue. The original grain is still valid AND separate from the new grain - hence a new physical structure is needed. Logically you can put it back together and present it as if it were all coupled nicely (thanks to the capabilities of…

So why was the grain of the rows changed if the fact was already additive? a new fact table at a different grain should have been built. OBIEE logically could have handled it and the change would have been much easier to implement and the end users largely unaffected by the incoming change. I'd argue that it's not a flag -…

A_CAN is what in terms of data ... you say count but aggregate with a sum -- that's inconsistent and confusing.With your SQL example ... selecting distinct with a group by of the same is redundant ... in any case ... A_CAN doesn't seem to match the new grain -- thus you actually are driving at having 2 fact tables (2…