Bases de Datos y

Sistemas de Informacin

Grado en Ingeniera Informtica

Unidad Didctica 3: Diseo de Bases de Datos

Relacionales
Parte 2: Diseo Conceptual
(Doc. UD3.2)
 Para la elaboracin de este documento se han consultado los siguientes textos:
- [BRJ06] Booch, G.; Rumbaugh, J.; Jacobson, I.; El lenguaje unificado de modelado (2 edicin).
Pearson, Addsion Wesley, 2006.
- [CB10] Thomas M. Connolly, Carolyn E. Begg; Database Systems: A Practical Approach to
Design, Implementation and Management, 5/E , Addison-Wesley, 2010.
- [CCM03] Celma, M.; Casamayor, J. C.; Mota, L.; Bases de datos relacionales. Pearson, Prentice
Hall, 2003.
- [EN02] Ramez Elmasri, Shamkant B. Navathe. Fundamentos de sistemas de bases de datos.
Addison-Wesley 2002)
- [Lar04] Larman, C.; UML y Patrones: una introduccin al anlisis y diseo orientado a objetos y
al proceso unificado (2 edicin). Pearson, Prentice Hall, 2004
- [MCC94] Mota, L.; Celma, M.; Casamayor, J. C.; Bases de datos relacionales: teora y diseo
SPUPV 767.94, 1994.
- [Oli01] Oliv, A.; Modelitzaci conceptual de sistemes dinformaci. Edicions UPC. 2001.
- [SR07] Stevens, P.; Pooley, R.; Utilizacin del UML en Ingeniera del Software con objetos y
componentes (2 edicin). Pearson, Addsion Wesley, 2007.

ndice
1 Introduccin ........................................................................................................................... 1
2 Diseo Conceptual .................................................................................................................. 1
2.1 El diagrama de clases de UML ........................................................................................... 1
2.1.1 Clase ........................................................................................................................... 1
2.1.2 Atributo ...................................................................................................................... 2
2.1.3 Asociacin binaria....................................................................................................... 4
2.1.4 Asociacin n-arias ....................................................................................................... 7
2.1.5 Clases dbiles ............................................................................................................. 8
2.1.6 Generalizacin/Especializacin ................................................................................... 9
2.2 Obtencin del diagrama de clases .................................................................................. 11
2.2.1 Identificar las clases con sus atributos ...................................................................... 11
2.2.2 Identificar generalizaciones/especializaciones .......................................................... 12
2.2.3 Identificar asociaciones entre clases ......................................................................... 14
2.2.4 Especificar restricciones de integridad ...................................................................... 18
2.3 Ejercicio 1: Restaurante .................................................................................................. 20
2.4 Ejercicio 2: Ciclismo ........................................................................................................ 21
2.5 Ejercico 3: Una compaa de seguros .............................................................................. 22
Departamento de Sistemas Informticos y Computacin

1 INTRODUCCIN
En este documento se presenta el Diseo conceptual de Sistemas de Informacin. Se utiliza el
diagrama de clases de UML para el diseo de la parte esttica (los datos con sus restricciones) de
un SI. Tambin se presentan algunos aspectos metodolgicos que nos ayuden en el proceso de
diseo conceptual.

2 DISEO CONCEPTUAL
El diseo conceptual es la fase del diseo de una base de datos cuyo objetivo es obtener una
representacin de la realidad que capture las propiedades estticas y dinmicas de la misma que
son necesarias para satisfacer los requisitos; esta representacin debe suponer una imagen fiel del
comportamiento del mundo real.
Para realizar esta tarea se necesita una herramienta que permita obtener una representacin
(usualmente grfica) de la informacin que se maneja en el sistema de informacin. La
herramienta que se propone utilizar es el UML (Unified Modeling Language)1. El UML fue
propuesto por Booch, Rumbaugh y Jacobson en la dcada de los 90 y pretende ser una
herramienta para modelar desde sistemas de informacin empresariales hasta aplicaciones
distribuidas basada en web. De entre todos los diagramas que permite generar el UML hay uno, el
diagrama de clases, que resulta muy til en el diseo de una base de datos para la representacin
del esquema conceptual.

2.1 El diagrama de clases de UML

El diagrama de clases permite representar las estructuras que constituyen el contenido del
sistema de informacin junto con restricciones de distintos tipos que limitan las ocurrencias
vlidas de las mismas. Para ello hace uso, fundamentalmente, de tres conceptos: clase, atributo y
asociacin. Adems, para aumentar la capacidad expresiva del diagrama tambin se contempla la
definicin de objetos especializados (o generalizados). Todos estos conceptos se presentan a
continuacin con detalle.

2.1.1 Clase
La observacin de la realidad permite detectar el conjunto de objetos (fsicos o
conceptuales) de los que se quiere almacenar informacin para, mediante el uso de la
clasificacin, que es uno de los mecanismos de abstraccin ms primario que existen, descubrir el
conjunto de clases (o tipos de objetos) que son de inters para la organizacin. Este mecanismo
de abstraccin, que es utilizado la mayor parte de las veces de forma inconsciente, permite no
prestar atencin a las ocurrencias concretas sino al conjunto de ocurrencias.
Ejemplo 1
En el siguiente grfico se aprecia el uso de este mecanismo de abstraccin:

1 Una alternativa a esta herramienta es el Modelo Entidad-Relacin propuesto por Peter Pin-Shan Chen en 1976.

