Diagramas Entidad Relación (DER): El Enfoque por Hechos y la Metáfora del Agua (página 2)

La idea es simple, lo primero que hay que descubrir son las transacciones o hechos centrales del sistema y a continuación reducirlos a su mínima expresión. Nada mejor que un ejemplo para ilustrar la idea.

El hecho principal de un sistema puede ser la venta, hecho que generalmente encontramos asociado con una factura como documento.

Sin embargo, la factura no es la mínima expresión de la venta, lo mínimo, es la venta de cada ítem de la factura o ticket y podríamos denominar a esa entidad como renglón. En la entidad renglón voy a registrar para la empresa cada cosa que se vendió.

Otro ejemplo, en un hospital la transacción más chica sería cada una de las atenciones, consultas o estudios que se van registrando en la Historia clínica del paciente. En este caso la transacción la podríamos representar con una entidad atención la cual se realizaría a un determinado paciente, por un determinado médico, en tal servicio, en una fecha y hora, y un montón de circunstancias más que rodean a esta transacción y de las cuáles registraremos las que interesen al sistema requerido.

Bien, pero para seguir construyendo el modelo de datos, hagamos un poco de filosofía (siempre es elegante citar a un filósofo). Santo Tomás, en la descripción de los elementos que componen un acto distinguía los siguientes: el objeto (que), el sujeto (quién) y circunstancias que pueden detectarse mediante los adverbios de interrogación: cuándo, cómo, dónde, por qué, para qué, con qué, cuánto, etc.[1]

Pues bien, esto puede servir de orientación para ir encontrando las entidades que rodean al acto o hecho de interés de mi sistema o aplicación. Cada una de esas preguntas nos permitirá ir detectando entidades necesarias para el sistema.

Sin embargo, podemos advertir que en un modelo de datos comercial tenemos verdaderas telarañas de entidades, esto es así por que las circunstancias que registramos son muchas más que las que nombraba el filósofo y a veces registramos las circunstancias de las circunstancias en verdaderas escalas jerárquicas. Por ejemplo, quién compró es una entidad cliente, pero a su vez esta entidad cliente puede pertenecer a una región, a una raza, a una religión, tener un determinado nivel de ingreso, etc. las cuales son circunstancias del cliente que darán lugar a sendas entidades.

Para ser más ilustrativo retomo el ejemplo de la venta y lo amplío:

La entidad renglón es la mínima transacción, pero circunstancialmente puedo vender varios renglones en una misma fecha y a un mismo cliente por lo tanto resulta útil crear una entidad cabecera de factura donde registro esos datos comunes a toda la venta. Las preguntas son cuándo y a quién vendí.

También ocurre que un cliente vuelve varias veces a comprar en mi establecimiento (por suerte), entonces habrá varias facturas de ese cliente, por lo tanto será útil una entidad cliente.

Ilustración 3 -DER 1

A su vez esa entidad cliente puede ser clasificada por varias entidades (clase social, raza, región, religión, profesión, edad, etc.). Todas son circunstancias del cliente: cómo es, de qué raza, de qué religión, en qué trabaja, cuantos años tenía, cual es su nivel social, etc., etc. preguntas que nos pueden interesar en nuestro sistema.

Eligiendo algunas, el DER queda así:

Ilustración 4 – DER 2

En este DER inicial ya debemos tomar en cuenta algo muy importante, las cardinalidades. Cuántas ocurrencias de una entidad se relacionan con cada ocurrencia de la otra entidad.

Bien, podemos notar fácilmente lo siguiente, a medida que nos acercamos a la entidad hecho (renglón en este caso), aumenta la cantidad de ocurrencias de las entidades. El hecho es la mínima entidad, pero la que tiene mayor cantidad de ocurrencias registradas o potenciales.

Luego, cada circunstancia (expresadas por entidades) que lo rodea tiene menos ocurrencias, por que en realidad son rótulos bajo los cuáles podrán clasificarse cierta cantidad de hechos o transacciones (renglones).

A medida que me alejo del hecho, las entidades van agrupando o concentrando las ocurrencias de los hechos.

Así vemos en el ejemplo, que respecto a las cardinalidades, todas las relaciones apuntan de uno a varios, desde las circunstancias hacia el hecho a registrar.

