Kontakt

Ansicht
Dokumentation

ABENCDS_F1_DEFINE_HIERARCHY - CDS F1 DEFINE HIERARCHY

ABENCDS_F1_DEFINE_HIERARCHY - CDS F1 DEFINE HIERARCHY

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

- DEFINE HIERARCHY

$[@entity_annot1$]
$[@entity_annot2$]
...
$[@hierarchy_annot1$]
$[ @hierarchy_annot2$]
...
$[DEFINE$] HIERARCHY hierarchy
         $[parameter_list$]
         AS PARENT CHILD HIERARCHY(
           SOURCE cds_view
           CHILD TO PARENT ASSOCIATION _hierarchy_assoc
           $[PERIOD FROM field1 TO field2 VALID FROM from TO to$]
           $[DIRECTORY _directory_assoc FILTER BY cds_cond$]
           $[START WHERE cds_cond$]
           SIBLINGS ORDER BY field1 $[ASCENDING$|DESCENDING$]$[,
                             field2 $[ASCENDING$|DESCENDING$], ...$]
           $[DEPTH depth$]
           $[NODETYPE node_type$]
           $[LOAD BULK$|INCREMENTAL$|load_option$]
           $[MULTIPLE PARENTS ${NOT ALLOWED$}$|LEAVES$|ALLOWED$]
           $[ORPHANS IGNORE$|ERROR$|ROOT$]
           $[CYCLES ERROR$|BREAKUP$]
           $[GENERATE SPANTREE$]
           $[CACHE ON$|OFF$|FORCE$])
     { element_list }

Zusätze:

1. ... SOURCE cds_view

2. ... CHILD TO PARENT ASSOCIATION _hierarchy_assoc

3. ... PERIOD FROM field1 TO field2 VALID FROM from TO to

4. ... DIRECTORY _directory_assoc FILTER BY cds_cond

5. ... START WHERE cds_cond

6. ... SIBLINGS ORDER BY field1 $[ASCENDING$|DESCENDING$], ...

7. ... DEPTH depth

8. ... NODETYPE node_type

9. ... LOAD BULK$|INCREMENTAL$|load_option

10. ... MULTIPLE PARENTS ${NOT ALLOWED$}$|${LEAVES ONLY$}$|ALLOWED

11. ... ORPHANS IGNORE$|ERROR$|ROOT

12. ... CYCLES ERROR$|BREAKUP

13. ... GENERATE SPANTREE

14. ... CACHE ON$|OFF$|FORCE

Wirkung

Definiert eine CDS-Entität hierarchy als CDS-Hierarchie in der CDS DDL. Eine CDS-Hierarchie hat eine tabellarische Ergebnismenge, unter deren Zeilen Eltern-Kind-Beziehungen bestehen. Bei einem Zugriff auf eine CDS-Hierarchie als Datenquelle einer Query von wird diese als SQL-Hierarchie behandelt, bei der zusätzliche Hierarchiespalten selektiert werden können.

  • Mit parameter_list wird eine Liste optionaler Eingabeparameter für die CDS-Hierarchie deklariert.
  • Mit element_list werden die Elemente der CDS-Hierarchie deklariert.

Die Zusätze in den Klammern hinter AS PARENT CHILD HIERARCHY definieren, wie die Hierarchie erzeugt werden soll:

  • Hinter SOURCE ist eine CDS-View cds_view als Quelle der Hierarchie anzugeben.
  • Hinter START WHERE kann eine Startbedingung angegeben werden, welche Wurzelknoten für die Wurzelknotenmenge der Hierarchie definiert. Die Hierarchie besteht aus den Wurzelknoten der Wurzelknotenmenge und deren Nachfahrenknoten. Bei der Nichtangabe von START WHERE besteht die Wurzelknotenmenge implizit aus allen Zeilen, in denen die Spalte mit dem Elternknoten (wie durch die Hierarchieassoziation definiert) initial ist.

Die übrigen Zusätze legen weitere Eigenschaften der Hierarchie fest. Die Zeilen der tabellarischen Ergebnismenge der CDS-Hierarchie sind die Hierarchieknoten der erzeugten Hierarchie ohne deren Hierarchiespalten.

