¿Qué es un modelo entidad relación?
Historia de los modelos entidad relación
Usos de los diagramas entidad-relación
Los componentes y las características de un diagrama ER
Creación de mapas de lenguaje natural
Símbolos y notaciones de diagramas ER
Modelos de datos físicos, lógicos y conceptuales
Limitaciones de los modelos y diagramas ER
Cómo dibujar un diagrama ER básico
Más consejos sobre diagramas ER
Aprende lo básico de los diagramas ER y los modelos ER, además de sus orígenes, usos, ejemplos, componentes, limitaciones y pautas sobre cómo dibujarlos usando nuestra herramienta de diagramas ER.

Un diagrama entidad-relación, también conocido como modelo entidad relación o ERD, es un tipo de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo para diseñar o depurar bases de datos relacionales en los campos de ingeniería de software, sistemas de información empresarial, educación e investigación. También conocidos como los ERD o modelos ER, emplean un conjunto definido de símbolos, tales como rectángulos, diamantes, óvalos y líneas de conexión para representar la interconexión de entidades, relaciones y sus atributos. Son un reflejo de la estructura gramatical y emplean entidades como sustantivos y relaciones como verbos.

Los diagramas de ER se relacionan con los diagramas de estructura de datos (DSD), que se centran en las relaciones de los elementos dentro de las entidades, en lugar de las relaciones entre las entidades mismas. Los diagramas ER a menudo se combinan con los diagramas de flujo de datos (DFD), que trazan el flujo de la información para procesos o sistemas.

Historia de los modelos entidad relación

Peter Chen (también conocido como Peter Pin-Shan Chen) actualmente se desempeña como miembro de la facultad de la Universidad Carnegie Mellon ubicada en Pittsburgh y se le atribuye el desarrollo del modelo ER para el diseño de bases de datos en los 70. Mientras trabajaba como profesor adjunto en la Escuela de Administración y Dirección de Empresas Sloan del MIT, publicó un documento influyente en 1976 llamado "Modelo entidad-relación: hacia una visión unificada de los datos".

Usos de los diagramas entidad-relación

Los diagramas ER se componen de entidades, relaciones y atributos. También representan la cardinalidad, que define las relaciones en términos de números. Puedes ver un glosario a continuación:

Conjunto de entidades: es igual que un tipo de entidad, pero se define en un momento determinado, como por ejemplo estudiantes que se inscribieron en una clase el primer día. Otros ejemplos son clientes que realizaron una compra en el último mes o autos registrados actualmente en Florida. Un término relacionado es una instancia, en la que una persona determinada o un auto específico podría ser una instancia del conjunto de entidades.

Claves de entidad: se refiere a un atributo que únicamente define una entidad en un conjunto de entidades. Las claves de entidad se dividen en superclave, clave candidata o clave primaria. Superclave: un conjunto de atributos (uno o más) que juntos definen una entidad en un conjunto de entidades. Clave candidata: es una superclave mínima, es decir, contiene el menor número posible de atributos para seguir siendo una superclave. Un conjunto de entidades puede tener más de una clave candidata. Clave primaria: es una clave candidata seleccionada por el diseñador de la base de datos para identificar únicamente al conjunto de entidades. Clave extranjera: identifica la relación entre las entidades.

Relación recursiva: la misma entidad participa más de una vez en la relación.

 
Atributo descriptivo: una propiedad o característica de una relación (frente a una entidad).

Cardinalidad
Define los atributos numéricos de la relación entre dos entidades o conjuntos de entidades. Las tres relaciones cardinales principales son uno a uno, uno a muchos y muchos a muchos. Un ejemplo de uno a uno sería un estudiante asociado a una dirección de correo electrónico. Un ejemplo de uno a muchos (o muchos a uno, en función de la dirección de la relación) sería un estudiante que se inscribe en muchos cursos, y todos esos cursos se asocian a ese estudiante en particular. Un ejemplo de muchos a muchos sería los estudiantes en grupo están asociados a múltiples miembros de la facultad y a su vez los miembros de la facultad están asociados a múltiples estudiantes.

Restricciones de cardinalidad: Los números máximos o mínimos que se aplican a una relación.

Los componentes ER pueden reflejar las categorías gramaticales, eso fue lo que hizo Peter Chen. Esto muestra cómo un diagrama ER se compara con un diagrama gramatical:

Crear diagramas en línea es fácil y rápido con Lucidchart. Empieza una prueba gratis hoy para crear y colaborar.

Hay numerosos sistemas de notación que son similares, pero que se diferencian en algunos aspectos específicos.

Estilo de la notación de IDEF1X
 

Modelos de datos físicos, lógicos y conceptuales

Modelo de datos conceptuales: la visualización de nivel más alto que contiene la menor cantidad de detalle. Su valor muestra el alcance global del modelo y representa la arquitectura del sistema. Para un sistema de menor alcance, quizás no sea necesario dibujarlo. En cambio, se comienza con el modelo lógico.
Modelo de datos lógicos: contiene más detalle que un modelo conceptual. Ahora se definen las entidades transaccionales y operativas más detalladas. El modelo lógico es independiente de la tecnología en la que se implementará.
Modelo de datos físicos: uno o más modelos físicos pueden desarrollarse a partir de cada modelo lógico. El modelo físico debe mostrar los suficientes detalles tecnológicos para producir e implementar la base de datos en cuestión.
Ten en cuenta que existen niveles de alcance y de detalle similares en otros tipos de diagramas, como los diagramas de flujo de datos, pero esto se contrasta con el enfoque de tres esquemas de la ingeniería de software, que divide la información de forma diferente. En algunas ocasiones, los ingenieros ramificarán los diagramas ER con jerarquías adicionales con el fin de agregar los niveles de información necesarios para el diseño de la base de datos. Por ejemplo, pueden agregar categorías mediante la ampliación hacia arriba con superclases y hacia abajo con subclases.

