2.

Modelo entidad-relación (ER)

El modelo de datos de entidad-relación (ER) se basa en una

percepción de un mundo real que consiste en un conjunto de objetos básicos
llamados entidades y de relaciones entre estos objetos. Se desarrolló para
facilitar el diseño de bases de datos permitiendo especificar un esquema
empresarial.

Hay tres nociones básicas que emplea el modelo de datos ER:

entidades, relaciones y atributos.

2.1. Entidad

Denominamos Entidad a la abstracción que permite representar

aquellos objetos del mundo real que comparten una serie de características
comunes.

Una entidad tiene un conjunto de propiedades, y los valores para

algún conjunto de propiedades pueden identificar una entidad de forma
unívoca. Por ejemplo, el CURP AAGM820405MVZPLL09 identifica
unívocamente una persona particular en la empresa.

Una entidad puede ser concreta, como una persona o un libro o

pueden ser abstractas como una fecha o un préstamo. Cada uno de los
objetos concretos que pertenecen a la entidad es un Ejemplar u Ocurrencia
de entidad.

La entidad en sentido abstracto se refiere a un conjunto de elementos

con características comunes, como por ejemplo la entidad cliente, una
ocurrencia, realización u instancia podía ser José.

“Fundamentos de bases de datos SCM-0412”

- 26 -
 Las entidades las podemos clasificar como:

Fuerte: Es aquellas que existen por sí mismas y que la existencia de un

ejemplar en la entidad no depende de la existencia de otros ejemplares en
otra entidad.

Débil: Son aquellas entidades en las que se hace necesaria la existencia de

ejemplares de otras entidades distintas para que puedan existir ejemplares
en esta entidad.

Un conjunto de entidades es un grupo de entidades del mismo tipo. El

conjunto de todas las personas que tienen una cuenta en el banco, por
ejemplo, puede definirse como el conjunto de entidades clientes.

Una entidad está representada por un conjunto de atributos. Los

posibles atributos del conjunto de entidades cliente son nombre, CURP, calle
y ciudad. Cada entidad tiene un valor para cada uno de sus atributos, como
por ejemplo la entidad cliente puede tener el valor de Juan para el atributo
nombre.

Para cada atributo existe un rango de valores permitidos, llamado

dominio del atributo. El dominio del atributo nombre podría ser el conjunto
de todos los nombres de personas de cierta longitud.

Un atributo, como se usa en el modelo E-R, se puede caracterizar por los

siguientes tipos de atributos.

• Atributos simples y compuestos. Los atributos simples son los que

no están divididos en subpartes (es decir los que no se pueden dividir
en otros atributos), ejemplos de estos son: estatura, edad, peso. Los
atributos compuestos son los que se pueden dividir en subpartes (es

“Fundamentos de bases de datos SCM-0412”

- 27 -
 decir, en otros atributos). Por ejemplo el nombre de un cliente podría
estar estructurado como un atributo compuesto consistente nombre,
primer apellido y segundo apellido.

Figura 2.7. Ejemplo de atributos compuestos

• Atributos monovalorados y multivalorados. Los atributos

monovalorados son aquellos que solo puede tener un único valor, los
ejemplos anteriores tienen solo un valor para entidad. Como ejemplo,
el atributo nombre del equipo para una entidad equipo hace referencia
a un único valor. Los atributos multivalorados son aquellos atributos
que pueden tener varios valores. Por ejemplo, el atributo número de
asistencias de un jugador de básquetbol puede tener una o mas
asistencias.

• Atributos derivados. Son aquellos cuyo valor se obtiene a partir de

otros atributos. Por ejemplo, si el conjunto de entidades cliente tiene
un atributo fecha_nacimiento, se puede calcular la edad a partir de la
fecha de nacimiento y de la fecha actual. El valor de un atributo
derivado no se almacena, sino que se calcula cuando sea necesario.

Un atributo toma un valor nulo cuando una entidad no tiene un valor para
un atributo. El valor nulo también puede indicar no aplicable, es decir, que el
valor no existe para la entidad. Por ejemplo, una persona puede no tener
segundo nombre de pila. Nulo también puede designar que el valor de un
atributo es desconocido. Un valor desconocido puede ser, bien perdido (el
“Fundamentos de bases de datos SCM-0412”
- 28 -
valor existe pero no se tiene esa información) o desconocido (no se conoce si
el valor existe realmente o no).

Por ejemplo, si el valor nombre para un jugador es nulo, se asume que el

