Inicio / Exportar Datos

Exportacion de Datos Taxonomicos

Documentacion tecnica y descarga de estructuras de datos para integracion con sistemas externos

Modelo de Datos Relacional

El sistema de taxonomias implementa un modelo de datos jerarquico normalizado que permite la clasificacion multidimensional de entidades institucionales. La arquitectura sigue los principios de la Tercera Forma Normal (3FN), separando las tablas de catalogos (categorias) de las tablas de entidades y utilizando tablas intermedias para gestionar las relaciones muchos-a-muchos.

Se distinguen tres tipos de artefactos de datos: (1) Catalogos de Categorias, que definen las taxonomias abstractas mediante estructuras de arbol con auto-referencia; (2) Tablas de Relacion, que implementan el mapeo entre entidades concretas y categorias; y (3) Vistas Desnormalizadas, que consolidan la informacion para facilitar consultas de lectura.

DIAGRAMA ENTIDAD-RELACION SIMPLIFICADO

┌─────────────────────┐       ┌─────────────────────────┐       ┌─────────────────────┐
│  CATEGORIA          │       │  RELACION_ENTIDAD_CAT   │       │  ENTIDAD (BD ext.)  │
├─────────────────────┤       ├─────────────────────────┤       ├─────────────────────┤
│ PK  id              │◄──────┤ FK  id_categoria        │       │ PK  id              │
│     nombre          │   1:N │ FK  id_entidad ─────────┼──────►│     nombre          │
│ FK  parent_id ──────┼───┐   │     nombre_entidad      │  N:1  │     ...             │
│     nivel           │   │   └─────────────────────────┘       └─────────────────────┘
│     descripcion     │   │              N:M
└─────────────────────┘   │   (Una entidad puede tener
          │               │    multiples categorias;
          └───────────────┘    una categoria puede
       Auto-referencia         aplicar a multiples
       (jerarquia)             entidades)
1

Catalogos de Categorias (Tablas Maestras)

Estructuras taxonomicas jerarquicas - Solo metadatos de clasificacion

Definicion y Proposito

Los catalogos de categorias constituyen tablas maestras de referencia que definen vocabularios controlados para la clasificacion de entidades. Cada catalogo implementa una estructura de arbol mediante auto-referencia (patron Adjacency List), donde el campo parent_id establece la relacion padre-hijo entre registros de la misma tabla.

Estas tablas no contienen datos transaccionales ni entidades reales; unicamente definen las categorias abstractas disponibles para clasificacion. La integridad referencial se mantiene mediante restricciones de clave foranea que apuntan a la misma tabla (auto-referencia) con ON DELETE RESTRICT para prevenir la eliminacion de categorias con hijos dependientes.

El campo nivel es un valor derivado (desnormalizado) que indica la profundidad del nodo en el arbol, donde nivel 0 representa la raiz. Este campo facilita consultas de filtrado por profundidad sin necesidad de recursion.

Cardinalidad

Auto-referencia 1:N (un padre puede tener multiples hijos)

Integridad

FK parent_id → id (misma tabla), NULL permitido solo en raices

Indices recomendados

PRIMARY(id), INDEX(parent_id), INDEX(nivel)

DEFINICION DE ESQUEMA (DDL)

CREATE TABLE categoria_taxonomia (
    id              INTEGER PRIMARY KEY,        -- Identificador unico de la categoria
    nombre          VARCHAR(200) NOT NULL,      -- Nombre descriptivo de la categoria
    parent_id       INTEGER NULL,               -- FK a categoria padre (NULL = raiz)
    nivel           SMALLINT NOT NULL DEFAULT 0,-- Profundidad en el arbol (0 = raiz)
    descripcion     TEXT,                       -- Descripcion extendida opcional

    CONSTRAINT fk_parent
        FOREIGN KEY (parent_id) REFERENCES categoria_taxonomia(id)
        ON DELETE RESTRICT ON UPDATE CASCADE,

    CONSTRAINT chk_nivel CHECK (nivel >= 0),
    CONSTRAINT chk_root CHECK (
        (parent_id IS NULL AND nivel = 0) OR
        (parent_id IS NOT NULL AND nivel > 0)
    )
);

