ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

Modelado Conceptual

Esperanza Marcos
 Modelo Conceptual

Contenido
GUÍA DE ESTUDIO......................................................................................................................................... 3

1. EL MODELADO CONCEPTUAL DE DATOS EN EL PROCESO DE DESARROLLO SOFTWARE .................. 4

2. CONCEPTO DE MODELO DE DATOS .................................................................................................... 5

3. EL MODELO ENTIDAD/INTERRELACIÓN EXTENDIDO (E/R) ................................................................ 8

3.1. ENTIDAD .............................................................................................................................................. 8
3.2. INTERRELACIÓN...................................................................................................................................... 9
3.2.1. Elementos de una Interrelación............................................................................................... 10
3.2.2. Cardinalidad de una Entidad en una Interrelación .................................................................. 11
3.3. DOMINIO Y VALOR ................................................................................................................................ 12
3.4. ATRIBUTO ........................................................................................................................................... 13
3.5. GENERALIZACIÓN/ESPECIALIZACIÓN ......................................................................................................... 15
3.6. EJEMPLO ............................................................................................................................................ 18
4. ETAPAS DEL MODELADO CONCEPTUAL ............................................................................................ 19
4.1. ANÁLISIS DE REQUISITOS ........................................................................................................................ 19
4.2. ETAPA DE CONCEPTUALIZACIÓN............................................................................................................... 19
4.3. PASO DEL ESQUEMA PERCIBIDO AL ESQUEMA CONCEPTUAL ......................................................................... 21
5. EJERCICIOS DE AUTOCOMPROBACIÓN ............................................................................................. 24
5.1. ENUNCIADOS....................................................................................................................................... 24
6. BIBLIOGRAFÍA .................................................................................................................................... 27
6.1. BIBLIOGRAFÍA BÁSICA ........................................................................................................................... 27
6.2. BIBLIOGRAFÍA RECOMENDADA ................................................................................................................ 27

2
 Modelo Conceptual

Guía de Estudio

Podemos decir que el núcleo de todo Sistema de Información (en adelante SI)
orientado a la gestión está constituido por los datos del sistema, por lo que éstos son un
elemento clave en el proceso de desarrollo software. Si además estamos hablando de
desarrollo estructurado de software nos encontramos con que los datos forman el eje a
partir del cual se construye el sistema.
En esta unidad se abordará el problema del modelado conceptual de datos, dentro de
la fase de análisis del proceso de desarrollo software. El objetivo que nos planteamos es
que, al finalizar dicha asignatura, el alumno sea capaz de realizar el modelado conceptual
de datos de un SI.
Para ello, en primer lugar, situaremos las actividad del modelado conceptual de datos
en el lugar que les corresponde dentro del proceso de desarrollo, estableciendo las
relaciones existentes entre ésta y otras actividades. Posteriormente, revisaremos el
concepto de modelo de datos, pasando a continuación a exponer el modelo
Entidad/inteRrelación (en adelante E/R) como la técnica más aceptada de modelado de
datos en el desarrollo estructurado. Al final de la unidad se incluyen una serie de ejercicios
de autocomprobación con las soluciones propuestas. Es importante que el alumno tenga
en cuenta que las soluciones propuestas, en general, no serán únicas, especialmente en
los ejercicios de modelado conceptual. Por tanto, el alumno puede llegar a otras
soluciones alternativas que no serán necesariamente iguales a las que nosotros
proponemos. Finalmente se detalla la bibliografía que se ha divido en dos apartados:
bibliografía básica en la que nos hemos basado para desarrollar esta unidad y que, en
general, el alumno debería conocer; y bibliografía recomendada, constituida por libros
que también hemos consultado y que se recomienda a aquellos alumnos que deseen
profundizar o completar algún aspecto concreto de ésta unidad. La unidad contiene
también un control que permitirá evaluar los conocimientos adquiridos por el alumno al
final de la misma.
A modo de recomendación, y siempre que sea posible, el alumno debería contrastar
sus soluciones con las de otros alumnos. Esto permitirá discutir las distintas alternativas
analizando las ventajas e inconvenientes de cada una de ellas. Si esto no fuera posible, el
alumno dispone de una dirección de correo electrónico (cuca@escet.urjc.es) a la que
podrá enviar sus comentarios, dudas o sugerencias.

3
 Modelo Conceptual

1. El Modelado Conceptual de Datos en el Proceso de Desarrollo Software

El modelado conceptual permite describir, de un modo totalmente independiente de la
implementación, los datos que el usuario quiere recoger en el sistema. Dependiendo de la
cantidad de información que se desee representar, tendremos aplicaciones más o menos
orientadas a los datos. Así, por ejemplo, la gestión de una biblioteca es una aplicación
pura de Bases de Datos (en adelante BD) ya que prácticamente toda la funcionalidad del
sistema se centra en el mantenimiento de los datos (introducir un libro, prestar un libro,
etc.). Existen, sin embargo, otras aplicaciones, como por ejemplo un sistema de control de
navegación aérea, en las que los datos son algo secundario. Podemos decir que, en
general, los datos son el núcleo de todo SI orientado a la gestión.
El desarrollo estructurado de software, a diferencia de lo que ocurre en el desarrollo
orientado a objetos, mantiene una clara separación entre los datos y las funciones del
sistema. Por ello, es necesario disponer, en cada una de las etapas del proceso de
desarrollo, de técnicas específicas para la especificación de los datos, que serán diferentes
de las técnicas orientadas a la especificación de las funciones o procesos.
El modelado conceptual es una actividad que se realiza en la etapa de análisis,
paralelamente al modelado de procesos o funciones. Su objetivo, como ya hemos dicho,
es captar toda la información del mundo real que se desea representar en el mundo
informático. En este proceso es importante abstraer los detalles sin importancia y
representar tan sólo aquella información que sea relevante.
En este punto no nos interesa el cómo ni donde se va a implementar el sistema. De
hecho, dependiendo del tipo de sistema (más o menos orientado a los datos), del volumen
de información, de los requisitos de eficiencia, etc. se podrán utilizar distintos
mecanismos de persistencia de los datos: Sistemas de Bases de Datos, Sistemas de
Ficheros, etc. De estos aspectos nos ocuparemos en la etapa de diseño (ver la unidad
dedicada a diseño estructurado de datos). En esta etapa interesa recoger la máxima
cantidad de información posible, por lo necesitamos una técnica que cumpla los siguientes
requisitos:
 Ser independiente de los modelos o lenguajes de implementación
 Tener una capacidad semántica alta
 Ser lo mas cercana posible al usuario
