Defining Domain Models

Objective

After completing this lesson, you will be able to capture basic domain models using Core Data Services

Fundamental Principles of CDS Models

The Role of Core Data Services

Core Data Services (CDS) are a fundamental concept in CAP. They provide the means to declaratively capture data models as well as service models.

Watch the video to understand the model-based approach.

In this lesson we will focus on domain models. Service models will be covered in the next lesson.

The Nature of Models

CDS models are represented in Core Schema Notation (CSN). CSN (pronounced like "season") is similar to JSON Schema, but goes beyond the capabilities of JSON to capture full-blown entity-relationship models and extensions.

Watch the video to get an overview of the source and target formats of the CDS models.

In this learning, we will define models in .cds files.

Domain Entities

As mentioned earlier, let's now look at how to create domain models using CDL. To do this, we create a file with the extension .cds in the db folder of the CAP project. The name of the file is arbitrary, a common file name is for example schema.cds.

First, we specify a single domain entity called Authors in the file (see figure A Simple Domain Entity).

Domain entities are structured types with named and typed elements representing data sets that can be read and manipulated using usual CRUD operations. When translated into persistence models, entities become tables.

Hint

Naming conventions: It is recommended to capitalize entity names. Also use the plural form for entity names (e.g. Authors). Start elements with a lower case letter (e.g. name).

To type the elements, CDS comes with a small set of built-in types. A list of the built-in types can be found in the CDS documentation.

The syntax entity Authors used in the figure is equivalent to define entity Authors. This means that the keyword define is optional.

Use the keyword key to specify one or more elements that form the primary key of an entity.

Hint

Prefer simple, technical primary keys that only consist of a single field. Utilize ID as the name for this single key field and type it with the built-in data type UUID. Primary key elements with the type UUID are automatically filled upon INSERT.

Namespaces

You can define namespaces that are automatically applied to all relevant names in a file. In the example shown, the entity name Authors is prefixed with the namespace com.sap.learning, resulting in com.sap.learning.Authors as the full entity name. Namespaces are just prefixes - there is nothing special about them beyond that. Namespaces are optional - use them if your models could be reused in other projects; otherwise you can do without them.

Hint

The reverse domain name approach works well for choosing namespaces.

Custom-Defined Types

You can declare custom types for elements in entity definitions. The custom types can be simple types, i.e. derived from one of the built-in types, structured types or associations. Here we will deal with simple types and structured types. Associations will be covered later in the learning journey.

Simple Types

In figure Example of a Simple Type, a simple type called NoOfBooks is defined. It is based on the built-in data type Integer. This means that wherever NoOfBooks is used, it essentially represents an Integer value.

The Books entity shown has a stock element that is typed with the NoOfBooks type. This means that the data type of this element is essentially Integer.

The definition

Code Snippet
1
type NoOfBooks : Integer;
used in the figure is equivalent to the following:
Code Snippet
1
define type NoOfBooks : Integer;
This means that the keyword define is optional.

Note

Custom types can increase the semantic expressiveness of your models. However, avoid excessive use of such types. They are valuable if you have an appropriate level of reuse. Without reuse, your models will only become more difficult to read and understand, as you will always have to look up the relevant type definitions.

Structured Types

Structured types are custom data types that combine one or more related elements under a single type. They make it possible to create complex data structures and use them within entities.

The Books entity shown in figure Example of a Structured Type has a price element of type Price, which is a separately defined structured type.

The Price type has two elements: amount of built-in type Decimal and currency of built-in type String with a maximum length of 3 characters.

Hint

Naming conventions: It is recommended to capitalize type names in the same way as entity names. In contrast to entity names, however, use the singular form for type names (e.g. Price). 

Enumerations

Enumerations (or enums for short) can be used to make code more readable and self-explanatory, as they allow you to replace cryptic values with symbols in the application logic.

You can specify enumeration values for a type as a semicolon-separated list of symbols with assigned corresponding values. For string types, the assignment of actual values is optional; if omitted, the actual values are the string counterparts of the symbols.

The Books entity in figure Example of Enums has an element called genre of type Genre, which is a custom type with enumeration values.

The Genre type is based on the built-in Integer type, which means that each symbol in the enumeration corresponds to an Integer value.

The Genre enumeration contains two symbols: fiction, which corresponds to Integer value 1, and non_fiction, which corresponds to Integer value 2.

Compiling Models

Generating DDL Files

When you execute cds watch in the terminal to start a server, your domain model, which is defined in the project's db folder, is automatically translated into a persistence model and deployed to the configured database. This means that corresponding SQL DDL statements are generated and executed on the basis of your CDS model.

You can also generate these SQL DDL statements manually using the following command in the terminal:

Code Snippet
1
cds compile <models> [<options>]
You obtain a detailed description of this command by executing
Code Snippet
1
cds compile ?
in the terminal.

To generate an SQL DDL script for a domain model contained in a file named schema.cds in the db folder of the CAP project, execute this command in the root directory of the project:

Code Snippet
1
cds compile db/schema.cds --to sql

The SQL DDL script in figure Compiled CDS Model was generated in this way.

Hint

Instead of entering the above command in the terminal, you can also select the following entry in the context menu of the .cds file: CDS PreviewPreview as sql. This generates the same output as the command line command.

Watch the video to understand the rules that apply to the generated SQL DDL output.

Later we will see that projected entities are generated as views. We will also see that foreign key fields are automatically created in generated database tables to reflect certain associations that can be defined between entities.

Demonstration & Exercise: Capture a Domain Model

Note

As exercise, carry out the step-by-step instructions in the following demonstration yourself in the SAP Business Application Studio.

You can find the source code from the simulation in the branches main and 2_domain_model of the following GitHub repository:

https://github.com/SAP-samples/cap-development-learning-journey

The main branch provides the initial template for the demonstration, while the 2_domain_model branch also contains the sources created in the simulation.

Detailed information on the content of the repository and how to use it can be found here.

Watch the video to see how to capture a domain model.

Log in to track your progress & complete quizzes