BD03_Contenidos

1 de 52

[Link]

Interpretacin de diagramas entidad/relacin.

Caso prctico
Ada est analizando la manera en la que Juan y Mara han comenzando
a construir la base de datos que sustentar el sitio web de juegos online.
Parece que la aplicacin del modelo relacional est marchando
correctamente, aunque le interesa que el proceso se realice siguiendo un
mtodo lo ms estandarizado posible y que les ofrezca independencia
del SGBD que escojan.
De este modo, podrn planificar el desarrollo de cada una de las fases y
ajustar mejor los tiempos dedicados a cada una de ellas.

Como se ha descrito en unidades anteriores, un modelo de datos es una coleccin de herramientas

conceptuales que permiten llevar a cabo la descripcin de los datos, sus relaciones, su semntica o
significado y las restricciones que se les pueden aplicar. Sabemos que los SGBD cuentan con una
arquitectura que simplifica, a los diferentes usuarios de la base de datos, su labor. El objetivo fundamental
de esta arquitectura es separar los programas de aplicacin de la base de datos fsica, proponiendo tres
niveles de abstraccin: nivel interno o fsico, nivel lgico o conceptual y nivel externo o de visin del
usuario.

30/06/2013 14:53

BD03_Contenidos

2 de 52

[Link]

1. Anlisis y diseo de bases de datos.

El Nivel lgico o conceptual describe la estructura completa de la base de
datos a travs de lo que llamamos Esquema Conceptual, que se encarga de
representar la informacin de una manera totalmente independiente del
Sistema Gestor de Base de Datos.
Cuando hemos de desarrollar una base de datos se distinguen claramente dos
fases de trabajo: Anlisis y Diseo. En la siguiente tabla te describimos las
etapas que forman parte de cada fase.

Pasos de las fases de Anlisis y de Dsiseo

Fase de Anlisis

Fase de Diseo

Anlisis de entidades: Se trata de

localizar y definir las entidades y sus
atributos.

Diseo de tablas.

Anlisis de relaciones: Se definirn

las relaciones existentes entre
entidades.

Normalizacin.

Obtencin del Esquema Conceptual

a travs del modelo E-R.

Aplicacin de
fuese necesario.

Fusin de vistas: Se renen en un

nico esquema todos los esquemas
existentes en funcin de las
diferentes vistas de cada perfil de
usuario.

Diseo
de
transacciones:
localizacin
del
conjunto
de
operaciones o transacciones que
operarn
sobre
el
esquema
conceptual.

Aplicacin del enfoque de datos

relacional.

Diseo de sendas de acceso: se

formalizan los mtodos de acceso
dentro de la estructura de datos.

retrodiseo,

si

Llevando a cabo una correcta fase de anlisis estaremos dando un paso determinante en el desarrollo de
nuestras bases de datos. El hecho de saltarse el esquema conceptual conlleva un problema de prdida de
informacin 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 realizacin de esquemas que ofrezcan una visin global de los datos, Peter Chen en 1976 y 1977
presenta dos artculos en los que se describe el modelo Entidad/Relacin (entity/relationship). Con el paso
del tiempo, este modelo ha sufrido modificaciones y mejoras. Actualmente, el modelo entidad/relacin
extendido (ERE) es el ms aceptado, aunque existen variaciones que hacen que este modelo no sea
totalmente un estndar. Ambos modelos sern estudiados a lo largo de esta unidad.

30/06/2013 14:53

BD03_Contenidos

3 de 52

[Link]

2.- Qu es el Modelo E/R?

Caso prctico
Mara, Si un carpintero recibe un encargo de un mueble, en qu
crees que se basa para fabricarlo? Pregunta Ada.
Levantando la vista de la pantalla de su ordenador, Mara contesta:
Supongo que un esquema o croquis, a veces hay detalles que es
necesario consultar en la documentacin, porque todo no es posible
memorizarlo.
Juan interviene: Me temo que ya s por dnde van los tiros, Ada.
Con esa pregunta te ests refiriendo a los esquemas grficos que se
deben crear para la construccin de bases de datos?
Ada sonre y hace un gesto para que ambos se acerquen: Sabis lo
qu es el modelo Entidad Relacin?

Es una herramienta de referencia para la representacin

conceptual de problemas del mundo real. Su objetivo principal,
facilitar el diseo de bases de datos permitiendo la especificacin
de un esquema que representa la estructura lgica 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 ms fiel posible al comportamiento del
mundo real para modelarlo.
El modelo de datos E-R representa el significado de los datos, es un modelo semntico. De ah que no est
orientado a ningn sistema fsico concreto y tampoco tiene un mbito informtico puro de aplicacin, ya que
podra utilizarse para describir procesos de produccin, estructuras de empresa, etc. Adems, las
caractersticas actuales de este modelo favorecen la representacin de cualquier tipo de sistema y a
cualquier nivel de abstraccin o refinamiento, lo cual da lugar a que se aplique tanto a la representacin de
problemas que vayan a ser tratados mediante un sistema informatizado, como manual.
Gracias al modelo Entidad-Relacin, creado por Peter Chen en los aos setenta, se puede representar el
mundo real mediante una serie de smbolos y expresiones determinados. El modelo de datos
Entidad/Relacin (E/R E-R) est basado en una percepcin consistente en objetos bsicos llamados
entidades y relaciones entre estos objetos, estos y otros conceptos se desarrollan a continuacin.

Autoevaluacin
La informacin con la que el modelo Entidad-Relacin trabaja ha de ser lo ms detallada y
fiel posible a la realidad del problema a representar.
Verdadero.

Falso.

Correcto. Debe ser as, si no estaramos representando parcialmente la realidad a modelar

y la funcionalidad de nuestra base de datos se vera comprometida.

30/06/2013 14:53

BD03_Contenidos

4 de 52

[Link]

3.- Entidades.

Caso prctico
Cada una de las tablas que hemos estado generando
equivale a una entidad en el modelo E/R? Pregunta Juan.
Algunas de ellas corresponden a entidades y otras a
relaciones, depende del problema a resolver. Por ejemplo, la
tabla USUARIO s se correspondera con una entidad.
Adems, hay que tener cuidado a la hora de identificar
entidades porque algunas veces podemos confundir entidades
con atributos y viceversa responde Ada.
Para los miembros de BK Programacin va a ser necesario que conozcan bien cmo se aplica
este modelo si quieren que el proceso de creacin de bases de datos sea correcto.

Si utilizamos las bases de datos para guardar informacin sobre cosas que nos interesan o que interesan a
una organizacin, No crees que hay que identificar esas cosas primero para poder guardar informacin
sobre ellas? Para ello, vamos a describir un primer concepto, el de Entidad.
Una entidad puede ser un objeto fsico, un concepto o cualquier elemento que queramos modelar, que
tenga importancia para la organizacin y del que se desee guardar informacin. Cada entidad debe poseer
alguna caracterstica, 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 caractersticas. El alumnado
podra ser distinguido mediante su nmero de identificacin escolar (NIE), por ejemplo.
Entidad: objeto real o abstracto, con caractersticas 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 montaa, los elementos: camping, pista forestal, valle, ro, 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 organizacin o sistema que vaya a utilizar
dicha base de datos. Pero no siempre una entidad puede ser concreta, como un camping o un ro, en
ocasiones puede ser abstracta, como un prstamo, una reserva en un hotel o un concepto.
Un conjunto de entidades sern un grupo de entidades que poseen las mismas caractersticas o
propiedades. Por ejemplo, al conjunto de personas que realizan reservas para un hotel de montaa
determinado, se les puede definir como el conjunto de entidades cliente. El conjunto de entidades ro,
representar todos los ros existentes en una determinada zona. Por lo general, se suele utilizar el trmino
entidad para identificar conjuntos de entidades. Cada elemento del conjunto de entidades ser una
ocurrencia de entidad.
Si establecemos un smil con la Programacin Orientada a Objetos, podemos decir que el concepto de
entidad es anlogo al de instancia de objeto y que el concepto de conjunto de entidades lo es al de
clase.
En el modelo Entidad/Relacin, la representacin grfica de las entidades se realiza mediante el nombre de
la entidad encerrado dentro de un rectngulo. A continuacin se muestra la representacin de la entidad
CLIENTE.

30/06/2013 14:53

BD03_Contenidos

5 de 52

[Link]

30/06/2013 14:53

BD03_Contenidos

6 de 52

[Link]

3.1.- Tipos: fuertes y dbiles.

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 rectngulo.
b. Entidades dbiles:
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 numeracin pero en edificios
diferentes. La numeracin de cada aula no identificar completamente cada una de ellas. Para poder
identificar completamente un aula es necesario saber tambin en qu edificio est localizada. Por
tanto, la existencia de una instancia de una entidad dbil depende de la existencia de una instancia
de la entidad fuerte con la que se relaciona.
Entidad Dbil: Es un tipo de entidad cuyas propiedades o atributos no la identifican
completamente, sino que slo la identifican de forma parcial. Esta entidad debe participar en una
relacin que ayude a identificarla.
En el modelo E/R una entidad dbil se representa con el nombre de la entidad encerrado en un rectngulo
doble. En el grfico se muestra la representacin de la entidad AULA.
Las entidades dbiles presentan dos tipos de dependencia:
Dependencia en existencia: entre entidades, si desaparece una instancia de entidad fuerte
desaparecern las instancias de entidad dbiles que dependan de la primera. La representacin de
este tipo de dependencia incluir una E en el interior de la relacin dbil.
Dependencia en identificacin: debe darse una dependencia en existencia y adems, una
ocurrencia de la entidad dbil no puede identificarse por s misma, debiendo hacerse mediante la
clave de la entidad fuerte asociada. La representacin de este tipo de dependencia incluir una ID en
el interior de la relacin dbil.

Recomendacin
Tanto las entidades fuertes como las dbiles se nombran habitualmente con sustantivos
en singular.
Puede ser que haya algunos conceptos que an no hemos desarrollado (relacin, atributo
y clave) y que se estn utilizando para describir los tipos de dependencias, no te
preocupes, en los siguientes epgrafes te los describimos claramente.

30/06/2013 14:53

BD03_Contenidos

7 de 52

[Link]

Autoevaluacin
Identifica cul de las siguientes entidades no podra ser considerada como entidad dbil:
PROVEEDOR (perteneciente a una base de datos de gestin de stocks).
PAGO (perteneciente a una base de datos bancaria).
FAMILIAR (perteneciente a una base de datos hospitalaria).
Efectivamente, esta entidad puede existir por s misma sin depender de otras ocurrencias de
entidad. Adems, posee propiedades o atributos propios que la identifican frente a otras
ocurrencias de la misma entidad.

30/06/2013 14:53

BD03_Contenidos

