SAP Datasphere bietet verschiedene Möglichkeiten an, Daten aufzubereiten. So können Sie zum Beispiel Views verwenden, um lokale oder Remote-Tabellen bzw. andere Views zu kombinieren. Auf diese Weise können Sie Daten verknüpfen, filtern und anreichern. Darüber hinaus können Sie Spalten umbenennen oder entfernen und Berechnungen hinzufügen.
SAP Datasphere erlaubt es Ihnen, grafische Views und SQL-Views anzulegen. Welcher Ansatz ist der Richtige für Sie? In diesem Artikel vergleichen wir die beiden Möglichkeiten, um Ihnen zu helfen, eine fundierte Entscheidung auf der Grundlage ihrer spezifischen geschäftlichen Bedürfnisse zu treffen.
Grafische Views erlauben es Ihnen, Ihre Daten auch ohne SQL Kenntnisse aufzubereiten. Mithilfe einer grafischen Oberfläche können auch Benutzer, die nicht technisch versiert sind, und Benutzer aus dem Fachbereich Views erstellen. Sie können verschiedene Quellen über Drag & Drop hinzufügen und kombinieren.
Außerdem können Sie Daten verfeinern, filtern und anreichern. So ist es im grafischen Editor möglich, Datenquellen hinzuzufügen, Joins und Unions anzulegen, Spalten neu anzuordnen, umzubenennen oder auszuschließen. Darüber hinaus können Sie neue berechnete Spalten anlegen, Daten filtern und aggregieren. Daher können grafische Views eingesetzt werden, um die Datenflüsse zu vereinfachen.
Bei Bedarf können Sie die entsprechende SQL-Anweisung über den Menüpfad Bearbeiten → Exportieren → SQL-Vorschau generieren und anzeigen. So können grafische Views als Vorlage für die SQL Views genutzt werden.
Mit SQL Views können Sie komplexe Szenarien abdecken, bei denen grafische Views an ihre Grenzen stoßen. So sind grafische Views auf SQL Statements begrenzt, die Funktionen von SQLScript stehen nicht zur Verfügung. In SQL Views dagegen können Sie beide Sprachen nutzen.
Aber auch relativ einfache Views sehen in SQL aufgeräumter aus. Vorausgesetzt, dass Sie unsere Tipps zum lesbaren SQLScript befolgen. Ein versierter Entwickler versteht dann auf einen Blick, was bei dem View passiert. Ohne sich durch die einzelnen Joins im grafischen Editor durchklicken zu müssen. Das kann die Wartung beschleunigen.
SQL Views werden in einem SQL-Editor geschrieben. Die zu verwendenden Tabellen oder Views können per Drag and Drop hinzugefügt werden und werden in Code transformiert. Darüber hinaus unterstützen die automatischen Vorschläge und Vervollständigung den Entwickler.
Bei der Erstellung von SQL Views können Sie entweder Standard-SQL oder SQLScript als Sprache verwenden. Bei SQL muss die gesamte Logik in einer SELECT-Anweisung erfolgen, was sehr schnell unübersichtlich werden kann. Andererseits ermöglicht die Verwendung von regulärem SQL Datasphere, die Struktur des Abfrageergebnisses automatisch zu erkennen und die Felder mit semantischen Informationen aus den zugrunde liegenden Objekten zu füllen (z. B. Kennzahlen, Attribute, semantische Typen, Datentypen usw.).
Sie können auch SQLScript verwenden, um interne Tabellen zu definieren, die im Code genutzt werden. Darüber hinaus können Sie auf Window-Funktionen zurückgreifen, um auch komplexe Anforderungen abzubilden. Die SQL Views bieten Ihnen also mehr Flexibilität.
Was sind nun die Hauptunterschiede zwischen den beiden Ansätzen? Während grafische Views eine einfach zu bedienende, benutzerfreundliche Oberfläche bieten, punkten SQL Views mit Flexibilität. Dank der visuellen Darstellung erfordern grafische Views keine technischen Fähigkeiten. Außerdem sind grafische Views auch weniger fehleranfällig.
Für einen erfahrenen Entwickler sind SQL Views besser geeignet. Der Entwickler hat die Möglichkeit, auch die kompliziertesten Anforderungen zu erfüllen. So können mit SQLScript Unterabfragen und Window-Funktionen (z.B. ROW_NUMBER() OVER ( PARTITION BY)) definiert werden.
Darüber hinaus wird ein technisch versierter Anwender den SQL Code schneller schreiben, als die Joins per Drag und Drop zu definieren. Ferner sind die SQL Views einfacher zu warten. Die Logik kann mit einem Blick erfasst werden. Man muss nicht durch die einzelnen Joins gehen, um die Verknüpfungen zu verstehen. Der in einer Abfrage verwendete Code kann auch mit wenigen Anpassungen für weitere Abfragen übernommen werden.
Wenn Sie die zwei nachfolgenden Bilder vergleichen, fällt auf, dass der SQL Code viel einfacher lesbar ist. Daher sollten Sie bei Views, die mit der Zeit wachsen und angepasst werden, eher zu SQL Views greifen. Falls Sie zurzeit für diese Szenarien grafische Views verwenden, sollten Sie über eine Migration nachdenken. Je früher Sie den Schritt machen, desto einfacher wird es. Zwar können grafische Views, wie weiter oben erwähnt, in SQL Code exportiert werden. Allerdings ist dieser maschinell erstellte Code schlecht lesbar und muss ohnehin für den menschlichen Nutzer angepasst werden.
Wenn Sie sich für die Verwendung von SQL Views entscheiden, beachten Sie unsere Tipps zum lesbaren SQLScript Code sowie Tipps für SQLScript Performance als Best Practices. Bei der späteren Wartung werden Sie die Vorteile sehen.
Letztendlich hängt es von Ihrem individuellen Fall ab, wann Sie welchen View einsetzen. Bei der Entscheidung sollten Sie die Projektziele und Fähigkeiten des Teams genauso berücksichtigen wie die Komplexität der Daten und langfristige Skalierbarkeiten. Wenn Sie eine hohe Komplexität der Geschäftslogik erwarten, vor allem für Ihre großen transaktionalen Datenmodelle, dann ist es eine gute Idee, gleich mit SQL zu beginnen, da die Konvertierung der grafischen Ansicht in SQL eine kaum lesbare Version von SQL erzeugt, die anschließend zu vielen manuellen Anpassungen führt.
Gegebenenfalls kommt auch ein gemischtes Szenario in Frage. Dabei können Sie grafische Views in Ihrer SQL Logik verwenden oder auch in SQLScript geschriebene Funktionen in der grafischen Oberfläche anreichern.
Haben Sie Fragen zu SAP HANA SQLScript oder zu SAP Datasphere? Versuchen Sie das nötige Know-How in Ihrer Abteilung aufzubauen oder benötigen Sie Unterstützung bei einer konkreten Fragestellung? Wir helfen Ihnen gerne dabei. Fordern Sie noch heute ein unverbindliches Beratungsangebot an!