Mentalidad de Modelado de Datos para Bases de Datos Profesionales

Propósito del modelado de datos en contextos reales

Modelar datos no es “dibujar tablas”: es construir una representación explícita del negocio que permita almacenar, consultar y gobernar información sin interpretaciones contradictorias. En un entorno profesional, el propósito principal es reducir ambigüedades (qué significa cada cosa), habilitar decisiones (qué se puede medir y cómo) y disminuir costos de cambio (que el sistema evolucione sin romperse).

Una mentalidad útil es pensar el modelo como un contrato: define qué se guarda, con qué significado, bajo qué reglas y con qué límites. Si el contrato es débil, el sistema termina “adivinando” con datos incompletos, duplicados o inconsistentes.

Señales de que falta mentalidad de modelado

• Dos áreas usan la misma palabra para cosas distintas (por ejemplo, “cliente” como persona vs. “cliente” como cuenta).
• Se guardan valores “por si acaso” sin definición (por ejemplo, un campo estado sin lista de valores ni reglas).
• Las reglas viven solo en el código o en la cabeza de alguien (por ejemplo, “un pedido no puede facturarse si no está aprobado”).
• Se duplican datos sin justificar (por ejemplo, dirección del cliente repetida en múltiples lugares sin motivo).

Vocabulario mínimo y su traducción a componentes de base de datos

Para modelar con precisión, conviene acordar un vocabulario mínimo y mapearlo a elementos concretos de una base de datos. Esto evita discusiones abstractas y ayuda a validar el diseño con personas no técnicas.

Regla mental: “si no lo puedes definir, no lo puedes modelar”

Antes de crear un atributo o entidad, exige una definición operativa: cómo se obtiene, cuándo cambia, quién lo usa y qué pasa si falta. Esto reduce campos “misteriosos” que luego se vuelven deuda técnica.

Levantamiento de requerimientos orientado a reglas de negocio

Un levantamiento efectivo no empieza preguntando “¿qué tablas necesitas?”, sino “¿qué decisiones se toman y qué hechos deben quedar registrados para soportarlas?”. El foco está en reglas de negocio, eventos y conceptos, porque son los que determinan qué datos existen, cómo se relacionan y qué restricciones aplican.

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

Qué buscar: conceptos, eventos y decisiones

• Conceptos: sustantivos del dominio que deben persistir (Cliente, Contrato, Producto, Sucursal).
• Eventos: cosas que ocurren y dejan rastro (Pedido creado, Pago recibido, Envío despachado, Devolución aprobada).
• Decisiones: condiciones que cambian el flujo y requieren evidencia (aprobaciones, límites de crédito, elegibilidad, estados).

Guía práctica paso a paso (entrevista + extracción de reglas)

1. Define el objetivo del modelo: qué procesos cubre y qué preguntas debe responder. Ejemplo: “Registrar el ciclo de vida de pedidos y pagos para facturación y conciliación”.

2. Lista actores y fuentes: quién conoce las reglas (operaciones, finanzas, soporte) y qué sistemas ya existen (CRM, ERP, planillas).

3. Recolecta lenguaje del negocio: captura términos tal como los dicen. No los “traduces” aún. Marca sinónimos y homónimos.

4. Identifica eventos clave: pide que describan el proceso como una secuencia de eventos. Para cada evento, pregunta: “¿qué se registra?”, “¿quién lo ejecuta?”, “¿qué lo dispara?”, “¿qué lo invalida?”.

5. Extrae reglas en formato verificable: convierte frases vagas en reglas testables. Ejemplo: de “un pedido debe estar completo” a “un pedido no puede pasar a estado APROBADO si no tiene al menos un ítem y dirección de entrega”.

6. Detecta cardinalidades y opcionalidades: “¿un cliente puede tener cero pedidos?”, “¿un pedido puede tener varios pagos?”, “¿un pago puede aplicarse a varios pedidos?”.

7. Define identificadores y unicidad: qué hace único a cada entidad (natural vs. surrogate). Ejemplo: “email es único por cliente” o “el cliente se identifica por id_cliente y el email puede cambiar”.

8. Clasifica atributos: obligatorios vs. opcionales, derivados vs. almacenados, sensibles vs. no sensibles. Ejemplo: total_pedido ¿se calcula de ítems o se guarda por auditoría?

9. Valida con escenarios: prueba el modelo con casos reales y bordes. Ejemplo: “pedido sin pago”, “pago parcial”, “devolución después de facturar”.

Ejemplo: convertir conversación en reglas y estructura

Entrada (lenguaje natural): “Un cliente puede hacer varios pedidos. Un pedido puede pagarse en varias partes. No aceptamos pagos negativos. El email identifica al cliente, pero a veces cambia.”

