In Framework Manager gibt es verschiedene Hebel zur Optimierung der Abfrage Performance. Einer davon ist die Richtlinie „Minimized SQL wo immer möglich“.

Minimized SQL

Das modellierte Cognos Framework Modell kennt zwei Modi zur Generierung von SQL:

1. „As View“
2. „Minimized SQL“

„Minimized SQL“ bedeutet, dass nur der notwendige Anteil an Tabellen, JOINs und Spalten in die Abfrage einbezogen wird, der notwendig ist, um die Abfrage zu beantworten. Wenn zum Bsp. von einem Model-Query-Subject“ nur ein einzelnes Query-Item in eine Abfrage einbezogen wird, so wird auch nur für diese Spalte ein entsprechendes SQL-Select generiert. Im gezeigten Beispiel wird für die Role-Playing-Dimension „Datum Antrag“ nur das Query-Item „Ant: Monat Bez. (lang)“ und „Ant: Monat (Nr.)“ in die Abfrage einbezogen. Die Abfrage wird in diesem Fall direkt in Framework-Manager mittels der Funktion „Test“ durchgeführt.

Zusätzlich wurde die Checkbox für „Auto Sum“ aktiviert. Als Ergebnis wird folgendes angezeigt:

Nach Klick auf Registerkarte „Query Information“:

Wie man sieht wurde noch eine weitere Spalte in die Query mitaufgenommen. Dies hat mit der Definition von Determinanten zu tun, die für die unterschiedlichen Ebenen der Zeitdimension definiert wurden. Wichtig ist jedoch die Tatsache, dass sonst keine weiteren Spalten und auch kein JOIN zu einer Faktentabelle mit in das SQL aufgenommen wurde. Man spricht in diesem Fall von einem „Minimized SQL“. Nur die Spalte „BEZ_JAHR_MONAT“ wurde noch zusätzlich aufgenommen, weil sie über die Determinaten Definition als Gruppierungsschlüssel dient.

Für jedes „Data-Query-Subject“ oder „Model-Query-Subject“ gibt es die Möglichkeit unter „Edit Definition“ den SQL-Generierungsmodus einzustellen.

Ein SELECT, das mit der Option „Minimized SQL“ generiert wurde, hat eine höhere Chance durch den Datenbank-Optimizer hinsichtlich Ausführungspfad optimiert zu werden. Die Performance-Optimierung über den Einsatz von Materialized Views ist hiervon betroffen.

„Minimized SQL“ kann in den folgenden Fällen (unter Umständen) nicht generiert werden:

• Wenn Filter, Calculations, Parameterized SQL in den Data-Source-Query-Subjects hinzugefügt wurden
• Wenn das von Framework-Manager (per Default) generierte SQL in den „Data-Source-Query-Subjects“ überschrieben / angepasst wurde
• Wenn ein (abgeleitetes) Model-Query-Subject mind. zwei andere Model-Query-Subjects referenziert, die bereits Releationships besitzen und ferner dieses abgeleitete Model-Query-Subject ebenfalls eine Relationship besitzt bei deren Erzeugung auf die Frage „Re-Create-Underlying Relationship?“ mit „Yes“ geantwortet wurde.
  Bsp. Die Tabellen Order_Detail und Order_Header wurden über einen JOIN zu einem Query-Subject“ namens „Sales_Fact“ zusammengefügt, um Abfragen einfacher und sicherer für die Berichtsersteller zu gestalten.

Manchmal ist es auch notwendig, Query-Pfade anzupassen – vorallem, wenn kein sauber modelliertes Star-Schema zugrundeliegt. In diesem Fall wird im Hintergrund immer der zugrunde liegende JOIN und weitere Spalten im SQL mitgeneriert. Auf die im Beispiel beschriebene Weise wird eine „As View“ SQL-Generierung erzeugt.

Model-Query-Subjects und SQL-Types

Bsp.: Ein Model-Query-Subject ABC referenziert) ein anderes Query-Subjekt XYZ. Wenn XYZ die Einstellung „Minimized SQL“ besitzt, dann übernimmt ABC nicht die Einstellungen von XYZ. Ist Query-Subject XYZ auf „As View“ eingestellt, so wird die SQL Logik von XYZ auf ABC vererbt („As View“).

Minimized SQL“ ist die Default-Einstellung für Model-Query-Subjects.

Ein weiteres Beispiel, um zu verdeutlichen, was Minimized SQL“ bedeutet
(aus der Cognos Dokumentation, daher ausnahmsweise in Englisch)

When you use minimized SQL, the generated SQL contains only the minimal set of tables and joins needed to obtain values for the selected query items.

To see an example of what minimized SQL means, you can use the following Product tables. Four query subjects, Product Line, Product Type, Product, and Product Multilingual all join to each other.

They can be combined in a model query subject.

If you test the Products model query subject as a whole, you see that four tables are referenced in the from clause of the query.

select 
 PRODUCT_LINE.PRODUCT_LINE_CODE as Product_Line_Code,
 PRODUCT_LINE.PRODUCT_LINE_EN as Product_Line,
 PRODUCT_TYPE.PRODUCT_TYPE_CODE as Product_Type_Code,
 PRODUCT_TYPE.PRODUCT_TYPE_EN as Product_Type,
 PRODUCT.PRODUCT_NUMBER as Product_Number,
 PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Name,
 PRODUCT_MULTILINGUAL.DESCRIPTION as Product_Description,
 PRODUCT.INTRODUCTION_DATE as Introduction_Date,
 PRODUCT.PRODUCT_IMAGE as Product_Image,
 PRODUCT.PRODUCTION_COST as Production_Cost,
 PRODUCT.MARGIN as Margin
from
 gosl_82..gosl.PRODUCT_LINE PRODUCT_LINE,
 gosl_82..gosl.PRODUCT_TYPE PRODUCT_TYPE,
 gosl_82..gosl.PRODUCT PRODUCT,
 gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL
where
 (PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN') and 
(PRODUCT_LINE.PRODUCT_LINE_CODE = PRODUCT_TYPE.PRODUCT_LINE_CODE) and
(PRODUCT_TYPE.PRODUCT_TYPE_CODE = PRODUCT.PRODUCT_TYPE_CODE) and
(PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER

If you test only Product name, you see that the resulting query uses only Product Multilingual, which is the table that was required. This is the effect of minimized SQL.

select 
 PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Name 
from 
 gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL 
where 
 (PRODUCT_MULTILINGUAL."LANGUAGE" - N'EN")

Example: When Minimized SQL Is Important

If you are modeling a normalized data source, you may be more concerned about minimized SQL because it will reduce the number of tables used in some requests and perform better. In this case, it would be best to create relationships and determinants between the data source query subjects and then create model query subjects that do not have relationships.

There is a common misconception that if you do not have relationships between objects, you cannot create star schema groups. This is not the case. Select the model query subjects to include in the group and use the Star Schema Grouping wizard. Or you can create shortcuts and move them to a new namespace. There is no need to have shortcuts to the relationships; this feature is purely visual in the diagram. The effect on query generation and presentation in the studios is the same.

Example: When Minimized SQL Is Not as Important as Predictable Queries

There may be some elements in a data source that you need to encapsulate to ensure that they behave as if they were one data object. An example might be a security table that must always be joined to a fact. In the Great Outdoors Sales model, Order Header and Order Details are a set of tables that together represent a fact and you would always want them to be queried together. For an example, see Where Should You Create Relationships and Determinants?