8 de 52

[Link]

4.- Atributos.

Caso prctico
Juan muestra a Mara qu atributos han creado para la tabla
JUEGOS, pero al aplicar el modelo Entidad-Relacin se ha dado

cuenta de que le falta algn atributo ms.

Mara esta dibujando la entidad JUEGOS y sus atributos asociados.
Ahora va a aadir grficamente un atributo que recoja la productora
de software asociada a cada juego.

Cmo guardamos informacin de cada entidad? A travs de sus atributos. Las entidades se representan
mediante un conjunto de atributos. stos describen caractersticas 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 informacin parecida para cada ocurrencia de entidad. Pero,
cada ocurrencia de entidad tendr su propio valor para cada atributo.
Atributo: Cada una de las propiedades o caractersticas que tiene un tipo de entidad o un tipo de
relacin se denomina atributo; los atributos toman valores de uno o varios dominios.
Por tanto, un atributo se utilizar para guardar informacin sobre
alguna caracterstica o propiedad de una entidad o relacin.
Ejemplos de atributos pueden ser: altura, color, peso, DNI,
fecha, etc. todo depender de la informacin que sea necesaria
almacenar.
En el modelo Entidad/Relacin 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 lnea
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 minscula. En el grfico se representan algunos de los atributos para la
entidad PACIENTE.
Al conjunto de valores permitidos para un atributo se le denomina dominio. Todos los posibles valores que
puede tomar un atributo debern 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, estn definidos dentro del dominio de cadenas de caracteres de una determinada longitud.
Aunque los dominios suelen ser amplios (nmeros enteros, reales, cadenas de caracteres, etc.), a la hora
de llevar a cabo el desarrollo de una base de datos, es mejor establecer unos lmites 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.

30/06/2013 14:53

BD03_Contenidos

9 de 52

[Link]

4.1.- Tipos de atributos.

Todos los atributos son iguales? Claro que no. Existen varias
caractersticas que hacen que los atributos asociados a una
entidad o relacin sean diferentes, los clasificaremos segn varios
criterios.
a. Atributos obligatorios y opcionales. Atributo obligatorio:
es aqul que ha de estar siempre definido para una entidad
o relacin. Por ejemplo, para la entidad JUGADOR ser
necesario tener algn atributo que identifique cada ocurrencia de entidad, podra ser su DNI. Una
clave o llave es un atributo obligatorio. Atributo opcional: es aqul que podra ser definido o no para
la entidad. Es decir, puede haber ocurrencias de entidad para las que ese atributo no est definido o
no tenga valor.
b. Atmicos o compuestos.
Atributo simple o atmico: es un atributo que no puede dividirse en otras partes o atributos,
presenta un nico elemento. No es posible extraer de este atributo partes ms pequeas que puedan
tener significado. Un ejemplo de este tipo de atributos podra ser el atributo dni de la entidad
JUGADOR del grfico.
Atributo compuesto: son atributos que pueden ser divididos en subpartes, stas constituirn otros
atributos con significado propio. Por ejemplo, la direccin del jugador podra considerarse como un
atributo compuesto por la calle, el nmero y la localidad.
c. Atributos monovaluados o multivaluados.
Atributo monovaluado: es aqul que tiene un nico valor
para cada ocurrencia de entidad. Un ejemplo de este tipo de
atributos es el dni.
Atributo multivaluado: es aqul que puede tomar diferentes
valores para cada ocurrencia de entidad. Por ejemplo, la
direccin de e-mail de un empleado podra tomar varios
valores para alguien que posea varias cuentas de correo. En este tipo de atributos hay que tener en
cuenta los siguientes conceptos:
La cardinalidad de un atributo indica el nmero mnimo y el nmero mximo de valores que
puede tomar para cada ejemplar de la entidad o relacin a la que pertenece.
La cardinalidad mnima indica la cantidad de valores del atributo que debe existir para que la
entidad sea vlida. Este nmero casi siempre es 0 o 1. Si es 0, el atributo podra no contener
ningn valor y si es 1, el atributo debe tener un valor.
La cardinalidad mxima indica la cantidad mxima de valores del atributo que puede tener la
entidad. Por lo general es 1 o n. Si es 1, el atributo no puede tener ms que un valor, si es n,
el atributo puede tener mltiples valores y no se especifica la cantidad absoluta.
El atributo E_mail de la figura, puede ser opcional y no contener ningn valor, o bien, almacenar
varias cuentas de correo electrnico de un jugador. Como ves, la cardinalidad representada en la
imagen es (0,n).
d. Atributos derivados o almacenados: el valor de este tipo de atributos puede ser obtenido del valor
o valores de otros atributos relacionados. Un ejemplo clsico de atributo derivado es la edad. Si se
ha almacenado en algn atributo la fecha de nacimiento, la edad es un valor calculable a partir de
dicha fecha.

Autoevaluacin
Rellena los huecos en blanco con los conceptos adecuados.
Si en nuestra base de datos tenemos una entidad USUARIO, los atributos password y login
debern ser atributos
obligatorios
ya que son imprescindibles para iniciar o jugar
partidas. En cambio, un posible atributo ranking que indique en qu posicin se encuentra el
usuario entre todos los jugadores, podra considerarse un atributo

derivado

si tenemos

30/06/2013 14:53

BD03_Contenidos

10 de 52

[Link]

en cuenta la puntuacin obtenida por cada usuario.

Reiniciar

Mostrar las respuestas

Tu puntuacin es 0/2.
Los atributos password y login deben ser obligatorios para que los usuarios puedan iniciar
sesin y jugar partidas. Por otra parte, el atributo ranking puede considerarse derivado, ya
que su valor puede obtenerse de las puntuaciones almacenadas para cada usuario.

30/06/2013 14:53

BD03_Contenidos

11 de 52

[Link]

4.2.- Claves.
En el apartado anterior hablbamos de un tipo de atributo especial obligatorio,
las claves o llaves. Ahora es el momento de abordar con mayor detalle este
concepto.
Est claro que es necesario identificar correctamente cada ocurrencia de
entidad o relacin, de este modo el tratamiento de la informacin que se
almacena podr realizarse adecuadamente. Esta distincin podra llevarse a
cabo tomando todos los valores de todos los atributos de una entidad o
relacin. 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 idnticos valores para varias entidades, por lo que
cualquier subconjunto no ser vlido.
Por tanto, los valores de los atributos de una entidad deben ser tales que permitan identificar
unvocamente a la entidad. En otras palabras, no se permite que ningn par de entidades tengan
exactamente los mismos valores de sus atributos. Teniendo en cuenta esto, presta atencin a los siguientes
conceptos:

Superclave (Superllave): Es cualquier conjunto de atributos que permite identificar de forma

nica a una ocurrencia de entidad. Una superclave puede tener atributos no obligatorios, es
decir, que no identificaran por si solos una ocurrencia de entidad.
Clave candidata: Si de una superclave no es posible obtener ningn subconjunto que sea a su
vez superclave, decimos que dicha superclave es clave candidata.
Clave primaria (Primary Key): Tambin llamada llave primaria o clave principal. De todas las
claves candidatas, el diseador de la base de datos ha de escoger una, que se denominar clave
principal o clave primaria. La clave primaria es un atributo o conjunto de ellos, que toman valores
unvocamente. No puede
nicos y distintos para cada ocurrencia de entidad, identificndola
contener valores nulos.
Claves alternativas: son el resto de claves candidatas que no han sido escogidas como clave
primaria.

La representacin en el modelo Entidad/Relacin de las claves primarias puede realizarse de dos formas:
Si se utilizan elipses para representar los atributos, se subrayarn aquellos que formen la clave
primaria.
Si se utilizan crculos para representar los atributos, se utilizar un crculo negro en aquellos que
formen la clave primaria.

Autoevaluacin
Sea la entidad TRABAJADOR, con los atributos nombre, apellido_1, apellido_2, dni,
numero_afiliacion_ss , fecha_nacimiento y cdigo_empresa . Los atributos nombre, apellido_1

30/06/2013 14:53

BD03_Contenidos

12 de 52

[Link]

y apellido_2 podran formar una clave candidata?

S, y podran ser elegidos para ser la clave primaria de TRABAJADOR.
No, para esta entidad slo el atributo dni ser la clave primaria.
No, si tenemos en cuenta que puede haber varios trabajadores con el mismo nombre y
apellidos.
Efectivamente, los atributos dni y numero_afiliacion_ss, seran dos claves candidatas
adecuadas. Si escogemos dni como clave primaria, numero_afiliacion_ss quedara como
clave alternativa.

30/06/2013 14:53

BD03_Contenidos

13 de 52

[Link]

4.3.- Atributos de una relacin.

Una relacin puede tambin tener atributos que la describan. Para
ilustrar esta situacin, observa el siguiente ejemplo.
Consideremos la relacin CURSA entre las entidades ALUMNO y
ASIGNATURA. Podramos asociar a la relacin CURSA un atributo nota
para especificar la nota que ha obtenido un alumno/a en una
determinada asignatura.
Otro ejemplo tpico son las relaciones que representan histricos. 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 accin. Para ello, habr que crear un
atributo asociado a la relacin entre la entidad CLIENTE y FACTURA que se encargue de guardar la fecha de
emisin.
En el modelo Entidad/Relacin la representacin de atributos asociados a relaciones es exactamente igual
a la que utilizbamos para entidades. Podremos utilizar una elipse con el nombre del atributo en su interior,
conectada con una lnea a la relacin, o bien, un crculo blanco conectado con una lnea a la relacin y
junto a l, el nombre del atributo. En el grfico puedes ver esta segunda representacin.

30/06/2013 14:53

BD03_Contenidos

14 de 52

[Link]

5.- Relaciones.

Caso prctico
Mara ha identificado claramente las entidades y atributos que van a
intervenir en su esquema, pero duda a la hora de representar cmo se
van a relacionar dichas entidades.
Ada le indica que es muy importante leer muy bien el documento de
especificacin de requerimientos del caso real a modelar, ya que de ste
se desprendern las particularidades de las relaciones entre las
entidades que acaba de identificar.
Representar una relacin grficamente en el modelo E/R es sencillo,
pero lo interesante es dotar a esa representacin de los elementos
grficos adecuados que reflejen fielmente cmo es en realidad: grado,
cardinalidad, [Link] Ada.

Cmo interactan entre s las entidades? A travs de las relaciones. La relacin o interrelacin es un
elemento del modelo Entidad/Relacin que permite relacionar datos entre s. En una relacin se asocia un
elemento de una entidad con otro de otra entidad.
Relacin: es una asociacin entre diferentes entidades. En una relacin no pueden aparecer dos
veces relacionadas las mismas ocurrencias de entidad.
La representacin grfica en el modelo Entidad/Relacin
corresponde a un rombo en cuyo interior se encuentra inscrito el
nombre de la relacin. El rombo estar conectado con las entidades
a las que relaciona, mediante lneas rectas, que podrn o no acabar
en punta de flecha segn el tipo de relacin.