valor es perdido, ya que cada jugador debe de tener un nombre.

2.2. Relación

Una relación es una asociación entre varias entidades. Por ejemplo es

posible definir una relación que asocie al cliente Gutiérrez con la cuenta 401.
Esta relación específica que Gutiérrez es un cliente con el préstamo número
401. Cada asociación que se establece entre ejemplares concretos de las
entidades que interviene en una relación se denomina EJEMPLAR u
ocurrencia de relación.

Un conjunto de relaciones es un grupo de relaciones del mismo tipo.

Considérese el conjunto de entidades cliente y cuenta. Se definirá el
conjunto de relaciones cliente-cuenta para denotar la asociación entre los
clientes y las cuentas bancarias que tienen.

Las relaciones binarias, son aquellas que implican a dos conjuntos de

entidades, (por ejemplo la relación cliente-cuenta) Existen conjuntos de
relaciones que incluyen a n-conjuntos de entidades, estas don las relaciones
n-arias, por ejemplo las relaciones ternaria cliente-cuenta-sucursal que
especifica que el cliente Gutiérrez tienen la cuenta 401 en la surcusal
Córdoba.

Las relaciones recursivas son relaciones binarias que conectan una

entidad consigo misma.

“Fundamentos de bases de datos SCM-0412”

- 29 -
 El número de conjuntos de entidades que participan en un conjunto de
relaciones es también el grado del conjunto de relaciones. Un conjunto de
relaciones binarias tiene grado 2; un conjunto de relaciones ternario tiene
grado 3.

Una relación también puede tener atributos descriptivos o rótulos.

Por ejemplo, fecha podría ser un atributo del conjunto de relaciones cliente-
cuenta. Esto especifica la última fecha en que el cliente tuvo acceso a su
cuenta.

2.3. Correspondencia de cardinalidad

Hay que tener en cuenta en el modelo de E-R la cardinalidad de cada

extremo en una relación. La cardinalidad expresa cuántas del conjunto de
entidades de un extremo de la relación están relacionadas con cuántas
entidades del conjunto del otro extremo. Pueden ser ``uno a uno'', ``uno a
varios'' o ``varios a varios''.

Supongamos para un conjunto de relaciones binarias R entre los

conjuntos de entidades A y B, la correspondencia de cardinalidad debe de
ser una de las siguientes:

• Una a una: una entidad de A está asociada únicamente con una

entidad de B y una entidad de B está asociada solo con una entidad
de A (Figura 2.8).

“Fundamentos de bases de datos SCM-0412”

- 30 -
 Figura 2.8. Relación una a una

• Una a muchas: una entidad en A está asociada con varias entidades

de B, pero una entidad de B puede asociarse únicamente con una
entidad de A (Figura 2.9).

Figura 2.9. Relación una a muchas

y Muchas a una: una entidad de A está asociada únicamente con

una entidad en B, pero una entidad de B está relacionada con
varias entidades de A (Figura 2.11).

“Fundamentos de bases de datos SCM-0412”

- 31 -
 Figura 2.10. Relación muchas a una

• Muchas a muchas: una entidad en A está asociada con varias

entidades de B y una entidad en B está vinculada con varias
entidades de A (Figura 2.11).

Figura 2.11. Relación muchas a muchas

Para ilustrar lo anterior, considérese el conjunto de relaciones cliente-

cuenta. Si en un banco dado una cuenta puede pertenecer únicamente a un
cliente y un cliente puede tener varias cuentas, entonces el conjunto de
relaciones cliente-cuenta es una a muchas, de cliente a cuenta. Si una
cuenta puede pertenecer a varios clientes, entonces el conjunto de
relaciones cliente-cuenta es una a muchas, de cuenta a cliente, entonces en
definitiva el conjunto de relaciones cliente-cuenta es muchas a muchas.

“Fundamentos de bases de datos SCM-0412”

- 32 -
 Las dependencias de existencia constituyen otra clase importante de
limitantes. Si la existencia de la entidad x depende de la existencia de la
entidad y, entonces se dice que x es dependiente por existencia de y.
Funcionalmente esto quiere decir que si se elimina y, también se eliminará x.
Se dice que la entidad y en una entidad dominante y que x es una entidad
subordinada. Por ejemplo supongamos que tenemos los conjuntos de
entidades cuenta y transacción. Se forma la relación cuenta-transac entre
estos dos conjuntos es decir que para una cuenta determinada pueden existir
varias transacciones. Esta relación es una a muchas de cuenta a
transacción. Cada entidad transacción debe estar relacionada con una
entidad cuenta. Si se elimina una entidad cuenta, entonces deben eliminarse
también todas las entidades transacción vinculada con esa cuenta. Por lo
contrario pueden eliminarse entidades transacción de la base de datos sin
afectar ninguna cuenta. Por lo tanto, el conjunto de entidades cuenta es
dominante y transacción es subordinada en la relación cuenta-transac.

