MODELADO DE DATOS CON UML

Entidades (clases en UML)

Rectángulo con tres partes (nombre –superior-, lista de atributos –centro-, lista de
operaciones –inferior-. La parte destinada a la lista de operaciones la vamos a dejar en
blanco). El nombre será, preferentemente, un sustantivo.

NombreEntidad
+ atr_1 : int
+ atr_2 : char
+ atr_3 : Date
+ atr_4 :
+ atr_5 :

Para cada atributo especificamos su nombre y, si tenemos esa información, su tipo. Si

conocemos qué atributo (o atributos) van a ser identificadores, podemos indicarlo (por
ejemplo escribiendo su nombre en MAYÚSCULAS)

Asociaciones

Se representan con una línea que une dos entidades. A ser posible les daremos un
nombre, preferentemente un verbo.

Entidad_A 1..1 1..1 Entidad_B

nombreAsociación

Siempre indicaremos su cardinalidad.

En función de la cardinalidad, las asociaciones se clasifican en asociaciones de uno a

uno, asociaciones de uno a muchos (o de muchos a uno) y asociaciones de muchos a
muchos.

• Asociaciones uno a uno

Entidad A Entidad B Explicación

0..1 0..1 Cada instancia de A se relaciona con una o con ninguna instancia de B.
Cada instancia de B ser relaciona con una o con ninguna instancia de A.
1..1 0..1 Cada instancia de A se relaciona con una o con ninguna instancia de B.
Cada instancia de B se relaciona con una instancia de A
0..1 1..1 Cada instancia de A se relaciona con una instancia de B
Cada instancia de B ser relaciona con una o con ninguna instancia de A.
1..1 1..1 Cada instancia de A se relaciona con una instancia de B
Cada instancia de B se relaciona con una instancia de A

Enric Sesa i Nogueras 1

 MODELADO DE DATOS CON UML

• Asociaciones de uno a muchos (o de muchos a unos)

Entidad A Entidad B Explicación

0..1 0..* Cada instancia de A se puede relacionar con múltiples instancias de B
(cero, una o más de una)
Cada instancia de B se relaciona con una o con ninguna instancia de A
0..1 1..* Cada instancia de A se puede relacionar con múltiples instancias de B
pero se ha de relacionar con una como mínimo
Cada instancia de B se relaciona con una o con ninguna instancia de A
0..1 * Cada instancia de A se puede relacionar con múltiples instancias de B
(se desconoce si hay un mínimo)
Cada instancia de B se relaciona con una o con ninguna instancia de A
1..1 0..* Cada instancia de A se puede relacionar con múltiples instancias de B
(cero, una o más de una)
Cada instancia de B se relaciona, obligatoriamente, con una de A
1..1 1..* Cada instancia de A se puede relacionar con múltiples instancias de B
pero se ha de relacionar con una como mínimo
Cada instancia de B se relaciona, obligatoriamente, con una de A
1..1 * Cada instancia de A se puede relacionar con múltiples instancias de B
(se desconoce si hay un mínimo)
Cada instancia de B se relaciona, obligatoriamente, con una de A

Para el caso de muchos a uno, sólo hay que intercambiar los papeles de A y B en la
asociación

• Asociaciones de muchos a muchos

Entidad A Entidad B Explicación

0..* 0..* Cada instancia de A se puede relacionar con múltiples instancias de B
(cero, una o más de una)
Cada instancia de B se pude relacionar con múltiples instancias de A
(cero, una o más de una)
0..* 1..* Cada instancia de A se puede relacionar con múltiples instancias de B
pero se ha de relacionar con una como mínimo
Cada instancia de B se pude relacionar con múltiples instancias de A
(cero, una o más de una)
1..* 0..* Cada instancia de A se puede relacionar con múltiples instancias de B
(cero, una o más de una)
Cada instancia de B se pude relacionar con múltiples instancias de A
pero se ha de relacionar con una como mínimo
1..* 1..* Cada instancia de A se puede relacionar con múltiples instancias de B
pero se ha de relacionar con una como mínimo
Cada instancia de B se pude relacionar con múltiples instancias de A
pero se ha de relacionar con una como mínimo

