---
title: Modelo de objetos y relaciones
slug: modelo-de-objetos-y-relaciones
description: Cómo se relacionan la taxonomía, los objetos de gobierno y las fuentes técnicas en GovFrame.
audiencia: Administrador | Data Owner | Data Steward | Ingeniero de datos | Usuario | Superadministrador
roles: Consulta para todos los perfiles autenticados; administración según capacidad y alcance
modulo: Referencia transversal
estado: Comportamiento actual validado
revision: "2026-10-19"
section: explicaciones
order: 10
sources:
  - "Modelodeobjetosyrelaciones.md"
---

# Modelo de objetos y relaciones

GovFrame usa la **taxonomía como columna vertebral**. La taxonomía organiza el contexto de negocio; los demás objetos se relacionan con uno o más niveles para explicar qué significa un dato, quién responde por él, dónde vive, cómo se controla y cómo se publica.

Esta página responde dos preguntas:

1. ¿En qué nivel taxonómico se relaciona cada objeto?
2. ¿Cómo se conectan entre sí los objetos de negocio, técnicos y operativos?

## 1. La taxonomía es el eje de navegación

El tenant puede trabajar con uno de estos modelos:

```text
Taxonomía estándar:  Dominio → Entidad → Atributo
Taxonomía expandida: Dominio → Subdominio → Entidad → Atributo
```

| Nivel | Qué representa | Qué suele depender de él |
|---|---|---|
| **Dominio** | Gran ámbito de negocio y responsabilidad. | Alcance de usuarios, ownership, productos, contratos, políticas y objetos de alto nivel. |
| **Subdominio** | División opcional del dominio. | Alcance más preciso, entidades, productos, contratos, políticas y casos operativos. |
| **Entidad** | Concepto u objeto de negocio. | Atributos, términos, roles de gobierno, repositorios heredados y datos no estructurados. |
| **Atributo** | Elemento de información dentro de una entidad. | Reglas de calidad, campos del Diccionario técnico, clasificaciones y contratos. |

Un objeto puede tener una **asociación directa** con un nivel o llegar a él por una relación derivada. Por ejemplo, un campo técnico apunta directamente a un Atributo; el Dominio se obtiene atravesando Atributo → Entidad → (Subdominio) → Dominio.

## 2. Regla de asociación directa y heredada

- **Directa:** el registro guarda explícitamente el vínculo con el nivel taxonómico. Ejemplo: un Producto guarda `domainId` y, opcionalmente, `subdomainId`.
- **Por componente:** el vínculo se guarda en una relación reutilizable que permite asociar un objeto a uno o varios nodos. Ejemplo: un Repositorio puede asociarse a varios Dominios o Subdominios.
- **Heredada:** el sistema calcula el contexto desde un objeto hijo. Ejemplo: una Regla de calidad hereda Dominio y Subdominio desde el Atributo al que pertenece.
- **Derivada por composición:** un Contrato puede llegar a atributos, reglas, campos y términos mediante sus tablas de asociación, aunque su alcance principal sea Dominio/Subdominio.

La asociación heredada no cambia el nivel original del objeto. Sirve para filtros, autorización, navegación, cobertura y análisis de impacto.

## 3. Matriz de objetos y nivel de relación

