Your issue is solved with a physical structure not a logical one.

#2 - use of information drives physical design ... why not have the values already calculated and stored at the intersection of timeofday and duration -- these should be dimensions which drive the grain of your fact table

Use of information drives physical design ... so in your case you want to know a count at a particular point in time AND what it was at a referential point in time past. To do this you need to take snapshots of the counts as they are - so then you can look back. It is far to involved to be trying to look back in time to…

Headcounts are inventory style - to compare over time you are better off storing snapshots of the counts at regular intervals. Doing the calculations logically won't give it to you and trying to nest some of the aggr rules (last, first, etc) in timeseries functions will be problematic. Once you have a snap shot the AGO()…

dimensional modeling would have changed it to 1 fact and multiple dimensions... Really the only measure you have is target amount. So you should have a logical fact table with that and the agent_id key. Then you have 3 dimensions: Dim Agent: Agent_Id, Agent_Name Dim Target: Agent_Id, Target_Start_Date, Target_End_Date Dim…

D Managing Security for Dashboards and Analyses D.2.3.1 What Are Presentation Services Privileges? Presentation Services privileges control the rights that users have to access the features and functionality of Presentation Services. Privileges are granted or denied to specific application roles, individual users, and…

It's DW 101 stuff ... so have your team get it done! 

Every fact table should be built with the Count column having a 1 default value ... use of information drives physical design. Having that count column makes your life so much easier. 

put the raw values into a 100% stacked bar and you get their contributions to the whole ...

https://docs.oracle.com/middleware/11119/core/FUGBI/bi_plan.htm#FUGBI591

you are forcing a dimension ... do it right and have your hours bucket dimension and get a key into your fact table for the range in which the fact timestamp falls (do it in ETL; where you have a ton more power and control to do it right) Hint: when you have timestamp sensitive data it's best to start with DATE and TIME as…

log into oracle via SQL Developer with same connection credentials - do you see the schema in the list and objects?

Oracle database itself can dump a table to xml ... using BIP or OBIEE to do this is inefficient. Take a look at using the Oracle DB Documentation: https://docs.oracle.com/cd/E11882_01/appdev.112/e23094/xdb13gen.htm#ADXDB1600

none of the fact tables are compatible with the query request This means that the BI server is not encountering the logical fact star model it requires. OBIEE - Query Compiler [Gerardnico] (scroll down to the bottom of this page) If you don't have a star model (you have some logical snowflaking) you can model around it…

You are struggling with the roof of the house ... I'm telling you it doesn't fit because of the lack of a foundation. 

Since you have 2 specific granularities month and hour ... really you should have 2 dimensions: Date dim & Time dim ... then both facts are related through the conformed level of date ... one fact can be aggregated to month from there and one can be aggregated to date from time ... your fact B with time in it needs to have…

You don't need administrator rights, you need to run a BI project to make the change. Who's building BI content without use of information requirements? IT departments that foist BI content on the business are doomed to fail - your posts prove it yet again. BUSINESS Intelligence - not PROGRAMMER Intelligence. The fact star…

Use of information drive physical data model design ... build a view/table that puts the address components into their own columns. The database is much better at doing this than the BI or Presentation server.

You need a fact table that stores the count of employees by date - if you want the historical 'inventory' of headcount. It's a snapshot fact - take the snapshot on regular intervals (monthly, quarterly, weekly, etc) or if you don't care about measuring over time ... do what @Christian Berg has suggested.

Google works splendidly ... https://community.emc.com/docs/DOC-14023