Resumen

Diagramas Entidad Relacin (DER): El Enfoque por Hechos y la Metfora del Agua

El presente artculo tiene como objeto presentar la confeccin de los diagramas entidad- relacin desde otra perspectiva proveyendo al alumno de las materias relacionadas con bases de datos, de un enfoque diferente, enriqueciendo sus posibilidades de interpretarlos. El referido enfoque es el de hechos y registro de hechos. Luego se aporta una visualizacin del modelo de datos mediante una metfora acutica, la cual puede ser prctica para captar rpidamente problemas o necesidades no cubiertas por el modelo de datos. Summary The present article has like object to present the making of the diagrams entity - relationship from another perspective, providing the student of the matters referred to databases of a different focus, enriching its possibilities to interpret them. The one referred focus is that of facts and registration of facts. Then a visualization of the pattern of data is contributed by means of an aquatic metaphor that can be practical to capture problems or necessities quickly not covered by the pattern of data.

Introduccin

Las Bases de datos se usan para mantener en forma ordenada y accesible la informacin de una organizacin, sin embargo no existe una nica forma de organizar los datos y hasta la fecha se han sucedido diferentes enfoques y modelos. Lo que debe reconocerse en el estado actual del arte, es el xito de la combinacin de los modelos entidad relacin y el modelo relacional. Esta combinacin es dominante en el rea de base de datos y sobre todo en las aplicaciones comerciales. La irrupcin de los modelos orientados a objetos no ha provocado la aparicin de Bases de Datos con orientacin a objetos con xito en el mercado comercial. Es ms, al incorporarse algunos de los componentes de la orientacin a objetos dentro de las bases de datos relacionales y del Modelo Entidad Relacin (MER extendido), se ha logrado una nueva sntesis que por ahora desalienta la aparicin de nuevas recetas para el diseo de modelos de datos. Reconociendo que estos modelos an tienen mucho para dar, es que me propongo en este artculo abundar sobre la metodologa de confeccin de un modelo entidad relacin. Desarrollo

El modelo Entidad Relacin

El modelo entidad relacin (MER) expresados en Diagramas Entidad Relacin (DER) es un paso previo al diseo de un modelo relacional y su implementacin lgica en una Base de datos fsica. DISEO DE BASES DE DATOS

DISEO CONCEPTUAL
Se convierte en

ALTO NIVEL DE ABSTRACCIN CERCANO AL SISTEMA REAL

DISEO LGICO
Se Compila en

MODELO LGICO DE ORIGEN RELACIONAL U OO PROPIO DE LA BD SELECCIONADA

DISEO FSICO

BAJO NIVEL DE ABSTRACCIN PROPIO DE LA IMPLEMENTACIN FISICA DEL M ODELO

Ilustracin 1 Etapas de implementacin de un Modelo de Datos El Modelo Entidad Relacin es un modelo conceptual muy cercano a la descripcin verbal de los conjuntos de datos reales. La idea de entidad relacin, es una idea semntica, o sea que depende directamente del significado de las palabras. Bsicamente una relacin entre entidades es la relacin entre un sujeto y un predicado a travs de un verbo, el cual le da sentido a dicha relacin.
EDITA EDITOR IAL 1 n LIBRO

Ilustracin 2 Relacin entre dos entidades

Por lo tanto gran parte del arte de construir un DER consiste en descubrir los significados en la descripcin verbal del sistema identificando las entidades y sus relaciones dentro del sistema bajo anlisis. Tambin se deben definir los grados de relacin (cantidad de entidades involucradas en cada relacin) y las cardinalidades (cada ocurrencia de una entidad se relaciona con cierta cantidad de ocurrencias de la otra entidad). Sin embargo no voy a proseguir con esta lnea, de la cual hay mucha literatura disponible, lo que pretendo es enfocar el asunto de otra manera.

El enfoque por hechos

