Parte I - Diseño Lógico Conceptual

UT2: DISEÑO DE BASES DE DATOS RELACIONALES.
DISEÑO CONCEPTUAL
Módulo: BASES DE DATOS
Curso: 2023-2024
INDICE DE CONTENIDOS
1. Introducción.
2. Modelos de datos.
3. Diseño de una base de datos.
4. Modelo Entidad Relación (MER)
4.1. Entidades.
4.2. Relaciones.
4.3. Grado y cardinalidad. Debilidad.
4.4. Atributos.
5. Modelo Entidad/Relación extendido.
5.1. Generalización y especialización.
5.2. Agregación.
Diseño de bases de datos relacionales. DAMEL
Diseño CONCEPTUAL 2023-24
1. Introducción
Gracias al modelo conceptual Entidad-Relación de Peter Chen (años setenta) podemos

representar el mundo real a través de una serie de símbolos y expresiones determinadas. El objetivo
de este modelo es simplificar el diseño de bases de datos partiendo de descripciones textuales de
la realidad y posteriormente serán los requisitos del sistema que como informáticos se debe
desarrollar. Esa representación debe ser una imagen fiel del comportamiento del mundo real.
Al ser un modelo conceptual, no está orientado a ningún sistema concreto: tipo de ordenador,
SGBD, sistema operativo…Tampoco tiene un objetivo informático claro, podría usarse para
explicarle a un empleado cualquiera el funcionamiento de cualquier proceso de una forma natural
y sencilla, por lo que debe ser un sistema de fácil compresión para personas sin conocimientos
informáticos.
2. Modelos de datos.
Un modelo de datos es una colección de conceptos para la descripción de los datos, las
relaciones entre ellos y las restricciones que deben cumplir. Un esquema es una descripción de
una base de datos mediante un modelo. Los modelos de datos se clasifican en:
 Modelos conceptuales: describen los datos en un alto nivel de abstracción, usando
entidades, atributos y relaciones. Son independientes de la base de datos a usar.
Ejemplos: modelo entidad-relación, modelo orientado a objetos.
 Modelos lógicos: representan los datos con estructuras de registros de varios tipos,
formados por campos. Son dependientes de la base de datos. Por ejemplo, el modelo
relacional, el de red, el jerárquico.
 Modelos físicos: describen cómo se almacenan los datos en cuanto al formato de los
registros, las estructuras de los ficheros y los métodos de acceso.
3. Diseño de una base de datos.
La creación de una base de datos es un proceso complejo que requiere tiempo. Un buen diseño
de nuestra base de datos nos va dar:
 Mayor rendimiento.
 Mejor velocidad de acceso a los datos.
 Eliminar las redundancias (repeticiones innecesarias de información)
 Eliminar la inconsistencia: como consecuencia de las redundancias, se pueden dar
registros duplicados con valores distintos lo que produce incoherencia.
 Mantener dependencias funcionales: muy importantes para mantener la lógica de los
datos.
Por tanto, y teniendo en cuenta los modelos de datos anteriormente explicados, el diseño de una
base de datos puede dividirse en las siguientes fases:
2 | 30
Fase I: Diseño Conceptual. Consiste en el estudio del problema a

resolver. Esto llevará implícito una toma de requisitos a través de
reuniones con el cliente que debe detallar las necesidades de
información que desea resolver. Con esta toma de requisitos, el
diseñador de la base de datos, debe obtener el esquema
conceptual usando un modelo conceptual. Nosotros realizaremos
esta fase del diseño mediante el modelo Entidad-Relación de
Peter Chen.
Fase II: Diseño lógico. Partiendo del diseño conceptual obtenido en la fase anterior, llegamos a un
diseño lógico. Transformamos las entidades y relaciones obtenidas del modelo anterior en tablas.
Además, se realiza en esta fase la toma de requisitos funcionales donde el usuario final describe los
tipos de operaciones que quieren llevar sobre los datos (informes, por ejemplo). Nosotros usaremos
el modelo Relacional. El resultado de esta fase (esquema relacional) no es comprensible por el usuario
final que no tiene conocimientos informáticos.
Fase III: Diseño físico. Este diseño si depende del ordenador. Se usa el gestor de la base de datos para
proceder a implementar las tablas y los objetos descritos en la fase anterior a través de instrucciones
del DDL (SQL).
4. Modelo Entidad-Relación.
El modelo Entidad/Relación (E/R) fue propuesto por Peter Chen en los años 70. Presenta una vista
unificada de los datos centrándose en la estructura lógica y abstracta de los mismos, como
representación del mundo real.
Inicialmente (en la propuesta de Chen) solo se incluían los conceptos de entidad, relación y
atributos. Después se añadieron otras propuestas como atributos compuestos, generalizaciones,
…que forman el llamado modelo entidad-relación extendido.
4.1.Elementos básicos.
Los elementos básicos son: entidades (E), relaciones (R) y atributos.
4.1.1. Entidades.
La entidad representa cualquier persona, suceso, evento o concepto sobre el que queremos
almacenar información.
Las entidades se representan con sustantivo dentro de un rectángulo, dentro del mismo situamos
el nombre de la entidad.
Ejemplos de entidad:
3 | 30
Las entidades cumplen las siguientes propiedades:

o Tienen existencia propia. Desde el punto de vista en el cual se estudia el sistema y al nivel de
abstracción en que es considerado, la entidad existe como un elemento que interviene en el
comportamiento global del sistema.
o Es diferente al resto de entidades del sistema.
o Todas las ocurrencias (elementos) de la entidad tienen las mismas características.
Dentro de las entidades distinguimos entre dos tipos:

Entidades fuertes: su existencia no depende de ninguna otra entidad. Se representa con el nombre
de la entidad encerrado dentro de un recuadro como las anteriores.
Entidades débiles: su existencia está condicionada a la aparición de otra entidad. Se representa
mediante un doble recuadro, encerrando el nombre de la entidad.
Por ejemplo: Para que exista una cuenta bancaria, es necesario que
exista otra entidad, en la que pondríamos titular, que es el beneficiario
de la misma. Si no hay ningún titular no existe la cuenta. Dicho de otra
forma, si eliminásemos el titular de la cuenta de nuestra base de datos,
nos veríamos obligados a borrar todas sus cuentas. Esto demuestra que
cuenta es una entidad débil que depende de titular.
4.1.2. Relaciones.
Las relaciones se representan con un verbo, dentro de un rombo. Las relaciones representan
asociaciones entre entidades.
compra
Podemos poner un pequeño ejemplo representado en este modelo: Supongamos que tenemos un
almacén, y lo queremos informatizar. Entonces tenemos dos entidades, por un lado, la entidad
CLIENTE, y por otro lado tenemos la entidad PRODUCTO. Entre los clientes y los productos del
almacén existe una relación, que hemos denominado compra.
4 | 30
4.1.2.1. Grado de una Relación.
El grado de una relación nos indica el número de entidades que asocia. Una interrelación puede
ser:
 Unaria: asocia una entidad consigo misma (de forma reflexiva).
 Binaria: Asocia dos entidades.
 Ternaria: Asocia 3 entidades.
 N_aria: Asocia n entidades, más de tres.
4.1.2.2. Cardinalidad de una Relación.
La Cardinalidad define la forma en que se relación las entidades e identifica el número de