Der Name einer CDS-Hierarchie befindet sich im Namensraum aller globalen Typen eines AS ABAP.

Hinweise

  • Anders als in kann in ABAP CDS nicht auf die zusätzlichen Hierarchiespalten einer CDS-Hierarchie zugegriffen werden. Statt dessen müssen die zugehörigen Hierarchieattribute falls gewünscht in der Elementliste der CDS-Hierarchie aufgelistet werden.
  • Auf einer SAP-HANA-Datenbank beruht die Erzeugung der Ergebnismengen von CDS-Hierarchien und des Hierarchiegenerators HIERARCHY auf der Verwendung der dortigen Hierarchie-Generator-Funktionen HIERARCHY und ähnlichen. Für mehr Informationen siehe die HANA-SQL-Dokumentation.
  • Da aus der START WHERE-Bedingung generierte Hierarchien auf der Datenbank gepuffert werden, sollen fest Werte, die selten geändert werden, für die Wurzelknoten von großen Datenhierarchien verwendet werden. Mit den Hierarchienavigatoren im ABAP SQL können dann Unterknoten solcher Hierarchien ausgewertet werden. Insbesondere die Angabe der Wurzelknoten durch beliebige Parameter sollte auf kleine Hierarchien oder Demonstrationen eingeschränkt werden.

Beispiel

Definition einer einfachen CDS-Hierarchie. Das Programm DEMO_HIERARCHY_TREE greift auf die CDS-Hierarchie zu und vergleicht diesen Zugriff mit anderen Zugriffen auf gleichartige Hierarchien in .

Zusatz 1

... SOURCE cds_view

Wirkung

Der obligatorische Zusatz SOURCE gibt eine oder als Hierarchiequelle der CDS-Hierarchie an. Die Quelle muss die hinter CHILD TO PARENT ASSOCIATION angegebene Hierarchieassoziation in ihrer SELECT-Liste exponieren.

Hinweis

Derzeit sind CDS-View-Entitäten und DDIC-basierte CDS-Views die einzigen CDS-Entitäten, die als Quelle einer CDS-Hierarchie angegeben werden können. Insbesondere kann eine CDS-Hierarchie nicht Quelle einer CDS-Hierarchie sein.

Beispiel

Die CDS-Hierarchie des vorhergehenden Beispiels verwendet folgende CDS-View als Quelle:

Zusatz 2

... CHILD TO PARENT ASSOCIATION _hierarchy_assoc

Wirkung

Der obligatorische Zusatz CHILD TO PARENT ASSOCIATION gibt die Hierarchieassoziation an, über deren ON-Bedingung die Nachfahrenknoten der Wurzelknotenmenge selektiert werden. Die Hierarchieassoziation muss von der hinter SOURCE angegebenen CDS-View exponiert werden.

Die Hierarchieassoziation definiert die Eltern-Kind-Beziehung zwischen den Hierarchieknoten. Dafür gelten folgende Voraussetzungen:

  • In der ON-Bedingung der CDS-Assoziation dürfen nur mit AND kombinierte Vergleiche auf Gleichheit mit dem Operator = vorkommen.
  • In jedem Vergleich der ON-Bedingung muss ein Feld der Assoziationsquelle mit einem über den Präfix _hierachy_assoc gekennzeichneten Feld des Assoziationsziels verglichen werden.
  • Die Assoziationsquelle der Assoziation darf keine Felder enthalten, die den gleichen Namen wie ein Hierarchieattribut haben. Für ein solches Feld muss ein alternativer Elementname definiert werden.

Jede Zeile der Ergebnismenge der Quelle hierarchy_source, welche die ON-Bedingung für einen bereits vorhandenen Hierarchieknoten erfüllt, wird falls möglich rekursiv als dessen Kindknoten in die Hierarchie aufgenommen.

Hinweis

Die optionalen Zusätze definieren weitere Bedingungen, ob eine Zeile als Hierarchieknoten aufgenommen werden kann oder nicht.

Beispiel

Die CDS-View des vorhergehenden Beispiels exponiert ihre Assoziation _tree. Diese CDS-Assoziation erfüllt alle Anforderungen an eine Hierarchieassoziation und kann als solche verwendet werden.

Zusatz 3

... PERIOD FROM field1 TO field2 VALID FROM from TO to