Aunque existen diversas técnicas, utilizaremos el modelo E/R porque además de
cumplir los requisitos anteriores es la técnica de modelado conceptual universalmente
aceptada para el desarrollo estructurado.

4
 Modelo Conceptual

En la figura 1.1 se muestra la situación del modelado conceptual en el proceso de

desarrollo, así como la relación existente entre esta y otras actividades. La etapa de
análisis comprende, tanto el análisis de datos, modelado conceptual de datos, como el de
funciones. La técnica más habitual para el modelado conceptual de datos es el modelo E/R
y para el modelado conceptual de procesos son los Diagramas de Flujo de Datos (en
adelante DFD). Existen algunas técnicas, como el Diagrama de Historia de Vida de las
Entidades o la Matriz Entidad-Evento, que permiten integrar la visión de los datos y la de
los procesos. Como se puede apreciar, la etapa de diseño también se compone del diseño
de datos y del diseño de procesos.

DATOS FUNCIONES
Modelado Conceptual de DE
REQUISITOS Modelado
Datos: E/R Conceptual de Procesos: DFD
INFORMACIÓN
ANALISIS

Diseño de Datos: Relacional

DEDiseño de Procesos: DEC
DISEÑO REQUISITOS LOS PROCESOS

Figura 1.1. Comparación entre el proceso de diseño de datos y el de procesos

2. Concepto de Modelo de Datos

Un modelo puede definirse como la construcción mental a partir de la realidad en la
que se reproducen los principales componentes y relaciones del segmento de la realidad
analizada. Éste es, efectivamente, el significado de modelo en las ciencias empíricas en las
que, a fin de estudiar el comportamiento de una determinada parcela de la realidad, se
crea un modelo de ésta. Dicho modelo habrá de ser isomórfico respecto a la realidad que
representa y más simple que ésta, destacando sus principales características, o aquellas
que son relevantes para un determinado interés de estudio. Sin embargo, ésta no es la
única acepción del término modelo, al que podemos asignar dos significados:

5
 Modelo Conceptual

 Por un lado, el modelo entendido como una reproducción simplificada de la

realidad; este es el caso, ya expuesto, de las ciencias empíricas, en las que se
definen modelos de comportamiento simplificados de la parcela del mundo real
que es objeto de estudio;
 Y, por otro lado, el modelo entendido como la realidad propiamente dicha;
piénsese, por ejemplo, en un pintor, quien reproduce en lienzo a sus modelos;
en este segundo caso, el modelo no es la representación del mundo real, sino
que constituye el mundo real en sí mismo: es un modelo a copiar o a simular.
Esta segunda acepción de modelo es la que corresponde a la lógica matemática, donde
la representación recibe el nombre de teoría y lo representado el de modelo, mientras
que la primera corresponde, como ya hemos visto, al concepto de modelo en las ciencias
empíricas.
En algunos casos, como en el caso de los modelos de datos, el concepto de modelo
responde simultaneamente a estas dos acepciones. Quizá resulte esclarecedor el ejemplo
del arquitecto, para quien una maqueta es un modelo a copiar para la construcción de un
nuevo edificio. La maqueta sería, en un primer momento, la realidad puesto que el edificio
aún no existe. El arquitecto obtiene un nuevo edifio tomando dicha maqueta como
modelo. A partir de este momento, el edificio constituye la realidad, mientras que la
maqueta puede considerarse una copia del mismo.
En el ámbito de la bases de datos es muy común la utilización del término modelo de
datos, y existen diferentes definiciones del mismo en la literatura. Así, por ejemplo,
Dittrich define modelo de datos como "un conjunto de herramientas conceptuales para
describir la representación de la información en términos de datos. Los modelos de datos
comprenden aspectos relacionados con: estructuras y tipos de datos, operaciones y
restricciones".
Un modelo de datos permite representar una parcela de información del mundo real
de especial interés, lo que habitualmente se denomina universo del discurso o, en
términos, de Dittrich mini-mundo. La representación del universo del discurso se concibe
en dos niveles: el de la información en sí misma y el de las estructuras que hacen posible
la representación de tal información. Estos dos niveles dan lugar, en el ámbito de las bases
de datos, a la distinción entre esquema y base de datos, conceptos que Dittrich define
como sigue: "La descripción específica de de un determinado mini-mundo en términos de
un modelo de datos se denomina esquema (o esquema de datos) del mini-mundo. La
colección de datos que represntan la información a cerca del mini-mundo constituya la
base de datos".

6
 Modelo Conceptual

Sin embargo, el término modelo, debido a las diferentes acepciones del mismo, puede
dar lugar a ambigüedad y es importante tener en cuenta que en otros ámbitos diferentes
al de las bases de datos esta terminología puede variar. Así, por ejemplo, algunos autores
hablan de formalismos, en lugar de modelos, como marcos en los que definir esquemas, a
los que ellos se refieren como modelos. De este modo, en muchas ocasiones se habla de
modelos (modelos conceptuales, modelos de conocimiento, modelos lógicos, etc.) para
referirse indistintamente, tanto al modelo del universo del discurso (esquema) como al
formalismo en el que éste es definido (modelo de datos).
El problema deriva, de la doble acepción del término modelo. Podemos decir que un
esquema es un modelo (entendido como una copia simplificada de la realidad), y un
modelo (entendido como un original que se toma como referencia) si ese esquema se
implementa en un sistema informático. Por este motivo, podemos encontrar autores que
hablan de modelos para referirse a lo que nosotros denominaremos esquemas, o que se
refieran a los modelos como formalismos o técnicas. Por ejemplo, un DFD no es en sí
mismo un modelo, sino que suelen ser denominados técnicas, mientras que se denomina
modelo funcional, a la representación de la parte dinámica de un universo del discurso
utlizando la técnica de los DFDs.
Teniendo presente que esta terminología puede variar y que empleamos ésta por ser la
más extendida en el mundo de los “datos” en el que se centra la presente unidad,
definimos modelo de datos como un:

Conjunto de conceptos, reglas y convenciones

que permiten describir y manipular los datos
de la parcela del mundo real que constituye
nuestro universo del discurso.

Y esquema se datos como la:

Representación de un determinado universo

del discurso en términos de un modelo de

7
 Modelo Conceptual

3. El modelo Entidad/inteRrelación extendido (E/R)

El modelo E/R fue propuesto por Peter P. Chen en dos artículos ya históricos publicados
en 1976 y 1977. Permite al diseñador concebir los datos del sistema a un nivel superior de
abstracción, aislándolo de consideraciones relativas a la máquina y a los usuarios en
particular. El modelo, como su nombre indica, se apoya en dos conceptos: entidad e
interrelación1. Para Chen, una entidad es “una cosa que se puede identificar claramente”
y “una interrelación una vinculación entre entidades”.
Posteriormente otros muchos autores (ver a modo de ejemplo Elsmari et al. (1997)),
han investigado y escrito sobre el modelo, proponiendo importantes extensiones.
Realmente no se puede considerar que exista un único modelo E/R, sino más bien lo que
podríamos llamar una familia de modelos, por lo que hay importantes diferencias en la
presentación que del modelo hacen distintos autores. Nosotros nos basaremos en el
modelo expuesto en De Miguel et al. (1999) que incluye la mayoría de las extensiones que
se han ido aportando a lo largo del tiempo, así como algunas consideraciones e
interpretaciones propias.
En el modelo E/R, tal como fue propuesto por Chen, se distinguen los siguientes
elementos: Entidad, Interrelación, Dominio y Atributo. De entre las diversas extensiones
propuestas al modelo básico, consideraremos aquí la Generalización debido a su
importancia en el modelado conceptual debida, en parte, a que es un constructor básico
en el paradigma de la orientación a objetos.

3.1. Entidad
El mundo real se compone de una serie de objetos (reales o abstractos) acerca de los
cuales queremos obtener y representar información. En general dichos objetos podrán
agruparse en conjuntos de acuerdo a unas características comunes a todos aquellos que
forman parte de un mismo conjunto. Denominamos entidad a la abstracción que permite
representar aquellos objetos del mundo real que comparten una serie de características
comunes. Cada uno de los objetos concretos que pertenecen a la entidad es un ejemplar u
ocurrencia de entidad. Así, por ejemplo, DEPARTAMENTO es una entidad que permite
representar el conjunto de departamentos de los que se compone una empresa.
Ejemplares de la entidad DEPARTAMENTO podrían ser el departamento de ventas, de I+D,
de personal, de formación, etc. El conjunto de ejemplares de una entidad en un momento
dado será la extensión de ese tipo de entidad.

1
Hemos traducido por interrelación el término inglés “relationship” a fin de distinguirlo de la relación del modelo relacional que, en
inglés, se denomina “relation”. El término asociación lo utilizaremos para referirnos al caso general de conexión entre objetos, dejando
interrelación para expresar la asociación en el modelo E/R.

8
 Modelo Conceptual

La representación gráfica de una entidad es un rectángulo etiquetado en cuyo interior

está el nombre del tipo de entidad. La figura 3.1 muestra la representación de las
entidades DEPARTAMENTO y EMPLEADO.

DEPARTAMENTO EMPLEADO

Figura 3.1. Representación de entidades

Existen dos clases de entidades: regulares, que son aquellas cuyos ejemplares tienen
existencia por sí mismos (como DEPARTAMENTO y EMPLEADO), y débiles, en las cuales la
existencia de un ejemplar depende de que exista un cierto ejemplar de otro tipo de
entidad. Por ejemplo, la entidad HIJO es una entidad débil que depende de EMPLEADO, ya
que a la empresa tan sólo le interesa información de los hijos de sus empleados, del tal
modo que la desaparición de un determinado empleado hace que desaparezcan también
los hijos de éste. Las entidades débiles se representan con dos rectángulos concéntricos
con su nombre en el interior, como se ve en la figura 3.2.

HIJO

Figura 3.2.- Representación de una entidad débil

3.2. Interrelación
Se entiende por interrelación una asociación, vinculación o correspondencia entre
entidades. Cada asociación o vinculación que se establece entre ejemplares concretos de
las entidades que intervienen en una interrelación se denomina ejemplar u ocurrencia de
interrelación. Por ejemplo, Pertenece es una interrelación que vincula las entidades
DEPARTAMENTO y EMPLEADO; un ejemplar de la interrelación Pertenece es la vinculación
entre el departamento de “formación” y la empleada “B. Vela”.
Representaremos la interrelación mediante un rombo etiquetado con un nombre,
unido mediante arcos a los tipos de entidad que asocia, como se ve en la figura 3.3, en
donde establecemos la interrelación Pertenece entre DEPARTAMENTO y EMPLEADO.
Entre dos entidades puede existir más de una interrelación.

9
 Modelo Conceptual

DEPARTAMENTO Imparte EMPLEADO

Figura 3.3.- Representación de la relación Imparte

3.2.1. Elementos de una Interrelación