Otra manera de abordar la construccin de un DER es a travs del planteo de los hechos que se pretenden registrar en un modelo de datos. Cualquier organizacin realiza transacciones o acciones sobre el medio, que son la razn de existencia, su tarea principal, su origen de fondos y la consiguiente necesidad de control. El hecho o transaccin ms comn es la venta (la mayora de los sistemas comercializan algo), pero tambin puede ser una atencin mdica, un control vehicular, un control aduanero, una medicin meteorolgica, la produccin de una pieza, un servicio, la llegada de un pasajero, el paso por un peaje, la visita a una pgina web, un clic de mouse, etc. La idea es simple, lo primero que hay que descubrir son las transacciones o hechos centrales del sistema y a continuacin reducirlos a su mnima expresin. 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 mnima expresin de la venta, lo mnimo, es la venta de cada tem de la factura o ticket y podramos denominar a esa entidad como rengln. En la entidad rengln voy a registrar para la empresa cada cosa que se vendi. Otro ejemplo, en un hospital la transaccin ms chica sera cada una de las atenciones, consultas o estudios que se van registrando en la Historia clnica del paciente. En este caso la transaccin la podramos representar con una entidad atencin la cual se realizara a un determinado paciente, por un determinado mdico, en tal servicio, en una fecha y hora, y un montn de circunstancias ms que rodean a esta transaccin y de las cules registraremos las que interesen al sistema requerido. Bien, pero para seguir construyendo el modelo de datos, hagamos un poco de filosofa (siempre es elegante citar a un filsofo). Santo Toms, en la descripcin de los elementos que componen un acto distingua los siguientes: el objeto (que), el sujeto (quin) y circunstancias que pueden detectarse mediante los adverbios de interrogacin: cundo, cmo, dnde, por qu, para qu, con qu, cunto, etc.1 Pues bien, esto puede servir de orientacin para ir encontrando las entidades que rodean al acto o hecho de inters de mi sistema o aplicacin. 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 telaraas de entidades, esto es as por que las circunstancias que registramos son muchas ms que las que nombraba el filsofo y a veces registramos las circunstancias de las circunstancias en verdaderas escalas jerrquicas. Por ejemplo, quin compr es una entidad cliente, pero a su vez esta entidad cliente puede pertenecer a una regin, a una raza, a una religin, tener un determinado nivel de ingreso, etc. las cuales son circunstancias del cliente que darn lugar a sendas entidades. Para ser ms ilustrativo retomo el ejemplo de la venta y lo amplo: La entidad rengln es la mnima transaccin, 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 cundo y a quin vend. Tambin 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.

Ilustracin 3 DER 1 A su vez esa entidad cliente puede ser clasificada por varias entidades (clase social, raza, regin, religin, profesin, edad, etc.). Todas son circunstancias del cliente: cmo es, de qu raza, de qu religin, en qu trabaja, cuantos aos tena, cual es su nivel social, etc., etc. preguntas que nos pueden interesar en nuestro sistema. Eligiendo algunas, el DER queda as:

Ilustracin 4 - DER 2 En este DER inicial ya debemos tomar en cuenta algo muy importante, las cardinalidades. Cuntas ocurrencias de una entidad se relacionan con cada ocurrencia de la otra entidad. Bien, podemos notar fcilmente lo siguiente, a medida que nos acercamos a la entidad hecho (rengln en este caso), aumenta la cantidad de ocurrencias de las entidades. El hecho es la mnima 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 rtulos bajo los cules podrn 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 inters. Por ejemplo el qu de cada transaccin, o sea qu es lo que vend y nos aparece la entidad producto (tambin podramos bautizarla catlogo) que se relacionar directamente con cada ocurrencia de rengln. Por supuesto, un producto ser vendido en varios renglones (sino el negocio va mal). Los productos tambin pueden pertenecer a una categora, con lo que nos aparece una jerarqua de agrupamiento, una entidad categora agrupa a varios productos. Actualizando el diagrama se vera as:

Ilustracin 5 - DER 3 Ahora podramos agregar el dnde se realiz la venta? (factura) y tendremos la entidad sucursal. Si preguntamos quin compr? tenemos la entidad cliente, pero si preguntamos quin vendi? tenemos la entidad vendedor. Replanteando nuevamente el diagrama se ver as:

Ilustracin 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 tambin circunstancia de la entidad vendedor (dnde trabaja?). O sea que varios vendedores trabajan en cada sucursal. Graficamos esa relacin. Finalmente, una correccin ms, la localidad puede ser la circunstancia dnde? de varias sucursales por lo cual tambin podemos relacionar localidad con sucursal adems de la relacin localidad con cliente.

Ilustracin 7 - DER 5

La metfora del agua

Siguiendo esta lnea de buscar nuevos enfoques voy a proponer ahora una metfora que me parece de gran utilidad para visualizar rpidamente 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 metfora es una imagen, sonido, movimiento, etc. que puede asociarse por analoga a un tema diferente y que puede facilitar la comprensin o memorizacin de ese asunto. En este caso la metfora es visual y dinmica, el agua en movimiento llevada por la gravedad como ocurre en los ros y arroyos. Cmo surge la idea? ; durante la construccin de un modelo de estrella para un datawarehouse, un alumno me pregunt porqu no se poda traer la informacin de una entidad que se hallaba bastante alejada en el diagrama. Le d una larga explicacin sobre la inexistencia de una relacin con las entidades intermedias que pudieran transmitir la informacin hacia la tabla central del modelo. Entonces l me contest, pero si los caos 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 plomera. Sin embargo otro da en que record esta ancdota, yo mismo me pregunt lo siguiente, quizs lo del agua podra funcionar si ponemos alguna regla para su desplazamiento. Entonces se me ocurri esa regla, y la enuncio en su forma ms 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 informacin 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 rengln, podramos juntar la

