Diseño de base de datos:

Modelo Entidad Relación

(I)
I. Fases del desarrollo para lograr un
buen diseño
El proceso de diseño de una base de datos comienza por una descripción detallada del
sistema de información (SI) a modelar (normalmente los datos de interés para la
empresa). A partir de ahí se obtiene lo que denominamos un modelo conceptual
(modelo entidad relación – MER) que, mediante ciertas reglas se transforma en un
modelo lógico (modelo relacional –MR).

Este modelo será el que nos permita llevar a cabo la construcción o implementación de
nuestras bases en un sistema de bases de datos real (Sistema Gestor de Bases de
Datos o SGBD) mediante un lenguaje de datos (Structured Query Language o SQL).

Análisis de Diseño Diseño lógico- Diseño Diseño físico

requisitos Conceputal relacional normalizado

•FASE 3: •FASE 4: SQL + •IMPLANTACIÓN

•FASE 1: •FASE 2: REGLAS DE
NORMALIZACIÓN AJUSTES EN SGBD
DISEÑO TRANSFORMACIÓN
CONCEPTUAL

Figura 1 Fases para obtener un buen diseño

1. Fase 1
Tras el establecimiento de las restricciones o requisitos o reglas de negocio
del sistema y un análisis de las mismas (proceso realizado interactivamente

1
 con el cliente) se pasa a realizar el primero diagrama conceptual (Diagrama
Entidad Relación) donde se establecerán las entidades importantes y las
relaciones que las vinculan así como sus atributos.

2. Fase 2
Aplicando las reglas que más tarde se explicarán, se traduce el esquema
inicial a un modelo lógico o relacional que en principio podría servir como
esquema de bases de datos.

3. Fase 3
Se refina el modelo eliminando “impurezas” o errores de normalización
aplicando, por tanto, las reglas de normalización.

4. Fase 4
Usando un lenguaje de definición de datos (DDL) como SQL y aplicándole
sentido común para adaptar la base de datos a nuestro sistema (para lograr
una mayor eficiencia y optimización del funcionamiento) generamos el
código para traducir el esquema a un sistema físico usando un SGBD.
A continuación se estudiarán los elementos claves de este proceso, empezando
por el modelo Entidad-Relación o MER.

II. Modelo Entidad Relación

1. Definición

El Modelo Entidad Relación o MER es un método de representación abstracta del

mundo real centrado en las restricciones o propiedades lógicas de una base de datos y
que precede al modelo relacional. Por lo tanto, no es directamente aplicable en un
Sistema Gestor de Bases de Datos o SGBD, sino que necesita una transformación a las
estructuras de datos del modelo de datos propio de dicho SGBD. Ese mundo real hace
referencia a un grupo de objetos básicos llamados entidades y relaciones entre esos
objetos y que se implementa a través del Diagrama Entidad Relación.

2
2. Entidad

Representa un objeto real o bien abstracto, que existe o puede existir en un contexto
determinado del que queremos guardar información.

Por ejemplo, pensemos en una aplicación informática que gestiona la información de

un Instituto. Es muy probable que necesitemos almacenar la información de los
alumnos del centro, con lo que con toda probabilidad en la base de datos existirá una
tabla Alumnos. Cada fila de esta tabla contendrá la información de un alumno. Cada
fila recibe el nombre de tupla o registro.

Figura 2 Relación entre entidades y tablas

Las entidades en el modelo entidad relación se representan mediante rectángulos, en

cuyo interior solo aparece el nombre. Si necesitamos modelar atributos, se deben
añadir dentro de una elipse, conectada a la entidad mediante una línea. Cada elipse
contendrá un atributo. En ocasiones podrás encontrarte que algunos atributos
aparecen subrayados. Eso es porque son clave primaria de esa entidad, cuyo
significado se verá a continuación.

3
 Figura 3 Representación de una entidad con sus atributos y clave primaria