Documento UD3.2 1
Departamento de Sistemas Informticos y Computacin

Mundo real Modelo de la realidad

PERSONA

CLASIFICACIN

COCHE

As pues, los componentes bsicos de un sistema de informacin son los objetos de los que se
quiere almacenar informacin; todos los objetos que son de la misma clase se representan con un
una clase.

Una clase es una descripcin de un conjunto de objetos que comparten las

mismas propiedades.

Con una clase se representar cualquier tipo de persona, concepto, suceso o evento (en
definitiva cualquier cosa) sobre el que se quiera almacenar informacin.
En diagrama de clases del UML, una clase se representa con un rectngulo nominado dividido
en tres secciones como se muestra a continuacin.
Clase1 nombre de la clase
Atributo1 atributos

Mtodo 1
mtodos

En el apartado siguiente se describe la seccin de los atributos. En la tercera seccin de la clase

se pueden incluir las operaciones (o procesos) asociadas a la clase. Dado que esto se corresponde
con la dinmica del sistema, este punto no se va a presentar y en muchos casos no se dibujar.

2.1.2 Atributo
Un atributo representa una propiedad del elemento que se est modelando y que es
compartida por todos los objetos de la clase.

Un atributo es una propiedad de una clase identificada con un nombre, cuyas

instancias pueden tomar valor de un conjunto que se especifica.

Grficamente, los atributos se listan en el compartimento que hay justo debajo del nombre de
la clase y para cada uno se puede indicar:
El tipo de datos asociado que determina los valores que puede tomar el atributo. Se
pueden dar dos casos:
El atributo toma valores simples: en este caso hay que indicar el nombre de un
tipo de datos conocido: char (cadena de caracteres), real, int (entero), date
(fecha), o bien una enumeracin de valores posibles entre parntesis.
El atributo est estructurado en un registro.

Documento UD3.2 2
Departamento de Sistemas Informticos y Computacin

Restricciones. Se definen entre corchetes y pueden ser:

De unicidad: representa el hecho de que las distintas ocurrencias de una clase
deben tomar valores distintos para el atributo (o conjunto de atributos) sobre
los que se define esta restriccin.
Se indica con la etiqueta {nicoi} en cada atributo que forme parte del isimo
conjunto de atributos con restriccin de unicidad
De cardinalidad: expresan el nmero de valores que puede tomar el atributo
para cada ocurrencia de la clase. Los valores ms usuales son los siguientes:
{1..1}: el atributo tiene exactamente un valor para cada ocurrencia de la
clase.
{0..1}: el atributo puede tener como mucho un valor para cada ocurrencia de
la clase o puede no tener valor (es el valor por defecto).
{1..*}: el atributo puede tener ms de un valor para cada ocurrencia de la
clase pero al menos tiene un valor.
{0..*}: el atributo puede tener ms de un valor para cada ocurrencia de la
clase o puede no tener valor.
De identificacin: un identificador es un conjunto de atributos con restriccin de
unicidad y con cardinalidad {1..1} que permite distinguir dos ocurrencias de la
clase y que se elige como mecanismo para hacer referencia a los objetos o
instancias de la clase (slo hay un identificador aunque puede constar de varios
atributos). A los atributos que constituyen el identificador se les distingue con la
etiqueta {id}.
Ejemplo 2
En la figura siguiente se muestra la clase Persona que se describe por sus atributos:
DNI (Documento Nacional de Identidad): se ha elegido como identificador y es de tipo
cadena de caracteres.
NSS (Nmero de la Seguridad Social): siempre toma un valor que debe ser distinto para
cada persona y es de tipo cadena de caracteres.
Nombre: siempre toma un valor para cada persona y tiene dos campos, propio y
apellidos ambos de tipo cadena de caracteres.
Edad: puede tener o no valor para cada persona y es de tipo entero.
Telfonos: cada persona puede tener cero, uno o varios nmeros de telfono.
Persona
DNI: {id}: char
NSS: {unico1}: {1..1}: char
nombre: {1..1}:
propio: char
apellidos: char
edad: {0..1}: int
telfonos: {0..*}: char

Documento UD3.2 3
Departamento de Sistemas Informticos y Computacin

2.1.3 Asociacin binaria

Los objetos de un sistema de informacin se conectan unos con otros siendo tambin de
inters modelar estas conexiones; para ello se utilizar el concepto de asociacin del diagrama de
clases de UML.

Las asociaciones permiten representar las posibles relaciones existentes entre

las clases del sistema de informacin.