-- Indices para optimizacion de consultas jerarquicas
CREATE INDEX idx_parent ON categoria_taxonomia(parent_id);
CREATE INDEX idx_nivel ON categoria_taxonomia(nivel);

Taxonomia: Cargo/Puesto

Clasificacion ocupacional del personal

Total de categorias29
Profundidad maxima4 niveles (0-3)
Rango de IDs1000 - 1999
Nodos raiz1 (id=1000)
Nodos hoja16
Nivel 0: TODO EL PERSONAL
├─ Nivel 1: FUNCIONARIOS JUDICIALES
│ ├─ Nivel 2: MAGISTRATURAS
│ └─ Nivel 2: JUDICATURAS
├─ Nivel 1: AUXILIARES JUDICIALES
│ ├─ Nivel 2: SECRETARIOS JUDICIALES
│ ├─ Nivel 2: OFICIALES JUDICIALES
│ └─ Nivel 2: DILIGENCIAMIENTO...
└─ Nivel 1: PERSONAL ADMIN. Y TECNICO
├─ Nivel 2: PERSONAL TECNICO
│ └─ Nivel 3: (6 subcategorias)
├─ Nivel 2: PERSONAL ADMINISTRATIVO
│ └─ Nivel 3: (4 subcategorias)
└─ Nivel 2: PERSONAL OPERATIVO
└─ Nivel 3: (6 subcategorias)

Taxonomia: Dependencias

Clasificacion de unidades organizacionales

Total de categorias27
Profundidad maxima3 niveles (0-2)
Rango de IDs2000 - 2999
Nodos raiz1 (id=2000)
Nodos hoja23
Nivel 0: TODAS LAS DEPENDENCIAS
├─ Nivel 1: DEP. JURISDICCIONALES
│ ├─ Nivel 2: CORTE SUPREMA DE JUSTICIA
│ ├─ Nivel 2: SALAS DE APELACIONES
│ ├─ Nivel 2: TRIBUNALES DE SENTENCIA
│ ├─ Nivel 2: JUZGADOS PRIMERA INSTANCIA
│ ├─ Nivel 2: JUZGADOS DE PAZ
│ └─ Nivel 2: (3 mas...)
├─ Nivel 1: DEP. ADMINISTRATIVAS
│ └─ Nivel 2: (6 subcategorias)
└─ Nivel 1: DEP. APOYO JURISDICCIONAL
└─ Nivel 2: (9 subcategorias)

Taxonomia: Ramos Juridicos

Materias del derecho aplicables

Total de categorias14
Profundidad maxima2 niveles (0-1)
Rango de IDs3000 - 3999
Nodos raiz1 (id=3000)
Nodos hoja13
Nivel 0: TODOS LOS RAMOS
├─ Nivel 1: RAMO PENAL (3010)
├─ Nivel 1: RAMO CIVIL (3020)
├─ Nivel 1: RAMO DE FAMILIA (3030)
├─ Nivel 1: RAMO LABORAL (3040)
├─ Nivel 1: RAMO NIÑEZ Y ADOLESCENCIA (3050)
├─ Nivel 1: RAMO FEMICIDIO Y VCM (3060)
├─ Nivel 1: RAMO CONTENCIOSO ADMIN. (3070)
├─ Nivel 1: RAMO ECONOMICO COACTIVO (3080)
├─ Nivel 1: RAMO EXTINCION DOMINIO (3090)
├─ Nivel 1: RAMO MAYOR RIESGO (3100)
├─ Nivel 1: RAMO MIXTO (3110)
├─ Nivel 1: RAMO DE PAZ (3120)
└─ Nivel 1: SIN RAMO ESPECIFICO (3130)

