MicroStrategy ONE

Outer Join zwischen der Such- und Fakt-/Ergebnistabelle

Die folgenden VLDB-Eigenschaftseinstellungen für „Alle endgültigen Ergebniselemente beibehalten“ legen fest, wie ein äußerer Join für das Endergebnis sowie für die Nachschlage- und Beziehungstabellen durchgeführt wird:

  • Wenn Sie den Standard auswählen Keinen Outer Join zwischen der Such- und Fakt-/Ergebnistabelle Option generiert die SQL-Engine einen Equi-Join. Daher werden Ihnen nur die Elemente angezeigt, die in beiden Tabellen vorhanden sind.
  • Wenn Sie sich für entscheiden Outer-Join zwischen der Such- und Fakt-/Ergebnistabelle Option generiert die SQL-Engine einen Outer-Join und Ihr Bericht enthält alle Elemente, die im endgültigen Ergebnissatz enthalten sind. Wenn diese Einstellung aktiviert ist, werden äußere Verknüpfungen für alle Verknüpfungen von der Faktentabelle zur Nachschlagetabelle sowie zu allen Beziehungstabellen generiert. Dies liegt daran, dass es schwierig ist, zu unterscheiden, welche Tabelle als Nachschlagetabelle und welche Tabelle als Beziehungstabelle verwendet wird, also die beiden Rollen, die eine Tabelle oft spielt. Beispielsweise dient LOOKUP_DAY sowohl als Nachschlagetabelle für das Tagesattribut als auch als Beziehungstabelle für Tag und Monat.

    Diese Einstellung sollte nicht in Standard-Data Warehouses verwendet werden, in denen die Nachschlagetabellen ordnungsgemäß gepflegt werden und alle Elemente in der Faktentabelle Einträge in der jeweiligen Nachschlagetabelle haben. Es sollte nur verwendet werden, wenn ein bestimmtes Attribut in der Faktentabelle mehr (eindeutige) Attributelemente enthält als die entsprechende Nachschlagetabelle. Im obigen Beispiel enthält die Faktentabelle beispielsweise die Umsätze von fünf verschiedenen Geschäften, die Geschäftstabelle jedoch nur die von vier Geschäften. Dies sollte in einem Standard-Data-Warehouse nicht passieren, da die Nachschlagetabelle per Definition alle Attributelemente enthalten sollte. Dies kann jedoch der Fall sein, wenn die Fakttabellen häufiger aktualisiert werden als die Suchtabellen.

  • Wenn Sie sich für entscheiden Alle Elemente der letzten Anweisung der Ergebnistabelle für die Suchtabelle, jedoch nicht für die Beziehungstabelle beibehalten Option generiert die SQL-Engine bei allen Durchläufen mit Ausnahme des letzten Durchlaufs einen Inner-Join. beim letzten Durchlauf wird ein Outer-Join generiert.
  • Wenn Sie sich für entscheiden Einstellung auf Berichtebene nicht beachten, Elemente des letzten Durchlaufs entsprechend der Einstellung auf Attributebene beibehalten. Wenn diese Option auf Attributebene ausgewählt ist, entspricht das Verhalten der Option zum Beibehalten gemeinsam verwendeter Elemente (d. h. Auswahl 1 ) , wird die Einstellung für diese VLDB-Eigenschaft auf der Attributebene verwendet.

    Diese Einstellung ist hilfreich, wenn Sie nur über wenige Attribute verfügen, die unterschiedliche Join-Typen erfordern. Wenn zum Beispiel von den Attributen in einem Bericht nur eines die Elemente aus der letzten Anweisung der Tabelle beibehalten muss, können Sie die VLDB-Eigenschaft auf festlegen Alle Ergebniselemente des letzten Durchlaufs beibehalten -Einstellung für dieses eine Attribut ändern. Sie können dann den Bericht auf festlegen Nicht zuhören -Einstellung für die VLDB-Eigenschaft. Beim Ausführen des Berichts führt lediglich das anders festgelegte Attribut zu einem äußeren Join in SQL. Alle anderen Attribut-Suchtabellen werden unter Verwendung eines Equal-Joins verbunden, was zu einer besseren SQL-Leistung führt.

Beispiel: Gemeinsam verwendete Elemente aus Ergebnistabelle des letzten Durchlaufs und Such-/Beziehungstabelle beibehalten

Die Vorlage eines Berichts enthält Laden- und Dollarumsätze.

Die Option „Gemeinsame Elemente der endgültigen Ergebnistabelle und der Nachschlagetabelle beibehalten“ gibt unter Verwendung des folgenden SQL die folgenden Ergebnisse zurück.

Speichern Dollar-Verkäufe

Osten

5000

Zentral

8000

Süd

12000

 
Wählen Sie a11.Store_id Store_id,
max(a12.Store) Store,
sum(a11.DollarSls) WJXBFS1
from Fact a11
join Store a12
ein (a11.Store_id = a12.Store_id)
Gruppierung nach a11.Store_id

