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.