Podemos utilizar * en el caso que desconozcamos si hay un mínimo o no.

Enric Sesa i Nogueras 2

 MODELADO DE DATOS CON UML

Las asociaciones de muchos a muchos pueden tener atributos. Se trata de atributos que
no pertenecen a ninguna de las entidades asociadas sino a la propia asociación. Para
modelar esta situación se recurre al uso de pseudoentidades1 que recogen los atributos
de la asociación.

Estudiantes 0..* 1..* Asignaturas

cursar

cursar
+ nota : int

En el ejemplo gráfico anterior, la asociación “cursar” entre estudiantes y asignaturas

tiene un atributo (nota).

Asociaciones reflexivas

Cuando las ocurrencias de una entidad pueden relacionarse entre ellas decimos que se
da una asociación reflexiva

0..1
director
Empleado

dirigir

1..*
subordinado

En el ejemplo gráfico anterior, los empleados se relacionan entre ellos porqué algunos
empleados dirigen a otros empleados (un director puede tener uno o mas subordinados,
un empleado tiene, a lo sumo, un director).

Si es posible, daremos un nombre a cada uno de los roles, para facilitar la lectura del
modelo.

1
La palabra pseudoentidad para referirse a la entidad que recoge los atributos de una asociación es un
invento del autor. Algunas veces se le llama entidad asociativa (o asociación entitativa) pero este nombre
también se utiliza para referirse a otras construcciones de modelado. Para evitar conflictos, he decidido
usar pseudoentidad.

Enric Sesa i Nogueras 3

 MODELADO DE DATOS CON UML

Entidades débiles o dependientes

En algunos casos nos vamos a encontrar con entidades las instancias de las cuales no
pueden identificarse sólo con sus atributos sino que para hacerlo han de recurrir al
identificador de otra(s) instancia(s) de otra(s) entidad(es) con la(s) que están
relacionadas. A esas entidades las llamamos débiles o dependientes.

UML no dispone de una notación específica para representar entidades dependientes.

Dado que frecuentemente (pero no siempre) las dependencia es equiparable a la
agregación/composición, podemos utilizar la notación para esa situación (rombo al lado
de la entidad identificadota –no débil-)
Hoteles Habitaciones
1..1 tener 0..*
+ NOMBRE : + NUMERO :

En el ejemplo gráfico anterior (los hoteles tienen habitaciones, las habitaciones están en
los hoteles) habitaciones es una entidad dependiente de hoteles porque se quiere
modelar el hecho que una habitación no puede ser identificada sólo por su número en un
contexto en el cual hay más de un hotel. No basta con decir “habitación 108” hay que
ser más precisos e indicar, por ejemplo, “habitación 108 del hotel Princesa”

Si los mismos identificadores de hotel pudiesen ser utilizados en más de una ciudad,
tendríamos algo como:

Ciudades Hoteles Habitaciones

estar_en 1..1 tener 0..*
1..1
+ NOMBRE_C : + NOMBRE : + NUMERO :
0..*

(Ejemplo: me alojo en la habitación 108 del hotel Princesa de Córdoba)

En algunos casos, la dependencia puede serlo para con mas de una entidad

Estudiantes Vínculos Asignaturas

tener 1..* 1..1
+ NIF : + SEMESTRE : ser_con + NOMBRE :
1..1 + oyente? :
0..*
+ nota :

En el ejemplo anterior se quiere modelar el hecho que un estudiante se vincula cada

semestre con un determinado número de asignaturas y que cada semestre un
determinado número de estudiantes se vinculan con esa asignatura. Como puede darse
el caso que un estudiante haya de vincularse a una asignatura más de una vez, en
diferentes semestres, una asociación de muchos a muchos no basta.
Una asociación ternaria –estudiantes, semestres, asignaturas- también podría haber
modelado la misma situación, pero UML no dispone de tales asociaciones.

Enric Sesa i Nogueras 4

 MODELADO DE DATOS CON UML

Generalizaciones y especializaciones

La representación UML es la siguiente:

EntidadPadre

EntidadHija_1 EntidadHija_2

Es necesario documentar aparte si la generalización es

- completa o no
- disjunta o no (solapada)

Enric Sesa i Nogueras 5