ocurrencias máximas y mínimas de una entidad en una relación. Dicho de otra forma, el número de
instancias de cada entidad que pueden intervenir.
Distinguiremos entonces diferentes tipos de cardinalidad:
 1:1. uno a uno. Por cada ocurrencia de una entidad sólo puede aparecer uno de la entidad
asociada.
5 | 30
 1:N. uno a muchos. Por una ocurrencia de una entidad pueden aparecer muchas ocurrencias de
la entidad asociada.
 N:M. muchos a muchos. La cantidad de asociaciones de una entidad con otra es múltiple. Dicho
de otra forma: por cada ocurrencia de un tipo de entidad hay un número indefinido y mayor que
uno de ocurrencias en la otra y viceversa para el otro tipo de entidad.
La forma de representarlas es situar, encima del rombo que representa la asociación, su

correspondiente numeración.
Hay que aclarar que para representar correctamente la cardinalidad escribimos el número
mínimo y el número máximo de ocurrencias de la entidad en la relación, separados por 2 puntos,
y rodeados por paréntesis, (mínimo : máximo). Esto se verá más adelante con el modelo Entidad–
Relación extendido.
4.1.3. Atributos.
Los atributos almacenan las propiedades (las informaciones) que nos interesan de las entidades.
Los atributos aparecen encerrados dentro de una elipse, y conectados con la entidad o relación a la
que pertenecen mediante una línea.
El rango es el conjunto de valores que puede tomar cada atributo, en función del tipo de dato que
almacena.
Los atributos pueden ser de los siguientes tipos:

 Atributos obligatorios: Un atributo debe tomar un valor obligatoriamente.
 Atributos opcionales: Un atributo puede no tomar un valor porque sea desconocido en un
momento determinado. En este caso, el atributo tiene un valor nulo.
 Atributos compuestos: Un atributo compuesto es aquel que se puede descomponer en
atributos más sencillos, por ejemplo, el atributo hora_de_salida se puede descomponer en
dos (hora y minutos).
 Atributos univaluados: Un atributo que toma un único valor.
6 | 30
 Atributos multivaluados: Estos atributos pueden tomar varios valores, por ejemplo el
atributo teléfono puede tomar los valores de un teléfono móvil y un teléfono fijo.
 Atributo derivado: Son aquellos cuyo valor se puede calcular a través de otros atributos.
Por ejemplo, el atributo Edad, se puede calcular a partir de la fecha de nacimiento de una
persona.
Al igual que con la mayoría de las notaciones, no existe unanimidad a la hora de dibujar en
un diagrama los tipos de atributos. Una de las más extendidas entre los diseñadores de
bases de datos es la siguiente:
De entre todos los atributos, debemos seleccionar uno como campo clave, que haga que
la tupa sea diferente a todas las demás en el conjunto de la entidad.
Por ejemplo, la dirección de una persona nos da información sobre ella, pero su DNI la
identifica.
Existen distintos tipos de claves:

 Superclave: Identifican a una entidad (pueden ser o no mínimas). Por ejemplo, para un
empleado, las superclaves posibles son el DNI, o el DNI+Nombre, o el DNI+Nombre+Numero de
la Seguridad Social, etc.
 Clave candidata: Es la mínima Superclave. En el caso del empleado, nos quedaríamos con el DNI
y el Número de la seguridad social como claves candidatas. Claves candidatas, ¿a qué? Pues a
clave primaria (Primary KEY).
 Clave primaria: es la clave candidata por la que ha optado el diseñador de la base de datos. Una
entidad puede tener varias claves candidatas, pero sólo puede tener una clave primaria que es
la que elegimos como tal.
Para elegir la clave primaria existen varios criterios:
Se prefiere la clave numérica ante la alfanumérica.
La corta ante la larga.
La formada por un campo a la formada por varios campos.
 Clave foránea o ajena: sirve para establecer relaciones, es parte de la clave primaria de una
relación, y simultáneamente es clave primaria de otra entidad. Por ejemplo: si relacionamos un
7 | 30
socio con las películas que ha alquilado en la entidad Alquilan, debe aparecer la clave del socio,
que puede ser su número.
 Clave alternativa: son las claves candidatas por las que no ha optado el diseñador como claves
primarias.
Atendiendo a la cantidad de atributos que componen una clave las podemos clasificar en:
 Claves simples: la clave está formada por un solo atributo. Por ejemplo, en la entidad socio, el
número del socio es una clave simple.
 Claves compuestas: la clave está formada por más de un atributo. Por ejemplo: En Alquilan
tenemos como clave la calve de la entidad socio, más la clave de la entidad películas, más la
fecha de alquiler.
4.2. Modelo Entidad / Relación EXTENDIDO
El modelo inicial de Peter Chen resultaba algo limitado para representar ciertos aspectos en el
plano conceptual por lo que se realizaron “extensiones” que aportaran más significado y relevancia
a los diseños.
Vamos a ver qué aspectos se han mejorado.
4.2.1. Cardinalidad de un tipo de entidad (Participación)
Se define como el número máximo y mínimo de ocurrencias de una entidad que participan en
el tipo de relación.
Las cardinalidades de las entidades se define como el número máximo y mínimo de instancias
de una entidad que pueden estar relacionadas con una instancia de otra u otras entidades que
participan en la relación. Su representación gráfica es una etiqueta del tipo (0,1), (1,1), (0,N) o (1,
N), según corresponda. El significado de cada una es:
(0,1)  Para una ocurrencia determinada, en las otras entidades que participan en la relación
nos encontramos mínimo 0, máximo 1.
(1,1)  Para una ocurrencia determinada, en las otras entidades que participan en la relación
nos encontramos una y solo una.
(0,n)  Para una ocurrencia determinada, en las otras entidades que participan en la relación
nos encontramos 0 o N.
(1,n)  Para una ocurrencia determinada, en las otras entidades que participan en la relación
nos encontramos una como mínimo y N como máximo.
Ejemplo: imaginemos que queremos registrar la relación de empleados y los proyectos en los
que trabajan. Los requisitos nos especifican los siguiente:
“los empleados pueden trabajar para varios proyectos, o pueden estar de vacaciones
8 | 30
(sin proyecto). Por otro lado, en un proyecto pueden trabajar 1 o varios empleados”.
Para calcular la participación de cada entidad en la relación “ EMPLEADO TRABAJA EN

PROYECTO”, nos hacemos las siguientes preguntas.
¿Cuántos empleados trabajan en un proyecto?

Como mínimo 1, como máximo N.  Cardinalidad (1,n) en la parte del EMPLEADO.
¿En cuántos proyectos trabaja un empleado?

Según los requisitos, como mínimo 0, porque puede estar de vacaciones y no estar
asignado a ninguno y como máximo, N  Cardinalidad (0,n) en la parte de PROYECTO.
En base al modelo diseñado, podemos afirmar:

 “Por cada proyecto, habrá un empleado como mínimo y n como máximo”.
 “Cada empleado trabajará en 0 proyectos como mínimo y n como máximo”.
4.2.2. Cardinalidad de la Relación en el modelo Extendido.
La cardinalidad de una relación se calcula a través de las participaciones de sus ocurrencias en

ella. Se toman el número máximo de participaciones de cada una de las entidades en la relación.
Ejemplo:
En un supermercado hay productos organizados en categorías (frutas, ultramarinos, carnes,
pescados, etc.). Cada producto pertenece a una única categoría, y puede haber categorías que
todavía no tengan ningún producto asignado, sin embargo, no puede haber productos sin
categoría. Calcula las participaciones de cada entidad en la relación Producto Pertenece a
Categoría.
¿Cuántos productos pertenecen a una categoría? Mínimo 0, máximo n (0,n) en la parte de