FORMATO JSON - ESTRUCTURA JERARQUICA ANIDADA

Estructura Padre → Hijo (top-down): el arbol inicia en la raiz (nivel 0) y los descendientes estan en el array hijos. Facilita renderizado de TreeView.

{
  "metadata": {
    "nombre": "cargo_puesto",
    "version": "3.0_reorganizada",
    "total_categorias": 29
  },
  "jerarquia": [
    {
      "id": 1000,
      "nombre": "TODO EL PERSONAL",
      "observaciones": "NIVEL_0",
      "hijos": [
        {
          "id": 1100,
          "nombre": "FUNCIONARIOS JUDICIALES",
          "observaciones": "NIVEL_1",
          "hijos": [
            {
              "id": 1110,
              "nombre": "MAGISTRATURAS",
              "observaciones": "NIVEL_2",
              "hijos": []
            },
            {
              "id": 1120,
              "nombre": "JUDICATURAS",
              "observaciones": "NIVEL_2",
              "hijos": []
            }
          ]
        }
        // ... mas nodos
      ]
    }
  ]
}

FORMATO CSV - TABLA PLANA CON REFERENCIAS

Formato tabular apto para importacion directa a RDBMS. La jerarquia se reconstruye via JOINs.

id,nombre,parent_id,nivel
1000,TODO EL PERSONAL,,0
1100,FUNCIONARIOS JUDICIALES,1000,1
1110,MAGISTRATURAS,1100,2
1120,JUDICATURAS,1100,2
1200,AUXILIARES JUDICIALES,1000,1
1210,SECRETARIOS JUDICIALES,1200,2
1220,OFICIALES JUDICIALES,1200,2
1230,DILIGENCIAMIENTO Y EJECUCION,1200,2
1600,PERSONAL ADMINISTRATIVO Y TECNICO,1000,1
1300,PERSONAL TECNICO Y PROFESIONAL,1600,2
1310,ASESORIA JURIDICA DE ALTO NIVEL,1300,3
1320,ASESORIA ESPECIALIZADA,1300,3
...

Query para obtener hijos directos:

SELECT * FROM categorias WHERE parent_id = 1000;
2

Tablas de Relaciones (Mapeo Entidad-Categoria)

Tablas intermedias que implementan la relacion muchos-a-muchos

Definicion y Proposito

Las tablas de relaciones implementan el patron de tabla asociativa (junction table) para resolver la relacion muchos-a-muchos entre entidades y categorias. El campo id_entidad corresponde a la clave primaria de la entidad en el sistema origen (base de datos institucional externa), permitiendo realizar operaciones JOIN sin necesidad de transformacion de identificadores.

Cada registro representa una asignacion atomica de una categoria a una entidad. Una misma entidad puede tener multiples registros en la tabla (uno por cada categoria asignada), lo que implementa la herencia de categorias jerarquicas: cuando una entidad pertenece a una categoria de nivel N, tambien se registra su pertenencia a todas las categorias ancestro hasta la raiz.

El campo nombre_entidad es un atributo desnormalizado incluido por conveniencia para facilitar la lectura humana de los datos exportados; en un modelo estrictamente normalizado, este campo se obtendria mediante JOIN con la tabla de entidades del sistema origen.

Cardinalidad

N:M (muchos-a-muchos) resuelta mediante tabla asociativa

Clave compuesta

PK(id_entidad, id_categoria) previene duplicados

Integridad referencial

FK id_categoria → categoria(id); id_entidad → sistema externo

Origen de los Identificadores (id_entidad)

Los valores de id_entidad provienen de los archivos maestros del sistema institucional. La cobertura de IDs originales varia segun el tipo de entidad, dependiendo de su presencia en las fuentes de datos primarias.

cargo_puestos.csv

Tabla maestra que relaciona cargos con puestos funcionales.