Recomendacin
Cuando debas dar un nombre a una relacin procura que ste haga referencia al objetivo o
motivo de la asociacin de entidades. Se suelen utilizar verbos en singular. Algunos ejemplos
podran ser: forman, poseen, atiende, contrata, hospeda, supervisa, imparte, etc.

En algunas ocasiones, es interesante que en las lneas que conectan las entidades con la relacin, se
indique el papel o rol que desempea cada entidad en la relacin. Como se ver ms 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 relacin.
Cardinalidad de la relacin.
Cardinalidades de las entidades.
A continuacin desarrollamos cada uno de ellos.

30/06/2013 14:53

BD03_Contenidos

15 de 52

[Link]

5.1.- Grado de una relacin.

Pueden intervenir varias entidades en una misma relacin? Claro que s, en una relacin puede intervenir
una nica entidad o varias.
Grado de una relacin: nmero de entidades que participan en una relacin.
En funcin del grado se pueden establecer diferentes tipos de
relaciones:
Relacin Unaria o de grado 1: Es aquella relacin en la
que participa una nica entidad. Tambin llamadas
reflexivas o recursivas.
Relacin Binaria o de grado 2: Es aquella relacin en la
que participan dos entidades. En general, tanto en una
primera
aproximacin,
como
en
los
sucesivos
refinamientos, el esquema conceptual de la base de datos
buscar tener slo este tipo de relaciones.
Relacin Ternaria o de grado 3: Es aquella relacin en la que participan tres entidades al mismo
tiempo.
Relacin N-aria o de grado n: Es aquella relacin que involucra n entidades. Este tipo de relaciones
no son usuales y deben ser simplificadas hacia relaciones de menor grado.
Relacin doble: ocurre cuando dos entidades estn relacionadas a travs de dos relaciones. Este
tipo de relaciones son complejas de manejar.
En este grfico puedes observar cada uno de los tipos de relaciones en funcin de su grado y su
representacin grfica en el modelo Entidad/Relacin.

Autoevaluacin
Rellena los huecos con los conceptos adecuados.
En la relacin unaria que puedes ver en el grfico anterior, un empleado puede ejercer el rol de

jefe
Reiniciar

o el rol de

subordinado

Mostrar las respuestas

Tu puntuacin es 0/2.
Al ser una relacin reflexiva que relaciona una entidad consigo misma, un empleado puede
ejercer el rol de jefe sobre uno o varios empleados y, a su vez, podra ejercer el rol de
subordinado bajo las ordenes de un jefe.

30/06/2013 14:53

BD03_Contenidos

16 de 52

[Link]

5.2.- Cardinalidad de relaciones.

Qu es eso de la cardinalidad? En matemticas, el cardinal de un conjunto es el nmero de elementos que
lo forman. Este concepto puede extrapolarse a las relaciones con las que estamos tratando.
Cardinalidad de una relacin: Es el nmero mximo de ocurrencias de cada entidad que
pueden intervenir en una ocurrencia de relacin. La cardinalidad vendr expresada siempre para
relaciones entre dos entidades. Dependiendo del nmero 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 nmero de

ocurrencias de la entidad JUGADOR que se relacionan con cada
ocurrencia de la entidad EQUIPO y viceversa. Podramos hacer la
siguiente lectura: un jugador pertenece a un equipo y a un equipo
pueden pertenecer varios jugadores.
Una posible representacin de la cardinalidad de las relaciones es la que hemos visto en el ejemplo
anterior. Podramos representar el resto de cardinalidades mediante las etiquetas 1:1, 1:N, N:1, M:N que se
leeran 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 slo 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 slo
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 slo 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 slo habr una ocurrencia relacionada de la entidad DOCENTE (si se
establece que una asignatura slo puede ser impartida por un nico docente). O lo que es lo mismo,
un docente puede impartir varias asignaturas y una asignatura slo 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/Relacin. A continuacin, te ofrecemos un resumen de las notaciones clasificadas por autores, ms
empleadas en la representacin de cardinalidad de relaciones.

Notaciones para representacin de cardinalidad de relaciones.

Relaciones uno a uno.

Relaciones uno a muchos.

Relaciones muchos a muchos.

30/06/2013 14:53

BD03_Contenidos

17 de 52

[Link]

30/06/2013 14:53

BD03_Contenidos

18 de 52

[Link]

5.3.- Cardinalidad de entidades.

Si existe cardinalidad en las relaciones, supondrs que tambin
existe para las entidades. Ests en lo cierto, la cardinalidad con
la que una entidad participa en una relacin especifica el nmero
mnimo y el nmero mximo de correspondencias en las que
puede tomar parte cada ejemplar de dicha entidad. Indica el
nmero de relaciones en las que una entidad puede aparecer.
Sean las entidades A y B, la participacin de la entidad A en una relacin es obligatoria (total) si la
existencia de cada una de sus ocurrencias necesita como mnimo de una ocurrencia de la entidad B (ver
figura). En caso contrario, la participacin es opcional (parcial).
La cardinalidad de una entidad se representa con el nmero mnimo y mximo de correspondencias en las
que puede tomar parte cada ejemplar de dicha entidad, entre parntesis. Su representacin grfica ser,
por tanto, una etiqueta del tipo (0,1), (1,1), (0,N) o (1,N). El significado del primer y segundo elemento del
parntesis corresponde a (cadinalidad mnima, cardinalidad mxima):
Cardinalidad mnima. Indica el nmero mnimo 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
mnima de ms de uno, se indica slo un uno). El valor 0 se pondr cuando la participacin de la
entidad sea opcional.
Cardinalidad mxima. Indica el nmero mximo 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).
Vemoslo ms claro a travs del siguiente ejemplo: un JUGADOR
pertenece como mnimo a ningn EQUIPO y como mximo a uno
(0,1) y, por otra parte, a un EQUIPO pertenece como mnimo un
JUGADOR y como mximo 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 ningn equipo o como mximo 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 mnimo un
jugador y mximo varios.
Ten en cuenta que cuando se representa la cardinalidad de una entidad, el parntesis y sus
valores han de colocarse junto a la entidad con la que se relaciona. Es decir en el lado opuesto a
la relacin.
La cardinalidad de entidades tambin puede representarse en el modelo Entidad/Relacin con la notacin
que se representa en la imagen de la derecha. Por tanto, el anterior ejemplo quedara representado as:

Autoevaluacin
Supongamos que seguimos diseando una base de datos para un sitio de juegos online.
En un punto del proceso de diseo 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

30/06/2013 14:53

BD03_Contenidos

19 de 52

[Link]

crear partidas. Cules seran las etiquetas del tipo (cardinalidad mnima, cardinalidad
mxima) que deberan ponerse junto a las entidades USUARIO y PARTIDA respectivamente, si
stas estn asociadas por la relacin CREAR (partida)?
(1,N) y (0,N)
(1,1) y (1,N)
(1,1) y (0,N)
Efectivamente, con estas cardinalidades estaras indicando que un usuario puede crear
varias partidas, o ninguna. Por otra parte, una partida deber estar creada exclusivamente
por un nico usuario.

30/06/2013 14:53

BD03_Contenidos

20 de 52

[Link]

6.- Simbologa del modelo E/R.

Caso prctico
Mara acaba de venir de comprar un tabln de anuncios de
corcho. Va a colgarlo cerca su puesto de trabajo, junto al de
Juan.
Mira Juan, voy a imprimir estos grficos en los que figuran
los smbolos ms utilizados a la hora de generar diagramas
E/R. Sabas que existen diferentes notaciones? pregunta
Mara.
Juan, que est buscando en su cajn la caja de las
chinchetas, aade: Me parece una idea genial y s, s que
conoca la existencia de diferentes smbolos. Adems, mientras buscaba en Internet algunos
ejemplos, he visto que se pueden representar de diferentes maneras los mismos elementos.
Estupendo, as tendris a mano la gran mayora de smbolos y os ser ms cmodo interpretar
los ejemplos que consultis comenta Ada.

Recuerdas todos y cada uno de los smbolos que hemos utilizado a lo largo de esta unidad? Es probable
que no. Para facilitar tu aprendizaje, te ofrecemos a continuacin un resumen bsico de los smbolos
utilizados en el modelo Entidad/Relacin. Vers que existen diferentes maneras de representar los
mismos elementos, las que aqu se resumen te servirn para interpretar la gran mayora de esquemas con
los que te puedas encontrar.

Resumen bsico de la simbologa del modelo Entidad/Relacin.

Resumen bsico de la simbologa del modelo Entidad/Relacin

Para saber ms
Si quieres ver un ejemplo de cmo se aplican algunas de estas notaciones en un esquema
conceptual de una base de datos, chale un vistazo al siguiente ejemplo:
Un ejemplo de esquema conceptual.

(0.02 MB)

30/06/2013 14:53

BD03_Contenidos

21 de 52

[Link]

7.- El modelo E/R Extendido.

Caso prctico
Cuando la representacin de determinadas entidades y relaciones se
complique, los miembros de BK Programacin necesitarn aplicar
alguna tcnica adicional que les permita realizar un modelado adecuado
del problema. Ada, est preparando una presentacin en soporte
informtico con la que ensear a Juan y Mara las nuevas
posibilidades que les brinda el modelo Entidad-Relacin Extendido.

Hemos visto que a travs del modelo Entidad/Relacin se pueden modelar la gran mayora de los requisitos
que una base de datos debe cumplir. Pero existen algunos que ofrecen especial dificultad a la hora de
representarlos a travs de la simbologa tradicional del modelo E/R. Para solucionar este problema, en el
modelo Entidad/Relacin Extendido se han incorporado nuevas extensiones que permiten mejorar la
capacidad para representar circunstancias especiales. Estas extensiones intentan eliminar elementos de
difcil o incompleta representacin a travs de la simbologa existente, como por ejemplo relaciones con
cardinalidad N:M, o la no identificacin clara de entidades.
A continuacin, se detallan estas nuevas caractersticas que convierten al modelo E/R tradicional en el
modelo Entidad/Relacin Extendido, como son: tipos de restricciones sobre las relaciones,
especializacin, generalizacin, conjuntos de entidades de nivel ms alto y ms bajo, herencia de atributos
y agregacin.

30/06/2013 14:53

BD03_Contenidos

22 de 52

[Link]

7.1.- Restricciones en las relaciones.