♦ Claves

Es necesario tener una forma de especificar cómo las entidades

dentro de un conjunto de entidades dado y las relaciones dentro de un
conjunto de relaciones dado son distinguibles. Conceptualmente las
entidades y relaciones individuales son distintas; desde una perspectiva de
bases de datos, sin embargo, la diferencia entre ellas se debe expresar en
términos de sus atributos.

Por lo tanto, los valores de los atributos de una entidad deben ser
tales que permitan identificar unívocamente a la entidad. En otras palabras,
no se permite que ningún par de entidades tengan unívocamente los mismos
valores de sus atributos.

“Fundamentos de bases de datos SCM-0412”

- 33 -
 Una clave permite identificar un conjunto de atributos suficiente para
distinguir las entidades entre sí. Las claves también ayudan a identificar
unívocamente a las relaciones y así distinguir las relaciones entre sí.

Una superclave es un conjunto de atributos que permiten identificar

unívocamente a una entidad dentro de un conjunto de entidades. Este tipo de
claves contiene comúnmente atributos ajenos; es decir; atributos que no son
indispensables para llevar a cabo el reconocimiento del registro. Por ejemplo,
atributo id-cliente del conjunto de entidades cliente es suficiente para
distinguir una entidad cliente de las otras. Así, id-cliente es un a superclave.
Análogamente, la combinación de nombre-cliente e id-cliente es una
superclave del conjunto de entidades cliente. El atributo nombre-cliente de
cliente no es una superclave porque varias personas podrían tener el mismo
nombre.

Las claves candidatas son aquellas superclaves que no contienen

atributos ajenos; es decir, aquellos conjuntos de atributos que no tienen un
subconjunto menor que pueda considerarse como superclave.

Una clave primaria en una clave candidata elegida por el diseñador

de la base de datos para identificar unívocamente a las distintas entidades
de un tipo.

2.4. Diagrama entidad-relación

La estructura lógica general de una base de datos puede expresarse en

forma gráfica por medio de un diagrama ER que se integra con los siguientes
componentes:

“Fundamentos de bases de datos SCM-0412”

- 34 -
Cuadro 2.1.- Símbolos usados en el diagrama entidad-relación.
Nombre Gráfica

Entidades fuertes

Atributos

Relaciones

Conector de entidades y
atributos

Atributos multivalorados

Atributos derivados

Indicador de participación
total de una entidad en
una relación.

Entidad débil

Identificador de conjunto
se entidades débiles.

Clave primaria
A

Relación varios a varios

R

Relación varios a uno

R

“Fundamentos de bases de datos SCM-0412”

- 35 -
 Relación uno a uno
R

Especialización o
generalización
ES

Considérese el diagrama entidad-relación de la siguiente figura, que

consiste en dos conjuntos de entidades cliente y préstamo, relacionados
mediante el conjuntos de relaciones binarias prestatario. En la figura 2.12 los
atributos de conjunto de entidades que son miembros de la clave primaria
están subrayados.

Figura 2.12. Relación varios a varios.

Si el conjunto de relaciones prestatario fuera uno a varios, desde cliente

a préstamo, entonces la línea desde prestatario a cliente sería dirigida, con
una flecha que apuntaría al conjunto de entidades cliente (Figura 2.13).

Figura 2.13. Relación una a varias

“Fundamentos de bases de datos SCM-0412”

- 36 -
 Si el conjunto de relaciones prestatario fuera varios a uno desde cliente
a préstamo, entonces la línea desde prestatario a préstamo tendría una
flecha que apuntaría al conjunto de entidades préstamo (figura 2.14).

Figura 2.14. Relación varios a una

Si el conjunto de relaciones prestatario fuera de entidades préstamo y

otra apuntaría al conjunto de entidades cliente (figura 2.15).

Figura 2.15 Relación una a una

La figura 2.16 muestra como se pueden representar los atributos

