Relación de las bases de datos

Propósito

Este documento resume la organización y la relación funcional observada entre COMUN, CARTOGRAFIA y BOMBERO_INSCRIP. Está dirigido a las personas que necesitan orientarse en el modelo sin conocer todavía la historia de las bases de datos.

El análisis se realizó sobre una instancia SQL Server en Docker. Las conclusiones combinan el catálogo de SQL Server, los nombres y tipos de columnas, coincidencias de códigos entre bases, la definición de vistas y el diccionario de la Ficha Bombero.

Resumen ejecutivo

La interpretación más consistente es la siguiente:

COMUN concentra catálogos y datos compartidos; CARTOGRAFIA concentra referencias geográficas; BOMBERO_INSCRIP recibe los datos de la ficha de reinscripción. inbp_bombero es una base de datos adicional candidata normalizada.

Las tres bases principales no forman un único esquema relacional normalizado. Tienen claves primarias, pero no tienen claves foráneas declaradas entre sus tablas. Por tanto, las relaciones se implementan mediante códigos conocidos por el frontend, el backend o procesos de integración.

Las flechas continuas representan relaciones observadas en los datos y en el diseño de la ficha. Las flechas discontinuas representan una relación arquitectónica probable, no una dependencia declarada por SQL Server.

Inventario general

Base	Tablas dbo	Filas aproximadas observadas	Responsabilidad probable
COMUN	28	45.206	Catálogos compartidos y directorio histórico de teléfonos
CARTOGRAFIA	12	10.339	Geografía, ubicaciones, población, zonas y establecimientos de salud
BOMBERO_INSCRIP	7	11	Captura de datos para la reinscripción 2026

Los conteos de COMUN y CARTOGRAFIA incluyen las tablas heredadas dtproperties y sysdiagrams, que son metadatos de diagramas de SQL Server y no entidades del negocio.

1. Base COMUN

Responsabilidad

COMUN es la fuente de valores codificados que se reutilizan en la ficha y en otras partes del sistema. Su contenido es principalmente de referencia: descripciones, tipos, clasificaciones y códigos que el usuario selecciona en formularios.

También contiene Telefonos, una tabla grande que asocia números y otros datos telefónicos con un CodBom.

Tablas de negocio

• CargoTrabajo: cargos o trabajos.
• CatalogoBien: catálogo de bienes y cuentas asociadas.
• CatalogoCBP y CatalogoCBPMarca: catálogo de bienes o equipos del CGBVP y sus marcas.
• CentroEstudio: centros de estudio.
• ClaseCen: clases de centro.
• ClaseTalla y Tallas: clases y valores de tallas.
• Estado, EstadoCivil y SitLab: estados generales, estado civil y situación laboral.
• GrupSang: grupos sanguíneos.
• LinConducir: categorías o tipos de licencia de conducir.
• Meses y Romanos: catálogos auxiliares.
• Parentesco: tipos de parentesco.
• profesion: profesiones, ocupaciones y títulos.
• Sistemas: sistemas o subsistemas codificados.
• TipoDoc: tipos de documento de identidad.
• TipoEstudio: tipos de estudio.
• TipoTelef y ubitelef: tipos y ubicaciones de teléfonos.
• UnidadMedida: unidades de medida.
• Telefonos: teléfonos vinculados conceptualmente a un bombero mediante CodBom.
• Etiquetas y etiquetas2: datos auxiliares de etiquetas.

Vistas

Las vistas de COMUN quedan operativas con el nombre canónico de la base:

• VistaCamisa: presenta tallas de camisa.
• VistaPantalon: presenta tallas de pantalón.
• VistaTelefonos: combina teléfonos con la descripción del tipo telefónico.
• VistaTipoDoc: filtra los tipos de documento utilizados por la aplicación.
• tablas: vista heredada de inventario de objetos de SQL Server.

Relaciones internas destacables

• Telefonos.CodTipoTelef se corresponde con TipoTelef.CodTipoTelef en las 29.493 filas observadas.
• Telefonos.UbiTelef se corresponde con ubitelef.codubitelef en las 29.493 filas observadas.
• CatalogoCBP.CodUnidMed se corresponde completamente con UnidadMedida.CodUnidMed.
• CatalogoCBP.CodClaseTalla se corresponde en la mayoría de los casos con ClaseTalla.CodClaseTalla; el código 0 aparece como valor sin catálogo y parece ser un valor por defecto o desconocido.

