The short answer is 'no', join order is not relevant.
Type of join, yes, but you can specify that in the logical layer when joining logical tables.
OBIEE will use metadata configured in the rpd, like levels and no of elements to optimise your queries.
And of course the best foundation for speed is report against a data warehouse consisting of star schemas, as opposed to 3NF modelling, which whilst possible will always be sub-optimal.
Where are you trying to filter out the records - At RPD Level or at Analysis/Report Level?
Also, is this filtering based on the inputs the users will provide?
If yes, I think you can get the help of Session Variable in RPD and Request Variable in Analysis to achieve this.
I hope this link will help you understand the things as well. (How to Use Presentation Variable in RPD? )
Also, you will have to use this in WHERE section of BMM layer.
1 person found this helpful
But if; -
Fact -> Time Dimension
Where -> is fact.time_key = Time.Key
And filter is; -
Time.Year = '2018' (or whatever descriptor)
Then OBIEE will NOT do full table scan on fact table and access will 'lead' by smaller time data set.
Unless something is badly wrong with your data model....
If you look at all the answers, then...long story short: The problem is probably something completely different than an "order of joins".
Adding to Robert's comments I'd also say: If you are in the situation where your join multiplies the result rows because you're joining in N corresponding rows then there is definitely something rotten with your model to begin with.
That would make a nice three letter acronym, the RMP; "Rotten Model Paradigm" ;-)
As in; - Looks like you have a real RMP there...
And if you have several of them, it will make the project sound like it's going down a stony road on wooden tires: rmp, rmp, rmp, rmp...
A good analogy on a number of levels
If your question is answered could you kindly close it / mark correct / helpful as appropriate.