Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Ut2.- Interpretación del diseño conceptual.

Diagramas Entidad/Relación.

Objetivos
Esta unidad realiza un recorrido desde la fase de análisis hasta la fase de diseño de bases
de datos. Se inicia describiendo y detallando los elementos que componen el modelo
Entidad/Relación. Desde el concepto de entidad, sus tipos, atributos y claves, pasando por
el de relaciones, su grado y cardinalidad, para desembocar la simbología empleada en el
modelo.

Posteriormente, se afronta el estudio de las opciones adicionales que aporta el modelo

Entidad/Relación Extendido, las restricciones, jerarquías de especialización/generalización
y la agregación.

Una vez descritos los conceptos y elementos a representar en los diagramas E/R, se
aborda cómo realizar el proceso de elaboración de dichos diagramas. Se describen
técnicas de identificación de entidades y relaciones, así como metodologías de desarrollo
estandarizadas.

Para que los diagramas generados tengan una calidad adecuada se hace necesario
eliminar las posibles redundancias existentes y se destacan cuáles serían las
características deseables que deben cumplirse al aplicar el modelo Entidad-Relación.

1 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

1. Análisis y diseño de bases de datos.

El Nivel conceptual describe la estructura completa de la base de datos a través de lo que llamamos
Esquema Conceptual, que se encarga de representar la información de una manera totalmente
independiente del Sistema Gestor de Base de Datos.

Cuando hemos de desarrollar una base de datos se distinguen claramente tres fases de trabajo: Análisis,
Diseño e Implementación.

Análisis: Se trata de localizar y definir las entidades y sus atributos. Se definirán las relaciones
existentes entre entidades. Obtención del Esquema Conceptual a través del modelo E/R.
Diseño: Conversión del modelo E/R en un modelo relacional. Creación de tablas con todas las
restricciones definidas. Normalización.
Implementación: Creación de las tablas en un SGBD concreto. Establecimiento de las reglas de
acceso (qué usuarios pueden acceder a qué datos).

Llevando a cabo una correcta fase de análisis estaremos dando un paso determinante en el desarrollo de
nuestras bases de datos. El hecho de saltarse el esquema conceptual conlleva un problema de pérdida
de información respecto al problema real a solucionar. El esquema conceptual debe reflejar todos los
aspectos relevantes del mundo real que se va a modelar.

Para la realización de esquemas que ofrezcan una visión global de los datos, Peter Chen en 1976 y 1977
presenta dos artículos en los que se describe el modelo Entidad/Relación (entity/relationship).

Con el paso del tiempo, este modelo ha sufrido modificaciones y mejoras. Actualmente, el modelo
Entidad/Relación extendido (ERE) es el más aceptado, aunque existen variaciones que hacen que este
modelo no sea totalmente un estándar. Ambos modelos serán estudiados a lo largo de esta unidad.

2 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

2.- ¿Qué es el Modelo E/R?

Es una herramienta de referencia para la representación conceptual de problemas del mundo real. Su
objetivo principal, facilitar el diseño de bases de datos permitiendo la especificación de un esquema que
representa la estructura lógica completa de una base de datos. Este esquema partirá de las descripciones
textuales de la realidad, que establecen los requerimientos del sistema, buscando ser lo más fiel posible
al comportamiento del mundo real para modelarlo.

El modelo de dato E/R representa el significado de los datos, es un modelo semántico. De ahí que no
esté orientado a ningún sistema físico concreto y tampoco tiene un ámbito informático puro de aplicación,
ya que podría utilizarse para describir procesos de producción, estructuras de empresa, etc. Además, las
características actuales de este modelo favorecen la representación de cualquier tipo de sistema y a
cualquier nivel de abstracción o refinamiento, lo cual da lugar a que se aplique tanto a la representación
de problemas que vayan a ser tratados mediante un sistema informatizado, como manual.

Gracias al modelo Entidad-Relación, creado por Peter Chen en los años setenta, se puede representar el
mundo real mediante una serie de símbolos y expresiones determinados. Este modelo está basado en
una percepción consistente en objetos básicos llamados entidades y relaciones entre estos objetos.

Autoevaluación
La información con la que el modelo Entidad-Relación trabaja ha de ser lo más
detallada y fiel posible a la realidad del problema a representar.

Verdadero Falso

3 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

3.- Entidades.
Si utilizamos las bases de datos para guardar información sobre cosas que nos interesan o que interesan
a una organización, ¿No crees que hay que identificar esas cosas primero para poder guardar
información sobre ellas? Para ello, vamos a describir un primer concepto, el de Entidad.

Una entidad puede ser un objeto físico, un concepto o cualquier elemento que queramos modelar, que
tenga importancia para la organización y del que se desee guardar información. Cada entidad debe
poseer alguna característica, o conjunto de ellas, que lo haga único frente al resto de objetos. Por
ejemplo, podemos establecer una entidad llamada ALUMNO que tendrá una serie de características. El
alumnado podría ser distinguido mediante su número de identificación escolar (NIE) por ejemplo.

Entidad: objeto real o abstracto, con características diferenciadoras capaces de hacerse

distinguir de otros objetos.

¿Ponemos otro ejemplo? Supongamos que tienes que desarrollar el esquema conceptual para una base
de datos de mapas de montaña, los elementos: camping, pista forestal, valle, río, pico, refugio, etc., son
ejemplos de posibles entidades. A la hora de identificar las entidades, hemos de pensar en nombres que
tengan especial importancia dentro del lenguaje propio de la organización o sistema que vaya a utilizar
dicha base de datos.

Pero no siempre una entidad puede ser concreta, como un camping o un río, en ocasiones puede ser
abstracta, como un préstamo, una reserva en un hotel o un concepto.