PRODUCTOS.
¿A cuántas categorías puede pertenecer un producto? Mínimo 1, máximo 1, a solo una  (1,1)
en la parte de CATEGORÍA.
9 | 30
El resultado sería, por tanto:
La cardinalidad de la relación sería 1:N, puesto que, por el lado de las categorías, el máximo
de (1,1) es 1, y por el lado de los productos, el máximo de (0,n) es N.
Las cardinalidades en el modelo extendido siguen

siendo las mismas que en el modelo de Peter
Chen. Las recordamos con algunos ejemplos:
 Cardinalidad 1:1  Una ocurrencia de la

entidad A puede estar vinculada mediante
una relación a una y solo una ocurrencia de
otra entidad B y viceversa. La participación
en un extremo y otro puede ser:
 (0,1) – (0,1)
 (0,1) – (1,1)
 (1,1) – (1,1)
 Cardinalidad 1:N (o Muchos)  Una

ocurrencia de la entidad A puede estar
vinculada mediante una relación a varias
ocurrencias de otra entidad B. Sin embargo,
una de las ocurrencias de la entidad B solo
puede estar vinculada a una ocurrencia de
la entidad A. La participación que da lugar a
esta cardinalidad en un extremo y otro,
puede ser:
 (1,n) – (1,1)
 (0,n) – (1,1)
 (1,n) – (0,1)
 (0,n) – (0,1)
10 | 30
 Cardinalidad M:N (o Muchos:Muchos o

N:M)  esta cardinalidad especifica que
una ocurrencia de la entidad A puede estar
vinculada mediante una relación a varias
ocurrencias de la entidad B, y a su vez, una
ocurrencia de la entidad B puede estar
vinculada a varias de la entidad A. La
participación que da lugar a esta
cardinalidad en un extremo y otro, puede
ser:
 (1,n) – (1,n)
 (0,n) – (0,n)
 (1,n) – (0,n)
4.2.2.1 Cardinalidad de relaciones NO binarias
Para calcular la cardinalidad de una relación ternaria se tomará una de las tres entidades y se
combinan las otras dos. A continuación, se calcula la participación de la entidad en la combinación de
las otras dos. Posteriormente, se hará lo mismo con las otras dos entidades. Finalmente, tomando los
máximos de las participaciones se genera la cardinalidad de la relación.
En este ejemplo, se distinguen tres participaciones:

 Empresa y Expediente-Auditora.
 Auditora y Empresa-Expediente.
 Expedite y Empresa-Auditora.
NOTA: sabemos que una auditora se encarga de hacer inspecciones a las empresas. Estas
inspecciones se realizan basándose en un expediente. Nos dicen que,
11 | 30
 Un expediente solo puede ser supervisado por una auditora.

 La auditora puede llevar varios expedientes a la vez de otras empresas.
 Una empresa puede tener varias inspecciones abiertas (cuentas, trabajo…) lo que
generará varios expedientes.
Las preguntas que nos haremos serán las siguientes:
¿Cuántas empresas pueden tener un expediente con una auditora?

Puede tener un mínimo de 0 y un máximo de 1  Participación de Empresa (0,1).
¿Cuántos expedientes puede tener con una empresa con una auditora?
Puede tener un mínimo de 0 y un máximo de n  Participación de Expedientes (0,n).
¿Cuántas auditoras pueden auditar un expediente a una empresa?

Un mínimo de 1 y un máximo de 1  Participación de Auditoras (1,1).
4.2.2. Relaciones exclusivas
Cuando cada ocurrencia de un tipoi de entidad solo puede pertenecer a un tipo de relación y solo
a uno simultáneamente. Esto se representa mediante un semicírculo.
4.2.3. Entidades débiles
El modelo de Peter Chen, define el concepto de entidad y distingue entre entidades fuertes y
débiles atendiendo a la dependencia de existencia. Esta dependencia está muy ligada a la semántica
del problema: escritor escribe libro, tren tiene vagón, etc. ¿Qué sentido tiene el vagón si no tengo tren
el libro si no tengo escritor?
Existe otra dependencia que definen las entidades débiles que explicamos a continuación: la
dependencia de identificación.
Este tipo se produce cuando, además de la dependencia de existencia, la entidad débil
necesita a la fuerte para poder crear una clave, de tal manera que pueda completar la identificación
de sus ocurrencias. Según este principio, las entidades débiles estarían compuestas por:
 Un discriminador (o clave parcial o descriptor).
 Una clave primaria que se forma con la clave primaria de la entidad/es fuerte/s con la
que se relaciona y el discriminador.
12 | 30
Por ejemplo:
Imaginemos un banco que gestiona los pagos de un préstamo. La entidad Pago, en este caso,
es débil porque cumple los dos principios:
 De existencia, ¿Qué sentido tienen los pagos si previamente no hemos firmado un
préstamo?
 De identificación porque a cada pago se le identifica con un numero_pago, pero este
estará repetido tantas veces como préstamos haya. Es decir:
Préstamo 1  Pagos del 1 al 100.
El número de pago por tanto no identifica a los elementos dentro de pago.
En el modelo entidad/relación marcaremos estas entidades como débiles (cuando cumplen los
dos principios), el atributo que hace de discriminador irá punteado, no subrayado y la relación que le
une con la entidad que fuerte irá con doble contorno.
4.2.4. Generalización y especialización
Relación que existe entre un tipo de entidad (supertipo) y los tipos de entidad más específicos
(subtipos), en donde los atributos del supertipo son heredados por los subtipos.
La subdivisión es una necesidad bastante habitual en BD.
La generalización es el proceso contrario a la

especialización, es la manera en la que se deduce la
relación en función de los requisitos, en la manera que los
datos vayan apareciendo en el enunciado. Puede ser que
nos definan claramente el supertipo o superclase y a
medida que leemos, vamos identificando las subclases
con sus características especiales (especialización). Puede
ser que identifiquemos las hijas de forma independiente y
tras una lectura nos demos cuenta de la cantidad de datos
en común que contienen y decidamos abstraer esos datos
en una superclase (generalización).
Pero el resultado es el mismo, la construcción de una jerarquía. Se representa por un triángulo

invertido con la base paralela al supertipo.
13 | 30
4.2.4.1. Tipos de jerarquías

 Especialización Exclusiva: En este caso, cada una de las ocurrencias de la superclase solo puede
materializarse en una de las especializaciones. Por ejemplo, si un empleado es un directivo, no
puede ser un técnico o un comercial. Para representar esta especialización exclusiva, el
triángulo de la jerarquía lleva un arco.
 Especialización Inclusiva: Se produce cuando las ocurrencias de la superclase pueden

materializarse a la vez en varias ocurrencias de las subclases. En este caso, el empleado
directivo, podría ser también técnico y comercial.
 Especialización Total: Se produce cuando la entidad superclase tiene que materializarse

obligatoriamente en una de las especializaciones. Se representan añadiendo un pequeño
círculo al triángulo de la generalización:
 Especialización Parcial: La entidad superclase no tiene por qué materializarse en una de las
especializaciones (es opcional).
Por tanto: generalizaciones totales y exclusivas, totales y solapadas, parciales y exclusivas,

