Validación del Modelo de Datos con Casos Reales y Pruebas de Consistencia

Qué significa “validar” un modelo de datos

Validar un modelo de datos es demostrar, con evidencia práctica, que el modelo soporta los casos reales del negocio sin ambigüedades y que sus restricciones se comportan como se espera ante datos válidos e inválidos. No es solo “revisar el diagrama”: implica ejecutar escenarios, crear datos de ejemplo, forzar errores controlados y confirmar que las cardinalidades, reglas y dependencias se reflejan en el esquema lógico y en el comportamiento de inserciones, actualizaciones y borrados.

Método de verificación: del caso de uso a la prueba

Paso 1: Recorrer casos de uso y convertirlos en historias verificables

El punto de partida es una lista corta de casos de uso reales (no genéricos) y su traducción a acciones sobre datos. Para cada caso de uso, define: (1) qué se crea/consulta/actualiza/borra, (2) qué reglas aplican, (3) qué resultado es aceptable y qué debe ser rechazado.

• Formato recomendado: “Como [rol], quiero [acción] para [objetivo], cumpliendo [reglas]”.
• Salida: una tabla de “caso de uso → operaciones → reglas → pruebas”.

Paso 2: Preparar un dataset mínimo de ejemplo (semilla)

Crea un conjunto pequeño de datos que cubra el flujo normal del negocio. La idea es que sea lo suficientemente pequeño para inspeccionarlo a mano, pero lo bastante variado para activar reglas y cardinalidades.

• Incluye al menos: 1 registro “base” por entidad principal, 2–3 registros por entidad transaccional, y referencias cruzadas que ejerciten relaciones obligatorias y opcionales.
• Incluye valores “típicos” y valores “cercanos al límite” (por ejemplo, longitudes máximas, fechas en fin de mes, montos 0, etc.).

Paso 3: Comprobar restricciones y cardinalidades con datos reales

Para cada relación y restricción importante, define una verificación explícita: qué dato insertas/actualizas/borras y qué esperas que ocurra (éxito o error). Esto evita validaciones “por intuición”.

• Cardinalidades: prueba el mínimo y el máximo (por ejemplo, “0..1”, “1..N”).
• Obligatoriedad: prueba nulos donde no deberían permitirse.
• Unicidad: intenta duplicar valores que deberían ser únicos.
• Integridad referencial: intenta referenciar padres inexistentes y borrar padres con hijos.

Conjunto de pruebas de consistencia (test suite)

Un conjunto de pruebas es una lista repetible de operaciones SQL (o del motor que uses) que valida el comportamiento del modelo. Idealmente se ejecuta cada vez que el modelo cambia. A continuación se muestra una plantilla práctica usando un dominio de ejemplo (ventas): cliente, pedido, linea_pedido, producto.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

1) Pruebas de inserción (válidas e inválidas)

Ejemplos de SQL (ajusta nombres y tipos a tu esquema):

-- Inserción válida (semilla mínima) INSERT INTO cliente (cliente_id, email) VALUES (1, 'ana@correo.com'); INSERT INTO producto (producto_id, sku, precio) VALUES (10, 'SKU-001', 19.99); INSERT INTO pedido (pedido_id, cliente_id, fecha) VALUES (100, 1, '2026-01-10'); INSERT INTO linea_pedido (pedido_id, producto_id, cantidad, precio_unitario) VALUES (100, 10, 2, 19.99);  -- Inserción inválida: cliente inexistente (FK) INSERT INTO pedido (pedido_id, cliente_id, fecha) VALUES (101, 999, '2026-01-10');  -- Inserción inválida: SKU duplicado (UNIQUE) INSERT INTO producto (producto_id, sku, precio) VALUES (11, 'SKU-001', 25.00);  -- Inserción inválida: cantidad no permitida (CHECK) INSERT INTO linea_pedido (pedido_id, producto_id, cantidad, precio_unitario) VALUES (100, 10, 0, 19.99);

2) Pruebas de borrado (DELETE) y efectos en dependencias

El borrado es donde más inconsistencias aparecen. Define explícitamente la política esperada por relación: RESTRICT (no permitir), CASCADE (propagar), o “borrado lógico” (marcar estado).

-- Si el modelo usa RESTRICT: debería fallar si existen dependencias DELETE FROM cliente WHERE cliente_id = 1;  -- Si el modelo usa CASCADE en pedido->linea_pedido: borrar pedido debería borrar sus líneas DELETE FROM pedido WHERE pedido_id = 100;

3) Pruebas de actualización (UPDATE) y estabilidad de claves

Las actualizaciones deben comprobar dos cosas: (1) que los cambios permitidos no rompen reglas, y (2) que los cambios prohibidos realmente se bloquean. En particular, prueba actualizaciones sobre claves naturales/candidatas, estados y campos usados para trazabilidad.

• Actualizar a valor inválido: email sin formato, precio negativo, estado inexistente.
• Actualizar un identificador (si existe): confirmar si está prohibido o si propaga correctamente.
• Cambio de estado: probar transiciones válidas e inválidas (por ejemplo, de “CANCELADO” a “PAGADO”).

-- Actualización inválida por CHECK (precio no puede ser negativo) UPDATE producto SET precio = -1 WHERE producto_id = 10;  -- Actualización que podría violar UNIQUE (duplicar email) UPDATE cliente SET email = 'ana@correo.com' WHERE cliente_id = 2;

4) Escenarios límite (edge cases) que suelen romper modelos

