Kitabı oku: «Schnelleinstieg in SQLScript für SAP HANA»

1 Einführung in SAP HANA SQL und SQLScript

Im ersten Kapitel dieses Buches möchte ich Sie in die Grundlagen von SQL einführen. Hier geht es um die Basisterminologie, die in HANA SQLScript verwendet wird. Zusätzlich werden die ersten Schritte angesprochen, wie das Anlegen von Tabellen, die wir im weiteren Verlauf des Buches nutzen werden. SQLScript ist keine von SQL unabhängige Sprache, sondern ermöglicht es dem Anwender, eine Vielzahl von Befehlen zu kombinieren und automatisiert auszugeben.

Seit der Einführung der HANA Database (im Folgenden nur noch DB genannt) und deren Verwendung z.B. unter SAP BW (Business Warehouse) oder SAP ECC (ERP Central Component) wurde der Einsatz von SQL immer interessanter.

1.1 Geschichte von SQL

SQL wurde 1970 erfunden und seit dieser Zeit immer mehr erweitert. Es handelt sich dabei zwar um eine Standardprogrammiersprache, aber wie bei allen Sprachen (etwa Englisch oder Deutsch) existieren zu SQL auch Dialekte, die datenbankabhängig sind (etwa Oracle, IBM, Microsoft).

SQL-Syntax in diesem Buch

Wir werden uns in diesem Buch ausschließlich mit SQL der HANA DB beschäftigen.

Alle SQL-Aspekte beruhen auf einem relationalen Datenmodell, das die Tabellen des relationalen Modells in Beziehung setzen kann. Hier spricht man auch von Datenbank-Views. Ich werde Ihnen im Buch aufzeigen, wie man Tabellen anhand dieser Views mittels SQLScript verknüpft.

1.2 Definition von SQL

Die Structured Query Language, kurz SQL, ist eine standardisierte Programmierungssprache zur Definition von Objekten (wie z.B. Tabellen) in einer Datenbank. Diese Objektdefinition bzw. deren Abfrage kann je nach Anforderung einfach oder komplex sein. Außerdem lassen sich mittels SQL Daten abfragen oder andere Objekte wie Views oder Prozeduren anlegen. SQL kann zusätzlich zu den Datenabfragen Objekte direkt definieren und die Abfragen anhand von SQLScript komplex erweitern.

Wenn Sie SQL in einem HANA-basierten SAP-System aufrufen, finden Sie in der Regel bereits eine Vielzahl an Tabellen vor, die durch die SAP definiert und ausgeliefert wurden.

Manchmal ist es trotz der enormen Leistungsfähigkeit von HANA durchaus sinnvoll, neue Tabellen anzulegen, um bestimmte Daten mittels SQL, wenn auch nur temporär, zwischenzuspeichern. Dies kann dazu dienen, die Performance zu erhöhen und bestimmte Prozeduren lesbarer zu halten. Daher sollte Ihnen das Anlegen und Löschen von Tabellen ebenfalls bekannt sein. Dieses Buch wird Sie dabei Schritt für Schritt unterstützen.

1.3 Definition von SQLScript

Abbildung 1.1 zeigt eine vereinfachte Darstellung der Definition von HANA SQLScript. Wie Sie erkennen können, erweitert SQLScript die Sprache SQL sowohl um die von Ihnen erstellten funktionalen Ergänzungen, wie eigene Prozeduren oder Funktionen, als auch um die Verwendung von Schleifen oder komplexen Logiken zur Steuerung des Ablaufs (IF … THEN … etc.).

Abbildung 1.1: Funktionalität von HANA SQLScript

Ein wesentlicher Unterschied zwischen reinem SQL, bei dem ein Datumsfeld nach Selektion im zweiten Schritt mittels SELECT DATE FROM TABLE XYZ umgerechnet werden muss, und SQLScript ist, dass Letzteres diese Vereinfachungen der Syntax sowie eine gewisse Funktionalität bereits beinhaltet.

So kann z.B. über SELECT CURRENT_UTCDATE FROM DUMMY die automatische Rückgabe des UTC-Datums (Greenwich Mean Time) abgefragt oder alternativ mit Offsets wie +1, wodurch eine Stunde auf das Datum addiert wird, gearbeitet werden.