parciales y solapadas pueden ser las opciones que podemos tener a la hora de hacer una jerarquía.
14 | 30
Prueba a representar las siguientes jerarquías:

 Un concesionario de coches vende coches nuevos y usados. Los atributos específicos de los
nuevos son las: unidades y el descuento, de los usados son: los kilómetros y el año de fabricación.
 Consideramos el conjunto de personas de una ciudad, distinguimos a los trabajadores,
estudiantes y parados. De los trabajadores nos interesa el número de la seguridad social, la
empresa de trabajo y el salario. De los estudiantes el número de matrícula y el centro educativo,
y de los parados la fecha del paro.
 En un campo de fútbol los puestos de los futbolistas pueden ser: portero, defensa, medio y
delantero.
15 | 30
5. Construcción de diagramas Entidad / Relación
5.1.Recomendaciones para el diseño
1. Leer varias veces el problema hasta memorizarlo.
2. Obtener una lista inicial de candidatos a entidades, relaciones y atributos. Se realiza

siguiendo los siguientes consejos:
a. Identificar las entidades. Suelen ser aquellos nombres comunes que son
importantes para el desarrollo del problema. Por ejemplo, empleado, vehículo,
agencia, etc. En principio, todos los conceptos deberían estar perfectamente
especificados en el documento de requisitos, pero, de no existir el documento de
requisitos, quizá solo se disponga de extractos de conversaciones con usuarios en
las que se hacen referencias vagas a ciertos objetos, teniendo que hacer un
importante ejercicio de abstracción para poder distinguir si son entidades,
atributos, etc. Por ejemplo, un mecánico que tan solo habla de ciertos modelos de
vehículos pertenecientes a determinadas personas, pero que nunca hace referencia
a los vehículos Diesel que serán fundamentales identificar para el correcto diseño
de la base de datos.
b. No hay que obsesionarse en los primeros pasos por distinguir las entidades fuertes
de las débiles. Si es trivial, se toma nota de aquellas que parezcan claramente
entidades débiles. De lo contrario, se apuntan como entidades sin especificar si son
fuertes o débiles.
c. Extraer los atributos de cada entidad, identificando aquellos que pueden ser
clave. Se suelen distinguir por ser adjetivos asociados a un nombre común
seleccionadas como entidades. Por ejemplo, color, que es un adjetivo, puede ir
asociado a la entidad vehículo. Además, se debe establecer el tipo de atributo,
seleccionando si es opcional, obligatorio, multivaluado, compuesto o derivado. Si es
compuesto se indica su composición, y si es derivado, cómo se calcula. Es bastante
útil apuntar sinónimos utilizados para el atributo para eliminar redundancias.
d. Es fácil identificar las generalizaciones si se obtiene un atributo que es aplicable a

más de una entidad. En ese caso, se puede intentar aplicar una
generalización/especialización, indicando cuál es la superclase y cuál las subclases.
Además, se deben especificar los tipos de especialización (inclusiva, exclusiva,
parcial, total).
e. Identificar los atributos de cada relación. Se suelen distinguir, al igual que los de
entidad, por ser adjetivos, teniendo en cuenta que para que sean de relación, solo
deben ser aplicables a la relación y no a ninguna de las de las entidades
relacionadas.
16 | 30
f. También es posible que los nombres comunes contengan muy poca información y
no sea posible incluirlas como entidades. En este caso, se pueden seleccionar
como atributos de otra entidad, por ejemplo, el autor de un libro puede ser una
entidad, pero si solo se dispone del nombre del autor, no tiene sentido incluirlo
como una entidad con un único atributo. En este caso, se puede incluir como
atributo de la entidad Libro.
g. Extraer los dominios de los atributos. Siempre es buena práctica, ir apuntando,

aunque en el diagrama entidad relación no se exprese explícitamente, a qué
dominio pertenece cada atributo. Por ejemplo, el Salario pertenece a los números
reales (Salario: Reales), o el color de un objeto puede ser verde, amarillo o rojo
(Color; Verde, Amarillo, Rojo).
h. Identificar las relaciones. Se pueden ver extrayendo los verbos del texto del
problema. Las entidades relacionadas serán el sujeto y el predicado unidos por el
verbo que hace de relación. Por ejemplo, agente inmobiliario vende edificio. En este
caso el agente inmobiliario representaría una entidad el edificio la otra entidad y
'vende' sería la relación.
3. Averiguar las participaciones y cardinalidades. Generalmente se extraen del propio

enunciado del problema. Si no vienen especificadas, se elegirá la que almacene mayor
cantidad de información en la base de datos.
4. Poner todos los elementos listados en el paso 2 en un mapa y volver a considerar la
pertenencia de cada uno de los elementos listados a su categoría. Así, se replanteará de
nuevo si cierto atributo es una entidad, o si cierta entidad puede ser una relación, etc.
5. Refinar el diagrama hasta que se eliminen todas las incoherencias posibles, volviendo a
los pasos anteriores en caso de encontrar algún atasco mental o conceptos dudosos que
dificulten la continuación del análisis. Es bueno, en estas circunstancias discutir con
compañeros u otros expertos sobre el diseño realizado.
6. Si hay dudas sobre el enunciado o sobre los requisitos, o se han quedado algunas cosas en
el tintero, será necesario acudir al responsable del documento de requisitos o volver a
concertar una entrevista con el usuario para aclarar conceptos. En este caso, se aclararán
las dudas y se volverá al punto 2 para reiniciar el análisis.
5.2. Caso práctico resuelto
Se desea realizar el diagrama de estructuras de datos en el modelo E-R correspondiente al

siguiente enunciado:
“supongamos que en un centro escolar se imparten muchos cursos. Cada curso está formado por
un grupo de alumnos, de los cuales uno de ellos es el delegado del grupo. Los alumnos cursan
asignaturas, y una asignatura puede o no ser cursada por los alumnos”.
Seguimos los siguientes pasos:
17 | 30
1. Identificación de entidades: una entidad es un objeto del mundo real, algo que tiene interés
para la empresa, se hace un análisis del enunciado, de donde sacaremos los candidatos a
entidades: CENTROS, CURSOS, ALUMNOS, ASIGNATURAS, DELEGADOS.
Si analizamos esta última veremos que los delegados son alumnos, por lo tanto, el alumno “Lola
López King” estaría recogida en ALUMNOS al igual que el resto de delegados. Eliminamos por
tanto DELEGADOS.
Si analizamos CENTROS, también deberíamos eliminarla pues se trata de UN ÚNICO CENTRO.
Es decir, en nuestra entidad CENTROS solo tendríamos un elemento por ejemplo “IES RIBERA
DEL TAJO”. Si nos pidieran la gestión de diferentes centros tendría más sentido incluirla.
2. Identificar las relaciones: para ello es muy importante estudiar los requisitos del sistema de
información para poder identificar las relaciones que existen entre las entidades y el tipo de
relación que existe. Un método que nos puede ayudar mucho es construimos una matriz de
entidades en la que las filas y las columnas son los nombres de entidades y cada celda puede
contener o no la relación, las relaciones aparecen explícitamente en el enunciado. En este
ejemplo las relaciones no tienen atributos. Del enunciado sacamos lo siguiente:
 Un curso está formado por muchos alumnos, la relación entre estas dos entidades la