Un conjunto de entidades serán un grupo de entidades que poseen las mismas características o
propiedades. Por ejemplo, al conjunto de personas que realizan reservas para un hotel de montaña
determinado, se les puede definir como el conjunto de entidades cliente. El conjunto de entidades río,
representará todos los ríos existentes en una determinada zona. Por lo general, se suele utilizar el
término entidad para identificar conjuntos de entidades. Cada elemento del conjunto de entidades será
una ocurrencia de entidad.

En el modelo Entidad/Relación, la representación gráfica de las entidades se realiza mediante el nombre

de la entidad encerrado dentro de un rectángulo.

A continuación se muestra la representación de la entidad CLIENTE.

4 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Tipos: fuertes y débiles.

Las entidades pueden ser clasificadas en dos grupos:

a. Entidades Fuertes o Regulares:

Son aquellas que tienen existencia por sí mismas, es decir, su existencia no depende de la
existencia de otras entidades. Por ejemplo, en una base de datos hospitalaria, la existencia de
instancias concretas de la entidad DOCTOR no depende de la existencia de instancias u objetos de
la entidad PACIENTE. En el modelo E/R las entidades fuertes se representan como hemos indicado
anteriormente, con el nombre de la entidad encerrado dentro de un rectángulo.

b. Entidades débiles:

Son aquellas cuya existencia depende de la existencia de otras instancias de entidad. Por ejemplo,
consideremos las entidades EDIFICIO y AULA. Supongamos que puede haber aulas identificadas
con la misma numeración pero en edificios diferentes. La numeración de cada aula no identificará
completamente cada una de ellas. Para poder identificar completamente un aula es necesario
saber también en qué edificio está localizada. Por tanto, la existencia de una instancia de una
entidad débil depende de la existencia de una instancia de la entidad fuerte con la que se relaciona.

En el modelo E/R una entidad débil se representa con el nombre de la entidad encerrado en un
rectángulo doble. En el gráfico se muestra la representación de la entidad AULA.

Las entidades débiles presentan dos tipos de dependencia:

Dependencia en existencia: entre entidades, si desaparece una instancia de entidad fuerte

desaparecerán las instancias de entidad débiles que dependan de la primera. La representación de
este tipo de dependencia incluirá una E en el interior de la relación débil.

Dependencia en identificación: debe darse una dependencia en existencia y además, una

ocurrencia de la entidad débil no puede identificarse por sí misma, debiendo hacerse mediante la
clave de la entidad fuerte asociada. La representación de este tipo de dependencia incluirá una ID
en el interior de la relación débil.

5 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Recomendación

Tanto las entidades fuertes como las débiles se nombran habitualmente con
sustantivos en singular.
Puede ser que haya algunos conceptos que aún no hemos desarrollado (relación,
atributo y clave) y que se están utilizando para describir los tipos de dependencias,
no te preocupes, en los siguientes epígrafes te los describimos claramente.

Autoevaluación
Identifica cuál de las siguientes entidades no podría ser considerada como entidad
débil:

PROVEEDOR (perteneciente a una base de datos de gestión de stocks).

PAGO (perteneciente a una base de datos bancaria).
FAMILIAR (perteneciente a una base de datos hospitalaria).

6 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

4.- Atributos.
¿Cómo guardamos información de cada entidad? A través de sus atributos. Las entidades se
representan mediante un conjunto de atributos. Éstos describen características o propiedades que posee
cada miembro de un conjunto de entidades. El mismo atributo establecido para un conjunto de entidades
o, lo que es lo mismo, para un tipo de entidad, almacenará información parecida para cada ocurrencia de
entidad. Pero, cada ocurrencia de entidad tendrá su propio valor para cada atributo.

Cada una de las propiedades o características que tiene un tipo de entidad o un tipo de
relación se denomina atributo; los atributos toman valores de uno o varios dominios

Por tanto, un atributo se utilizará para guardar información sobre alguna característica o propiedad de una
entidad o relación. Ejemplos de atributos pueden ser: altura, color, peso, DNI, fecha, etc. todo dependerá de la
información que sea necesaria almacenar.

En el modelo Entidad/Relación los atributos de una entidad son representados mediante el nombre del
atributo rodeado por una elipse. La elipse se conecta con la entidad mediante una línea recta. Cada
atributo debe tener un nombre único que haga referencia al contenido de dicho atributo. Los nombres de
los atributos se deben escribir en letra minúscula. En el gráfico se representan algunos de los atributos
para las entidades PACIENTE y JUGADOR.

Al conjunto de valores permitidos para un atributo se le denomina dominio. Todos los posibles valores
que puede tomar un atributo deberán estar dentro del dominio. Varios atributos pueden estar definidos
dentro del mismo dominio. Por ejemplo, los atributos nombre, apellido primero y apellido segundo de la
entidad PACIENTE, están definidos dentro del dominio de cadenas de caracteres de una determinada
longitud.

Aunque los dominios suelen ser amplios (números enteros, reales, cadenas de caracteres, etc.), a la hora
de llevar a cabo el desarrollo de una base de datos, es mejor establecer unos límites adecuados para que
el sistema gestor de la base de datos lleve a cabo las verificaciones oportunas en los datos que se
almacenen, garantizando así la integridad de éstos.

7 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Tipos de atributos.

¿Todos los atributos son iguales? Claro que no. Existen varias características que hacen que los atributos
asociados a una entidad o relación sean diferentes, los clasificaremos según varios criterios.

Atributos obligatorios y opcionales.

