Schnelleinstieg in SQLScript für SAP HANA

1.5.2 Relationale Modelle

Bei Verwendung von SAP-Lösungen sind auf der Datenbank im DBMS normalerweise bereits viele von der SAP ausgelieferte Tabellen (Kunde, Material, Bestellungen etc.) vorhanden, die das betriebswirtschaftliche Modell einer Firma abbilden. Die verschiedenen Tabellen stehen über das relationale Datenmodell in Verbindung. In der Regel beinhalten sie nur Schlüsselwerte und keine Texte.

Abbildung 1.4 zeigt am Beispiel eines SAP-Kundenstamms (Tabelle KNA1), wie ein Kunde mit dem Vertriebsbeleg sowie den Auftragsstammdaten von Ländern und Branchen verknüpft ist. Diese relationale Darstellung werden Sie in ähnlicher Weise für die folgenden Aufgaben nutzen.

Abbildung 1.4: Relationales Datenmodell am Beispiel SAP-Kundenstamm (Tabelle KNA1)

Für die ersten Beispiele werden Sie zunächst eigene Tabellen anlegen (DDL), mit Daten füllen (DML) und diese in Relation zueinander abfragen (DQL), sofern Ihre Berechtigungen (DCL) dies zulassen. Die von Ihnen angelegten Tabellen werden Sie im Verlauf dieses Buches begleiten und dienen dazu, die SQLScript-Beispiele auszuführen.

1.6 SQL-Objekttypen

Innerhalb der vom DBMS verwalteten Datenbank gibt es verschiedene Objekttypen, die ich im Detail in den Abschnitten 1.10 bis 1.12 ansprechen und in Übungen und Beispielen nutzen werde. An dieser Stelle gebe ich Ihnen vorab schon einmal eine kurze Definition der wichtigsten Objekttypen:

 Tabellen (zeilen- oder spaltenbasiert) = physikalischer Datenbestand

 Views = Sicht auf eine oder mehrere Tabellen

 Indizes = Performanceoptimierung für Tabellenzugriffe

 Funktionen = Einfache Funktionalität als globales Objekt (z.B. »Multipliziere A * B und gib den Wert zurück«)

 Prozeduren = Komplexe Prozeduren (»Stored Procedures«), um vielschichtige Aufgaben zu lösen (beispielsweise die Übergabe von Kundennummer und Analyse einer Tabelle, um bestimmte Fragestellungen zu beantworten)

 Trigger = Start/Ausführung einer Aktion nach bestimmten Events der Datenbank

SQLScript-Operatoren

In der Sprache SQLScript werden Operatoren dazu genutzt, Werte zu berechnen oder zu vergleichen.

 Arithmetische Operatoren berechnen ein Ergebnis aus den Operanden, wie z.B. C = A + B:Addition (+)Subtraktion (−)Multiplikation (*)Division (/)

 Vergleichsoperatoren vergleichen zwei oder mehr Werte, wie z.B. IF (A > 100), und liefern ein Boolean-Ergebnis (TRUE, FALSE bzw. UNKNOWN). Der Rückgabewert UNKNOWN wird von der DB geliefert, sofern ein Wert der Operanden NULL als Ergebnis liefert oder ist:Gleich (=)Ungleich (!= oder <>)Größer (>)Kleiner (<)Kleiner gleich (<=)Größer gleich (>=)

 Vergleichsoperator der DB-Tabelleninhalte: eine Abfrage, ob eine Spalte/Zeile einer Tabelle einen Wert hat, wie z.B. Select * from A Where "Spalte" IS NULL:Spalte/Zeile hat keinerlei Wert (IS NULL)Spalte/Zeile hat irgendeinen Wert (IS NOT NULL)

Ausnahmen bei Vergleichsoperatoren bei NULL-Werten