La primera extensin que el modelo Entidad/Relacin Extendido incluye,
se centra en la representacin de una serie de restricciones sobre las
relaciones y sus ejemplares, vamos a describirlas:
a. Restriccin de exclusividad.
Cuando existe una entidad que participa en dos o ms
relaciones y cada ocurrencia de dicha entidad slo puede
pertenecer a una de las relaciones nicamente, decimos que
existe una restriccin de exclusividad. Si la ocurrencia de entidad
pertenece a una de las relaciones, no podr formar parte de la
otra. O se produce una relacin o se produce otra pero nunca
ambas a la vez.
Por ejemplo, supongamos que un msico puede dirigir una orquesta o tocar en en ella, pero no
puede hacer las dos cosas simultneamente. Existirn por tanto, dos relaciones dirige y toca,
entre las entidades MUSICO y ORQUESTA, establecindose una relacin de exclusividad entre ellas.
La representacin grfica en el modelo Entidad/Relacin Extendido de una restriccin de
exclusividad se realiza mediante un arco que engloba a todas aquellas relaciones que son
exclusivas.
b. Restriccin de exclusin.
Este tipo de restriccin se produce cuando las ocurrencias de las entidades slo pueden
asociarse utilizando una nica relacin.
Pongamos un ejemplo, supongamos que un monitor puede impartir diferentes cursos de
perfeccionamiento para monitores, y que ste puede a su vez recibirlos. Pero si un monitor imparte
un determinado curso, no podr estar recibindolo simultneamente y viceversa. Se establecer, por
tanto, una restriccin de exclusin que se representa mediante una lnea discontinua entre las dos
relaciones, tal y como se muestra en el ejemplo.
c. Restriccin de inclusividad.
Este tipo de restricciones se aplican cuando es necesario modelar situaciones en las que para que
dos ocurrencias de entidad se asocien a travs de una relacin, tengan que haberlo estado
antes a travs de otra relacin.
Siguiendo con el ejemplo anterior, supongamos que para que un monitor pueda impartir cursos de
cocina sea necesario que reciba previamente dos cursos: nutricin y primeros auxilios. Como puedes
ver, es posible que los cursos que el monitor deba recibir no tengan que ser los mismos que luego
pueda impartir. Aplicando una restriccin de inclusividad entre las relaciones imparte y recibe,
estaremos indicando que cualquier ocurrencia de la entidad MONITOR que participa en una de las
relaciones (imparte) tiene que participar obligatoriamente en la otra (recibe).
Se representar mediante un arco acabado en flecha, que partir desde la relacin que ha de
cumplirse primero hacia la otra relacin. Se indicar junto al arco la cardinalidad mnima y mxima de
dicha restriccin de inclusividad. En el ejemplo, (2,n) indica que un monitor ha de recibir 2 cursos
antes de poder impartir varios.
d. Restriccin de inclusin.
En algunas ocasiones aplicar una restriccin de inclusividad no representa totalmente la realidad a
modelar, entonces se hace necesario aplicar una restriccin de inclusin que es an ms fuerte.
En nuestro ejemplo, si hemos de modelar que un monitor pueda impartir un curso, si previamente lo
ha recibido, entonces tendremos que aplicar una restriccin de inclusin. Con ella toda ocurrencia de
la entidad MONITOR que est asociada a una ocurrencia determinada de la entidad CURSO, a travs
de la relacin imparte, ha de estar unida a la misma ocurrencia de la entidad CURSO a travs de la
relacin recibe.

30/06/2013 14:53

BD03_Contenidos

23 de 52

[Link]

Autoevaluacin
Supongamos que hemos de modelar mediante el modelo Entidad/Relacin Extendido el
siguiente requerimiento de una base de datos: Para que un hombre se divorcie de una
mujer, primero ha de haber estado casado con ella.
Las entidades participantes son MUJER y HOMBRE, que estarn asociadas a travs de dos
relaciones: se casa, se divorcia. No tendremos en cuenta la cardinalidad de ambas
relaciones.
Qu tipo de restriccin sobre las relaciones hemos de establecer en nuestro esquema
para representar correctamente este requisito?
Restriccin de exclusividad.
Restriccin de inclusividad.
Restriccin de inclusin.
Efectivamente, este tipo de restriccin establece la obligatoriedad de haber un casamiento
para que pueda haber un divorcio y, adems, las entidades que se relacionan a travs de la
relacin se casa, deben ser las mismas que las participantes en se divorcia.

30/06/2013 14:53

BD03_Contenidos

24 de 52

[Link]

7.2.- Generalizacin y especializacin.

La segunda extensin incorporada en el modelo Entidad/Relacin
Extendido se centra en nuevos tipos de relaciones que van a permitir
modelar la realidad de una manera ms fiel. Estos nuevos tipos de
relacin reciben el nombre de jerarquas y se basan en los
conceptos de generalizacin, especializacin y herencia.
Cuando estamos diseando una base de datos puede que nos encontremos con conjuntos de entidades
que posean caractersticas comunes, lo que permitira crear un tipo de entidad de nivel ms alto que
englobase dichas caractersticas. Y a su vez, puede que necesitemos dividir un conjunto de entidades en
diferentes subgrupos de entidades por tener stas, caractersticas diferenciadoras. Este proceso de
refinamiento ascendente/descendente, permite expresar mediante la generalizacin 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 tambin 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 especializacin de una superclase en subclases, y
anlogamente, establecer una generalizacin de las subclases en superclases. La generalizacin es la
reunin en una superclase o supertivo de entidad de una serie de subclases o subtipos de entidades, que
poseen caractersticas comunes. Las subclases tendrn otras caractersticas que las diferenciarn entre
ellas.
Cmo detectamos una generalizacin? Podremos identificar una
generalizacin cuando encontremos una serie de atributos
comunes a un conjunto de entidades, y otros atributos que sean
especficos. Los atributos comunes conforman la superclase o
supertipo y los atributos especficos la subclase o subtipo.
Las jerarquas se caracterizan por un concepto que hemos de
tener en cuenta, la herencia. A travs de la herencia los atributos
de una superclase de entidad son heredados por las subclases. Si
una superclase interviene en una relacin, las subclases tambin
lo harn.
Cmo se representa una generalizacin o especializacin? Existen varias notaciones, pero hemos de
convenir que la relacin que se establece entre una superclase de entidad y todos sus subtipos se expresa
a travs de las palabras ES UN, o en notacin inglesa IS A, que correspondera con ES UN TIPO DE.
Partiendo de este punto, una jerarqua se representa mediante un tringulo invertido, sobre l quedar la
entidad superclase y conectadas a l a travs de lneas rectas, las subclases.
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 caractersticas y heredan las
pertenecientes a su superclase.
Una generalizacin/especializacin podr tener las siguientes restricciones semnticas:
Totalidad: una generalizacin/especializacin ser total si todo ejemplar de la superclase pertenece
a alguna de las subclases.
Parcialidad: una generalizacin/especializacin ser parcial si no todos los ejemplares de la
superclase pertenecen a alguna de las subclases.
Solapamiento: una generalizacin/especializacin presentar solapamiento si un mismo ejemplar de
la superclase puede pertenecer a ms de una subclase.
Exclusividad: una generalizacin/especializacin presentar exclusividad si un mismo ejemplar de la
superclase pertenece slo a una subclase.

Debes conocer
Las diferentes restricciones semnticas descritas tienen su representacin grfica, a travs del
grfico que a continuacin te mostramos podrs entender mejor su funcionamiento.

30/06/2013 14:53

BD03_Contenidos

25 de 52

[Link]

Ejercicio resuelto
Supongamos la existencia de dos entidades TURISMO y CAMION. Los atributos de la entidad
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.
Si analizamos ambas entidades existen algunos atributos comunes y otros que no. Por
tanto, podremos establecer una jerarqua. Para ello, reuniremos los atributos comunes y
los asociaremos a una nueva entidad superclase denominada VEHICULO. Las subclases
TURISMO y CAMI0N , con sus atributos especficos, quedarn asociadas a la superclase
VEHICULO mediante una jerarqua parcial con solapamiento. En el siguiente grfico puedes
apreciar la transformacin.
TURISMO

Para saber ms
Si quieres ver cmo se integra la representacin de jerarquas dentro de un esquema conceptual
completo, te proponemos el siguiente enlace:
Representacin de jerarqua en un esquema conceptual.

(0.08 MB)

30/06/2013 14:53

BD03_Contenidos

26 de 52

[Link]

7.3.- Agregacin.
Abordamos ahora la tercera de las extensiones del modelo
Entidad/Relacin Extendido, la Agregacin. En el modelo
Entidad/Relacin no es posible representar relaciones entre
relaciones. La agregacin es una
abstraccin a travs de la cual
las relaciones se tratan como entidades de nivel ms alto, siendo
utilizada para expresar relaciones entre relaciones o entre
entidades y relaciones.
Supongamos un ejemplo en el que hemos de modelar la siguiente
situacin: una empresa de seleccin de personal realiza entrevistas a diferentes aspirantes. Puede ser que,
de algunas de estas entrevistas a aspirantes, se derive una oferta de empleo, o no. En el siguiente grfico
se representan tres soluciones, las dos primeras errneas y una tercera correcta, utilizando una agregacin.
Como has podido observar, la representacin grfica de una agregacin se caracteriza por englobar con un
rectngulo las entidades y relacin a abstraer. De este modo, se crea una nueva entidad agregada que
puede participar en otras relaciones con otras entidades. En este tipo de relacin especial de agregacin, la
cardinalidad mxima y mnima de la entidad agregada siempre ser (1,1) no indicndose por ello en el
esquema.
Existen dos clases de agregaciones:
Compuesto/componente: Un todo se obtiene por la unin de diversas partes, que pueden ser
objetos distintos y que desempean papeles distintos en la agregacin. Teniendo esto en cuenta,
esta abstraccin permite representar que un todo o agregado se obtiene por la unin de diversas
partes o componentes que pueden ser tipos de entidades distintas y que juegan diferentes roles en la
agregacin.
Miembro/Coleccin: Un todo se obtiene por la unin de diversas partes del mismo tipo y que
desempean el mismo papel en la agregacin. Teniendo esto en cuenta, esta abstraccin permite
representar un todo o agregado como una coleccin de miembros, todos de un mismo tipo de entidad
y todos jugando el mismo rol. Esta agregacin puede incluir una restriccin de orden de los
miembros dentro de la coleccin (indicando el atributo de ordenacin). Es decir, permite establecer
un orden entre las partes.
En la siguiente figura puedes apreciar los tipos de agregacin y su representacin grfica.

