Escolar
Profesor: Fernando Sáenz
Práctica 1.1. Ejemplo de diseño de bases de datos relacionales
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, dependiendode su estado de salud, son ingresados en la planta 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. La implementación se realizará en el SGBDR Access. Además de la especificacióndel esquema, se impondrán restricciones de integridad sobre él.
1.1.1.
Diseño conceptual
En este apartado se muestran las dos primeras etapas (diseño conceptual y diseño lógico) del diseño de bases de datos relacionales.
1.1.1.1.
Identificación de entidades.
La entidad que surge inmediatamente es Pacientes. Otras entidades posibles son Médicos e Ingresos. La primera se refiere alos 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 lainformació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
•
1
Bases de datos y sistemas de información
Profesor: Fernando Sáenz
asignado en cada ocasión diferentes médicos, con lo que nos encontraríamos con atributos multivalorados.1.1.1.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. Provincia Código postal. Número de teléfono. Número de historial clínico. Observaciones • Entidad Ingresos: Procedencia. Fecha deingreso. 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.
2
Bases de datos y sistemas de información
Profesor: Fernando Sáenz
1.1.1.3.
Identificación de relaciones
Por unaparte 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
1.1.1.4.
1.1.1.4.1. • •
Identificación de restricciones
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 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. En la práctica, se elige muchas veces usar un nuevo atributo sin significado que sirva únicamente para...
Regístrate para leer el documento completo.