Beispiel: Alle finalen Durchlaufergebniselemente beibehalten

Die Vorlage eines Berichts enthält Laden- und Dollarumsätze.

Die Option „Alle endgültigen Ergebnispasselemente beibehalten“ gibt unter Verwendung des folgenden SQL die folgenden Ergebnisse zurück. Beachten Sie, dass jetzt die Daten für die Store_IDs 4 und 5 angezeigt werden.

Speichern Dollar-Verkäufe

Osten

5000

Zentral

8000

Süd

12000

 

3000

 

1500

 
Wählen Sie a11.Store_id Store_id,
max(a12.Store) Store,
sum(a11.DollarSls) WJXBFS1
from Fact a11
linker äußerer Join Store a12
ein (a11.Store_id = a12.Store_id)
Gruppierung nach a11.Store_id

Beispiel: Alle Elemente der letzten Anweisung der Ergebnistabelle für die Suchtabelle, jedoch nicht für die Beziehungstabelle beibehalten

Ein Bericht weist in der Vorlage die Angaben „Land“, „Metrik 1“ und „Metrik 2“ auf. Für jede Metrik sind folgende Faktentabellen vorhanden:

CALLCENTER_ID Fakt 1

1

1000

2

2000

1

1000

2

2000

3

1000

4

1000

 

ANGESTELLTEN ID Fakt 2

1

5000

2

6000

1

5000

2

6000

3

5000

4

5000

5

1000

Die SQL Engine führt drei Durchläufe durch. Im ersten Durchgang berechnet die SQL Engine die Metrik 1. Die SQL Engine verknüpft die obige Tabelle „Fact Table (Metric 1)“ innerlich mit der Callcenter-Lookup-Tabelle „LU_CALL_CTR“ unten:

CALLCENTER_ID COUNTRY_ID

1

1

2

1

3

2

um die folgende temporäre Tabelle für Metrik 1, gruppiert nach Land, mit dem folgenden SQL zu erstellen:

COUNTRY_ID Metrik 1

1

6000

2

1000

 
create table ZZSP00 nologging as
select a12.COUNTRY_ID COUNTRY_ID,
 sum((a11.QTY_SOLD * a11.DISCOUNT))
WJXBFS1
from ORDER_DETAIL a11, 
 LU_CALL_CTR a12
where a11.CALL_CTR_ID = a12.CALL_CTR_ID
group by a12.COUNTRY_ID

Im zweiten Durchgang wird Metrik 2 berechnet. Die SQL Engine verknüpft die obige Tabelle „Fact Table (Metric 2)“ innerlich mit der Mitarbeiter-Lookup-Tabelle „LU_EMPLOYEE“ unten:

ANGESTELLTEN ID COUNTRY_ID

1

1

2

2

3

2

So erstellen Sie die folgende temporäre Tabelle für Metrik 2, gruppiert nach Ländern, mit dem folgenden SQL:

COUNTRY_ID Metrik 2

1

10000

2

17000

 
create table ZZSP01 nologging as
wählen Sie a12.COUNTRY_ID COUNTRY_ID,
Summe(a11.FREIGHT) WJXBFS1
aus ORDER_FACT a11,
LU_EMPLOYEE a12
where a11.EMP_ID = a12.EMP_ID
group by a12.COUNTRY_ID

Im dritten Durchgang verwendet die SQL Engine die folgende Länder-Lookup-Tabelle „LU_COUNTRY“:

COUNTRY_ID LAND_DESC

1

USA

3

Europa

Die SQL Engine führt einen linken äußeren Join zwischen der obigen METRIC1_TEMPTABLE und der Tabelle LU_COUNTRY durch. Die SQL-Engine führt dann einen Left Outer Join zwischen der obigen METRIC2_TEMPTABLE und der LU_COUNTRY-Tabelle durch. Abschließend führt die SQL Engine eine innere Verknüpfung der Ergebnisse des dritten Durchgangs durch, um die endgültigen Ergebnisse zu erzeugen.

Die Option „Alle Elemente der Ergebnistabelle des letzten Durchgangs in Bezug auf die Nachschlagetabelle, jedoch nicht auf die Beziehungstabelle beibehalten“ gibt unter Verwendung des folgenden SQL die folgenden Ergebnisse zurück.

COUNTRY_ID LAND_DESC Metrik 1 Metrik 2

1

USA

6000

10000

2

 

1000

17000

 
select pa1.COUNTRY_ID COUNTRY_ID,
a11.COUNTRY_NAME COUNTRY_NAME,
pa1.WJXBFS1 WJXBFS1,
pa2.WJXBFS1 WJXBFS2
von ZZSP00 pa1,
ZZSP01 pa2,
LU_COUNTRY a11
wobei pa1.COUNTRY_ID = pa2.COUNTRY_ID und
pa1.COUNTRY_ID = a11.COUNTRY_ID ( )