第1章では、WindowsにCAP Java開発環境を構築し、bookshopという名前のCAP Javaプロジェクトを作成して、実際に起動するところまで確認しました。
第2章では、いよいよCAP開発の中心とも言えるCDS（Core Data Services）を使って、データモデル（テーブル）を作っていきます。
ABAPerにとって、テーブル設計はもっとも馴染み深い領域のひとつだと思います。ABAP Dictionary（SE11）で長年テーブルを作ってきた経験が、CDSでどこまで通用するのか、どこが違うのかを意識しながら進めていきます。
第2章はボリュームが大きいため、4本の記事に分けてお届けします。
この記事ではまず、CDSとは何かという基礎知識と、最初のEntity（テーブル）を作るところまでを扱います。
CDSとは何か｜ABAP Dictionaryとの違い
まず、CDS（Core Data Services）が何者なのかを整理しておきます。
ABAP開発では、テーブルの定義は基本的にABAP Dictionary（SE11）で行ってきました。
SE11でフィールドを定義し、データ型を指定し、活性化（アクティベート）することで、実際のデータベーステーブルが作られます。
その後、必要に応じてABAP CDSビューを重ねて、参照・結合・集計などのロジックを追加していく、というのがおおよその流れだったと思います。
CAPにおけるCDSは、これとは少し立ち位置が異なります。
CDSは、テーブルの構造（エンティティ）から、ビュー、さらにはサービスの公開定義まで、CAPアプリケーションのデータに関するすべてを一貫して記述するための言語です。
ABAPのように「まずDDICでテーブルを作り、あとからCDSビューを重ねる」という2段構えではなく、最初からCDSがすべての起点になります。
特に大きな違いは、CDSが単なるテキストファイルであるという点です。
SE11のようにGUIで項目を1つずつ追加していくのではなく、テキストエディタ（VS Code）でエンティティを記述していきます。
最初は「GUIがない」ことに不安を感じるかもしれませんが、慣れてくると、コピー＆ペーストや一括修正がしやすく、Gitでの差分管理もできるという点で、むしろ快適に感じる部分も多いです。
CAP Javaのフォルダー構成の解説
作成された bookshop フォルダーの中身を見てみましょう。
VS Codeで bookshop フォルダーを開くと（メニューの「ファイル」→「フォルダーを開く」）、次のような構成になっているはずです。
bookshop/
├── db/ … データモデル（CDS）を置く場所
├── srv/ … サービス定義・ビジネスロジックを置く場所
├── package.json … Node.js/CDSツール向けの設定ファイル
├── pom.xml … Mavenのビルド設定ファイル（Java機能を追加すると生成される）
└── mvnw / mvnw.cmd … Mavenを個別インストールしなくても実行できるようにするラッパーcopy
ポイントは、「データモデル（db）」「ビジネスロジック（srv）」がフォルダーとして明確に分離されていることです。
ABAP開発では、これらはすべて「同じシステムの中のオブジェクト」として扱われ、パッケージやトランザクションコードで区別していましたが、CAPではフォルダー構成そのものが、その役割分担を表しています。
最初のEntityを作ってみよう
それでは、実際に手を動かしていきます。
第1章で作成したbookshopプロジェクトを開いてください。
cd C:\projects\cap\bookshop
code .copy
CAPのデータモデルは、慣習としてdbフォルダーの中に置きます。dbフォルダーの中にschema.cdsというファイルを新規作成してください。
db/
└── schema.cdscopy
このファイルに、最初のエンティティとして「本（Books）」を定義してみます。
namespace my.bookshop;
entity Books {
key ID : Integer;
title : String(30);
stock : Integer;
}copy
ABAPerの感覚で言うと、SE11で「ZBOOKS」というテーブルを新規作成し、ID（キー項目）、TITLE、STOCKという3つのフィールドを追加して活性化した状態、とイメージしてもらうと近いです。
先頭のnamespace my.bookshop;は、このエンティティがどの名前空間に属するかを示すものです。
ABAPで言えば、ZやYから始まる命名規則で自社の開発オブジェクトを識別するのに近い役割です。
CDSでは、この名前空間を「.」区切りの階層で表現します。
保存したら、構文が正しいかを確認してみましょう。ターミナルで次のコマンドを実行します。
cds compile db/schema.cdscopy
エラーがなければ、コンパイル結果（内部的なデータモデルの構造）がターミナルに出力されます。
これは、ABAPで言えば「構文チェック（Ctrl+F2）」を実行したイメージに近いです。
CDSのデータ型をABAPの型と比較して理解する
先ほどの例ではIntegerとStringという型を使いました。CDSにはこの他にもいくつかの基本データ型が用意されています。
ABAPの型と対比しながら整理しておきます。
ABAPと大きく違うと感じたのは、String(n)のnが「バイト数」ではなく「Unicode文字数」を表すという点です。
ABAPのCHAR型もUnicodeシステムであれば文字数ベースですが、レガシーな感覚で「バイト数を気にして型を決める」という発想からは、CDSでは基本的に解放されます。
また、Decimalは金額や数量など、誤差が許されない値に使う点でABAPのCURRやDECと同じ考え方です。
逆に、レポート集計値など多少の誤差が許容される場面ではDoubleを使う、という使い分けも、ABAPでFLTPを使う場面と近い感覚です。
次の記事（第2章-②）では、主キーの定義方法や、String・Decimal・Date・Timestampといった主要なデータ型の使い方、そしてcuid・managedによる共通項目の自動追加について見ていきます。
引き続き、頑張っていきましょう。頑張れABAPer。
コメント