compuestos. En este caso, el atributo compuesto nombre, con los atributos
componentes nombre_pila, primer_apellido y segundo_apellido sustituye el
atributo simple nombre_cliente de cliente. Además el atributo compuesto
dirección, cuyos atributos componentes son calle, ciudad, provincia y
código_postal, sustituye a los atributos calle_cliente y ciudad_cliente de
cliente. El atributo calle es por sí mismo un atributo compuesto cuyos
componentes son número_calle, nombre_calle y número_pago.

“Fundamentos de bases de datos SCM-0412”

- 37 -
 También muestra un atributo multivalorado, número_teléfono, indicado
por una elipse doble y un atributo derivado, indicado por una elipse
discontinua.

Figura 2.16.- Ejemplo de atributos compuestos, multivalorados y

derivados.

♦ Características del modelo entidad-relación extendido

Son relaciones de contención que existen entre un conjunto de entidades

fuertes y uno o más conjunto de entidades débiles.

La especialización es el resultado de tomar un subconjunto de un

conjunto de entidades fuertes, para formar un conjunto de entidades de más
débiles.

Como ejemplo, considérese el conjunto de entidades persona con los

atributos id_persnona, nombre, calle y ciudad. Cada persona se pude
clasificarse de una de las siguientes categorías:

• cliente
• empleado

“Fundamentos de bases de datos SCM-0412”

- 38 -
 Cada uno de estos tipos de personas se describen mediante un conjunto
de atributos que incluyen todos los atributos del conjunto de entidades
persona más otros posibles atributos adicionales. Por ejemplo, las entidades
cliente se pueden describir además mediante el atributo
clasificación_crediticia, mientras que las entidades empleado se pueden
describir además mediante el atributo sueldo. El proceso de establecimiento
de subgrupos dentro del conjunto de entidades se denomina
especialización. La especialización de persona permite distinguir entre las
personas basándose en si son empleados o clientes: en general, cada
persona puede ser empleado, cliente, las dos cosas o ninguna de ellas.

En términos de los diagramas E-R, la especialización se representa

mediante un componente triangular etiquetado ES, como se muestra en la
figura 2.17.

La generalización es una relación de concatenación que existe entre el

conjunto de entidades de nivel superior y uno o varios conjuntos de
entidades de nivel inferior.

Por ejemplo, persona es el conjunto de entidades de nivel superior y

cliente y empleado son conjuntos de entidades de nivel inferior. En este caso,
los atributos que son conceptualmente iguales tienen nombres diferentes en
los dos conjuntos de entidades de nivel inferior. Para crear la generalización
los atributos deben de tener un nombre común y representarse mediante la
entidad de nivel superior persona.

Los conjuntos de entidades de nivel superior e inferior también se pueden

denominar con los términos superclase y subclase. El conjunto de
entidades persona es la superclase de las subclases cliente y empleado.

“Fundamentos de bases de datos SCM-0412”

- 39 -
 Figura 2.17. Ejemplos Generalización y Especialización

La generalización se utiliza para hacer resaltar las semejanzas entre los

tipos de entidades débiles y para ocultar sus diferencias. La especialización
es lo inverso, hace resaltar las diferencias entre los conjuntos de entidades
fuertes y débiles. Los atributos son lo que los distinguen. Esto se realiza
mediante la herencia de atributos. Los conjuntos débiles heredan los
atributos de los conjuntos de entidades fuertes.

Un tipo de restricción a las generalizaciones implica la determinación de

las entidades que pueden formar parte de un conjunto de entidades de nivel
inferior dado. Esta pertenencia puede ser una de las siguientes:

• Definida por la condición. En los conjuntos de entidades de nivel

inferior definidos por la condición, la pertenencia se evalúan en función
del cumplimiento de una condición o predicado explícito por la entidad.
Por ejemplo, supóngase que el conjunto de entidades de nivel superior
cuenta tiene el atributo tipo_cuenta. Todas las entidades cuenta se
evalúan según el atributo tipo_cuenta que las define. Sólo las

“Fundamentos de bases de datos SCM-0412”

- 40 -
 entidades que satisfacen la condición tipo_cuenta=”cuenta de ahorro”
