2.1 Core Data Services Definition Language

Die Core Data Services Definition Language (CDL) legt ihr Hauptaugenmerk darauf, Datenmodelle kurz und prägnant zu beschreiben, ohne dass dabei der Fokus auf die Problemdomäne in technischen Details verloren geht. Dazu wurde eine SQL-ähnliche Syntax entwickelt. Kernelement ist wie bei ABAP CDS und dem SAP Gateway die Entität (im folgenden CDL-Entität genannt). Eine Entität repräsentiert einen Eintrag in einer Datenbanktabelle bzw. Einträge in mehreren zusammenhängenden Datenbanktabellen und besteht aus mehreren Feldern, die einen elementaren oder zusammengesetzten Datentyp besitzen. SAP CAP veröffentlicht Entitäten mittels OData-Services.

2.1.1 Datentypen

CDL-Entitäten setzen sich aus elementaren Datentypen (CDL-Datentypen) zusammen. Tabelle 2.1 zeigt alle elementaren CDL-Datentypen. Dazu ist der jeweilige SQL-Datentyp, der bei Generierung des Datenbankschemas Anwendung findet, mit angegeben.

¹ Länge und Dezimalstellen sind eine optionale Angabe. Ohne diese Angabe wird der Datentyp »DECFLOAT« verwendet.

² Genauigkeit von einer Sekunde.

³ Genauigkeit von 0,1 µs.

Tabelle 2.1: CDL-Datentypen

Aus den elementaren Datentypen können Sie wie in Listing 2.1 strukturierte Datentypen erstellen. Mit dem Zusatz many lassen sich auch Array-Typen konstruieren.

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress name: String } 

Listing 2.1: Array-Typen

Der Nutzerentität aus Listing 2.1 können Sie wegen des Array-Typs mehrere E-Mail-Adressen zuordnen. Die Datenbank legt für Array-Typen ein Feld vom Typ NCLOB an und speichert die Array-Typen als JSON-Arrays.

Mit dem Zusatz type of (siehe Listing 2.2) können Sie auf andere Typen referenzieren (vergleichbar mit der LIKE-Anweisung in ABAP).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String(50) givenName: type of surName } 

Listing 2.2: Typ-Referenzen

2.1.2 Virtuelle Elemente

Der Zusatz virtual kennzeichnet virtuelle Elemente. Diese sind kein Bestandteil der Datenbank, werden aber zur Laufzeit berechnet und den OData-Services zur Verfügung gestellt (siehe Listing 2.3).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.3: Virtuelle Felder

2.1.3 Enums

Enumerationen (Enums) verwenden Sie für Variablen, die nur Werte aus einer vordefinierten endlichen Wertemenge, annehmen können, die Sie bei der Entwicklung festlegen. Beispielsweise können Sie Variablen, die den Kalendermonat oder einen akademischen Titel enthalten, mit Enums darstellen. Listing 2.4 enthält eine Enumeration mit dem akademischen Titel.

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String title: String enum { dr prof drProf } } 

Listing 2.4: Enumerationen

Enums haben im Prinzip dieselbe Funktion wie Domänenfestwerte des ABAP Dictionary.

2.1.4 Einschränkungen

Mit den Zusätzen null bzw. not null definieren Sie Einschränkungen (siehe Listing 2.5).

type EmailAddress { address: String active: Boolean } entity User : managed { key ID : UUID emails: many EmailAddress surName: String not null givenName: String not null virtual completeName: String gender: String enum { male female } null } 

Listing 2.5: Einschränkungen

Die Eingabe null meint in diesem Zusammenhang den SQL-NULL-Wert, d.h., das entsprechende Feld ist undefiniert.

2.1.5 Entitäten

Entitäten leiten Sie mit dem Schlüsselwort entity bzw. define entity ein. Entitäten werden in der Datenbank gesichert und als OData-Service zur Verfügung gestellt. Sie können mithilfe der OData-Services Entitäten erstellen, lesen, ändern und löschen (CRUD-Operationen: CREATE, READ, UPDATE, DELETE).

Mit den folgenden Aspektschlüsselwörtern können Sie Entitäten um häufig benötigte Felder erweitern, ohne die Felder einzeln anzugeben:

• managed – fügt der Entität die Felder createdAt (Label Angelegt am), createdBy (Label Angelegt von), modifiedAt (Label Geändert am) und modifiedBy (Label Geändert von) hinzu (siehe Abbildung 2.1). In Listing 2.6 verwendet die User-Entität das Aspektschlüsselwort managed und enthält damit die gleichen Felder wie die User1-Entität, der die Felder createdAt, createdBy, modifiedAt und modifiedBy manuell hinzugefügt wurden
• cuid – ergänzt ein eindeutiges Primärschlüsselfeld (siehe Listing 2.7)
• temporal (siehe Listing 2.8) – fügt eine zeitliche Gültigkeit hinzu (Felder validFrom, validTo in Abbildung 2.2).

using { managed, sap } from '@sap/cds/common' entity User : managed { key ID : UUID emails: many EmailAddress surName: String givenName: String virtual completeName: String } entity User1 { key ID : UUID createdAt: DateTime createdBy: User modifiedAt: DateTime modifiedBy: User emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.6: Entitäten mit und ohne Aspektschlüsselwort »managed«

Abbildung 2.1 enthält die Ansichtseinstellungen aus der Testvorschau für die User-Entität (siehe Listing 2.6). In Abschnitt 3.1 ist beschrieben, wie Sie die Testvorschau erstellen.

Abbildung 2.1: Aspektschlüsselwort »managed«

using { cuid, sap } from '@sap/cds/common' entity User : cuid { emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.7: Aspektschlüsselwort »cuid«

using { temporal, sap } from '@sap/cds/common' entity User : cuid, temporal { emails: many EmailAddress surName: String givenName: String virtual completeName: String } 

Listing 2.8: Aspektschlüsselwort »temporal«

Abbildung 2.2 enthält die Ansichtseinstellungen aus der Testvorschau für die User-Entität (siehe Listing 2.8).

Abbildung 2.2: Aspektschlüsselwort »temporal«

2.1.6 Assoziationen und Kompositionen

Mit den Schlüsselwörtern Association bzw. Composition (siehe Listing 2.9) bestimmen Sie Zusammenhänge zwischen Entitäten (sogenannte Managed Associations bzw. Managed Compositions). Assoziationen definieren die Beziehung zwischen Positions- und Kopfdaten und Kompositionen die Beziehung zwischen Kopf- und Positionsdaten.

SAP CAP nutzt Assoziationen und Kompositionen, um Navigationseigenschaften (OData-Services) zu generieren. Mit der Assoziation bzw. der Komposition in Listing 2.9 können Sie Aktien- und Firmenobjekte in einem Aufruf lesen oder verändern.

entity Company { key id : String(3) name : String ceo : String shares : Composition of many Share on shares.company = $self volume: Integer } entity Share : cuid { timestamp : Timestamp company : Association to Company stockPrice : Decimal(10, 2) } 

Listing 2.9: Managed Association