Предисловие — этот пост является частью SAP САРМ серии.

Введение

Модель предметной области в SAP CAP — это модель, которая описывает статические аспекты предметной области, связанные с данными, в терминах моделей отношений объектов. В этой статье мы подробно изучим моделирование предметной области в SAP CAP.

Моделирование предметной области

Проще говоря, CDS в SAP CAP создает модель предметной области таким образом, что она определяет бизнес-задачу с точки зрения ключей, полей и аннотаций. Код для создания модели предметной области написан в схеме CDS (db/schema.cds). Эти модели предметной области можно использовать в определениях служб, моделях постоянства, базах данных или даже повторно использовать в другой модели предметной области.

Пример примера:

Пространство имен используя {валюту, управляемую} из '@sap/cds/common'; сущность Сотрудники: управляемый { ID ключа: Integer; firstName: локализованная строка (111); lastName: локализованная строка (1111); менеджер: Ассоциация менеджеров; дата присоединения: целое число; зарплата: десятичная (9,2); валюта: Валюта; }

В этом примере мы создали файл schema.cds, в котором мы создали сущность «Сотрудники», которая включает основные сведения о сотруднике.

Вся эта схема получила пространство имен, т.е. empInfo

В этой схеме используется стандартный тип данных, т.е. валюта. Использование стандартного типа данных, подобного этому, помогает нам получить все предопределенные справки по значениям, связанные с ним.

Мы используем CDS для создания модели. В этой CDS мы используем

1. Объекты для представления набора уникальных объектов, например:
   1. Основная информация о сотруднике
   2. Информация для сотрудников
   3. Информация о зарплате сотрудников
2. Ассоциации для определения отношений
   1. Связь менеджера с другим менеджером объекта, который будет иметь весь список менеджеров

Соглашение об именах и рекомендации

1. Название объекта должно начинаться с заглавной буквы, оно должно быть понятным и не требующим пояснений — например, «Сотрудники».
2. Начинайте элементы со строчной буквы — например, firstName
3. Рекомендуется использовать формы множественного числа, например, Сотрудники.
4. Рекомендуется использовать форму единственного числа типов, например, Валюта.
5. не повторяйте контексты — например, Employees.name вместо Employees.EmployeeName
6. предпочитать названия, состоящие из одного слова – например, оклад вместо окладасумма
7. использовать идентификатор для технических первичных ключей — например, идентификатор для идентификатора сотрудника
8. Вы можете использовать пространство имен, чтобы сделать ваши сущности уникальными. Это похоже на концепцию клиента в SAP, где вы можете иметь повторяющиеся схемы (файлы cds) с уникальным пространством имен, чтобы различать их. Пространства имен необязательны, используйте пространства имен, если ваши модели могут быть повторно использованы в других проектах. В конце концов, это просто префиксы, которые автоматически применяются ко всем соответствующим именам в файле. - Например,

ноутбук пространства имен; объект Dell {}

..… эквивалентно:

объект ноутбук.Dell {}

9. Вы можете использовать контексты для вложенных разделов пространства имен. - Например,

ноутбук пространства имен; объект Dell {}           //> ноутбук.Dellконтекст Apple { объект MacBookPro {}       //> ноутбук.Apple.MacBookPro     объект MacBookAir {} }

Юридические лица

Сущности похожи на таблицы с первичными ключами. Мы можем выполнить операцию CRUD, используя эти объекты. Держите его как можно более плоским. Не переусердствуйте с его нормализацией. Не используйте одноразовые типы. Этот раздел предназначен только для моделирования, следует добавлять только аннотацию, относящуюся к отдельным полям, и никаких технических деталей (логики).

Тип

Типы похожи на домен в SAP ABAP, они используются для определения типов элементов данных.

аспекты

Аспекты являются расширениями моделей и в основном используются для расширения существующих определений и аннотаций. Как только модель определена, мы можем использовать различные файлы cds (Aspect) для добавления к ним аннотаций для конкретной задачи.

Например-

• компакт-дисков– модель вашей основной предметной области, оставленная чистой, простой и понятной
• аудит-model.cds- добавляет дополнительные поля, необходимые для аудита в файле
• авторизация-model.cds— добавляет аннотации для авторизации.

Первичные ключи

Подобно таблицам и CDS в SAP ABAP, мы поддерживаем первичные ключи для Entity, используя ключевое слово. .

Первичный ключ можно повторно использовать в модели с помощью методологии общих определений.

Мы можем создать модель common.cds, в которой можно хранить все общие определения.

// общие определения

сущность StandardEntity { идентификатор ключа: UUID; } Теперь эти общие определения можно повторно использовать, как показано ниже: using { StandardEntity } from './common'; сущность Сотрудник: StandardEntity { имя: Строка; ... } Менеджер сущностей: StandardEntity { имя: Строка; ... }

Общий файл уже создан по умолчанию с предопределенной сущностью с именем Cuid.

Сопоставление UUID с OData

CDS сопоставляет UUID с Edm.Guid по умолчанию во всех моделях OData. Однако стандарт OData устанавливает ограничительные правила для значений Edm.Guid — например, разрешены только строки с дефисами, — что может конфликтовать с существующими данными. Поэтому мы позволяем переопределить сопоставление по умолчанию следующим образом:

сущности Книги {

идентификатор ключа: UUID @одата.Type:'Edm.String';

...

}

При необходимости вы также можете добавить аннотацию @odata.MaxLength для переопределения соответствующего свойства.

Объединение

Он используется для определения отношений между двумя объектами. Подобно ABAP CDS, здесь мы также используем слово Ассоциация. Здесь ключевое слово много указывает на 0 .. * мощность. Ограничения на кардинальность можно добавить как ограничение (где условие) — например, с помощью ненулевой.

Композиции

В отличие от ассоциации, где мы связываем поле объекта с объектами всего объекта, композиции просто ссылаются на определенное поле другого объекта. Он имеет дополнительное преимущество самоуправляемых глубоких операций (вставка/обновление) и каскадного удаления (многозависимое удаление таблицы).

// Определяем Orders с содержащимися OrderItemsсущность Заказы { идентификатор ключа: UUID; Items : Состав множества Order_Items на Items.parent=$self;}entity Order_Items { // доступ возможен только через Заказы  key parent : Ассоциация с Заказами; ключевая книга: ассоциация с книгами; количество: целое число;}

Лучшие практики

1. Не добавляйте технические детали в Модели, мы используем аспектыдля этого
2. Используйте короткие имена и простые плоские модели
3. Не переусердствуйте с нормализацией объектов в моделях
4. Используйте локальные целочисленные последовательности, если вы действительно имеете дело с большими нагрузками и объемами. В противном случае предпочтите UUID

Чему мы научились до сих пор: Создание модели и аспектов поверх нее.