| Objeto | Asociación principal actual | Nivel de relación | Relaciones relevantes |
|---|---|---|---|
| **Término de negocio** | Dominio y enlaces a una o varias Entidades. | Dominio o Entidad; puede enlazarse mediante componentes a otros nodos. | Define lenguaje de negocio; puede formar parte de un Contrato y documentar un KPI. |
| **Rol de gobierno** | Dominio y enlaces a Entidades. | Dominio y Entidad. | Representa Owner/Steward u otra responsabilidad; puede ser responsable de Producto o Contrato. |
| **Regla de calidad** | Atributo. | Atributo, con contexto heredado de Entidad, Subdominio y Dominio. | Usa una Dimensión; se asocia a campos técnicos válidos y puede entrar en Contratos y Workflows. |
| **Campo del Diccionario técnico** | Atributo y Repositorio. | Atributo; el Repositorio aporta el contexto físico. | Guarda esquema, tabla, columna, tipo y características físicas; materializa un vínculo con la fuente. |
| **Repositorio de datos** | Uno o varios Dominios/Subdominios mediante asociaciones de alto nivel; puede conservar Entidad heredada. | Dominio/Subdominio; opcionalmente Entidad por compatibilidad o contexto legado. | Se conecta mediante un Conector; contiene metadata, snapshots y campos del Diccionario técnico; puede pertenecer a un Sistema. |
| **Sistema de información** | Uno o varios Dominios/Subdominios mediante asociaciones de alto nivel; puede conservar Entidad heredada. | Dominio/Subdominio; opcionalmente Entidad por contexto legado. | Se relaciona con Repositorios, Productos y Contratos. |
| **Datos no estructurados** | Entidad y/o asociación de componente. | Entidad, con Dominio/Subdominio heredado. | Puede ser un activo de arquitectura y participar en relaciones de gobierno. |
| **Activo de datos** | Dominio. | Dominio; puede recibir asociaciones adicionales de taxonomía. | Puede ser parte de un Producto y estar certificado, clasificado o comentado. |
| **Producto de datos** | Dominio y Subdominio opcional. | Dominio/Subdominio. | Agrupa Activos y se relaciona con un Owner y con Contratos. |
| **Contrato de datos** | Dominio, Subdominio y Owner. | Dominio/Subdominio. | Incluye Atributos, Reglas de calidad, Campos del Diccionario, Términos, Sistemas y Producto. |
| **Política, Proceso y Procedimiento** | Dominio/Subdominio opcionales. | Dominio/Subdominio. | Mantienen la jerarquía Política → Proceso → Procedimiento, versiones, responsables y aprobaciones. |
| **Objetivo** | Dominio/Subdominio opcionales. | Dominio/Subdominio. | Se relaciona con uno o varios KPI y mantiene mediciones y revisiones. |
| **KPI o Key Result** | Nivel primario explícito: Dominio, Subdominio, Entidad o Atributo. | Cualquiera de los cuatro niveles. | Puede tener enlaces secundarios a taxonomía y a Términos, Activos, Reglas, Diccionario, Repositorios, Sistemas, Productos y Contratos. |
| **Workflow y caso** | Dominio/Subdominio opcionales y objeto objetivo. | Contexto directo o derivado del objeto afectado. | Un caso puede apuntar a cualquier objeto del ecosistema; sus tareas, decisiones, evidencias y notificaciones dependen del caso. |
| **Solicitud de acceso** | Objeto solicitado y caso de Workflow. | Se deriva del objeto: tabla, dashboard, dataset u otro destino permitido. | Puede agrupar varias solicitudes, tener aprobación parcial, enmascaramiento y provisionamiento. |
| **Stewardship** | Asignaciones de Owner, scopes, clasificaciones, certificaciones, comentarios y tareas. | Se resuelve desde el objeto objetivo y su contexto taxonómico. | Añade responsabilidad y estado sin reemplazar la relación taxonómica del objeto. |

### Riesgos y controles: precisión del modelo actual

En la implementación actual no existe un módulo de catálogo independiente llamado **Riesgos** o **Controles** con tablas propias equivalentes a Términos o Reglas. El control se representa mediante combinaciones de objetos existentes, por ejemplo:

- una Regla de calidad como control técnico;
- una Política/Procedimiento como control normativo;
- un Workflow, tarea o aprobación como control operativo;
- una Regla incluida en un Contrato como compromiso verificable;
- una clasificación, certificación o tarea de stewardship como seguimiento.

La interfaz puede mostrar riesgos, alertas o cobertura derivados del dashboard y de tareas, pero esta documentación no los presenta como un inventario independiente hasta que exista ese módulo y su contrato de datos.

## 4. Cómo se forma el ecosistema

El recorrido funcional típico es:

```text
Taxonomía
  ↓
Responsables y alcance
  ↓
Términos de negocio ───────────────┐
  ↓                                │
Entidades y Atributos               │
  ↓                                │
Diccionario técnico ← Repositorio ← Conector / fuente
  ↓
Reglas de calidad ────────────────┐ │
  ↓                              │ │
Producto de datos ← Activos ←────┘ │
  ↓                                │
Contrato de datos ← Términos, Atributos, Reglas, Campos, Sistemas
  ↓
Workflows, solicitudes, tareas, aprobaciones y auditoría
```

Los KPI y Objetivos cruzan el ecosistema: toman un nivel taxonómico primario y pueden documentar su fórmula, fuente de medición, control, evidencia, producto o contrato mediante enlaces tipados.

## 5. Cómo leer una relación en la interfaz

1. Empieza por el Dominio o Subdominio para entender el contexto y el alcance.
2. Baja a Entidad y Atributo para encontrar el significado preciso.
3. Desde un Atributo, revisa Reglas de calidad y campos del Diccionario técnico.
4. Desde el campo, identifica Repositorio, esquema, tabla, columna y Sistema cuando estén registrados.
5. Recorre Productos y Contratos para entender qué se entrega, a quién y con qué compromisos.
6. Usa Workflows, tareas y solicitudes para seguir decisiones pendientes, cambios y accesos.

El Explorador de relaciones tiene tres perspectivas: **Panorama** para descubrir, **Impacto** para analizar dependencias y **Detalle técnico** para seguir el vínculo entre taxonomía y fuentes físicas. La guía de uso está en [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/).

## 6. Límites importantes

- Todas las relaciones están aisladas por empresa y deben respetar el alcance del usuario.
- Los códigos técnicos identifican registros, pero las guías funcionales deben mostrar nombres legibles.
- Una asociación de alto nivel no implica que todos los campos de una fuente estén asociados a todos los atributos.
- Una Regla de calidad solo genera SQL cuando tiene asociaciones válidas a campos físicos.
- Desactivar un módulo oculta y bloquea su operación para el tenant, pero no elimina automáticamente sus datos.

## Contenido relacionado

- [Roles, capacidades y alcance](/es/referencia/roles-capacidades-y-alcance/)
- [Módulos y dependencias](/es/referencia/modulos-y-dependencias/)
- [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/)
- [Índice oficial](/es/)