Atributo obligatorio: es aquél que ha de estar siempre definido para una entidad o relación.
Por ejemplo, para la entidad JUGADOR será necesario tener algún atributo que identifique
cada ocurrencia de entidad, podría ser su dni. Una atributo clave es un atributo obligatorio.
Atributo opcional: es aquél que podría estar definido o no para la entidad. Es decir, puede
haber ocurrencias de la entidad para las que ese atributo no tenga valor.
Atómicos o compuestos.
Atributo simple o atómico: es un atributo que no puede dividirse en otras partes o atributos,
presenta un único elemento. No es posible extraer de este atributo partes más pequeñas que
puedan tener significado. Un ejemplo de este tipo de atributos podría ser el atributo dni de la
entidad JUGADOR.
Atributo compuesto: es un atributo que puede ser dividido en subpartes, éstas constituirán
otros atributos con significado propio. Por ejemplo, la dirección del jugador podría
considerarse como un atributo compuesto por la calle, el número y la localidad.
Atributos derivados o almacenados: el valor de este tipo de atributos puede ser obtenido del valor
o valores de otros atributos relacionados. Un ejemplo clásico de atributo derivado es la edad. Si se
ha almacenado en algún atributo la fecha de nacimiento, la edad es un valor calculable a partir de
dicha fecha.

Autoevaluación
Rellena los huecos en blanco con los conceptos adecuados.
Si en nuestra base de datos tenemos una entidad USUARIO, los atributos password y login
deberán ser atributos ya que son imprescindibles para iniciar o
jugar partidas. En cambio, un posible atributo ranking que indique en qué posición se
encuentra el usuario entre todos los jugadores, podría considerarse un atributo
si tenemos en cuenta la puntuación obtenida por cada usuario.

8 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Claves.
En el apartado anterior hablábamos de un tipo de atributo especial obligatorio, las claves. Ahora es el
momento de abordar con mayor detalle este concepto.

Está claro que es necesario identificar correctamente cada ocurrencia de entidad o relación, de este
modo el tratamiento de la información que se almacena podrá realizarse adecuadamente. Esta distinción
podría llevarse a cabo tomando todos los valores de todos los atributos de una entidad o relación. Pero,
en algunas ocasiones, sabemos que puede no ser necesario utilizar todos, bastando con un subconjunto
de ellos. Aunque puede ocurrir que ese subconjunto tenga idénticos valores para varias entidades, por lo
que cualquier subconjunto no será válido.

Por tanto, los valores de los atributos de una entidad deben ser tales que permitan identificar
unívocamente a cada ocurrencia de la entidad. En otras palabras, no se permite que ningún par de
ocurrencias de la entidad tengan exactamente los mismos valores en todos sus atributos. Teniendo en
cuenta esto, presta atención a los siguientes conceptos:

Clave candidata: Atributo o conjunto de ellos, que toman valores únicos y distintos para cada
ocurrencia de entidad, identificándola unívocamente. No puede contener valores nulos.

Clave primaria: También llamada clave principal. De todas las claves candidatas, el diseñador
de la base de datos ha de escoger una, que se denominará clave principal o clave primaria.

Claves alternativas: son el resto de claves candidatas que no han sido escogidas como clave
primaria.

La representación en el modelo Entidad/Relación de las claves primarias puede realizarse de dos formas:

Si se utilizan elipses para representar los atributos, se subrayarán aquel o aquellos que formen la
clave primaria.
Si se utilizan círculos para representar los atributos, se utilizará un círculo negro en aquellos que
formen la clave primaria.

9 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Atributos de una relación.

Una relación puede también tener atributos que la describan. Para ilustrar esta situación, observa el
siguiente ejemplo.

Consideremos la relación CURSA entre las entidades ALUMNO y ASIGNATURA. Podríamos asociar a la
relación CURSA un atributo nota para especificar la nota que ha obtenido un alumno/a en una determinada
asignatura.

Otro ejemplo típico son las relaciones que representan históricos. Este tipo de relaciones suele constar
de datos como fecha y hora. Cuando se emite una factura a un cliente o se le facilita un duplicado de la
misma, es necesario registrar el momento en el que se ha realizado dicha acción. Para ello, habrá que
crear un atributo asociado a la relación entre la entidad CLIENTE y FACTURA que se encargue de guardar
la fecha de emisión.

En el modelo Entidad/Relación la representación de atributos asociados a relaciones es exactamente

igual a la que utilizábamos para entidades. Podremos utilizar una elipse con el nombre del atributo en su
interior, conectada con una línea a la relación, o bien, un círculo blanco conectado con una línea a la
relación y junto a él, el nombre del atributo. En el gráfico puedes ver esta segunda representación.

10 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

5.- Relaciones.
¿Cómo interactúan entre sí las entidades? A través de las relaciones. La relación o interrelación es un
elemento del modelo Entidad/Relación que permite relacionar datos entre sí. En una relación se asocia un
elemento de una entidad con otro de otra entidad.

Relación: es una asociación entre diferentes entidades. En una relación no pueden aparecer
dos veces relacionadas las mismas ocurrencias de entidad.

La representación gráfica en el modelo Entidad/Relación corresponde a un rombo en cuyo interior se

encuentra inscrito el nombre de la relación. El rombo estará conectado con las entidades a las que
relaciona, mediante líneas rectas, que podrán o no acabar en punta de flecha según el tipo de relación.

Recomendación
Cuando debas dar un nombre a una relación procura que éste haga referencia al objetivo o
motivo de la asociación de entidades. Se suelen utilizar verbos en singular. Algunos
ejemplos podrían ser: forman, poseen, atiende, contrata, hospeda, supervisa, imparte, etc.

En algunas ocasiones, es interesante que en las líneas que conectan las entidades con la relación, se
indique el papel o rol que desempeña cada entidad en la relación. Como se verá más adelante, los
papeles o roles son especialmente útiles en relaciones reflexivas.