En un tipo de interrelación se pueden distinguir los siguientes elementos:
a) Nombre: al igual que las entidades, los dominios y los atributos, cada interrelación
tiene un nombre que lo distingue unívocamente del resto, y mediante el cual ha de
ser referenciado.
b) Grado: es el número de entidades que participan en una interrelación. Así, una
interrelación es de grado 2 (o binaria) cuando asocia dos entidad (ver, por ejemplo,
figura 3.3). Un caso particular de interrelaciones de grado 2 son las interrelaciones
reflexivas, las cuales asocian una entidad consigo misma; en la figura 3.4 se muestra
la interrelación reflexiva Consta que asocia PROYECTO con PROYECTO, y que refleja la
posibilidad de que un cierto proyecto (por ejemplo, gestión de un hospital) esté
compuesto por (sub)proyectos (por ejemplo, gestión de personal, gestión de
historiales clínicos, etc.). Pueden existir también interrelaciones que asocien más de
dos entidades (interrelaciones n-arias). Las interrelaciones nárias, siendo n>2, más
frecuentes son las de grado 3 y reciben el nombre de interrelaciones ternárias.

PROYECTO

Consta

Figura 3.4. Ejemplo de interrelación reflexiva

10
 Modelo Conceptual

c) Tipo de correspondencia: es el número máximo de ejemplares de una entidad que

pueden estar asociados, en una determinada interrelación, con un ejemplar de
otra(s) entidad(es); para representarlo gráficamente, bien se pone una etiqueta con
1:1, 1:N o N:M l lado de la interrelación, o bien se orienta el arco de unión en el
sentido 1 a N mediante una punta de flecha, tal como aparece en la figura 3.5,
donde se han incluido ambos tipos de representación en tres ejemplos de tipos de
interrelación.
d) Papel (“rol”): es la función que cada una de las entidades realiza en la interrelación;
se representa poniendo el nombre del papel en el arco que une cada entidad con
interrelación (ver figura 3.5). Siempre que no exista ambigüedad se suele prescindir
de representar el papel.

PROYECTO DEPARTAMENTO PROYECTO

Coordina Se_compone_de Trabaja_en

Dirige 1:1 Pertenece 1:N Participa N:M

Es_cordinado_por Está_adscrito_a Es_realizado_por

EMPLEADO EMPLEADO EMPLEADO

Figura 3.5. Ejemplos e interrelación uno a uno (1:1), uno a muchos (1:N), y muchos a muchos
(N:N) y roles

3.2.2. Cardinalidad de una Entidad en una Interrelación

Se define como el número máximo y mínimo de ejemplares de una entidad que pueden
estar interrelacionadas con un ejemplar de la otra, u otras entidades que participan en la
interrelación. Se representa gráficamente añadiendo una etiqueta del tipo (0,1), (1,1), (0,n)
ó (1,n), según corresponda, al lado de las entidades asociados por la interrelación, tal como
aparece en la figura 3.6. Las cardinalidades máximas coinciden con el tipo de
correspondencia.

11
 Modelo Conceptual

1:N
DEPARTAMENTO Pertenece EMPLEADO
(1,1) (0,n)

Figura 3.6. Ejemplo de interrelación en la que aparecen las cardinalidades

En la figura 3.7 se muestran algunos ejemplares de la interrelación Pertenece entre

DEPARTAMENTO y EMPLEADO, en la que se ha supuesto que pueden existir departamentos
que (por estar recién creados) no tienen ningún empleado y que todo empleado tiene que
pertenecer siempre a un único departamento.

Pertenece (DEPARTAMENTO(1,1):EMPLEADO(0,n))
DEPARTAMENTO (1,1) EMPLEADO (0,n)

Figura 3.7. Representación de ejemplares de la interrelación Pertenece

3.3. Dominio y valor

Las distintas propiedades o características de una entidad o de una interrelación toman
valores para cada ejemplar de éstas. El conjunto de posibles valores que puede tomar una
cierta característica se denomina dominio. Se define dominio como un conjunto de
valores homogéneos con un nombre. Para saber si un valor pertenece a un dominio
determinado, comprobaremos que cumple el predicado que el dominio lleva siempre
asociado.

12
 Modelo Conceptual

Por ejemplo, el valor “formación” se toma del dominio Nombre_departamento, y

cumple el predicado de ser uno de los departamentos posibles del conjunto {“ventas”,
“I+D”, “personal”, “formación”, “desarrollo”}; el dominio Nombre_empleado es una tira
de caracteres. Un dominio puede definirse por intensión, especificando el tipo de datos
(por ejemplo, carácter (30) para el Nombre_empleado o fecha para la Fecha_alta); o por
extensión, declarando el valor de cada elemento del dominio (como es el caso de
Nombre_departamento).

3.4. Atributo
Cada una de las propiedades o características que tiene una entidad o una interrelación
se denomina atributo; los atributos toman valores de uno o varios dominios. Por tanto,
podemos decir que el atributo le da una determinada interpretación al dominio (o a los
dominios) en el contexto de un tipo de entidad o de un tipo de interrelación. El atributo se
representa gráficamente con un círculo u óvalo etiquetado con su nombre (ver figura 3.8)
y unido mediante un arco a la entidad o a la interrelación correspondiente.

Nombre_ Nombre_
departamento departamento

Figura 3.8. Dos formas de representación de un atributo

Por simplicidad, en el esquema conceptual resultante del modelado sólo

especificaremos los atributos más significativos; en la figura 3.9. se representa las
entidades DEPARTAMENTO y EMPLEADO y la interrelación Pertenece con alguno de sus
atributos.
Nombre_dep
DEPARTAMENTO
Codigo_dep

Pertenece Fecha_alta

Fecha_nac
Nombre_emp
EMPLEADO
DNI

Figura 3.9. Representación de atributos de entidades y de interrelación

13
 Modelo Conceptual

La existencia de un atributo está ligada a la de la correspondiente entidad. Así la fecha

