UNIDADES TECNOLOGICAS DE SANTANDER

GUIA DE ESTUDIO N 1

PROGRAMAACADMICO
UNIDADTEMTICA

IDENTIFICACION
GESTION DE SISTEMAS INFORMATICOS
ASIGNATURA: BASES DE DATOS RELACIONALES
UNIDAD 1:MODELAMIENTO DE BASES DE DATOS RELACIONALES

COMPETENCIA
Elaborar modelos de datos a partir
de problemas del mundo real.

RESULTADOSDEAPRENDIZAJE
Elabora modelos de datos a partir de problemas del mundo
real utilizando el modelo entidad-relacin

ACTIVIDADESDEAPRENDIZAJE
MODELDO ENTIDAD RELACIN
Un primer ejemplo1
Vamos ver un primer ejemplo, que nos ayudar a llevar a la prctica todo esto y a introducir el modelo EntidadRelacin. Supondremos que nos proponen el siguiente problema:
Se desea informatizar un centro de estudios de pequeo tamao. Interesa controlar
exclusivamente los asuntos acadmicos: qu alumnos tenemos, qu cursos/asignaturas han
realizado, qu profesores tenemos en plantilla, quin ha impartido cada uno de los cursos, etc.
Ahora tendramos que pensar si vemos que falta algo (y preguntar al cliente, si procede, cosas como si desea
guardar la direccin y dems datos postales de los alumnos y de los profesores, o si quiere saber la nota que
cada alumno obtuvo en cada curso) o incluso si sobra algo.
Pasamos a desglosar en bloques de informacin. De momento todava no hablaremos de tablas, sino de
entidades (un nombre ms ambiguo pero ms adecuado) y de relaciones entre estas entidades.
En nuestro caso, las cosas (entidades) que tenemos son bsicamente stas:
Alumnos.
Cursos.
Profesores.
Y las relaciones que hay entre estas entidades son:

Los profesores IMPARTEN cursos.

Los alumnos ASISTEN a cursos.
(Indirectamente, los alumnos y los profesores tambin estn relacionados: un alumno ha asistido a un
curso que ha impartido un cierto profesor; esta relacin ya queda reflejada a partir de las otras dos, as
que no es necesario detallarla).

Aun comentaremos algo ms sobre las relaciones. Una caracterstica importante de las relaciones es su
cardinalidad: por ejemplo, en la relacin de que los alumnos asisten a los cursos, es importante si a cada
curso slo puede asistir un alumno o varios, y si un alumno puede asistir a un solo curso o a varios.
Tendremos cuatro posibilidades:

Que cada alumno asista uno y solo uno de los cursos (se expresa como 1:1 -uno a uno-)
Que cada alumno pueda asistir a muchos cursos, pero en cada curso slo puede haber un alumno
(1:M -uno a muchos-)
Que cada alumno pueda asistir a un nico curso, pero pueda haber varios alumnos en un curso (M:1 muchos a uno-).
Que cada alumno pueda asistir a varios cursos, y en cada curso pueda haber varios alumnos (M:M muchos a muchos-)
En nuestro caso, la relacin asistir es una relacin de muchos a muchos (M:M).
Podramos preguntarnos la cardinalidad de la otra relacin (los profesores imparten cursos). En este caso,
cada profesor puede impartir varios cursos, y supondremos que cada curso es impartido por un nico profesor
(estoy dando por supuesto que se considera distinto un curso de Bases de Datos impartido en una fecha y
otro de la misma temtica pero impartido en fecha distinta). Se tratara de una relacin de uno a muchos 1:M.
1

CABANES, Nacho. Introduccin a las bases de datos. [en lnea] < www.nachocabanes.com/tutors/ibd006.pdf > [citado en
31 de agosto de 2012]
VERSIN: 6FECHA:2013

UNIDADES TECNOLOGICAS DE SANTANDER

GUIA DE ESTUDIO N 1
Una observacin: en las relaciones es importante el sentido en el que se leen. Por ejemplo, la relacin los
profesores imparten cursos es una relacin 1:M (uno a muchos), mientras que la relacin opuesta los cursos
son impartidos por profesores es una relacin M:1 (muchos a uno).
Estas relaciones que hemos comentado son relaciones binarias (entre dos entidades).
Diagrama EER de nuestro ejemplo.
Vamos a ver cmo quedara el diagrama Entidad-Relacin de nuestro ejemplo:

As de sencillo: tenemos 3 entidades (profesores, cursos, alumnos) y dos relaciones (impartir, entre profesores
y alumnos, 1:M, y asistir, entre alumnos y cursos, M:M).
Realmente, ya a este nivel se suele indicar los apartados que hay en cada entidad (lo que sern los campos
de nuestras tablas). A estos apartados les llamaremos atributos, y se representan como pequeas elipses
que salen de las entidades. Vamos a pensar primero qu atributos nos podra interesar para nuestras
entidades:
Alumnos:
. DI (Documento de Identidad)
. Nombre
. Direccin
. Ciudad
. Telfono
. Fecha de nacimiento
. Fecha de alta en el centro
. Fotografa

