Uso de associações e composições

As associações são usadas para definir relações entre entidades.

No exemplo mostrado na figura Associação de Livros a Autores, a associação entre Livros e Autores é definida através do elemento autor na entidade Livros. Esse elemento cria um link para a entidade Autores, que estabelece uma relação onde você pode navegar de uma entidade Livros para o autor associado para recuperar mais detalhes, como o nome do autor.

A associação to-one Books:author no código de amostra é uma associação gerenciada, onde campos-chave externos e condições on são automaticamente adicionados nos bastidores.

Com base na chave primária do destino, ou seja, a entidade Authors, CDS adiciona automaticamente o campo de chave externa auth_ID a um banco de dados SQL durante a ativação (consulte a figura Campo-chave externo gerado) e adiciona implicitamente a condição join correspondente.

Além das associações gerenciadas, também podemos usar associações não gerenciadas. As associações não gerenciadas especificam explicitamente condições join arbitrárias na respectiva cláusula on , que se referem a campos de chave externa disponíveis.

Em seguida, examinaremos um exemplo de uma associação para muitos.

Um autor pode escrever qualquer número de livros, ou seja, um autor pode ser associado a nenhum, um ou vários livros.

Associação de figuras de autores a livros mostra como tais associações para muitos são definidas em um modelo CDS.

A relação entre a entidade Autores e a entidade de destino Livros é especificada pelo elemento livros na entidade Autores. A sintaxe Association to many Books indica que um autor está associado a qualquer número de livros.

Na condição on , os livros de nomes de associação são usados como alias para a entidade de destino Livros a ser vinculada. A cláusula on books.author = $self especifica que o campo do autor na entidade Livros é usado para criar o link para a entidade Autores. $self é um caractere de preenchimento que se refere à instância atual de um autor.

Em geral, uma expressão de acordo com o seguinte padrão é especificada na condição on para associações para-muitos:

<assoc>.<backlink> = $self

O backlink pode ser qualquer associação gerenciada para um dos vários lados que aponta de volta para um lado.

Além das associações, o CAP também apoia a modelagem de composições.

Associações relacionam entidades que podem existir independentemente umas das outras - como autores e livros.

Por outro lado, as composições representam relações contidas e são utilizadas para modelar estruturas do documento. Eles são frequentemente exibidos em cenários de cabeçalho/filho - como pedidos e itens do pedido.

Composição significa que a entidade inferior (itens da ordem) faz parte de um todo e não pode existir independentemente da entidade superior (ordem). A entidade inferior está contida na entidade superior e só pode ser acessada por meio da entidade superior.

A figura Exemplo de uma composição demonstra como as composições são definidas no CDS. A composição exibida define uma relação um para muitos entre ordens e itens da ordem. A sintaxe é muito semelhante à definição de uma associação um-para-muitos. A única diferença é a cláusula Composition of em vez da cláusula Association to de um lado (compare a associação entre autores e livros acima).

Os tempos de execução da PAC tratam composições de forma diferente das associações em alguns aspectos. Entre outras coisas, existem as seguintes características especiais para composições:

• Exclusão em cascata

  A eliminação de uma ordem também resultaria na eliminação de todos os seus itens da ordem devido à relação de composição.

• Inserção profunda

  No serviço OData gerado, uma ordem e os itens da ordem contidos podem ser criados por meio de uma única solicitação POST.

Em seguida, vejamos como as associações podem ser expostas nas interfaces de serviço.

Você pode adicionar associações como elementos regulares à lista de seleção de uma visão (as select from ) ou projeção (as projection on ). Um select * inclui todas as associações.

Figura Expondo Projeções mostra as duas projeções AdminService.Books e AdminService.Autores de nosso cenário, que são expostos via AdminService. A assinatura efetiva da projeção AdminService.Books contém uma associação de autor com as mesmas características que a associação de autor da entidade com.sap.learning.Books. Da mesma forma, a assinatura da projeção AdminService.Authors contém uma associação de livros com as mesmas propriedades que a associação de livros da entidade com.sap.learning.Authors.

O AdminService mostrado na figura Exposição de projeções expõe as duas projeções nas entidades do modelo de dados subjacente.

Ao expor entidades relacionadas, as associações são redirecionadas automaticamente. Isso garante que os clientes possam navegar entre as entidades projetadas como esperado (consulte a figura Associações redirecionadas). Isso significa que AdminService.Authors.books aponta para AdminService.Books - e não para com.sap.learning.Books. Do mesmo modo, AdminService.Books.author se refere a AdminService.Authors - e não a com.sap.learning.Authors.

No serviço OData gerado, as associações publicadas estão disponíveis como características de navegação com o mesmo nome.

A figura Características de navegação geradas mostra o extrato correspondente do documento de metadados de serviço. O tipo de entidade Livros tem um autor de propriedade de navegação e o tipo de entidade Autores tem livros de propriedades de navegação.

Assista ao vídeo para ver como adicionar associações ao Domain Model.

Em seguida, veremos como as definições de entidade podem ser estendidas com novos elementos usando os chamados aspectos.