El BLOG de FLamelas

En esta práctica se realizará el diseño e implementación de una pequeña base de datos que guarde información de pacientes que ingresan en un hospital. En este hospital, los pacientes que llegan al servicio de urgencias del hospital son examinados y, dependiendo de su estado de salud, son ingresados en la unidad correspondiente (traumatología, cuidados intensivos, ...) bajo la supervisión de un médico responsable.

Para este ejemplo se llevarán a cabo las tres etapas de diseño de bases de datos (diseños conceptual, lógico y físico) teniendo en cuenta la especificación anterior.

Además de la especificación del esquema, se impondrán restricciones

de integridad sobre él.

Diseño conceptual

En este apartado se muestra el diseño conceptual de la base de datos relacional que resuelve los requerimientos antes expuestos.

1. Identificación de entidades.

La entidad que surge inmediatamente es Pacientes. Otras entidades posibles son Médicos e Ingresos. La primera se refiere a los médicos que son responsables de los pacientes y la segunda al ingreso en el hospital. Las entidades modelan en general tanto objetos y personas (pacientes y médicos) como acciones (ingresos).

Podrían surgir las siguientes preguntas:

• ¿Por qué no eliminar Médicos y hacer que forme parte como atributos de Pacientes? Como un médico será responsable en general de varios pacientes, repetir la información del médico para cada paciente no es buena idea.

• ¿Por qué no eliminar Ingresos y hacer que forme parte como atributos de

Pacientes? Un paciente puede ingresar varias veces en el hospital y tener asignado en cada ocasión diferentes médicos, con lo que nos encontraríamos con atributos multivalorados.

2. Identificación de atributos.

A cada tipo de entidad se le debe asignar tantos atributos como sea necesario en la especificación del problema.

• Entidad Pacientes:

Número de Seguridad Social

Nombre del paciente

Apellidos del paciente

Domicilio

Población

Departamento

Número de teléfono

Número de historial clínico

Observaciones

• Entidad Ingresos:

Procedencia

Fecha de ingreso

Número de planta

Número de cama

Observaciones

• Entidad Médicos:

Código de identificación del médico

Nombre

Apellidos

Especialidad

Número de colegiado

Cargo

Observaciones

¿Por qué no poner un atributo Nombre del hospital? Es una información implícita.

3. Identificación de relaciones

Por una parte tenemos pacientes que realizan ingresos y, por otra, médicos que atienden a pacientes. Según esto aparecen dos relaciones:

Realiza: Pacientes × Ingresos y Atiende: Ingresos × Médicos.

Ninguna de ellas tiene atributos asociados

4. Identificación de restricciones

4.1. Restricciones de clave primaria para las entidades

En las entidades Pacientes y médicos parece claro:

• Entidad Pacientes: Número de historial clínico.

• Entidad Médicos: Código de identificación del médico.

Sin embargo, en la entidad Ingresos hay varios atributos que, aisladamente, no parecen formar clave. El ingreso depende de un paciente en concreto, por lo que esta entidad debería guardar información de a qué paciente corresponde. De hecho, se podría pensar que se trata de un tipo de entidad conocida como débil, que debería tomar prestado el atributo clave de Pacientes para formar clave. Pero no es suficiente, es necesario añadir al menos la fecha en que ingresó el paciente. Pero, ¿qué ocurre si el paciente ingresa dos veces en el mismo día? … habría que añadir otro atributo, como la hora, para indicarlo.

Tras realizar el análisis anterior, se elige para la entidad ingresos un nuevo atributo sin significado que sirva únicamente para identificar unívocamente a las entidades de tipo Ingresos. En este caso usaremos un atributo denominado ID (de identificador de ingreso). En ese caso, la entidad ingresos ya no será débil pero sí tendrá una participación total con respecto a la entidad Pacientes.

• Entidad Ingresos: ID

4.2. Restricciones de cardinalidad

Relación Realiza:

• Pacientes -1- Realiza - Ingresos: Un ingreso sólo corresponde a un

paciente.

• Pacientes - Realiza -N- Ingresos: Un paciente puede sufrir varios

ingresos.

Relación Atiende:

• Médicos -1- Atiende - Ingresos: Un ingreso sólo es atendido por un

médico.

• Médicos - Atiende -N- Ingresos: Un médico puede atender varios

ingresos.

5. Diagrama E-R

Con la información identificada anteriormente se puede llegar al siguiente diagrama entidad-relación (realizado en el S/W Dia v 0.94), en el que NO se muestran los atributos que no sean clave primaria para simplificar el dibujo del ejemplo.

Diseño lógico

1. Traducción de tipos de entidades y relaciones al esquema relacional

Tablas procedentes de los tipos de entidades del Diagrama E-R:

• Pacientes(Número de Seguridad Social, Nombre del paciente, Apellidos

del paciente, Domicilio, Población, Departamento, Número de teléfono, No_Hist_Clinico, Observaciones)

• Ingresos(ID, Procedencia, Fecha de ingreso, Número de planta, Número de cama, Observaciones)

• Médicos(Cod_Id_Med, Nombre, Apellidos, Especialidad, Número de colegiado, Cargo, Observaciones)

2. Simplificación del esquema relacional (Esquema Definitivo)

Observando cómo queda el diseño, se puede simplificar gracias a que las relaciones que aparecen son de una a varias, e incluir esta información en la tabla Ingresos.

Por la relación Realiza, incluimos el atributo Número de historial clínico en Ingresos, de forma que a cada ingreso le va a corresponder un paciente en concreto y sólo uno. De igual forma, por la relación Atiende, incluimos el atributo Código de identificación del médico en Ingresos, de forma que a cada ingreso le va a corresponder un médico en concreto y sólo uno.

Esta técnica es la que se usa cuando nos encontramos relaciones una a varias.

Por lo tanto, el esquema simplificado es el siguiente:

• Pacientes(Número de Seguridad Social, Nombre del paciente, Apellidos del paciente, Domicilio, Población, Departamento, Número de teléfono, No_Hist_Clinico, Observaciones)

• Ingresos(ID, Procedencia, Fecha de ingreso, Número de planta, Número

de cama, Observaciones, Número de historial clínico, Código de identificación del médico)

• Médicos(Cod_Id_Med, Nombre, Apellidos, Especialidad, Número de colegiado, Cargo, Observaciones)

3. Restricciones de integridad

Según el enunciado del problema no parece que se puedan definir dependencias funcionales ni multivaloradas en ninguna de las tablas, por lo que se encuentran en la mejor forma normal que podamos exigir y no tiene sentido la normalización.

Sin embargo, sí es posible imponer restricciones de integridad referencial, observando que los atributos añadidos a Ingresos resultados de la simplificación provienen de tipos de entidades, y sabemos que debemos imponerlas para tales atributos. En concreto, el valor del campo Número de Seguridad Social de Ingresos lo debemos encontrar en Pacientes, así como el valor del campo Código de identificación del médico lo debemos encontrar en Médicos.

Diseño físico

En este apartado se muestran los lineamientos a seguir para el diseño físico de la base de datos del Hospital. Estos lineamientos deberán ser adecuados a las facilidades que provee el SGBD seleccionado.

Definición de los campos

Los tipos de campo, así como la definición de su tamaño permiten definir las restricciones de dominio que se refieren al tamaño y al tipo de los datos de un campo.

Para cada campo es posible especificar que no contenga valores nulos (es decir, imponer como restricción de dominio la eliminación del valor NULL del dominio del campo). También es posible especificar que si se trata de una cadena de caracteres, ésta no sea vacía.

Más adelante, cuando se estudien las propiedades de las tablas, se verá que también es posible especificar restricciones de dominio en función de valores de otros campos, es decir, restricciones en el contexto de la tabla.

A continuación se estudiará cómo se realiza la definición de los campos.

Nombre de los campos

Deben estar identificados por nombres únicos dentro del contexto de la base de datos.

Tipos de campos

Esto depende de las opciones que provee el SGBD pero básicamente se pueden mencionar los siguientes tipos de datos: INT, CHAR(n), VARCHAR(n), DATE, TIME, FLOAT, REAL, DECIMAL(n,p) entre otros tantos. (Para conocer todas las opciones disponibles hay que consultar la ayuda que provee el fabricante del SGBD).

Propiedades de los campos

Además del tipo de campo, es posible especificar otras propiedades de los campos, como su tamaño. Con el tamaño se consigue restringir aún más el tipo de campo para que concuerde con nuestras necesidades. No todos los tipos admiten expresar un tamaño de campo. Algunos tipos tienen un tamaño predeterminado que no se puede modificar (i.e. REAL, INT, FLOAT).

Reglas de validación (constraints o restricciones) de los campos

Las reglas de validación permiten especificar restricciones que deben cumplirse para los valores de un campo en particular o varios campos. Por ejemplo, la regla de validación puede ser >=0 (mayor o igual que cero) para un campo de tipo dinero.

Índices

Se pueden construir índices sobre campos aislados de una tabla o sobre un conjunto de ellos. Los índices se usan para mejorar los tiempos de respuesta con respecto a una consulta (o consultas) y los mismos se construyen luego de haberse preparado las consultas. Por lo general (aunque no se trata de una regla), si en un cláusula WHERE de una consulta aparece un campo que no forma parte de la clave primaria o de una clave foránea, se puede considerar dicho campo como un candidato a índice.