--- title: Diccionario técnico description: Documente campos físicos, su contexto de repositorio y su vínculo comprobable con atributos del catálogo de negocio. audiencia: Ingeniero de datos | Data Steward | Data Owner | Administrador roles: Ingeniero de datos y Administrador para gestión técnica; Data Steward y Data Owner para enriquecer significado dentro de alcance modulo: Diccionario técnico revision: "2026-10-19" section: "administrar-tecnicamente" order: 20 sources: - CONTEXT.md - ARCHITECTURE.md - TESTING_GUIDE.md - Modelodeobjetosyrelaciones.md - Módulosydependencias.md - Roles,capacidadesyalcance.md - Cómoleerelmapaderelaciones.md --- # Diccionario técnico El **Diccionario técnico** conecta el lenguaje de negocio con evidencia física registrada en una fuente. Cada campo del diccionario se contextualiza por su Repositorio y puede guardar los datos técnicos disponibles, como esquema, tabla, columna, tipo y características físicas. Cuando el vínculo es real, el campo se asocia con un Atributo de la taxonomía para hacer visible dónde se materializa un concepto de negocio. El diccionario es editable: la metadata procedente de fuentes aporta contexto físico y las personas responsables pueden completar o corregir descripciones y definiciones de negocio. No traduce ni modifica automáticamente los nombres dinámicos que la organización ya utiliza; el idioma de la interfaz no altera esos datos. ## Antes de empezar **Rol.** El **Ingeniero de datos** administra campos, metadata y asociaciones técnicas con `technical.manage` en los Repositorios que tiene asignados. El **Administrador** tiene ese alcance en toda la empresa. Data Steward y Data Owner pueden enriquecer descripciones y definiciones en sus Dominios o Subdominios autorizados; su participación no reemplaza el scope técnico del repositorio. **Módulo.** Deben estar habilitados **Diccionario técnico** y **Repositorios de datos**. El primero depende del segundo: no hay un diccionario técnico útil sin un repositorio registrado. Un módulo desactivado no se puede operar aunque una persona conozca una ruta de acceso. **Precondiciones.** Parte de una taxonomía que contenga el Dominio, la Entidad y el Atributo que se pretende documentar, y de un Repositorio que represente la fuente física. Verifica también que la asociación propuesta sea comprobable; no la deduzcas solo porque dos nombres se parecen. ## Recorrido recomendado 1. **Aclara el significado antes de asociar.** Ubica el Atributo en su Entidad y su contexto de Dominio o Subdominio. Revisa su nombre y definición funcional con el Steward u Owner responsable cuando sea necesario. 2. **Identifica el contexto físico.** Selecciona o registra el campo dentro del Repositorio correspondiente. Conserva los datos técnicos que permitan reconocerlo —por ejemplo, esquema, tabla, columna y tipo— sin incluir secretos ni detalles de acceso. 3. **Registra la relación física comprobada.** Asocia el campo al Atributo solo si representa ese elemento de información. La asociación directa documenta el vínculo; el contexto de Dominio y Subdominio puede obtenerse desde la cadena Atributo → Entidad → taxonomía. 4. **Enriquece la ficha.** Añade una descripción que explique la correspondencia entre el nombre físico y el significado de negocio. Distingue claramente una convención técnica de una definición de negocio para que el lector sepa qué parte se obtuvo de la fuente y cuál se mantiene de forma editorial. 5. **Revísalo en el contexto de relaciones.** En el detalle técnico del mapa se puede seguir el recorrido Atributo ↔ Campo del Diccionario técnico ↔ Repositorio, junto con esquema, tabla y columna cuando estén registrados. La ausencia de una línea significa que no hay una relación documentada, no que deba inferirse una. > **Ejemplo sintético.** El Atributo “Fecha de ingreso” de una Entidad Persona puede asociarse a un campo físico `fecha_ingreso` en una tabla del Repositorio Académico. La ficha debe explicar por qué ambos representan el mismo dato. Si otra tabla contiene una fecha con un propósito diferente, no se la asocia solo por compartir parte del nombre. ## Diccionario, calidad y SQL Las Reglas de calidad se definen sobre Atributos y pueden vincularse a campos del Diccionario técnico. Para generar SQL, GovFrame exige **asociaciones válidas a campos físicos** y un **dialecto configurado**. Si falta el campo físico o el dialecto, no debe generarse SQL. El SQL generado se limita a ese resultado documentado: no supone ejecución automática contra el repositorio ni sustituye la revisión de la persona responsable. Esta trazabilidad permite entender si una regla se apoya en una fuente concreta, pero no convierte todos los campos de una tabla en controles ni todos los controles en un catálogo independiente de Riesgos o Controles. Según el caso, el control se representa con una Regla de calidad, una Política o Procedimiento, un Workflow, una tarea, una aprobación, una clasificación o una certificación. ## Resultado esperado El resultado es una ficha técnica legible que identifica un campo físico dentro de su Repositorio y, cuando corresponde, muestra su asociación explícita con un Atributo. La ficha conserva el contexto necesario para navegar desde el significado de negocio a la fuente, analizar impacto y relacionar el campo con Reglas, Contratos u otros objetos que ya tengan vínculos registrados. ## Límites del estado actual - La pertenencia de una tabla a un Repositorio no registra automáticamente todos sus campos en el Diccionario ni los asocia a Atributos. - Un campo puede proporcionar contexto técnico sin que exista todavía una definición de negocio completa; esta ausencia debe mostrarse como tal, no rellenarse por inferencia. - Las relaciones, descripciones y operaciones están aisladas por empresa y se someten a roles, capacidades, módulos y alcance. - Los códigos técnicos sirven a persistencia, validación, importación o SQL generado; en la guía y la interfaz funcional deben prevalecer nombres comprensibles. ## Referencias relacionadas - [Modelo de objetos y relaciones](/es/explicaciones/modelo-de-objetos-y-relaciones/) - [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/) - [Roles, capacidades y alcance](/es/referencia/roles-capacidades-y-alcance/) - [Módulos y dependencias](/es/referencia/modulos-y-dependencias/)