Reglas que debe cumplir una entidad:

 Tiene que tener existencia propia.

 Todas las ocurrencias de un tipo de entidad deben tener los mismos tipos de
características (atributos).

III. Atributos
Son las características o propiedades que definen a la entidad. Podrían existir múltiples
atributos, siendo normalmente responsabilidad del diseñador implementar aquellas
con cierta relevancia dentro del problema.

Cuando existen un conjunto de ocurrencias de un tipo de entidad, cada una de ellas

suele tener valores diferentes, por lo que es posible su identificación unívoca.

Por ejemplo, estos serían tres alumnos modelando sus atributos ID, Nombre y Edad:

 (1, Sofía, 38)

 (2, Josefa, 19)
 (3, Carlos, 20)

En concreto existen atributos que permiten identificar de forma única a cada

ocurrencia de un tipo de entidad, en este ejemplo el ID.

Existen restricciones en los valores que el atributo puede tomar, por ejemplo, su tipo
de datos (cadenas de caracteres, solo números mayores que cero, solo números
enteros...). A dichas restricciones se les considera el dominio del atributo.

4
 1. Tipos de atributos

Según su opcionalidad:

 Opcionales: pueden tomar valores nulos.

 Obligatorios: necesariamente deben tener un valor para cada ocurrencia de
entidad (claves primarias).

Según su cardinalidad:

 Multivaluados: para una misma ocurrencia de entidad pueden tomar varios

valores.
 Univaluados: toman un único valor para cada ocurrencia.

Según su carácter:

 Simples: son atributos cuyo valor debe introducir el usuario.

 Derivados: son campos calculados a partir de datos simples de manera que
dotan de cierta ambigüedad al modelo.

IV. Claves

1. Clave primera

Se denomina clave principal o primaria al atributo o conjunto mínimo de atributos (uno

o más campos) que permiten identificar de forma única cada instancia de la entidad (es
decir, cada tupla o registro).

En el ejemplo anterior del usuario la clave primaria sería el Nick, puesto que en el
dominio de ese problema no se permiten dos usuarios con el mismo Nick en esa
aplicación en concreto.

2. Claves candidatas

Son todas aquellas claves que podrían servir como clave principal.

5
Volviendo al ejemplo de los alumnos, si queremos buscar una clave primaria para la
Entidad Alumno, debemos buscar qué atributo o combinación de atributos no se repite
de un alumno a otro. Es decir:

 Dos alumnos pueden tener el mismo nombre y apellidos, por lo que no puede
ser clave primaria.
 Dos alumnos pueden vivir en la misma casa, y por tanto tener la misma
dirección, por lo que tampoco es válido.
 Dos alumnos pueden tener el mismo número de teléfono (por ejemplo, si viven
en la misma casa).

En cambio:

 Dos alumnos no pueden tener el mismo DNI.

 Dos alumnos no pueden tener el mismo Legajo (el legajo es un número único
de identificación que sería algo así como el número de expediente).

Por tanto, estas dos últimas serian claves candidatas, y quedaría a elección del
diseñador de la base de datos elegir una como clave primaria. Por ejemplo, en este
caso seleccionaremos el DNI.

Las claves candidatas que no han sido elegidas como clave primaria se denominan
alternativas.

Figura 4. Claves candidatas vs Clave primaria

6
 3. Claves simples y compuestas

Se habla de clave simple si la clave primaria está compuesta de un solo atributo,

mientras que si está conformada por más de un atributo nos referiremos a ella como
clave compuesta.

Pensemos por ejemplo en cómo identificaríamos de forma única una clase (grupo de
alumnos) de un Instituto. No podemos identificarla diciendo que es un primero, ya que
habrá primero de DAM, primero de ASIR, primero de ESO, etc. Tampoco es suficiente
decir que es primero de ESO, porque puede haber primero A, primero B, etc. Por tanto,
necesitaremos una combinación de tres atributos para identificarla. Es decir,
necesitaremos agrupar el nivel (ESO, ASIR, etc.), el Grado (primero, segundo, tercero), y
la sección o letra (A, B, C).