Dieser Operator ist besonders, da nicht mit (Spalte = NULL) oder ("Spalte" != NULL) gearbeitet werden kann!

 Logische Operatoren verknüpfen ein oder mehrere Vergleiche oder Selektionen, wie z.B. IF(A > 100) AND (B < 5):Und-Verknüpfung (AND)Oder-Verknüpfung (OR)Nicht-Verknüpfung (NOT)

 Set-Operatoren verknüpfen Statements der Datenbank SQLScript, wie z.B. Select * from A UNION Select * from B:Verknüpfung von zwei oder mehr Statements OHNE Duplikate im Ergebnis (UNION)Verknüpfung von zwei oder mehr Statements INKLUSIVE aller Duplikate im Ergebnis (UNION_ALL)Verknüpfung von zwei Statements, aber Entfernung der Ergebnisse der zweiten Query aus dem Ergebnis der ersten Query (EXCEPT)Verknüpfung von zwei Statements und Schnittmenge der beiden Ergebnisse (INTERSECT)

1.7 HANA-Schema

Als HANA-Schema werden Bereiche benannt, in denen Tabellen erstellt werden und die je nach Schemaname gesonderte Zugriffsberechtigungen erhalten können.

Die HANA-Datenbank legt Daten in verschiedenen, voneinander getrennten Schemas ab, die in Abbildung 1.5 dargestellt sind. Schemas können dazu dienen, Daten physisch und berechtigungstechnisch voneinander zu trennen, obwohl diese gemeinsam in einer zentralen DB abgelegt werden.

Abbildung 1.5: Darstellung eines HANA-DB-Schemas

Einige dieser Schemas sind durch die SAP vorgegeben und dienen der internen Verwaltung der DB. Wie in Abbildung 1.5 ersichtlich, erkennt man die SAP-generierten Schemas meist am Präfix »_SCHEMA_NAME«, z.B. »_SYS_TASK«. Je nach Berechtigung können Sie auch eigene Schemas anlegen.

Sobald Sie über einen Zugang oder Benutzer auf der HANA DB verfügen, erstellt Ihnen das HANA-System automatisch ein eigenes User-Schema, welches (Default) für Sie sicht- und nutzbar ist. Der Name Ihres User-Schemas ist durch Ihren Benutzernamen festgelegt, daher kann er nicht verändert werden.

Die Zugriffsberechtigung jedes Schemas lässt sich individuell generieren, wodurch die Tabellen verschiedener Schemas nur für Anwender mit der entsprechenden Berechtigung nutzbar sind.

Erstellen eigener Kunden-Schemas

Ich empfehle unbedingt, für alle kundenspezifischen Programmierungen und Anlagen von DB-Objekten ein eigenes Schema anzulegen.

Dies dient dazu, alle Objekte in Ihrem »Kundenbereich« zu klammern und die passenden Zugriffsberechtigungen zu erteilen. Ebenso vereinfacht ein eigenes Schema das »Debugging« im Fehlerfall.

1.8 HANA-Unload-Priorität

HANA ist bekannt dafür, über die In-Memory-Funktionalität maximale Performance zu gewährleisten. Das ist aber nicht unbedingt in allen Fällen notwendig.

Hierzu ein Beispiel: Stellen Sie sich vor, einige Ihrer Tabellen beinhalten Daten, die Sie nur sporadisch benötigen, z.B. Daten von den Jahren 1990 bis 2000. Warum sollten diese Daten höchst performant im »heißen« Speicher und nicht im »kalten« Bereich, d.h. auf der Festplatte, abgelegt sein?

Für die Verwaltung von Daten im heißen Speicher benutzt HANA die sogenannte Unload Priority. Sie bestimmt, wann nicht mehr benötigte Daten aus dem Speicher entfernt und/oder wieder eingefügt werden.

Abbildung 1.6: Unload Priority von heißen und kalten Daten

Es stehen die Werte aus Tabelle 1.1 zur Verfügung:

Tabelle 1.1: Status von Unload-Prioritäten

Weitere Hinweise zu Loads und Unloads finden Sie im SAP Knowledge Base Article (KBA): 2127458 – FAQ: SAP HANA Loads and Unloads.

