Skip to content

3. Defining an EspressoViews report

RaduMarcel edited this page Sep 9, 2021 · 18 revisions

The hierarchy of SQL queries

An EspressoViews report consists of two or more report units. The heart of every report unit is the SQL query. A report unit is assigned a name, which acts as an identifier and preferably also as a short description of the information retrieved by the SQL query.

All report units in a definition file are linked to each other in a hierarchical structure, i.e. in a tree structure, whereby the first unit (read top-down) is the root or the first ancestor. In the below example are used 6 units/queries to build such a tree structure. The report units are represented here by an identifier followed by a list of the column names retrieved by the SQL query:

Explicit inheritance

Each valid query has minimum one column*. For every query in the hierarchy of queries you can explicitly chose one or more column names from its set of selected column names to be inherited to its children queries. And every child, which inherits one or more column names from his ancestor, transmits this inheritance to its children (given the case it has any children) and adds eventually some of his column names to the inheritance. To visualize this, let’s assume that in the tree structure build up previously the Root Query transmits the column names Column_A and Column_B to its children and Child Query 1.1 transmits Column_D to its child query 1.1.1:

Further, an inherited column name is applicable for an inheriting SQL query if and only if the inherited column name matches one of the column names of the inheriting SQL query.

What does a child query with an inherited applicable column name? This is be explained in detail in the next chapter. In a nutshell, every inherited applicable column name is an additional where-clause restriction applied to the inheriting child query.

No matter if an inherited column is applicable or not, a defined query always transmits an inherited column name to its child queries. The inheritance, once initiated, can be never stopped, but only the applicability of the inheritance. The below figure includes the applicability of the inheritance:

A report definition overview, here laboriously drawn with LibreOffice Impress, can be also generated with EspressoViews if you choose in the drop down menu "View Mode" the option "Structure Only":

Implicit inheritance

If no column name was explicitly specified to be transmitted to descendant queries, then, by default, the immediate children queries will inherit all applicable column names from their father/mother query. Note that this is another approach to define inheritance relations. If, in the above example, the Root Query would have not specified any column to its descendants, then the Child Query 1 would have inherited the columns Column_A and Column_C, Child Query 2 would have inherited only Column_B, and Child Query 2 would have inherited Column_A and Column_B. And finally Child Query 1.1.1 will have inherited only Column_D and not also Column_B, since Child Query 1 does not transmit Column_B to its descendants (see below).

Let's see in the next page how this hierachical structure and inheritance concept is applied.

* Further, the queries should fulfill the requirements of a view: each of the column names in the select clause is unique and each column name should have an unambiguous value domain

Next Page->