de nacimiento de un empleado (Fecha_Nac) no tiene sentido si de nuestro esquema
desaparece el tipo de entidad EMPLEADO; sin embargo, el dominio Fechas puede existir
con independencia de cualquier otra entidad.
El modelo E/R admite atributos compuestos, es decir, atributos definidos sobre más de
un dominio; por ejemplo, el atributo Fecha_Nac de la entidad EMPLEADO puede estar
definido sobre los dominios Día, Mes, y Año. En la figura 3.10 se muestran dos formas de
representar los atributos compuestos.

Día
EMPLEADO Mes
Fecha_nac Año

EMPLEADO Día
Mes
Año

Fecha_nac

Figura 3.10. Dos formas de representar atributos compuestos

El modelo E/R permite también atributos multivaluados. En general un atributo toma,

para cada ejemplar de entidad, un único valor de cada dominio (o dominios)
subyacente(s) (un empleado tiene un único nombre, un único DNI, etc.), pero también
existen atributos que pueden tomar más de un valor (por ejemplo, un empleado puede
tener varios números de teléfono). Estos atributos, que pueden tomar varios valores,
reciben el nombre de multivaluados frente a los univaluados que toman un solo valor. En
la figura 3.11 se muestra, mediante el ejemplo de los teléfonos, una forma de representar
los atributos multivaluados.

14
 Modelo Conceptual

Fecha_nac
EMPLEADO
Nombre_emp
DNI
Teléfono

Figura 3.12. Ejemplo de atributo multivaluado (Teléfono)

Entre todos los atributos de una entidad han de existir uno o varios (simples y/o
compuestos) que identifiquen unívocamente cada una de los ejemplares de esa entidad.
Cada uno de estos conjuntos de atributos se denomina Identificador Candidato (IC).
Cuando un IC es compuesto, el número de los atributos que lo componen debe ser
mínimo, en el sentido de que la eliminación de cualquiera de ellos le haría perder su
carácter identificador. Luego todo IC debe cumplir la condición de ser unívoco y mínimo.
Entre los IC se elige uno como Identificador Principal (IP) y el resto serán Identificadores
Alternativos (IA). El atributo IP se puede representar de cualquirea de los dos modos que
se muestran en la figura 3.13. Los identificadores principales compuestos se pueden
representar de forma análoga a la de los atributos compuestos.

EMPLEADO DNI

EMPLEADO DNI

Figura 3.13. Representación gráfica de IP y IA

3.5. Generalización/Especialización
En el modelo E/R básico propuesto por Chen no se encontraba este tipo de abstracción
que fue introducido en posteriores extensiones del modelo. La jerarquía de
generalización/especialización, en el modelo E/R, se considera como un caso especial de
asociación entre varias entidades (subtipos) y una entidad más general (supertipo) cuyas

15
 Modelo Conceptual

características son comunes a todos los subtipos. La asociación que se establece entre los
subtipos y el supertipo corresponde a la noción de es_un (IS_A, en inglés).
Aunque existen distintas convenciones para representar estas jerarquías de
generalización/especialización, nosotros utilizamos un triángulo cuya base es paralela al
rectángulo que representa la entidad del supertipo al cuál está conectado; triangulo que
también se une a los subtipos, tal como se muestra en la figura 3.14.

EMPLEADO SUPERTIPO
(1,1)
Es_un
(0,1) (0,1)
ANALISTA PROGRAMADOR

SUBTIPOS

Figura 3.14. Ejemplo de jerarquía de supertipo/subtipos

Esta clase de asociación tiene la característica de que todo ejemplar de un subtipo es

también un ejemplar del supertipo, aunque no sucede lo contrario, con lo que las
cardinalidades serán siempre (1,1) en el supertipo y (0,1) en los subtipos.
La aparición de estas jerarquías, en el modelado de datos, puede surgir de dos formas
distintas:
a) Generalización. Se observa que dos o más entidades comparten varios atributos y/o
interrelaciones, de donde se deduce la existencia de una entidad de nivel superior
(supertipo) que contiene los atributos y las interrelaciones comunes a todos los
subtipos.
b) Especialización. Se observa que una entidad tiene ciertos atributos y/o
interrelaciones que tienen sentido para unos ejemplares pero no para otros, por lo
que es conveniente definir uno o varios subtipos que contengan estos atributos y/o
interrelaciones específicos, dejando en el supertipo los que son comunes.
Por tanto, si nos movemos de los subtipos hacia el supertipo, se trata de una
generalización; mientras que si primero identificamos el supertipo y, a partir de él, llegamos
a los subtipos, se trata de una especialización.

16
 Modelo Conceptual

Puede ocurrir que se formen, por generalización y/o especialización, jerarquías a más de
un nivel donde un subtipo es, a su vez, supertipo de otros.
Otra característica muy importante de esta clase de asociación es la herencia, ya que,
todo atributo, o interrelación, del supertipo pasa a ser un atributo, o interrelación, de los
subtipos; por ejemplo, en la jerarquía de la figura 3.14 tanto los analistas como los
programadores son empleados, por lo que heredarán todos los atributos de la entidad
EMPLEADO (DNI, Nombre, Dirección, etc.).
En este tipo de abstracción los atributos comunes a todos los subtipos (incluidos los
identificadores) se asignan al supertipo, mientras que los atributos específicos se asocian al
subtipo al cual pertenecen. Del mismo modo, las interrelaciones que afectan a todos los
subtipos se asocian al supertipo, dejándose para los subtipos las interrelaciones específicas
en las que sólo participa el correspondiente subtipo.
La división en subtipos (especialización) puede venir determinada por una condición
predefinida (por ejemplo, en función de los valores de un atributo) en cuyo caso se
representará la condición (o el atributo discriminante) asociada al triángulo que representa
la interrelación.
Atendiendo a si los subtipos se solapan o son disjuntos, y a si la unión de los subtipos
recubre o no al supertipo se pueden distinguir cuatro clases de generalización. Si un mismo
ejemplar del supertipo puede pertenecer a más de un subtipo habrá solapamiento y si sólo
puede pertenecer a uno de los subtipos existirá exclusividad; por otro lado, si todo ejemplar
del supertipo tiene que pertenecer a algún subtipo tendremos totalidad y si, por el
contrario, no tiene obligatoriamente que pertenecer a algún subtipo habrá parcialidad.
La combinación de estas posibilidades da lugar a cuatro tipos de jerarquías, donde
representaremos por un arco el hecho de que los subtipos sean disjuntos y con un círculo la
presencia de una jerarquía total, como puede observarse en la figura 3.15, en la cual se
presenta una jerarquía total de subtipos disjuntos, ya que:
 Tanto un analista como un programador son empleados (jerarquía de
generalización)
 Los empleados con título de licenciado o ingeniero tienen categoría de analistas