Sie werden diese Funktionalität auch bei der SQL-Definition Ihrer Salesdaten verwenden (siehe Abschnitt 1.12.2).

1.9 HANA Delta Merge

Aus Leistungsgründen werden Daten, z.B. neue Kunden- oder Salesdaten, innerhalb der HANA DB nicht sofort in der Haupttabelle aktualisiert, sondern erst in deren Deltaspeicher schreiboptimiert abgelegt.

Nach definierten Kriterien, auf die ich nicht im Einzelnen eingehe, wird dann ein Delta Merge ausgeführt, welches das Delta und die Hauptdaten zusammenführt (siehe Abbildung 1.7), um eine optimale Komprimierung der Daten zu erreichen.

Wenn der Delta Merge über eine längere Zeit nicht ausgeführt wird, kann dieser manuell über SQLScript angestoßen werden. Näheres hierzu finden Sie im SAP KBA: 2057046 – FAQ: SAP HANA Delta Merges.

Abbildung 1.7: Delta Merge der Tabelle »Kunde«

1.10 Namenskonventionen SQLScript

Bei der Namenskonvention innerhalb der SQL-Syntax unter HANA kann bzw. sollte man Folgendes beachten:

Eine Abfrage an eine Tabelle im SQL-Editor, wie z.B.

SELECT vorname, land from kunde

kann zu einem Ergebnis wie in Abbildung 1.8 führen, da die physikalische Tabelle mit dem Namen KUNDE angelegt wurde und obige Abfrage von der DB automatisch als KUNDE (in Großbuchstaben) interpretiert wird.

Abbildung 1.8: Namenskonvention

Bei jeder Definition von Tabellen oder deren Abfrage ist es also wichtig, ob eine Namenskonvention eingehalten oder ob sie übersteuert wurde.

1.10.1 Grundsätzliche Namenskonvention für HANA SQLScript

SQL unterscheidet nicht zwischen Groß- und Kleinschreibung, es sei denn, Sie setzen die Namen der Datenbanktabellen und -felder in Hochkommas.

Für SQL-Befehle gibt es den ungeschriebenen Standard: Großschreibung.

SQL-Syntax in diesem Buch

In einigen Ratgebern werden SQL-Kommandos grundsätzlich großgeschrieben und auch von manchen Editoren automatisch in Großbuchstaben umgewandelt. Im Buch verwende ich mal die Groß- und mal die Kleinschreibung der SQLScript-Befehle, um darzustellen, dass dieses für die Ausführung unerheblich ist.

Select vorname, land from kundeSelect voRName, land from kUndE

Beide Codezeilen führen bei der Ausführung zu einem identischen Ergebnis.

Abfrage ohne Schemaangabe

SELECT vorname, land from kunde

Der Code bezieht sich auf das Benutzerschema, da nicht explizit ein Schemaname angegeben wurde, wodurch die Tabelle »Kunde« in dem Schema existent sein muss.

1.10.2 HANA-Schemadeklaration

Wenn keine Tabellen im Benutzerschema angesprochen werden, muss der Schemaname vor dem Tabellennamen angegeben werden. Schema- und Tabellenname sind durch einen Punkt voneinander getrennt.

Der folgende SQL-Code bezieht sich auf das Schema »MEIN_SCHEMA« und die dort erstellte Tabelle »Kunde«:

Select vorname, Land from MEIN_SCHEMA.KUNDE

1.10.3 Notation von Schema und Tabellen oder Tabellenfeldern

Alle Angaben in SQLScript, die Sie mit einem Hochkomma versehen, werden in HANA als Case-sensitive behandelt, was bedeutet, dass alles genau auf Grundlage Ihrer Eingabe übernommen wird. Dadurch werden auch fehlerhafte Eingaben, wie Leerzeichen, berücksichtigt. Das folgende Statement würde dazu führen, dass alle angelegten Spalten mit der exakten Bezeichnung und dem jeweiligen Leerzeichen angesprochen werden müssen:

CREATE TABLE MY_TABLE("UID" int, " UID" int , "UID " int);

Spaltennamen müssen nicht mit Hochkomma eingegeben werden, sofern diese nicht mit Kleinbuchstaben angelegt wurden. Abfragen mit Hochkomma sind somit obsolet.

Abfrage mit und ohne Hochkomma für Felder/Spalten

 Select vorname, land from kunde:

Dies liefert ein Ergebnis aus dem Schema des Benutzers, da die Tabelle nur mit Großbuchstaben in den Spalten angelegt und kein Schema explizit angegeben wurde.

 Select "vorname", "land" from "kunde":

Dies liefert KEIN Ergebnis, da die Tabelle nur mit Großbuchstaben angelegt wurde, hier aber durch die Hochkomma-Syntax explizit nach einer Spalte und Tabelle »kunde« gesucht wurde.

Ergebnis: Die Datenbank findet die Tabelle »kunde« nicht, da diese als »KUNDE« angelegt wurde.

Statt eines Ergebnisses liefert die Abfrage den Fehler

Could not execute 'Select "vorname", "land" from "kunde"'

SAP DBTech JDBC: [259]: invalid table name: Could not find table/view kunde in schema.

Falls eine Tabelle mit dem folgenden Befehl angelegt wurde, beinhaltet der physische Tabellenname auch Kleinbuchstaben.

CREATE COLUMN TABLE "Kunde"

Wenn Sie die in Abbildung 1.9 gezeigten Ergebnisse abrufen wollen, also

 Tabelle »Kunde« (Zeile 1) und

 Tabelle KUNDE oder kunde (Zeile 2),

so müssen die Tabelle »Kunde« in Zeile 1 mit und die Tabelle »KUNDE« in Zeile 2 mit oder ohne Hochkomma angelegt werden, wobei kein Hochkomma automatisch zur Großschrift bei Tabellen- und Spaltennamen führt.

Abbildung 1.9: Darstellung der Tabelle »Kunde« je nach Deklaration

Im ersten Fall (»Kunde«) muss diese Tabelle bei Abfragen mit einem Hochkomma angesprochen werden, da sonst kein Ergebnis geliefert wird, weil die Tabelle explizit mit Kleinbuchstaben im Namen deklariert wurde.

Select * from "Kunde"

Beide Tabellen können existieren und je nachdem, ob Sie die Tabelle Kunde oder KUNDE ansprechen, unterschiedliche Ergebnisse liefern.

Vermeiden Sie Hochkomma-Deklarationen

Ich empfehle, alle Tabellen und Spalten in Großbuchstaben anzulegen, ohne Hochkomma-Deklaration. Das spart Ihnen später Zeit bei den Abfragen und vermeidet viel Arbeit bei der Fehlersuche. Grundsätzlich sollten Tabellennamen eindeutig sein, daher sollten die Bezeichnungen Kunde und KUNDE in Ihrem Datenmodell nicht koexistieren!

Ausnahme: Tabellen mit Sonderzeichen

Eine Ausnahme bildet der Zugriff von Infoprovidern auf SAP-BW-Tabellen, da diese Sonderzeichen beinhalten. Jegliche Tabellen, die mit Sonderzeichen beginnen, müssen explizit mittels Hochkomma-Deklaration adressiert werden. Im SAP-Umfeld werden weiterhin Großbuchstaben bei der Namensgebung der Tabellen verwendet.

Ein Zugriff mittels SQL auf z.B. ein advanced Datastore Object (aDSO) in der Form

Select * from MY_BW_SCHEMA./BIC/AMEIN_ADSO2

ist aufgrund der Sonderzeichen im Tabellennamen nicht möglich und liefert den Fehler »Tabelle unbekannt«. Hier muss die Abfrage wie folgt lauten:

Select * from "MY_BW_SCHEMA"."/BIC/AMEIN_ADSO2"

