Žiga Vaupot's Blog

Using Session Variables in Row-Level Security Setup Dynamic row-level security is essential for scalable and maintainable data governance. It allows data access to be tailored automatically based on the current user’s context, improving security while simplifying administration. Instead of hard-coding filters for each user or report, dynamic security ensures that as the user base grows or changes, the security model adapts seamlessly without requiring manual updates for every report or subject area, enhancing both performance and user experience. In our first test example, we saw that we can use Session Variables for filtering analyses and reports based on a dynamic value dependent on the current user. However, it doesn't make much sense to create these filters every time on each report or analysis. It is a much better idea to implement filters in the model itself. This results in implicit filters on all reports, without the need to create filters explicitly. Applying row-...

In Oracle Analytics Semantic Modeler, variables play a critical role in customizing and controlling Analytics behavior at runtime. There are three main types of variables: Session Variables Global Variables Static Variables A global or session variable's initialization block contains a default initialization query that is run to initialize or refresh the variables defined in the initialization block. The initialization query references the data source's tables that supply the variable values. A query can populate values into several variables, with one variable for each column in the query result. A static variable's initialization block doesn't contain an initialization query. To define a static variable, you specify the variable name and value directly. Session Variables Session Variables are dynamic variables set per user session, typically at login or when a report is run. They help personalize content, enforce security, or pas...

In Oracle Analytics, calculations are a powerful way to create reusable business logic, KPIs, and metrics. These calculations reside in the logical layer ( Business Model and Mapping ), where they can be defined once and reused across multiple dashboards and reports, improving consistency and reducing maintenance effort. When we created a new Business Model in the Logical Layer , we defined measures in two main ways: The Fact table contains columns that are natural measures, such as REVENUE or UNITS . We can also use foreign key columns in a Fact Table to create count-based measures , such as # of Orders or # of Distinct Customers . However, these are not the only types of measures we can create in our Business Model . Calculations or Calculated Measures are essential for capturing business logic that may not exist as a raw column in your source data. While calculated measures are typically included in Facts , we can also define calculated columns in Dimensions . This ...