Sucesivamente podemos seguir agregando circunstancias de interés. Por ejemplo el qué de cada transacción, o sea qué es lo que vendí y nos aparece la entidad producto (también podríamos bautizarla catálogo) que se relacionará directamente con cada ocurrencia de renglón. Por supuesto, un producto será vendido en varios renglones (sino el negocio va mal).

Los productos también pueden pertenecer a una categoría, con lo que nos aparece una jerarquía de agrupamiento, una entidad categoría agrupa a varios productos.

Actualizando el diagrama se vería así:

Ilustración 5 – DER 3

Ahora ¿podríamos agregar el dónde se realizó la venta? (factura) y tendremos la entidad sucursal.

Si preguntamos ¿quién compró? tenemos la entidad cliente, pero si preguntamos quién vendió? tenemos la entidad vendedor.

Replanteando nuevamente el diagrama se verá así:

Ilustración 6 – DER 4

Por último hay que revisar sino hay entidades que sean circunstancias de otras ya creadas, plantando nuevas relaciones.

Por ejemplo sucursal es también circunstancia de la entidad vendedor (dónde trabaja?). O sea que varios vendedores trabajan en cada sucursal. Graficamos esa relación.

Finalmente, una corrección más, la localidad puede ser la circunstancia dónde? de varias sucursales por lo cual también podemos relacionar localidad con sucursal además de la relación localidad con cliente.

Ilustración 7 – DER 5

La metáfora del agua

Siguiendo esta línea de buscar nuevos enfoques voy a proponer ahora una metáfora que me parece de gran utilidad para visualizar rápidamente la utilidad o no de las relaciones existentes en un DER, para solucionar las necesidades de consultas de los usuarios de un sistema.

Justamente, una metáfora es una imagen, sonido, movimiento, etc. que puede asociarse por analogía a un tema diferente y que puede facilitar la comprensión o memorización de ese asunto. En este caso la metáfora es visual y dinámica, el agua en movimiento llevada por la gravedad como ocurre en los ríos y arroyos.

Cómo surge la idea?; durante la construcción de un modelo de estrella para un datawarehouse, un alumno me preguntó porqué no se podía traer la información de una entidad que se hallaba bastante alejada en el diagrama. Le dí una larga explicación sobre la inexistencia de una relación con las entidades intermedias que pudieran transmitir la información hacia la tabla central del modelo. Entonces él me contestó, "pero si los caños llegan, porqué los datos no llegan?", yo, con un poco de menos paciencia le dije que esto era un diagrama de datos no un problema de plomería.

Sin embargo otro día en que recordé esta anécdota, yo mismo me pregunté lo siguiente, quizás lo del agua podría funcionar si ponemos alguna regla para su desplazamiento. Entonces se me ocurrió esa regla, y la enuncio en su forma más simple, si en el DER las relaciones fueran flujos de agua, la misma correrá desde el uno hacia el varios. Dicho de otra manera, al hacer una consulta desde una entidad puedo enriquecer su información con la de todas aquellas entidades que llegan a esta con cardinalidad varios. Por ejemplo en el DER3 podemos ver que si hacemos una consulta partiendo desde la entidad renglón, podríamos juntar la información de todas las otras entidades, aún las más lejanas, por que todas las relaciones apuntan hacia ella con un varios.

En cambio por lo contrario veamos el siguiente ejemplo en DER5:

Ilustración 8 – DER 6

En este diagrama si yo quisiera saber qué ventas realizó un vendedor, no podría hacerlo, sé en qué sucursal trabaja el vendedor, pero no puedo individualizar sus ventas. Técnicamente diría que no tengo una clave foránea de vendedor en factura para adjudicar a cada uno sus ventas, pero con esta metáfora podría visualizar rápidamente que la caída del agua es desde sucursal hacia vendedor y desde sucursal hacia factura, pero como el agua no sube, no puede llegar el dato de vendedor hasta factura.

Ilustración 9 – DER 7

Evidentemente la solución es poner un caño con caída desde vendedor hacia factura, en factura va la pata de gallo, por lo tanto ahí irá como clave foránea el ID de vendedor.