CARGO | NOMBRE_CARGO | PUESTO | NOMBRE_PUESTO
40 | AGENTE DE SEGURIDAD | 4094 | AGENTE DE SEG...
22 | ANALISTA | 4056 | ANALISTA

Provee: 73 IDs de cargos, 307 IDs de puestos

arbol_dependencias.csv

Estructura jerarquica de unidades organizacionales.

LEVEL | DEPENDENCIA | DEPENDENCIA_1 | PADRE
1 | 160 | ADMIN JUZGADOS CIVILES... |
2 | 1254 | DIRECCION DE SEGURIDAD... | PRESIDENCIA

Provee: 1,805 IDs de dependencias

Cobertura de IDs Originales

Cargos68/73 (93%)
Puestos295/301 (98%)
Dependencias1,805/1,805 (100%)

Entidades sin ID: usar nombre como clave de union.

Diagrama de flujo de IDs:

cargo_puestos.csv ──────┬──► Cargos (CARGO → id_entidad)
                        └──► Puestos (PUESTO → id_entidad)

arbol_dependencias.csv ────► Dependencias (DEPENDENCIA → id_entidad)

DEFINICION DE ESQUEMA (DDL) - TABLA ASOCIATIVA

CREATE TABLE relacion_entidad_categoria (
    id_entidad      INTEGER NOT NULL,           -- FK a entidad en sistema origen (BD externa)
    id_categoria    INTEGER NOT NULL,           -- FK a categoria en tabla maestra local
    nombre_entidad  VARCHAR(300),               -- Desnormalizado para conveniencia

    PRIMARY KEY (id_entidad, id_categoria),     -- Clave compuesta evita duplicados

    CONSTRAINT fk_categoria
        FOREIGN KEY (id_categoria) REFERENCES categoria_taxonomia(id)
        ON DELETE CASCADE ON UPDATE CASCADE

    -- NOTA: id_entidad referencia tabla externa, no se puede declarar FK local
);

-- Indices para optimizacion de consultas bidireccionales
CREATE INDEX idx_entidad ON relacion_entidad_categoria(id_entidad);
CREATE INDEX idx_categoria ON relacion_entidad_categoria(id_categoria);

-- Query tipico: obtener todas las categorias de una entidad
SELECT c.id, c.nombre, c.nivel
FROM relacion_entidad_categoria r
JOIN categoria_taxonomia c ON r.id_categoria = c.id
WHERE r.id_entidad = ?
ORDER BY c.nivel;

Relacion: Cargo → Categoria Ocupacional

Entidades unicas (cargos)73
Total de registros221
Promedio cat/entidad3.03
Taxonomia destinocargo_puesto (1xxx)
Profundidad asignadaNiveles 0-3

Ejemplo de asignacion con herencia jerarquica:

GERENTE (id_entidad=3) pertenece a:
├─ 1000 TODO EL PERSONAL (raiz)
├─ 1600 PERSONAL ADMIN. Y TECNICO (nivel 1)
├─ 1400 PERSONAL ADMINISTRATIVO (nivel 2)
└─ 1410 ALTA DIRECCION (nivel 3, hoja)

Esto genera 4 registros en la tabla de relacion.

Relacion: Puesto → Categoria Ocupacional

Entidades unicas (puestos)301
Total de registros907
Promedio cat/entidad3.01
Taxonomia destinocargo_puesto (1xxx)
Profundidad asignadaNiveles 0-3

Ejemplo de asignacion con herencia jerarquica:

JUEZ DE PAZ V (id_entidad=4004) pertenece a:
├─ 1000 TODO EL PERSONAL (raiz)
├─ 1100 FUNCIONARIOS JUDICIALES (nivel 1)
└─ 1120 JUDICATURAS (nivel 2, hoja)

Esto genera 3 registros en la tabla de relacion.

Relacion: Dependencia → Categoria Organizacional

Entidades unicas (dependencias)1,805
Total de registros5,415
Promedio cat/entidad3.00
Taxonomia destinodependencias (2xxx)
Profundidad asignadaNiveles 0-2

