Derived table:

Derived table is not a physical in database however its logical table created in Business Objects Universe
using SQL. Derived table can be considered like views in database where its structure is defined using
SELECT statement.
Create Derived table in universe Designer:
Either goes to Insert Derived table or right click in the universe Structure and click Derived table, the
new Derived table editor will open.

Nested derived tables

A nested derived table (also known as a 'derived table on a derived table') is a table that is derived from
at least one existing derived table. The nested derived table can also reference the database tables.
Below are advantage and disadvantages of using Derived tables.

Many levels of nested derived tables can be created using @derivedTable function. Example, You

have Derived table DRV_SALES and want create another derived table by using DRV_SALES, then
create Select * from @Derived Table(DRV_SALES). Nesting derived table is limited to 20 levels.
Advantages:

SQL Statements with complex joins, expressions and conditional prompts can be used to create

derived tables when those are not possible in BO universe through normal tables.

Derived table will reduce the amount of data returned to the document for analysis.

Derived tables can be used as a normal table in the universe and do join with other tables.

To Update / Change the derived table structure in the universe is very easy.

You can merge data from different table which is not possible using normal in universe using

underlying data sources.

You can embed prompts in derived table definition.

Disadvantages:

Derived table cause poor performance of the report because the derived table do not stored the data

and it will execute whole SQL each report run.

Derived tables may cause memory issue on the server, if the database tables used in the derived

tables are huge and the query is complex.

Thinks to Remember:

Use only when you need complex joins and calculations between tables in the BO universe then go

with Derived table.

Join:
A join is a condition that links the data in separate but related tables. The tables usually have a
parent-child relationship. If a query does not contain a join, the database returns a result set that
contains all possible combinations of the rows in the query tables. Such a result set is known as
a Cartesian product and is rarely useful.as they allow you to combine data from multiple tables
in a meaningful way.
You have several approaches to creating joins in Designer:
Tracing joins manually in the schema.
Defining join properties directly.
Selecting automatically detected joins.
Automatically creating joins on table insertion.

Defining specific types of joins:

1. Equi-Joins: Link tables based on the equality between the values in the column of one table
and the values in the column of another. Because the same column is present in both tables,
the join synchronizes the two tables. You can also create complex equijoins, where one join
links multiple columns between two tables.
Table1.column_a = Table2.column_a
Complex equi-joins: You can also create a complex equi-join. This is a single join that links
multiple columns between two tables. You can create complex equi-joins by using the Complex
operator for a join in the Edit Properties sheet for a join.
2. Theta joins (conditional joins): Link tables based on a relationship other than equality
between two columns. (between operator).

3. Outer Join: Outer join links two tables using a join operator. When tables are linked using
outer joins the select query returns all the records which matches the join condition and returns
all the records from one table even though do not match the join condition.
(Or) Link two tables, one of which has rows that do not match those in the common column
of the other table. There are two types of outer join
Left Outer join: This outer join returns all the records from left table even when they do match
the join condition.
Right Outer join: This outer join returns all the records from right table even when they do
match the join condition.
4. Shortcut Joins: A shortcut join is a join that provides an alternative path between two tables.
Shortcut joins improve the performance of a query by not taking into account intermediate
tables, and it reduces number of joins in a query. Shortcut join is represented by dotted line in designer.
5. Self-restricting joins: Self restricting join is not actually a join but a restriction on a table.
Generally it is used to restrict the data returned by a table. To create a self-restricting join
1. Click on Insert menu and click on join to create new join
2. Select the table on which you want to create self-restricting join.
3. Select the same table name from table 2 combo box also.
4. Select the column which should be used for self-restricting join.
5. Edit the expression and put the restriction condition

6. Click ok

.
Cardinality of self-restricting join should be set to 1:1 otherwise it gives error while detecting contexts.

What is a join path problem?

A join path is a series of joins that a query can use to access data in the tables linked by the
joins. Join path problems can arise from the limited way that lookup and fact tables are related
in a relational database. The three major join path problems that you encounter when designing
a schema are the following:
loops
Chasm traps
Fan traps
Lookup Table: A lookup (or dimension) table contains information associated with a particular
entity or subject. For example, a lookup table can hold geographical information on customers
such as their names, telephone numbers as well as the cities and countries in which they
reside. In Designer, dimension and detail objects are typically derived from lookup tables.

