Inicio > Modelo de Datos > Modelado E-R

Modelado E-R

El Modelo E-R (Entidad-Relación) es un modelo de datos propuesto por Peter Chen en 1976 que busca definir los principales elementos del proceso a modelar como «Entidades» para pasar posteriormente a definir las «Relaciones» entre ellas. Una vez definidas las relaciones, obtendríamos un modelo Relacional, al que optimizaríamos sus relaciones mediante la Normalización.

Un proceso básico de Modelado E-R seguiría los siguientes pasos:

Proceso de Modelado E-R

Las finalidad de los Modelos E-R está en servir como soporte a los procesos operacionales, de ahí el enfásis en la Normalización. La normalización obtiene un modelo de datos cuyo enfásis recae en la manipulacíón de los datos ( insercción, actualización y borrado de datos).

En nuestro caso, al utilizar un modelo dimensional enfocado al análisis y toma de decisiones, donde una característica de los datos es su «no-volatilidad», y donde necesitamos optimizar la consulta de grandes volúmenes de datos, podemos utlilizar un modelo denormalizado.

Como ejemplo, vamos a realizar un Modelo E-R básico que se encuentra una empresa en su proceso de venta.

  1. Identificar las Entidades: cliente, pedido, producto, vendedor. En este apartado es necesario conocer bien el Negocio, por lo que habría que mantener reuniones con la gente del Negocio para poder comprender su proceso de venta.

    Entidades Modelo E-R

  2. Identificar los principales atributos: para «Cliente», sería nombre, apellidos, etc. Para «Pedido», identificador de pedido, estado, fecha de pedido, fecha de envío, etc. Para «Producto», tendríamos un identificador del producto, su nombre, tipo de producto, etc. Para «Vendedor», su identificador, su nombre, sus apellidos, etc.
  3. Identificar las relaciones: tendríamos que «Cliente», «Vendedor» y «Producto» se relacionan a través de «Pedidos»
  4. Cardinalidad: Aquí hay que volver a recoger información sobre el Negocio, ya que son ellos los que definen como son los clientes, que pueden y no pueden hacer, cuántos vendedores puede haber en un pedido, etc. Tras ello, concluimos que un cliente puede tener varios pedidos y un vendedor puede tener varios pedidos, pero un pedido solo puede tener un cliente y un vendedor. A la vez, un producto puede tener varios pedidos, y un pedido puede tener varios productos.
  5. Normalizar el modelo: que no es más que utilizar un conjunto de reglas matemáticas con las que evitar las redundancias. Para la mayoría de casos, nos bastaría con cumplir las 3 primeras normas. Por lo tanto, si en nuestra Entidad «Cliente» hemos incluído como atributo «Dirección», al normalizar la tabla, debemos quitar las columnas relacionadas con «Dirección» a una tabla aparte. Por lo tanto, al normalizar nos hemos dado cuenta de que hay atributos que no dependen exactamente de la clave. Habría que realizar lo mismo con todas las relaciones, entidades y atributos, y alcanzaríamos un modelo normalizado. Asimismo, la relación N:N entre el pedido y los productos, se trasladaría a otra tabla («detalle») cuya clave sean dos claves foráneas, una hacia «pedido» y otra hacia «productos».

    Modelo Relacional (Normalizado)

  6. Identificar los tipos de datos e índices: hay que prestar atención al rango de valores que serán incluídos así como identificar correctamente el tipo de dato que nos facilite la manipulación de la información. Un ejemplo lo tendríamos con los códigos postales. En España, el código postal es un número de cinco cifras. Podemos identificarlo como un «número entero» pero esto nos podría traer problemas en el futuro, ya que hay códigos postales que comienzan por cero («08080» es de Barcelona), y si lo tratamos como número, al almacenarlo es muy probable que se pierda el cero inicial. Por eso, sería más útil identificarlo como «texto», ya que no es necesario realizar operaciones algebráicas sobre él. Para los índices, es necesario identificar por qué columnas realizamos las búsquedas en las tabla, ya que la finalidad del índice es facilitar las mismas.
  7. Optimizar el Modelo: tener en cuenta el crecimiento futuro de la tabla, la rapídez de ejecución de las consultas en la tabla, particionamientos, seguridad, etc.

Tenemos un modelo relacional que funcionará correctamente y facilitará el mantenimiento de la información de ventas de la empresa.

  1. Laura Zapata Aspiazu
    octubre 6, 2010 a las 7:07 pm

    Muy buena aportación a la sociedad. 🙂

  2. Jorge
    noviembre 13, 2010 a las 9:42 pm

    Mis profesores de la facultad explican de casi 3 meses el Modelo E/R y aun asi no han dejado las cosas de todo claras y tu con un ejemplo sencillo y buenos comentarios consigues hacerlo. Te aconsejeria que pongas las relaciones que une cada Entidad y no solo las Cardinalidades. Sigue asi, necesitamos gente competente en los foros.

  1. May 6, 2010 a las 8:01 am

Deja un comentario