Ejemplo de asignacion con herencia jerarquica:

JUZGADO DE PAZ AMATITLAN (id=2) pertenece a:
├─ 2000 TODAS LAS DEPENDENCIAS (raiz)
├─ 2100 DEP. JURISDICCIONALES (nivel 1)
└─ 2150 JUZGADOS DE PAZ (nivel 2, hoja)

Exactamente 3 registros por dependencia.

Relacion: Dependencia → Ramo Juridico

Entidades unicas (dependencias)1,805
Total de registros3,610
Promedio ramos/entidad2.00
Taxonomia destinoramos (3xxx)
Cardinalidad real1-4 ramos/dep

Ejemplo de asignacion multiple (juzgado mixto):

JUZGADO MIXTO PANAJACHEL (id=45) pertenece a:
├─ 3000 TODOS LOS RAMOS (raiz)
├─ 3010 RAMO PENAL
├─ 3020 RAMO CIVIL
└─ 3030 RAMO DE FAMILIA

4 registros: raiz + 3 ramos especificos.

FORMATO JSON - ENTIDAD CON ARBOL DE CATEGORIAS

Estructura Padre → Hijo (top-down): inicia en la raiz y desciende via array hijos. El campo id_entidad solo aparece cuando existe en la BD origen.

{
  "metadata": {
    "tipo_relacion": "cargo_categoria",
    "tipo_entidad": "cargo",
    "total_entidades": 73,
    "entidades_con_id_original": 68,
    "total_relaciones": 221,
    "nota": "id_entidad es el ID original de la BD institucional..."
  },
  "entidades": [
    {
      "id_entidad": 40,  // ID original de BD institucional
      "nombre": "AGENTE DE SEGURIDAD",
      "tipo": "cargo",
      "categorias_arbol": [...]
    },
    {
      "id_entidad": 3,
      "nombre": "GERENTE",
      "tipo": "cargo",
      "categorias_arbol": [
        {
          "id": 1000,
          "nombre": "TODO EL PERSONAL",
          "nivel": 0,
          "hijos": [
            {
              "id": 1600,
              "nombre": "PERSONAL ADMIN. Y TECNICO",
              "hijos": [...]
            }
          ]
        }
      ]
    },
    {
      // Sin id_entidad = no existe en archivo fuente
      "nombre": "AUXILIAR MISCELANEO",
      "tipo": "cargo",
      "categorias_arbol": [...]
    }
  ]
}

FORMATO CSV - TABLA ASOCIATIVA PLANA

Formato para importacion directa. Los IDs originales provienen de los archivos maestros institucionales.

id_entidad,id_categoria,nombre_entidad
3,1000,GERENTE
3,1600,GERENTE
3,1400,GERENTE
3,1410,GERENTE
604,1000,JUEZ DE INSTANCIA
604,1100,JUEZ DE INSTANCIA
604,1120,JUEZ DE INSTANCIA
40,1000,AGENTE DE SEGURIDAD
40,1500,AGENTE DE SEGURIDAD
40,1550,AGENTE DE SEGURIDAD
0,1000,AUXILIAR MISCELANEO  // 0 = sin ID original
...

Query para obtener entidades de una categoria (con descendientes):

-- Obtener todos los cargos bajo "FUNCIONARIOS JUDICIALES" (1100)
WITH RECURSIVE descendientes AS (
  SELECT id FROM categorias WHERE id = 1100
  UNION ALL
  SELECT c.id FROM categorias c
  JOIN descendientes d ON c.parent_id = d.id
)
SELECT DISTINCT r.id_entidad, r.nombre_entidad
FROM relacion_cargo_cat r
WHERE r.id_categoria IN (SELECT id FROM descendientes);
3

Vistas Desnormalizadas (Entidades Consolidadas)

Proyecciones optimizadas para consultas de lectura - Un registro por entidad

Definicion y Proposito

Las vistas desnormalizadas constituyen proyecciones pre-calculadas que consolidan toda la informacion de categorizacion de una entidad en un unico registro. A diferencia de las tablas de relacion (que generan multiples filas por entidad), estas vistas implementan un patron de agregacion donde las categorias se almacenan como arrays o campos concatenados.

Este enfoque sacrifica la normalizacion a cambio de optimizacion en lecturas: elimina la necesidad de JOINs y agregaciones en tiempo de consulta. Es especialmente util para implementar tablas de lookup en memoria, caches de aplicacion, o alimentar sistemas de busqueda que requieren acceso O(1) a la categorizacion completa de una entidad.

El formato JSON incluye la ruta completa de navegacion (breadcrumb) para cada categoria, facilitando la construccion de interfaces de usuario que muestren el contexto jerarquico sin consultas adicionales. El formato CSV utiliza campos multivaluados separados por pipe (|) para compatibilidad con herramientas de importacion que no soportan arrays nativos.

Nivel de normalizacion

1FN (campos multivaluados) - Desnormalizado intencionalmente

Caso de uso optimo

Caches, indices de busqueda, APIs de solo lectura

Trade-off

Duplicacion de datos vs. velocidad de acceso

Vista: Puestos Consolidados

Total de registros301
Taxonomia incluidacargo_puesto
Campos por registroid, nombre, cats[]

Estructura de registro JSON:

{
  "id_entidad": 4004,  // ID original
  "nombre": "JUEZ DE PAZ V",
  "categorias": [
    {
      "id": 1120,
      "nombre": "JUDICATURAS",
      "nivel": 2,
      "ruta": "TODO EL PERSONAL >
              FUNCIONARIOS JUDICIALES >
              JUDICATURAS"
    }
  ]
}

Vista: Cargos Consolidados

Total de registros73
Taxonomia incluidacargo_puesto
Campos por registroid, nombre, cats[]

Estructura de registro JSON:

{
  "id_entidad": 3,  // ID original
  "nombre": "GERENTE",
  "categorias": [
    {
      "id": 1410,
      "nombre": "ALTA DIRECCION",
      "nivel": 3,
      "ruta": "TODO EL PERSONAL >
              PERS. ADMIN. Y TECNICO >
              PERS. ADMINISTRATIVO >
              ALTA DIRECCION"
    }
  ]
}

Vista: Dependencias Consolidadas

Total de registros1,805
Taxonomias incluidasdependencias + ramos
Campos por registroid, nombre, cats[], ramos[]

Estructura de registro JSON (dual):

{
  "id_entidad": 123,
  "nombre": "JUZGADO MIXTO...",
  "categorias_dependencia": [
    {"id": 2150, "nombre": "JUZGADOS DE PAZ",
     "ruta": "TODAS > JURISD > PAZ"}
  ],
  "ramos": [
    {"id": 3010, "nombre": "RAMO PENAL",
     "ruta": "TODOS > PENAL"},
    {"id": 3020, "nombre": "RAMO CIVIL",
     "ruta": "TODOS > CIVIL"}
  ]
}

FORMATO JSON - REGISTRO CONSOLIDADO COMPLETO

{
  "metadata": {
    "tipo_entidad": "dependencia",
    "taxonomias": ["dependencias", "ramos"],
    "total_entidades": 1805,
    "entidades_con_id_original": 1805,  // 100% cobertura
    "nota": "id_entidad es el ID original de la BD institucional..."
  },
  "entidades": [
    {
      "id_entidad": 123,  // ID de arbol_dependencias.csv
      "nombre": "JUZGADO PRIMERO DE PAZ CIVIL GUATEMALA",
      "tipo": "dependencia",
      "categorias_dependencia": [
        {
          "id": 2000,
          "nombre": "TODAS LAS DEPENDENCIAS",
          "nivel": 0,
          "ruta": "TODAS LAS DEPENDENCIAS"
        },
        {
          "id": 2100,
          "nombre": "DEPENDENCIAS JURISDICCIONALES",
          "nivel": 1,
          "ruta": "TODAS > JURISDICCIONALES"
        },
        {
          "id": 2150,
          "nombre": "JUZGADOS DE PAZ",
          "nivel": 2,
          "ruta": "TODAS > JURISDICCIONALES > JUZGADOS DE PAZ"
        }
      ],
      "ramos": [
        {
          "id": 3000,
          "nombre": "TODOS LOS RAMOS",
          "nivel": 0,
          "ruta": "TODOS LOS RAMOS"
        },
        {
          "id": 3020,
          "nombre": "RAMO CIVIL",
          "nivel": 1,
          "ruta": "TODOS LOS RAMOS > RAMO CIVIL"
        }
      ]
    }
  ]
}