Para saber ms
Con la agregacin hemos terminado de detallar las extensiones ms importantes del modelo
Entidad/Relacin Extendido. A lo largo de tu andadura por el mundo de las bases de datos y, en
concreto, en todo lo relacionado con los esquemas conceptuales y diagramas Entidad/Relacin,
es probable que te encuentres con diferentes notaciones y simbologas. Algunas ya las hemos
representado a lo largo de esta unidad y otras podrs encontrarlas en los dos enlaces que te
ofrecemos a continuacin. Adems, puedes utilizar la informacin que te proponemos para
reforzar y ampliar todo lo visto.

30/06/2013 14:53

BD03_Contenidos

27 de 52

[Link]

Resumen textual alternativo

Modelo E/R Extendido. (pginas 1 a 9).

(0.33 MB)

Autoevaluacin
Si hemos de representar a travs del modelo E/R Extendido los alumnos pertenecientes a
una clase, podramos utilizar una agregacin del tipo Compuesto/Componente.
Verdadero o Falso?
Verdadero.

Falso.

Correcto. No sera correcto, al ser el alumnado un conjunto de elementos que representan

el mismo rol en la relacin, el tipo de agregacin debera ser Miembro/Coleccin.

30/06/2013 14:53

BD03_Contenidos

28 de 52

[Link]

8.- Elaboracin de diagramas E/R.

Caso prctico
La verdad es que a travs del esquema que estamos generando,
queda ms claro cmo es cada entidad y cada relacin. Aplicando
estas tcnicas creo que vamos a ir afianzando un mtodo fiable que
podremos aplicar en futuros desarrollos afirma Juan.
Ada, est echando un vistazo a lo que llevan hecho Juan y Mara.
Efectivamente Juan, hay que ser metdicos y no descartar
ningn paso, pues podramos provocar errores en nuestros
desarrollos. La confianza de nuestros clientes es vital y para ello
hemos de obtener un producto con la mayor calidad posible.
Mara aade: Supongo que segn vayamos realizado proyectos
parecidos mejoraremos nuestra tcnica.

Llegados a este punto, te surgirn varias dudas Cmo creo un diagrama

E/R? Por dnde 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 elaboracin de diagramas
Entidad/Relacin.
Sabemos que en la fase de diseo conceptual de la base de datos, en la que
nos encontramos, hemos de generar el diagrama E/R que representar de
manera ms sencilla el problema real a modelar, independientemente del
Sistema Gestor de Base de Datos. Este esquema ser como un plano que
facilite la comprensin y solucin del problema. Este diagrama estar compuesto por la representacin
grfica, a travs de la simbologa vista, de los requisitos o condiciones que se derivan del problema a
modelar.
Saltarnos este paso en el proceso de creacin e implementacin de una base de datos, supondra prdida
de informacin. Por lo que esta fase, requerir de la creacin de uno o varios esquemas previos ms
cercanos al mundo real, antes del paso a tablas del modelo relacional.
Te dars cuenta que, como en la programacin, la prctica es fundamental. Los diagramas no siempre se
crean del mismo modo y, en ocasiones, hay que retocarlos e incluso rehacerlos. A travs de la resolucin
de diferentes problemas y la elaboracin de mltiples diagramas, obtendrs la destreza necesaria para
generar esquemas que garanticen una posterior y correcta conversin del modelo Entidad/Relacin al
modelo Relacional.

30/06/2013 14:53

BD03_Contenidos

29 de 52

[Link]

8.1.- Identificacin de entidades y relaciones.

Manos a la obra! Lo primero que hemos de tener a nuestra disposicin 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 especificacin de requerimientos. En otras palabras, el enunciado
del problema a modelar. Cuanto ms completa y detallada sea la informacin de la
que dispongamos, mucho mejor.
Suponiendo que conocemos la simbologa del modelo Entidad/Relacin y que
entendemos su significado Cmo empezamos? Las etapas para la creacin del
diagrama E/R se detallan a continuacin:
a. Identificacin de entidades: Es un proceso bastante intuitivo. Para localizar
aquellos elementos que sern las entidades de nuestro esquema,
analizaremos la especificacin de requerimientos en busca de nombres o
sustantivos. Si estos nombres se refieren a objetos importantes dentro del problema probablemente
sern entidades. Tendremos en cuenta que nombres referidos a caractersticas, cualidades o
propiedades no se convertirn 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 localizacin de varias caractersticas 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 nmero de entidades obtenidas debe ser manejable y segn se vayan identificando se les otorgar
nombres, preferiblemente en maysculas, representativos de su significado o funcin. De esta
manera el diagrama ser cada vez ms legible.
b. Identificacin de relaciones: Localizadas las entidades, debemos establecer qu relacin existe
entre ellas. Para ello, analizaremos de nuevo el documento de especificacin de requerimientos en
busca de verbos o expresiones verbales que conecten unas entidades con otras. En la gran
mayora de ocasiones encontraremos que las relaciones se establecen entre dos entidades
(relaciones binarias), pero prestaremos especial atencin a las relaciones entre ms entidades y a
unarias.
las relaciones recursivas o relaciones
Cada una de las relaciones establecidas deber tener asignado un nombre, preferiblemente en
minsculas, representativo de su significado o accin.

Reflexiona
En ocasiones, el identificador de una relacin est compuesto por varias palabras, como por
ejemplo: es supervisado, trabaja para, etc. Es recomendable que utilices guiones bajos para unir
las palabras que forman el identificador.

Dependiendo de la notacin elegida, el siguiente paso ser la representacin de la cardinalidad (mnima y

mxima) de las entidades participantes en cada relacin y del tipo de correspondencia de la relacin (1 a 1,
1 a muchos o muchos a muchos).
Si hemos encontrado alguna relacin
recursiva, reflexiva o unaria, hemos de representar en nuestro
esquema los roles desempeados por la entidad en dicha relacin.

30/06/2013 14:53

BD03_Contenidos

30 de 52

[Link]

Autoevaluacin
Rellena los huecos con los conceptos adecuados.
Las entidades suelen localizarse en el documento de especificacin de requerimientos a travs
de

sustantivos

cuidado, no siempre los

de atributos.
Reiniciar

y las relaciones a travs de

sustantivos

verbos

. Pero hemos de tener

representarn entidades, pues podra tratarse

Mostrar las respuestas

Tu puntuacin es 0/3.
En el documento de especificacin de requerimientos buscaremos los sustantivos y los
verbos para identificar entidades y relaciones respectivamente.

30/06/2013 14:53

BD03_Contenidos

31 de 52

[Link]

8.2.- Identificacin de atributos, claves y jerarquas.

Slo con la localizacin de entidades y relaciones no est todo hecho.
Hemos de completar el proceso realizando las siguientes tareas:
a. Identificacin de atributos: Volvemos sobre el documento de
especificacin de requerimientos para buscar nombres relativos a
caractersticas, propiedades, identificadores o cualidades de
entidades o relaciones. Resulta ms sencillo si nos preguntamos
Qu informacin es necesario tener en cuenta de una u otra
entidad o relacin? Quizs no todos los atributos estn reflejados
directamente
en
el
documento
de
especificacin
de
requerimientos, aplicando el sentido comn el diseador 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 algn 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 jerarqua de especializacin, o
bien, dejar las entidades tal y como han sido identificadas.
Cada atributo deber tener asignado un nombre, preferiblemente en minsculas, representativo de
su contenido o funcin. Adems, siempre es recomendable recopilar la siguiente informacin de cada
atributo:
Nombre y descripcin.
Atributos simples que lo componen, si es atributo compuesto.
Mtodo de clculo, 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 relacin.
b. Identificacin de claves: Del conjunto de atributos de una entidad se establecern una o varias
claves candidatas, escogindose una de ellas como clave o llave primaria de la entidad. Esta clave
estar formada por uno o varios atributos que identificarn de manera unvoca cada ocurrencia de
entidad. El proceso de identificacin 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 notacin elegida para la elaboracin
el diagrama E/R. Del mismo modo, se debern representar adecuadamente las entidades fuertes o
dbiles.
c. Determinacin de jerarquas: Como se ha comentado anteriormente, es probable que existan
entidades con caractersticas comunes que puedan ser generalizadas en una entidad de nivel
superior o superclase (jerarqua de generalizacin). Pero tambin, puede ser necesario expresar en
el esquema las particularidades de diferentes ejemplares de un tipo de entidad, por lo que se crearn
subclases o subtipos de una superclase o supertipo (jerarqua de especializacin). Para ello, habr
que analizar con detenimiento el documento de especificacin de requerimientos.
Si se identifica algn tipo de jerarqua, se deber representar adecuadamente segn el tipo de
notacin elegida, determinando si la jerarqua es total/parcial o exclusiva/con solapamiento.

30/06/2013 14:53

BD03_Contenidos

32 de 52

[Link]

8.3.- Metodologas.
Hasta aqu, tenemos identificados los elementos necesarios para construir nuestro
diagrama, pero Existe alguna metodologa para llevarlo a cabo? S, y adems
podremos utilizar varias. Partiremos de una versin preliminar del esquema
conceptual o diagrama E/R que, tras sucesivos refinamientos, ser modificado para
obtener el diagrama E/R definitivo. Las metodologas o estrategias disponibles para
la elaboracin del esquema conceptual son las siguientes:
a. Metodologa Descendente (Top-Down): Se trata de partir de un esquema
general e ir descomponiendo ste en niveles, cada uno de ellos con mayor
nmero de detalles. Se parte de objetos muy abstractos, que se refinan paso
a paso hasta llegar al esquema final.
b. Metodologa Ascendente (Bottom-Up): Inicialmente, se parte del nivel ms
bajo, los atributos. Se irn agrupando en entidades, para despus ir creando
las relaciones entre stas y las posibles jerarquas hasta obtener un
diagrama completo. Se parte de objetos atmicos que no pueden ser descompuestos y a
continuacin se obtienen abstracciones u objetos de mayor nivel de abstraccin que forman el
esquema.
c. Metodologa Dentro-fuera (Inside-Out): Inicialmente se comienza a desarrollar el esquema en una
parte del papel y a medida que se analiza la especificacin de requerimientos, se va completando
con entidades y relaciones hasta ocupar todo el documento.
d. Metodologa Mixta: Es empleada en problemas complejos. Se dividen los requerimientos en
subconjuntos que sern analizados independientemente. Se crea un esquema que servir como
estructura en la que irn interconectando los conceptos importantes con el resultado del anlisis de
los subconjuntos creados. Esta metodologa utiliza las tcnicas ascendente y descendente. Se
aplicar la tcnica descendente para dividir los requerimientos y en cada subconjunto de ellos, se
aplicar la tcnica ascendente.
Cul de estas metodologas utilizar? Cualquiera de ellas puede ser vlida, todo depender de lo fcil y til
que te resulte aplicarlas. Probablemente y, casi sin ser consciente de ello, t mismo crears tu propia
metodologa combinando las existentes. Pero, como decamos hace algunos epgrafes, la prctica es
fundamental. Realizando gran cantidad de esquemas, analizndolos y llevando a cabo modificaciones en
ellos es como irs refinando tu tcnica de elaboracin de diagramas E/R. Llegar un momento en que slo
con leer el documento de especificacin de requerimientos sers capaz de ir construyendo en tu mente
cmo ser su representacin sobre el papel, pero paciencia y ve paso a paso.