Fact Table: A fact table contains statistical information about transactions. For example,
it may contain figures such as Sales Revenue or Profit. In a universe, most but not all,
measures are defined from fact tables.
dddsddfdsfsd

Defining aliases:
Aliases are references to existing tables in a schema. An Alias is a table that is an exact
duplicate of the original table (base table), with a different name. The data in the table is exactly
the same as the original table, but the different name "tricks" the SQL of a query to accept that
you are using two different tables.
An alias is used when the same table is used more than once, and is typically indicated by that
table always being on the one side of a one-to-many joins.
A common use of alias is when a lookup table needs to be referenced several times in a query
and when different join rules exist for the lookup table. The alias allows for the lookup table to
be included multiple times in a universe and allows for the correct join rules to be associated
with the lookup table.
To use the table more than once in a query. This is the main reason for using aliases, and
includes using aliases to solve loops and fan traps.
Defining contexts:
Contexts are a collection of joins which provide a valid query path for Web Intelligence to
generate SQL.
They are used to resolve loops (and other SQL traps) and are indicated by tables always
appearing on the many side of a one-to-many join.
A context is a rule by which the report user can decide which path to choose when more than
one join path exists in query from one table to another table.
Solving loops, solving chasm traps.
Resolving loops:
In a relational database schema, a common type of join path that returns too few rows is called
a loop. A loop is a set of joins that defines a closed path through a set of tables in a schema.
Loops occur when joins form multiple paths between lookup tables.
Loops can be resolved by Alias, context.

Examples of Resolving Loops:

Creating an alias to break a loop caused by shared lookup tables
Determining when an alias is not appropriate to break a loop
Creating a context to resolve a loop
Using an alias and context together to resolve a loop.

Resolving Chasm Traps:

A chasm trap is a type of join path between three tables when two "many-to-one" joins converge
on a single table, and there is no context in place that separates the converging join paths. A
chasm trap is a common problem in relational database schemas in which a join path returns
more data than expected.

You will get incorrect results only when all the following conditions exist:
A "many to one to much relationship" exists among three tables in the universe structure.
Query includes objects based on two tables both at the "many" end of their respective joins.
There are multiple rows returned for a single dimension.
If you have two fact tables with many to one joins converging to a single lookup table, then you
have a potential chasm trap. Creating contexts will always solve a chasm trap in a universe.
When you have dimension objects in one or both fact tables, you should always use context.
When you run queries on the tables in the chasm trap, the query is separated for measures and
dimensions defined on the affected tables.
Like for the example below, where a customer can have multiple sales and also have multiple
purchases.

Now below conditions need to be met for a trap to occur:

1. There should be many to one to many join relationship between the three tables.
2. There should be objects selected from the many end of join tables (For eg. Objects from
sales and purchase should be present in query)
3. And as the cardinality says there should be multiple values of Customer table present in sales
and purchase table. (For eg. Customer 1 should have 2 or more rows of sales or 2 or more rows
of purchases)
The trap causes inflation of results and you basically get a result which is more than the
expected one (Like a Cartesian product).
I have created three tables:

These tables are connected in the following way, classes and objects created from this table list:

Query 1
Id

Query 2
C Name

Purchase Value

Id

C Name

Sale Value

101 Ashish

11,000

101 Ashish

6,000

102 Gaurav

7,000

102 Gaurav

4,000

Correct Results

Correct Results

Query3
Id

C Name

Purchase Value

Sale Value

101 Ashish

33,000

12,000

102 Gaurav

7,000

4,000

Wrong Results
Note:
In Query 1 purchase value of Ashish is coming correctly; in Query2 sale value is coming
correctly.
In Query 3, I used both purchase value and sale value in one query and it can be seen that the
results are inflated for Ashish.
But the result for Gaurav is still correct.
Now we will bring more objects in the query to see where exactly the problem is:

Id
Id

C Name

C Name

Sale Dt

Sale Value

Purchase Dt Purchase Value

101 Ashish

2010-01-01

1,000

101 Ashish

2010-02-01

2,000

101 Ashish

2010-01-10

5,000

101 Ashish

2010-02-10

6,000

101 Ashish

2010-03-01

3,000

102 Gaurav

2010-01-10

7,000

102 Gaurav

2010-01-01

4,000

Query1

Query2

Query3
Id

C Name

Purchase Dt Sale Dt

Purchase Value

