# 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![]()
```sql 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.