Propósito de la clase

La semana anterior fue reemplazada por una evaluación remedial. Por eso, antes de avanzar hacia el póster, necesitamos reforzar el paso que conecta la descarga de datos con el análisis.

No basta con descargar archivos desde Transparencia Activa.

Para analizarlos, necesitamos nombrarlos, identificarlos, limpiarlos, unirlos y resumirlos.

Ruta de trabajo de la semana

Hoy trabajaremos el siguiente flujo:

archivos descargados
        ↓
nombres ordenados
        ↓
variables identificadoras
        ↓
estandarización de columnas
        ↓
unión con bind_rows()
        ↓
tablas descriptivas
        ↓
exportación de resultados

¿Por qué esto importa para el póster?

El póster no parte con el diseño visual.

Parte con una base que permita responder una pregunta descriptiva.

Para eso necesitamos:

• una fuente clara
• un periodo definido
• variables identificadoras
• una base reproducible
• tablas y gráficos que salgan desde código
• decisiones metodológicas documentadas.

Tema del ejercicio

Trabajaremos con información de Transparencia Activa municipal.

En particular:

Remuneraciones mensuales informadas por municipios, desde marzo de 2023 hasta marzo de 2026, según disponibilidad.

Tipos de personal incluidos

Para el trabajo del curso se considerarán los cuatro tipos de personal:

Criterio común

El análisis principal debe incluir los cuatro tipos de personal, pero siempre distinguiendo el tipo de vínculo contractual.

No se debe mezclar planta, contrata, Código del Trabajo y honorarios como si fueran equivalentes.

Unidad institucional

Transparencia Activa puede separar la información en:

• Municipalidad
• Departamento de Administración de Educación Municipal
• Departamento de Salud.

Para el póster, el criterio base será trabajar con:

Municipalidad como unidad institucional principal.

¿Por qué con Municipalidad?

Porque permite mantener mayor comparabilidad.

DAEM y Salud tienen:

• funciones sectoriales distintas
• dotaciones más especializadas
• composiciones ocupacionales diferentes
• escalas y cargos no siempre comparables con la administración municipal general.

Nombres de archivos

Cada grupo descargará varios archivos por mes y por tipo de personal (desde la web de transparencia de su municipio).

Obligatoriamente, guardaremos los archivos en una carpeta llamada “datos_raw” dentro de nuestro proyecto, y los archivos se denominaran con una estructura común:

municipio_tipo_mes_anio.csv

Ejemplos:

vilcun_planta_marzo_2026.csv
vilcun_contrata_marzo_2026.csv
vilcun_cdt_marzo_2026.csv
vilcun_honorarios_marzo_2026.csv

Nombres que debemos evitar

archivo1.csv
remuneraciones.csv
datos.csv
marzo.csv
final.csv

¿Por qué el nombre del archivo no basta?

Porque cuando unimos muchos archivos en una sola base, el nombre del archivo deja de estar visible.

Por eso, cada fila debe conservar información mínima sobre su origen.

Variables identificadoras obligatorias

Cada archivo debe incorporar estas variables antes de unirse:

¿Qué pasa si no agregamos identificadores?

Cuando unimos los archivos, perdemos trazabilidad.

Después no sabremos:

• si una fila viene de planta, contrata, CDT u honorarios
• si corresponde a marzo de 2026 u otro periodo
• si pertenece a Municipalidad, DAEM o Salud
• desde qué archivo fue cargada.

Estructura recomendada del proyecto

proyecto_poster/
├── datos_raw/
│   ├── planta_marzo_2026.csv
│   ├── contrata_marzo_26.csv
│   ├── cdt_marzo_26.csv
│   └── honorarios_26.csv
├── datos_clean/
├── outputs/
├── scripts/
└── poster.qmd

Dos formas de combinar bases

Hoy distinguiremos dos operaciones:

Tipos de unión de bases de datos

No todas las uniones de bases sirven para lo mismo.
Antes de elegir un comando, debemos preguntarnos:

¿Queremos sumar registros o queremos agregar información?

bind_rows()

Usamos bind_rows() cuando tenemos archivos con registros similares y queremos construir una sola base larga.

remuneraciones <- bind_rows(
  planta_simple,
  contrata_simple,
  cdt_simple,
  honorarios_simple
)