Sale Value

101 Ashish

2010-01-10

2010-01-01

5,000

1,000

101 Ashish

2010-01-10

2010-02-01

5,000

2,000

101 Ashish

2010-01-10

2010-03-01

5,000

3,000

101 Ashish

2010-02-10

2010-01-01

6,000

1,000

101 Ashish

2010-02-10

2010-02-01

6,000

2,000

101 Ashish

2010-02-10

2010-03-01

6,000

3,000

102 Gaurav

2010-01-10

2010-01-01

7,000

4,000

I included purchase dt and sale dt in query 1 and query2 respectively.

In query 3, I included both of them.
Now the difference can be visualized in Query 3 number of rows which is coming for Ashish is
more than the expected one. Reason is it is created all possible combinations of sales dt and
purchase dt that makes (2*3=6 rows) of data for Ashish. But for Gaurav data is coming correct
because he has only one entry in both table so 1*1= 1 row.
So when we remove the purchase dt and sale dt from query 3, it aggregates and display wrong
results.
Lets see how to overcome this scenario.
How to detect chasm trap:

Mostly by analysis. When you are creating the universe, you should look for join
conditions (n:1:n) and definitely the inflation of results in reporting.

Detect Context in universe designer can help to analyze possible contexts, which says
there could be a trap, which needs to be resolved.

Now if I select sale value and purchase value in same query, it will generate below sql.

And the report data will be :

Id

C Name

Purchase Value

Sale Value

101 Ashish

11,000

6,000

102 Gaurav

7,000

4,000

This is absolutely correct.

Note: This option will not generate multiple sql for each measure, if you have not defined
aggregate function in the measure definition.For eg.,

If the definition of measure is like above than it will not create two sql, even if option is checked.
We need to have the deifintion as:

Note: this method will also not work if we select dimension objects from many end of the query
as two select will not be generated and will still display inflated results.
2. Another method which will resolve this issue is by Context, which is the most acceptable one.
Create two contexts like below:

Also we need to click on the check box in parameters:

If you dont click on this check box, using objects from purchase and sales in a single query will
fetch Incompatible objects error.
By clicking on this check box, will give two queries for each context, both in case of measure or
dimensions coming from many end of tables.

Id

C Name

Purchase Value

Sale Value

101 Ashish

11,000

6,000

102 Gaurav

7,000

4,000

This will resolve Chasm trap and will correct results in query.


Fan Trap:
This is also a join path problem created in universe when below scenarios are met:
Consider table A, B and C.

A --< B --< C i.e. A to B is One to Many and B to C is One to Many AND

Measures selected from Table B and any kind of object from Table C AND

Table B holds aggregated values from Table C.

This trap can also be created when we are having only two tables say B and C with One to
Many relationship, where we are using dimension and measure (which is aggregation of a
column in C) and an object from C table.
The results will be inflated like Cartesian product.
For eg:I have three tables

These tables are connected in below manner:

The relationship is something like this:

A customer says Gaurav purchased a car and accessories. He paid total amount (car cost +
accessories)=4000.
Now table Sales contain 4000 as the amount and sales detail captures the breakup of that
amount i.e.(car=3000 and accessories = 1000). So Sales tables hold aggregated value from
sales_detail table.
Classes and objects:

Now I will try to create a webi report using objects:

Query 1

Correct result

Id Sales

C Name

Sale Value

213 Gaurav

Query2

4,000

Incorrect result

Id Sales

C Name
213 Gaurav

Sale Value
8,000

Item Value
4,000

Adding another object i.e. Item type from

tableC.

C Name

Id Sales

Item Type Item Value Sale Value

Gaurav

213 Accessories

1,000

4,000

Gaurav

213 car

3,000

4,000

Observe that when we added Item Type to get the detail , item value is properly displayed but
sale value still shows two rows with same value and hence when we remove the item_type, it
gets aggregated and show 8000, which is a wrong value.
How to resolve this: Again like Chasm trap you have to create two separate queries to display
correct result.
1. Create 2 sql statements by checking the option of Multiple sql statements for each measure
2. Create alias and context.
3. Use aggregate awareness to avoid this scenario.
1. Setting the option in universe parameter:

This will generate 2 sql statements, if measures are selected from 2nd and 3rd table.

C Name
Gaurav

Item Value

Sale Value
4,000

4,000