Dimensión y calidad estructural

Telefonos tiene 29.493 filas y 16.804 CodBom distintos. Es una relación de uno a muchos respecto del bombero: un bombero puede tener varios teléfonos.

No hay claves foráneas declaradas. Varias tablas auxiliares tampoco tienen clave primaria, por ejemplo CatalogoBien, Telefonos, TipoEstudio y ubitelef. Esto no impide su uso actual, pero deja la integridad a cargo de la aplicación o de los procesos de carga.

2. Base CARTOGRAFIA

Responsabilidad

CARTOGRAFIA proporciona los valores geográficos que necesita la ficha para representar país, dirección, zona y ubicación. También contiene información para mapas, población y establecimientos de salud.

Tablas de negocio

• paises: países, abreviaturas y descripciones.
• ubigeo: catálogo principal de códigos geográficos.
• Ubigeo_CD: copia o extensión del catálogo de ubigeo, con CodComan adicional.
• Departamento: departamentos en una codificación histórica.
• Departamento_Poligono: polígonos geográficos en formato de texto.
• Zonas y TipoZona: zonas y tipos de zona.
• TipoVia: tipos y abreviaturas de vía.
• Poblacion: población por ubigeo y año.
• Nosocomios: hospitales o establecimientos de salud con dirección, teléfono, latitud y longitud.

Vistas geográficas

• VistaDepartamentos: deriva departamentos a partir de los primeros segmentos del código UBIGEO.
• VistaProvincias: deriva provincias a partir del código UBIGEO.
• VistaDistritos: deriva distritos a partir del código UBIGEO.
• VistaUbigeo: combina distrito, provincia y departamento en una vista utilizable por la aplicación.

Jerarquía geográfica observada

La relación conceptual principal es:

ubigeo
  ├── VistaDepartamentos / VistaProvincias / VistaDistritos
  ├── Zonas.Ubigeo
  └── Poblacion.ubigeo

Además:

• Zonas.CodTipoZona se corresponde con TipoZona.CodTipoZona en 5.103 de 5.104 filas. El código 00 es la excepción y parece representar un valor genérico o sin clasificación.
• Zonas.Ubigeo se corresponde con ubigeo.UBIGEO en 5.095 de 5.104 filas.
• Las 512 filas de Poblacion cubren cuatro años, de 2009 a 2012, y 128 códigos geográficos; sus códigos se corresponden con ubigeo.
• Ubigeo_CD contiene 2.084 códigos que se corresponden con el catálogo de ubigeo.

Diferencia de códigos de departamento

Departamento_Poligono.codigo utiliza valores como 01, 02 y 25, mientras que Departamento.cod_depto utiliza otra codificación histórica, por ejemplo 1, 41, 42 y 84. No se deben unir directamente esas columnas.

Los nombres de los departamentos permiten identificar una correspondencia en la mayoría de los casos, pero una integración formal necesita una tabla de equivalencias. Los nombres observados en los polígonos incluyen los 25 departamentos del mapa, mientras que el catálogo Departamento mantiene 24 registros y agrupa Lima y Callao en un registro histórico.

3. Base BOMBERO_INSCRIP

Responsabilidad

BOMBERO_INSCRIP representa la captura de la ficha de datos personales y sus bloques relacionados para una campaña de reinscripción. La fila de ReInscripcion observada corresponde al período 2026 y a la DIGEVO del CGBVP.

Tablas de negocio

Personal

Es el registro principal de la ficha. Contiene:

• identidad, nombres y apellidos;
• sexo, país y tipo/número de documento;
• fecha y lugar de nacimiento;
• dirección, tipo de vía, zona y Ubigeo del domicilio;
• correo y teléfonos personales;
• grupo sanguíneo, salud, alergias y problemas médicos;
• tallas de camisa, pantalón y calzado;
• indicadores de instrucción educativa, profesión y ocupación;
• latitud y longitud;
• auditoría básica de usuario y fecha de modificación.