Profesores:
. DNI.
. Nombre
. Direccin
. Ciudad
. Telfono
. Conocimientos
. Sueldo
. Cuenta bancaria

Cursos:
. Nombre del curso
. Fecha de comienzo
. Duracin (horas)
. Importe (euros)
. Nmero mximo de alumno

Es slo un ejemplo. Insisto en que de momento no estamos pensando en tablas, sino simplemente en qu
informacin queremos almacenar. Segn el sistema de bases de datos que empleemos realmente, puede
ocurrir que sea incmodo (o incluso imposible) trabajar con algunos de estos datos que hemos previsto (por
ejemplo, la fotografa del alumno).
Lo que s vamos a pensar ya es cul de esos datos nos permitir distinguir una ficha de otra. Esto se hace
porque podemos tener dos alumnos con el mismo nombre, pero claramente son personas distintas, y debemos
saber qu cursos ha realizado cada uno de ellos sin posibilidad de confusin, para no dar a uno el diploma que
corresponda a otro, ni cobrarle un dinero de otro.
En el caso de los alumnos, no son datos nicos los siguientes: el nombre (puede repetirse, incluso con
apellidos), la direccin (dos hermanos o dos amigos pueden vivir en la misma casa), el telfono (ocurre lo
mismo), la fecha de nacimiento (tambin podemos encontrar dos alumnos que hayan nacido el mismo da),
etc. Lo que realmente distinguir a un alumno de otro es su nmero de DNI (Documento Nacional de
Identidad) o pasaporte, que s es nico.
Pues bien, este dato que puede distinguir una persona de otra (o en general una ficha -registro- de otra) es lo
que llamaremos la clave.
Puede ocurrir que no exista nada que nos sirva claramente como clave, como es el caso de los cursos: no es
nico el nombre (podemos impartir ms de un curso con el mismo contenido), ni la fecha de comienzo (varios
cursos pueden comenzar el mismo da), ni la duracin, ni el importe, ni el nmero mximo de alumnos. En
estos casos se suele aadir algo arbitrario, un cdigo, que nos permita distinguir un curso de otro (en general
una ficha -registro- de otra). En nuestro caso, incluiramos un nuevo atributo, llamado Cdigo de curso.

VERSIN: 6FECHA:2013

UNIDADES TECNOLOGICAS DE SANTANDER

GUIA DE ESTUDIO N 1
Un ltimo comentario antes de ver cmo quedara nuestro diagrama EER con sus atributos. Puede ocurrir que
nuestra entidad tenga varios atributos nicos, todos los cuales puedan servir como clave. Entonces
escogemos una de ellas como clave principal, y el resto sern claves alternativas, que no llegaremos a
usar como claves. En el diagrama, el atributo que vaya a utilizarse como clave principal aparecer subrayado.
Ahora ya s. Nuestro diagrama quedara as (no incluyo todos los atributos que habamos pensado, slo
algunos como ejemplo, que es con los que trabajaremos a partir de ahora):

EVALUACIN

Construya un diagrama Entidad/Relacin para la siguiente situacin:

"Un concesionario de vehculos desea disear una base de datos para almacenar y gestionar informacin.
Para ello se tienen en cuenta los siguientes aspectos:

El concesionario dispone de una serie de vehculos para su venta. Se necesita conocer la placa, marca,
modelo, color y el precio de venta de cada vehculo. Cada vehculo slo puede ser comprado por un
nico cliente.
Del cliente se necesita conocer el nmero de identificacin, nombre, direccin, ciudad y nmero de
telfono. Un cliente puede comprar tantos vehculos como desee al concesionario.
El concesionario tambin se encarga de llevar a cabo las revisiones que se realizan a cada vehculo.
Cada revisin tiene asociado un cdigo que se incrementa automticamente por cada revisin que se
haga. De cada revisin se desea saber si se ha hecho cambio de filtro, si se ha hecho cambio de
aceite, si se ha hecho cambio de frenos u otros. Los vehculos pueden pasar varias revisiones en el
concesionario".
Las revisiones son realizadas por los mecnicos del concesionario. De ellos se almacena su
identificacin, nombre, direccin, telfono, fecha de vinculacin y salario. Un mecnico puede revisar
mltiples vehculos. Un vehculo puede ser revisado por varios mecnicos cada vez que es llevado al
conesionario.

BIBLIOGRAFIA
CABANES, Nacho. Introduccin a las bases de datos. [en lnea] < www.nachocabanes.com/tutors/ibd006.pdf > [citado
en 31 de agosto de 2012].
1

VERSIN: 6FECHA:2013