Una asociacin que conecta exactamente dos clases se dice que es binaria. Aunque no es
frecuente, se pueden tener asociaciones que conecten ms de dos clases (asociaciones n-arias).
Ms adelante, en este documento, se presentarn las asociaciones ternarias.
Grficamente, una asociacin se representa con una lnea continua que conecta dos clases no
necesariamente diferentes y puede llevar los siguientes adornos:
Nombre: una asociacin puede tener un nombre que se utiliza para describir la
naturaleza de la relacin. Se incluye en la parte central de la lnea que representa la
asociacin y, aunque no es obligatorio especificarlo, ayuda a la comprensin del
diagrama. Suele ser menos necesario en el caso de que haya roles. Para clarificar la
interpretacin de la asociacin se puede incluir una flecha, , que indique el sentido
del nombre de la asociacin. Por simplicidad, y a no ser que quede ambiguo el sentido
de la asociacin, se omitir. Slo se ha incluido en los ejemplos 6 y 7 para ilustrar su
uso.
Rol: sirve para expresar el papel que juega una clase en una asociacin. En el caso de
que la asociacin de una clase sea consigo misma, es necesario incluir el papel que la
clase tiene cuando participa en la asociacin en cada uno de los dos sentidos posibles,
ya que si no se incluye, no se pueden expresar claramente las restricciones de
cardinalidad. Para asociaciones entre clases distintas, no es obligatorio incluir esta
informacin.
Cardinalidad (o multiplicidad): una asociacin binaria representa el hecho de que
instancias de una clase se conectan, con un determinado significado, con instancias de
la otra clase. Es frecuente que existan limitaciones en cuanto al nmero de conexiones
posibles. Estas limitaciones se representan en la cardinalidad de cada clase en la
asociacin y se definen con un valor mnimo y un valor mximo separados por dos
puntos seguidos. Cuando se indican estos valores en un extremo de una asociacin, se
est especificando cuntos objetos de la clase de ese extremo puede haber para cada
objeto de la clase en el otro extremo.
En el siguiente diagrama se han representado dos clases (de nombres A y B) y una
asociacin entre ellas (de nombreR). Las cardinalidades incluidas especifican lo
siguiente:

A B
R
minB ..maxB minA ..maxA

R(A(minA..maxA), B(minB..maxB))

Documento UD3.2 4
Departamento de Sistemas Informticos y Computacin

Cada ocurrencia de A se relaciona con, como mnimo minA ocurrencias de B y

como mximo con maxA ocurrencias de B;
Cada ocurrencia de B se relaciona con, como mnimo minB ocurrencias de A y
como mximo con maxB ocurrencias de A;
Considerando la cardinalidad de A en el diagrama anterior, los valores ms frecuentes
son los siguientes:
minA=1 y maxA=1: Cada ocurrencia de A se relaciona con, como mnimo una
ocurrencia de B y como mximo con una ocurrencia de B, esto es, cada
ocurrencia de A se relaciona exactamente con una ocurrencia de B.
minA=0 y maxA=*: Cada ocurrencia de A puede relacionarse con cualquier
nmero de ocurrencias de B (0, 1,).
minA=0 y maxA=1: Cada ocurrencia de A se relaciona como mximo con una
ocurrencia de B o puede no relacionarse con ninguna.
minA=1 y maxA=*: Cada ocurrencia de A puede relacionarse con cualquier
nmero de ocurrencias de B pero al menos con una (1, 2,).
Cuando la cardinalidad mnima de una clase es distinta de 0 se dice que esa clase tiene
restriccin de existencia respecto a la asociacin.
En ocasiones para expresar la cardinalidad de una clase en una asociacin slo se
proporciona uno de los dos valores, siendo el otro asumido por defecto, as:
1: equivale a 1..1
*: equivale a 0..*
Sin embargo, por claridad es aconsejable especificar los dos valores para cada caso.
Cuando una asociacin tiene a su vez atributos, stos se especifican en una clase sin nombre
que se conecta mediante una lnea discontinua con la lnea de la asociacin. Una asociacin nunca
tendr atributos identificadores.
Ejemplo 3
Sea el siguiente diagrama que representa la informacin de qu ros pasan por qu provincias.
Se ha representado que un ro puede pasar por varias provincias, al menos por una, y que por una
provincia puede que pasen varios ros o ninguno.

Ro Provincia
Pasa_por
cod_r: {id}:char cod_p: {id}:char
0..* 1..*

Si queremos incluir en el diagrama un atributo que represente la informacin de durante

cuntos kilmetros pasa cada ro por cada provincia que atraviesa, la asociacin Pasa_por debe
definirse como una clase de la forma siguiente:

Documento UD3.2 5
Departamento de Sistemas Informticos y Computacin

Ro Provincia
Pasa_por
cod_r: {id}:char cod_p: {id}:char
0..* 1..*

km: {1..1}:real

Ejemplo 4
Sea el siguiente diagrama que representa la informacin sobre discos y canciones. La
asociacin Contiene representa las canciones que contiene cada disco.

Si adems se quiere mantener informacin de los cantantes, deberemos incluir una nueva
clase con la informacin que se quiera almacenar. Por otra parte, si se quiere poder incluir la
informacin de qu cantante canta una determinada cancin en un disco, se deber incluir una
nueva asociacin (Canta) que relacione una ocurrencia de Contiene (un par cancin/disco) con
una ocurrencia de Cantante. Para representar esta informacin, la asociacin Contiene se debe
considerar como una nueva clase (aunque en este caso no tenga atributos) ya que las asociaciones
slo se pueden establecer entre clases. Este mecanismo lo representaremos como se ve en la
siguiente figura.

Documento UD3.2 6
Departamento de Sistemas Informticos y Computacin

2.1.4 Asociacin n-arias