llamamos PERTENECE pues a un curso pertenecen muchos alumnos, relación 1:M.
Consideramos que es obligatorio que existan alumnos en un curso. Para calcular los
máximos y mínimos hacemos la pregunta: a un CURSO cuántos ALUMNOS pertenecen,
como mínimo y como máximo y se ponen los valores en la entidad ALUMNOS, en este caso
(1,M). Para el sentido contrario hacemos lo mismo, un ALUMNO, a cuántos CURSOS va a
pertenecer, como mínimo a 1, y como máximo a 1, en este caso pondremos (1,1) en la
entidad CURSOS.
 De los alumnos que pertenecen a un grupo uno de ellos es DELEGADO, hay una relación de
grado 1 entre la entidad ALUMNO que la podemos llamar ES DELEGADO. La relación es 1:M,
un alumno es delegado de muchos alumnos. Para calcular los valores máximos y mínimos
preguntamos: un ALUMNO de cuantos alumnos ES DELEGADO, como mínimo es 0, pues
puede que no sea delegado, y como máximo es M, pues si es delegado lo será de muchos,
pondremos en el extremo (0,M). Y en el otro extremo pondremos (1,1), pues
obligatoriamente el delegado es un alumno.
 Entre ALUMNOS y ASIGNATURAS surge una relación N:M, pues un alumno cursa muchas
asignaturas y una asignatura es cursada por muchos alumnos. La relación se llamará CURSA,
consideramos que puede haber asignaturas sin alumnos. Las cardinalidades serán (1:M)
entre ALUMNO-ASIGNATURA, pues un alumno como mínimo cursa una asignatura, y como
máximo muchas, y la cardinalidad entre ASIGNATURA-ALUMNO será (0,N), pues una
ASIGNATURA puede ser cursada por 0 alumnos o por muchos.
En la tabla se muestra la matriz de entidades y relaciones entre ellas:
CURSOS ALUMNOS ASIGNATURAS
CURSOS ---------------- PERTENECE(1:M) ---------------
ALUMNOS x ES DELEGADO(1:M) CURSA(N:M)
ASIGNATURAS --------------- x -------------
18 | 30
Las celdas que aparecen con una x indican que las relaciones están ya identificadas, las que
aparecen con guiones indican que no existe relación. En la siguiente figura se muestra el
diagrama de las relaciones y las cardinalidades:
3. Identificar los atributos: como el enunciado no explicita ningún tipo de característica de las
entidades nos imaginamos los atributos que pueden ser los siguientes:
CURSOS: COD_CURSO (clave primaria), DESCRIPCIÓN, NIVEL, TURNO y ETAPA
ALUMNOS: NUM-MATRÍCULA (clave primaria), NOMBRE, DIRECCIÓN, POBLACIÓN, TLF
y NUM_HERMANOS
ASIGNATURAS: COD-ASIGNATURA (clave primaria), DENOMINACIÓN y TIPO
19 | 30
Ejercicio 1 (MER BÁSICO).
Disponemos de la información de una serie de fabricantes de automóviles. Un Fabricante puede fabricar

muchos vehículos. Del vehículo sabemos el número de bastidor y el precio. El vehículo será fabricado por un
único fabricante.
El vehículo puede ser camión, turismo o motocicleta. Del camión nos interesa el número de ejes y el
tonelaje. Del turismo número de puertas y número de plazas. De la motocicleta la cilindrada. La motocicleta
puede llevar o no un sidecar. Del sidecar nos interesa su identificación, el precio y el número de plazas.
Los camiones tienen que superar una serie de controles, de los que nos interesa almacenar los datos
de los controles, así como la fecha en la que se realizó cada control.
Ejercicio 2 (MER BÁSICO)
Se desea gestionar la información sobre las personas que viven en cada vivienda, así como de los
propietarios de las viviendas. De las personas se guardarán los datos personales. De cada vivienda se necesita
saber la dirección completa, los metros cuadrados, así como el número del inmueble con el que aparece en el
catastro. Se supone que una persona solo puede vivir en una vivienda, pero una misma persona puede ser
propietaria de varios inmuebles.
Cada vivienda paga unos impuestos, de los que se quiere registra el identificador, el nombre y una
descripción.
Ejercicio 3
Una cadena de agencias de viajes desea disponer de una base de datos que contemple
información relativa al hospedaje y vuelos de los turistas que la contratan.
Los datos a tener en cuenta son:
 La información que nos interesa almacenar de cada hotel es el código de hotel, nombre y dirección.
 La información que nos interesa almacenar de cada vuelo es el número de vuelo, fecha y hora, origen y
destino, plazas de primera clase y plazas de clase turista de las que dispone.
 La información que se desea almacenar por cada turista es el código de turista, nombre y dirección.
Se deben tener en cuenta las siguientes circunstancias:
 A la cadena de agencias le interesa saber los servicios efectuados por cada agencia a los turistas. Los
datos que debe almacenar sobre cada agencia es el código de la agencia y la dirección.
 A la hora de contratar un vuelo el turista elige en que clase desea viajar.
A la hora de contratar un hotel el turista puede elegir el régimen de hospedaje (media pensión o pensión
completa)
20 | 30
Ejercicio 4
En un centro hospitalario se desea informatizar parte de la gestión relativa a pacientes. Tras el

análisis realizado, se establecen los siguientes requerimientos:
 Los datos de interés que se desea almacenar del paciente son: n° de la Seguridad Social, DNI,
nombre, apellidos y fecha de nacimiento.
 Un paciente estará asignado a una cama determinada de una planta del hospital, pudiendo estar
a lo largo del tiempo de ingreso en diferentes camas y plantas, siendo significativa la fecha de
asignación de cama y el número de ésta.
 Habrá que tener en cuenta que las camas se numeran correlativamente por cada planta, es decir,
existirá la cama número 12 de la tercera planta y también la número 12 de la séptima planta.
Las plantas del hospital estarán identificadas por número de planta, su nombre y n° de camas de
que dispone. En una planta hay muchas camas.
 Los pacientes pueden pedir tarjetas de visita, se entregan hasta un máximo de 4 tarjetas de
visita. Estas tarjetas de visita serán válidas para visitar a un único paciente. La tarjeta de visita se
definirá por: n° de tarjeta de visita y la hora de comienzo y de final en que se puede visitar al
enfermo.
 A un paciente le pueden atender diferentes médicos, siendo significativa por cada visita médica
la fecha y hora de ésta.
 Y un paciente puede tener diferentes diagnósticos de diferentes médicos, siendo significativa la
fecha de diagnóstico.
Los datos de interés de los médicos serán: código del médico, nombre y apellidos. Los datos de interés
de los diagnósticos serán: código de diagnóstico y descripción
21 | 30
Ejercicio 5
Un club náutico desea tener informatizados los datos correspondientes a sus instalaciones, empleados, socios
y embarcaciones que se encuentran en dicho club. El club está organizado de la siguiente forma:
 Los socios pertenecientes al club vienen definidos por su nombre, dirección, DNI, teléfono y fecha de
ingreso en el club.
 Las embarcaciones vienen definidas por: matricula, nombre, tipo y dimensiones.
 Los amarres tienen como datos de interés el número de amarre, la lectura del contador de agua y luz, y
si tienen o no servicios de mantenimiento contratados.
 Por otro lado, hay que tener en cuenta que una embarcación pertenece a un socio, aunque un socio
puede tener varias embarcaciones. Una embarcación ocupará un amarre y un amarre está ocupado por
una sola embarcación. Es importante la fecha en la que una embarcación en asignada a un amarre.
 Un socio puede ser propietarios o no de un amarre, incluso un socio puede tener en propiedad varios