Salida (reglas y componentes):

• Entidad Cliente con id_cliente como identificador técnico; atributo email con restricción de unicidad (si el negocio lo exige) o historial si cambia con frecuencia.
• Entidad Pedido relacionada 1:N con Cliente.
• Entidad Pago relacionada N:1 con Pedido (o N:M si un pago puede aplicarse a varios pedidos).
• Restricción: Pago.monto > 0 (CHECK) y moneda definida.

Reglas (formato verificable)  R1: Un Cliente puede tener 0..N Pedidos.  R2: Un Pedido debe pertenecer a 1 Cliente.  R3: Un Pedido puede tener 0..N Pagos.  R4: Un Pago debe pertenecer a 1 Pedido.  R5: El monto de Pago debe ser > 0.  R6: El email de Cliente puede cambiar; se define si se guarda historial o solo el valor actual.

Plantilla de especificación del modelo (para trabajo profesional)

Además del diagrama, un modelo profesional se acompaña de una especificación breve pero completa. Esto mejora la comunicación, facilita revisiones y permite trazabilidad entre requerimientos y diseño.

Plantilla sugerida

1) Alcance

• Procesos incluidos (ej.: pedidos, pagos, devoluciones).
• Procesos excluidos (ej.: logística avanzada, contabilidad general).
• Granularidad temporal (ej.: se registran eventos con fecha/hora; zona horaria).

2) Supuestos

• Supuestos operativos (ej.: “un pedido se factura en una sola moneda”).
• Supuestos de integración (ej.: “clientes provienen del CRM y se sincronizan cada 15 min”).
• Supuestos de calidad de datos (ej.: “email puede venir vacío en leads, pero no en clientes activos”).

3) Glosario de términos

4) Catálogo de entidades y atributos

Para cada entidad:

• Definición de negocio.
• Identificador (PK) y claves alternativas (si aplica).
• Atributos con: tipo, obligatoriedad, dominio/valores permitidos, si es derivado, sensibilidad.
• Relaciones: cardinalidad, opcionalidad, reglas de borrado/retención.

5) Reglas de negocio (numeradas)

Lista de reglas en formato testable, numeradas para trazabilidad.

R1: Un Pedido no puede estar en estado APROBADO si no tiene al menos 1 ítem. R2: El monto de Pago debe ser > 0. R3: Un Cliente activo debe tener email no nulo.

6) Decisiones de diseño y justificación

• Qué se normaliza vs. qué se duplica y por qué (rendimiento, auditoría, integración).
• Campos derivados almacenados (si aplica) y mecanismo de consistencia.
• Estrategia de historial (SCD, tablas de auditoría, eventos).

7) Trazabilidad

Matriz simple que conecte requerimientos/reglas con elementos del modelo.

Criterios de calidad del modelo

1) Consistencia

El mismo concepto se representa de una sola manera y con reglas coherentes. Indicadores prácticos:

• Los nombres siguen un patrón (ej.: fecha_creacion en todas las entidades, no createdAt mezclado).
• Los dominios son uniformes (monedas, estados, unidades).
• Las relaciones no se contradicen (si Pedido requiere Cliente, no existe un flujo que cree pedidos huérfanos).

2) Completitud

El modelo cubre los requerimientos del alcance sin huecos. Verificación práctica:

• Cada evento importante deja rastro (quién, cuándo, qué cambió).
• Las decisiones del proceso tienen datos para justificarse (aprobaciones, motivos, límites).
• Los atributos obligatorios están identificados y respaldados por restricciones o reglas.

3) Trazabilidad

Se puede explicar por qué existe cada entidad/atributo y qué regla o requerimiento lo respalda. Prácticas:

• Reglas numeradas y referenciadas en el catálogo.
• Matriz regla → restricción/tabla/columna.
• Historial de cambios del modelo (qué cambió y por qué).

4) Ausencia de redundancias injustificadas

No se duplican datos sin una razón explícita. Cuando se duplica, se documenta el motivo y el mecanismo de sincronización.

• Redundancia injustificada: guardar total_pedido y también subtotal y impuestos sin reglas claras de cálculo y actualización.
• Redundancia justificada: guardar total_pedido por auditoría (valor “congelado” al momento de facturar) y documentar que no se recalcula.

Checklist rápido de revisión (para reuniones de validación)

• ¿Cada término del glosario aparece con el mismo significado en todo el modelo?
• ¿Cada regla importante está implementada como restricción en BD o como regla documentada con su punto de control?
• ¿Hay campos “genéricos” (dato1, observaciones, estado) sin dominio definido?
• ¿Las cardinalidades reflejan la realidad (incluyendo excepciones)?
• ¿La duplicación de datos está justificada y controlada?