Sea R una asociacin n-aria (n > 2) definida sobre las clases A1, A2,, An. El conjunto de
ocurrencias posibles de R es R A1 A2 An. Sean A y B dos subconjuntos disjuntos del
conjunto de clases {A1, A2, , An} tales que A B = {A1, A2,, An}. Las cardinalidades se
representan, para cada par de subconjuntos A y B que se puedan formar, con la expresin
siguiente:
R(A(minA..maxA), B(minB..maxB))
Que significa que:
Cada ocurrencia del conjunto de entidades A puede estar relacionada a travs de R con n
ocurrencias del conjunto de entidades Bsiendo minA n maxA.
Cada ocurrencia del conjunto de entidades B puede estar relacionada a travs de R con n
ocurrencias del conjunto de entidades A siendo minB n maxB.
Para el caso de n=3 las asociaciones se llaman ternarias, para n=4 cuaternarias, y as
sucesivamente, aunque las asociaciones con n>3 son poco frecuentes.
Las asociaciones n-arias se representan por medio de lneas que salen de cada clase asociada y
confluyen en un punto intermedio.
Ejemplo 5
Sea el siguiente diagrama que representa la informacin sobre profesores, asignaturas y
grupos de una academia que prepara a los alumnos para la obtencin del titulo de la ESO. La
asociacin Docencia relaciona siempre un profesor con un grupo y una asignatura, por eso se la
llama asociacin ternaria.

Documento UD3.2 7
Departamento de Sistemas Informticos y Computacin

La manera de interpretar las cardinalidades es la siguiente:

Docencia(Profesor(0..*), Asignatura-Grupo(1..1)). Asignatura-Grupo(1..1) significa que
un par Asignatura-Grupo puede estar relacionado como mximo con un profesor y
como mnimo debe estar relacionado con un profesor, es decir, todo posible par
Asignatura-Grupo debe participar en la asociacin2. Profesor(0..*), significa que un
profesor se puede relacionar como mximo con muchos pares Asignatura-Grupo (*) o
puede que no participe en la asociacin Docencia (0).
Docencia(Asignatura(1..*), Profesor-Grupo(0..*)). Profesor-Grupo(0..*) significa que un
par Profesor-Grupo puede estar relacionado como mximo con muchas asignaturas y
como mnimo con 0 asignaturas. Asignatura(1..*) significa que una asignatura se puede
relacionar como mximo con muchos pares Profesor-Grupo (*) y que debe participar
necesariamente en la asociacin Docencia (1).
Docencia(Grupo(1..*), Profesor-Asignatura(0..*)). Profesor-Asignatura(0..*) significa
que un par Profesor-Asignatura puede estar relacionado como mximo con muchos
grupos y como mnimo con 0 grupos. Grupo(1..*) significa que un grupo se puede
relacionar como mximo con muchos pares Profesor-Asignatura (*) y que debe
participar necesariamente en la asociacin Docencia (1).

2.1.5 Clases dbiles

Una clase sufre restriccin de dependencia de identificacin cuando no puede identificarse con
sus propios atributos de manera que sus ocurrencias son distinguibles gracias a su asociacin con
otra/s clase/s. A este tipo de clases se les denomina clases dbiles. Esta restriccin implica siempre
una restriccin de existencia.
Esta restriccin se representa con la etiqueta {id} en lugar de la cardinalidad (en este caso la
cardinalidad es siempre 1:1), e implica que la clase dbil cuenta entre sus atributos con el o los
atributos identificadores de la/s clase/s de las que depende, sin que tengan que representarse
explcitamente.
A continuacin se muestran varios ejemplos que aclaran este concepto.
Ejemplo 6
Sea el siguiente diagrama:

Ciudad Pas
Est
nom_c: {id}:char nom_p: {id}: char
0..* {id}

La clase Ciudad es dbil ya que en la organizacin (informacin geogrfica mundial) que se est
modelando puede haber varias ciudades con el mismo nombre aunque evidentemente siempre en
distintos pases; entonces cmo se distingue una ciudad de otra? En primer lugar por el pas al
que pertenecen y dentro de un mismo pas por el atributo nom_c necesario en este caso ya que
en un pas puede haber muchas ciudades

2 Esto significa que necesariamente en todos los grupos se imparten todas las asignaturas.

Documento UD3.2 8
Departamento de Sistemas Informticos y Computacin

Ejemplo 7
Un caso menos frecuente se presenta a continuacin.
Una organizacin tiene informatizados los expedientes jurdicos de todos los pleitos en los
que est involucrada; de cada pleito, entre otras informaciones, se conoce el nmero de pleito y el
resultado de la sentencia que puede ser favorable o desfavorable. En caso de ser desfavorable se
puede presentar como mucho un recurso; cada recurso se identifica por el nmero de pleito al
que atae y entre otros atributos interesa saber en qu fecha se realiza. El diagrama asociado a
este problema sera:

Recurso Pleito
Afecta
fecha: {1..1}: date num: {id}: int
0..1 {id}

Dado que un pleito se puede recurrir como mucho una vez, para distinguir un recurso de otro
slo se necesita saber qu pleito se est recurriendo no siendo necesario en este caso un atributo
de la clase recurso que ayude a distinguirlos.
Resumiendo, las clases dbiles son aqullas para las que no existe un identificador como se ha
definido antes, sino que para distinguir entre sus ocurrencias es necesario utilizar una (o ms de
una) de sus asociaciones siendo necesario la existencia de un atributo (o conjunto de atributos)
llamado semiidentificador cuando la cardinalidad mxima de la otra clase sea mayor que 1.
Existe la posibilidad de que la clase se identifique gracias a varias asociaciones con otras clases;
en este caso, las cardinalidades mximas de todas estas clases en esas asociaciones deben ser
mayores que 1.
Ejemplo 8
Supnganse que se quiere almacenar informacin sobre las notas que han obtenido los
alumnos en distintas asignaturas teniendo en cuenta que un alumno se puede presentar varias
veces a una asignatura, pero en fechas distintas, y que los exmenes no tienen identificador.
Una posible forma de identificar cada examen es sabiendo qu alumno lo ha hecho, de qu
asignatura es y en qu fecha se realiz la prueba (para distinguir los exmenes del mismo alumno
en la misma asignatura). El esquema que muestra esta solucin es el siguiente.