This gives correct results. But will not work in case you are selecting only dimension objects and
not measure.

2. Using Aliases and Context:

We will now try to solve the trap using combination of aliases and context.
Create an alias of middle table, in our eg. It is Sales table.

Join Customer with alias table and set cardinalities of the same.
Now we will create two context lets say C1 and C2 like below.

Now we have to take the measure object from sales table i.e. sale_value from the aliased table
rather than sales, so repoint the sales value object to point to sale_value column of sales2
table.

Also check the below option in universe parameters:

Now, if you use the measure objects from two different context in one query, it will generate
multiple sql statements and the results will be correct.

C Name
Gaurav

Sale Value
4,000

Item Value
4,000

Note: There is another scenario also where this kind of trap can be created.
Lets say for example, in our structure of universe:

Lets say I ignore Customer table.

Now If have objects like C_id(dimension Object) , Sale_value(measure) from sales table and
item_value from sales_detail table in webi rich client query, it will again create a trap and will
show inflated results.
C Id

Sale Value
102

8,000

Item Value
4,000

So its showing inflated results again i.e. wrong value of sale value.
To resolve this, we will create alias of sales table, same as above case.

Created two contexts C1 and C2.

Checked the option of Multiple SQL for each contexts in universe parameters.
Change the sql of sale value object to point to sale_value column of alias table i.e. sales2.
Now, if you select the objects c_id, sale_value and item_value. It will display correct result.

What is an object?
In Business Objects products an object is a named component in a universe that represents a
column or function in a database.

What types of objects are used in a universe?

Three types of objects exist within a Business Objects universe
Dimension: Text based or date values that are the primary describing values of a query.
For example Country, Sales Person, Products, or Sales Line.
Detail: A detail provides descriptive data about a dimension. A detail is always attached to a
Dimension ex: phone number, address
Measure: Contains aggregate functions that map to statistics in the database. Sales revenue,
Profit. Measures differ from dimensions and details in the following ways:
1. Measures are dynamic: Returned values for a measure object vary depending on the
dimension and detail objects used with the measure object in a query.
2. Measures can project aggregates
What is a class?
A class is a container of objects. A class is the equivalent of a folder in the Windows environment.

Groupings or categories of objects within a universe are called classes. The primary function of
classes is to provide structure to the layout of universe. Typically, the general strategy is to
group related dimension and detail fields into a class and place measure objects into a different
class. This strategy can be extended through introducing sub-classes to break down objects into
more granular subsets.
Three categories of classes exist
Dimension Classes: Objects which are shared across transaction types to describe the
transaction and provide summarization levels.
Measure Classes: Primary reporting objects for displaying numeric results (also known as
facts).
Application Classes: Objects that support the reporting application, including customized lists
of values, prompts, and condition objects.

Subclasses:
A subclass is a class within a class. You can use subclasses to help organize groups of objects
that are related. A subclass can itself contain other subclasses or objects.

Hierarchies in Business Objects Universe:

Def.: Hierarchy is an ordered sequence of dimensions which is very helpful for multidimensional analysis of data.
Multidimensional analysis allows users to observe data from various viewpoints.In Web
Intelligence you can use drill up or down to perform multi-dimensional analysis.
Time Hierarchy:
Day->Week->Month->Quarter->Year
Geographic Location Hierarchy:
City->State->Country->Region
Hierarchy of designation:
CEO->CTO->Director->Manager
There are three type of drilling.
1.

Drill UP Drill up the levels from Low level detailed data to high level summarized data.

2.

Drill Down Drill down the levels from high level summarized data to Low level detailed

data.
3.

Drill By Drill By is an advanced drill feature that is also listed in the speed menu with Drill

Up and Drill Down. It allows you to skip over objects in the current hierarchy or to jump to a
different hierarchy for additional analysis.

Hierarchies in Business Objects Universe

1. Default Hierarchies:
By default hierarchy is set based on order in which dimensions are placed in the class.
e.g In store class dimensions are arranged as State->City->Store Name. So by default hierarchy
would be set as from top dimension to lower dimension.

2. Custom Hierarchies:
Business Objects allows creating logical hierarchies using custom hierarchy. In custom
hierarchy the sequence of dimensions is defined by developer based on business need of
analysis.

End user might want to drill down the revenue generated based on employee designation. You
can define the sequence of dimensions based on business need.
Creating Custom Hierarchies:
1. Click on Tools->Hierarchies
2. Hierarchies editor will show default hierarchies