• Cardinalidad mínima: entidades que requieren al menos un hijo (por ejemplo, pedido debe tener ≥1 línea). Si el motor no lo garantiza solo con FK, define cómo se valida (transacción, trigger, constraint diferida, o validación en capa de aplicación) y pruébalo.
• Fechas y rangos: fin de mes, años bisiestos, zonas horarias si aplica, “fecha_fin < fecha_inicio”.
• Longitudes máximas: textos al límite del tipo, caracteres especiales, normalización de mayúsculas/minúsculas si afecta unicidad.
• Montos y precisión: redondeos, 0, valores muy grandes, moneda.
• Concurrencia lógica: dos operaciones que intentan crear el mismo “único” (por ejemplo, mismo SKU) para confirmar que la unicidad está en la base y no solo en la UI.

Cómo revisar el modelo con stakeholders (preguntas orientadas a negocio)

La revisión con stakeholders busca reducir interpretaciones. En lugar de preguntar “¿está bien el diagrama?”, usa preguntas que obliguen a confirmar reglas, excepciones y vocabulario. Documenta las respuestas como reglas trazables (ID de regla) y enlázalas a tablas/columnas/constraints.

Preguntas para descubrir ambigüedades

• Definiciones: “Cuando dices ‘cliente’, ¿incluye prospectos? ¿un cliente puede ser empresa y persona a la vez?”
• Unicidad real: “¿Qué identifica de forma única a un producto en el negocio: SKU, código interno, combinación de atributos?”
• Obligatoriedad: “¿Puede existir un pedido sin líneas? Si existe temporalmente, ¿por cuánto tiempo y en qué estado?”
• Historial: “¿Necesitan conservar cambios de precio/dirección/estado? Si sí, ¿qué eventos y con qué granularidad?”
• Excepciones: “¿Qué casos raros ocurren en operación? (devoluciones parciales, pedidos sin pago, productos descontinuados)”
• Borrado: “¿Se puede eliminar un cliente/pedido o solo se anula? ¿por auditoría o normativa?”
• Reglas de cálculo: “¿El total del pedido se guarda o se calcula? Si se guarda, ¿cuál es la fuente de verdad?”

Técnica práctica: “ejemplos concretos antes que opiniones”

Lleva 3–5 ejemplos reales (anonimizados) y recórrelos con el stakeholder: “Con este caso, ¿qué registros existirían? ¿Qué campos serían obligatorios? ¿Qué no debería permitirse?”. Cada respuesta se convierte en una prueba del test suite.

Lista de chequeo final (antes de aprobar el modelo)

Claves

• ¿Cada tabla tiene clave primaria definida y estable?
• ¿Las claves candidatas (negocio) están protegidas con UNIQUE cuando corresponde?
• ¿Las claves foráneas están completas (mismo dominio/tipo) y con índices si aplica al uso?

Nulabilidad

• ¿Los campos obligatorios del negocio están en NOT NULL?
• ¿Los campos opcionales realmente pueden ser nulos sin romper reportes o procesos?
• ¿Se evita usar NULL para representar estados (por ejemplo, “no aplica”) cuando conviene un catálogo/estado explícito?

Unicidad

• ¿La unicidad está definida donde el negocio lo exige (email, SKU, folio, combinación de columnas)?
• ¿Se consideró sensibilidad a mayúsculas/minúsculas y normalización si afecta duplicados?

Dependencias e integridad referencial

• ¿Toda relación importante está respaldada por FK (o una estrategia equivalente si hay particiones/replicación)?
• ¿La política de borrado/actualización está definida por relación (RESTRICT/CASCADE/SET NULL/borrado lógico) y probada?
• ¿Se previenen registros huérfanos en tablas dependientes?

Nomenclatura

• ¿Nombres consistentes (singular/plural, prefijos, sufijos, idioma) y sin ambigüedad?
• ¿Columnas con significado claro (evitar valor1, dato_extra)?
• ¿Convenciones para PK/FK (por ejemplo, cliente_id) aplicadas de forma uniforme?

Trazabilidad de reglas

• ¿Cada regla de negocio relevante tiene un identificador y descripción?
• ¿Cada regla está mapeada a su implementación (constraint, FK, trigger, procedimiento, validación en aplicación) y a su prueba?
• ¿Existen pruebas para reglas críticas y para excepciones conocidas?

Documentación completa (artefactos mínimos)

• ER: diagrama actualizado con entidades/relaciones y notas de reglas clave.
• Esquema lógico: definición de tablas, PK, FK, UNIQUE, CHECK, tipos, defaults.
• Diccionario de datos: por columna: definición de negocio, tipo, nulabilidad, dominio/valores permitidos, ejemplo, regla asociada (ID), origen del dato y responsable.

Plantilla rápida: matriz “Regla → Implementación → Prueba”

Usa esta matriz para asegurar que nada queda “en el aire”.

Guía práctica paso a paso para ejecutar la validación en un sprint

1. Selecciona 5–8 casos de uso de mayor impacto (alta frecuencia o alto riesgo).

2. Deriva reglas verificables por caso de uso (obligatoriedad, unicidad, dependencias, estados).

3. Construye dataset semilla (mínimo) y dataset de borde (edge cases).

4. Escribe el test suite con: inserciones válidas, inserciones inválidas, updates válidos/ inválidos, deletes según política.

5. Ejecuta pruebas y registra hallazgos: cada fallo debe indicar si es (a) error del modelo, (b) regla no implementada, (c) regla mal entendida, (d) prueba incorrecta.

6. Revisión con stakeholders usando ejemplos concretos y preguntas orientadas a negocio; actualiza reglas y su trazabilidad.

7. Actualiza artefactos (ER, esquema lógico, diccionario) para que reflejen exactamente lo implementado y probado.