Citas para pensar

"Vsteme despacio, que tengo prisa".

Napolen Bonaparte.

Autoevaluacin

30/06/2013 14:53

BD03_Contenidos

[Link]

Rellena los huecos con los conceptos adecuados.

La metodologa en la que se parte de un alto nivel de abstraccin y que, tras un proceso de
refinamiento sucesivo, se obtiene el esquema final se denomina:

Metodologa
Reiniciar

Descendente

Mostrar las respuestas

Tu puntuacin es 0/2.
La Metodologa Descendente permite iniciar el proceso a partir de un esquema general
para conseguir un esquema detallado, a travs de sucesivos procesos de refinamiento y
descomposicin.

33 de 52

30/06/2013 14:53

BD03_Contenidos

34 de 52

[Link]

8.4.- Redundancia en diagramas E/R.

Una de las principales razones por las que las bases de datos aparecieron fue la eliminacin de la
redundancia en los datos Y qu es la redundancia?
Redundancia: reproduccin, reiteracin, insistencia, reincidencia, reanudacin. 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 grabacin o actualizacin 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, ms patente
se har esta problema.
Inconsistencia: se produce cuando los datos que estn 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 sabra qu dato es
vlido y cual errneo.
Para que una base de datos funcione ptimamente, hay que empezar realizando un buen diseo 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 solucin.
Dnde buscamos indicios de redundancia en nuestros esquemas? Existen lugares y elementos que
podran presentar redundancia, por ejemplo:
redundantes cuyo contenido se calcula en funcin de otros. Un atributo derivado
Atributos
puede ser origen de redundancia.
Varias entidades unidas circularmente o cclica a travs 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 relacin redundante:
Que el significado de las relaciones que componen el ciclo sea el mismo.
Que si eliminamos la relacin redundante, el significado del resto de relaciones es el mismo.
Que si la relacin eliminada tena 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 apreciacin. 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 mtodo de clculo del valor de un determinado atributo
derivado es complejo (varias operaciones matemticas 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 incorporacin o no de
redundancia controlada depender de la eleccin que haga el diseador.

30/06/2013 14:53

BD03_Contenidos

35 de 52

[Link]

8.5.- Propiedades deseables de un diagrama E/R.

Cuando construimos un diagrama Entidad/Relacin existen una serie de
propiedades o caractersticas que ste debera cumplir. Quiz no se
materialicen todas, pero hemos de intentar cubrir la gran mayora de ellas. De
este modo, conseguiremos que nuestros diagramas o esquemas conceptuales
tengan mayor calidad.
Estas caractersticas o propiedades deseables se desglosan a continuacin:
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 representacin del diagrama tiene su equivalente en los
requerimientos.
Correccin: Un diagrama E/R ser correcto si emplea de manera adecuada todos los elementos del
modelo Entidad/Relacin. La correccin de un diagrama puede analizarse desde dos vertientes:
Correccin sintctica: Se producir cuando no se produzcan representaciones errneas en el
diagrama.
Correccin semntica: Se producir cuando las representaciones signifiquen exactamente lo
que est estipulado en los requerimientos. Posibles errores semnticos seran: la utilizacin
de un atributo en lugar de una entidad, el uso de una entidad en lugar de una relacin, utilizar
el mismo identificador para dos entidades o dos relaciones, indicar errneamente alguna
cardinalidad u omitirla, etc.
Minimalidad: Un diagrama E/R ser mnimo si se puede verificar que al eliminar algn concepto
presente en el diagrama, se pierde informacin. Si un diagrama es redundante, no ser mnimo.
Sencillez: Un diagrama E/R ser sencillo si representa los requerimientos de manera fcil de
comprender, sin artificios complejos.
Legibilidad: Un diagrama E/R ser legible si puede interpretarse fcilmente. 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 estticos del diagrama.
Escalabilidad: Un diagrama E/R ser escalable si es capaz de incorporar posibles cambios
derivados de nuevos requerimientos.

Autoevaluacin
Si en un diagrama E/R asociamos un atributo a una entidad, pero este atributo debe
asociarse realmente a una relacin en la que interviene dicha entidad, estaramos
incumpliendo la propiedad de:
Completitud.
Correccin semntica.
Correccin sintctica.
Efectivamente, la Correccin semntica se centra en analizar si cada representacin del
diagrama significa exactamente lo mismo que lo estipulado por el documento de
especificacin de requerimientos.

30/06/2013 14:53

BD03_Contenidos

36 de 52

[Link]

9.- Paso del diagrama E/R al modelo relacional.

Caso prctico
Juan y Mara ya han terminado de elaborar el diagrama E/R,
con la ayuda de Ada. Las ltimas modificaciones hechas en
ste garantizan que todas las condiciones establecidas en el
documento de especificacin de requerimientos han sido
representadas adecuadamente.
Y ahora cmo se pasa este diagrama a una base de datos
real? pregunta Mara.
An hay que obtener el "paso a tablas" de lo representado en
el diagrama. En cuanto realicemos esa transformacin
tendremos los elementos necesarios para implementar nuestra
base de datos en cualquier SGBD relacional le aclara Ada.

30/06/2013 14:53

BD03_Contenidos

37 de 52

[Link]

Si analizamos todo el proceso descrito hasta el momento, la fase de

diseo conceptual desarrollada, y que se materializa en el diagrama
E/R, permite una gran independencia de las cuestiones relativas a la
implementacin fsica de la base de datos. El tipo de SGBD, las
herramientas software, las aplicaciones, lenguajes de programacin o
hardware disponible no afectarn, al menos hasta el momento, a los
resultados de esta fase.
Nuestro esquema conceptual habr sido revisado, modificado y probado
para verificar que se cumplen adecuadamente todos y cada uno de los
requerimientos del problema a modelar. Este esquema representar el punto de partida para la siguiente
fase, el diseo lgico de la base de datos.
El diseo lgico consistir en la construccin de un esquema de la informacin relativa al problema, basado
en un modelo de base de datos concreto. El esquema conceptual se transformar en un esquema lgico
que utilizar los elementos y caractersticas del modelo de datos en el que est basado el SGBD, para
implementar nuestra base de datos. Como pudimos ver anteriormente, estos modelos podrn ser: el modelo
en red, el modelo jerrquico y, sobre todo, el modelo relacional y el modelo orientado a objetos.
Para esta transformacin ser necesario realizar una serie de pasos preparatorios sobre el esquema
conceptual obtenido en la fase de diseo conceptual. Nos centraremos en la simplificacin y transformacin
del esquema para que el paso hacia el modelo de datos elegido (en este caso el modelo relacional) sea
mucho ms sencilla y efectiva.
Seguidamente, tomando como referencia el esquema modificado/simplificado,
se realizar el paso de ste al modelo de datos relacional. Esta transformacin
requerir de la aplicacin de determinadas reglas y condiciones que
garanticen la equivalencia entre el esquema conceptual y el esquema lgico.
Como paso posterior, sobre la informacin del esquema lgico obtenido, ser
necesario llevar a cabo un proceso que permitir disear de forma correcta la
estructura lgica de los datos. Este proceso recibe el nombre de
normalizacin, que se conforma como un conjunto de tcnicas que permiten
validar esquemas lgicos basados en el modelo relacional.
Entonces, qu pasos son los siguientes a dar? Resumiendo un poco,
simplificaremos nuestro diagrama E/R, lo transformaremos al modelo relacional, aplicaremos normalizacin
y obtendremos lo que se conoce en el argot como el paso a tablas del esquema conceptual o, lo que es lo
mismo, el esquema lgico. Desde ese momento, basndonos en este esquema, podremos llevarnos nuestra
base de datos a cualquier SGBD basado en el modelo relacional e implementarla fsicamente. Esta
implementacin fsica ser totalmente dependiente de las caractersticas del SGBD elegido.

30/06/2013 14:53

BD03_Contenidos

38 de 52

[Link]

9.1.- Simplificacin previa de diagramas.

Existe un conjunto de procedimientos y normas que es necesario aplicar a nuestros diagramas E/R para
que su transformacin al modelo lgico basado en el modelo relacional, sea correcta y casi automtica. Si
aplicas correctamente estas pautas, conseguirs que el proceso de transformacin sea fcil y fiable. Las
transformaciones de las que estamos hablando son las siguientes:
Transformacin de relaciones n-arias en binarias.
Eliminacin de relaciones cclicas.
Reduccin a relaciones jerrquicas (uno a muchos).
Conversin de entidades dbiles en fuertes.
Veamos detalladamente cmo llevar a cabo las transformaciones de las que hemos estado hablando:
Transformacin de atributos compuestos: Los atributos compuestos de una entidad han de ser
descompuestos en los atributos simples por los que estn formados.
Transformacin de atributos multivaluados: Si nuestro diagrama incluye la existencia de un
atributo multivaluado, este se ha de convertir en una entidad relacionada con la entidad de la que
procede. Para esta nueva entidad se elegir un nombre adecuado y tendr un nico atributo (el
correspondiente al antiguo atributo mltiple). Este atributo es posible que funcione correctamente
como clave primaria de la entidad pero a veces es posible que no. En este caso, la entidad que
hemos creado puede que sea dbil. Deberemos ajustar en cualquier caso correctamente las claves
primarias.
Transformacin a relaciones jerrquicas: Se trata de transformar las relaciones con cardinalidad
muchos a muchos (M a N) en relaciones con cardinalidad uno a muchos (1 a N). Observa la
animacin para comprender cmo se realiza la transformacin. Si existiese algn atributo asociado a
la relacin n-aria, quedara asociado a la nueva entidad que se crea.

Resumen textual alternativo

Transformacin de relaciones cclicas: De forma general, si tenemos una entidad sobre la que
existe una relacin cclica, para eliminar dicha relacin, se crea una nueva entidad cuya clave estar
formada por dos atributos, que contendrn las claves de las ocurrencias relacionadas. Entre ambas
entidades se establecen dos relaciones, cuya cardinalidad depender de la cardinalidad que tuviera
la relacin cclica en un principio.

30/06/2013 14:53

BD03_Contenidos

39 de 52

[Link]

Resumen textual alternativo

Transformacin de relaciones ternarias: El tratamiento de las relaciones ternarias es similar al

realizado para atributos asociados a relaciones, ya que una relacin ternaria puede considerarse
como una relacin binaria a a la que se le asocia una entidad. Por consiguiente, si en lugar de ser un
conjunto de atributos los asociados a la relacin es una entidad, se asociara sta mediante una
nueva relacin a la entidad resultante de eliminar la relacin binaria.

Resumen textual alternativo

Transformacin de entidades dbiles en fuertes: Para esta transformacin slo es necesario

aadir a la entidad dbil los atributos clave de la entidad que hace posible la identificacin de las
ocurrencias. La clave de esta nueva entidad fuerte estar formada por los atributos clave de la que
fuera entidad dbil ms los atributos adicionales.

Autoevaluacin

30/06/2013 14:53

BD03_Contenidos

40 de 52

[Link]

Sea la entidad ALUMNADO que participa en la relacin COLABORA con otra entidad llamada
GRUPO_TRABAJO. Un alumno o alumna puede colaborar en varios grupos de trabajo
simultneamente y, a su vez, en un grupo de trabajo pueden colaborar un nmero
indeterminado de alumnos. Se necesita registrar los das en los que el alumnado colabora
con cada grupo de trabajo, para ello se asocia a la relacin COLABORA un atributo
denominado fecha_colaboracin. Este atributo registrar en qu fecha un determinado
alumno/a ha colaborado en un determinado grupo de trabajo.
Si tuvieras que hacer la transformacin de esta parte del esquema conceptual para
eliminar la relacin M a N COLABORA, dnde colocaras el atributo fecha_colaboracin?
En la entidad ALUMNADO, ya que en esta entidad es donde se almacenan todos los datos
asociados al alumnado. Si consultamos el alumno o alumna, sabremos cundo a
colaborado en un grupo.
En una nueva entidad que es combinacin de ALUMNADO y GRUPO_TRABAJO, a la que
podramos llamar ALUMNADO_GRUPO.
En la entidad GRUPO_TRABAJO.
Correcto, al transformar la relacin M a N, se crean dos relaciones 1 a N entre ALUMNADOALUMNADO_GRUPO Y GRUPO_TRABAJO-ALUMNADO_GRUPO, siendo ALUMNADO_GRUPO una nueva entidad
que tendr por claves las claves primarias de ALUMNADO y GRUPO_TRABAJO, recibiendo como
atributo el atributo que estaba asociado a la relacin COLABORA. Para cada par
ALUMNADO/GRUPO_TRABAJO tendremos registrado cundo se realiz la colaboracin.

30/06/2013 14:53

BD03_Contenidos

41 de 52

[Link]

10.- Paso del diagrama E/R al Modelo Relacional.

Si se ha llevado a cabo el proceso preparatorio de nuestro esquema conceptual o diagrama E/R, segn se
ha indicado en epgrafes anteriores, dispondremos de un Esquema Conceptual Modificado (ECM) en el que
slo existirn exclusivamente entidades fuertes con sus atributos y relaciones jerrquicas (1 a N). Pues
bien, la aplicacin del modelo de datos Relacional es automtica, para ello se deben tener en cuenta las
siguientes cuestiones:
Toda entidad se transforma en una tabla.
Todo atributo se transforma en columna dentro de una tabla.
El atributo clave de la entidad se convierte en clave primaria de la tabla y se representar subrayado
en la tabla.
Cada entidad dbil generar una tabla que incluir todos sus atributos, aadindose a sta los
atributos que son clave primaria de la entidad fuerte con la que est relacionada. Estos atributos
aadidos se constituyen como clave fornea que referencia a la entidad fuerte. Seguidamente, se
escoger una clave primaria para la tabla creada.
Las relaciones Uno a Uno podrn generar una nueva tabla o propagar la clave en funcin de la
cardinalidad de las entidades.

Resumen textual alternativo

Las relaciones Uno a Muchos podrn generar una nueva tabla o propagar la clave.

30/06/2013 14:53

BD03_Contenidos

42 de 52

[Link]

Resumen textual alternativo

Las relaciones reflexivas o cclicas podrn generar una o varias tablas en funcin de la cardinalidad
de la relacin.

Resumen textual alternativo

Las jerarquas generarn la reunin, eliminacin o creacin de relaciones 1 a 1.

30/06/2013 14:53

BD03_Contenidos

43 de 52

[Link]

Resumen textual alternativo

Las relaciones Muchos a Muchos se transforman en una tabla que tendr como clave primaria las
claves primarias de las entidades que asocia.

Resumen textual alternativo

No obstante, si en el proceso de generacin del diagrama E/R o esquema conceptual hemos aplicado
correctamente las reglas de simplificacin de diagramas, nuestro Esquema Conceptual Modificado nos
permitir el paso a tablas teniendo en cuenta slo las transformaciones asociadas a entidades, relaciones 1
a N, 1 a 1 y Jerarquas.

30/06/2013 14:53

BD03_Contenidos

44 de 52

[Link]

Ejercicio resuelto
Sea la siguiente representacin a travs del modelo E/R de una relacin entre dos entidades,
obtn el paso a tablas de dicho esquema:

El paso a tablas de dicho esquema sera el siguiente:

EMPRESA (Cdigo_empresa, razn_social, domicilio, N_Trabajadores)
TRABAJADOR(DNI, Nombre, Apellido1, Apellido2, Num_SS)

Para materializar la relacin de uno a muchos LABORAL, se incluye una clave fornea en la
entidad TRABAJADOR, que referencia a la entidad EMPRESA, quedando:
EMPRESA (Cdigo_empresa, razn_social, domicilio, N_Trabajadores)
TRABAJADOR(DNI, Nombre, Apellido1, Apellido2, Num_SS, Cdigo_empresa)

30/06/2013 14:53

BD03_Contenidos

45 de 52

[Link]

11.- Normalizacin de modelos relacionales.

Caso prctico
En estos primeros desarrollos Ada debe estar muy pendiente del
trabajo que estn realizando Juan y Mara. El proceso de
transformacin del Esquema Conceptual Modificado al modelo
Relacional, requiere cierta experiencia y concentracin. Dada su
importancia y dificultad, este paso deben llevarlo a cabo de manera
tranquila y comentando en grupo las diferentes operaciones que
van a ir realizando.

Crees que tu base de datos ya podra construirse directamente sobre

el SGBD relacional que hayas elegido? La respuesta podra ser
afirmativa, pero si queremos que nuestra base de datos funcione con
plena fiabilidad, es necesario antes llevar a cabo un proceso de
normalizacin de las tablas que la componen.
Y qu es eso de la normalizacin?

Normalizacin: Proceso que consiste en imponer a las tablas del modelo Relacional una serie
de restricciones a travs de un conjunto de transformaciones consecutivas. Este proceso
garantizar que las tablas contienen los atributos necesarios y suficientes para describir la
realidad de la entidad que representan, permitiendo separar aquellos atributos que por su
contenido podran generar la creacin de otra tabla.

Para saber ms
A veces uno se pregunta Quin habr sido el ideante de estos conceptos? En el siguiente
enlace que te proponemos, puedes conocer quin fue.
Codd y la normalizacin de modelos relacionales.

A principios de la dcada de los setenta, concretamente en 1972, Codd establece una tcnica para llevar a
cabo el diseo de la estructura lgica de los datos representados a travs del modelo relacional, a la que
denomin normalizacin. Pero esta tcnica no ha de utilizarse para el diseo de la base de datos, sino
como un proceso de refinamiento que debe aplicarse despus de lo que conocemos como paso a tablas, o
lo que formalmente se denomina traduccin del esquema conceptual al esquema lgico. Este proceso de
refinamiento conseguir los siguientes objetivos:
Suprimir dependencias errneas entre atributos.
Optimizar los procesos de insercin, modificacin y borrado en la base de datos.
El proceso de normalizacin se basa en el anlisis de las dependencias entre atributos. Para ello tendr en
cuenta los conceptos de: dependencia funcional, dependencia funcional completa y dependencia

30/06/2013 14:53

BD03_Contenidos

46 de 52

[Link]

transitiva. Estos conceptos se desarrollan seguidamente.

Y cmo se aplica la normalizacin? Es un proceso que se realiza en varias etapas secuenciales. Cada
etapa est asociada a una forma normal, que establece unos requisitos a cumplir por la tabla sobre la que
se aplica. Existen varias formas normales: Primera, Segunda, Tercera, Boyce-Codd, Cuarta, Quinta y
Dominio-Clave. Como hemos indicado, el paso de una forma normal a otra es consecutivo, si no se
satisface una determinada forma normal no puede pasarse al anlisis de la siguiente. Segn vamos
avanzando en la normalizacin, los requisitos a cumplir sern cada vez ms restrictivos, lo que har que
nuestro esquema relacional sea cada vez ms robusto.
Como norma general, para garantizar que no existan problemas en la actualizacin de datos, es
recomendable aplicar el proceso de normalizacin hasta Tercera Forma Normal o incluso hasta
Forma Normal de Boyce-Codd. En los siguientes epgrafes se describen las caractersticas y requisitos de
cada una de las formas normales.

30/06/2013 14:53

BD03_Contenidos

47 de 52

[Link]

11.1.- Tipos de dependencias.

Vamos a desarrollar aqu los conceptos sobre los que se basa el anlisis de
dependencias entre atributos, que se lleva a cabo en el proceso de
normalizacin antes indicado, son los siguientes:
D iependencia Funcional: Dados los atributos A y B, se dice que B
depende funcionalmente de A, s, y solo s, para cada valor de A slo
puede existir un valor de B. La dependencia funcional siempre se
establece entre atributos de una misma tabla. El atributo A se denomina
determinante, ya que A determina el valor de B. Para representar esta
dependencia funcional utilizamos la siguiente notacin: A B. Hay que
indicar que A y B podran ser un solo atributo o un conjunto de ellos.
Dependencia Funcional Completa: Dados los atributos A1, A2, ...Ak y
B, se dice que B depende funcionalmente de forma completa de A1, A2,
...Ak, si y solo si B depende funcionalmente del conjunto de atributos A1, A2, ...Ak, pero no de
ninguno de sus posibles subconjuntos.
Dependencia Transitiva: Dados tres atributos A, B y C, se dice que existe una dependencia
transitiva entre A y C, si B depende funcionalmente de A y C depende funcionalmente de B. A, B y C
podran ser un solo atributo o un conjunto de ellos.
Para ilustrar los tipos de dependencias descritas, analiza el siguiente ejercicio resuelto.

Ejercicio resuelto
Dadas las siguientes tablas:
EMPLEADO( DNI, Nombre, Direccin, Localidad, Cod_Localidad,
Edad_hijo)
LIBRO (Ttulo_libro, Num_ejemplar, Autor, Editorial, Precio)

Nombre_hijo,

Resuelve las siguientes cuestiones:

a. Indica qu atributos presentan una dependencia funcional de la clave primaria de la tabla
EMPLEADO.
b. Indica qu atributos presentan una dependencia funcional completa en la tabla LIBRO.
c. Indica qu atributos presentan una dependencia transitiva en la tabla EMPLEADO.

Apartado a)
Los atributos Nombre, y Direccin dependen funcionalmente de DNI, ya que para un DNI
especfico slo podr haber un nombre y una direccin. Pero los atributos Nombre_hijo y
Edad_hijo no presentan esa dependencia funcional de DNI, ya que para un DNI especfico
podramos tener varios valores diferentes en esos atributos. (Consideraremos para este
ejemplo que todos los empleados registrados en esta base de datos tienen nombres
distintos). Expresemos estas dependencias funcionales mediante su notacin:
DNI Nombre
DNI Direccin
Apartado b)
Los atributos Editorial y Precio dependen funcionalmente del conjunto de atributos que
forman la clave primaria de la tabla, pero no dependen de Ttulo_libro o de
Num_ejemplar por separado, por lo que presentan una dependencia funcional completa de
la clave. El atributo Autor depende funcionalmente slo y exclusivamente de
Titulo_libro, por lo que no presenta una dependencia funcional completa de los atributos
que forman la clave.
Apartado c)