Para describir y definir adecuadamente las relaciones existentes entre entidades, es imprescindible
conocer los siguientes conceptos:

Grado de la relación.
Cardinalidad de la relación.
Cardinalidades de las entidades.

A continuación desarrollamos cada uno de ellos.

11 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Grado de una relación.

¿Pueden intervenir varias entidades en una misma relación? Claro que sí, en una relación puede
intervenir una única entidad o varias.

Grado de una relación: número de entidades que participan en una relación.

En función del grado se pueden establecer diferentes tipos de relaciones:

Relación Unaria o de grado 1: Es aquella relación en la que participa una única entidad. También
llamadas reflexivas.
Relación Binaria o de grado 2: Es aquella relación en la que participan dos entidades. En general,
tanto en una primera aproximación, como en los sucesivos refinamientos, el esquema conceptual
de la base de datos buscará tener sólo este tipo de relaciones.
Relación Ternaria o de grado 3: Es aquella relación en la que participan tres entidades al mismo
tiempo.
Relación N-aria o de grado n: Es aquella relación que involucra n entidades. Este tipo de
relaciones no son usuales y deben ser simplificadas hacia relaciones de menor grado.
Relación doble: ocurre cuando dos entidades están relacionadas a través de dos relaciones.

En este gráfico puedes observar cada uno de los tipos de relaciones en función de su grado y su
representación gráfica en el modelo Entidad/Relación.

12 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Cardinalidad de relaciones.
¿Qué es eso de la cardinalidad? En matemáticas, el cardinal de un conjunto es el número de elementos
que lo forman. Este concepto puede extrapolarse a las relaciones con las que estamos tratando.

Cardinalidad de una relación: Es el número máximo de ocurrencias de cada entidad que

pueden intervenir en una ocurrencia de relación. La cardinalidad vendrá expresada siempre
para relaciones entre dos entidades.

Dependiendo del número de ocurrencias de cada una de las entidades pueden existir
relaciones uno a uno, uno a muchos, muchos a uno y muchos a muchos

Observa el siguiente ejemplo, la cardinalidad indicará el número de ocurrencias de la entidad JUGADOR

que se relacionan con cada ocurrencia de la entidad EQUIPO y viceversa. Podríamos hacer la siguiente
lectura: un jugador pertenece a un equipo y a un equipo pueden pertenecer varios jugadores.

Una posible representación de la cardinalidad de las relaciones es la que hemos visto en el ejemplo
anterior. Podríamos representar el resto de cardinalidades mediante las etiquetas 1:1, 1:N, N:1, N:M que
se leerían respectivamente: uno a uno, uno a muchos, muchos a uno y muchos a muchos.

Veamos en detalle el significado de cada una de estas cardinalidades:

Relaciones uno a uno (1:1). Sean las entidades A y B, una instancia u ocurrencia de la entidad A
se relaciona únicamente con otra instancia de la entidad B y viceversa. Por ejemplo, para cada
ocurrencia de la entidad ALUMNO sólo habrá una ocurrencia relacionada de la entidad EXPEDIENTE
y viceversa. O lo que es lo mismo, un alumno tiene un expediente asociado y un expediente sólo
pertenece a un único alumno.
Relaciones uno a muchos (1:N). Sean las entidades A y B, una ocurrencia de la entidad A se
relaciona con muchas ocurrencias de la entidad B y una ocurrencia de la entidad B sólo estará
relacionada con una única ocurrencia de la entidad A. Por ejemplo, para cada ocurrencia de la
entidad DOCENTE puede haber varias ocurrencias de la entidad ASIGNATURA y para varias
ocurrencias de la entidad ASIGNATURA sólo habrá una ocurrencia relacionada de la entidad
DOCENTE (si se establece que una asignatura sólo puede ser impartida por un único docente). O lo
que es lo mismo, un docente puede impartir varias asignaturas y una asignatura sólo puede ser
impartida por un único docente.
Relaciones muchos a uno (N:1). Sean las entidades A y B, una ocurrencia de la entidad A está
asociada con una única ocurrencia de la entidad B y un ejemplar de la entidad B está relacionado
con muchas ocurrencias de la entidad A. Por ejemplo, Un JUGADOR pertenece a un único EQUIPO y
a un EQUIPO pueden pertenecer muchos jugadores.
Relaciones muchos a muchos (M:N). Sean las entidades A y B, un ejemplar de la entidad A está
relacionado con muchas ocurrencias de la entidad B y viceversa. Por ejemplo, un alumno puede
estar matriculado en varias asignaturas y en una asignatura pueden estar matriculados varios
alumnos.

La cardinalidad de las relaciones puede representarse de varias maneras en los esquemas del modelo
Entidad/Relación. A continuación, te ofrecemos un resumen de las notaciones clasificadas por autores,
más empleadas en la representación de cardinalidad de relaciones.

13 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Distintas notaciones que representan las cardinalidades:

14 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

15 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Cardinalidad de entidades.

Si existe cardinalidad en las relaciones, supondrás que también existe para las entidades. Estás en lo
cierto, la cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el
número máximo de correspondencias en las que puede tomar parte cada ejemplar de dicha entidad.
Indica el número de relaciones en las que una entidad puede aparecer.

Sean las entidades A y B, la participación de la entidad A en una relación es obligatoria (total) si la

existencia de cada una de sus ocurrencias necesita como mínimo de una ocurrencia de la entidad B. En
caso contrario, la participación es opcional (parcial).

La cardinalidad de una entidad se representa con el número mínimo y máximo de correspondencias en