Wie bereits erwähnt, sollte stets ein eigenes Schema zur Anlage kundeneigener Objekte gewählt werden. Dadurch verlängert sich zwar der Code eines Select-Statements um den gewählten Schemanamen, jedoch überwiegen die Vorteile bei Weitem.

Das aktuelle Schema, in dem Sie gerade arbeiten, erhalten Sie durch den Befehl:

SELECT CURRENT_SCHEMA AS "Current schema" FROM DUMMY;

Nutzung von Komma

Zur Trennung von Tabellenfeldern bei der Abfrage oder dem Einfügen von Daten ist das Komma notwendig. Auch hier gibt es in Ratgebern verschiedene Ansichten. Für die Ausführung in SQLScript ist das Komma als Trennzeichen der Feldnamen relevant, nicht aber dessen Position. In diesem Buch verwende ich das Komma am Ende des ersten Feldnamens.

Das Komma in der Deklaration von Tabellenfeldern kann am Ende des ersten oder am Anfang des zweiten Feldnamens eingegeben werden.

Dazu zwei Beispiele:

Select vorname, name, land, plz, ort from "Kunde"

Select vorname ,name ,land ,plz ,ort from "Kunde"

Beide Beispiele liefern das gleiche Ergebnis, die unterschiedlichen Schreibweisen hängen mehr mit der Ästhetik der Lesbarkeit zusammen. Sie sollten sich aber für eine einheitliche Schreibweise innerhalb Ihres SQLScript entscheiden.

1.10.4 Schemadeklaration von HANA Multitenant

Ab HANA 2.0 ist jede HANA-Datenbank Multitenant-fähig. Das bedeutet, dass in einer physikalischen Datenbank z.B. zwei oder mehr Datenbank-Tenants, somit auch komplette SAP-Systeme, existieren können. Durch SQL-Abfragen und Customizing der Datenbank, wobei der Durchgriff auf Tenants freigeschaltet werden muss (Detailinformation dazu finden Sie im HANA Developer Guide der SAP), werden auf diese Weise übergreifende Abfragen an die Daten ermöglicht.

Bei Verwendung von HANA 2.0 Multitenant-Datenbanken, auch als Multi Database Container (MDC) bekannt, muss für »Cross-database«-Abfragen die Tenant DB vor Schema- und Tabellennamen angegeben werden:

Select TENANT.SCHEMA.TABELLE

 Die Abfrage an eine Tabelle wird in der Regel unter Einbeziehung des Schemas erstellt:Der Schemaname ist führend vor dem Tabellennamen.Die Spaltennamen sind alle in Großbuchstaben angelegt, daher wird bei Abfragen die Schreibweise mit Hochkomma redundant.

 Wenn kein Schemaname angegeben wird, versucht das System stets, aus dem Benutzerschema zu lesen.

1.10.5 Konvention bei Typ einer Tabelle

In diesem Buch gehe ich nicht auf das Pro und Kontra von zeilen- oder spaltenbasierten Tabellen ein, da dies den Rahmen dieses Werkes sprengen würde. Grundlegend kann man aber die jeweiligen Vorteile wie folgt beschreiben:

 Zeilenbasierte Tabelle (Typ: ROW Store)optimal, wenn der Inhalt einer gesamten Zeile gelesen werden soll (z.B. für Druck- oder Listenausgaben)

 Spaltenbasierte Tabelle (Typ: COLUMN Store)optimiert für Komprimierungschnellerer Lese- und Schreibzugriffschnellere Aggregation und Berechnung von Werten

In Eclipse und in HANA Studio werden die beiden Tabellentypen nur durch unterschiedliche Icons dargestellt:

	= zeilenbasierte Tabelle
	= spaltenbasierte Tabelle

Für die Beispiele in diesem Buch werden Sie ausschließlich Tabellen vom Typ COLUMN Store verwenden, wie im nächsten Abschnitt zu sehen ist.

