Relações entre tabelas e caminhos de tabelas

Os dados dos clientes são muitas vezes espalhados por várias tabelas. É fundamental que estes dados estejam ligados entre si para que possa aproveitá-los para os seus cenários. Por exemplo, tem uma tabela para utilizadores, encomendas, detalhes da encomenda e produtos. Digamos que pretende um segmento de todos os utilizadores que fizeram uma encomenda recentemente. Para criar este segmento, não pode utilizar a tabela Utilizadores sozinha, mas precisaria da tabela Encomendas e da tabela Utilizadores. A tabela Utilizadores e Encomendas tem de estar ligada entre si com uma chave como userId. As relações no Customer Insights - Data permitem-lhe associar as suas tabelas, permitindo-lhe utilizar todos os seus dados através de segmentos, medidas e outros processos do Customer Insights - Data.

As relações definem um gráfico dos seus dados quando as tabelas partilham um identificador comum, uma chave externa. Esta chave externa pode ser referenciada de uma tabela para outra. A relação consiste numa tabela de origem que contém a chave externa e uma tabela de destino para a qual aponta a chave externa da tabela de origem.

Existem três tipos de relações:

• As relações de sistema não editáveis são criadas pelo sistema como parte do processo de unificação de dados
• As relações herdadas não editáveis são criadas automaticamente a partir da ingestão de origens de dados
• As relações personalizadas editáveis são criadas e configuradas pelos utilizadores

Relações de sistema não editáveis

Durante a unificação de dados, as relações de sistema são criadas automaticamente com base em correspondência inteligente. Estas relações ajudam a relacionar os registos do perfil de cliente com outros registos correspondentes. O diagrama que se segue ilustra a criação de três relações baseados em sistema. A tabela de cliente é compatível com outras tabelas para produzir a tabela unificada de Cliente.

• A relação CustomerToContact foi criada entre a tabela Cliente e a tabela Contacto. A tabela Cliente obtém o campo de chave Contact_contactID para se relacionar com o campo de chave da tabela Contacto contactID.
• A relação CustomerToAccount foi criada entre a tabela Cliente e a tabela Conta. A tabela Cliente obtém o campo de chave Account_accountID para se relacionar com o campo de chave da tabela Conta accountID.
• A relação CustomerToWebAccount foi criada entre a tabela Cliente e a tabela WebAccount. A tabela Cliente obtém o campo de chave WebAccount_webaccountID para se relacionar com o campo de chave da tabela WebAccount webaccountID.

Relações herdadas não editáveis

Durante o processo de ingestão de dados, o sistema verifica as origens de dados para relações existentes. Se não existe qualquer relação, o sistema cria-as automaticamente. Estas relações também são utilizadas em processos a jusante.

Criar uma relação personalizada

As relações personalizadas permitem-lhe ligar duas tabelas que podem depois ser utilizadas em conjunto em segmentos e medidas a jusante.

Por exemplo, pretende criar um segmento de todos os clientes que compraram café numa loja em Nova Iorque. Os dados são armazenados em três tabelas:

• loyaltyContacts: contém uma lista de todos os clientes. As colunas incluem LoyaltyId e FullName.
• Purchases: contém o histórico de compras de todos os clientes. As colunas incluem Timestamp, LoyaltyId, PurchasePrice e StoreId.
• Stores: contém mais detalhes sobre cada loja. As colunas incluem StoreId, StoreSize e StoreLocation. Para este exemplo, crie uma relação personalizada entre Purchases e Stores como uma relação muitos (compras) para um (lojas) na coluna StoreId. Após estabelecidas, pode criar o segmento necessário adicionando um filtro na coluna StoreLocation na tabela Stores.

1. Aceda a Dados>Tabelas.

2. Selecione o separador Relações.

3. Entidade de destino Nova relação.

4. No painel Nova relação, forneça as seguintes informações:

   

   • Nome da relação: nome que reflete o propósito da relação. Os nomes das relações são sensíveis a maiúsculas e minúsculas. Exemplo: PurchasesToStores.

   • Descrição: descrição da relação.

   • Tabela de origem: a tabela que é utilizada como a origem na relação. Exemplo: Purchases.

   • Tabela de destino: a tabela que é utilizada como o destino na relação. Exemplo: Stores.

   • Cardinalidade de origem: cardinalidade da tabela de origem. Cardinalidade descreve o número de elementos possíveis num conjunto. Está sempre relacionado com a cardinalidade de destino. Pode escolher entre Um e Muitos. Só são suportadas relações muitos-para-um e um-para-um.

     • Muitos-para-um: vários registos fornecidos com o programa podem relacionar-se com um registo de destino. Exemplo: várias compras de uma única loja.
     • Um-para-um: um único registo fornecido com o programa relaciona-se com um registo de destino.

     Nota

     É possível criar relações muitos-para-muitos utilizando duas relações muitos-para-um e uma tabela de ligação, a qual liga a tabela fornecida com a tabela de destino.

   • Cardinalidade de destino: cardinalidade dos registos da tabela de destino.

   • Campo de chave de origem: campo de chave externa na tabela de origem. Exemplo: StoreId

   • Campo de chave de destino: campo de chave da tabela de destino. Exemplo: StoreId