¿Qué hace bind_rows()?

Imaginemos cuatro bases:

planta
contrata
cdt
honorarios

Cada una contiene registros mensuales de personas o prestaciones informadas.

Con bind_rows() obtenemos:

remuneraciones
├── registros de planta
├── registros de contrata
├── registros de Código del Trabajo
└── registros de honorarios

¿Cuándo usamos join?

Usamos join cuando queremos agregar columnas desde otra base.

Por ejemplo, una base auxiliar de municipios:

Ejemplo de left_join()

remuneraciones <- remuneraciones |>
  left_join(datos_municipio, by = "municipio")

Esto no suma más personas.

Agrega columnas de contexto a los registros existentes.

En fácil

Si quiero sumar registros, uso bind_rows().

Si quiero agregar información (variables) sobre esos registros, uso join.

¿Cuál usaremos en el ejercicio?

Para construir la base de remuneraciones usaremos principalmente:

bind_rows()

Porque queremos apilar archivos mensuales y tipos de personal.

Los join los revisaremos como herramienta complementaria.

Datos reales de ejemplo

En el laboratorio usaremos archivos tipo de Vilcún (pueden usar los de su municipio):

planta_marzo_2026.csv
contrata_marzo_26.csv
cdt_marzo_26.csv
honorarios_26.csv

Estos archivos tienen estructuras parecidas, pero no idénticas.

Columnas frecuentes en planta y contrata

Planta y contrata incluyen, entre otras:

• Año
• Mes
• Estamento
• Nombre completo
• Cargo o función
• Grado EUS o jornada
• Calificación profesional o formación
• Remuneración bruta
• Remuneración líquida
• Fecha de inicio
• Fecha de término
• Observaciones.

Honorarios tiene otra estructura

Honorarios incluye, entre otras:

• Año
• Mes
• Nombre completo
• Descripción de la función
• Calificación profesional o formación
• Honorario Total Bruto del mes
• Honorario Total Líquido del mes
• Tipo de pago
• Número de cuotas
• Fecha de inicio
• Fecha de término
• Observaciones.

Problema metodológico

No podemos unir directamente bases con estructuras distintas sin tomar decisiones.

Necesitamos crear nombres comunes.

Base final esperada

Una vez procesados los archivos, la base debería tener columnas como:

municipio
unidad
tipo_personal
anio
mes
mes_num
periodo
nombre
estamento
funcion
formacion
monto_bruto
monto_liquido
fecha_inicio
fecha_termino
observaciones
archivo_origen

¿Qué hacemos con columnas que no existen?

Algunas columnas existen en una base, pero no en otra.

Por ejemplo:

• honorarios no tiene estamento
• planta y contrata no tienen tipo_pago
• CDT puede tener columnas distintas de horas extra.

En esos casos, se puede crear la columna con NA.

estamento = NA_character_

Limpieza de montos

Los montos suelen venir como texto:

$ 1.737.854
-
No informa

Antes de calcular promedios, medianas o totales, deben transformarse a números.

Ejemplo de limpieza

limpiar_monto <- function(x) {
  x |>
    str_remove_all("\\$") |>
    str_remove_all("\\.") |>
    str_trim() |>
    na_if("-") |>
    na_if("") |>
    na_if("No informa") |>
    as.numeric()
}

¿Qué tablas podemos construir?

Una vez unida la base, podemos construir tablas como:

• número de registros por tipo de personal
• remuneración promedio por tipo de personal
• remuneración mediana por tipo de personal
• casos sin monto informado
• comparación entre planta, contrata, CDT y honorarios.

Tabla descriptiva esperada

Cómo interpretar la tabla

Una buena interpretación debe incluir:

1. qué muestra la tabla
2. qué resultado destaca
3. qué cifra respalda el resultado
4. qué precaución metodológica debe considerarse.

Ejemplo de interpretación

La tabla resume las remuneraciones brutas informadas por tipo de vínculo contractual en la Municipalidad de Vilcún durante marzo de 2026. Permite observar diferencias descriptivas en el número de registros y en los montos informados entre planta, contrata, Código del Trabajo y honorarios. Sin embargo, estas diferencias deben interpretarse con cautela, porque los tipos de vínculo no necesariamente corresponden a funciones, jornadas o responsabilidades equivalentes.