Alumno Examen Asignatura

Hace Sobre
DNI: {id}:char fecha: {id}:date cod: {id}:char
{id} 0..* nota: {1..1}:real 0..* {id}

2.1.6 Generalizacin/Especializacin
Cuando se detecta que entre distintas clases definidas en el esquema existe una relacin de
inclusin (esto es, que todas las ocurrencias de una clase son a su vez ocurrencia de otra ms
general), este hecho se expresa por medio de la Generalizacin/Especializacin. Esto significa que
la clase ms general se especializa en una o varias clases especializadas o subclases, o dicho a la
inversa, que una o varias clases se generalizan en una clase general o superclase. Este proceso se

Documento UD3.2 9
Departamento de Sistemas Informticos y Computacin

puede repetir a distintos niveles, siendo posible que una clase tenga ms de una superclase,
siempre que la clase ms general del conjunto sea nica. La clase ms general ser adems la
nica que tenga identificador. Todas las subclases de una clase tienen, adems de sus atributos
propios, todos los atributos de sus superclases (en cualquier nivel), aunque no se representan en
el diagrama.
Una clase puede participar en distintas Generalizaciones/Especializaciones que se definen
atendiendo a criterios distintos. El criterio se puede indicar al lado del arco.
La especializacin se representa uniendo todas las clases especializadas segn un criterio con
un arco que se conecta con la clase general mediante una flecha.

Clase G

Clase 1 Clase 2 Clase 3

La especializacin de una clase en varias subclases puede ser, segn el recubrimiento que
hagan las clases especializadas de la clase general en:
Total: en este caso todas las ocurrencias de la clase general deben corresponderse con
al menos una ocurrencia de alguna de las subclases; o
Parcial: cuando puedan existir ocurrencias de la clase general que no se especialice en
ninguna de las subclases.
Por otra parte, segn la posible interseccin entre las clases especializadas, puede ser:
Solapada: cuando una ocurrencia de la clase general pueda corresponderse con ms de
una ocurrencia de las subclases; o
Disjunta: cada ocurrencia de la clase general puede corresponderse como mucho con
una ocurrencia de alguna de las subclases.
Estas propiedades se especifican entre llaves junto al arco que representa la especializacin.
Los valores por defecto son parcial y solapada, es decir, los menos restrictivos.
Ejemplo 9
En el siguiente diagrama de clases se expresa que los empleados de una empresa pueden
especializarse de acuerdo a tres criterios:
Segn el cuerpo al que pertenece.
Segn que el empleado sea o no gerente.
Segn el tipo de contrato que tiene.

Documento UD3.2 10
Departamento de Sistemas Informticos y Computacin

2.2 Obtencin del diagrama de clases

El objetivo fundamental de este apartado es ensear cmo se puede abordar la tarea del
diseo conceptual de las propiedades estticas de un sistema de informacin utilizando el
diagrama de clases presentado, es decir, proponer una metodologa de diseo as como destacar
puntos conflictivos que pueden aparecer en el desarrollo de un sistema de informacin.
Desafortunadamente, no es posible definir un algoritmo que permita obtener, de forma
determinista, a partir de las especificaciones el mejor diagrama posible, de manera que la
metodologa se reduce a un conjunto de tareas a realizar y a una serie de consejos que pretenden
avisar al alumno de ciertos detalles que pueden ayudarle a definir un diagrama correcto al menos
sintcticamente.
Para obtener un diagrama adecuado y fiable a partir del anlisis de la realidad y de los
requisitos de la organizacin hay que realizar las siguientes actividades:
Identificar las clases con sus atributos,
Identificar generalizaciones/especializaciones,
Identificar asociaciones entre clases, y
Especificar restricciones de integridad.
Estas actividades se realizan de forma iterativa hasta conseguir definir un diagrama de clases lo
ms fiel posible a la realidad y en el cual el conjunto de restricciones de integridad explcitas
incluidas en el anexo al diagrama sea lo ms pequeo posible. A continuacin se comentan todas
ellas.

2.2.1 Identificar las clases con sus atributos

Por cada tipo de objeto de la realidad, una vez concretada la informacin descriptiva que se
desea almacenar, se definir una clase en el diagrama. Una clase viene definida por un conjunto
de atributos que representan la informacin que se desea conocer de cada tipo de objeto. Para
cada atributo se debe:
Asociar un tipo de datos, y
Especificar la cardinalidad y las restricciones de unicidad si es que las hay.
De entre estos atributos, si es posible, se destacarn los atributos del identificador; si no existe
identificador, la clase debe ser considerada dbil y habr que decidir, cuando se estudien las
asociaciones, sobre cul o cules se apoya para identificarse.
Documento UD3.2 11
Departamento de Sistemas Informticos y Computacin