amarres, siendo importante la fecha de compra del amarre. Hay que tener en cuenta que un amarre
pertenece a un solo socio y que NO HAY ninguna relación directa entre la fecha en la que se compra un
amarre y en la que una embarcación se asigna a un amarre.
 El club náutico está dividido en varias zonas definidas por una letra, que indica el tipo de barcos que tiene,
el número de barcos que contiene, la profundidad y el ancho de los amarres. Una zona tendrá varios
amarres y un amarre pertenece a una sola zona.
 En cuanto a los empleados, estos vienen definidos por su código, nombre, dirección, teléfono y
especialidad. Un empleado está asignado a varias zonas y en una zona puede haber más de un empleado,
siendo de interés los de barcos de los que se encarga en cada zona. Hay que tener en cuenta que un
empleado puede no encargarse de todos los barcos de una zona, pero siempre habrá un empleado
encargado de un barco.
22 | 30
Ejercicio 6
Un zoo necesita una aplicación informática para llevar su organización respecto a las especies que posee, los
empleados (cuidadores y guías), y los distintos itinerarios de visita que ofrece. La información está estructurada
de la siguiente manera:
 Especies: de las especies interesa saber el nombre en español, el nombre científico y una descripción
general. Hay que tener en cuenta que una especie puede vivir en diferentes hábitats naturales y que un
hábitat puede ser ocupado por diferentes especies. Cada especie se encuentra en una zona y en una zona
hay varias especies.
 Hábitats: los diferentes hábitats naturales vienen definidos por el nombre, el clima y el tipo de
vegetación, así como el continente o continentes en los que se encuentran. Cada hábitat se encuentra
en una zona.
 Zonas: las zonas del parque en las que se encuentran las distintas especies vienen definidas por el nombre
y la extensión que ocupan.
 Itinerarios: los itinerarios discurren por distintas zonas del parque. La información de interés para los
itinerarios es: código de itinerario, la duración del recorrido, la longitud del itinerario, el máximo número
de visitantes autorizado y las zonas que se visitan. Hay que tener en cuenta que un itinerario recorre
distintas zonas del parque y que una zona puede ser recorrida por diferentes itinerarios. Además un
itinerario puede que no visite todos los hábitats de una zona.
 Guías: los guías del parque vienen definidos por el nombre, dirección, teléfono y fecha en la que
comenzaron a trabajar en el zoo. Interesa saber qué guías han realizado un itinerario, teniendo en cuenta
que un guía puede llevar realizar itinerarios y que un itinerario puede ser asignado a diferentes guías en
diferentes fechas y horas, siendo estos datos de interés.
 Cuidadores: los cuidadores vienen definidos por el nombre, dirección, teléfono y fecha de ingreso en el
parque. Hay que tener en cuenta que un cuidador puede estar a cargo de varias especies y que una
especie puede ser atendida por varios cuidadores, siendo de interés la fecha en la que un cuidador se
hace cargo de una especie.
23 | 30
Ejercicio 7
TRANSATALÁNTICARIBERA, empresa naviera dedicada a la realización de cruceros de gran lujo, desea se le

confeccione una Base de Datos que le permita gestionar la siguiente información:
 La empresa realiza diferentes cruceros, por ejemplo, crucero por el mediterráneo, crucero por
las islas griegas, …
 La empresa posee diferentes barcos para la realización de los cruceros.
 Cada barco está asignado a un crucero en concreto, de tal forma que si se produce una avería el
crucero no se realizará.
 Los clientes contratan los cruceros por medio de diferentes agencias de viajes. Sólo se pueden
contratar los cruceros por medio de una agencia de viajes.
 Durante el viaje los clientes pueden contratar diferentes servicios que se ofrecen durante el
crucero: actuaciones, cenas especiales, excursiones….
 Los servicios que se ofertan en los diferentes cruceros son muy parecidos, aunque puede haber
servicios distintos en diferentes cruceros.
 Los servicios tienen muy buena acogida por parte de los clientes que siempre contratan alguno
de los servicios que ofrece cada uno de los cruceros.
 Los barcos tienen una tripulación formada por marineros, camareros, personal de
mantenimiento, cocineros, personal de limpieza, …. Los marineros no están siempre asignados
a los mismos barcos.
 Hay un marinero que actúa como representante sindical de todos los marineros y hay un
marinero que es el capitán del barco.
La información que se desea que suministre como mínimo el Sistema de Información es la siguiente:
1. Dado un barco:
a. Las veces que ha realizado un crucero
b. Los clientes que lo han utilizado.
c. El capitán.
d. Los marineros que ha tenido.
2. Dado un crucero:
a. Los clientes y las agencias con las que han contratado.
b. Los servicios y los clientes que los han utilizado.
3. Dado un marinero:
a. Los barcos.
b. Si es capitán, indicar de que barco.
c. Su representante sindical.
24 | 30
Ejercicio 8
El Centro Universitario de Talavera del Reina desea que se le confeccione un Sistema de Información.
Para ello nos facilita la siguiente información:
 Un alumno se puede estar matriculado en las asignaturas que desee. Las asignaturas de las que se
matricula el alumno no tienen por qué pertenecer a la misma titulación.
 Una asignatura solo se imparte en una titulación.
 Un alumno puede poseer otras titulaciones universitarias.
 Una titulación se puede obtener en varios centros.
 Un alumno puede haber estado matriculado anteriormente de otras asignaturas, de las que nos interesa
conocer titulación a la que pertenecen, el año académico en el que estuvo matriculado, el curso dentro
de la titulación al que pertenece las asignaturas y la nota obtenida en cada una de las convocatorias a las
que se presentó a examen el alumno.
 Una asignatura es impartida por varios profesores (laboratorio, teoría, problemas, toda la asignatura, un
parcial…), y un profesor puede impartir varias asignaturas. Siendo de interés conocer la parte de la
asignatura que imparte cada profesor.
 Un profesor pertenece a un departamento.
 Las asignaturas que imparte un profesor pertenecen al departamento al que pertenece el profesor.
 Los profesores eligen la bibliografía de las asignaturas que imparten, se puede dar la situación de que dos
profesores que imparten la misma asignatura no tengan la misma bibliografía.
 Un libro puede ser escrito por uno o por varios autores, de los que nos interesa conocer sus datos,
también nos interesa tener información actualizada de los datos de la editorial a la cual pertenece un
libro.
1. Dado un alumno:
a. Las asignaturas en las que está matriculado.
b. Las asignaturas en las que ha estado matriculado y el año y la convocatoria en la que aprobó.
c. Las titulaciones que posee y los centros en que las obtuvo.
2. Dada una asignatura:
a. La titulación a la que pertenece.
b. El curso en el que se imparte.
3. Dado un profesor:
a. Las asignaturas que imparte.
b. Las asignaturas que ha impartido.
c. Los libros que utiliza en cada asignatura.
4. Dado un departamento:
a. El profesor que es jefe del departamento.
b. Los profesores que pertenecen al departamento.
5. Dado un libro:
a. Todos los datos de la editorial a la que pertenece.
b. Todos los datos del autor (autores).
c. Las asignaturas en que utiliza.
d. Los profesores que lo utilizan.
25 | 30
Ejercicio 9
El restaurante QUEBIENSECOMEENELRIBERA desea que se le confeccione una aplicación integral que le permita
gestionar el funcionamiento tanto de los clientes, el personal, así como de las especialidades que se ofrecen en
la carta.
Para ello nos facilita la siguiente información:
 El restaurante es visitado por diferentes clientes de los que nos interesa tener almacenados todos los