30/06/2013 14:53

BD03_Contenidos

48 de 52

[Link]

Los atributos Cod_Localidad y Localidad dependen funcionalmente de DNI, pero entre

Cod_Localidad y Localidad existe otra dependencia funcional. Por tanto, se establece
que Localidad depende funcionalmente de Cod_Localidad, y a su vez, Cod_Localidad
depende funcionalmente de DNI. Con lo que podemos afirmar que existe una dependencia
transitiva entre Localidad y DNI. Si lo representamos con la notacin asociada a las
dependencias funcionales, quedara: DNI Cod_Localidad Localidad.

30/06/2013 14:53

BD03_Contenidos

49 de 52

[Link]

11.2.- Formas Normales.

Una vez conocidos los conceptos sobre los que se basa el proceso de
normalizacin, se han de llevar a cabo una serie de etapas
consecutivas en las que se aplicarn las propiedades de cada una de
las formas normales definidas por Codd. A continuacin se exponen los
requisitos a cumplir por las tablas de nuestra base de datos segn la
forma normal que apliquemos.
1 Forma Normal: Una tabla est en Primera Forma Normal (1FN o
FN1) s, y slo s, todos los atributos de la misma contienen valores
atmicos, es decir, no hay grupos repetitivos. Dicho de otra forma,
estar en 1FN si los atributos no clave, dependen funcionalmente de la
clave. Cmo se normaliza a Primera Forma Normal?
a. Se crea, a partir de la tabla inicial, una nueva tabla cuyos atributos son los que presentan
dependencia funcional de la clave primaria. La clave de esta tabla ser la misma clave primaria de la
tabla inicial. Esta tabla ya estar en 1FN.
b. Con los atributos restantes se crea otra tabla y se elije entre ellos uno que ser la clave primaria de
dicha tabla. Comprobaremos si esta segunda tabla est en 1FN. Si es as, la tabla inicial ya estar
normalizada a 1FN y el proceso termina. Si no est en 1FN, tomaremos la segunda tabla como tabla
inicial y repetiremos el proceso.
2 Forma Normal: Una tabla est en Segunda Forma Normal (2FN o FN2) s, y slo s, est en 1FN y,
adems, todos los atributos que no pertenecen a la clave dependen funcionalmente de forma completa de
ella. Es obvio que una tabla que est en 1FN y cuya clave est compuesta por un nico atributo, estar en
2FN. Cmo se normaliza a Segunda Forma Normal?
a. Se crea, a partir de la tabla inicial, una nueva tabla con los atributos que dependen funcionalmente
de forma completa de la clave. La clave de esta tabla ser la misma clave primaria de la tabla inicial.
Esta tabla ya estar en 2FN.
b. Con los atributos restantes, se crea otra tabla que tendr por clave el subconjunto de atributos de la
clave inicial de los que dependen de forma completa. Se comprueba si esta tabla est en 2FN. Si es
as, la tabla inicial ya est normalizada y el proceso termina. Si no est en 2FN, tomamos esta
segunda tabla como tabla inicial y repetiremos el proceso.
3 Forma Normal: Una tabla est en Tercera Forma Normal (3FN o FN3) s, y slo s, est en 2FN y,
adems, cada atributo que no est en la clave primaria no depende transitivamente de la clave primaria.
Cmo se normaliza a Tercera Forma Normal?
a. Se crea, a partir de la tabla inicial, una nueva tabla con los atributos que no poseen dependencias
transitivas de la clave primaria. Esta tabla ya estar en 3FN.
1. Con los atributos restantes, se crea otra tabla con los dos atributos no clave que intervienen en la
dependencia transitiva, y se elije uno de ellos como clave primaria, si cumple los requisitos para ello.
Se comprueba si esta tabla est en 3FN. Si es as, la tabla inicial ya est normalizada y el proceso
termina. Si no est en 3FN, tomamos esta segunda tabla como tabla inicial y repetiremos el proceso.
Forma Normal de Boyce Codd: Una tabla est en Forma Normal de Boyce-Codd (FNBC o BCFN) s, y
slo s, est en 3FN y todo determinante es una clave candidata. Un determinante ser todo atributo simple
o compuesto del que depende funcionalmente de forma completa algn otro atributo de la tabla. Aquellas
tablas en la que todos sus atributos forman parte de la clave primaria, estarn en FNBC. Por tanto, si
encontramos un determinante que no es clave candidata, la tabla no estar en FNBC. Esta redundancia
suele ocurrir por una mala eleccin de la clave. Para normalizar a FNBC tendremos que descomponer la
tabla inicial en dos, siendo cuidadosos para evitar la prdida de informacin en dicha descomposicin.
Otras formas normales
Existen tambin la Cuarta Forma Normal (4FN o FN4), Quinta Forma Normal (5FN o FN5) y Forma Normal
de Dominio-Clave (DKFN), aunque se ha recomendado normalizar hasta 3FN o FNBC. La 4FN se basa en
el concepto de Dependencias Multivaluadas, la 5FN en las Dependencias de Join o de reunin y la DKFN
en las restricciones impuestas sobre los dominios y las claves.