1. Click on New Button to create new hierarchy

2. Select objects by expanding classes and click on Add button
3. You can use Move UP/Down Button to arrange the dimensions.

If two or more hierarchies starts with same dimensions but follow different dimensions at lower
end and if user performs drill-down on dimensions from such hierarchy then Web Intelligence
asks user to select the drill path.
e.g. If we create two custom hierarchy which starts with Year but follow different path.

Then it asks user to select the drill path as there two drill path defined from Year.

List of Values (LOV) in Business Objects Universe:

List of values or LOV is a distinct list of data values associated with an object. When any
dimension of details object is created LOV is assigned to an object automatically.

1. LOV from Database:

Use of List of values:
When user needs to filter data in a query based on specific object values, User can simply view
the LOV of that objects and choose the value on which they want to filter the data.

A LOV is

generated by a simple SQL statement like SELECT DISTINCT TABLE.COLUMN FROM

TABLE. But you can modify the statement by adding some other objects through the Query
Panel; you can also add some conditions on these objects.
e.g. if COUNTRY dimension has following distinct values
A,B,C and if user wants to filter the data of country B, user can put a filter on Country dimension
and choose the B as filter while executing the query.
How to create a LOV for an object:
1. Double click on object in designer to view its properties. 2. Click on Properties Tab
3. Click on Associate a List of Values checkbox.
4. Select other LOV options based on requirement.

When first LOV is created it is stored in .LOV file name at universe subfolder on the system file
system.The default location is
C:\Documents and Settings\<UserName>\Application Data\Business Objects\Business Objects
12.0\Universes\@<ServerName>\<UniverseName>

LOV Options
List Name
Its the name of LOV file by which it will stored on local file system. User can override the default
name and can enter his own LOV name. Maximum character limit is 8.
Allow Users to Edit List of Values
When checked this option allows report users to edit the list of values of an objects. The
purpose of a list of values is usually to limit the set of available values to a user. If they can edit
a list, you no longer have control over the values they choose. Normally, if you are not using a
personal data file as a list of values source, you clear this option to ensure that users do not edit
lists of values.
Automatic Refresh before Use
When selected this option LOV will be refreshed each times it is referred and used in report.
You should choose this option only if contents of underlying column are frequently changing.
These options should be use very carefully after evaluation. If this option is not selected LOV is
refreshed first when the objects is used in a user session.
Hierarchical Display
Select the Hierarchical Display property to display the cascading list of values as a hierarchy in
Web Intelligence.
Export with Universe
When this option is selected LOV file associated with object is exported to universe CMS and
gets stored as XML on CMS
Viewing the LOV of an object
To view the LOV of an objects click on display button on properties tab of an object

Modifying the LOV of an object

You can remove the values from LOV of an object by applying a filter or add values to LOV by
adding a column.
Apply condition on LOV
To apply condition on LOV
1. Click on Edit button on objects edit properties tab
2. The designer query panel will appear showing default object of a LOV
3. Drag drop the condition object in condition pane and specify the appropriate condition.
4. You can also view the SQL of the LOV query by click on SQL icon on toolbar.
5. Run the query to test the values after applying condition on LOV

2.LOV from a flat file:

View and Edit LOV of complete universe
You can also view the entire object which has LOV associated with them and edit them.
1. Click on Tools->List of Values->Edit
2. List of values dialog will appear
3. Select the LOV objects and click on Edit if you want to edit a LOV.

1. In addition to query you can also define LOV for an object using personal data file like CSV and
values from this file can also be used as LOV for an object. To do so.
2. Click on Personal Data and provide the details on Personal data LOV dialog box.

Cascading LOV:
Cascading LOV is a LOV associated with hierarchy of an object in the universe. Cascading LOV
is created, and if any of the objects is used as prompt filter in report query, user has to answer
series of values from cascading LOV.
How to create Cascading LOV
1. Click on Tools->List of Values->Create Cascading LOV.

1. Add the object and re-arrange them as per your hierarchy

2. Click on generate LOVs
3. Click OK.
Now if you use any of the objects as prompt in query. It will prompt the hierarchical LOV to user.

Linking universes