pueden pertenecer al conjunto de entidades de nivel inferior
cuenta_ahorro. Todas las entidades que satisfacen la condición
tipo_cuenta=”cuenta corriente” se incluyen en cuenta_corriente. Dado
que todas las entidades de nivel inferior se evalúan en función del
mismo atributo, se dice que este tipo de generalización está definida
por el atributo.
• Definida por el usuario. Los conjuntos de entidades de nivel inferior
definidos por el usuario no están restringidos por una condición de
pertenencia; más bien, el usuario de la base de datos asigna las
entidades a un conjunto de entidades dado. Por ejemplo, supóngase
que, después de tres meses de trabajo, los empleados del banco se
asignan a uno de los cuatro grupos de trabajo. En consecuencia, los
grupos representan como cuatro conjuntos de entidades de nivel
inferior del conjunto de entidades de nivel superior empleado. No se
asigna cada empleado a una entidad grupo concreta automáticamente
de acuerdo con una condición explícita que lo defina. En vez de eso,
la asignación al grupo la lleva a cabo el usuario que toma persona a
persona. La asignación se implementan mediante una operación que
añade cada entidad a un conjunto de entidades.

Un segundo tipo de restricciones tiene la relación con la pertenencia de

las entidades a más de un conjunto de entidades de nivel inferior de la
generalización. Los conjuntos de entidades de nivel inferior pueden ser de
uno de los siguientes tipos:

• Disjuntos. La restricción sobre la condición de disjunción exige que

cada entidad no pertenezca a más de un conjunto de entidades de
nivel inferior. En el ejemplo, cada entidad cuenta sólo puede cumplir
una condición del atributo tipo_cuenta, cada entidad puede ser una

“Fundamentos de bases de datos SCM-0412”

- 41 -
 cuenta de ahorro o una cuenta corriente, pero no ambas cosas ala
vez.
• Solapados. En las generalizaciones solapadas la misma entidad
puede pertenecer a más de un conjunto de entidades de nivel inferior
de la generalización. Considérese el ejemplo del grupo de trabajo de
empleado y supóngase que algunos directores participan en más de
un grupo de trabajo. Cada empleado, por lo tanto, puede aparecer en
más de uno de los conjuntos de entidades grupo que son conjuntos de
entidades de nivel inferior de empleado. Por lo tanto, la generalización
es solapada.

Una última restricción, la restricción de completitud sobre una

generalización o especialización, especifica si una entidad del conjunto de
entidades de nivel superior debe pertenecer, al menos, a uno de los
conjuntos de entidades de nivel inferior de la generalización o
especialización. Esta restricción puede ser de uno de los siguientes tipos:

• Generalización o especialización total. Cada entidad de nivel

superior debe pertenecer a un conjunto de entidades de nivel inferior.
• Generalización o especialización parcial. Puede que alguna entidad
de nivel superior no pertenezca a ningún conjunto de entidades de
nivel inferior.

La generalización parcial es la predeterminada. Se puede especificar la

generalización total en los diagramas E-R usando una línea doble para
conectar el rectángulo que representa el conjunto de entidades de nivel
superior con el símbolo triangulo.

Una limitación del modelo ER es que no es posible expresar relaciones

entre relaciones. Tomemos la relación ternaria trabaja_en, entre empleado,
sucursal y trabajo (figura 2.18). Supóngase que ahora que se desea registrar

“Fundamentos de bases de datos SCM-0412”

- 42 -
el director responsable de las tareas realizadas por cada empleado de cada
sucursal, es decir, se desea registrar al director responsable de las
combinaciones (empleado, sucursal, trabajo). Supóngase que existe un
conjunto de entidades director.

Una alternativa para representar esta relación es crear una relación

dirige entre empleado, sucursal, trabajo y director (se necesita una relación
cuaternaria, una relación binaria entre director y empleado no permitiría
representar las combinaciones (sucursal, trabajo) de cada empleado que son
responsabilidad de cada director) (figura 2.18).

Figura 2.18. Ejemplo de relaciones redundantes

Parece que los conjuntos de relaciones trabaja_en y dirige se puede

combinar en un solo conjunto de relaciones. No obstante, no se deben
combinar en una sola relación, ya que puede que algunas combinaciones
empleado, sucursal, trabaja_en no tenga director.

No obstante, hay información redundante en la figura obtenida ya que

cada combinación empleado, sucursal, trabajo de dirige también está en
trabaja_en. Si el director fuese un valor en lugar de una entidad director, se
podría hacer que director fuese un atributo multivalorado del la relación

“Fundamentos de bases de datos SCM-0412”

- 43 -
trabaja_en. Pero eso dificulta encontrar, por ejemplo, las tripletas empleado-
sucursal-trabajo de la que es responsable cada director. Como el director es
una entidad director, esta alternativa queda descartada en cualquier caso.

La mejor forma de modelar una situación como la descrita es usar la

