Utilisation d'associations et de compositions

Les associations sont utilisées pour définir les relations entre les entités.

Dans l'exemple illustré dans la figure Association des livres aux auteurs, l'association entre Livres et Auteurs est définie via l'élément auteur dans l'entité Livres. Cet élément crée un lien vers l'entité Auteurs, qui établit une relation dans laquelle vous pouvez naviguer d'une entité Pages à l'auteur associé pour récupérer plus de détails tels que le nom de l'auteur.

L'association to-one Books:writer dans l'exemple de code est une association dite gérée, où les champs de clés externes et les conditions on sont automatiquement ajoutés en arrière-plan.

En fonction de la clé primaire de la cible, c'est-à-dire de l'entité Authors, CDS ajoute automatiquement la zone de clé externe author_ID à une base de données SQL lors de l'activation (voir la figure Zone de clé externe générée) et ajoute implicitement la condition de jointure correspondante.

En plus des associations gérées, on peut aussi utiliser des associations non gérées. Les associations non gérées spécifient explicitement des conditions de jointure arbitraires dans leur clause on qui font référence aux zones de clé externe disponibles.

Ensuite, nous allons examiner un exemple d'association à plusieurs.

Un auteur peut écrire n'importe quel nombre de livres, c'est-à-dire qu'un auteur peut être associé à aucun, un ou plusieurs livres.

La figure Association des auteurs aux pages montre comment ces associations sont définies dans un modèle CDS.

La relation entre l'entité Auteurs et l'entité cible Pages est spécifiée par l'élément Pages dans l'entité Auteurs. La syntaxe Association to many Books indique qu'un auteur est associé à un nombre quelconque de livres.

Dans la condition on , les jeux de noms d'association sont utilisés comme alias pour l'entité cible Pages à lier. La clause on books.author = $self spécifie que le champ auteur de l'entité Pages est utilisé pour créer le lien vers l'entité Auteurs. $self est un espace réservé qui fait référence à l'instance actuelle d'un auteur.

En général, une expression selon le modèle suivant est spécifiée dans la condition on pour les associations à plusieurs :

<assoc>.<backlink> = $self

Le backlink peut être n'importe quelle association gérée à un du côté multiple qui pointe vers l'un des côtés.

Outre les associations, CAP supporte également la modélisation des compositions.

Les associations relient des entités qui peuvent exister indépendamment les unes des autres, telles que les auteurs et les livres.

Les compositions, quant à elles, représentent des relations enfermées et sont utilisées pour modéliser des nomenclatures documents. Ils s'affichent fréquemment dans plusieurs scénarios en-têtes/enfants, tels que les commandes et les postes de commande.

Composition signifie que l'entité subordonnée (postes d'ordre) fait partie d'un ensemble et ne peut pas exister indépendamment de l'entité supérieure (ordre). L'entité enfant est contenue dans l'entité parent et est accessible uniquement via l'entité parent.

La figure Exemple de composition illustre la manière dont les compositions sont définies dans CDS. La composition affichée définit une relation un-à-plusieurs entre les ordres et les postes de commande. La syntaxe est très similaire à la définition d'une association un-à-plusieurs. La seule différence est la clause Composition of au lieu de la clause Association to d'un côté (comparez l'association entre les auteurs et les livres ci-dessus).

Les durées d'exécution de la PAC traitent les compositions différemment des associations à certains égards. Il existe entre autres les particularités suivantes pour les compositions :

• Suppression en cascade

  La suppression d'un ordre entraînerait également la suppression de tous ses postes d'ordre en raison de la relation de composition.

• Deep Insert

  Dans le service OData généré, une commande et les postes de commande contenus peuvent être créés via une seule demande POST.

Voyons ensuite comment les associations peuvent être exposées dans les interfaces de service.

Vous pouvez ajouter des associations comme des éléments réguliers à la liste de sélection d'une vue (as select from) ou à une projection (as projection on). Un select * comprend toutes les associations.

La figure Exposé des projections montre les deux projections AdminService.Books et AdminService.Authors de notre scénario, qui sont exposées via le AdminService. La signature effective de la projection AdminService.Books contient une association d'auteur avec les mêmes propriétés que l'association auteur de l'entité com.sap.learning.Books. De même, la signature de la projection AdminService.Authors contient une association de livres avec les mêmes propriétés que l'association livres de l'entité com.sap.learning.Authors.

Le service d'administration illustré dans la figure Exposition de projections présente les deux projections sur les entités à partir du modèle de données sous-jacent.

Lors de l'exposition d'entités liées, les associations sont automatiquement redirigées. Cela garantit que les clients peuvent naviguer entre les entités projetées comme prévu (voir la figure Associations redirigées). Cela signifie que AdminService.Authors.books pointe vers AdminService.Books - et non vers com.sap.learning.Books. De même, AdminService.Books.author fait référence à AdminService.Authors - et non à com.sap.learning.Authors.

Dans le service OData généré, les associations publiées sont disponibles comme propriétés de navigation avec le même nom.

La figure Propriétés de navigation générées montre l'extrait correspondant du document de métadonnées de service. Le type d'entité Livres a une propriété de navigation Auteur et le type d'entité Auteurs a un livre de propriétés de navigation.

Regardez la vidéo pour voir comment ajouter des associations au modèle de domaine.

Ensuite, nous étudierons comment les définitions d'entité peuvent être étendues avec de nouveaux éléments à l'aide d'aspects.