Wirkung

Der optionale Zusatz PERIOD definiert die Hierarchie als temporale SQL-Hierarchie in der die Hierarchieknoten durch einen Abgleich von Zeitintervallen limitiert werden.

  • Mit field1 und field2 werden die Felder der Quelle cds_view angegeben, welche die Unter- und Obergrenzen einer Periode in den Hierarchiedaten definieren. field1 und field2 müssen unterschiedliche Felder mit gleichem Datentyp sein. Dies kann sein:
  • Der eingebaute Typ DATS des ABAP Dictionary.

  • Mit from und to wird die Unter- und Obergrenze eines Zeitintervalls definiert, das als Bedingung für die Perioden der Wurzelknotenmenge wirkt. Der Datentyp von from und to muss dem von field1 und field2 entsprechen. Gepflegt werden können z.B.:

Eine temporale SQL-Hierarchie wird wie folgt erzeugt:

  • Es werden nur Wurzelknoten der Wurzelknotenmenge berücksichtigt, in denen die über field1 und field2 definierte Periode eine nicht leere Schnittmenge mit dem durch from und to definierten Zeitintervall hat. Diese Schnittmenge bildet das Gültigkeitsintervall der Wurzelknoten.
  • Es werden nur Kindknoten erzeugt, in denen die über field1 und field2 definierte Periode eine nicht leere Schnittmenge mit dem Gültigkeitsintervall des Elternknotens hat. Diese Schnittmenge bildet das Gültigkeitsintervall des Kindknotens.

Für temporale SQL-Hierarchien gibt es zusätzliche Hierarchieattribute VALID_FROM und VALID_UNTIL, welche die Intervallgrenzen des Gültigkeitsintervalls jedes Hierarchieknotens enthalten.

Der Zusatz PERIOD darf nicht zusammen mit GENERATE SPANTREE verwendet werden.

Hinweise

  • Das Gültigkeitsintervall eines Nachfahrenknotens ist immer Teilmenge der Gültigkeitsintervalle aller Vorfahrenknoten. Gültigkeitsintervalle können von Hierarchieebene zu Hierarchieebene nur gleich bleiben oder schmaler werden, aber sich nie verbreitern.
  • Damit ein Nachfahrenknoten zu einer temporalen SQL-Hierarchie gehört, genügt es nicht, dass sich seine Periode mit dem über from und to definierten Zeitintervall überschneidet. Ausschlaggebend ist allein das Gültigkeitsintervall des Elternknotens. Ein Pfad einer normalen Hierarchie wird in einer temporalen SQL-Hierarchie an der Stelle abgeschnitten, an der es keine Schnittmenge zwischen der Periode und dem vorangehenden Gültigkeitsintervall gibt.
  • Der Wert von to kann auch kleiner als der Wert von from sein. Es wird gegebenenfalls dennoch ein Gültigkeitsintervall gebildet. Wenn der Wert der unteren Intervallgrenze der Periode dagegen größer als der Wert der oberen Intervallgrenze ist, ist das Gültigkeitsintervall leer.
  • Zusätze wie MULTIPLE PARENTS oder CYCLES wirken auf die temporale SQL-Hierarchie. Knoten, die in einer normalen Hierarchie zu Ausnahmen führen würden, können in einer temporalen SQL-Hierarchie ausgeblendet sein.
  • Für die Erzeugung einer temporalen SQL-Hierarchie wird auf einer SAP-HANA-Datenbank die dortige Hierarchie-Generator-Funktion HIERARCHY_TEMPORAL aufgerufen.

Beispiel

Die folgenden CDS-Hierarchien erzeugen zwei temporale SQL-Hierarchien, wobei einmal Datums- und einmal Zeitstempelfelder als Perioden verwendet werden. Das Programm DEMO_HIERARCHY_TEMPORAL greift auf die CDS-Hierarchien zu und vergleicht die Ergebnisse mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes PERIOD.

Zusatz 4

... DIRECTORY _directory_assoc FILTER BY cds_cond

Wirkung