1.10.6 DML-Syntax zum Einfügen von Daten

Bei der Syntax, mit der Daten in eine Tabelle eingefügt werden (siehe Abschnitt 1.12.1), muss erst die Angabe der Spalten (UID, VORNAME, NACHNAME, EMAIL etc.) und dann die der eigentlichen Daten in der richtigen Reihenfolge (1,'Susan', 'Meier', 'sume@mail.de') erfolgen.

Je nach Definition des Spaltentyps der Tabelle (VORNAME als zeichenartige, 20-stellige Spalte, oder PLZ als Integer) testet die Datenbank automatisch, ob die Werte korrekt sind. Wenn Sie bei der PLZ versehentlich ALPHA-Zeichen eingegeben haben, würde die DB dies verweigern und der Vorgang zu einem Fehler führen. Hier können Sie durch die Definition des Datentyps Fehleingaben bereits im Vorfeld vermeiden.

Zeichenartige Werte wie VORNAME sind mit einfachem Apostroph einzubinden, z.B. 'Susanne'. Durch den Apostroph wird auch die jeweilige Groß- und Kleinschreibung berücksichtigt.

1.10.7 Null oder NULL

Ein wichtiger Aspekt in der HANA-Datenbank ist der Wert NULL. Hiermit ist nicht der dezimale Wert »0« (null) gemeint, sondern der DB-Wert NULL. Während sich in einer Tabelle Werte beispielsweise auf null (0) summieren (10 € − 10 € = 0 €) oder als null (0) abgelegt werden können, bedeutet der Wert NULL, dass in der Spalte/Zeile der Tabelle kein Wert vorhanden ist. Beim Anlegen einer Tabelle kann man definieren, ob eine Spalte den Wert NULL beinhalten darf oder ob dieser als NOT NULL definiert ist (siehe Abschnitt 1.11). Im zweiten Fall (NOT NULL) muss explizit ein Wert abgelegt werden, ansonsten gibt die DB bei der Befüllung der Tabelle einen Fehler aus.

Zusätzlich lässt sich bei der Abfrage einer Tabelle auch NULL als Kriterium verwenden, um Fehler zu vermeiden.

Vergleich mit Operatoren auf NULL

Wie schon bei den Operatoren erwähnt (vgl. Abschnitt 1.6), ist eine Abfrage über NULL nicht mit dem Standard-Vergleichsoperator »=« bzw. »!=« möglich, da diese Abfrage kein Ergebnis liefern würde. Eine Abfrage auf NULL erfordert immer »IS NULL« oder »IS NOT NULL«.

So könnte die SQL-Abfrage für »Zeige mir alle Kunden an, bei denen die Postleitzahl nicht gepflegt wurde« wie folgt aussehen:

SELECT * FROM KUNDE WHERE PLZ IS NULL

Das Gegenteil wäre die Abfrage »Zeige alle Kunden, für die die PLZ gepflegt ist«:

SELECT * FROM KUNDE WHERE PLZ IS NOT NULL

Wenn der Wert der PLZ, der in BW immer dem Initialwert des Merkmals entspricht, z.B. '' (also LEERSTRING) oder bei Integer-Werten eine Null (0) ist, so wird bei der SQL-Abfrage der NULL-Wert nicht berücksichtigt.

Sofern Sie alle PLZ-Einträge sehen möchten, die den BW-Wert »Initial« haben, müssen Sie Ihre Anfrage auf den Leerstring anpassen.

SELECT * FROM KUNDE WHERE PLZ = ''

Wenn eine Tabelle für bestimmte Spalten keine Werte aufweist, führt das bei der Darstellung in Eclipse/HANA Studio zur Anzeige als ? (Fragezeichen). Somit wird jeder NULL-Wert als Fragezeichen dargestellt, um von möglichen Leerstring-Werten den Unterschied zu NULL-Werten darzustellen (siehe Abbildung 1.10).

Abbildung 1.10: Darstellung von NULL-Werten in einer Tabelle