Esquema e mapeamento da tabela RDBMS

O diagrama a seguir mostra as tabelas e os relacionamentos no esquema RDBMS de origem.

Conforme mostrado no diagrama anterior, a production_apps tabela tem version colunas id e, que têm uma one-to-many relação com as production_app_configs tabelas production_app_properties e. Portanto, no design do DynamoDB, production_app_properties as tabelas production_app_configs e são incorporadas ao, conforme mostrado production_app item no código JSON a seguir. Como production_app_properties e production_app_configs podem ter vários valores, essas tabelas são adicionadas como matrizes no código JSON. As test_apps tabelas changed_apps e são mapeadas de forma semelhante.

Design de tabela única

O DynamoDB não mantém relacionamentos; ele oferece suporte a um esquema de tabela fixo. Como resultado, você pode armazenar diferentes tipos de itens (como tabelas SQL) em uma única tabela do DynamoDB, com um atributo ItemType () que identifica o tipo de item.

No DynamoDB, a combinação de chaves de partição (PK) e chaves de classificação (SK) deve ser exclusiva, portanto, essas chaves variam de acordo com o tipo de item.

Índices secundários globais

Os índices ajudam a recuperar dados mais rapidamente e a melhorar o desempenho do aplicativo. Para o aplicativo de amostra, os índices a seguir foram criados. Os PKs e SKs foram escolhidos com base em como itens distintos poderiam ser identificados.

Nome do índice	Descrição	Chave de partição (PK)	Chave de classificação (SK)	Atributos_projetados
Version-index	Obtém todos os aplicativos de produção de um determinadoversion.	version		id, name
Release-index	Obtém todos os aplicativos de teste de um determinadorelease-id.	release-id		id, name
Change-index	Obtém todos os aplicativos (alterados) associados a umchange-id.	change-id		id, modified-by, date