las que puede tomar parte cada ejemplar de dicha entidad, entre paréntesis. Su representación gráfica
será, por tanto, una etiqueta del tipo (0,1), (1,1), (0,N) o (1,N). El significado del primer y segundo
elemento del paréntesis corresponde a (cadinalidad mínima, cardinalidad máxima):

Cardinalidad mínima. Indica el número mínimo de asociaciones en las que aparecerá cada
ocurrencia de la entidad (el valor que se anota es de cero o uno, aunque tenga una cardinalidad
mínima de más de uno, se indica sólo un uno). El valor 0 se pondrá cuando la participación de la
entidad sea opcional.
Cardinalidad máxima. Indica el número máximo de relaciones en las que puede aparecer cada
ocurrencia de la entidad. Puede ser uno, otro valor concreto mayor que uno (tres por ejemplo) o
muchos (se representa con n).

Veámoslo más claro a través del siguiente ejemplo: un JUGADOR pertenece como mínimo a ningún
EQUIPO y como máximo a uno (0,1) y, por otra parte, a un EQUIPO pertenece como mínimo un JUGADOR y
como máximo varios (1,n). Como puedes ver, la cardinalidad (0,1) de JUGADOR se ha colocado junto a la
entidad EQUIPO para representar que un jugador puede no pertenecer a ningún equipo o como máximo a
uno. Para la cardinalidad de EQUIPO ocurre igual, se coloca su cardinalidad junto a la entidad JUGADOR
para expresar que en un equipo hay mínimo un jugador y máximo varios.

Ten en cuenta que cuando se representa la cardinalidad de una entidad, el paréntesis y sus
valores han de colocarse junto a la entidad con la que se relaciona. Es decir en el lado
opuesto a la relación.

La cardinalidad de entidades también puede representarse en el modelo Entidad/Relación con la notación

que se representa en la imagen de la derecha. Por tanto, el anterior ejemplo quedaría representado así:

16 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Utilizando otra notación:

Autoevaluación
Supongamos que seguimos diseñando una base de datos para un sitio de juegos
online. En un punto del proceso de diseño se ha de modelar el siguiente requisito:
cada usuario registrado podrá crear las partidas que desee (a las que otros usuarios
pueden unirse), pero una partida solo podrá estar creada por un único usuario. Un
usuario podrá o no crear partidas. ¿Cuáles serían las etiquetas del tipo (cardinalidad
mínima, cardinalidad máxima) que deberían ponerse junto a las entidades USUARIO y
PARTIDA respectivamente, si éstas están asociadas por la relación CREAR (partida)?

(1,N) y (0,N)
(1,1) y (1,N)
(1,1) y (0,N)

17 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

6.- El modelo E/R Extendido.

Hemos visto que a través del modelo Entidad/Relación se pueden modelar la gran mayoría de los
requisitos que una base de datos debe cumplir. Pero existen algunos que ofrecen especial dificultad a la
hora de representarlos a través de la simbología tradicional del modelo E/R. Para solucionar este
problema, en el modelo Entidad/Relación Extendido se han incorporado nuevas extensiones que permiten
mejorar la capacidad para representar circunstancias especiales.

A continuación, se detallan algunas de estas nuevas características que convierten al modelo E/R
tradicional en el modelo Entidad/Relación Extendido, como son: tipos de restricciones sobre las
relaciones, especialización y generalización.

GENERALIZACIÓN Y ESPECIALIZACIÓN

Cuando estamos diseñando una base de datos puede que nos encontremos con conjuntos de entidades
que posean características comunes, lo que permitiría crear un tipo de entidad de nivel más alto que
englobase dichas características. Y a su vez, puede que necesitemos dividir un conjunto de entidades en
diferentes subgrupos de entidades por tener éstas, características diferenciadoras. Este proceso de
refinamiento ascendente/descendente, permite expresar mediante la generalización la existencia de tipos
de entidades de nivel superior que engloban a conjuntos de entidades de nivel inferior. A los conjuntos de
entidades de nivel superior también se les denomina superclase o supertipo. A los conjuntos de
entidades de nivel inferior se les denomina subclase o subtipo.

Por tanto, existirá la posibilidad de realizar una especialización de una superclase en subclases, y
análogamente, establecer una generalización de las subclases en superclases. La generalización es
la reunión en una superclase o supertivo de entidad de una serie de subclases o subtipos de entidades,
que poseen características comunes. Las subclases tendrán otras características que las diferenciarán
entre ellas.

¿Cómo detectamos una generalización? Podremos identificar una generalización cuando encontremos
una serie de atributos comunes a un conjunto de entidades, y otros atributos que sean específicos. Los
atributos comunes conforman la superclase o supertipo y los atributos específicos la subclase o subtipo.

Las jerarquías se caracterizan por un concepto que hemos de tener en cuenta, la herencia. A través de la
herencia los atributos de una superclase de entidad son heredados por las subclases. Si una superclase
interviene en una relación, las subclases también lo harán.

¿Cómo se representa una generalización o especialización? Existen varias notaciones, pero hemos de
convenir que la relación que se establece entre una superclase de entidad y todos sus subtipos se
expresa a través de las palabras ES UN, o en notación inglesa IS A, que correspondería con ES UN TIPO
DE. Partiendo de este punto, una jerarquía se representa mediante un triángulo invertido, sobre él
quedará la entidad superclase y conectadas a él a través de líneas rectas, las subclases.

18 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

En el ejemplo de la imagen, las subclases INVITADO, REGISTRADO y ADMINISTRADOR constituyen

subclases de la superclase USUARIO. Cada una de ellas aporta sus propias características y heredan las
pertenecientes a su superclase.

Una generalización/especialización podrá tener las siguientes restricciones semánticas:

Totalidad: una generalización/especialización será total si todo ejemplar de la superclase

pertenece a alguna de las subclases.
Parcialidad: una generalización/especialización será parcial si no todos los ejemplares de la
superclase pertenecen a alguna de las subclases.
Solapamiento: una generalización/especialización presentará solapamiento si un mismo ejemplar
de la superclase puede pertenecer a más de una subclase.
Exclusividad: una generalización/especialización presentará exclusividad si un mismo ejemplar de
la superclase pertenece sólo a una subclase.

Ejercicio resuelto
Supongamos la existencia de dos entidades TURISMO y CAMION. Los atributos de la
entidad TURISMO son: Num_bastidor, Fecha_fab, precio y Num_puertas. Los atributos de la entidad
CAMION son: Num_bastidor, Fecha_fab, precio, Num_ejes y Tonelaje.

19 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Si analizamos ambas entidades existen algunos atributos comunes y otros que [Link]
tanto, podremos establecer una jerarquía.

Para ello, reuniremos los atributos comunes y los asociaremos a una nueva entidad
superclase denominada VEHICULO. Las subclases TURISMO y CAMION, con sus atributos
específicos, quedarán asociadas a la superclase VEHICULO mediante una jerarquía parcial
con solapamiento.

En el siguiente gráfico puedes apreciar la transformación.

20 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

7.- Elaboración de diagramas E/R.

Llegados a este punto, te surgirán varias dudas ¿Cómo creo un diagrama E/R? ¿Por dónde empiezo? ¿Y
qué puedo hacer con todo lo visto? Son cuestiones totalmente normales cuando se comienza, no te
preocupes, vamos a darte una serie de orientaciones para que puedas aplicar todos los conceptos
aprendidos hasta ahora en la elaboración de diagramas Entidad/Relación.

Sabemos que en la fase de diseño conceptual de la base de datos, en la que nos encontramos, hemos de
generar el diagrama E/R que representará de manera más sencilla el problema real a modelar,
independientemente del Sistema Gestor de Base de Datos.

Este esquema será como un plano que facilite la comprensión y solución del problema. Este diagrama
estará compuesto por la representación gráfica, a través de la simbología vista, de los requisitos o
condiciones que se derivan del problema a modelar.

Saltarnos este paso en el proceso de creación e implementación de una base de datos, supondría
pérdida de información. Por lo que esta fase, requerirá de la creación de uno o varios esquemas previos
más cercanos al mundo real, antes del paso a tablas del modelo relacional.

Te darás cuenta que, como en la programación, la práctica es fundamental. Los diagramas no siempre
se crean del mismo modo y, en ocasiones, hay que retocarlos e incluso rehacerlos.

A través de la resolución de diferentes problemas y la elaboración de múltiples diagramas, obtendrás la

destreza necesaria para generar esquemas que garanticen una posterior y correcta conversión del
modelo Entidad/Relación al modelo Relacional.

21 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Identificación de entidades y relaciones.

Lo primero que hemos de tener a nuestra disposición para poder generar un diagrama E/R adecuado es
el conjunto de requerimientos, requisitos o condiciones que nuestra base de datos ha de cumplir. Es lo
que se denomina el documento de especificación de requerimientos. En otras palabras, el enunciado del
problema a modelar. Cuanto más completa y detallada sea la información de la que dispongamos, mucho
mejor.

Suponiendo que conocemos la simbología del modelo Entidad/Relación y que entendemos su significado
¿Cómo empezamos? Las etapas para la creación del diagrama E/R se detallan a continuación:

a. Identificación de entidades: Es un proceso bastante intuitivo. Para localizar aquellos elementos

que serán las entidades de nuestro esquema, analizaremos la especificación de requerimientos en
busca de nombres o sustantivos. Si estos nombres se refieren a objetos importantes dentro del
problema probablemente serán entidades. Tendremos en cuenta que nombres referidos a
características, cualidades o propiedades no se convertirán en entidades.

Otra forma de identificar entidades es localizando objetos o elementos que existen por sí mismos.
Por ejemplo: VEHICULO, PIEZA, etc. En otras ocasiones, la localización de varias características o
propiedades puede dejar ver la existencia de una entidad.

¿Esto puede ser una entidad o no? Es una pregunta que se repite mucho cuando estamos en esta
etapa. Algunos autores indican que para poder considerarse como entidad se deben cumplir tres
reglas:

Existencia propia.
Cada ejemplar de un tipo de entidad debe poder ser diferenciado del resto de ejemplares.
Todos los ejemplares de un tipo de entidad deben tener las mismas propiedades.

El número de entidades obtenidas debe ser manejable y según se vayan identificando se les
otorgará nombres, preferiblemente en mayúsculas, representativos de su significado o función.
De esta manera el diagrama será cada vez más legible.

b. Identificación de relaciones: Localizadas las entidades, debemos establecer qué relación existe
entre ellas. Para ello, analizaremos de nuevo el documento de especificación de requerimientos en
busca de verbos o expresiones verbales que conecten unas entidades con otras. En la gran
mayoría de ocasiones encontraremos que las relaciones se establecen entre dos entidades
(relaciones binarias), pero prestaremos especial atención a las relaciones entre más entidades y a
las relaciones reflesivas o relaciones unarias.

Cada una de las relaciones establecidas deberá tener asignado un nombre, preferiblemente en
minúsculas, representativo de su significado o acción.

Dependiendo de la notación elegida, el siguiente paso será la representación de la cardinalidad (mínima y

máxima) de las entidades participantes en cada relación y del tipo de correspondencia de la relación (1 a
1, 1 a muchos o muchos a muchos).