mientras que los diplomados o ingenieros técnicos tienen categoría de
programadores. Un mismo empleado no puede ser a la vez analista y
programador (exclusividad)
 Todo empleado tiene que ser obligatoriamente un analista o un programador
(totalidad)

17
 Modelo Conceptual

EMPLEADO SUPERTIPO
(1,1)

Es_un Título

(0,1) (0,1)

ANALISTA PROGRAMADOR SUBTIPOS

Figura 3.15. Ejemplo de jerarquía total sin solapamiento

3.6. Ejemplo
A continuación, figura 3.16, representamos en el modelo E/R el esquema conceptual
completo que hemos utilizado a lo largo de la explicación. En el se muestran dos
interrelaciones (una 1:N y otra N:M) con sus cardinalidades, los atributos identificadores
pricipales (AIP) de cada una de las entidades así como los atributos de las interrelaciones.

DEPARTAMENTO Codigo_dep
(1,1)

1:N Pertenece Fecha_alta

1:N Codigo_proy
DNI
(0,n) N:M
(1,n) (0,n)
EMPLEADO Participaa PROYECTO

Figura 3.16. Ejemplo de esquema conceptual en el modelo E/R

18
 Modelo Conceptual

4. Etapas del Modelado Conceptual

El modelado conceptual, también denominado diseño conceptual, puede subdividirse
en dos etapas claramente diferenciadas:

4.1. Análisis de requisitos

Esta primera etapa, en general común para datos y procesos, es la etapa de
percepción, identificación y descripción de los fenómenos del mundo real a analizar. En el
análisis de requisitos se ha de responder a la pregunta: “¿Qué representar?”.
Mediante el estudio de las reglas de una empresa (que proveen el marco para el
análisis del sistema) y de entrevistas a los usuarios de los diferentes niveles de la
organización (que proveen los detalles sobre los datos) se llega a elaborar un esquema
descriptivo de la realidad. Aunque son varias las propuestas existentes respecto a la forma
de expresar el esquema descriptivo, en general se utiliza el lenguaje natural para recoger
esta primera información.
Uno de los problemas más importantes con los que nos enfrentamos en esta etapa es
la dificultad de comunicación entre los usuarios y los analistas. Los problemas que
presenta esta primera especificación se irán solucionando a lo largo del resto de las etapas
de diseño de modo que este primer esquema percibido se irá refinando hasta llegar a un
esquema más correcto: el esquema conceptual.

4.2. Etapa de conceptualización

En la etapa de conceptualizción se transforma este primer esquema descriptivo,
refinándolo y estructurándolo adecuadamente. Esta etapa responde a la pregunta:
“¿Cómo representar?”. En la Figura 4.1 se recoge el proceso de modelado conceptual,
distinguiéndose las dos etapas, así como los distintos procesos que hay que realizar para
pasar del mundo real al esquema descriptivo, y de éste al esquema conceptual.

19
 Modelo Conceptual

PROBLEMA A MUNDO ETAPA:

RESOLVER REAL

PERCEPCION
ANALISIS DE LOS
¿Qué representar? REQUISITOS
ANALISIS
(DESCRIPCION DEL
DESCRIPCION MUNDO REAL)

ESQUEMA
DESCRIPTIVO

CONCEPTUALIZACION
TRANSFORMACION
¿Cómo representar? (REPRESENTACION
REFINAMIENTO NORMALIZADA DEL
ESQUEMA DESCRIPTIVO)

ESQUEMA
CONCEPTUAL

Figura 4.1. Proceso de modelización conceptual

En esta etapa de conceptualización se habrá de buscar una representación normalizada

que se apoye en un modelo de datos que cumpla determinadas propiedades, a saber:
coherencia, plenitud, no redundancia, simplicidad, fidelidad, etc., para llegar así al
denominado esquema conceptual. Un modelo de datos que cumple tales requisitos es el
modelo E/R. Una característica importante del esquema conceptual es que no debe
describir los aspectos ligados a la implementación, sino que debe permitir ver la
información con todo su contenido semántico.
En el proceso de modelado conceptual se parte del análisis del universo del discurso (lo
que también podría denominarse realidad empresarial), analizando los listados, pantallas,
normativas, etc. y realizando un conjunto de entrevistas a varios niveles de la empresa.
Posteriormente se elabora un esquema percibido, expresado en lenguaje natural, que nos
facilita la obtención del esquema conceptual, esto es, delimita qué entidades, atributos,
interrelaciones y restricciones semánticas vamos a considerar. Este proceso se realiza de
forma iterativa hasta que se introducen y clasifican todos los objetos del universo del
discurso de forma satisfactoria.

20
 Modelo Conceptual

4.3. Paso del Esquema Percibido al Esquema Conceptual