Figura 5. Claves compuestas

4. Claves foráneas

La clave foránea o bien externa es un atributo que a su vez es clave primaria en otra
entidad con la cual se relaciona. Se expresa en la fase del modelo relacional.

7
 Test
1. En cuál de estas fases se encuadra el Modelo Entidad Relación:
a. Fase 1: Diseño conceptual.
b. Fase 2: Reglas de transformación.
c. Fase 3: Normalización.
d. Fase 4: Definición del esquema de BD mediante SQL.
2. Indica la afirmación verdadera respecto al MER:
a. Es abstracto por lo que no representa objetos o restricciones del mundo
real.
b. Es directamente aplicable a un SGBD tal como Oracle.
c. Se basa en entidades y relaciones para la representación.
d. No existe ninguna forma estandarizada para su representación.
3. Cuál de estos nombres no es correcto para denominar las ocurrencias de
entidades almacenadas en una tabla:
a. Fila.
b. Tupla.
c. Columna.
d. Registro.
4. ¿Qué no es correcto respecto a la representación del Diagrama Entidad
Relación?:
a. La elipse permite representar los atributos y el rectángulo las entidades.
b. La clave primaria se representa con un subrayado.
c. La elipse permite representar los atributos y un rectángulo dentro las claves
candidatas.
d. Puede haber tantas elipses como atributos tenga la entidad.
5. Dados tres alumnos con los siguientes atributos, ID Nombre Edad:
 (1, Sofía, 38)
 (2, Josefa, 19)
 (3, Carlos, 20)

8
 a. El ID para Sofía y Carlos debería ser coincidente ya que pertenecen al
mismo tipo de entidad.
b. Con este modelo no podrían existir dos alumnos llamados Carlos distintos.
c. Si tengo que representar un alumno llamado Carlos distinto tendré que
crear otra fila con id 4.
d. No es posible representar otro alumno llamado Carlos y con edad 20.
6. Señala la afirmación incorrecta respecto de los atributos:
a. Si el número de matrícula de un alumno es clave primaria no puede ser
opcional.
b. La edad puede considerarse un campo derivado de la fecha de nacimiento.
c. Si el DNI del alumno es clave candidata puede tomar valor nulo.
d. Para mejorar el rendimiento, todos los atributos son siempre simples.
7. Indica cuál de las siguientes no podría ser una clave candidata de un alumno:
a. El DNI.
b. El número de la seguridad social.
c. El número de expediente.
d. El domicilio.
8. Si NumVuelo es clave primaria, señala la clave alternativa compuesta para
una entidad Vuelo:
a. Destino y Fecha.
b. Origen Destino y Número Pasajeros.
c. Compañía Origen y Destino.
d. Origen Destino Fecha y Hora.
9. El diagrama utilizado en la Fase 1 o en la primera fase (diseño conceptual)
para realizar un buen diseño de nuestra base de datos se suele denominar:
a. Diagrama relacional.
b. Diagrama físico.
c. Diagrama del Modelo Entidad Relación.
d. Diagrama de normalización.

10. En la siguiente tabla: alumno (dni, num_expediente, num_seguridad_social,

nombre, apellidos, dirección, teléfono):

9
 a. dni, num_expediente, num_seguridad_social y nombre son consideradas
claves candidatas.
b. nombre podría ser clave primaria de la relación.
c. Si selecciono el num_expediente como primaria, las claves alternativas
serían el dni y el num_seguridad_social.
d. Si selecciono el num_expediente como primaria, las claves alternativas
serían el nombre y apellidos, y el num_seguridad_social.

Respuestas:

1 a/2 c/3 c/4 c/5 c/6 d/7 d/ 8 d/9 c/10 c

10