EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
Ejemplo Hospital
Enunciado
Con el objeto de crear un software para la administración de un hospital, se pretende diseñar una base de
datos. Tras un estudio de la información existente en dicho centro, se obtuvieron los siguientes datos:
En el hospital se almacena información relativa a los enfermos: código de enfermo, nombre,
dirección, DNI, fecha de nacimiento, teléfono de contacto, edad.
También se almacena la información relativa a los trabajadores del hospital (en este caso sólo serán
médicos y auxiliares), de los que se desea conocer: Nombre, dirección, DNI, sueldo,teléfono de
contacto. En el caso de los médicos, además se desea conocer la especialidad.
Los enfermos están alojados en habitaciones, siendo interesante almacenar la fecha de
hospitalización del enfermo así como la fecha de alta cuando el enfermo abandona el hospital.
En una misma habitación, puede haber más de un enfermo. Para cada habitación se almacena
además de su número, la cantidad de camas que tiene y se anotan las observaciones. Las habitaciones
pertenecen a las distintas plantas del hospital no pudiéndose repetir su numeraciónen distintas
plantas.
Para cada planta se almacena la cantidad de habitaciones que hay y la especialidad de la planta
además de su número.
Existe un conjunto de auxiliares de enfermería. Cada auxiliar, está asignado a una única planta.
Cada enfermo tendrá un conjunto de diagnósticos que son emitidos por los médicos que los
curan. Para cada diagnóstico del enfermo, se guarda la fecha del diagnóstico, y el informe, junto con
el código correspondiente. Cada diagnóstico es emitido por un único médico.
Se pide realizar el análisis y diseño de la base de datos. Para ello vamos a obtener el diagrama E/R
resultante (entidades, atributos, relaciones, claves, cardinalidades y otras características del modelo E/R
Extendido) y su posterior transformación al Modelo Relacional (conjunto de tablas con sus claves
correspondientes y sus relaciones)
1.- Elaboración del diagrama Entidad-Relación
1.1. Identificación de entidades, atributos y relaciones.
Empezamos identificando las entidades, para ello leemos el texto e intentamos identificar los sustantivos
que puedan representar algo importante en nuestro sistema de información.
Después de una primera lectura nos encontramos con ENFERMO, TRABAJADOR (MÉDICO,
AUXILIAR), HABITACIÓN, PLANTA y DIAGNÓSTICO como posibles entidades.
Seguimos el estudio identificando los atributos. Al leer los requerimientos del sistema nos preguntamos:
¿Qué información necesitamos almacenar de las distintas entidades encontradas?
Para la entidad ENFERMO necesitamos conocer: ‘codigo_enfermo’, ‘nombre’, ‘dirección’,
‘DNI’, ‘fecha_nacimiento’, „telefono’ y ‘edad’, por lo que todos ellos son los atributos de la
entidad ENFERMO. Hay que hacer una especial mención al atributo ‘edad’, que no es más que un
atributo derivado, ya que se puede obtener como resultado de una operación sobre el
campo‘fecha_nacimiento’. De la misma manera también tenemos que estudiar qué ocurre con el
atributo ‘dirección’, ya que dependiendo de cómo lo consideremos puede tratarse de un atributo
simple, o un atributo compuesto por la calle, el número, población y provincia. En este caso lo
consideramos como un atributo simple.
Para la entidad DIAGNÓSTICO se va a almacenar la ‘fecha’ y el ‘informe’, junto con el
‘codigo_diagnóstico’ correspondiente.
De la entidad MÉDICO necesitamos almacenar la siguiente información: ‘nombre’, ‘dirección’,
‘DNI’, ‘sueldo’, ‘telefono’ y ‘especialidad’.
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
De la entidad AUXILIAR queremos almacenar: ‘nombre’, ‘direccion’, ‘DNI’ y ‘telefono’
De la entidad HABITACIÓN almacenaremos: ‘numero_habitacion’, ‘cantidad_camas’ y
‘observaciones’.
Para la entidad PLANTA, por último, almacenaremos: ‘numero_planta’, ‘cantidad_habitaciones’ y
‘especialidad’ de la planta.
Continuamos nuestro estudio identificando las relaciones, para ello volvemos a leer el texto.
¿De qué manera se relacionan las entidades que hemos descubierto en el paso anterior?
Claramente tenemos que ENFERMO se relaciona con HABITACION mediante ‘alojado’, que
HABITACION se relaciona con PLANTA mediante ‘ubicada’, PLANTA con AUXILIAR mediante
‘asignado’, MÉDICO con DIAGNÓSTICO mediante ‘emite’ y por último DIAGNÓSTICO con
ENFERMO mediante “pertenece”.
Ya hemos identificado todos los atributos de las entidades pero, ¿las relaciones no pueden tener
también atributos?
Leyendo los requerimientos de nuestro problema podemos observar que uno de los puntos que nos dan es el
siguiente: “Los enfermos están alojados en habitaciones, siendo interesante almacenar la fecha de
hospitalización del enfermo así como la fecha de alta cuando el enfermo abandona el hospital.” De esta
forma nos indican que tenemos que guardar la información de cuándo se asigna la habitación a un
enfermo y cuándo deja de estar asignada a ese enfermo, y la única manera que tenemos para hacerlo es
añadiendo dos atributos a la relación ‘alojado’. Estos atributos no son más que ‘fecha_ingreso’ y
‘fecha_alta’.
No se aprecian más atributos de otras relaciones.
En cuanto a las entidades y una vez estudiadas las relaciones que hay entre ellas, ¿Podríamos
considerarlas todas como entidades fuertes, o hay alguna que pueda ser una entidad débil?
Si leemos con detenimiento, la entidad DIAGNÓSTICO podría ser una entidad débil que depende de
ENFERMO mediante la relación “pertenece”, y en efecto así es, puesto que si desaparece una instancia
de la entidad ENFERMO (fuerte), no tiene sentido la existencia de ningún DIAGNÓSTICO (débil)
para ese paciente, luego DIAGNÓSTICO presenta una dependencia en existencia respecto a la entidad
ENFERMO.
1.2. Estudio de las cardinalidades de entidades y cardinalidades
de relaciones.
Ahora que ya sabemos cuáles son las entidades y las relaciones implicadas, ¿cómo calculamos la
cardinalidad de las entidades y por consiguiente de las relaciones?
Muy sencillo, haciéndonos la siguiente pregunta para cada entidad: una instancia de la entidad que nos
interesa, ¿con cuántas instancias se relaciona de la otra entidad que estamos estudiando? La
respuesta para cada caso es la siguiente:
En la relación ENFERMO ‘alojado’ HABITACIÓN
Para la entidad ENFERMO teniendo en cuenta la relación ‘alojado’, un enfermo, ¿en cuántas
habitaciones se puede alojar? Si se necesita guardar la fechas de entrada y salida, es evidente que
nos interesa guardar las distintas ocupaciones durante un periodo de tiempo, por lo que un enfermo
podrá ocupar una o varias habitaciones, por lo que su cardinalidad será (1,n).
Para la entidad HABITACIÓN teniendo en cuenta la relación ‘alojado’, una habitación,
¿cuántos enfermos puede alojar? En este caso puede que aún no se haya alojado aún ningún
enfermo, o que se hayan alojado varios, que sera lo normal, por lo que la cardinalidad será (0,n).
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
En la relación HABITACIÓN ‘ubicada’ PLANTA
Para la entidad HABITACIÓN teniendo en cuenta la relación ‘ubicada’, una habitación ¿en
cuántas plantas puede estar? Es obvio que una habitación sólo puede estar en una planta, por
lo que su cardinalidad será en este caso (1,1).
Para la entidad PLANTA teniendo en cuenta la relación ‘ubicada’, una planta ¿cuántas
habitaciones puede tener? La respuesta es inmediata, como mínimo una planta debe tener una
habitación y como máximo n habitaciones. La cardinalidad en este caso será (1,n).
En la relación PLANTA ‘asignado’ AUXILIAR
Para la entidad PLANTA teniendo en cuenta la relación ‘asignado’, una planta ¿cuántos
auxiliares de enfermería puede tener asignados? Al menos debe haber un auxiliar y puede
haber hasta n. Su cardinalidad en este caso será (1,n).
Para la entidad AUXILIAR teniendo en cuenta la relación ‘asignado’, un auxiliar ¿a cuántas
plantas puede estar asignado? Por el enunciado que tenemos, a una única planta, por lo que su
cardinalidad será (1,1).
En la relación MÉDICO ‘emite’ DIAGNOSTICO
Para la entidad MÉDICO teniendo en cuenta la relación „emite’, un médico ¿cuántos
diágnosticos puede emitir? Está claro que un médico puede no emitir ningún diagnóstico y
puede emitir hasta n diagnósticos. Por este motivo, su cardinalidad será (0,n).
Para la entidad DIAGNÓSTICO teniendo en cuenta la relación „emite’, un diágnostico,
¿cuántos médicos lo han podido emitir? Gracias al enunciado sabemos que un diagnóstico
puede ser emitido por un único médico, por lo que su cardinalidad será (1,1).
En la relación DIAGNOSTICO ‘pertenece’ ENFERMO
Para la entidad DIÁGNÓSTICO teniendo en cuenta la relación „pertenece’, un diagnóstico, ¿a
cuántos enfermos puede pertenecer? Evidentemente un diagnóstico pertenecerá a un solo
enfermo, por lo que la cardinalidad será (1,1).
Por último, para la entidad ENFERMO teniendo en cuenta la relación „pertenece‟, un enfermo,
¿cuántos diagnósticos puede tener? Según el enunciado, podrá tener uno o varios dependiendo de
los médicos que lo estén tratando. La cardinalidad será (1,n).
NOTA: es importante recordar que cuando representemos las cardinalidades de las entidades en el
diagrama E/R, cada cardinalidad estudiada no se representa en su propia entidad, sino junto a la
otra entidad con la que participa en la relación.
Una vez que tenemos calculadas estas cardinalidades, ¿cómo calculo las cardinalidades de las relaciones?
La respuesta es muy sencilla, tomando los valores máximos de las cardinalidades de cada una de las
entidades que une dicha relación. Por tanto, en nuestro caso tenemos:
La cardinalidad de la relación ‘alojado’ es M:N.
La cardinalidad de la relación ‘ubicada’ es 1:N.
La cardinalidad de la relación ‘asignada’ es 1:N.
La cardinalidad de la relación ‘emite’ es 1:N.
La cardinalidad de la relación ‘tener’ es 1:N
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
1.3. Identificando claves candidatas y elección de clave primaria.
El siguiente paso a dar es identificar las claves candidatas y elegir la clave principal.
¿Sabemos cómo identificar las claves en una entidad?
Estudiamos las entidades una a una, y recordamos que una clave es un atributo o conjunto de atributos
que identifica de manera única cada instancia de una entidad:
ENFERMO, como claves candidatas tenemos DNI y “ codigo_enfermo”, podemos seleccionar
cualquiera de ellas como clave principal. Elegimos DNI
DIAGNÓSTICO, tiene como única clave candidata “codigo_diagnostico”, por lo tanto es además su
clave principal.
MEDICO, como clave candidata sólo tenemos DNI, por lo que también es nuestra clave principal.
AUXILIAR, como clave candidata sólo tenemos DNI, por lo que también es nuestra clave
principal.
HABITACIÓN, como única clave candidata tenemos “numero_habitacion”, y por lo tanto es laclave
principal.
PLANTA, como clave candidata tenemos únicamente “numero_planta”, por lo que también es la clave
principal.
1.4. Estudio de otras características con el modelo Entidad
Relación Extendido.
¿Crees que ya hemos terminado con el estudio de nuestro diagrama?
Si observas con detenimiento los contenidos de la unidad, te fijarás que en determinadas ocasiones no se
puede representar ciertas características con el modelo Entidad-Relación y por eso surgió el modelo EER
(Entidad-Relación Extendido). Por tanto, aún nos queda estudiar si hay ciertas características a
implementar.
Al leer con detenimiento el enunciado del problema nos percatamos de que existe una gran similitud entre
las entidades AUXILIAR y MÉDICO, tanto en atributos, como en el papel que juegan dentro del
sistema de información. De ambas entidades se requiere almacenar la misma información, que sólo
difiere en el caso de la entidad MÉDICO, de la que deseamos guardar también el atributo ‘especialidad’,
por lo que podemos considerar una generalización de ambas entidades en una denominada
TRABAJADOR. El tipo de restricción que tendría sería TOTAL con EXCLUSIVIDAD. Es “total”
porque todos los trabajadores deben pertenecer a uno de los subtipos de la generalización y con
“exclusividad” porque si un trabajador es MÉDICO no puede ser a su vez AUXILIAR y viceversa.
Comprobamos que no hay ninguna otra característica del EER para nuestro caso de estudio pero antes de
representar el diagrama E/R, tendremos que comprobar que no exista redundancia en nuestro diagrama,
sobre todo si existe algún ciclo en nuestro diseño. En nuestro caso, ninguna de las relaciones que forman
el ciclo se puede eliminar porque no existe ningún camino alternativo para relacionar las entidades que
están unidas mediante las distintas relaciones.
Y por último tendremos que comprobar que se cumplen los criterios de calidad mencionados en la
unidad, es decir, la cualidad de ser completo, la corrección, la minimalidad, la sencillez , la legibilidad y
la flexibilidad del diagrama.
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
1.5. Representación del diagrama E/R.
Con todo el estudio realizado el diagrama E/R que deberíamos representar quedaría de la siguiente forma:
2.- Paso al Modelo Relacional
2.1. Paso a tablas de entidades y sus atributos.
Entidades que nos encontramos: HABITACION, PLANTA y ENFERMO como entidades fuertes,
y DIAGNOSTICO como entidad débil. De momento vamos a dejar las entidades
TRABAJADOR, MEDICO y AUXILIAR por ser un caso de generalización que trataremos en el
siguiente apartado como un caso especial.
Todas las entidades se convierten en tablas y sus atributos en sus propios campos. Las claves
primarias las pondremos en primer lugar y las identificaremos de forma subrayada y en negrita para
distinguirlas del resto de campos de la tabla. Así tenemos las siguientes tablas de momento:
HABITACION(num_habitacion, cant_camas, observaciones)
PLANTA(num_planta, cant_habitaciones, especialidad)
ENFERMO(DNI, cod_enfermo, nombre, direccion, telefono, fec_nac, edad)
DIAGNOSTICO(cod_diagnostico, fecha, informe)
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
Debemos recordar que las entidades débiles heredan los atributos de la clave primaria de la
entidad fuerte de la que dependen, por lo que la entidad DIAGNOSTICO hereda el campo DNI de
la entidad ENFERMO de la que depende. Es habitual modificar el nombre del campo heredado
si es necesario para evitar posibles ambigüedades o confusiones en la identificación de los
atributos heredados. Siguiendo esta recomendación nombramos el DNI de ENFERMO como
DNI_enfermo en la tabla DIAGNOSTICOpara tener presente en todo momento de dónde procede
dicho atributo. Así pues la tabla modificada quedaría:
DIAGNOSTICO(cod_diagnostico, fecha, informe, DNI_enfermo)
2.2. Paso a tablas de los casos especiales.
En este caso, tanto AUXILIAR como MÉDICO pueden considerarse claramente como casos de
especialización sobre la entidad TRABAJADOR. (O bien TRABAJADOR como una generalización
de MEDICOy AUXILIAR). Vamos a ver cómo se pasa a tablas este caso:
Pasamos la especialización a tablas: De entre las distintas posibilidades que tenemos para pasar
a tablas una especialización, nos quedamos con la opción de convertir las entidades especializadas
en tablas y no la generalización, es decir, pasamos a tablas las entidades MEDICO y AUXILIAR
y no TRABAJADOR debido a que existen atributos específicos de una de las entidades y además
cada una de ellas establece una relación concreta con otras entidades, lo que le da peso específico
para existir de manera independiente.
Debemos recordar que las entidades que componen la especialización heredan los atributos de
la entidad más general y se le añaden los atributos propios si los tuviera.
Con estos recordatorios podemos considerar:
MEDICO(DNI_medico, nombre, sueldo, direccion, telefono, especialidad)
AUXILIAR(DNI_auxiliar, nombre, sueldo, direccion, telefono)
2.3. Paso a tablas de las relaciones y posibles atributos.
Ya hemos generado las primeras tablas de las entidades y los casos especiales, vamos a realizar el paso
a tablas de las relaciones, para lo que debemos de fijarnos en el tipo de cardinalidad de la relación. Las
relaciones muchos a muchos siempre se convierten en tabla, las relaciones uno a uno dependerá
de las cardinalidades de las entidades que participan en la relación y las relaciones uno a muchos
normalmente se propagará la clave principal de la entidad que tiene la cardinalidad máxima 1 en el
diagrama E/R hasta la entidad que tiene la cardinalidad máxima N salvo algún caso excepcional.
Paso a tabla de las relaciones con cardinalidad muchos a muchos: La única relación de
muchos a muchos es la de “alojado” entre ENFERMO y HABITACIÓN, que además tiene atributos
propios.
Por tanto, optamos por la creación de la tabla alojado. La clave de esa nueva relación estará
constituida por los tres campos DNI, num_habitacion y fecha_entrada. El campo num_habitacion y DNI
son claves foráneas a sus respectivas tablas. Si nos fijamos en el campo fecha_entrada también pertenece
a la CP de esta tabla porque podríamos tener que un mismo enfermo ingrese en la misma habitación pero
en fechas de entrada distintas. Por eso, para poder identificar unívocamente cada ocurrencia de esta
tabla necesitaremos una clave primaria formada por estos tres campos.
alojado (num_habitacion, DNI, fec_entrada, fec_salida)
Paso a tabla de las relaciones con cardinalidad uno a uno: Si nos fijamos en el diagrama E/R no
disponemos en este caso de ninguna relación de este tipo.
Paso a tabla de las relaciones uno a muchos: Podemos observar que todas las relaciones de este
tipo tienen cardinalidad mínima uno de la entidad que participa a uno, por lo que todas las relaciones
son candidatas a propagar la clave primaria de la relación que participa con cardinalidad 1 a la
EJEMPLO HOSPITAL DIAGRAMA E/R y MODELO RELACIONAL
relación que participa con cardinalidad N. Así pues comencemos a propagar las claves y a modificar
las tablas iniciales que ya teníamos:
En la relación 1:N “ubicada” entre PLANTA y HABITACIÓN, se propaga la clave de la
entidad que participa con uno (PLANTA) a la tabla generada por la entidad que participa con
muchos (HABITACIÓN), quedando la tabla de la siguiente forma:
HABITACION(num_habitacion, cant_camas, observaciones, num_planta)
En la relación 1:N “emite” entre MÉDICO y DIAGNÓSTICO, se propaga la clave de la entidad
que participa con uno (MÉDICO) a la tabla generada por la entidad que participa con muchos
(DIAGNÓSTICO), quedando de la siguiente forma:
DIAGNOSTICO(cod_diagnostico, fecha, informe, DNI_enfermo, DNI_medico)
En la relación 1:N “asignada” entre AUXILIAR y PLANTA, se propaga la clave de la entidad
que participa con uno (PLANTA) a la tabla generada por la entidad que participa con muchos
(AUXILIAR), quedando la tabla de la siguiente forma:
AUXILIAR(DNI_auxiliar, nombre, sueldo, direccion, telefono, num_planta)
En la relación 1:N “presenta” entre DIAGNÓSTICO y ENFERMO, debemos recordar
que ya hemos propagado la clave de la entidad débil a la entidad fuerte de la que
depende, por lo que ya hemos realizado el paso a tabla de esta relación.
2.4. Representación del modelo relacional.
Para la representación del modelo relacional, identificaremos en cada una de las tablas resultantes las
claves primarias con un subrayado continuo y las claves foráneas o ajenas con un subrayado discontinuo.
Además, representaremos mediante una flecha las relaciones entre todas las tablas quedando la
representación de la siguiente forma:
