Errores frecuentes en el modelado conceptual
Un diagrama puede ser correcto desde el punto de vista gráfico y, aun así, representar mal el dominio. Los siguientes errores aparecen con frecuencia al construir modelos E/R.
1. Convertir mecánicamente sustantivos y verbos #
La gramática solo proporciona pistas. No todo sustantivo es una entidad ni todo verbo es una relación.
En «el cliente realiza una compra», Cliente suele ser una entidad y realiza sugiere una relación. Sin embargo, Compra podría modelarse como una entidad si el negocio necesita identificarla, conservar su estado, registrar su fecha o relacionarla con pagos y devoluciones.
La decisión depende de las reglas del dominio:
- Si solo importa la asociación entre Cliente y Producto, compra puede ser una relación con atributos.
- Si cada compra tiene identidad, ciclo de vida y relaciones propias, puede justificarse como entidad.
El error consiste en decidir por la forma de la palabra en lugar de analizar su significado.
2. Modelar como entidad lo que es un atributo #
Un elemento descriptivo no necesita convertirse en entidad si no tiene identidad ni relaciones propias.
Por ejemplo, Color puede ser un atributo de Vehículo si únicamente se registra su valor. Podría convertirse en entidad si el dominio mantiene un catálogo de colores con código, descripción, fabricante y relaciones adicionales.
Pregunta de comprobación: «¿Necesitamos distinguir y describir este elemento por sí mismo, además de utilizarlo como valor?».
3. Sustituir incorrectamente una relación ternaria por relaciones binarias #
Supongamos que un Proveedor suministra un Producto para un Proyecto, y que la cantidad acordada depende de la combinación de los tres participantes.
La relación ternaria:
Proveedor suministra Producto para Proyecto
no equivale necesariamente a estas tres relaciones binarias:
- Proveedor suministra Producto.
- Proveedor participa en Proyecto.
- Proyecto utiliza Producto.
Las relaciones binarias indican qué pares están asociados, pero pueden generar combinaciones que nunca existieron y no permiten saber a qué triple pertenece la cantidad acordada. Una relación de grado tres solo debe descomponerse cuando las reglas del dominio demuestren que no se pierde información.
4. Confundir entidad débil con dependencia existencial #
Que una entidad no pueda existir sin otra no significa necesariamente que sea débil.
- Pedido puede depender de Cliente para existir, pero si posee un identificador global propio, su dependencia es existencial y no de identificación.
- Línea de pedido puede ser débil si su número de línea solo es único dentro de un Pedido. Necesita el identificador del pedido y su clave parcial para quedar identificada.
Una entidad es débil cuando necesita a otra entidad para completar su identificación, no solo porque exista una regla que condicione su existencia.
5. Leer la cardinalidad en una sola dirección #
La frase «un departamento tiene muchos empleados» no basta para completar la relación. También debemos preguntar cuántos departamentos puede tener un empleado y si ambas participaciones son obligatorias.
Cada relación debe leerse en los dos sentidos:
- Para una ocurrencia de A, ¿cuántas ocurrencias de B puede o debe haber?
- Para una ocurrencia de B, ¿cuántas ocurrencias de A puede o debe haber?
6. Confundir “puede” con “debe” #
«Un socio puede realizar préstamos» indica que la participación mínima de Socio podría ser cero. «Todo préstamo debe pertenecer a un socio» indica participación mínima uno para Préstamo.
Omitir la participación mínima hace que el modelo no distinga entre relaciones opcionales y obligatorias.
7. Colocar un atributo en la entidad equivocada #
Si el valor depende de una asociación concreta, debe pertenecer a la relación o al acontecimiento que la representa.
Por ejemplo, fecha_asignación no describe por sí sola a Empleado ni a Proyecto: describe la asignación de un empleado concreto a un proyecto concreto.
8. Guardar como independiente un dato derivable sin justificarlo #
La edad cambia con el tiempo y puede calcularse a partir de la fecha de nacimiento. Modelarla como atributo almacenado puede producir incoherencias. Debe representarse como derivado, salvo que el dominio necesite conservar la edad declarada en un momento determinado.
9. Duplicar conceptos por falta de vocabulario común #
Si unas personas utilizan «Cliente» y otras «Comprador», pueden aparecer dos entidades para el mismo concepto. También puede ocurrir lo contrario: utilizar «Usuario» para conceptos diferentes, como Socio y Empleado.
El glosario del dominio debe resolver sinónimos y homónimos antes de consolidar el diagrama.
10. Introducir decisiones técnicas demasiado pronto #
Tablas intermedias, claves foráneas, índices y tipos específicos de un SGBD pertenecen a fases posteriores. En el modelo conceptual debemos expresar entidades, identificadores, relaciones y restricciones del dominio sin depender de cómo se implementarán.
11. Preguntas para revisar un posible error #
Antes de aceptar una decisión de modelado, conviene preguntar:
- ¿Qué requisito o regla de negocio justifica este elemento?
- ¿Podemos explicar su significado sin hablar de tablas ni código?
- ¿La relación conserva su significado al leerla en ambos sentidos?
- ¿Los mínimos y máximos están confirmados o son supuestos?
- ¿Un ejemplo válido puede representarse sin contradicciones?
- ¿El modelo rechaza los casos que el negocio considera inválidos?