30/06/2013 14:53

BD03_Contenidos

50 de 52

[Link]

Para saber ms
Si deseas conocer cules son las propiedades y requisitos a cumplir establecidos en las formas
normales 4, 5 y DKFN, te proponemos los siguientes enlaces:
Cuarta Forma Normal.
Quinta Forma Normal.
Forma Normal Dominio-Clave.

Ejercicio resuelto
Sea la siguiente tabla:
COMPRAS (cod_compra, cod_prod, nomb_prod, fecha, cantidad, precio, fecha_rec,
cod_prov, nomb_prov, tfno).

Se pide normalizarla hasta FNBC.

Comprobamos 1FN:
La tabla COMPRAS est en 1FN ya que todos sus atributos son atmicos y todos los atributos
no clave dependen funcionalmente de la clave.
Comprobamos 2FN:
Nos preguntaremos Todo atributo depende de todo el conjunto de atributos que forman la
clave primaria, o slo de parte?. Como vemos, existen atributos que dependen slo de una
parte de la clave, por lo que esta tabla no est en 2FN.
Veamos las dependencias:
cod_prod nomb_prod, y cod_prod es parte de la clave primaria.

Al no estar en 2FN, hemos de descomponer la tabla COMPRAS en:

COMPRA1 (cod_compra, cod_prod,
cod_prov, nomb_prov, tfno).
PRODUCTO (cod_prod, nomb_prod).

fecha,

cantidad,

precio,

fecha_rec,

Una vez hecha esta descomposicin, ambas tablas estn en 2FN. Todos los atributos no
clave dependen de toda la clave primaria.
Comprobamos 3FN:
PRODUCTO est en 3FN, ya que por el nmero de atributos que tiene no puede tener
dependencias transitivas.
COMPRA1 est en 3FN? Hemos de preguntarnos si existen dependencias transitivas entre
atributos no clave.
Veamos las dependencias:
cod_prov nomb_prov
cod_prov tfno
(siendo cod_prov el cdigo del proveedor y nomb_prov el nombre del proveedor)

30/06/2013 14:53

BD03_Contenidos

51 de 52

[Link]

COMPRA1 no est en 3FN porque existen dependencias transitivas entre atributos no clave,

por tanto hemos de descomponer:

COMPRA2 (cod_compra, cod_prod, fecha,
cod_prov)
PROVEEDOR (cod_prov, nomb_prov, tfno)

cantidad,

precio,

fecha_rec,

Comprobamos FNBC:
PRODUCTO est en FNBC, ya que est en 3FN y todo determinante es clave candidata.
COMPRA2 est en FNBC, ya que est en 3FN y todo determinante es clave candidata.
PROVEEDOR est en FNBC, ya que est en 3FN y todo determinante es clave candidata.

La tabla inicial COMPRAS queda normalizada hasta FNBC del siguiente modo:
PRODUCTO (cod_prod, nomb_prod)
COMPRA2 (cod_compra, cod_prod, fecha,
cod_prov)
PROVEEDOR (cod_prov, nomb_prov, tfno)

cantidad,

precio,

fecha_rec,

30/06/2013 14:53

BD03_Contenidos

52 de 52

[Link]

Anexo.- Licencias de recursos.

Licencias de recursos utilizados en la Unidad de Trabajo.
Recurso (1)

Datos del recurso (1)

Recurso (2)

Datos del re

Autora: NASA
Licencia: Dominio Pblico.
Procedencia: [Link]
/wiki/File:Aldrin_Apollo_11_original.jpg

Autora: Oskari Kettun

Licencia: Creative Co
2.0 Generic
Procedencia:
[Link]
/wiki/File:Norway_Lys

Autora: [Link]
Licencia: Creative Commons Attribution-Share Alike
2.0 Generic
Procedencia: [Link]
/wiki/File:Frank_Zane.jpg

Autora: [Link]
Licencia: GPL
Procedencia:
[Link]
/wiki/File:Exquisite-Co

Autora: Eduloqui
Licencia: Creative Commons Attribution
Unported
Procedencia: [Link]
/wiki/File:[Link]

Autora: Lander777
Licencia: Dominio Pb
Procedencia:
[Link]
/wiki/File:[Link]

3.0

Autora: Delaroche.
Licencia: Dominio pblico.
Procedencia: [Link]
/wiki/File:Napoleonbonaparte_coloured_drawing.png

Autora: Diego Daz E

Licencia: Dominio pb
Procedencia:
M
[Link]
/wiki/File:FormasNorm

30/06/2013 14:53