Der optionale Zusatz DIRECTORY definiert eine Filterbedingung cds_cond für die Zeilen der hinter SOURCE angegebenen Quelle der Hierarchie. Die Hierarchie wird nur aus den Zeilen der Quelle generiert, welche die Filterbedingung erfüllen. Für cds_cond können wie folgt mit AND verknüpfte Vergleiche auf Gleichheit mit dem Operator = angegeben werden:

  • Der Operator auf der linken Seite eines Vergleichs muss ein Element der aktuellen Hierarchie sein, dessen Name in der hinter SOURCE angegebenen CDS-View wie folgt als Operand vorkommt:
  • Auf der linken Seite einer ON-Bedingung einer CDS-Assoziation _directory_assoc.

  • Auf der linken Seite einer ON-Bedingung der Hierarchieassoziation _hierarchy_assoc.

  • Der Operator auf der rechten Seite des Vergleichs kann ein typisiertes Literal oder ein vom Typ her passender Parameter aus der Parameterliste der Hierarchie sein.

Es gelten die gleichen Regeln für die vergleichbaren Typen wie für CDS-Views.

Hinweise

  • Die Filterbedingung entfernt alle Hierarchieknoten und deren Nachfahrenknoten aus der Ergebnismenge, die nicht der Bedingung cds_cond genügen.
  • Der Inhalt des Assoziationsziels der CDS-Assoziation _directory_assoc spielt für die Auswertung der Filterbedingung keine Rolle.
  • Die Einschränkung der Operanden auf der linken Seite eines Vergleichs auf die Operanden einer CDS-Assoziation der Quelle unterstützt bestimmte Programmiermodelle. Frameworks, welche auf den Modellen beruhen, lesen Daten aus dem Assoziationsziel dieser CDS-Assoziation und übergeben sie an Eingabeparameter der Hierarchie, welche sie in der Filterbedingung auswertet.

Beispiel

Die folgende CDS-View veröffentlicht eine Selbstassoziation _pcr, die eine Eltern-Kind-Beziehung definiert, und eine CDS-Assoziation _dir zu einer DDIC-Datenbanktabelle DEMO_HIERA_DIR:

Die folgende CDS-Hierarchie verwendet den Operand dir_entry aus der linken Seite der ON-Bedingung aus der CDS-View in der Filterbedingung hinter DIRECTORY _dir FILTER BY:

Ein Ausführen des Programms DEMO_HIERARCHY_PARENTCHILD_DIR erlaubt die Übergabe verschiedener Parameter und zeigt die Wirkung der Filterbedingung.

Zusatz 5

... START WHERE cds_cond

Wirkung

Der optionale Zusatz START WHERE gibt die Startbedingung für die Erzeugung der Hierarchie an. Hinter START WHERE kann ein logischer Ausdruck cds_cond angegeben werden, welcher Zeilen der Quelle cds_view selektiert. Für cds_cond können die gleichen Operatoren wie in einer WHERE-Klausel einer CDS-View angegeben werden und es gelten die gleichen Regeln. Die Operanden der linken Seite können Elemente der hinter SOURCE angegebenen CDS-View sein. Die Operanden der rechten Seite können Literale, Parameter aus der Parameterliste der Hierarchie und Sitzungsvariablen sein. Für die Angabe von Literalen, Parametern und Sitzungsvariablen gilt das gleiche wie bei der Definition von CDS-Views.

Bei der expliziten Nichtangabe des Zusatzes START WHERE wird er über eine Bedingung implizit hinzugefügt, die alle Zeilen mit einer initialen Elternknotenspalte (wie in der Hierarchieassoziation definiert) selektiert.

Die selektierten Zeilen werden als Wurzelknotenmenge in die Hierarchie eingefügt. Für jeden Wurzelknoten der Wurzelknotenmenge werden dann die Nachfahrenknoten selektiert, welche die ON-Bedingung der Hierarchieassoziation erfüllen, und falls möglich ebenfalls in die Hierarchie eingefügt.

Hinweise

  • Es wird empfohlen, die Startbedingung immer explizit anzugeben, um die Lesbarkeit der Definition zu erhöhen. Weiterhin ist die durch die implizite Startbedingung definierte Wurzelknotenmenge nicht immer geeignet und kann auch nicht durch Parameter beeinflusst werden.
  • Die Startbedingung sollte eine sinnvolle Wurzelknotenmenge selektieren. Wenn keine Zeile der Ergebnismenge der Quelle cds_view die Bedingung erfüllt ist die Hierarchie leer, wenn alle Zeilen sie erfüllen, werden die Nachfahrenknoten jeder Zeile selektiert und eingefügt.

