--- title: Modelo de objetos e relações slug: modelo-de-objetos-y-relaciones description: >- Como a taxonomia, os objetos de governança e as fontes técnicas se relacionam no GovFrame. audiencia: >- Administrador | Responsável pelos dados | Curador de dados | Engenheiro de dados | Usuário | Superadministrador roles: >- Consulta para todos os perfis autenticados; administração conforme capacidades e escopo modulo: Referência transversal estado: Comportamento atual validado revision: '2026-10-19' section: explicaciones order: 10 sources: - Modelodeobjetosyrelaciones.md locale: pt-br --- # Modelo de objetos e relações O GovFrame usa a **taxonomia como espinha dorsal**. A taxonomia organiza o contexto de negócio; os demais objetos se relacionam com um ou mais níveis para explicar o significado de um dado, quem é responsável por ele, onde está, como é controlado e como é publicado. Esta página responde a duas perguntas: 1. Em que nível taxonômico cada objeto se relaciona? 2. Como os objetos de negócio, técnicos e operacionais se conectam entre si? ## 1. A taxonomia é o eixo de navegação O tenant pode trabalhar com um destes modelos: ```text Taxonomia padrão: Domínio → Entidade → Atributo Taxonomia expandida: Domínio → Subdomínio → Entidade → Atributo ``` | Nível | O que representa | O que costuma depender dele | |---|---|---| | **Domínio** | Grande escopo de negócio e responsabilidade. | Escopo de usuários, responsabilidades, produtos, contratos, políticas e objetos de alto nível. | | **Subdomínio** | Divisão opcional do Domínio. | Escopo mais preciso, Entidades, produtos, contratos, políticas e casos operacionais. | | **Entidade** | Conceito ou objeto de negócio. | Atributos, Termos, funções de governança, Repositórios herdados e dados não estruturados. | | **Atributo** | Elemento de informação dentro de uma Entidade. | Regras de qualidade, Campos do Dicionário técnico, classificações e contratos. | Um objeto pode ter uma **associação direta** com um nível ou chegar a ele por meio de uma relação derivada. Por exemplo, um Campo técnico aponta diretamente para um Atributo; o Domínio é obtido percorrendo Atributo → Entidade → (Subdomínio) → Domínio. ## 2. Regra de associação direta e herdada - **Direta:** o registro armazena explicitamente o vínculo com o nível taxonômico. Exemplo: um Produto armazena `domainId` e, opcionalmente, `subdomainId`. - **Por componente:** o vínculo é armazenado em uma relação reutilizável que permite associar um objeto a um ou mais nós. Exemplo: um Repositório pode ser associado a vários Domínios ou Subdomínios. - **Herdada:** o sistema calcula o contexto a partir de um objeto filho. Exemplo: uma Regra de qualidade herda o Domínio e o Subdomínio do Atributo ao qual pertence. - **Derivada por composição:** um Contrato pode chegar a Atributos, Regras, Campos e Termos por meio de suas tabelas de associação, embora seu escopo principal seja Domínio/Subdomínio. A associação herdada não altera o nível original do objeto. Ela serve para filtros, autorização, navegação, cobertura e análise de impacto. ## 3. Matriz de objetos e níveis de relação | Objeto | Associação principal atual | Nível de relação | Relações relevantes | |---|---|---|---| | **Termo de negócio** | Domínio e vínculos com uma ou várias Entidades. | Domínio ou Entidade; pode ser vinculado por meio de componentes a outros nós. | Define a linguagem de negócio; pode fazer parte de um Contrato e documentar um KPI. | | **Função de governança** | Domínio e vínculos com Entidades. | Domínio e Entidade. | Representa a responsabilidade de Responsável pelos dados/Curador de dados ou outra responsabilidade; pode ser responsável por um Produto ou Contrato. | | **Regra de qualidade** | Atributo. | Atributo, com contexto herdado de Entidade, Subdomínio e Domínio. | Usa uma Dimensão; é associada a Campos técnicos válidos e pode fazer parte de Contratos e Workflows. | | **Campo do Dicionário técnico** | Atributo e Repositório. | Atributo; o Repositório fornece o contexto físico. | Armazena esquema, tabela, coluna, tipo e características físicas; materializa um vínculo com a fonte. | | **Repositório de dados** | Um ou vários Domínios/Subdomínios por meio de associações de alto nível; pode manter a Entidade herdada. | Domínio/Subdomínio; opcionalmente Entidade, por compatibilidade ou contexto legado. | Conecta-se por meio de um Conector; contém metadados, snapshots e Campos do Dicionário técnico; pode pertencer a um Sistema. | | **Sistema de informação** | Um ou vários Domínios/Subdomínios por meio de associações de alto nível; pode manter a Entidade herdada. | Domínio/Subdomínio; opcionalmente Entidade, por contexto legado. | Relaciona-se com Repositórios, Produtos e Contratos. | | **Dados não estruturados** | Entidade e/ou associação de componente. | Entidade, com Domínio/Subdomínio herdado. | Pode ser um ativo de arquitetura e participar de relações de governança. | | **Ativo de dados** | Domínio. | Domínio; pode receber associações adicionais de taxonomia. | Pode fazer parte de um Produto e ser certificado, classificado ou comentado. | | **Produto de dados** | Domínio e Subdomínio opcional. | Domínio/Subdomínio. | Agrupa Ativos e relaciona-se com um Responsável pelos dados e com Contratos. | | **Contrato de dados** | Domínio, Subdomínio e Responsável pelos dados. | Domínio/Subdomínio. | Inclui Atributos, Regras de qualidade, Campos do Dicionário, Termos, Sistemas e Produto. | | **Política, Processo e Procedimento** | Domínio/Subdomínio opcionais. | Domínio/Subdomínio. | Mantêm a hierarquia Política → Processo → Procedimento, versões, responsáveis e aprovações. | | **Objetivo** | Domínio/Subdomínio opcionais. | Domínio/Subdomínio. | Relaciona-se com um ou vários KPIs e mantém medições e revisões. | | **KPI ou Key Result** | Nível primário explícito: Domínio, Subdomínio, Entidade ou Atributo. | Qualquer um dos quatro níveis. | Pode ter vínculos secundários com taxonomia e Termos, Ativos, Regras, Dicionário, Repositórios, Sistemas, Produtos e Contratos. | | **Workflow e caso** | Domínio/Subdomínio opcionais e objeto-alvo. | Contexto direto ou derivado do objeto afetado. | Um caso pode apontar para qualquer objeto do ecossistema; suas tarefas, decisões, evidências e notificações dependem do caso. | | **Solicitação de acesso** | Objeto solicitado e caso de Workflow. | É derivada do objeto: tabela, dashboard, dataset ou outro destino permitido. | Pode agrupar várias solicitações, ter aprovação parcial, mascaramento e provisionamento. | | **Stewardship** | Atribuições de Responsável pelos dados, escopos, classificações, certificações, comentários e tarefas. | É resolvida a partir do objeto-alvo e de seu contexto taxonômico. | Acrescenta responsabilidade e estado sem substituir a relação taxonômica do objeto. | ### Riscos e controles: precisão do modelo atual Na implementação atual, não existe um módulo de catálogo independente chamado **Riscos** ou **Controles** com tabelas próprias equivalentes às de Termos ou Regras. O controle é representado por combinações de objetos existentes, por exemplo: - uma Regra de qualidade como controle técnico; - uma Política/Procedimento como controle normativo; - um Workflow, tarefa ou aprovação como controle operacional; - uma Regra incluída em um Contrato como compromisso verificável; - uma classificação, certificação ou tarefa de stewardship como acompanhamento. A interface pode exibir riscos, alertas ou cobertura derivados do dashboard e de tarefas, mas esta documentação não os apresenta como um inventário independente até que esse módulo e seu contrato de dados existam. ## 4. Como o ecossistema se forma O fluxo funcional típico é: ```text Taxonomia ↓ Responsáveis e escopo ↓ Termos de negócio ───────────────┐ ↓ │ Entidades e Atributos │ ↓ │ Dicionário técnico ← Repositório ← Conector / fonte ↓ Regras de qualidade ────────────┐ │ ↓ │ │ Produto de dados ← Ativos ←────┘ │ ↓ │ Contrato de dados ← Termos, Atributos, Regras, Campos, Sistemas ↓ Workflows, solicitações, tarefas, aprovações e auditoria ``` Os KPIs e Objetivos atravessam o ecossistema: adotam um nível taxonômico primário e podem documentar sua fórmula, fonte de medição, controle, evidência, produto ou contrato por meio de vínculos tipados. ## 5. Como ler uma relação na interface 1. Comece pelo Domínio ou Subdomínio para entender o contexto e o escopo. 2. Avance até a Entidade e o Atributo para encontrar o significado preciso. 3. A partir de um Atributo, consulte as Regras de qualidade e os Campos do Dicionário técnico. 4. A partir do Campo, identifique o Repositório, o esquema, a tabela, a coluna e o Sistema, quando estiverem registrados. 5. Percorra Produtos e Contratos para entender o que é entregue, a quem e com quais compromissos. 6. Use Workflows, tarefas e solicitações para acompanhar decisões pendentes, alterações e acessos. O Explorador de relações tem três perspectivas: **Visão geral** para descobrir, **Impacto** para analisar dependências e **Detalhe técnico** para acompanhar o vínculo entre a taxonomia e as fontes físicas. O guia de uso está em [Como ler o mapa de relações](/pt-br/guias/como-leer-mapa-de-relaciones/). ## 6. Limites importantes - Todas as relações são isoladas por empresa e devem respeitar o escopo do usuário. - Os códigos técnicos identificam registros, mas os guias funcionais devem exibir nomes legíveis. - Uma associação de alto nível não significa que todos os Campos de uma fonte estejam associados a todos os Atributos. - Uma Regra de qualidade só gera SQL quando tem associações válidas a Campos físicos. - Desativar um módulo oculta e bloqueia sua operação para o tenant, mas não exclui automaticamente seus dados. ## Conteúdo relacionado - [Funções, capacidades e escopo](/pt-br/referencia/roles-capacidades-y-alcance/) - [Módulos e dependências](/pt-br/referencia/modulos-y-dependencias/) - [Como ler o mapa de relações](/pt-br/guias/como-leer-mapa-de-relaciones/) - [Índice oficial](/pt-br/)