Construa um modelo de dados sob medida para o seu negócio de telemática com o Business Data Repository

Uma plataforma de telemática geralmente começa com um conjunto conhecido de objetos: veículos, dispositivos, motoristas, cercas virtuais.

As operações reais dos clientes raramente param aí.

Uma empresa de logística também pode precisar de reboques, contratos, depósitos, tipos de carga e registros de manutenção. Uma empresa de locação pode trabalhar com filiais, categorias de equipamento, clientes e unidades de locação. Um integrador de sistemas pode precisar conectar informações de vários sistemas de negócio ao mesmo ativo físico.

É aí que um modelo de dados rígido na plataforma começa a virar um problema.

Você pode colocar um segundo banco de dados ao lado da plataforma de telemática. Pode codificar os dados de negócio em notas e tags. Ou pode construir uma camada de sincronização que fica traduzindo o tempo todo entre o modelo do cliente e o modelo da plataforma.

As três abordagens funcionam. Nenhuma delas envelhece bem.

Pegue um arranjo comum na logística: um caminhão pode trabalhar com reboques diferentes, e cada reboque pode levar seus próprios equipamentos de rastreamento e sensores. A empresa precisa saber não só onde o caminhão está, mas qual reboque está acoplado a ele, quais dispositivos pertencem àquele reboque e quais dados operacionais estão associados a cada parte do conjunto.

Em um modelo de dados rígido, representar essas relações normalmente significa tabelas extras, identificadores duplicados ou lógica de sincronização fora da plataforma de telemática.

O Business Data Repository está sendo construído para modelar essa estrutura diretamente. Um integrador pode definir caminhões, reboques, equipamentos, contratos ou outros objetos de negócio, conectá-los por meio de relações explícitas e estender cada tipo com os atributos que a sua operação exige. A mesma abordagem pode então ser aplicada a uma frota de construção civil, a uma operação de locação, a um negócio de cadeia de frio ou a praticamente qualquer outro modelo específico de cliente.

A GraphQL Repository API é o contrato por trás dessa flexibilidade. Ela dá aos integradores uma forma consistente de definir e trabalhar com essas entidades de negócio conectadas sem esperar por mudanças no esquema da plataforma. Estão planejados SDKs para Kotlin, TypeScript e Python, para deixar o mesmo modelo mais fácil de usar nas linguagens com que os integradores já entregam, além de um servidor MCP previsto sobre as mesmas entidades, para trabalhar com elas a partir da Navixy e de ferramentas externas.

Um contexto importante desde já: a API e o SDK do Business Data Repository ainda não foram lançados publicamente. A documentação atual é uma documentação de prévia (preview), e estruturas ou comportamentos ainda podem mudar antes do lançamento. Então leia isto como a direção do modelo e o motivo pelo qual ela importa, não como um guia de implantação em produção para hoje.

O modelo de operações conectadas

Uma forma útil de pensar a Business Data Repository API é este modelo de cinco camadas:

1. Tipo — defina o formato de objeto que o seu negócio realmente usa.
2. Vínculo — conecte os registros entre si como relações, não como texto solto.
3. Validação — garanta a qualidade dos dados no nível do tipo de campo.
4. Catálogo — padronize os vocabulários controlados uma vez e reutilize em todo lugar.
5. Rastro — mantenha o histórico de mudanças para que o contexto operacional não se perca com o tempo.

Os campos personalizados fazem parte disso, mas são apenas uma das camadas.

Comece pelos objetos de negócio, não apenas pelos padrões da plataforma

Campos personalizados são úteis, mas resolvem só parte do problema.

Às vezes você não precisa de mais um atributo no veículo. Você precisa de outro tipo de objeto no seu modelo operacional.

Por exemplo, um integrador pode precisar representar reboques, embarques, contratos de serviço, unidades de locação ou equipamentos auxiliares como entidades de negócio de primeiro nível, no mesmo ambiente de dados.

A Business Data Repository API é projetada para permitir que um workspace defina seus próprios tipos em duas famílias de objetos: tipos de ativos e tipos de geo-objetos. Tudo o que está na lista acima — um reboque, um embarque, um contrato de serviço, uma unidade de locação, um equipamento — é modelado como um tipo de ativo seu, com seus próprios atributos; zonas, locais e áreas de atendimento são tipos de geo-objetos.

Em vez de forçar “contrato de serviço” dentro de uma nota no veículo ou de manter isso só em uma tabela externa, você pode modelar isso diretamente em uma camada conectada.

Isso não significa que toda conta comece de um modelo em branco. Quando um cliente cria uma conta, ele também pode pré-criar tipos de entidade prontos, como Vehicle e Cargo. Esses tipos já vêm com um conjunto básico de campos, e esse conjunto pode ser estendido como em qualquer outro tipo — a ideia é começar mais rápido, não um esquema travado.

Se você integra para vários setores, isso importa ainda mais. Uma construtora, um operador de cadeia de frio e uma locadora de equipamentos podem usar a mesma plataforma de telemática mantendo modelos de negócio bem diferentes por cima.

Para entender como a Navixy modela ativos tipados hoje, veja o guia de trabalho com ativos.

Conecte registros em vez de guardar IDs como texto puro

Criar registros só é útil se eles puderem ser conectados de forma significativa.

Em muitos sistemas, um campo como reboque acaba guardando um valor de texto como TR-1048. Esse valor pode parecer útil, mas continua sendo apenas uma string. A plataforma não sabe, por si só, se aquele reboque existe, o que ele é, ou o que mais está ligado a ele.

A Repository API é projetada em torno de relações de referência entre registros.

Isso muda o que os integradores podem construir:

• veículo -> reboque
• equipamento -> contrato de serviço
• embarque -> veículo
• ativo -> cliente, representado como uma entrada de catálogo ou um tipo de ativo seu