Si hemos encontrado alguna relación reflexiva o unaria, hemos de representar en nuestro esquema los
roles desempeñados por la entidad en dicha relación.

22 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Autoevaluación
Rellena los huecos con los conceptos adecuados.
Las entidades suelen localizarse en el documento de especificación de requerimientos a
través de y las relaciones a través de . Pero hemos
de tener cuidado, no siempre los representarán entidades, pues
podría tratarse de atributos.

23 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Identificación de atributos, claves y jerarquías.

Sólo con la localización de entidades y relaciones no está todo hecho. Hemos de completar el proceso
realizando las siguientes tareas:

a. Identificación de atributos: Volvemos sobre el documento de especificación de requerimientos

para buscar nombres relativos a características, propiedades, identificadores o cualidades de
entidades o relaciones. Resulta más sencillo si nos preguntamos ¿Qué información es necesario
tener en cuenta de una u otra entidad o relación? Quizás no todos los atributos estén reflejados
directamente en el documento de especificación de requerimientos, aplicando el sentido común el
diseñador podrá establecerlos en algunos casos y en otros, será necesario consultar e indagar en
el problema.

Tendremos en cuenta si los atributos localizados son simples o compuestos, derivados o

calculados y si algún atributo o conjunto de ellos se repite en varias entidades. Si se da este último
caso, deberemos detenernos y plantear la posibilidad de establecer una jerarquía de
especialización, o bien, dejar las entidades tal y como han sido identificadas.

Cada atributo deberá tener asignado un nombre, preferiblemente en minúsculas, representativo de

su contenido o función. Además, siempre es recomendable recopilar la siguiente información de
cada atributo:

Nombre y descripción.
Atributos simples que lo componen, si es atributo compuesto.
Método de cálculo, si es atributo derivado o calculado.

En el caso de encontrar atributos asociados a relaciones con cardinalidad uno a muchos, se

valorará asignar ese atributo o atributos a la entidad con mayor cardinalidad participante en la
relación.

b. Identificación de claves: Del conjunto de atributos de una entidad se establecerán una o varias
claves candidatas, escogiéndose una de ellas como clave primaria de la entidad. Esta clave estará
formada por uno o varios atributos que identificarán de manera unívoca cada ocurrencia de
entidad. El proceso de identificación de claves permitirá determinar la fortaleza (al menos una clave
candidata) o debilidad (ninguna clave candidata) de las entidades encontradas.

Se representará la existencia de esta clave primaria mediante la notación elegida para la

elaboración el diagrama E/R. Del mismo modo, se deberán representar adecuadamente las
entidades fuertes o débiles.

c. Determinación de jerarquías: Como se ha comentado anteriormente, es probable que existan

entidades con características comunes que puedan ser generalizadas en una entidad de nivel
superior o superclase (jerarquía de generalización). Pero también, puede ser necesario expresar en
el esquema las particularidades de diferentes ejemplares de un tipo de entidad, por lo que se
crearán subclases o subtipos de una superclase o supertipo (jerarquía de especialización). Para
ello, habrá que analizar con detenimiento el documento de especificación de requerimientos.

Si se identifica algún tipo de jerarquía, se deberá representar adecuadamente según el tipo de

notación elegida, determinando si la jerarquía es total/parcial o exclusiva/con solapamiento.

24 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Metodologías.
Hasta aquí, tenemos identificados los elementos necesarios para construir nuestro diagrama, pero
¿Existe alguna metodología para llevarlo a cabo? Sí, y además podremos utilizar varias. Partiremos de
una versión preliminar del esquema conceptual o diagrama E/R que, tras sucesivos refinamientos, será
modificado para obtener el diagrama E/R definitivo. Las metodologías o estrategias disponibles para la
elaboración del esquema conceptual son las siguientes:

a. Metodología Descendente (Top-Down): Se trata de partir de un esquema general e ir

descomponiendo éste en niveles, cada uno de ellos con mayor número de detalles. Se parte de
objetos muy abstractos, que se refinan paso a paso hasta llegar al esquema final.
b. Metodología Ascendente (Bottom-Up): Inicialmente, se parte del nivel más bajo, los atributos. Se
irán agrupando en entidades, para después ir creando las relaciones entre éstas y las posibles
jerarquías hasta obtener un diagrama completo. Se parte de objetos atómicos que no pueden ser
descompuestos y a continuación se obtienen abstracciones u objetos de mayor nivel de
abstracción que forman el esquema.
c. Metodología Dentro-fuera (Inside-Out): Inicialmente se comienza a desarrollar el esquema en
una parte del papel y a medida que se analiza la especificación de requerimientos, se va
completando con entidades y relaciones hasta ocupar todo el documento.
d. Metodología Mixta: Es empleada en problemas complejos. Se dividen los requerimientos en
subconjuntos que serán analizados independientemente. Se crea un esquema que servirá como
estructura en la que irán interconectando los conceptos importantes con el resultado del análisis de
los subconjuntos creados. Esta metodología utiliza las técnicas ascendente y descendente. Se
aplicará la técnica descendente para dividir los requerimientos y en cada subconjunto de ellos, se
aplicará la técnica ascendente.

¿Cuál de estas metodologías utilizar? Cualquiera de ellas puede ser válida, todo dependerá de lo fácil y
útil que te resulte aplicarlas. Probablemente y, casi sin ser consciente de ello, tú mismo crearás tu propia
metodología combinando las existentes. Pero, como decíamos, la práctica es fundamental. Realizando
gran cantidad de esquemas, analizándolos y llevando a cabo modificaciones en ellos es como irás
refinando tu técnica de elaboración de diagramas E/R. Llegará un momento en que sólo con leer el
documento de especificación de requerimientos serás capaz de ir construyendo en tu mente cómo será
su representación sobre el papel, pero paciencia y ve paso a paso.