agregación. La agregación es una abstracción a través de la cual las
relaciones se tratan como entidades de nivel superior. Así, para este ejemplo,
se considera el conjunto de relaciones trabaja_en (que relaciona los
conjuntos de entidades empleado, sucursal y trabajo) como el conjunto de
entidades de nivel superior denominado trabaja_en. Ese conjunto de
entidades se trata de la misma forma que cualquier otro conjunto de
entidades. Se puede crear entonces la relación binaria dirige entre
trabaja_en y director para representar el responsable de cada tarea (figura
2.19).

Figura 2.19. Ejemplo de agregación

2.4. Diseño de un esquema de base de datos

Un modelo de datos de alto nivel sirve al diseñador de la base de

datos para proporcionar un marco conceptual en el que especificar de forma
sistemática los requisitos de datos que existen, y cómo se estructurará la
base de datos para completar estos requisitos. La fase inicial del diseño de

“Fundamentos de bases de datos SCM-0412”

- 44 -
bases de datos, por tanto, es caracterizar completamente las necesidades de
datos esperadas por los usuarios de la base de datos. El resultado de esta
fase es una especificación de requisitos del usuario.

El diseñador elige un modelo de datos y, aplicando los conceptos de l

modelo de datos elegido, traduce estos requisitos a un esquema conceptual
de la base de datos. El es quema desarrollado en esta fase de diseño
conceptual proporciona una visión detallada del desarrollo. En términos del
modelo E-R, el esquema especifica todos los conjuntos de entidades,
conjuntos de relaciones, atributos y restricciones de correspondencia. El
diseñador revisa el esquema para confirmar que todos los requisitos de datos
se satisfacen realmente y no hay conflictos entre sí. También se examina el
diseño para eliminar características redundantes. Lo importante en este
punto es describir los datos y las relaciones, más que especificar detalles del
almacenamiento físico.

Un esquema conceptual completamente desarrollado indicará también

los requisitos funcionales de la empresa. En una especificación de
requisitos formales los usuarios describen los tipos de operaciones (o
transacciones) que se realizan sobre los datos. Algunos ejemplos de
operaciones son la modificación o actualización de datos, la búsqueda y
recuperación de datos específicos y el borrado de datos. En esta fase de
diseño conceptual se puede hacer una revisión del esquema para encontrar
los requisitos funcionales.

El proceso de trasladar un modelo abstracto de datos a la

implementación de la base de datos consta de dos fases de diseño finales.
En fase de diseño lógico, el diseñador traduce el esquema conceptual de
alto nivel al modelo de datos de la implementación del sistema de base de
datos que se usará. El diseñador usa el esquema resultante específico a la
base de datos en la siguiente fase de diseño lógico, en la que se

“Fundamentos de bases de datos SCM-0412”

- 45 -
especifican las características físicas de la base de datos. Estas
características incluyen la forma de organización de los archivos y las
estructuras del almacenamientos interno.

Ahora veremos los requisitos de diseño de la base de datos para el banco

y desarrollaremos un diseño mas realista, aunque también mas complicado
de lo que se ha visto anteriormente. Sin embargo, no se intentará modelar
cada aspecto del diseño de la base de datos para un banco; se consideraran
sólo unos cuantos aspectos para ilustrar el diseño de bases de datos.

♦ Requisitos de datos

La especificación inicial de los requisitos de usuario se puede basar en

entrevistas con los usuarios de la base de datos y en el análisis propio del
diseñador del desarrollo. La descripción que surge de esta fase de diseño
sirve como base para especificar la estructura conceptual de la base de
datos. La siguiente lista describe los principales requisitos del banco:

• El banco está organizado en sucursales. Cada sucursal está ubicada

en una ciudad particular y se identifica por un nombre único. El banco
supervisa los activos de cada sucursal.
• Los clientes del banco se identifican mediante sus valores de id-
cliente. El banco almacena cada nombre de cliente, la calle y ciudad
donde viven los clientes. Los clientes pueden tener cuentas y puede
pedir préstamos. Un cliente puede estar asociado con un banquero
particular, que puede actuar como responsable de préstamos o
banquero personal para un cliente.
• Los empleados del banco se identifican mediante sus valores de id-
empleado. La administración del banco almacena el nombre y número
de teléfono de cada empleo, los nombres de los subordinados del
empleado, y el número id-empleado del jefe del empleado. El banco

“Fundamentos de bases de datos SCM-0412”

- 46 -
 también mantiene registro de la fecha de comienzo del contrato del