Uma referência resolve para um registro dentro do seu modelo, então o cliente, o fornecedor ou a equipe responsável desse último exemplo é alguém que você mesmo modelou — uma entrada de catálogo ou um tipo de ativo — e não um login da plataforma. Vale decidir isso cedo, porque isso define como você representa pessoas e organizações em todo o modelo.

Essa é uma distinção técnica com consequências práticas. Quando os vínculos são modelados como relações, e não como texto livre, suas telas operacionais, regras e APIs passam a trabalhar com contexto conectado em vez de fragmentos desconexos.

Adicione atributos que correspondam à função de cada objeto

Com os tipos de objeto definidos, os campos personalizados ficam muito mais valiosos.

Cada tipo pode carregar os atributos relevantes para ele, em vez de todos dividirem um único balde universal de “campos extras”.

Um reboque pode precisar de número do chassi, limites de carga e datas de inspeção. Um contrato de serviço pode precisar de número do contrato, datas de vigência e status. Uma unidade de locação pode precisar de campos de utilização e de entrega.

O contrato atual de prévia define um sistema de campos tipados com comportamento de validação (por exemplo, limites de tamanho para textos, restrições numéricas para decimais e valores restritos para opções/referências). Isso permite que o modelo imponha parte da lógica de negócio, em vez de empurrar toda a validação para cada aplicação cliente.

Uma decisão desse desenho é definitiva, e vale planejar em torno dela: o tipo de um campo fica fixo no momento em que o campo é criado. Títulos, limites de validação e obrigatoriedade continuam editáveis, e um campo que você parou de usar pode ser arquivado e restaurado.

O tipo é a exceção — mudar um campo de texto para referência, ou de número para lista de opções, significa excluir a definição e criar uma nova, e os valores já gravados sob a definição antiga ficam para trás nos dados armazenados, sem nada que os sustente. Trate a escolha do tipo como você trataria o tipo de uma coluna em um esquema que não dá para migrar: para um integrador que projeta um modelo que os clientes vão preencher com registros reais, essa é a decisão mais cara desta página.

Para os detalhes mais recentes conforme a prévia evolui, veja Implementação de campos personalizados.

Use catálogos para manter a linguagem do negócio consistente

Muitos atributos de negócio vêm de vocabulários controlados: fabricantes, categorias de serviço, classes de carga, estruturas de filiais, centros de custo.

Sem catálogos, as equipes normalmente acabam convivendo com variações de grafia:

• Bosch
• BOSCH
• Bosch GmbH

A Business Data Repository API inclui estruturas de catálogo definidas pelo usuário, para que esses valores sejam normalizados uma vez e reutilizados nos objetos relacionados.

Conforme a modelagem específica de cada cliente cresce, esse é um dos maiores multiplicadores de qualidade: menos limpeza de dados, menos divergências e menos bugs de integração do tipo “a mesma coisa, escrita de três formas”.

Guarde o contexto das mudanças, não apenas o estado atual

Em fluxos de trabalho operacionais, o valor atual muitas vezes não basta.

A pergunta comum não é “que valor esse objeto tem agora?”, e sim “que valor ele tinha quando esse evento aconteceu?”.

A Business Data Repository API inclui contexto de mudança orientado a histórico/auditoria das entidades, para que os integradores construam interfaces em que a linha do tempo e a procedência importam, não apenas o estado mais recente.

Para operações internas, processos regulados, investigação de incidentes e ferramentas administrativas voltadas ao cliente, isso pode ser bem mais útil do que um conjunto plano de campos editáveis.

Dê conta das operações comuns de telemática com menos código de integração

Os integradores costumam gastar tempo em tarefas operacionais repetidas que ficam entre o “CRUD simples” e motores completos de fluxo de trabalho.

Um bom exemplo é a troca de dispositivo. Quando um rastreador é movido de um ativo para outro, o modelo de dados deve suportar essa mudança de relação de forma limpa, em vez de forçar uma lógica de sincronização frágil e de várias etapas em torno de IDs soltos.

O mesmo vale para situações com vários dispositivos, em que um dos dispositivos acoplados precisa ficar claramente marcado como principal.

Isoladamente, essas não são promessas de destaque. Mas refletem a mesma direção de projeto: modelar as relações operacionais diretamente, em vez de fazer cada integrador reconstruí-las em torno de identificadores desconexos.

Por que GraphQL combina com esse modelo

A Business Data Repository API usa GraphQL, que combina bem com a modelagem de dados conectados.

Os integradores podem pedir exatamente os campos e os objetos relacionados de que uma interface precisa, em vez de recolher payloads completos de vários endpoints fixos e costurá-los depois.

Para produtos interativos — consoles de operação, portais de clientes, ferramentas internas, interfaces administrativas — isso normalmente significa menos sobrecarga de transporte e uma lógica de aplicação mais limpa.

A conclusão mais ampla

Sistemas de telemática vivem dentro de operações de negócio mais amplas. Veículos estão conectados a reboques. Equipamentos pertencem a locais. Ativos estão ligados a contratos e a estruturas de clientes. Essas relações são específicas de cada empresa.

A Business Data Repository API está sendo construída para tornar esse contexto de negócio modelável: defina as estruturas de que você precisa, conecte-as, valide-as e acompanhe como elas evoluem.

Para os integradores, o ganho prático é direto: menos tempo brigando com um esquema fixo do fornecedor e mais liberdade para modelar como o cliente realmente conduz a operação.

Se você quer acompanhar como esse modelo evolui antes do lançamento, comece pelo índice da documentação da Business Data Repository API e acompanhe as atualizações nos guias de prévia, incluindo o comportamento de filtragem/ordenação de campos personalizados na referência de filtragem de campos personalizados.