Autoevaluación
Rellena los huecos con los conceptos adecuados.
La metodología en la que se parte de un alto nivel de abstracción y que, tras un proceso de
refinamiento sucesivo, se obtiene el esquema final se denomina:
.

25 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Redundancia en diagramas E/R.

Una de las principales razones por las que las bases de datos aparecieron fue la eliminación de la
redundancia en los datos ¿Y qué es la redundancia?

Redundancia: reproducción, reiteración, insistencia, reincidencia, reanudación. En bases de

datos hace referencia al almacenamiento de los mismos datos varias veces en diferentes
lugares.

La redundancia de datos puede provocar problemas como:

Aumento de la carga de trabajo: al estar almacenado un dato en varios lugares, las operaciones
de grabación o actualización de datos necesitan realizarse en varias ocasiones.
Gasto extra de espacio de almacenamiento: al estar repetidos, los datos ocupan mayor cantidad
de espacio en el medio de almacenamiento. Cuanto mayor sea la base de datos, más patente se
hará esta problema.
Inconsistencia: se produce cuando los datos que están repetidos, no contienen los mismos
valores. Es decir, se ha actualizado su valor en un lugar y en otro no, por lo que no se sabría qué
dato es válido y cual erróneo.

Para que una base de datos funcione óptimamente, hay que empezar realizando un buen diseño de ella.
Es imprescindible que nuestros diagramas E/R controlen la redundancia y, para ello, debemos analizar el
esquema y valorar qué elementos pueden estar incorporando redundancia a nuestra solución.

¿Dónde buscamos indicios de redundancia en nuestros esquemas? Existen lugares y elementos que
podrían presentar redundancia, por ejemplo:

Atributos redundantes cuyo contenido se calcula en función de otros. Un atributo derivado puede
ser origen de redundancia.
Varias entidades unidas circularmente o cíclica a través de varias relaciones, es lo que se conoce
como un ciclo. En caso de existir un ciclo, deberemos tener en cuenta las siguientes condiciones,
antes de poder eliminar dicha relación redundante:
Que el significado de las relaciones que componen el ciclo sea el mismo.
Que si eliminamos la relación redundante, el significado del resto de relaciones es el mismo.
Que si la relación eliminada tenía atributos asociados, éstos puedan ser asignados a alguna
entidad participante en el esquema, sin que se pierda su significado.

Pero hay que tener en cuenta que no siempre que exista un ciclo estaremos ante una redundancia.
Es necesario analizar detenidamente dicho ciclo para determinar si realmente existe o no redundancia.

Para finalizar, una apreciación. No toda redundancia es perjudicial. Existen ciertas circunstancias y
condiciones en las que es conveniente (sobre todo a efectos de rendimiento) introducir cierta
redundancia controlada en una base de datos.

Por ejemplo, si el método de cálculo del valor de un determinado atributo derivado es complejo (varias
operaciones matemáticas o de cadenas de caracteres, varios atributos implicados, etc.) y ralentiza el
funcionamiento de la base de datos, quizá sea conveniente definir dicho atributo desde el principio y no
considerarlo como un atributo redundante. La incorporación o no de redundancia controlada dependerá
de la elección que haga el diseñador.

26 de 27
Ut2.- Interpretación del diseño conceptual. Diagramas Entidad/Relación.

Propiedades deseables de un diagrama E/R.

Cuando construimos un diagrama Entidad/Relación existen una serie de propiedades o características
que éste debería cumplir. Quizá no se materialicen todas, pero hemos de intentar cubrir la gran mayoría
de ellas. De este modo, conseguiremos que nuestros diagramas o esquemas conceptuales tengan mayor
calidad.

Estas características o propiedades deseables se desglosan a continuación:

Completitud: Un diagrama E/R será completo si es posible verificar que cada uno de los
requerimientos está representado en dicho diagrama y viceversa, cada representación del
diagrama tiene su equivalente en los requerimientos.
Corrección: Un diagrama E/R será correcto si emplea de manera adecuada todos los elementos
del modelo Entidad/Relación. La corrección de un diagrama puede analizarse desde dos vertientes:
Corrección sintáctica: Se producirá cuando no se produzcan representaciones erróneas en
el diagrama.
Corrección semántica: Se producirá cuando las representaciones signifiquen exactamente lo
que está estipulado en los requerimientos. Posibles errores semánticos serían: la utilización
de un atributo en lugar de una entidad, el uso de una entidad en lugar de una relación,
utilizar el mismo identificador para dos entidades o dos relaciones, indicar erróneamente
alguna cardinalidad u omitirla, etc.
Minimalidad: Un diagrama E/R será mínimo si se puede verificar que al eliminar algún concepto
presente en el diagrama, se pierde información. Si un diagrama es redundante, no será mínimo.
Sencillez: Un diagrama E/R será sencillo si representa los requerimientos de manera fácil de
comprender, sin artificios complejos.
Legibilidad: Un diagrama E/R será legible si puede interpretarse fácilmente. La legibilidad de un
diagrama dependerá en gran medida del modo en que se disponen los diferentes elementos e
interconexiones. Esta propiedad tiene mucho que ver con aspectos estéticos del diagrama.
Escalabilidad: Un diagrama E/R será escalable si es capaz de incorporar posibles cambios
derivados de nuevos requerimientos.

Autoevaluación
Si en un diagrama E/R asociamos un atributo a una entidad, pero este atributo debe
asociarse realmente a una relación en la que interviene dicha entidad, estaríamos
incumpliendo la propiedad de:

Completitud.
Corrección semántica.
Corrección sintáctica.

27 de 27