empleado, así su antigüedad.
• El banco ofrece dos tipos de cuentas: cuentas de ahorro y cuentas
corrientes. Las cuentas pueden asociarse a más de un cliente y un
cliente puede tener más de una cuenta. Cada cuenta está asignada a
un único número de cuenta. El banco mantiene un registro del saldo
de cada cuenta y la fecha más reciente en que la cuenta fue accedida
por cada cliente que mantiene la cuenta. Además, cada cuenta de
ahorro tiene un tipo de interés y para cada cuenta corriente se
almacena el descubierto.
• Un préstamo tiene lugar en una sucursal particular y puede estar
asociada a uno o más clientes. Un préstamo se identifica mediante un
único número de préstamo. Para cada préstamo el banco mantiene
registro del importe del préstamo y de los pagos del préstamo. Aunque
un número de pago del préstamo no identifica de forma única un pago
entre todos los préstamos del banco, un número de pago identifica un
pago particular para un préstamo específico. Para cada pago se
almacena la fecha y el importe.

En un desarrollo de un banco real, el banco mantendrá información de

los abonos y cargos en las cuentas de ahorros y en las cuentas
corrientes, igual que se mantiene registro de los pagos para los
préstamos. Debido a que los requisitos del modelo para es seguimiento
son similares, y para mantener nuestro ejemplo reducido, en este modelo
no se mantiene un seguimiento de tales abonos y cargos.

♦ Designación de los conjuntos de entidades

La especificación de los requisitos de datos sirve como punto de

partida para la construcción de un esquema conceptual para la base de

“Fundamentos de bases de datos SCM-0412”

- 47 -
 datos. Se comienza a identificar los conjuntos de entidades y sus
atributos.

• El conjunto de entidades sucursal, con los atributos nombre-sucursal,

cd-sucursal y activo.
• El conjunto de entidades cliente, con los atributos id-cliente, nombre-
cliente, calle-cliente y cd-cliente. Un posible atributo adicional es
nombre-banquero.
• El conjunto de entidades empleado, con los atributos id-empleado,
nombre-empleado, numero-telefono, sueldo y jefe. Algunas
características descriptivas adicionales son el atributo multivalorado
nombre-subordinado, el atributo base fecha-comienzo y el atributo
derivado antigüedad.
• Dos conjuntos de entidades cuenta – cuenta.ahorro y cuenta-corriente
– con los atributos comunes cuenta-corriente y saldo; además, cuenta-
ahorro tiene el atributo tipo-interes y cuenta-corriente tiene el atributo
descubierto.
• El conjunto de entidades prestamo, con los atributos numero-
prestamo, importe y sucursal-origen.
• El conjunto de entidades débiles pago-prestamo, con los atributos
numero-pago, fecha-pago e importe-pago.

♦ Designación de los conjuntos de relaciones

Ahora se especifican los siguientes conjuntos de relaciones y

correspondencia de cardinalidades.

• prestatario, un conjunto de relaciones varios a varios entre cliente y

préstamo.
• prestamo-sucursal, un conjunto de relaciones varios a uno que indica
la sucursal en que se ha originado un préstamo. Nótese que este

“Fundamentos de bases de datos SCM-0412”

- 48 -
 conjunto de relaciones reemplaza al atributo sucursal-origen del
conjunto de entidades prestamo.
• pago-prestamo, un conjunto de relaciones uno a varios de prestamo a
pago, que documenta que se ha realizado un pago de préstamo.
• impositor, con el atributo de relación fecha-acceso, un conjunto de
relaciones varios a varios entre cliente y cuenta, indicando que un
cliente posee una cuenta.
• banquero-consejero, con el atributo de relación tipo, un conjunto de
relaciones varios a uno que expresa que un cliente puede ser
aconsejado por un empleado del banco, y que un empleado del banco
puede aconsejar a uno o más clientes. Nótese que este conjunto de
relaciones ha reemplazado al atributo nombre-banquero del conjunto
de entidades cliente.
• Trabaja-para, un conjunto de relaciones entre entidades empleado con
papeles que indican jefe y trabajador; la correspondencia de
cardinalidades expresa que un empleado trabaja para un único jefe, y
que un jefe supervisa uno o más empleados. Nótese que este
conjunto de relaciones reemplaza al atributo jefe de empleado.

♦ Diagrama E-R

Conforme a lo discutido en los apartados anteriores se presenta ahora el