Ilustración 10 – DER 8

Por otra parte, elegí a propósito el diagrama de patas de gallo pues me parece que refuerza la metáfora, dado que las relaciones semejan un curso de agua, desde un delgado origen hasta un ancho delta (de uno a varios).

Pero, qué hacemos con las relaciones uno a uno? En estos casos el diseñador decide el sentido del flujo al asignar la clave foránea a una u otra de las entidades intervinientes. Por ejemplo si tuviéramos una relación uno a uno entre una entidad empleado y otra cónyuge, en un sistema empresa seguramente nos interesaría más el empleado, por lo tanto pondríamos la clave foránea DNIcónyuge en la entidad empleado, por que seguramente empleado será el nexo con el resto del modelo y a través de él podremos recabar también información sobre su cónyuge.

Ilustración 11 – Resolución de una relación uno a uno

O sea que en el caso de una relación uno a uno, es una decisión de diseño hacia donde orientamos el flujo de datos.

Por último, ¿qué pasa si la relación es varios a varios? Bueno, cualquiera que diseñe modelos de datos relacionales debe saber que esta relación encubre la existencia de una entidad intermedia y la verdadera relación es de uno a varios de cada entidad fuerte hacia la débil (la intermedia). Por lo tanto, la metáfora es aplicable.

Ilustración 12 – Resolución de una relación varios a varios

La relación varios a varios entre producto y marca queda resuelta como las relaciones un producto tiene varias marcas y una marca tiene varios productos.

Veamos un ejemplo más grande retomando el DER 5:

Ilustración 13 – DER 5

En este DER podemos visualizar rápidamente que la entidad desde donde podemos recolectar toda la información de las entidades es la entidad renglón, la cual es una suerte de sumidero, donde sólo hay conexiones de cardinalidad varios.

Puedo ver también que por ejemplo, puedo recoger en factura la información de la localidad de donde vive el cliente, y de la localidad donde está la sucursal, pero desde localidad no puedo averiguar que relación tiene una sucursal con un cliente.

También veo que la entidad provincia está en un punto muy elevado y sólo tiene una salida para abastecer a la entidad localidad y desde ésta a sucursal y a cliente.

Las restantes posibilidades se las dejo al análisis del lector.

Conclusiones

"En el principio era el verbo" (Juan 1:1-3)[2]

Para terminar no olvidemos que ésta sólo es una metáfora visual, no sólo es cuestión de tirar caños entre cualquier par de entidades. Aquí se acaba la metáfora, como dijimos desde un principio es un modelo semántico y para que el caño sea viable debe haber un verbo o acción que lo justifique y le dé sentido. Por ejemplo, el empleado tiene un cónyuge, el vendedor realiza varias ventas, etc. En el DER 5 por ejemplo me resultaría difícil encontrar un verbo que justifique una relación entre las entidades Provincia y Profesión.

En fin, retomando el primer tema de este artículo, espero que el enfoque de construir el modelo de datos a partir del hecho registrable les sirva de alternativa para facilitar su interpretación y lograr su realización. Aclaro que la única originalidad de esta propuesta es la de haber tomado el enfoque por hechos, (el cual se usa para detectar posibles tablas de hecho dentro de un DER ya existente, con el objeto de diseñar diagramas de estrella o copo de nieve para un datawarehouse[3]y usarlo en forma inversa para la construcción de un DER desde el principio.

Si no tuve éxito, espero que la metáfora del agua les ayude a visualizar rápidamente las posibilidades de ejecutar una consulta en un modelo existente o deficiencias de información. Es sólo un recurso didáctico, pero creo que aquí si hay un poco más de originalidad.

Autor:

Horacio José Caballero

[1] Aquino, Santo Tomás de €“ Suma Teológica €“ Parte I-II Cuestión 7. Respetuosamente, este párrafo es un resumen extremo de todo el análisis que hace el filósofo sobre la composición del acto y sus circunstancias.

[2] Nuevo Testamento €“ Evangelio de Juan 1:1-3

[3] Neil, Carlos €“ Datawarehouse y bases de datos temporales €“ Universidad Abierta Interamericana €“ Capítulos 2 y 3.