Beispiel

Die folgende CDS-Hierarchie verwendet eine Intervallabgrenzung mit BETWEEN als Startbedingung. Das Programm DEMO_HIERARCHY_START_WHERE greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Beispiel

Folgende CDS-Hierarchie hat keine START WHERE-Bedingung:

Sie wird wie folgende CDS-Hierarchie implizit behandelt:

Es wird eine implizite START WHERE-Bedingung hinzugefügt, die von der Elternspalte abhängt, die wiederum von der Hiearchieassoziation abhängig ist. Mit dem Programm DEMO_CDS_HIERA_START_WHERE wird gezeigt, dass beide CDS-Hierarchien die gleichen Daten selektieren.

Zusatz 6

... SIBLINGS ORDER BY field1 $[ASCENDING$|DESCENDING$],  ...

Wirkung

Der obligatorische Zusatz SIBLINGS ORDER BY sortiert Geschwisterknoten in der Hierarchie. Hinter dem Zusatz SIBLINGS ORDER BY können in einer kommaseparierten Liste Felder field1, field2, ... der Quelle cds_view angegeben werden, nach denen die Geschwisterknoten sortiert werden sollen.

Zu jedem Feld kann der Zusatz ASCENDING für aufsteigende oder DESCENDING für absteigende Sortierung angegeben werden, wobei standardmäßig aufsteigend sortiert wird.

Die hinter SIBLINGS ORDER BY angegebenen Felder dürfen nicht vom Typ LCHR, LRAW, STRING, RAWSTRING oder GEOM_EWKB sein.

Hinweis

Der Zusatz SIBLINGS ORDER BY ist bei einer CDS-Hierarchie obligatorisch, da diese Sortierung nicht mehr nachträglich durchgeführt werden kann. Beispielsweise kann das Ergebnis eines Hierarchienavigators in von der Sortierung der als Quelle angegebenen Hierarchie abhängen. Während ein als Quelle angegebener Hierarchiegenerator direkt dort sortiert werden kann, ist dies bei vordefinierten CDS-Hierarchien nicht mehr möglich.

Beispiel

Die folgende CDS-Hierarchie sortiert Geschwister absteigend nach dem Feld id. Das Programm DEMO_HIERARCHY_SIBLINGS_ORDER greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 7

... DEPTH depth

Wirkung

Der optionale Zusatz depth begrenzt die Anzahl der Hierarchieebenen, über die Nachfahrenknoten erzeugt werden. Für depth kann ein typisiertes Literal oder ein Parameter aus der Parameterliste der Hierarchie angegeben werden, der einen Integer-Typ hat.

Der Wert in depth hat folgende Bedeutung:

  • Für Werte von depth größer 0 werden ausgehend von einem Wurzelknoten so viele Hierarchiekanten verfolgt, wie in depth angegeben sind.
  • Für Werte von depth gleich 0 werden nur die Wurzelknoten in die Hierarchie eingefügt.

Der Zusatz DEPTH kann nur dann verwendet werden, wenn der Zusatz ORPHANS nicht oder als ORPHANS IGNORE angegeben ist.

Beispiel

Die folgende CDS-Hierarchie begrenzt die Hierarchieebenen über einen Eingabeparameter p_depth. Das Programm DEMO_HIERARCHY_DEPTH greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 8

... NODETYPE node_type

Wirkung

Mit dem optionalen Zusatz NODETYPE wird eine Element der CDS-Hierarchie identifiziert, das den Typ des Hierarchieknotens ermittelt kann. Die Werte dieses Elements müssen Elementnamen sein, die auch in der Elementliste der CDS-Hierarchie enthalten sind. Über die Fremdschlüssel- oder Textassoziation, die dem jeweiligen Element über eigene Annotationen zugeordnet ist, können die Attribute und der Text für den jeweiligen Hierarchieknoten ermittelt werden. Das mit NODETYPE angegebene Element node_type wird in den Metadaten der CDS-Hierarchie abgelegt und kann von Consumern über die Methode GET_NODETYPE_FIELD des Interfaces IF_DD_CDS_READ_API_HIER_C2P ausgelesen werden.