5. Selecione Guardar para criar a relação personalizada.

Gerir relações existentes

Aceda a Dados>Tabelas e o separador Relações para ver todas as relações que foram criadas, a respetiva tabela de origem, a tabela de destino e a cardinalidade.

Utilize as opções Filtrar por ou Procurar relações para localizar uma relação específica. Para ver um diagrama de rede das relações existentes e a respetiva cardinalidade, selecione Visualizador.

Selecione uma relação para ver as ações disponíveis:

• Editar: atualize as propriedades de relações personalizadas no painel de edição e guarde as alterações.
• Eliminar: elimine relações personalizadas.
• Ver: veja relações criadas pelo sistema e herdadas.

Explore o visualizador de relações

O visualizador de relações mostra um diagrama de rede de relações existentes entre as tabelas ligadas e a respetiva cardinalidade. Também visualiza o caminho da relação.

Para personalizar a vista, pode alterar a posição das caixas arrastando-as na tela. Outras opções incluem:

• Exportar como imagem: guarde a vista atual como um ficheiro de imagem.
• Alterar para esquema horizontal/vertical: altere o alinhamento das tabelas e relações.
• Editar: atualize as propriedades de relações personalizadas no painel de edição e guarde as alterações.

Caminhos da relação

Um caminho da relação descreve as tabelas que estão ligadas a relações entre uma tabela de origem e uma tabela de destino. É usado na criação de um segmento ou uma medida que inclui outras tabelas que não a tabela de perfil unificado e existem múltiplas opções para chegar à tabela de perfil unificado. Diferentes caminhos de relações podem produzir resultados diferentes.

Por exemplo, a tabela eCommerce_eCommercePurchases tem as seguintes relações com a tabela de Cliente de perfil unificado:

• eCommerce_eCommercePurchases > Cliente
• eCommerce_eCommercePurchases > eCommerce_eCommerceContacts > POS_posPurchases > Cliente
• eCommerce_eCommercePurchases > eCommerce_eCommerceContacts > POS_posPurchases > loyaltyScheme_loyCustomers > Cliente

Um caminho de relação determina que tabelas pode usar ao criar regras para medidas ou segmentos. Escolher a opção com o caminho de relação mais longo provavelmente produzirá menos resultados porque os registos correspondentes precisam de fazer parte de todas as tabelas. Neste exemplo, um cliente tem de ter comprado bens através de comércio eletrónico (eCommerce_eCommercePurchases), num ponto de venda (POS_posPurchases) e participar no nosso programa de fidelização (loyaltyScheme_loyCustomers). Ao escolher a primeira opção, provavelmente obteria mais resultados porque os clientes só precisam de existir numa outra tabela.

Relação direta

Uma relação é classificada como uma relação direta quando uma tabela de origem se relaciona com uma tabela de destino com apenas uma relação.

Por exemplo, se uma tabelas de atividade chamada eCommerce_eCommercePurchases se ligar a uma tabela de destino eCommerce_eCommerceContacts apenas através de ContactId, é uma relação direta.

Relação de múltiplos caminhos

Uma relação de múltiplos caminhos é um tipo especial de relação direta que liga uma tabela de origem a mais do que uma tabela de destino.

Por exemplo, se uma tabela de atividade chamada eCommerce_eCommercePurchases se relacionar com duas tabelas de destino, tanto eCommerce_eCommerceContacts como loyaltyScheme_loyCustomers, é uma relação de múltiplos caminhos.

Relação indireta

Uma relação é classificada como uma relação indireta quando uma tabela de origem se relaciona com uma ou mais outras tabelas antes de se relacionar com a tabela de destino.

Relação de múltiplos saltos

Uma relação de múltiplos saltos é uma relação indireta que lhe permite ligar uma tabela de origem a uma tabela de destino através de uma ou mais outras tabelas intermediárias.

Por exemplo, se uma tabela de atividade chamada eCommerce_eCommercePurchasesWest se ligar a uma tabela intermediária chamada eCommerce_eCommercePurchasesEast e, em seguida, se ligar a uma tabela de destino chamada eCommerce_eCommerceContacts, é uma relação de múltiplos saltos.

Relação de de múltiplos saltos, múltiplos caminhos

Relações de múltiplos saltos e de múltiplos caminhos podem ser usadas em conjunto para criar relações de múltiplos saltos e de de múltiplos caminhos. Este tipo especial combina as funções de Relações de múltiplos saltos e de múltiplos caminhos. Permite ligar a mais de uma tabela de destino enquanto utiliza tabelas intermediárias.

Por exemplo, se uma tabela de atividade chamada eCommerce_eCommercePurchasesWest se ligar a uma tabela intermediária chamada eCommerce_eCommercePurchasesEast e, em seguida, se ligar a duas tabelas de destino, ao eCommerce_eCommerceContacts e ao loyaltyScheme_loyCustomers, é uma relação de múltiplos saltos, múltiplos caminhos.

Próximo passo

Relações de sistema e personalizados são usadas para criar segmentos e medidas com base em múltiplas origens de dados que já não são colocadas em silo.