No hay que pensar en que antes de avanzar en el diseo hay que definir un conjunto de clases
que sea fijo, sino que ste puede cambiar a medida que se tomen ciertas decisiones de diseo. Por
ejemplo es posible que algunos atributos inicialmente considerados desaparezcan luego y se
conviertan en clases.

2.2.2 Identificar generalizaciones/especializaciones

La especializacin es el proceso por el que se clasifica una clase de objetos en subclases ms
especializadas. La generalizacin es el proceso inverso por el que se generalizan varias clases para
obtener una abstracta de ms alto nivel que incluya los objetos de todas estas clases. La
especializacin es un refinamiento conceptual mientras que la generalizacin es una sntesis
conceptual.
Se pueden distinguir tres procesos mentales que pueden conducir a definir una generalizacin/
especializacin.
1) Estrategia descendente (especializacin): en el conjunto de ocurrencias de una clase, se
pueden definir subconjuntos con propiedades estticas (atributos) o de comportamiento
(asociaciones) distintas.
Ejemplo 10
En el contexto de una agencia de viajes, sobre los clientes de la agencia, se ha diseado el
siguiente diagrama:

Cliente
Empresa
DNI: {id}: char
nombre: {1..1}: char 0..* Pertenece 0..1 CIF: {id}: char
gua: {0..1}: char nombre: {1..1}: char
pas: {0..*}: char

Ms tarde se detecta que hay dos clases de clientes: los turistas, a los que siempre se asignar
un gua; y los viajantes de negocios, que siempre pertenecen a una empresa y de los que interesa
conocer los pases que suelen visitar; entonces, una solucin ms adecuada al problema sera la
siguiente:
Cliente
DNI: {id}: char
nombre: {1..1}: char

{Total, Solapada}

Empresa
Turista Viajante
0..* Pertenece 1..1 CIF: {id}: char
gua: {1..1}: char pas: {1..*}: char nombre: {1..1}: char

2) Estrategia ascendente (generalizacin): existe en el esquema un conjunto de clases con

algunas propiedades similares y que en la realidad se podran clasificar en un objeto comn.

Documento UD3.2 12
Departamento de Sistemas Informticos y Computacin

Ejemplo 11
En el siguiente diagrama se han definido dos clases independientes con algunos atributos
comunes.
Secretario Tcnico
DNI: {id}: char DNI: {id}: char
nombre: {1..1}: char nombre: {1..1}: char
pulsaciones: {1..1}: int categora: {1..1}: char
idiomas: {0..*}: char

Si adems se observa que ambas clases se refieren a trabajadores de la empresa que para
algunos procesos conviene tener juntos, sera ms correcto considerar una clase general
Empleado:
Empleado
DNI: {id}: char
nombre: {1..1}: char

{Parcial, Disjunta}

Secretario Tcnico
pulsaciones: {1..1}: int categora: {1..1}: char
idiomas: {0..*}: char

3) Jerarqua: se detecta una relacin de inclusin entre clases previamente definidas.

Ejemplo 12
En el contexto de una escuela universitaria, supngase que se han definido dos clases:
Alumno Proyectante
DNI: {id}: char DNI: {id}: char
nombre: {1..1}: char nombre: {1..1}: char
especialidad: {0..1}: int especialidad: {0..1}: char
ttulo: {1..1}: char
director: {1..1}:char

Pero si se tiene en cuenta que todo proyectante es tambin un alumno, la solucin ms

adecuada sera:
Alumno
DNI: {id}: char
nombre: {1..1}: char
especialidad: {0..1}: int

Proyectante
ttulo: {1..1}: char
director: {1..1}:char

Documento UD3.2 13
Departamento de Sistemas Informticos y Computacin

Como se puede observar en los ejemplos, en cualquiera de estos casos se ha definido una
generalizacin/especializacin de manera que los atributos identificadores y los descriptores que
son comunes a todas las clases estn en la clase general, quedndose los atributos especficos y las
asociaciones especficas en cada una de las clases especializadas.
Hay que darse cuenta de que la generalizacin/especializacin no debe definirse por los
nombres que puedan tener los atributos sino cuando realmente exista entre los objetos la relacin
de subclase que implica este concepto. Por otra parte, una generalizacin/especializacin en la
que las clases especializadas no tienen propiedades distintivas (atributos o asociaciones) no
resulta muy til pudindose representar la misma informacin y de forma ms sencilla con un
atributo discriminador en la clase general (esta idea se ilustra en el ejemplo siguiente).
Ejemplo 13
Supngase que interesa saber si los libros de una biblioteca estn escritos en espaol o en
otros idiomas. Un diseo como el siguiente:

Libro
ISBN: {id}: char
ttulo: {1..1}: char

{Total, Disjunta}

En_Espaol No_en_Espaol

es demasiado complicado si la nica diferencia entre los libros es si estn escritos o no en

espaol. Se puede expresar lo mismo con el siguiente diagrama que por otra parte resulta mucho
ms sencillo:
Libro
ISBN: {id}: char
ttulo: {1..1}: char
espaol: {1..1}: (s, no)

Se debe indicar qu tipo de generalizacin/especializacin se est definiendo, especificando si

es total o parcial y disjunta o solapada como se ha hecho en todos los ejemplos presentados,
excepto si hay una sola subclase, en cuyo caso no hace falta, ya que siempre ser parcial, y no se
tiene sentido las propiedades disjunta y solapada

2.2.3 Identificar asociaciones entre clases

