Oracle Analytics Weekly Roundup — 11-May

Posted on By Adrian Ward

Below is this week’s Oracle analytics and data roundup for obiee.co.uk readers, covering Oracle Analytics (OAC/OAS), Fusion Data Intelligence, Autonomous Data Warehouse / 23ai, and a practical SQL tip. Note: there were no new official product announcements or blog posts in the provided feed this week, so this roundup focuses on stable, currently available capabilities and how you can use them effectively.

Oracle Analytics (OAC & OAS)

1. Practical Use of Data Actions for Drill-Through Navigation

TL;DR: Data Actions in OAC/OAS let you build intuitive drill-throughs from summary visualisations to detailed reports or external apps, without custom code. Use them to keep dashboards clean while still offering power-user depth on demand.

Even in quieter news weeks, one of the most underused but powerful features in both Oracle Analytics Cloud and Oracle Analytics Server remains Data Actions. These allow you to right-click (or use the context menu) on a data point in a visual and jump to:

  • Another workbook or classic analysis filtered to that selection
  • An external web application (e.g. a ticketing system) with URL parameters
  • A navigation path that mimics traditional OBIEE “drill to detail” behaviour

Because Data Actions are defined at the workbook or project level, they are a low-friction way to add guided navigation for business users without changing the underlying RPD or semantic model. A common pattern is:

  1. Top-level KPI or summary chart in a workbook
  2. Context menu → “View Detail Transactions”
  3. Open a second workbook or classic analysis filtered by the selected customer, product, or period

When designing Data Actions, keep these best practices in mind:

  • Limit the number of actions per visual to avoid clutter.
  • Use clear labels like “Drill to Order Detail” rather than generic names.
  • Test filter mappings carefully, especially when mapping between different subject areas or datasets.

For a refresher on Data Actions in OAC, see the official documentation:
https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsds/use-data-actions.html

2. Keeping OAS and OAC Semantic Models in Sync

TL;DR: If you run both OAS and OAC, treat your RPD/semantic model as a shared asset with version control and promotion paths, rather than two separate models that drift over time.

Many organisations now run OAS on-premises alongside OAC in the cloud. Even without new feature drops this week, it’s worth revisiting how you manage semantic models across environments:

  • Maintain a single source RPD (or JSON semantic model) in version control.
  • Use branching for experimental changes and merge only after testing.
  • Automate promotion from DEV → TEST → PROD for both OAS and OAC wherever possible.

This reduces the risk of “it works in OAS but not in OAC” issues and makes later migrations or consolidations far easier. For reference on semantic models in OAC:
https://docs.oracle.com/en/cloud/paas/analytics-cloud/acsds/model-data.html

Fusion Data Intelligence (FDI)

3. Using FDI as a Curated Source for Analytics

TL;DR: FDI provides pre-modeled, curated data from Fusion applications that you can consume in downstream tools, reducing the need to reverse-engineer Fusion transactional schemas.

There were no new FDI-specific announcements in the provided items, but the existing positioning of Fusion Data Intelligence remains important for analytics teams working with Fusion ERP, HCM, and CX. FDI aims to:

  • Expose subject-area style, business-friendly models of Fusion data
  • Provide historical and snapshot data that is not always easy to derive directly from transactional tables
  • Act as a stable integration layer between Fusion and downstream analytics platforms, including OAC and ADW

For BI teams, this means you can often treat FDI as your “operational data store” for Fusion, and then:

  • Ingest FDI data into Autonomous Data Warehouse for further modeling
  • Expose it directly in OAC via data sets or semantic models
  • Blend FDI data with non-Fusion sources (e.g. legacy on-prem ERP, web analytics)

Official FDI documentation and architecture references are the best place to confirm current capabilities and supported Fusion modules:
https://docs.oracle.com/en/cloud/saas/fusion-data-intelligence/index.html

Autonomous Data Warehouse / 23ai

4. Treating ADW as the Hub for Oracle Analytics

TL;DR: Autonomous Data Warehouse (including 23ai-based deployments) continues to be the natural hub for OAC/OAS and FDI data, offering managed performance, security, and lifecycle operations.

Even without new feature announcements in the feed, the current best practice remains to use Autonomous Data Warehouse (ADW) as the central data platform for Oracle Analytics workloads:

  • Land data from FDI, on-prem sources, and third-party SaaS into ADW.
  • Build conformed dimensions and enterprise metrics in ADW schemas.
  • Expose those curated schemas to OAC/OAS via semantic models.

With the 23ai generation, ADW continues to focus on managed performance, automatic indexing, and patching, which are particularly useful for analytics teams that don’t want to manage database infrastructure. When planning models, keep an eye on:

  • Zone-based schemas (raw, staged, curated, presentation)
  • Incremental loads and change data capture from source systems
  • Partitioning and clustering for large fact tables serving OAC

For current ADW and 23ai capabilities, refer to the official documentation:
https://docs.oracle.com/en/cloud/paas/autonomous-database/index.html

SQL Tip of the Week

5. Using MATCH_RECOGNIZE for Simple Time-Series Pattern Detection

TL;DR: Oracle’s MATCH_RECOGNIZE clause lets you detect patterns in ordered data (like runs of increasing sales) in a single SQL statement, which is ideal for ADW-backed analytics.

Oracle Database (including ADW/23ai) supports the powerful MATCH_RECOGNIZE clause for pattern recognition in time-series or ordered data. Here’s a compact example that finds runs of at least three consecutive days where daily sales are increasing for a given product.

SELECT *
FROM   sales
MATCH_RECOGNIZE (
  PARTITION BY product_id
  ORDER BY    sales_date
  MEASURES
    FIRST(sales_date) AS start_date,
    LAST(sales_date)  AS end_date,
    COUNT(*)          AS days_in_run
  ONE ROW PER MATCH
  PATTERN (rise{3,})
  DEFINE
    rise AS sales_amount > PREV(sales_amount)
);

What this does:

  • PARTITION BY product_id – looks at each product separately.
  • PATTERN (rise{3,}) – finds sequences of at least three rows that match the rise condition.
  • DEFINE rise AS sales_amount > PREV(sales_amount) – each row in the sequence must have higher sales than the previous row.
  • MEASURES – returns the start and end dates of each run and its length.

This is far more concise than equivalent self-join or analytic-function approaches and is fully supported in Oracle Database, making it a great tool for advanced reporting in OAC/OAS projects backed by ADW.

For more details on pattern recognition syntax, see:
https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/MATCH_RECOGNIZE.html

Weekly News