diagrama E-R completo para el ejemplo del banco. El la figura 20 se muestra
la representación completa de un modelo conceptual de un banco,
expresada en términos de los conceptos E-R. el diagrama incluye los
conjuntos de entidades, atributos, conjuntos de relaciones y correspondencia
de cardinalidades alcanzados a través del proceso de diseño los apartado
anteriores.

“Fundamentos de bases de datos SCM-0412”

- 49 -
 Figura 2.20.- Diagrama entidad – relación para un banco

2.5. Lenguaje de Modelado Unificado (UML)

Los diagramas entidad-relación ayudan a modelar el componente de

representación de datos de un sistema software. La representación de datos,
sin embargo, sólo forma parte de un diseño completo de un sistema. Otros
componentes son modelos de interacción del usuario con el sistema,

“Fundamentos de bases de datos SCM-0412”

- 50 -
especificación de módulos funcionales del sistema y su interacción, etc. El
lenguaje de modelado unificado (UML, Unified Modeling Languaje) es un
estándar propuesto para la creación de especificaciones de varios
componentes de un sistema de software. Algunas de las partes de UML son:

• Diagrama de clases: Un diagrama de clases es similar a un diagrama

E-R.
• Diagrama de implementación: Los diagramas de implementación
muestran los componentes del sistema y sus interconexiones tanto en
el nivel del componente de software como el hardware.

En a tabla 2.2 se muestran varios constructores de diagramas E-R y sus

constructores equivalentes de los diagramas de clase UML. UML muestra los
conjuntos de entidades como cuadros y, a diferencia de E-R, muestra los
atributos dentro del cuadro en lugar de cómo elipses separadas. UML modela
realmente objetos, mientras que E-R modela entidades. Los objetos son
como entidades, y tienen atributos, pero además proporcionan un conjunto
de funciones (denominadas métodos) que se pueden invocar para calcular
valores en términos de los atributos de los objetos, o para modificar el propio
objeto. Los diagramas de clase pueden describir métodos además de
atributos.

Los conjuntos de relaciones binarias se representan en UML

dibujando simplemente una línea que conecte los conjuntos de entidades. Se
escribe el nombre del conjunto de relaciones adyacente a la línea. También
se pueden especificar el papel que juega un conjunto de entidades en un
conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto
con los atributos del conjunto de relaciones, y conectar el cuadro con una
línea discontinua a la línea que describe el conjunto de relaciones. Este
cuadro se puede tratar entonces como un conjunto de entidades, de la
misma forma que una agregación en los diagramas E-R puede participar en

“Fundamentos de bases de datos SCM-0412”

- 51 -
relaciones con otros conjuntos de entidades. Las relaciones no binarias se
pueden representar directamente en UML.

Las restricciones de cardinalidad se especifican en UML de la misma

forma que en los diagramas E-R, de la forma i…s, donde i denota el mínimo
y s el máximo número de relaciones en que se puede participar una entidad.
Sin embargo, se debería ser conciente que la ubicación de las restricciones
es exactamente el inverso de la ubicación de las restricciones en los
diagramas E-R, como se muestra en la figura 24. La restricción 0…* en el
lado E2 y 0…1 en el lado E1 significa que cada entidad E2 puede participar a
lo sumo en una relación, mientras que casa entidad E1 puede participar en
varias relaciones; en otras palabras, la relación es varias a uno de E2 a E1.

Los valores como 1 o * se pueden escribir en los arcos; el valor 1

sobre un arco se trata equivalentemente como 1…1, mientras que * es
equivalente a 0…*.

La generalización y la especificación se representan en el diagrama E-

R conectando conjunto de entidades por una línea con un triángulo al final
correspondiente al conjunto de entidades más general. Por ejemplo, el
conjunto de entidades personar es una generalización de cliente y empleado.
Los diagramas UML también pueden representar explícitamente las
restricciones de generalización disjuntas y solapadas. En la figura 24 se
muestra las generalizaciones disjuntas y solapadas de cliente y empleado a
persona. Se debe recordar que la generalización de cliente / empleado a
persona es disjunta, y significa que ninguna entidad puede ser ala vez un
cliente y un empleado. Una generalización solapada permite que una
persona sea tanto cliente como empleado.

“Fundamentos de bases de datos SCM-0412”

- 52 -
 Cuadro 2.2.- Símbolos usados en la notación de diagrama de clases UML.
Nombre Diagrama E-R Diagrama de clases en
UML
Conjunto de
entidades y
atributos.

Relaciones

Restricciones de
cardinalidad

Generalización y
especialización

“Fundamentos de bases de datos SCM-0412”

- 53 -