Una vez definido un conjunto inicial de clases que, como ya se ha comentado, podr ser
reconsiderado a lo largo del todo el diseo, hay que estudiar las asociaciones existentes entre
ellas, ya que raramente existirn clases sin conexiones con otras. Para definir una asociacin hay
que especificar las clases implicadas y las cardinalidades mximas y mnimas.
Para la definicin de un conjunto de asociaciones adecuado es importante tener en cuenta las
siguientes indicaciones:

Documento UD3.2 14
Departamento de Sistemas Informticos y Computacin

1) Ante la duda se recomienda elegir las cardinalidades menos restrictivas (0 para la mnima y *
para la mxima).
2) Las asociaciones redundantes deben eliminarse. Dos o ms asociaciones se consideran
redundantes si representan el mismo concepto; sin embargo, hay que darse cuenta de que entre
las mismas clases se pueden definir ms de una asociacin siempre que tengan significados
diferentes.
Ejemplo 14
En el siguiente diagrama, aunque con nombres diferentes, se han definido dos asociaciones
que representan la misma informacin por lo que una debera eliminarse:

Proveedor Pieza
0..* Vende 0..*
DNI: {id}: char cdigo: {id}: char
nombre: {1..1}:char 0..* Suministra 0..* peso: {id}: real

Sin embargo, pueden existir dos asociaciones definidas sobre las mismas clases pero con
significados completamente distintos:

Vuelo Ciudad
0..* Despega 1..1
num_vuelo: {id}: char nombre: {id}: char
precio: {1..1}: real 0..* Aterriza 1..1 pas: {id}: char

3) Eliminar la redundancia que se deriva de dependencias transitivas, una asociacin ser

redundante por dependencias transitivas cuando pueda derivarse a travs de otras asociaciones
(dos o ms).
Ejemplo 15
En el siguiente diagrama se han definido tres asociaciones:
Comunidad_Autnoma
nombre: {id}: char
1..1
habitantes: entero
1..1

Pertenece

1..* 1..*
Provincia Municipio
cdigo: {id}: char 1..1 Est_en 1..* nombre: {id}: char
nombre: {1..1}: real dir_ayuntamiento: char

La asociacin Es_de es redundante ya que sus ocurrencias se pueden derivar a partir de

Pertenece y Est_en (un municipio es de la comunidad autnoma a la que pertenece su provincia);
por ello se debera eliminar.

Documento UD3.2 15
Departamento de Sistemas Informticos y Computacin

Comunidad
nombre: {id}: char
habitantes: entero
1..1

Pertenece

1..*
Provincia Municipio
cdigo: {id}: char 1..1 Est_en 1..* nombre: {id}: char
nombre: {1..1}: real dir_ayuntamiento: char

Sin embargo, no siempre es posible eliminar la redundancia como se muestra en el siguiente

ejemplo.
Ejemplo 16
Departamento
nombre: {id}: char
1..1
telfono: {0..*}: char
1..1

Pertenece

0..* 0..*
Profesor Asignatura
DNI: {id}: char 0..1 Responsable 0..1 cdigo: {id}: char
nombre: {1..1}: real nombre. {1..1}: char

Si en este sistema de informacin se debe cumplir que los profesores slo son responsables de
asignaturas de su departamento, entonces el departamento al que pertenece un profesor puede
derivarse a travs del departamento al que est adscrita la asignatura de la que es responsable,
pero como puede darse el caso de que un profesor no sea responsable de ninguna asignatura no
se puede eliminar. La misma reflexin puede hacerse respecto a la asociacin Adscrita. As pues,
dado que pese a existir cierta redundancia no es posible eliminar ninguna asociacin sin perder
por ello informacin, este diagrama necesita una restriccin de integridad que controle la
restriccin: los profesores slo son responsables de asignaturas de su departamento.
Sin embargo, no hay que pensar, que siempre que hay un ciclo entre clases existe una
dependencia transitiva, como se ilustra en siguiente ejemplo.

Documento UD3.2 16
Departamento de Sistemas Informticos y Computacin

Ejemplo 17
Provincia
cdigo: {id}: char
1..1
nombre: char
1..1

Pertenece

1..* 0..*
Ciudad Persona
cdigo: {id}: char 1..1 Trabaja 0..* DNI: {id}:char
nombre: {1..1}: real nombre: char

En este caso, pese a existir un ciclo de las mismas caractersticas que en el ejemplo 13 no existe
redundancia ya que una persona no tiene por qu haber nacido en la misma provincia en la que
est la ciudad en la que trabaja.
4) Especificar el rol que cada clase juega en una asociacin cuando alguna clase participa ms
de una vez en ella. El caso ms sencillo se presenta en las asociaciones binarias en las que las dos
clases relacionadas son la misma. En el siguiente ejemplo se muestran algunas asociaciones de
este tipo especificando el rol o papel.
Ejemplo 18
1) Relacin de prerrequisitos en el conjunto de las asignaturas de una carrera: una asignatura
puede ser prerrequisito de muchas asignaturas y tener tambin a muchas asignaturas como
prerrequisito.

2) Relacin de composicin entre piezas: una pieza se compone de muchas piezas y a su vez
puede formar parte de muchas piezas.

Documento UD3.2 17
Departamento de Sistemas Informticos y Computacin

3) Relacin entre los ros por el hecho de que unos son afluentes de otros: un ro puede ser
afluente de otro pero a su vez muchos ros pueden afluir a l

