Relacionamentos de tabelas no App Builder

Introdução

Uma vez que você tenha criado as tabelas do seu aplicativo, pode definir relacionamentos entre elas. Um relacionamento conecta duas tabelas com base em dados correspondentes em uma ou mais colunas.

Os relacionamentos de tabelas oferecem as seguintes vantagens:

• Os relacionamentos permitem que você imponha a integridade dos dados no nível do banco de dados. Por exemplo, ao vincular uma tabela de Pedidos a uma tabela de Clientes, você pode impedir que um usuário crie um pedido para um cliente que não existe. Você também pode definir regras que determinam o que acontece com os registros relacionados quando um registro é atualizado ou excluído.

• Quando o App Builder sabe como as tabelas estão relacionadas, ele melhora automaticamente a interface do usuário para criar uma experiência mais intuitiva. Por exemplo, quando a tabela Pedido inclui uma coluna CustomerID:

  • Sem um relacionamento, ao construir uma página para criar um novo pedido, o App Builder gera uma caixa de texto simples para o CustomerID. O usuário precisa saber e inserir manualmente o ID correto do cliente.

  • Com um relacionamento entre a coluna CustomerID da tabela Pedido e a tabela Cliente, o App Builder entende a conexão. Em vez de uma caixa de texto, ele gera automaticamente uma lista suspensa ou controle de pesquisa na página do pedido. Este controle será preenchido com os nomes amigáveis dos clientes (da coluna Título designada da tabela Cliente), em vez de seus IDs.

Como criar e gerenciar relacionamentos

Embora as tabelas possam ser criadas usando o Assistente de Tabelas, os relacionamentos são gerenciados na aba Tabelas dentro do App Workbench. A partir daí, você pode selecionar uma tabela e, em seguida, definir seus relacionamentos com outras tabelas. O App Builder pode frequentemente sugerir relacionamentos de chave estrangeira, que você pode então confirmar.

Ao definir um relacionamento, você também pode especificar regras que ditam como o App Builder mantém a integridade dos dados quando um registro na tabela pai (o lado "um" de um relacionamento um-para-muitos) é atualizado ou excluído. (Por exemplo, o que deve acontecer com os pedidos de um cliente se esse registro de cliente for excluído?) Essas são conhecidas como regras de cascata. As opções são as seguintes:

• Regra On Delete:

  • Cascata: Se um registro pai for excluído, todos os seus registros filhos relacionados também são excluídos. (Por exemplo, excluir um cliente também exclui todos os seus pedidos).

  • Padrão: Se um registro pai for excluído, o valor na coluna de chave estrangeira correspondente dos registros filhos (referenciando) é definido como o valor padrão da coluna. Essa ação requer que um valor padrão seja definido na coluna de chave estrangeira.

  • Nulo: Se um registro pai for excluído, o valor da chave estrangeira nos registros filhos relacionados é definido como NULL. Isso requer que a coluna de chave estrangeira na tabela filha permita valores NULL. (Por exemplo, os pedidos permanecem, mas não estão mais associados a esse cliente).

  • Prevenir: Impede que o registro pai seja excluído se ele tiver algum registro filho associado. Esta é frequentemente a opção padrão mais segura.

• Regra On Update:

  • Esta regra se aplica se o valor da chave primária do registro pai for alterado. As opções são as mesmas da regra On Delete.

Qual regra você escolher depende da sua lógica de negócios e de como deseja gerenciar seus dados.