Hinweis

Ein aktuelles Framework, mit dem NODETYPE analysiert werde kann, ist die ABAP Analytical Engine.

Beispiel

In der folgenden baumartigen CDS-Hierarchie wird das Element name als Knotentyp festgelegt. Wenn ein Hierarchieknoten im Element name den Wert Apple hat, soll er ein Blattknoten ohne Nachfahrenknoten sein.

Das Programm DEMO_HIERARCHY_TREE_NODETYPE greift auf die CDS-Hierarchie zu und ein Ausführen gibt die Hierarchieknoten aus, die gegen die Regel verstoßen. Hierzu wird der Knotentyp der CDS-Hierarchie vom folgenden Quelltext ausgewertet:

Beispiel

In der folgenden baumartigen CDS-Hierarchie wird das Element NodeType als Knotentyp festgelegt. Bei der Auswahl von Daten aus der CDS-Hierarchie für eine mit der ABAP Analytical Engine verwendbare View kann das Element NodeType zwei unterschiedliche Werte zurückgeben. Der eine ist CostCenter und der andere ist HierarchyNode. Falls NodeType = CostCenter, müssen die Elemente ControllingArea und CostCenter gefüllt werden und es kann über die Fremdschlüsselassoziation _CostCenter der Text und zusätzliche Attribute abgeleitet werden. Falls NodeType = HierarchyNode, wird über die Textassoziation _Text der Text für diesen Knoten abgerufen.

define hierarchy DEMO_COSTCENTERHIER
  with parameters
    p_controllingArea : fis_kokrs,
    P_hierarchy : fis_hryid_cctr
  as parent child hierarchy(
    source
      DEMO_COSTCENTERHIERARCHYNODE
    child to parent association
      _parent
    directory
      _Hierarchy
        filter by
          ControllingArea        = $parameters.p_controllingArea
         and CostCenterHierarchy = $parameters.P_hierarchy
    start where
      ParentNode is initial
    siblings order by
      HierarchyNodeSequence
    nodetype
      NodeType
  )
{
      @ObjectModel.foreignKey.association: '_ControllingArea'
      ControllingArea,
      CostCenterHierarchy,
      @ObjectModel.text.association: '_Text'
      HierarchyNode,
      ParentNode,
      @ObjectModel.foreignKey.association: '_CostCenter'
      CostCenter,
      HierarchyNodeSequence,
      NodeType,

      _Text,
      _CostCenter,
      _Hierarchy,
      _ControllingArea
}

Zusatz 9

... LOAD BULK$|INCREMENTAL$|load_option

Wirkung

Der Zusatz LOAD gibt die Load-Richtlinie für die generierte Hierarchie an. Er kann für die Performance-Optimierung verwendet werden.

Der Zusatz bewirkt folgendes:

  • BULK
Dies ist die Standardeinstellung. Die vollständige Quelltabelle der Hierarchie wird geladen.
  • INCREMENTAL
Nur die Zeilen der Quelltabelle, die von den Startknoten (Wurzelknotenmenge) erreicht werden können, werden geladen.
  • load_option
Für load_option kann mit der Syntax $parameters.pname ein Parameter aus der Parameterliste der Hierarchie angegeben werden. Der Parameter muss den Datentyp CHAR oder SSTRING und mindestens die Länge 11 haben. Der Parameter hat die gültigen Werte "BULK" oder "INCREMENTAL“ in Großbuchstaben, die die gleiche Wirkung wie die jeweiligen Schlüsselwörter haben. Ungültige Werte führen zu einer Ausnahme von der Datenbank.

