Identidad, tipos y dominio de valores

¿Cómo sabe un sistema que «Ana López» que hoy cambia de correo electrónico sigue siendo la misma clienta del mes pasado, y no una persona nueva? Para que los datos representen la realidad sin confundir entidades ni aceptar valores absurdos, necesitamos definir tres propiedades lógicas: identidad, tipos de datos y dominio de valores.

Objetivos y conocimientos previos

Partiendo de Datos, información y representación, aprenderás a distinguir la identidad de una entidad de sus atributos descriptivos, a elegir tipos de datos conceptuales adecuados (incluidos códigos y enumeraciones) y a declarar restricciones de dominio que protejan la integridad del sistema.

Identidad frente a atributos descriptivos

Dos personas distintas pueden llamarse «Juan Pérez». Además, una misma persona puede cambiar su dirección, su teléfono o incluso su nombre legal a lo largo del tiempo.

Si un sistema utiliza el nombre o el correo como única referencia para unir a un cliente con sus facturas:

• Cuando dos clientes coincidan en nombre, sus facturas se mezclarán.
• Cuando un cliente cambie su correo, parecerá que sus facturas antiguas pertenecen a otra persona.

Por eso distinguimos:

• Identificador (Clave de identidad): un valor único e inmutable dentro del sistema que señala a una entidad concreta (id_cliente: C-00104 o un identificador único universal). Su única función es distinguir esa entidad de cualquier otra, aunque todos sus demás datos cambien.
• Atributos descriptivos: características de la entidad (nombre, ciudad, correo, telefono). Pueden coincidir entre distintos registros o modificarse según las reglas del negocio sin que la entidad deje de ser la misma.
• Identificadores externos o de negocio: documentos oficiales (DNI, NIF), números de serie o códigos de factura legibles. Aunque en el mundo real buscan ser únicos, pueden contener errores de carga inicial o formatos distintos según el país; el modelo debe decidir explícitamente si admiten corrección sin romper la identidad interna del registro.

Tipos de datos conceptuales

Un tipo de dato define la naturaleza lógica de un atributo y qué operaciones tienen sentido sobre él. Más allá de cómo los llame cada lenguaje de programación, al modelar un sistema debes distinguir:

Códigos y conjuntos cerrados (Enumeraciones)

Cuando un atributo solo admite un conjunto predefinido de opciones —como el estado de una reserva o el tipo de comprobante—, permitir texto libre provoca inconsistencias inmediatas: distintos usuarios o procesos escribirán "Activa", "activa", "ACT", "Vigente" o "Confirmada" para referirse a lo mismo.

Un código o enumeración restringe el atributo a una lista cerrada y estandarizada de valores simbólicos:

Usar códigos uniformes evita que una consulta o un informe deje registros fuera por diferencias de escritura o de idioma en la interfaz.

Dominio de valores e invariantes de atributo

El tipo de dato no basta por sí solo. Que importe sea un número entero en céntimos impide guardar la palabra "hola", pero todavía permitiría guardar -50000 o 0.

El dominio de valores añade las restricciones específicas del problema sobre ese tipo:

• capacidad_actividad: número entero mayor que 0 y menor o igual al límite físico de la sala.
• importe_factura_centimos: número entero estrictamente mayor que 0.
• estado_reserva: únicamente uno de los valores {ACTIVA, CANCELADA}.
• fecha_vencimiento: fecha igual o posterior a fecha_emision.

Estas reglas son invariantes de datos: el sistema debe rechazar cualquier entrada o modificación que intente violarlas, venga de un formulario humano, de un archivo importado o de un agente de IA.

Practica

Un agente ha generado el siguiente diseño para la tabla de Facturas:

1. Señala qué problema de identidad tiene este diseño tanto para la factura en sí como para el cliente.
2. Corrige el tipo conceptual de cada campo y explica por qué el tipo elegido por el agente para telefono_cliente, importe, pagada y fecha causará fallos.
3. Define el dominio de valores (qué valores concretos son válidos e inválidos) para el importe y para el estado de la factura.

Criterio de comprensión: debes añadir un identificador único para la factura y una referencia al identificador único del cliente (no solo su nombre), sustituir el texto libre del estado por un conjunto cerrado de valores, exigir representación exacta para el dinero y formato temporal válido para la fecha.

Profundiza con IA

Aquí tienes mi revisión del esquema de Facturas: [tu respuesta]. Actúa como un revisor de diseño de datos: intenta introducir tres registros tramposos que cumplan mis tipos pero violen la lógica de un sistema de facturación real. Pídeme que ajuste mis restricciones de dominio para bloquear esos casos sin darme la respuesta hecha.

Siguiente lectura

Ya sabemos cómo definir los atributos y la identidad de un registro individual. ¿Cómo se conectan las facturas con los clientes y las categorías sin duplicar datos? Continúa con Estructuras y relaciones: maestros, movimientos y parámetros.