Como hemos señalado, de la primera subfase de la etapa de modelado conceptual se
obtiene un esquema percibido en lenguaje natural que representa los requisitos del
sistema a diseñar. Posteriormente, este esquema se irá refinando sucesivamente y
normalizando hasta obtener un esquema en el modelo E/R. Será preciso, por tanto,
interpretar las frases del lenguaje natural en el que está descrito el esquema percibido,
convirtiéndolas en elementos del modelo E/R (entidades, atributos e interrelaciones).
Si bien no existen reglas deterministas que nos digan qué elemento va a ser una
entidad o cuál otro una interrelación, sí podemos enunciar unos principios generales que,
junto al buen criterio del diseñador, puedan ayudarnos a elaborar un primer esquema
conceptual, que será sometido después a un proceso de refinamientos sucesivos.
En el enfoque lingüístico Chen, se proponen un conjunto de heurísticas que tienen en
cuenta tanto la estructura de las oraciones como los atributos gramaticales de las
palabras. El objetivo de estas recomendaciones es depender menos de la intuición de los
diseñadores y más de métodos estructurados. Chen presenta 11 heurísticas (no reglas, ya
que para cada una de ellas se pueden encontrar contra ejemplos). Destacamos las más
relavantes:
 Un substantivo (nombre común) que actúa como sujeto o complemento directo en
una frase es, en general, una entidad, aunque podría ser un atributo. Por ejemplo,
en la frase “Los departamentos solicitan empleados”, existen dos posibles
entidades: DEPARTAMENTO (substantivo que actúa como sujeto) y EMPLEADO
(que actúa como complemento directo).
 Los nombres propios nos suelen indicar ejemplares de una entidad; por ejemplo,
“Vela, B.” indica un ejemplar de EMPLEADO.
 Un verbo transitivo o una frase verbal es una interrelación; por ejemplo, en la
frase anterior “solicitar” indica una interrelación entre las dos entidades,
DEPARTAMENTO y EMPLEADO.
 Una preposición o frase preposicional entre dos nombres suele ser una
interrelación, o también puede establecer la asociación entre una entidad y sus
atributos. Por ejemplo, al decir, “el área del departamento”, podemos estar
indicando la interrelación entre las entidades DEPARTAMENTO y AREA, o bien
podemos estar asociando el atributo área a la entidad DEPARTAMENTO.

21
 Modelo Conceptual

El estudio de las frases que definen los requisitos del sistema permite ir clasificando los
distintos objetos. Existen dos verbos, muy comunes en la especificación de los requisitos,
que presentan un especial interés: ser y tener.
1) “ES UN” nos permite, como ya hemos visto, crear jerarquías de entidades, ya que
corresponde al concepto de generalización. Por ejemplo, dada la frase: “...tanto un
analista como un programador son empleados...”, podemos establecer una
generalización como la que representamos en la figura 3.13.
2) “TIENE” es un verbo sobreutilizado en castellano ya que posee múltiples
interpretaciones. Según la acepción del verbo en la correspondiente frase, puede
corresponder a:
a) Una interrelación general entre entidades: en cuyo caso el verbo se utiliza
como otro cualquiera, sin una acepción específica; por ejemplo, “...los
empleados tiene un jefe...”, indica una interrelación entre las entidades
EMPLEADO y JEFE. En esta frase, tener actúa de forma totalmente análoga
a cualquier verbo transitivo, y podría ser sustituido, por ejemplo, por
asignar.
b) Una asociación de las entidades con sus atributos; por ejemplo, si decimos
que “...los empleados tienen nombre y apellidos, un DNI, una dirección y un
teléfono...”, estamos asociando a la entidad EMPLEADO una serie de
atributos: nombre, apellidos, DNI, dirección, teléfono.
Existen otros aspectos a tener en cuenta, entre los que cabe destacar que, del número
de las entidades (singular/plural) puede deducirse ciertos tipos, cardinalidades y grados de
las interrelaciones; así, si decimos “...un empleado participa en uno o varios proyectos... y
...en un proyecto participan varios empleados...” podemos deducir que la interrelación es
de tipo N:M, y de grado 2.
Dijimos al comienzo de este apartado lo difícil que puede resultar la categorización de
los objetos del universo del discurso. Hemos visto, sin embargo, unos principios generales
que pueden servirnos como guía en este proceso, aunque siguen subsistiendo problemas
y ambigüedades, como la distinción entre atributo y entidad, que no siempre resulta clara
del análisis lexicográfico del esquema percibido. A continuación resumimos algunas
consideraciones que nos pueden ayudar a decidir si un determinado objeto de datos debe
ser representado como un atributo, o como entidad interrelacionada con la entidad de la
que se supone que podría ser atributo.

22
 Modelo Conceptual

Es preferible considerar el objeto de datos como entidad, en lugar de como atributo, en

los siguientes casos:
 Si el objeto de datos tiene asociados otros atributos. Por ejemplo, si las áreas de
un departamento (que considerábamos un atributo de DEPARTAMENTO) tiene a
su vez otros atributos, como responsable de área, tareas asignadas al área, fecha
de creación, etc.), conviene crear la entidad AREA.
 Si el objeto de datos estuviese relacionado con otras entidades. Por ejemplo, si el
área la hubiéramos considerado como un atributo de DEPARTAMENTO, no
podríamos reflejar las posibles interrelaciones existentes entre las áreas y los
empleados (por ejemplo, no se podría especificar que empleados pertenecen a un
área concreta).

Un mismo atributo no puede aparecer en distintas entidades de datos y si esto

ocurriera debemos plantearnos la existencia de una interrelación no identificada entre
dichas entidades.
Estas reglas que acabamos de exponer pueden servirnos de ayuda en el paso del
esquema percibido al conceptual. Sin embargo, no se debe olvidar que se trata de un
proceso iterativo, y que sólo mediante refinamientos sucesivos, a lo que nos ayudará la
crítica constructiva de los usuarios, podremos llegar a un esquema conceptual que refleje
lo más fielmente posible la estructura de la información de la empresa u organización.

23
 Modelo Conceptual

5. Ejercicios de Autocomprobación