Hinweise

  • Die Performance-Optimierung mit LOAD INCREMENTAL ist abhängig von der Datenquelle. Wenn die Quelltabelle sehr groß ist und die Hierarchie vergleichsweise wenig Zeilen liest, wirkt es sich günstig auf die Performance aus. Wenn die Quelltabelle dagegen nur wenige Zeilen hat und sie alle Teil der Hierarchie sind, kann LOAD INCREMENTAL sogar mehr Zeit in Anspruch nehmen als LOAD BULK.
  • LOAD INCREMENTAL darf nicht mit globalen temporären Tabellen als Datenquelle verwendet werden, weil es sich nicht günstig auf die Performance auswirkt, sondern diese verlangsamt.
  • Die gültigen Werte für load_option sind die Namen von Aufzählungskonstanten mit dem Aufzählungstyp LOAD_OPTION aus der Klasse SQL_HIERARCHY. Beim Zugriff auf eine CDS-Hierarchie mit einem Parameter für load_option in ABAP SQL kann die Zeichendarstellung dieser Aufzählungskonstanten übergeben werden.

Beispiel

Folgende CDS-Hierarchie verwendet den Zusatz LOAD mit einem Parameter p_load:

Folgende SELECT-Anweisung wird dem Programm DEMO_CDS_HIERA_BULK_INCREMENT entnommen:

Durch die Konvertierung der Aufzählungskonstante sql_hierarchy=>c_load_option-incremental in eine Zeichenkette wird der Wert "INCREMENTAL" an den Parameter p_load übergeben. Das Programm funktioniert wie im ausführbaren Beispiel für den Hierarchiegenerator von ABAP SQL beschrieben.

Zusatz 10

... MULTIPLE PARENTS ${NOT ALLOWED$}$|${LEAVES ONLY$}$|ALLOWED

Wirkung

Der optionale Zusatz MULTIPLE PARENTS legt fest, ob die Hierarchie Kindknoten mit mehreren Elternknoten haben darf oder nicht:

  • NOT ALLOWED
Standardeinstellung, ein Kindknoten darf nur genau einen Elternknoten haben.
  • LEAVES ONLY
Nur Blattknoten dürfen mehrere Elternknoten haben.
  • ALLOWED
Alle Hierarchieknoten dürfen mehrere Elternknoten haben.

Beispiel

Die folgende CDS-Hierarchie erlaubt mehrere Elternknoten für Blattknoten. Das Programm DEMO_HIERARCHY_MULTI_PARENTS greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 11

... ORPHANS IGNORE$|ERROR$|ROOT

Wirkung

Der optionale Zusatz ORPHANS definiert die Behandlung von Waisenknoten. Es gibt folgende Arten von Waisenkindern:

  • Hierarchieknoten, denen gemäß der Eltern-Kind-Beziehung zwar Elternknoten zugeordnet werden könnten, die Elternknoten aber nicht in der Hierarchie enthalten sind (echte Waisen).
  • Hierarchieknoten, die nicht über Hierarchiekanten von der Wurzelknotenmenge aus erreichbar sind.
  • Hierarchieknoten, die zu einem Knotenzyklus gehören und nicht über Hierarchiekanten von der Wurzelknotenmenge aus erreichbar sind (Waiseninseln).

Die Zusätze bewirken Folgendes:

  • IGNORE
Standardeinstellung, Waisenknoten werden nicht in die Hierarchie eingefügt.
  • ERROR
Wenn Waisenknoten erkannt werden, kommt es zu einer Ausnahme.
  • ROOT
Waisenknoten werden wie folgt in die Hierarchie eingefügt:
  • Echte Waisen werden als Wurzelknoten in die Wurzelknotenmenge aufgenommen und im Hierarchieattribut HIERARCHY_IS_ORPHAN als Waisenknoten gekennzeichnet.

  • Nachfahrenknoten von echten Waisen werden wie solche von normalen Elternknoten aus der Wurzelknotenmenge behandelt, sind aber ebenfalls im Hierarchieattribut HIERARCHY_IS_ORPHAN als Waisenknoten gekennzeichnet.

  • Für die Hierarchieknoten einer Waiseninsel wird ein Elternknoten in der Wurzelknotenmenge für den Kindknoten generiert, bei dem der Zyklus auftritt. In dem generierten Wurzelknoten enthalten alle Spalten der Quelle hierarchy_source den Null-Wert. In den Hierarchieattributen ist der zusätzliche Wurzelknoten als Waisenknoten gekennzeichnet und PARENT_ID enthält ebenfalls den Null-Wert.

Beispiel

Die folgende CDS-Hierarchie verwandelt Waisenknoten in Wurzelknoten. Das Programm DEMO_HIERARCHY_ORPHANS greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 12

