Estructuras y relaciones: maestros, movimientos y parámetros

¿Qué ocurre cuando repites el nombre y la ciudad de un cliente dentro de cada una de sus cien facturas y un día el cliente se muda? Si cambias su ciudad solo en la última factura, el sistema tendrá dos respuestas contradictorias para la misma pregunta. Para evitarlo, un sistema organiza sus datos en estructuras relacionadas con responsabilidades distintas.

Objetivos y conocimientos previos

Partiendo de Identidad, tipos y dominio de valores, aprenderás a clasificar los conjuntos de datos en maestros, movimientos y parámetros, a conectar registros mediante claves de referencia y a explicar por qué la normalización y la integridad referencial evitan contradicciones.

Niveles de agrupación lógica

Desde el punto de vista lógico, los datos estructurados se agrupan en niveles progresivos:

1. Atributo (o campo): una propiedad individual con tipo y dominio definidos (importe_centimos, ciudad).
2. Registro (o entidad individual): la agrupación de atributos que describen un único individuo o suceso identificado por su clave (Cliente C-101, Factura F-501).
3. Colección (o tabla/archivo lógico): el conjunto de todos los registros de una misma clase que obedecen al mismo esquema (Clientes, Facturas).
4. Base de datos del sistema: el conjunto coordinado de colecciones y las reglas que gobiernan sus relaciones.

Las tres funciones de los datos en un sistema

En casi cualquier aplicación de gestión —desde reservas hasta comercio o control de gastos—, las colecciones de datos cumplen una de estas tres funciones fundamentales:

Separar estas tres funciones permite analizar de un vistazo cualquier sistema nuevo que te pidan construir o revisar.

Relaciones y por qué no debemos duplicar datos (Normalización)

Imagina que guardamos los gastos o facturas en una sola tabla plana que mezcla datos del movimiento con datos del maestro:

Esta tabla presenta tres anomalías lógicas:

1. Anomalía de actualización / contradicción: ¿Ana López vive en Rosario o en Córdoba? Al repetir nombre_cliente y ciudad_cliente en cada movimiento, abrimos la puerta a datos inconsistentes.
2. Anomalía de inserción: No podemos registrar a un cliente nuevo hasta que no le emitamos su primera factura.
3. Anomalía de borrado: Si anulamos y borramos la única factura de un cliente, perdemos también los datos de contacto del cliente.

La solución lógica consiste en separar la entidad maestra del movimiento y relacionarlas únicamente a través del identificador (id_cliente):

• En Clientes (Maestro), id_cliente es la clave primaria (identifica al cliente sin repetición).
• En Facturas (Movimiento), id_factura es la clave primaria de la factura, mientras que id_cliente actúa como clave foránea (referencia): apunta al registro único de Clientes.

Atención: cuándo un dato histórico sí debe conservarse en el movimiento

No todo dato repetido es un error de diseño; hay que distinguir un atributo actual de un hecho histórico del movimiento:

• Si Clientes guarda la dirección actual de Ana, pero la ley exige que la factura F-01 conserve la dirección fiscal exacta que Ana tenía el día en que se emitió en 2024, entonces la factura debe conservar ese dato histórico de emisión (o apuntar a una versión fechada de sus datos fiscales).
• Del mismo modo, si el precio de un producto en el catálogo maestro sube hoy de 10 EUR a 15 EUR, las facturas del mes pasado no deben recalcularse a 15 EUR: el movimiento debe registrar el precio aplicado en el momento de la operación.

La regla lógica es clara: referencia al maestro para saber quién es la entidad; registra en el movimiento los valores que deben quedar congelados como parte del hecho histórico.

Integridad referencial

Conectar dos colecciones mediante un identificador exige una regla adicional llamada integridad referencial:

Ningún movimiento puede apuntar a un identificador maestro inexistente.

Esto implica dos comprobaciones obligatorias:

1. Al crear el movimiento: No se puede emitir una factura para el cliente C-999 si C-999 no existe en Clientes.
2. Al intentar eliminar un maestro: Si el cliente C-101 tiene facturas registradas, el sistema no puede borrar sin más a C-101 de la tabla Clientes, porque dejaría facturas huérfanas apuntando a un cliente fantasma. En su lugar, debe impedir el borrado físico y ofrecer una desactivación lógica (activo: falso).

Practica

En el caso de estudio de un Sistema de Control de Gastos Personales, queremos registrar cada gasto diario, clasificarlo por categoría (Alimentación, Transporte, Vivienda, Salud, etc.) y comparar el gasto mensual de cada categoría contra un presupuesto máximo mensual definido por el usuario.

1. Clasifica qué colecciones serían Maestros, cuáles Movimientos y cuáles Parámetros (o configuración).
2. Define los atributos esenciales de cada colección e indica qué campo sirve como clave de identidad y cuál como referencia (clave foránea).
3. Explica qué pasaría si en el archivo de movimientos de gastos guardásemos el texto "Alimentación" en lugar del código de referencia a la tabla de categorías, y un día quisiéramos renombrar esa categoría o consultar su presupuesto.
4. Indica qué debe hacer el sistema si el usuario intenta borrar una categoría en la que ya existen gastos registrados en enero.

Criterio de comprensión: debes separar al menos la colección maestra de Categorías y la colección de movimientos de Gastos vinculadas por el identificador de categoría, e incluir una regla explícita de integridad referencial que impida dejar gastos apuntando a una categoría inexistente.

Profundiza con IA

Este es mi modelo de colecciones y relaciones para el Sistema de Control de Gastos: [tu respuesta]. Revisa si hay datos duplicados innecesariamente o si, por el contrario, algún valor histórico podría cambiar por accidente al modificar un maestro o un parámetro (por ejemplo, si cambia el presupuesto el mes que viene). Plantea un caso concreto para poner a prueba mi diseño.

Siguiente lectura

Una vez estructurados los datos y sus relaciones, ¿cómo cambian a lo largo del tiempo sin perder trazabilidad? Continúa con Ciclo de vida del dato, estado y operaciones.