Die DB kann automatisch auf die gesetzten Vorgaben reagieren und so beispielsweise bei der Ermittlung eines Datums die Verschiebung der Zeitzonen berücksichtigen. Dabei werden alle notwendigen Additionen und Subtraktionen sowie die Verschiebung des Datums von der Datenbank übernommen. Eine Abfrage an die Datenbank, um eine bestimmte Funktionalität wie die Anonymisierung von Daten zu nutzen, müssen Sie nicht »von Hand« programmieren, sondern können diese mit SQLScript direkt aufrufen (ähnlich dem Aufruf von Funktionen/Prozeduren, die später noch erläutert werden).

SQLScript soll Sie in die Lage versetzen, auch komplexe DB-Funktionalitäten mit wenigen Zeilen Code aufzurufen und auszuführen.

Ein weiterer Unterschied zum klassischen SQL ist, dass SQLScript Parameter für Filterungen und Einschränkungen der Daten unterstützt.

Außerdem lassen sich Geschäftslogiken wie eine Währungsumrechnung oder Datumskonvertierung zu einem Stichtag durch SQLScript realisieren. Hierzu finden Sie ein Beispiel in Abschnitt 1.14.9.

SQLScript sollte immer dann eingesetzt werden, wenn die Funktionalität von z.B. grafischen Calculation Views zur Datenermittlung nicht ausreicht.

Scripted Calculation Views

Bitte verwenden Sie keine »Scripted« Calculation Views mehr. Deren Nachfolger sind die sogenannten Table Functions.

Ich werde auf Table Functions im Abschnitt 2.3 näher eingehen.

Im Gegensatz zur Entwicklung in SAP ABAP, bei der die Daten aus einer Tabelle in Schleifen von der Datenback in den Applikationsserver geladen werden, wird SQLScript-Code direkt in der Datenbank ausgeführt. Dadurch ist für den Endanwender nur das fertige Ergebnis auf dem Applikationsserver aufrufbar.

Der Sinn von SQLScript ist, möglichst viel der programmierten Logik direkt innerhalb der Datenbank auszuführen, um das Netzwerk zu entlasten. Es dient in allen Bereichen wie AMDP, Calculation Views, Core Data Services oder native HANA-Entwicklung dazu, eine höchstmögliche Parallelität für Aufgaben in der Datenbank zu realisieren. Der SQL Optimizer versucht bei jeder Ausführung einen optimalen Zugriff zu ermöglichen.

Als kleines Beispiel dazu soll Ihnen eine klassische SAP BW Query dienen, in der eine Ausnahmeaggregation durchgeführt wird.

SAP-BW-Abfrage

Stellen Sie sich vor, dass eine BW Query den Umsatz eines Produktes je Land liefert. Sie möchten jedoch zusätzlich den durchschnittlichen Umsatz pro Kunde angezeigt bekommen.

Annahme:

 Ihr Infoprovider, z.B. Advanced Data Store Object (ADSO), oder Ihre Tabelle beinhaltet eine Million Datensätze auf Kundenebene für ein selektiertes Geschäftsjahr.

 Die Anzahl der Kunden im selektierten Geschäftsjahr beträgt 20.

Im klassischen BW werden alle Daten, eine Million in diesem Beispiel, für das selektierte Geschäftsjahr auf den Applikationsserver übertragen. Dort wird im Online Analytical Processing (OLAP) für die 20 Kunden der Durchschnittswert ermittelt. Es bleiben also 20 Datensätze übrig, wobei der Rest verworfen wird, da diese nicht benötigt werden.

Nun nehmen Sie für das klassische BW an, dass eine Million Datensätze über das Netzwerk 12 Sekunden benötigen, dass die Aufbereitung in der DB 3 Sekunden und die OLAP Engine von SAP BW weitere 3 Sekunden Laufzeit in Anspruch nehmen.