... CYCLES ERROR$|BREAKUP

Wirkung

Der Zusatz CYCLES legt die Behandlung von Knotenzyklen fest. Die Zusätze bewirken folgendes:

  • FEHLER
Standardeinstellung, wenn ein Knotenzyklus erkannt wird, kommt es zu einer Ausnahme.
  • BREAKUP
Die Verfolgung von Nachfahrenknoten wird bei dem Kindknoten, bei dem ein Knotenzyklus auftritt, abgebrochen und das Hierarchieattribut HIERARCHY_IS_CYCLE auf den Wert 1 gesetzt.

Wenn der Zusatz BREAKUP angegeben ist, dann muss auch MULTIPLE PARENTS ALLOWED angegeben sein.

Beispiel

Die folgende CDS-Hierarchie bricht Knotenzyklen mit CYCLES BREAKUP ab. Das Programm DEMO_HIERARCHY_CYCLES greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 13

... GENERATE SPANTREE

Wirkung

Der Zusatz GENERATE SPANTREE bewirkt, dass ausgehend von jedem Wurzelknoten nur Kindknoten in die Hierarchie eingefügt werden, die nicht mehrere Elternknoten haben. Wenn ein Kindknoten auf Grund der Eltern-Kind-Beziehungen hinter seinem Wurzelknoten mehrere Elternknoten hätte, wird von den möglichen Pfaden von dem Wurzelknoten zu diesem Kindknoten genau einer ausgewählt und nur für diesen wird der Kindknoten erzeugt.

  • Bei verschieden langen Pfaden ist es der kürzeste.
  • Bei gleich langen Pfaden ist es der erste gefundene.

Wenn der Zusatz GENERATE SPANTREE angegeben ist, dürfen die Zusätze MULTIPLE PARENTS, ORPHANS und CYCLES nicht angegeben werden und es gelten teilweise andere Standardwerte:

  • MULTIPLE PARENTS wird implizit mit ALLOWED verwendet.
  • CYCLES wird implizit mit BREAKUP verwendet.

Hinweise

  • Wenn die Eltern-Kind-Beziehungen für die aktuellen Daten ohnehin nur baumartige Hierarchien ergeben, hat der Zusatz GENERATE SPANTREE keine Wirkung.
  • Die Auswahl eines von mehreren Pfaden zu einem Kindknoten bedeutet nicht, dass die anderen Pfade vollständig verworfen werden. Es fehlen nur die zu dem Kindknoten führenden Kanten.
  • Der Zusatz GENERATE SPANTREE kann verwendet werden, um festzustellen, ob es mindestens einen Pfad von einem Wurzelknoten zu einem Kindknoten gibt, ohne dass die Ergebnismenge sämtliche Pfade enthalten muss.
  • Mit dem Zusatz GENERATE SPANTREE wird auf einer SAP-HANA-Datenbank die dortige Hierarchie-Generator-Funktion HIERARCHY_SPANTREE aufgerufen.

Beispiel

Die folgende CDS-Hierarchie verwendet den Zusatz GENERATE SPANTREE. Das Programm DEMO_HIERARCHY_SPANTREE greift auf die CDS-Hierarchie zu und vergleicht das Ergebnis mit einer entsprechenden Verwendung des Hierarchiegenerators HIERARCHY in . Ein Ausführen des Programms zeigt die Wirkung des Zusatzes.

Zusatz 14

... CACHE ON$|OFF$|FORCE

Wirkung

Der optionale Zusatz CACHE definiert die Caching-Richtlinie für das generierte Hierarchieergebnis. Er kann für die Performance-Optimierung verwendet werden. Der Zusatz bewirkt folgendes:

  • ON
Falls die Quelle als zuverlässig deterministisch festgestellt werden kann, wird die generierte Hierarchie durch die Datenbank zwischengespeichert. Dies ist das Standardverhalten.
  • OFF
Die generierte Hierarchie wird durch die Datenbank nicht zwischengespeichert.
  • FORCE
Auch wenn die Quelle nicht als zuverlässig deterministisch festgestellt werden kann, wird die generierte Hierarchie durch die Datenbank zwischengespeichert.






General Material Data   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 69346 Date: 20240523 Time: 173655     sap01-206 ( 727 ms )