La fila se identifica funcionalmente mediante CodBom, aunque la tabla también tiene IdReg como clave primaria técnica.

PerFam

Contiene familiares del bombero: nombres, apellidos, fecha de nacimiento, parentesco, condición de bombero, estado de vida, teléfono y dirección.

Su relación prevista es PerFam.CodBom -> Personal.CodBom y PerFam.CodParentesco -> COMUN.Parentesco.CodParentesco.

PerEmer

Contiene contactos para casos de emergencia: nombre, parentesco, dirección, teléfonos y códigos de usuario.

Su relación prevista es PerEmer.CodBom -> Personal.CodBom y PerEmer.CodParentesco -> COMUN.Parentesco.CodParentesco.

PerEstudios

Contiene estudios ingresados en la ficha, incluyendo centro, nombre del estudio, registro/colegiatura, fechas y situación.

Su relación prevista es PerEstudios.CodBom -> Personal.CodBom, PerEstudios.IdReInscripcion -> ReInscripcion.IdReInscripcion y PerEstudios.CentroEstudio -> COMUN.CentroEstudio.CodCen.

ReInscripcion

Define la campaña o período de reinscripción. La fila observada tiene período 2026 y estado S.

Bom_DatosLogeo

Contiene datos de acceso o contacto de login asociados a CodBom, como teléfono, correo y usuario que registra o modifica.

VistaPrincipal

Aunque su nombre comienza por Vista, en esta base es una tabla, no una vista SQL. Tiene ocho filas de datos de desarrollo y no tiene clave primaria. El diccionario de la ficha indica que fue creada como tabla ficticia para desarrollo, mientras que el ambiente real utilizaría una fuente de bombero.

Estado de los datos observados

La copia tiene muy pocos datos de la campaña:

Tabla	Filas observadas
Personal	1
PerFam	0
PerEmer	0
PerEstudios	0
ReInscripcion	1
Bom_DatosLogeo	1
VistaPrincipal	8

Las tablas de detalle están vacías, por lo que sus relaciones se deducen del diseño y de los nombres de columnas, pero todavía no pueden validarse con filas de detalle en esta copia.

Relaciones entre las bases

Catálogos usados por Personal

Los códigos de la única fila observada en BOMBERO_INSCRIP.Personal se resolvieron de la siguiente forma:

Columna de Personal	Fuente conceptual	Resultado observado
CodPais	CARTOGRAFIA.paises.CodPais	Coincide
CodTipoDoc	COMUN.TipoDoc.CodTipoDoc o COMUN.VistaTipoDoc	Coincide
CodLinconducir	COMUN.LinConducir.CodLinConducir	Coincide
CodGrupSang	COMUN.GrupSang.CodGrupSang	Coincide
CodEstCiv	COMUN.EstadoCivil.CodEstCiv	Coincide
CodTipoVia	CARTOGRAFIA.TipoVia.CodTipoVia	Coincide
LugNacUbigeo	CARTOGRAFIA.ubigeo.UBIGEO	Coincide
DomiUbigeo	CARTOGRAFIA.ubigeo.UBIGEO	Coincide
CodZona	CARTOGRAFIA.Zonas.CodZona	Vacío en la fila observada

Esto muestra que BOMBERO_INSCRIP consume valores de referencia de las otras dos bases, pero no los copia necesariamente como filas descriptivas. Guarda los códigos y espera que otra capa resuelva sus descripciones.

Teléfonos y CodBom

COMUN.Telefonos.CodBom es el vínculo conceptual entre el directorio telefónico compartido y la identidad de bombero. En la muestra inicial, cuatro filas de Telefonos compartían el CodBom de la única fila de Personal, correspondiente a una sola clave distinta.

La cantidad de coincidencias es específica de esta copia y no debe interpretarse como una cobertura completa de producción.

Diferencia entre las poblaciones actuales

No se debe asumir que todas las tablas con CodBom representan la misma población:

• BOMBERO_INSCRIP.Personal tiene una fila de reinscripción actual.
• BOMBERO_INSCRIP.VistaPrincipal tiene ocho filas ficticias de desarrollo.
• BOMBERO_INSCRIP.Bom_DatosLogeo tiene una fila que coincide con una de las ocho filas de VistaPrincipal, no con la fila actual de Personal.
• La fila de Personal coincide con inbp_bombero.persona, mientras que las ocho filas de VistaPrincipal no coinciden con el maestro.

La lectura más probable es que VistaPrincipal y Bom_DatosLogeo son datos de prueba o una fotografía anterior, mientras que Personal representa el flujo de reinscripción en desarrollo.

Flujo funcional propuesto

El flujo que mejor explica los datos y el diccionario es:

1. El usuario inicia una reinscripción para un CodBom existente.
2. La aplicación consulta catálogos de COMUN y CARTOGRAFIA para llenar selects y resolver descripciones.
3. La aplicación guarda la información principal en BOMBERO_INSCRIP.Personal.
4. Guarda familiares, contactos de emergencia y estudios en PerFam, PerEmer y PerEstudios.
5. ReInscripcion identifica la campaña o período al que pertenece la captura.
6. Después del cierre oficial definido por DIGEVO, un proceso todavía pendiente de documentar debería validar y consolidar los datos en el sistema operativo o maestro.

El diccionario indica que el procedimiento oficial de cierre de la reinscripción y el carácter de declaración jurada todavía deben ser definidos por DIGEVO. Por eso no debe suponerse que la inserción en BOMBERO_INSCRIP actualiza automáticamente inbp_bombero.

Riesgos y decisiones importantes

Integridad referencial

Las tres bases principales no tienen claves foráneas declaradas. Las relaciones de CodBom, IdReInscripcion, Ubigeo y los catálogos pueden quedar huérfanas si el backend no las valida.

Recomendación: crear validaciones explícitas y, cuando la propiedad de los datos esté clara, agregar claves foráneas o tablas de referencia controladas. Esto debe hacerse después de revisar los datos históricos y no como una migración automática.

Colaciones

Algunas columnas de texto de BOMBERO_INSCRIP utilizan SQL_Latin1_General_CP1_CI_AS y otras utilizan Modern_Spanish_CI_AS. Comparaciones entre columnas con colaciones distintas fallan si no se especifica una conversión.

Recomendación: definir una colación institucional y normalizar los códigos en una migración planificada. Mientras tanto, los procesos de auditoría o integración deben usar una colación explícita y documentada.

Catálogos duplicados

COMUN, CARTOGRAFIA e inbp_bombero contienen familias de catálogos con nombres equivalentes, pero no siempre con la misma cantidad de filas. Por ejemplo, ubigeo, Zonas y Tallas tienen diferencias entre las copias.

Recomendación: identificar una fuente de verdad por catálogo, versionar las copias y definir cómo se actualizan.

Códigos geográficos

Los códigos de Departamento_Poligono y Departamento no pertenecen al mismo sistema de codificación. La integración debe usar una tabla de equivalencias, no una conversión implícita ni un join directo por número.

Datos de desarrollo

VistaPrincipal no es una vista y contiene datos ficticios. No debe usarse como fuente de verdad para el padrón de bomberos ni como evidencia de que el maestro está actualizado.

Procedimiento de cierre

La base de inscripción tiene una campaña, pero el proceso de aprobación, cierre, declaración jurada y consolidación no está representado por procedimientos almacenados. Debe documentarse como parte del diseño funcional y operativo.

Conclusión

La organización recomendada para explicar estas bases a un nuevo integrante es:

• COMUN: catálogos compartidos y teléfonos históricos.
• CARTOGRAFIA: países, Ubigeo, zonas, vías, población, polígonos y nosocomios.
• BOMBERO_INSCRIP: captura temporal o de campaña de la ficha de reinscripción.
• inbp_bombero: base de datos candidata normalizada

La idea central es: la ficha guarda códigos y datos ingresados; COMUN y CARTOGRAFIA proporcionan el contexto de esos códigos; y un proceso posterior debe decidir cuándo y cómo consolidar la ficha en el sistema maestro. Las bases comparten convenciones de nombres y códigos, pero actualmente dependen demasiado de la lógica de la aplicación y de procesos externos para garantizar la integridad entre ellas.