Exclusivo para datos relacionales: comprende que el propósito es solo mostrar las relaciones. Los diagramas ER muestran únicamente la estructura relacional.
Inadecuado para datos no estructurados: a menos que los datos se delineen claramente en campos, filas o columnas diferentes, es probable que los diagramas ER tengan un uso limitado. Lo mismo sucede con los datos semiestructurados, porque solo algunos datos serán útiles.
Complicaciones al realizar una integración con una base de datos existente: usar modelos ER para realizar una integración con bases de datos existentes puede ser un desafío debido a las diferentes arquitecturas.
Cómo dibujar un diagrama ER básico

Entidades: identifican las entidades involucradas. Cuando estés listo, comienza a dibujarlas en rectángulos (o en la figura que selecciones en tu sistema) y etiquétalas como sustantivos.

Atributos: brindan más detalles mediante la adición de atributos clave de las entidades. Los atributos a menudo se muestran como óvalos.

Muestra el nivel de detalle necesario para tu propósito. Tal vez desees dibujar un modelo físico, lógico o conceptual, en función de los detalles necesarios. (Consulta más arriba las descripciones de esos niveles).

Si estás solucionando un problema de una base de datos, presta atención a los vacíos en las relaciones o los atributos o entidades que faltan.

Puedes convertir tablas relacionales a diagramas ER, y viceversa, si eso te ayuda a alcanzar tu objetivo.

Puede haber diferentes enfoques válidos para un diagrama ER. Mientras brinde la información necesaria para su alcance y propósito, es apropiado.

3. 

Las bases de datos son un gran pilar de la programación actual, ya que nos permiten almacenar y usar de forma rápida y eficiente cantidades ingentes de datos con cierta facilidad. En la actualidad se usa de forma mayoritaria lasbases de datos relacionales (dominadas por distintos gestores a través del lenguaje SQL, en gran medida).

Pero ahora vamos a dar un pequeño repaso a lo más esencial del modelo entidad-relación, que es y ha sido durante años la mejor forma de representar la estructura de estas bases de datos relacionales (o de representar sus esquemas).

Como ya he comentado este modelo es solo y exclusivamente un método del que disponemos para diseñar estos esquemas que posteriormente debemos de implementar en un gestor de BBDD (bases de datos). Este modelo se representa a través de diagramas y está formado por varios elementos.

Este modelo habitualmente, además de disponer de un diagrama que ayuda a entender los datos y como se relacionan entre ellos, debe de ser completado con un pequeño resumen con la lista de los atributos y las relaciones de cada elemento.

Entidad

Las entidades representan cosas u objetos (ya sean reales o abstractos), que se diferencian claramente entre sí.

Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes entidades:

• Coches (objeto físico): contiene la información de cada taller.
• Empleado (objeto físico): información de los trabajadores.
• Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulos, como los siguientes.

Atributos

Los atributos definen o identifican las características de entidad (es el contenido de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha...).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad "Coches", que nos darán información sobre los coches de nuestro supuesto taller.

Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del propietario, marca, modelo y muchos otros que complementen la información de cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no es necesario representarlos todos, sino los más significativos, como a continuación.

En un modelo relacional (ya implementado en una base de datos) una ejemplo de tabla dentro de una BBDD podría ser el siguiente.

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese necesario) y seguirían la misma estructura de columnas, tras implementarlo en unaBBDD.

Relación

Es un vínculo que nos permite definir una dependencia entre varias entidades, es decir, nos permite exigir que varias entidades compartan ciertos atributos de forma indispensable.

Por ejemplo, los empleados del taller (de la entidad "Empleados") tienen un cargo (según la entidad "Cargo del empleado"). Es decir, un atributo de la entidad "Empleados" especificará que cargo tiene en el taller, y tiene que ser idéntico al que ya existe en la entidad "Cargo del empleado".

Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante líneas.

Yo, bajo mi punto de vista, entiendo mejor esto en una tabla (de una implementación en una BBDD), por lo que voy a poner el ejemplo de como se representaría (resaltada la relación, que posteriormente veremos como se haría).

Empleados

Cargo del empleado

Relaciones de cardinalidad

Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de la relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en esa relación.

Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).

Uno a varios o varios a uno: determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller.

Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios coches distintos.

Los indicadores numéricos indican el primero el número mínimo de registros en una relación y posteriormente el máximo (si no hay límite se representa con una "n").

Claves

Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de los demás registros (no permitiendo que el atributo específico se repita en la entidad) o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son los distintos tipos:

Superclave: aplica una clave o restricción a varios atributos de la entidad, para así asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en dudas al querer identificar un registro.

Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se repita en la misma entidad. Como sería la matrícula o el número de chasis de un coche (no puede existir dos veces el mismo).

Clave externa o clave foránea: este campo tiene que estar estrictamente relacionado con la clave primaria de otra entidad, para así exigir que exista previamente ese clave. Anteriormente hemos hablado de ello cuando comentábamos que un empleado indispensablemente tiene que tener un cargo (que lo hemos representado numéricamente), por lo cual si intentásemos darle un cargo inexistente el gestor de bases de datos nos devolvería un error.

Esto ha sido solo un repaso por encima de lo que es el modelo entidad-relación, sin entrar en grandes detalles.

También, bajo mi punto de vista, creo que es una buena forma de diseñar correctamente las bases de datos, aunque algunas veces resulta más rápido implementarlo directamente en nuestro gestor de BBDD sin la necesidad de crear un gran diagrama, sino usando notas más simples.