Banco de Dados


Guia de Consulta

Visão Geral

O Dommus é composto por múltiplos módulos, e cada módulo possui o seu próprio banco de dados. Além dos bancos individuais, existe um banco central chamado GU (General User), responsável por armazenar informações globais da plataforma, como usuários cadastrados e permissões de acesso.

Estrutura dos Bancos de Dados por Módulo

Cada módulo segue uma convenção de nomenclatura própria para o banco e para as tabelas. Abaixo estão os principais:

Módulo Vendas O banco de dados do módulo Vendas segue o padrão DOMMUS_NOMEDOCLIENTE. As tabelas deste banco utilizam o prefixo tb_, por exemplo: tb_equipe, tb_processo, tb_unidade. A separação entre palavras é feita sempre com underscore (_), sem espaços ou pontuações especiais.

Módulo CRM O banco de dados do CRM segue o padrão CRM_INQUILINO_00IDDOINQUILINODOCLIENTE. As tabelas deste banco não utilizam o prefixo tb_, por exemplo: oferta_ativa. A separação entre palavras também segue o padrão underscore, sem espaços ou pontuações.

Módulo Conecta O banco de dados do Conecta segue o padrão DOMMUS_CA_INQUILINO_00ID_INQUILINO_CLIENTE. As tabelas deste banco utilizam o prefixo tb_, por exemplo: tb_perfil.

Módulo Desk O banco de dados do Desk segue o padrão DESK_INQUILINO_00ID_INQUILINO_CLIENTE. As tabelas deste banco não utilizam o prefixo tb_, por exemplo: ticket_status.

Banco GU (Geral) O banco GU é o repositório central de informações da plataforma. Nele estão armazenados todos os usuários cadastrados no Dommus, acessíveis pela tabela dommus_homolog_gu.tb_usuario. Este banco serve de referência para validações de acesso e permissões em qualquer módulo.

Regra Geral de Nomenclatura de Tabelas

Independentemente do módulo, todas as tabelas seguem a seguinte convenção: a separação de palavras é sempre feita por underscore (_), nunca por espaços, pontos, hífens ou qualquer outro caractere especial.

Chaves Primárias e Secundárias

Todos os bancos de dados da Dommus são compostos por chaves primárias e chaves secundárias (estrangeiras). Isso significa que uma tabela pode conter o ID de outra tabela como referência, permitindo filtrar registros sem precisar conhecer o ID principal da tabela.

Por exemplo, na tb_processo existe o campo referente ao ID da unidade. Isso permite buscar todos os processos de uma unidade antes mesmo de saber o ID do processo. Exemplo de consulta:

sql
Copiar
SELECT * FROM tb_processo WHERE unidade = 12323;

Para obter o ID da unidade, é necessário consultá-la previamente na tb_unidade, buscando pela informação desejada.

Fluxo de Validação por Módulo

Quando um cliente reporta um problema relacionado a um módulo específico, a validação deve ser feita no banco correspondente. O módulo reportado pelo cliente indica onde a consulta deve ser realizada.

Exemplo prático — Cliente com problema de login no CRM:

  1. Validação 1 — Verificar se o cliente está habilitado para o módulo CRM.
  2. Validação 2 — Consultar a tabela tb_cliente_modulo_usuario no banco dommus_homolog_gu.
  3. Validação 3 — Verificar o perfil_usuario diretamente no banco do CRM do cliente.

Tabelas Importantes no Módulo Vendas

tb_referencia_integracao — Esta tabela é responsável por referenciar a relação entre o Dommus e uma integração externa, como um ERP Financeiro ou uma plataforma de Assinatura Digital. Quando há uma integração ativa, é nesta tabela que está registrado o vínculo entre os dois sistemas.

tb_atividade_parceiro — Esta tabela registra os retornos de erros de integrações. Quando ocorre uma falha em uma operação integrada (por exemplo, ao tentar enviar um contrato para assinatura digital), o log de erro correspondente estará registrado nesta tabela. É o primeiro lugar a ser consultado para diagnosticar problemas de integração.

Se quiser, posso complementar com mais tabelas, adicionar exemplos de queries ou formatar de forma diferente para se adequar melhor ao padrão do duvidas.dommus.com.br.