Oracle BI Architecture and Components
The layered stack
Oracle BI is best understood as a chain of tiers, each with a distinct job. The client tier is the browser and the analyses or dashboards it renders. The web tier hosts the presentation services application, which manages sessions, dashboard layout, and the catalog of saved objects. The application (middle) tier runs the BI Server, the query engine that translates logical SQL into physical SQL against sources. Beneath it sit the data sources: transactional databases, warehouses, flat files, and OLAP cubes. A separate scheduler component runs agents and delivers results by email or to a dashboard.
What each component owns
Know the division of labor. Presentation Services never talks to a database directly; it sends logical SQL to the BI Server. The BI Server reads the repository (RPD) for semantics and caching settings. The Oracle BI Presentation Catalog stores analyses, dashboards, filters, and prompts as XML files in a folder hierarchy. The Cluster Controller coordinates servers in a scale-out deployment, and the JavaHost supports charting and some advanced visualization services.
Traps to watch
Questions love to blur the boundary between logical and physical SQL. The BI Server emits logical SQL to Presentation Services and physical SQL to the database - a frequent reversal trap. Another trap: the catalog is not the repository. The RPD holds metadata and business models; the catalog holds user content. Also remember that caching happens in the BI Server, not the web tier, and that the scheduler is optional infrastructure, not part of the query path.
Rule of thumb
Trace any request top-down: browser → Presentation Services → BI Server → physical source. Whichever component appears in the middle of that arrow chain is the answer to "which component does X?"