Linked universes are universes that share common components such as parameters, classes,
objects, Or joins. When you link two universes, one universe has the role of a core universe, the
other a derived universe. When changes are made in core universe, they are automatically
propagated to the derived universes.
What is a core universe?
The core universe is a universe to which other universes are linked. It contains components that
are common to the other universes linking to it. These universes are called derived universes.
The core universe represents a re-usable library of components. A core universe can be a
kernel or master universe depending on the way the core universe components are used in the
derived universes.

What is a derived universe?

A derived universe is a universe that contains a link to a core universe. The link allows the
derived universe to share common components of the core universe:
If the linked core universe is a kernel universe, then components can be added to the derived
universe.
If the linked core universe is a master universe, then the derived universe contains all the core
universe components. Classes and objects are not added to the derived universe. They can be
hidden in the derived universe depending on the user needs of the target audience.
Different ways to link universes:
You can use any the following approaches when linking universes:
Kernel approach
Master approach
Component approach
You can use any of the three approaches individually, or, combine one or more together.
Kernel approach:
With the kernel approach, one universe contains the core components. These are the
components common in all universes. The derived universes that you create from this kernel
universe contain these core components as well as their own specific components. Any
changes you make to the kernel universe are automatically reflected in the core components of
all the derived universes.
Master approach:
The master approach is another way of organizing the common components of linked
universes. The master universe holds all possible components. In the universes derived from
the master, certain components are hidden depending on their relevance to the target users of
the derived universe. The components visible in the derived universes are always a subset of
the master universe. There are no new components added specific to the derived universe. Any
changes you make to the master universe are automatically reflected in the core components of
all the derived universes.
Component approach:
The component approach involves merging two or more universes into one universe. The Sales
universe below was created by merging two universes.

Advantages of linking universes

You have the following advantages when linking universes:
Reduce development and maintenance time. When you modify a component in the core
universe, the universe design tool propagates the change to the same component in all the
derived universes.
You can centralize often used components in a core universe, and then include them in all new
universes. You do not have to re-create common components each time you create a new
universe.
Facilitate specialization. Development can be split between database administrators who set
up a basic core universe, and the more specialized designers who create more functional
universes based on their specific field.
Limitations and Restrictions of Linking Universes:

Both the universes (core and derived) must use same connection and should connect to
same database.

Both the universe must be present in same repository in order to link.

Only one level of linking is allowed you can create derived universe from another derived
universe.

Both universes should have unique object and classes. If there are duplicate
objects/classes it will be renamed in core universe.

Tables from two universes must be joined after linking in order to avoid Cartesian product.

When core universe is linked in derived universe only classes, objects and tables are made
available in derived universe. Context and LOV needs to be recreated in derived universe.

How to Link Universes?

To link universe make sure

Core universe is exported to repository

Its open in designer.

Now open universe parameters from File->Parameters

Click on Link tab

Click on Add Link

Select the core universe to link.

Click OK

After this components from core universe will be available in derived universe and it will be
grayed.

Now analyze the derived universe and create joins between tables added from core
universe.

Create context/Alias wherever required.

Save and Export the derived universe.

Using Include to import one universe into another

In linking universe contents are not copied to derived universe and one cannot edit the core
universe components in derived. However sometimes one need to merge two universe into one.
For this purpose one can use Include universe approach instead of linking. When universe are
included components of one universe are copied into another.
Difference between Linking and Including Universes:
Linking
Core universe structure is created once and used in many derived universe.
Only one copy of components from core universe exists in repository.
Changes needs to done only to core universe and it gets propagated to all derived universe.
Linking universe needs both the universe to be present in repository.
Only one level of linking is allowed.
Context and LOV needs to recreate in derived universe.
Both the universe must use same connection and connect to same database
Including
Its the easiest and fastest way to copy universe into another.
Context needs to redefine after including.
Changes are not propagated from core to derived universe.
Both the universe must exist in repository like in linking.
One can easily maintain one universe rather than multiple universe o maintenance becomes
bit easy.

Aggregate Awareness in Universe:

Aggregate awareness is a feature of DESIGNER that makes use of aggregate tables in a

database. These are tables that contain pre-calculated data. The purpose of these tables is to
enhance the performance of SQL transactions; they are thus used to speed up the execution of
queries.

Lets see what this aggregate awareness functionality is and how it is useful in universe.
Lets say I have two tables customer and daily fact with below data:

If I create the report of customers daily sales, it will join customer and daily fact table using cid
column and will give me 24 rows of data.
But if my requirement is to create only quarterly sales or just monthly sales than the data will still
traverse through 24 rows of daily fact table.
For eg. Monthly sales will give me 12 rows of data while quarterly will be 4 rows of data. But
this is still getting data from detail fact which has 24 rows, which if hold million facts can slow
down the performance.
So we create materialized views or summary tables in our database for better performance.
And I created monthly and quarterly fact in my sample database. Below are the aggregated
tables that I can use in my universe.

Now, the question is, we have aggregate tables but how to use the same in my universe based
on user queries dynamically. Aggregate awareness functionality will help me in achieving the
same. It is a two-step process:
1

Use aggregate aware function in objects that needs to be made aggregate aware.

Setting incompatibilities of objects with tables in aggregate navigation section.

Below is the structure of my universe now:

Now, I have made time dimensions i.e. Sales Dt, Sales Month and Sales Qtr and measue Sales
as aggregate aware.
Aggregate function has syntax like:
@Aggregate_Aware(sum(aggregate table1),...,sum(aggregate tableN)) Defines a measure
object using precalculated aggregate tables.
Where table1 is highly aggregated (in our case quarterly fact),........and tableN is the least
aggregate or detailed one(in our case daily fact)

If you observe the definition in the select statement of Sales measure here, it is from highly
aggregated table to detail one , same is done for the dimension table as well.

Now month is present in only two tables, hence only monthly and daily fact is used.

Sales Qtr object, quarter is present in all three fact tables; hence all the three are used.
We have used aggregate function in these tables, so we hope that system automatically will
decide which table to refer dynamically, when a user selects or tries to run a query.
That means if user wants daily data than daily fact should be used, if monthly than monthly fact
or if quarterly sales than quarterly fact.
Now, we have to set the incompatibilities.
This is done from Aggregate Navigation section under tools, in menu bar.
We have to make objects incompatible to tables.
For eg. Sales dt is incompatible to quarter and months table, similarly Sales month object is
incompatible to quarter table.
You have to click the table and check the box in front of object to make it incompatible with the
selected table.

Lets see how the queries behave, when you select different set of objects:
Scenario 1:
I selected customer name and sales, and if you see the below query , it is behaving same as the
one i expect it, as it is taking data from quarterly fact table.

Scenario 2: I added sales month object to it, and will remove quarter object.(it should only now
point to monthly facts)

And if you observe, it is now using monthly facts only.

Scenario3: Using sales dt object.

This also worked correctly.

Note: if aggregate navigation have not been used than the measure sales will always point to
quarterly fact, even if you use sales dt object in your query, which is wrong behavior.
Also it is required to link aggregate fact to dimension tables, else it would fetch Cartesian
product for table which are not joined. In efashion universe the aggregate table are not joined to
other because the table itself has all the dimension objects, which is not always the case. In real
time aggregate fact will hold aggregate measures and foreign keys of dimension table only, that
is why it has to be joined to dimension tables.

. What are the different @ Functions?

@Aggregate_Aware
@Prompt
@Script
@Select
@Variable
@Where

 The @prompt function asks the end user to enter any specific values. Prompt functions are
generally used in where clause of an object to build interactive filter condition in the report.
@Prompt(message,type,[lov],mono/multi,free/constrained/primary_key,persistent/not_
persistent, [{default value:default key'[,default value:defaultkey,]})
Message: Is the text which would be prompted to user. It should be included in single quotes.
Type: Data type to be returned by function. It can be any one of following.
A: Alphanumeric
N: Number
D: Date
LOV: List of values which would be displayed to end user to choose from. LOV could be
hardcode or you can use LOV of an existing object.
e.g. {A,B} or Country\Name
Mono: User can select only one value from list
Multi: user can select multiple values from list
Free: User can select or enter value.
Constrained: User ,ust select value from the list.
The Visual Basics for applications macros results will be recovered by using @Script
function. @Script(var_name, vartype, script_name)
An existing statements SELECT statement can be re-used by using @Select function.
Syntax: @Select(Classname\Objectname)
The @Variable function is used to call the value assigned to variables. This function is
generally used in security implementation. You can more information on this function
on business objects user guide.
e.g. You variable (BOUSER) will return the name of currently logged in business
objects user
An existing objects where clause can be re-used by @Where functions.
Syntax: @Where(Classname\Objectname)