informacin de todas las otras entidades, an las ms lejanas, por que todas las relaciones apuntan hacia ella con un varios. En cambio por lo contrario veamos el siguiente ejemplo en DER5:

Ilustracin 8 - DER 6 En este diagrama si yo quisiera saber qu ventas realiz un vendedor, no podra hacerlo, s en qu sucursal trabaja el vendedor, pero no puedo individualizar sus ventas. Tcnicamente dira que no tengo una clave fornea de vendedor en factura para adjudicar a cada uno sus ventas, pero con esta metfora podra visualizar rpidamente que la cada 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.

Ilustracin 9 - DER 7 Evidentemente la solucin es poner un cao con cada desde vendedor hacia factura, en factura va la pata de gallo, por lo tanto ah ir como clave fornea el ID de vendedor.

Ilustracin 10 - DER 8 Por otra parte, eleg a propsito el diagrama de patas de gallo pues me parece que refuerza la metfora, 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 diseador decide el sentido del flujo al asignar la clave fornea a una u otra de las entidades intervinientes. Por ejemplo si tuviramos una relacin uno a uno entre una entidad empleado y otra cnyuge, en un sistema empresa seguramente nos interesara ms el empleado, por lo tanto pondramos la clave fornea DNIcnyuge en la entidad empleado, por que seguramente empleado ser el nexo con el resto del modelo y a travs de l podremos recabar tambin informacin sobre su cnyuge.

Ilustracin 11 Resolucin de una relacin uno a uno O sea que en el caso de una relacin uno a uno, es una decisin de diseo hacia donde orientamos el flujo de datos. Por ltimo, qu pasa si la relacin es varios a varios? Bueno, cualquiera que disee modelos de datos relacionales debe saber que esta relacin encubre la existencia de una entidad intermedia y la verdadera relacin es de uno a varios de cada entidad fuerte hacia la dbil (la intermedia). Por lo tanto, la metfora es aplicable.

Ilustracin 12 - Resolucin de una relacin varios a varios La relacin 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 ms grande retomando el DER 5:

Ilustracin 13 - DER 5 En este DER podemos visualizar rpidamente que la entidad desde donde podemos recolectar toda la informacin de las entidades es la entidad rengln, la cual es una suerte de sumidero, donde slo hay conexiones de cardinalidad varios. Puedo ver tambin que por ejemplo, puedo recoger en factura la informacin de la localidad de donde vive el cliente, y de la localidad donde est la sucursal, pero desde localidad no puedo averiguar que relacin tiene una sucursal con un cliente. Tambin veo que la entidad provincia est en un punto muy elevado y slo tiene una salida para abastecer a la entidad localidad y desde sta a sucursal y a cliente. Las restantes posibilidades se las dejo al anlisis del lector.

Conclusiones
"En el principio era el verbo" (Juan 1:1-3)2 Para terminar no olvidemos que sta slo es una metfora visual, no slo es cuestin de tirar caos entre cualquier par de entidades. Aqu se acaba la metfora, como dijimos desde un principio es un modelo
2

semntico y para que el cao sea viable debe haber un verbo o accin que lo justifique y le d sentido. Por ejemplo, el empleado tiene un cnyuge, el vendedor realiza varias ventas, etc. En el DER 5 por ejemplo me resultara difcil encontrar un verbo que justifique una relacin entre las entidades Provincia y Profesin. En fin, retomando el primer tema de este artculo, espero que el enfoque de construir el modelo de datos a partir del hecho registrable les sirva de alternativa para facilitar su interpretacin y lograr su realizacin. 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 disear diagramas de estrella o copo de nieve para un datawarehouse 3) y usarlo en forma inversa para la construccin de un DER desde el principio. Si no tuve xito, espero que la metfora del agua les ayude a visualizar rpidamente las posibilidades de ejecutar una consulta en un modelo existente o deficiencias de informacin. Es slo un recurso didctico, pero creo que aqu si hay un poco ms de originalidad.

Neil, Carlos Datawarehouse y bases de datos temporales Universidad Abierta Interamericana Captulos 2 y 3.