datos.
 Un cliente puede visitar en diferentes ocasiones el restaurante, incluso en el mismo día.
 Los clientes, cuando visitan el restaurante, pueden tomar cualquier plato de los que se ofrece el
restaurante o cualquier vino.
 Un plato se realiza con diferentes productos, de los que nos interesa conocer su cantidad.
 Un producto se puede comprar a diferentes proveedores.
 Para la realización de un plato se utilizan diferentes técnicas (sofrito, cocción, asado, plancha, guisado
…), incluso un plato puede tener varias técnicas.
 Nos interesa tener la receta de cada uno de los platos, en la que se describirá de forma detallada como
se realizan los platos.
 Los platos pueden ser: carnes, pescados, postres o ensaladas, de las carnes nos interesa saber su origen,
de los pescados si es salvaje o de piscifactoría, de las ensaladas la denominación de origen de cada una
de las verduras, es posible que una verdura se compre a diferentes denominaciones de origen.
 Los platos son confeccionados por un cocinero y sus pinches.
 Un cocinero puede tener asignado uno o varios pinches que le ayudaran en la realización de los platos y
un pinche sólo trabaja para un cocinero.
 Hay un cocinero que actúa como jefe de todos los cocineros.
 El restaurante posee una gran diversidad de vinos, de los que nos interesa conocer: el nombre, la cosecha,
así como una descripción del vino.
 Para mejorar el servicio los vinos son recomendados y servidos a los clientes, por alguno de los sumilleres
del restaurante, nos interesa saber que sumiller ha servido a un cliente.
 Los vinos pertenecen a bodegas de las que tenemos sus datos para poder realizar los pedidos.
 En el restaurante trabajan camareros que se encargan de atender a los clientes cuando visitan el
restaurante.
 Un cliente cuando visita el restaurante puede ser atendido por uno o varios camareros, pero un plato es
servido por un camarero, incluso un cliente puede ser atendido por el mismo u otro diferente en cada
una de las ocasiones que visita el restaurante.
 Hay un camarero que actúa como metre.
 De todos los trabajadores del restaurante tenemos algunas informaciones que son comunes como el
nombre, dirección, teléfono, DNI, número de la seguridad social. Además de cada uno de los tipos de
trabajadores tenemos informaciones particulares a cada uno de los tipos de trabajadores del restaurante.
26 | 30
Ejercicio 10
El laboratorio de inventos RiberaInventionLaboratory, situado en un edificio de varias plantas frente

al Río Tajo, necesita un sistema de información que le permita gestionar su funcionamiento. Para ello
nos ha proporcionado la siguiente información:
 En el laboratorio trabajan los inventores de los que se quieren guardar sus datos personales.
 Todos los inventores participan o han participado en el desarrollo de uno o varios inventos. Es
importante la fecha de inicio y la fecha de fin en la que el inventor participó en el proyecto.
 Además, un inventor se hace cargo de la dirección del invento, pudiendo haber dirigido a lo
largo de su carrera otros inventos.
 Un invento está identificado por un código, un nombre y una descripción.
 Cada inventor tiene asignado una serie de maestros que les aportan ideas en momentos de
oscuridad creativa. Un maestro puede tener asignado más de un inventor.
 De los maestros nos interesa saber sus datos personales, así como los años de experiencia.
 Uno de los maestros es el jefe absoluto del laboratorio.
 Periódicamente, los inventores imparten “clases magnas”, acompañados de un maestro en las
aulas de teoría. Interesa saber el título de la clase y la fecha y la hora a la que se impartió, así
como la duración de la clase.
 Del aula es importante saber si es de juntas o de docencia.
 Los inventores también realizan presentaciones de sus inventos en uno de los laboratorios del
edificio. Debido a la naturaleza de los inventos, existen laboratorios Analíticos, Científicos,
I+D…Un invento solo puede ser presentado una vez y por un solo inventor.
 De las aulas y de los laboratorios existen una serie de propiedades en común, como son el
nombre, la ubicación dentro del edificio y el número de plazas que tiene.
 Los inventos tienen una serie de fases: identificación, exploración, diseño, planificación,
construcción, evaluación y divulgación. Las fases se identifican por un nombre y una
descripción. Hay que tener en cuenta que no todos los inventos constan de las mismas fases. El
laboratorio quiere registrar la fecha en la que se inicia la fase y la fecha en la que termina.
 Por último, cada laboratorio es coordinado por un maestro y un maestro coordina un solo
laboratorio, siendo de interés la fecha del nombramiento.
1. Dado un inventor: a) Los inventos que ha dirigido.
b) El periodo en el que participó en el desarrollo de un invento.
c) Los maestros que tiene.
d) Los inventos que ha presentado y la fecha en la que lo hizo.
2. Dado un laboratorio: a) Los inventores que han presentado allí sus inventos.
b) El maestro que lo coordina.
3. Dado un invento: Las fases que tiene.
4. Dado un maestro: Los inventores a los que ha acompañado en una ponencia en un aula determinada y
en una fecha concreta.
5. ¿Podríamos conocer basándote en tu modelo, las FASES de cada invento en las que han participado los
INVENTORES? RAZONA TU RESPUESTA.
27 | 30
Ejercicio 11. Ejemplo Pregunta Examen
Ribera Grooming es un salón de belleza para perros que nos ha pedido el diseño de una base de datos.
Recibimos los siguientes requisitos:
En nuestra empresa es necesario llevar el control de empleados, las mascotas y sus dueños, así como los servicios
que realizamos.
De los clientes, siempre solicitamos los datos personales: Nombre Completo, dirección, teléfono de contacto.
También los datos de su perro o perros, independientemente de que nos lo haya traído alguna vez. De estos, nos
interesa saber el nombre, la fecha de nacimiento, la raza, el peso y observaciones. Solo registramos el perro a
nombre de un dueño.
Ribera Grooming controla las reservas que realizan nuestros clientes para los distintos servicios. Necesitamos
guardar el día y la hora y para qué perro nos está solicitando la reserva del servicio. En cada reserva solo se
realizará un servicio.
Los servicios que realizamos en el salón son: baño, uñas, baño+uñas, baño+uñas+corte,
baño+uñas+corte+secado y nutrición. Cada servicio se identifica por un código, nombre y una descripción
detallada. También almacenamos un “precio orientativo” porque es en el momento de realizar el servicio cuando
ponemos el precio final en función del peso del perro. Además de esto, cuando a una mascota se le realiza un
servicio, se registra la fecha y si hubo algún tipo de incidente así como el empleado o los empleados que le
atendieron durante el servicio.
En nuestra empresa, también disponemos de productos, nutricionales o estéticos, de los que queremos guardar
una breve descripción y el stock que tenemos del producto.
Los clientes, pueden realizar una compra en nuestro salón. Cada compra se caracteriza por un número de factura
que es irrepetible, la fecha y el total de la factura.
Hay que tener en cuenta que, en una misma factura, se pueden obtener uno o varios productos, así es que nos
gustaría registrar por cada producto comprado, el PVP (el precio de venta del producto) y el número de unidades
que adquiere el cliente.
Cada producto es suministrado por un único proveedor y un proveedor nos puede suministrar varios productos.
Es importante saber a qué precio compramos ese producto.
En nuestro salón trabaja personal de atención al cliente, auxiliares de peluquería, estilistas y nutricionistas. De
los nutricionistas, almacenamos el número de colegiado y el título académico. De los estilistas, almacenamos la
especialidad que tienen.
De todos los empleados, nos interesa tener sus datos personales (DNI, nombre completo, dirección y teléfono,
así como la fecha de alta en nuestra empresa). Algunos de ellos tienen un plus de antigüedad. El plus de
antigüedad es único para cada empleado y se lo concedemos cuando llevan un tiempo trabajando con nosotros.
Este plus implica, una comisión y la cesión de una determinada plaza de aparcamiento.
Por último, hay un empleado que hace de coordinador de sus compañeros.
28 | 30
Necesidades de información:
a) Dado un perro:
a. La información de las reservas.
b. Los servicios que le hemos realizado.
c. Su dueño.
d. El empleado que le ha atendido en cada uno de los servicios que se le ha realizado.
b) Dado un Cliente:
a. El dinero total que se ha gastado en todos los servicios que le hemos realizado a todos sus
perros.
b. El dinero total de las compras realizadas en la tienda.
c. Los productos que ha comprado de nutrición.
c) Dado un producto:
a. Los clientes que lo han comprado.
b. El proveedor que lo suministra.
c. El número de unidades que se han vendido.
d. Si es de nutrición o de belleza.
d) Dado un empleado:
a. Si es estilista, los servicios que ha realizado y las mascotas a las que ha atendido.
b. Los datos de su coordinador.
c. Los datos de su plus de antigüedad si lo tuviera.
29 | 30
Ejercicio 12. Ejemplo Pregunta Examen
El club de conducción RiberaCarting necesita un sistema de información que le permita gestionar su

