---
title: Definir regras de qualidade
description: >-
  Documente regras associadas a Atributos, dimensões e campos físicos, com
  limites e SQL somente quando houver suporte técnico válido.
audiencia: >-
  Administrador | Responsável pelos dados | Curador de dados | Engenheiro de
  dados
roles: >-
  Administrador; Responsável pelos dados e Curador de dados dentro do escopo;
  Engenheiro de dados para contexto técnico autorizado
modulo: Regras de qualidade
revision: '2026-10-19'
section: gobernar-datos
order: 30
sources:
  - CONTEXT.md
  - Modelodeobjetosyrelaciones.md
  - 'Roles,capacidadesyalcance.md'
  - Módulosydependencias.md
  - Cómoleerelmapaderelaciones.md
locale: pt-br
---
# Definir regras de qualidade

Uma Regra de qualidade expressa um controle sobre um **Atributo** da taxonomia. No GovFrame, ela pode documentar uma dimensão, uma expressão, um limite e uma frequência. Seu contexto de Domínio, Subdomínio e Entidade é obtido do Atributo associado: a regra continua sendo um objeto de nível Atributo, mesmo quando aparece em filtros de níveis superiores.

A regra pode se relacionar com campos do Dicionário técnico e participar de um Contrato de dados. Essa associação conecta o controle de negócio a uma fonte física registrada. O SQL só é gerado a partir de associações válidas a campos físicos e de um dialeto configurado; sem ambos os elementos, a Regra pode existir como definição de governança, mas não deve ser apresentada como SQL gerado nem como validação executável.

## Antes de começar

- **Papel e escopo:** o Administrador tem escopo global na empresa. Responsáveis pelos dados e Curadores de dados precisam da capacidade de negócio correspondente e de escopo sobre o Domínio ou Subdomínio herdado pelo Atributo. O Engenheiro de dados administra o contexto técnico somente nos Repositórios incluídos em seu escopo técnico.
- **Módulo:** confirme se **Regras de qualidade** está ativo. Para trabalhar com associações físicas, **Dicionário técnico** e **Repositórios de dados** também são relevantes, pois são dependências declaradas do módulo.
- **Pré-requisitos:** disponha de uma taxonomia com o Atributo desejado. Se a intenção for gerar SQL, deve existir um campo físico associado no Dicionário técnico e o dialeto correspondente deve estar configurado. Identifique a dimensão, a expressão de controle e o limite que o negócio possa explicar.

> **Exemplo sintético:** para o Atributo **E-mail de contato**, uma regra de completude pode declarar que o valor não deve ficar vazio e registrar o limite acordado. Só poderá gerar SQL se estiver vinculada a um campo físico válido e houver um dialeto configurado para esse contexto.

## Percurso recomendado

1. **Comece pelo Atributo, não por uma tabela isolada.** Selecione o Atributo cujo significado deve ser protegido e verifique sua Entidade e seu Domínio. Isso permite que o controle tenha uma responsabilidade e um escopo de negócio inequívocos.
2. **Descreva o controle.** Registre um nome legível, a dimensão de qualidade, a expressão, o limite e a frequência correspondentes à definição vigente. Evite nomear uma Regra apenas com o nome de uma coluna, pois o mesmo nome físico pode ter contextos distintos.
3. **Verifique a associação técnica.** Quando necessário, relacione a Regra ao campo do Dicionário técnico que materializa o Atributo. Verifique se a associação física documenta o Repositório, esquema, tabela, coluna e tipo correspondentes; uma relação com o Repositório, por si só, não associa todas as suas colunas.
4. **Trate o SQL como um artefato condicionado.** Solicite SQL somente quando a associação do campo for válida e o dialeto estiver configurado. O resultado é SQL gerado para a Regra, não uma promessa de execução automática, conexão à fonte ou resultado de qualidade.
5. **Relacione compromissos e acompanhamento.** Se a Regra for relevante para uma entrega, associe-a ao Contrato de dados correspondente. É possível manter históricos, estados e scripts SQL versionados com auditoria, mas este guia não define valores de estado nem um fluxo de trabalho de aprovação.
6. **Revise o contexto quando os metadados mudarem.** Os metadados podem gerenciar prévias, agendamento manual/diário/semanal/mensal e snapshots versionados. O agendamento e qualquer automação efetiva dependem da configuração da empresa; não presuma a existência de jobs de produção habilitados nem que um snapshot execute a Regra.

## Resultado esperado

A empresa dispõe de uma Regra explicável a partir do Atributo que controla, com sua dimensão, expressão, limite e frequência documentados. Quando há rastreabilidade técnica válida, também é possível identificar o campo físico e o dialeto que permitem gerar SQL; quando ela não existe, o limite fica visível em vez de simular uma execução.

Uma Regra de qualidade pode funcionar como controle técnico no modelo atual, mas o GovFrame não dispõe de catálogos independentes de Riscos ou Controles equivalentes às Regras. O acompanhamento normativo ou operacional é representado pelos objetos existentes — por exemplo, políticas, procedimentos, contratos, tarefas ou aprovações — de acordo com a relação registrada.

Para aprofundar, consulte o [modelo de objetos e relações](/pt-br/explicaciones/modelo-de-objetos-y-relaciones/), [como ler o mapa de relações](/pt-br/guias/como-leer-mapa-de-relaciones/), [papéis, capacidades e escopo](/pt-br/referencia/roles-capacidades-y-alcance/) e [módulos e dependências](/pt-br/referencia/modulos-y-dependencias/).