FORMATO CSV - CAMPOS MULTIVALUADOS

nombre_dependencia,categorias_ids,ramos_ids
JUZGADO PRIMERO DE PAZ CIVIL GUATEMALA,2000|2100|2150,3000|3020
JUZGADO SEGUNDO DE TRABAJO GUATEMALA,2000|2100|2140,3000|3040
SALA PRIMERA CIVIL CORTE APELACIONES,2000|2100|2120,3000|3020
GERENCIA FINANCIERA,2000|2200|2220,3000|3130
CENTRO DE MEDIACION QUETZALTENANGO,2000|2300|2370,3000|3130
...

Para procesar campos multivaluados en SQL:

-- PostgreSQL: convertir campo | a array
SELECT
  nombre_dependencia,
  string_to_array(categorias_ids, '|')::integer[] as cat_array
FROM dependencias_consolidadas
WHERE '2150' = ANY(string_to_array(categorias_ids, '|'));

-- MySQL: buscar dentro de campo concatenado
SELECT * FROM dependencias_consolidadas
WHERE FIND_IN_SET('2150', REPLACE(categorias_ids, '|', ','));
4

Grafo Completo de la Taxonomia Institucional

Exportacion integral del arbol organizacional con todas las relaciones

Este archivo contiene la representacion completa del grafo organizacional del Organismo Judicial, incluyendo las 1,805 dependencias organizadas en su jerarquia natural (hasta 4 niveles de profundidad), con los puestos asignados a cada dependencia como nodos terminales.

La estructura implementa un arbol n-ario serializado donde cada nodo contiene: identificador unico, nombre, nivel jerarquico, referencia al padre, lista de hijos (recursiva), y lista de puestos. El archivo resultante (~3 MB) es util para: (a) reconstruir la estructura completa en memoria, (b) analisis offline de la organizacion, (c) backup de la taxonomia, (d) alimentar sistemas de visualizacion de grafos.

taxonomia_completa.json

Tamaño: ~3 MB | Nodos: 1,805 dependencias | Profundidad: 4 niveles | Formato: JSON anidado recursivo

Guia de Seleccion de Artefacto

Caso de Uso Artefacto Recomendado Formato Justificacion Tecnica
Poblar componente TreeView/Dropdown Seccion 1: Catalogos JSON Estructura ya anidada, mapeo directo a componentes recursivos
Importar a RDBMS como tabla maestra Seccion 1: Catalogos CSV Formato tabular con FK explicita, COPY/LOAD directo
JOIN con tabla de empleados existente Seccion 2: Relaciones CSV id_entidad coincide con PK de sistema origen
Cache en memoria / HashMap Seccion 3: Entidades JSON Lookup O(1) por id_entidad, datos pre-agregados
Indice de busqueda (Elasticsearch, etc.) Seccion 3: Entidades JSON Documentos autocontenidos, rutas como texto indexable
Backup / Migracion completa Seccion 4: Completa JSON Grafo completo serializado, reconstruccion total

Escuela de Estudios Judiciales

Eje Transversal de Tecnologia | Innovacion Juridico Tecnologico

Organismo Judicial de Guatemala - 2025