5.1. Enunciados
1. ¿En que etapa del proceso de desarrollo se encuentra el modelado conceptual de
datos?
2. ¿Qué es el universo del discurso?
3. Explique con sus palabras el concepto de modelo de datos, dentro del contexto del
modelado conceptual de datos.
4. ¿Qué entendemos por esquema conceptual de datos?
5. Brevemente, explique cuales son los objetivos del modelado conceptual de datos.
6. Describa las características deseables para un modelo conceptual de datos.
7. Enumere los elementos básicos del modelo E/R.
8. ¿Qué es un atributo identificador principal (AIP)?. Cite un ejemplo.
9. Defina los conceptos de entidad regular y entidad débil.
10. ¿Qué etapas pueden distinguirse en el modelado conceptual de datos? Describa
brevemente en qué consiste cada una de ellas.
Supuestos
Para cada uno de los siguientes supuestos, se pide realizar el modelado conceptual de
datos utilizando el modelo E/R extendido. Suponemos que las entrevistas con los usuarios
ya han sido realizadas y por tanto estamos ya en la etapa de conceptualización. De la
etapa de análisis de requisitos se han obtenido las siguientes especificaciones de usuario:
S1. Basándose en el ejemplo de la figura 3.16, represente, en el modelo E/R, el
esquema resultante de aplicar las siguientes especificaciones de usuario:
 Un empleado puede ser, bien analista bien programador, pero nunca ambas
cosas a la vez.
 Todo proyecto tiene un único jefe, que deberá ser analista, y uno o varios
programadores asignados.
 Un analista puede ser jefe de un solo proyecto. Un programador puede
participar en varios proyectos simultáneamente.

24
 Modelo Conceptual

S2. La empresa de formación X, desea llevar un control informatizado de los cursos que
imparte así como de lo profesores que participan en dichos cursos. Para ello, nos han
dado las siguientes especificaciones:
 Cada curso, del que se desea conocer el título, el número de horas y el tema o
los temas que trata, se identifica por un código de cuso.
 Cada curso puede tener una serie de cursos cuyo realización previa es
obligatoria (prerrequisito) o recomendada.
 Cada curso se puede impartir una o varias veces, en diferentes fechas y en cada
edición del mismo pueden participar diferentes empleados.
 Los empleados, de los que se desea conocer su código de empleado, nombre,
DNI y fecha de antiguedad en la empresa, pueden impartir y recibir cursos pero
con la restricción de que en una mismo edición de un curso no pueden
participar como profesores y como alumnos.
S3. La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio,
emplear una base de datos para almacenar la información referente a las películas que
ofrece en alquiler. Esta información es la siguiente:
 Una película se caracteriza por su título, nacionalidad, productora y fecha (p.e.,
“Quo Vadis”, “Estados Unidos”, “M.G.M.”, 1955).
 En una película pueden participar varios actores (nombre, nacionalidad, sexo)
algunos de ellos como actores principales.
 Una película está dirigida por un director (nombre, nacionalidad).
 De cada película se dispone de uno o varios ejemplares diferenciados por un
número de ejemplar y caracterizados por su estado de conservación.
 Un ejemplar se puede encontrar alquilado a algún cliente (nombre, dirección,
teléfono). Se desea almacenar la fecha de comienzo del alquiler y la de
devolución.
 Cada socio puede alquilar como máximo 4 ejemplares.
 Un socio tiene que ser avalado por otro socio, que responda de él en caso de
tener problemas en el alquiler.
S4. La empresa Personal Quality desea incorporar en su política de contratación
criterios de calidad del personal basados en la medición de sus habilidades o
competencias personales.

25
 Modelo Conceptual

 La empresa desea medir las competencias intelectuales de todos sus

empleados y además desea conocer las competencias emocionales de sus
directivos (por ejemplo, la capacidad de trabajo en grupo, la motivación,
capacidad de liderazgo, etc.). De todas ellas se desea conocer: su código de
identificación, su nombre y su descripción. Además, para cada competencia
emocional se desea conocer, lo que se ha denominado el umbral; es decir, el
valor mínimo de cada competencia por debajo del cual ningún empleado podrá
ser directivo.
 Para llevar a cabo este estudio, Personal Quality ha contactado con el
Emotional Skill Center quien le ha proporcionado una batería de Test. Cada
competencia está asociada a un conjunto de test que permiten medirla. Un test
puede medir una única competencia. Cada Test se identifica por un nombre y
debe tener asociado un conjunto de preguntas, una plantilla para su corrección
así como el modo en que se deberán interpretar los resultados.
 Cada empleado se identifica por un código interno. Además se quiere conocer
el nombre, la dirección y un teléfono de contacto de cada empleado.

26
 Modelo Conceptual

6. Bibliografía

6.1. Bibliografía Básica

 Piattini, M., Marcos, E., Calero, C., Vela. B. Tecnología y Diseño de Bases de Datos. Ed.
Ra-ma, Madrid 2006.
Es el libro en el que nos hemos basado para la elaboración de esta documentación, por
lo que es un excelente complemento de la misma. Presenta, de un modo claro y
preciso, el modelo E/R así como las diferentes aproximaciones al modelado conceptual
de datos. Contiene además una colección de ejercicios de modelado conceptual,
algunos de ellos con soluciones, por lo que es también recomendable para aquellos
alumnos que deseen practicar más.

6.2. Bibliografía Recomendada

 Batini, C., Ceri, S., Navathe, S. Diseño Conceptual de Bases de Datos. Un enfoque de
entidades-interrelaciones. Addison Wesley Iberoamericana, 1994.
Aunque no se trata de un libro reciente (la versión original es de 1992), es uno de los
primeros libros en abordar el tema de diseño conceptual de datos. El enfoque de
Batini, Ceri y Navathe ha sido seguido por numerosos autores, por lo que se considera
una obra básica para el modelado conceptual utilizando el modelo E/R.
 Elsmari, R. y Navathe, S. B. Fundamentos de Sistemas de Bases de Datos. Addison-
Wesley Iberoamericana,5ª Ed. 2007.
Se trata de un libro de referencia obligado en el tema de bases de datos. Aunque no es
específico para diseño conceptual, también trata esta parte de un modo claro y
riguroso, siguiendo el enfoque E/R. Además, es un excelente complemento para el
alumno que quiera profundizar en la tecnología de BD

27