En general, hay que ser cuidadosos con las asociaciones reflexivas ya que normalmente exigen
que se especifiquen ciertas propiedades que no quedan contempladas en la definicin de la
asociacin. Por ejemplo, las tres asociaciones representadas en el ejemplo anterior son
antisimtricas (una asignatura no puede ser prerrequisito de un prerrequisito suyo) y
antirreflexivas (una asignatura no puede ser prerrequisito de s misma), propiedades que no se
expresan en el diagrama.

2.2.4 Especificar restricciones de integridad

Para terminar con el diseo, todas aquellas propiedades de la realidad que no hayan quedado
expresadas en el diagrama de clases deben incluirse. Para ello puede hacerse uso de los elementos
de anotacin de los diagramas de UML. Los elementos de anotacin son comentarios que se
pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento del
modelo. Grficamente se representa con un rectngulo con una esquina doblada en el que se
incluye un texto. El rectngulo se conecta con una flecha discontinua apuntando hacia el objeto al
que se refiere.
Ejemplo 19
Para el diagrama del ejemplo 12 se podra incluir la siguiente restriccin: Para todo vuelo las
ciudades de despegue y aterrizaje son distintas:

Documento UD3.2 18
Departamento de Sistemas Informticos y Computacin

Vuelo Ciudad
La ciudad de despegue 0..* Despega 1..1
debe ser distinta de la num_vuelo: {id}: char nombre: {id}: char
de aterrizaje precio: {1..1}: real 0..* Aterriza 1..1 pas: {id}: char

Para finalizar, en un diagrama de clases correcto hay que tener en cuenta las siguientes reglas:
Todas las clases tienen identificador o bien son dbiles o especializaciones.
Las asociaciones nunca tienen identificador
No puede haber dos nombres iguales entre las clases, las asociaciones ni los roles.
Los nombres de atributos en una clase no se repiten.
Las clases especializadas nunca tienen identificador ni son dbiles ya que heredan la
identificacin de su clase general.
En el diagrama de clases no existen las claves ajenas (concepto propio del modelo
relacional) de forma que nunca se debe incluir un atributo en una clase con la intencin
de que represente una asociacin con otra clase.

Documento UD3.2 19
Departamento de Sistemas Informticos y Computacin

2.3 Ejercicio 1: Restaurante

Un restaurante desea que sus mens puedan ser consultados desde terminales y para ello ha
decidido disear una base de datos relacional. En el restaurante se ofertan varios mens de los
que se quiere saber el cdigo, el precio y los platos que lo componen (al menos uno); cada plato
puede haber sido diseado como mucho por un cocinero del restaurante (que tiene DNI y
nombre, tambin puede tener pas de origen y edad como datos de inters); de los platos se debe
saber el cdigo asignado al plato, el nombre y quizs las caloras aproximadas; tambin puede
interesar almacenar para algunos platos los ingredientes necesarios (indicando la cantidad) y el
vino que se recomienda para su completo disfrute. De cada vino disponible en el restaurante se
quiere conocer su cdigo (interno al restaurante) y el nombre, tambin se desea conecer el tipo, y
la aada. Por ltimo y para poder controlar la despensa, de cada ingrediente se debe almacenar
un cdigo, el nombre, el precio en mercado y las existencias que quedan
El diagrama de clases que representa este sistema de informacin es el siguiente:

Documento UD3.2 20
Departamento de Sistemas Informticos y Computacin

2.4 Ejercicio 2: Ciclismo

El siguiente diagrama de clases representa el sistema de informacin de la base de datos de
ciclismo, utilizada en anteriormente.

Documento UD3.2 21
Departamento de Sistemas Informticos y Computacin

2.5 Ejercico 3: Una compaa de seguros

Una compaa de seguros desea disear un sistema de informacin para gestionar las
peritaciones de los vehculos accidentados a su cargo. Cada peritacin se identifica con un nmero
de referencia y se debe conocer necesariamente la fecha de realizacin, el perito asignado (cdigo
y nombre), los datos del taller donde se ha realizado (nombre del taller y domicilio) y del vehculo
peritado. Cada vehculo, se codifica con un identificador secuencial. Para los vehculos
matriculados adems se almacena la matrcula, para los ciclomotores el nmero de placa
municipal y para cualquier otro (por ejemplo bicicletas) un cdigo interno (las matrculas, nmeros
de placa, y cdigos internos en conjunto deben ser nicos). Adems, interesa saber la marca,
modelo, propietario y si est asegurado, el nmero de pliza, la compaa, el tipo y la fecha de
caducidad (toda pliza siempre va ligada a un vehculo). Slo se tiene informacin de los vehculos
sobre los que se hacen peritaciones.
Se dispone de un catlogo de las diferentes partes de los vehculos codificadas con su
correspondiente descripcin (por ejemplo, XX1 Aleta delantera, XX2 Puerta Derecha, XX3 Faro
Derecho, etc.). El resultado de la peritacin consiste en una estimacin de las partes del vehculo
afectadas. Para cada parte afectada, se emite un diagnstico en el que se indica si se ha de reparar
o sustituir, as como el tiempo de mano de obra estimado. Adems, se detallan los materiales a
utilizar en la reparacin de cada parte afectada. De estos materiales tambin se dispone de un
catlogo con el cdigo, descripcin y precio.

Documento UD3.2 22