funcionamiento. Para ello nos ha proporcionado la siguiente información:
 El club está formado por socios.
 Hay socios que tiene uno o varios kars, puede darse el caso de que un kar pertenezca a varios
socios, es decir, haya sido comprado por varios socios.
 También hay socios que no tiene ningún kar, pero que alquilan los kars que pone a su
disposición el club.
 Es importante para el club tener información de cada uno de los alquileres que se han realizado:
socio, karting, fecha y horas que dura el alquiler.
 Los socios pueden recibir clases de conducción por los monitores del club. Las clases se pueden
realizar con cualquiera de los kars del club. De cada clase sólo nos interesa conocer: el kar, el
monitor, el socio, la fecha, la hora y la duración de la clase.
 Al club le interesa tener información de los monitores, su dni y su teléfono de contacto.
 Los kars son guardados en plazas de garajes de dimensiones especiales. Cada kar tiene su plaza
de aparcamiento. No puede darse el caso de que un kar no tenga plaza de aparcamiento. Una
plaza de aparcamiento viene definida por un número único y una descripción.
 Para asegurar el correcto funcionamiento de los kars, hay que realizar una serie de revisiones.
Las revisiones son realizadas por los mecánicos del club.
 Cada revisión queda definida por un código único, un nombre de la revisión, así como la
descripción de cómo debe realizarse la revisión.
 Cualquiera de los mecánicos del club está capacitado para realizar cualquiera de las revisiones.
Incluso puede darse el caso de que realice la misma revisión sobre el mismo kar en varias
ocasiones.
 De un mecánico interesa saber, el código que tiene asignado y sus datos personales.
 Es importante para el club, tener información del fabricante de cada uno de los kars,
fundamentalmente datos de contacto.
Nota: si no se indican los atributos de alguna de las entidades, presuponer un cod_entidad y

una descripción por defecto.
30 | 30

Parte I - Diseño Lógico Conceptual

Cargado por

Copyright:

Formatos disponibles

Parte I - Diseño Lógico Conceptual

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Parte I - Diseño Lógico Conceptual

Cargado por

Copyright:

Formatos disponibles

UT2: DISEÑO DE BASES DE DATOS RELACIONALES.

Gracias al modelo conceptual Entidad-Relación de Peter Chen (años setenta) podemos

3. Diseño de una base de datos.

Fase I: Diseño Conceptual. Consiste en el estudio del problema a

Los elementos básicos son: entidades (E), relaciones (R) y atributos.

Las entidades cumplen las siguientes propiedades:

Dentro de las entidades distinguimos entre dos tipos:

4.1.2.1. Grado de una Relación.

 Binaria: Asocia dos entidades.

 Ternaria: Asocia 3 entidades.

 N_aria: Asocia n entidades, más de tres.

4.1.2.2. Cardinalidad de una Relación.

La Cardinalidad define la forma en que se relación las entidades e identifica el número de

La forma de representarlas es situar, encima del rombo que representa la asociación, su

Los atributos pueden ser de los siguientes tipos:

Existen distintos tipos de claves:

4.2. Modelo Entidad / Relación EXTENDIDO

4.2.1. Cardinalidad de un tipo de entidad (Participación)

Para calcular la participación de cada entidad en la relación “ EMPLEADO TRABAJA EN

¿Cuántos empleados trabajan en un proyecto?

¿En cuántos proyectos trabaja un empleado?

En base al modelo diseñado, podemos afirmar:

4.2.2. Cardinalidad de la Relación en el modelo Extendido.

La cardinalidad de una relación se calcula a través de las participaciones de sus ocurrencias en

¿Cuántos productos pertenecen a una categoría? Mínimo 0, máximo n (0,n) en la parte de

El resultado sería, por tanto:

Las cardinalidades en el modelo extendido siguen

 Cardinalidad 1:1  Una ocurrencia de la

 Cardinalidad 1:N (o Muchos)  Una

 Cardinalidad M:N (o Muchos:Muchos o

4.2.2.1 Cardinalidad de relaciones NO binarias

En este ejemplo, se distinguen tres participaciones:

 Un expediente solo puede ser supervisado por una auditora.

Las preguntas que nos haremos serán las siguientes:

¿Cuántas empresas pueden tener un expediente con una auditora?

¿Cuántas auditoras pueden auditar un expediente a una empresa?

4.2.2. Relaciones exclusivas

4.2.3. Entidades débiles

4.2.4. Generalización y especialización

La generalización es el proceso contrario a la

Pero el resultado es el mismo, la construcción de una jerarquía. Se representa por un triángulo

4.2.4.1. Tipos de jerarquías

 Especialización Inclusiva: Se produce cuando las ocurrencias de la superclase pueden

 Especialización Total: Se produce cuando la entidad superclase tiene que materializarse

Por tanto: generalizaciones totales y exclusivas, totales y solapadas, parciales y exclusivas,

Prueba a representar las siguientes jerarquías:

5. Construcción de diagramas Entidad / Relación

5.1.Recomendaciones para el diseño

1. Leer varias veces el problema hasta memorizarlo.

2. Obtener una lista inicial de candidatos a entidades, relaciones y atributos. Se realiza

d. Es fácil identificar las generalizaciones si se obtiene un atributo que es aplicable a

g. Extraer los dominios de los atributos. Siempre es buena práctica, ir apuntando,

3. Averiguar las participaciones y cardinalidades. Generalmente se extraen del propio

5.2. Caso práctico resuelto

Se desea realizar el diagrama de estructuras de datos en el modelo E-R correspondiente al

Ejercicio 1 (MER BÁSICO).

Disponemos de la información de una serie de fabricantes de automóviles. Un Fabricante puede fabricar

Ejercicio 2 (MER BÁSICO)