Bei SQLScript findet die Berechnung direkt in der DB statt, und nur die erwünschten 20 Datensätze werden übertragen. Neben der guten Grundperformance der Datenbank wird dadurch Netzwerklaufzeit und Zeit beim OLAP-Prozess auf dem Applikationsserver gespart. Zudem werden CPU und Memory des Applikationsservers geschont.

Die Rechnung für SQLScript fällt deutlich vereinfacht aus: Das Netzwerk benötigt unter einer Sekunde für 20 Datensätze, OLAP fällt gänzlich aus und die DB-Berechnung dauert je nach Auslastung der CPUs ebenfalls maximal eine Sekunde.

Wir haben somit im Vergleich zwischen dem klassischen BW (18 Sekunden) und SQLScript (2 Sekunden) einen Laufzeitunterschied von 16 Sekunden, der aber zulasten des BW durchaus auch höher ausfallen kann.

Abbildung 1.2 zeigt eine angenommene Ausführung mit den exemplarischen Laufzeiten von Queries. Eine Query bezieht sich im Beispiel auf eine in SAP BW mit dem Business Explorer (BEx) durch den Query Designer erstellte Abfrage.

Abbildung 1.2: BW OLAP versus SQLScript

1.4 SAP ABAP oder SQLScript

Kann man SQLScript aufgrund der Performance auch in ABAP nutzen?

Ja, in einer HANA-Umgebung wie SAP BW, BW/4HANA oder SAP S/4HANA sollte versucht werden, die Datenlast in der DB zu halten. Hierzu hat die SAP im BW-Umfeld die ABAP Managed Database Procedures (AMDP), z.B. für Transformationen und Core Data Services (CDS) Views, eingeführt, die den Code kapseln sollen.

AMDP sind spezielle ABAP-Prozeduren, die Sie mit SQLScript programmieren, aber analog zu normalen ABAP-Prozeduren aufrufen können.

CDS-Views sind durch SQLScript programmierbare Sichten auf Daten, wie BW-Tabellen oder Abfragen in S/4HANA an die Tabelle ACDOCA, die wie Tabellen in SQL Queries (sowohl ABAP als auch SQLScript) eingebunden werden können. Der große Vorteil ist, dass durch Annotationen in den CDS-Views bestimmt werden kann, ob es sich um eine Tabelle oder einen Endanwenderreport handelt. Beispiele hierzu finden Sie im Abschnitt 2.4.

1.5 SQL/SQLScript – Basiswissen

Wie bereits am Anfang beschrieben, dreht sich bei SQL und SQLScript alles darum, Daten aus der Datenbank zu lesen, neue Daten zu erfassen oder diese zu verändern. Oftmals werden für die verschiedenen Funktionen Kürzel verwendet, die ich Ihnen nun erläutern möchte.

1.5.1 Definitionstypen

Seit dem Erscheinen dieser Datenbanksprache hat man SQL nach und nach in vier Bereiche unterteilt:

 Data Definition Language (DDL): Definition von Objekten (z.B. Tabellen)

 Data Manipulation Language (DML): Einfügen von Daten in Tabellen, Löschen oder Modifizierung von Daten

 Data Control Language (DCL): Erstellung von Usern und deren Zugriffsrechten auf Tabellen, Funktionen etc.

 Data Query Language (DQL): Definition von Abfragen auf Daten, um spezifische Werte zu sehen (Filter, Aggregationen, Kennzahlenberechnung)

Wie in Abbildung 1.3 ersichtlich, greifen alle vier genannten Funktionen auf die zentrale Instanz Database Management System (DBMS) der Datenbank zu. Das DBMS verwaltet die Anfragen und stellt sicher, dass der Zugriff eines Users auf bestimmte Tabellen (mit DQL) erlaubt oder verhindert wird, je nach Definition der Berechtigung über DCL.

Abbildung 1.3: Darstellung der DBMS und SQL-Funktionalität

Wenn eine HANA DB neu installiert wird, stehen eventuell, bis auf die durch HANA generierten internen Tabellen, noch keinerlei kundeneigene Tabellen zur Verfügung. Die Funktionalität der verschiedenen SQL-Bereiche ist dennoch ab dem Moment der Installation gegeben.

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