El BLOG de FLamelas

El objetivo del presente proyecto es diseñar y construir una base de datos en el SGBD SQL Anywhere 9.0.2 de Sybase así como construir un aplicativo en el lenguaje visual de su elección que interactúe con dicha base de datos por medio de un driver ODBC, JDBC u OLEDB.

La Oficina de Registro del MIN (Museo de la Identidad Nacional) desea que se le diseñe y construya una base de datos y una aplicación que le permita llevar un mejor control sobre el inventario de los bienes culturales que son administrados por el MIN.

El MIN cuenta con una serie de salas que pueden ser de dos tipos: Exhibición Permanente y Exhibición Temporal. Las salas se identifican por medio de un código alfanumérico único; de las salas se desea guardar también: espacio en mts. cuadrados, nombre completo del responsable de la sala (que es un personal de tipo administrativo con cargo de Coordinador), cantidad de lámparas y cantidad de vitrinas. Se desea llevar un control de cada vitrina disponible en cada sala, esto porque en una sala pueden existir vitrinas de distinta forma que deben ser identificables de alguna manera.

Las salas de Exhibición Permanente cuentan con un nombre y una breve descripción de la sala (que ilustra a los visitantes sobre el contenido de los bienes que se exhiben de manera permanente en dicha sala). Por su parte, las salas de Exhibición Temporal cuentan con: nombre de la colección que se exhibe, nombre del museo propietario de la colección, cantidad de piezas que se exhiben, periodo de tiempo de la exhibición (fecha inicial y fecha final).

El MIN cuenta con personal que se puede catalogar de dos tipos: administrativo y técnico. El personal se identifica por medio del número de identidad (en el caso de hondureños) y por el número de pasaporte (en el caso de extranjeros). Adicionalmente, se desea almacenar la siguiente información del personal: nombre completo (nombres y apellidos), domicilio, teléfono del domicilio, teléfono móvil (si posee), correo electrónico, formación académica (primaria/secundaria/universitaria). Todo personal del MIN que sea técnico cuenta adicionalmente con un título (por ejemplo: “curador”, “conservador”, “museógrafo”) y con una serie de especialidades (por ejemplo: frescos, óleo, escultura, orfebrería, entre otros). Por su parte, el personal administrativo cuenta con una cargo (por ejemplo: registrador, coordinador, electricista, carpintero, instalador, vigilante, entre otros).

Un personal de tipo administrativo puede ser responsable de más de una sala del MIN; sin embargo, una sala sólo cuenta con una persona responsable.

Los bienes culturales son identificados por medio de un código único y cuentan además con: nombre, autor, año de realización (si se conoce), antigüedad, clasificación de la obra (pintura/escultura/dibujo), fecha y hora de ingreso al MIN, tipo del ingreso (donación/compra/canje/reubicación) y una historia breve del bien. También se desea almacenar en la base de datos una imagen del bien, de igual forma, se requiere que en el aplicativo se pueda ver una imagen pequeña (thumbnail) del bien.

Del autor de cada bien se desea almacenar: código único de identificación, nombre completo (nombres y apellidos), domicilio, nacionalidad, teléfono del domicilio, correo electrónico (si posee), fecha de nacimiento y edad. Cabe destacar que una obra puede ser realizada por más de un autor y que un autor puede ser el creador de más de un bien.

Un bien cultural cuando ingresa al MIN se ingresa a la Oficina de Registro y una vez codificado el bien, el mismo es ubicado posteriormente en alguna vitrina de una sala de acuerdo a la exposición que se realizará; no obstante, como en una sala pueden coexistir bienes de distinta índole que no necesariamente requieren de alguna vitrina, un bien se ubica directamente en una sala. El aplicativo que se desarrolle deberá indicar dónde se encuentra ubicado exactamente cada bien a una fecha y hora determinada y por qué motivo se encuentra en dicha ubicación; esto es, si aún no ha sido ubicado (por encontrarse en el proceso de registro), en qué sala y vitrina (si el bien requiere de vitrina) o sólo en qué sala (si se trata de bienes que se ubican en las paredes, como es el caso de los cuadros).

En el sistema, cuando un bien es ubicado en alguna sala, se deberá registra la fecha y hora en que el bien ingresa a la sala; igualmente, se deberá registrar el motivo del ingreso a dicha sala. Igualmente, si un bien es movido a otra sala, en el sistema se deberá registrar la fecha y hora en que el bien sale de dicha sala y el motivo por el cual el bien se traslada a otra sala.

El sistema deberá llevar un registro de todos los movimientos que ha experimentado un bien (desde el momento mismo en que ingresa a la Oficina de Registro hasta su ubicación actual).

Se requiere que el aplicativo que se desarrolle cuente con un sub-sistema de control de accesos. Lo anterior se requiere porque existen distintos tipos de usuarios en el sistema con distintos niveles de acceso. Se deberá validar que aquellos usuarios con acceso al sistema (no todo el personal del MIN contaría con un usuario en el sistema) sólo puedan visualizar y operar las pantallas que se enuncian a continuación.

Existen usuarios que mantienen actualizada la información del personal que labora en el MIN. Se trata de usuarios tipo COORDINADOR y básicamente deberán tener acceso a realizar: Alta/Baja/Cambio del Personal en el sistema así como Alta/Baja/Cambio de las Salas y Alta/Baja/Cambio de las Vitrinas que existen en el MIN.

Por su parte existen usuarios del tipo REGISTRADOR que realizan el: Alta/Baja/Cambio de los bienes culturales en el sistema y el Alta/Baja/Cambio de los autores de bienes. Igualmente, los usuarios de tipo REGISTRADOR tienen acceso a ingresar la ubicación inicial de los bienes culturales (luego de que estos han sido inventariados en la Oficina de Registro) así como a mover los bienes de una sala a otra, indicando la fecha, hora y motivo de los movimientos.

Tanto los usuarios de tipo COORDINADOR y REGISTRADOR pueden accesar las pantallas de movimientos experimentados por un bien y ambos tipos de usuarios pueden consultar la ubicación de un bien a una fecha y hora determinada y conocer el motivo por el cual el bien se encuentra en dicha sala.

A. Elaborar un documento impreso que contenga el Diseño Conceptual de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com) (5 puntos).

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Identificación de Entidades y criterios usados para su selección.

b. Identificación de atributos por Entidad.

c. Identificación de Relaciones o Vínculos existentes y criterios usados para su selección.

d. Identificación de Restricciones de Clave Primaria para las Entidades.

e. Identificación de Restricciones de Cardinalidad de las Relaciones identificadas.

f. Diagrama Entidad-Relación (E-R) construído con el software DIA.

B. Elaborar un documento impreso que contenga el Diseño Lógico y Físico de la base de datos relacional que resuelva los requerimientos expuestos. El documento en cuestión usará los lineamientos generales contenidos en el Ejemplo de Diseño de una Base de Datos Relacional colocado en el blog de la clase (flamelas.blogspot.com). Adicionalmente, el documento contendrá las sentencias DDL del Modelo Relacional. Dichas sentencias se construirán usando la sintaxis SQL del SGBD Sybase Adaptive Server Anywhere 9 tomando en cuenta TODAS las restricciones de integridad necesarias (llaves primarias, llaves foráneas, referencias relacionales, checks). (10 puntos)

Los apartados del documento deberán ser estos (además de contar con una portada y tabla de contenido):

a. Esquema Relacional (2 puntos)

b. Sentencias DDL del SQL de Sybase (1 punto)

Ejecutar en el aula de clases en la base de datos Sybase SQL Anywhere del proyecto, las sentencias DDL (que incluyen las tablas, vistas y demás objetos identificados) así como las sentencias de llenado de las tablas antes creadas con datos muestra (básicamente se deberán llenar TODAS las tablas MAESTRAS). (2 puntos)

Presentar TODAS las pantallas con las que se satisfarán los requerimientos estipulados en el punto C de esta misma sección (en esta entrega se evaluará sólo presentación o diseño de las pantallas). (5 puntos)

C. Construir un aplicativo en un lenguaje de programación visual que interactúe con el SGBD Sybase Adaptive Server Anywhere 9. (13 puntos)

Por medio del aplicativo visual se deben poder realizar las siguientes operaciones de mantenimiento y consulta en la base de datos:

a) Utilizando un usuario tipo COORDINADOR: Crear, borrar, modificar y visualizar los datos de distintos tipos de personal. (2 puntos)

b) Utilizando un usuario tipo COORDINADOR: Crear, borrar, modificar y visualizar los datos de: Salas y de Vitrinas. (3 puntos)

c) Utilizando un usuario tipo REGISTRADOR: Crear, borrar, modificar y visualizar los datos de: Bienes Culturales y de Autores. (3 puntos)

Por medio del aplicativo visual se deben poder realizar las siguientes transacciones sobre la base de datos:

d) Ingresar ubicación inicial de bienes (utilizando un usuario tipo REGISTRADOR). (2 puntos)

e) Realizar movimientos de bienes entre salas (utilizando un usuario tipo REGISTRADOR). (3 puntos)

D. Por medio del aplicativo visual se debe poder satisfacer los siguientes requerimientos de información por medio de consultas a pantalla o de reportes (utilizando un usuario tipo: COORDINADOR o REGISTRADOR): (2 puntos)

a) Mostrar a una fecha determinada, la ubicación de todos los bienes registrados en el sistema. Se deberá presentar: código del bien, nombre del bien, motivo por el cual el bien se encuentra en dicha ubicación. (1 punto)

b) Mostrar el historial de movimientos que ha experimentado un bien (que puede ser cualquiera). Se deberá presentar: código del bien, nombre del bien, fecha y hora de ingreso del bien en cada ubicación, motivo del ingreso, fecha y hora de salida del bien en cada ubicación, motivo de la salida. (1 punto)

· El proyecto tiene un valor total de 30 puntos ORO y deberá ser presentado por ambos integrantes del equipo en el AULA DE CLASES el día que les corresponda.

· Si uno de los miembros del equipo NO se presenta el día de la presentación del proyecto y la causa de su ausencia NO ES JUSTIFICADA, perderá los puntos correspondientes a esa revisión.

· Si un grupo NO se presenta el día que le corresponda, perderá 2.5 puntos ORO por cada día de atraso en la primera entrega, 5 puntos ORO por cada día de atraso en la segunda entrega y 7.5 puntos ORO por cada día de atraso en la tercera entrega.

· A partir de la segunda entrega de la presentación del proyecto, cada equipo deberá traer un computador desde donde le mostrará al profesor distintos aspectos del proyecto desarrollado.

· El proyecto será presentado en tres (3) entregas (La primera con un valor de 5 puntos ORO, la segunda con un valor de 10 puntos ORO y la tercera con un valor de 15 puntos ORO. La primera entrega se efectuará el día: 3 de agosto y comprende el punto A de la descripción del proyecto. La segunda entrega se realizará los días: 30 y 31 de agosto y comprende el punto B de la descripción del proyecto. La tercera y última entrega se llevará a cabo los días: 19 y 20 de septiembre y comprende los puntos C y D de la descripción del proyecto.

· En la primera entrega, cada grupo sólo deberá entregar su documento. Durante la segunda y tercera entrega, además de la entrega de documentos se harán revisiones en el aula de clases (segunda entrega, revisión de scripts DDLs/carga de datos y de pantallas del aplicativo; tercera entrega, revisión de interacción del aplicativo visual desarrollado con la base de datos creada en las fases anteriores).

· Los documentos de la primera y segunda entrega serán revisados por el profesor y serán entregados hasta el día lunes de la siguiente semana con las correcciones sugeridas para cada caso. Cada grupo deberá aplicar dichas correcciones antes de proceder con las siguientes etapas del proyecto.

· En la última entrega, cada grupo deberá presentar la versión final impresa del documento del diseño de la base de datos relacional, un manual de usuario donde se muestre el uso del aplicativo desarrollado y un CD que contenga el aplicativo desarrollado y la base de datos Sybase SQL Anywhere creada.

El documento impreso deberá contener:

o Portada

o Tabla de contenido

o Introducción

o Objetivos

o Versión corregida del Diseño Conceptual

o Versión corregida del Diseño Lógico y Conceptual

o Conclusiones

o Bibliografía

o Anexos (Manual de Usuario)

El CD deberá contener los códigos fuente y objeto del software de aplicación desarrollado. Se deberán incluir los scripts DDLs de creación de la base de datos y los scripts de llenado de tablas. Se deberá incluir la base de datos final con los datos de muestra. Igualmente, se deberá incluir el manual de usuario.

· Toda consideración que se haga en el proyecto, deberá estar debidamente documentada y justificada en los distintos documentos donde se aplique.

· Cada grupo deberá construir y darle mantenimiento a un ciberdiario (blog site) (usando las facilidades que provee el blogger.com). En este blog site, se deberán colocar avances semanales en el desarrollo del proyecto. Cada grupo deberá enviarme por correo electrónico la dirección de su blog.

· La descripción del proyecto representa los productos mínimos esperados en este proyecto y se podrán otorgar puntos adicionales sólo si el proyecto excede las expectativas de todos los productos mínimos esperados en el mismo.

· El calendario de entregas por grupo se muestra al final de este documento.

Grupo	Primera Revisión	Segunda Revisión	Tercera Revisión
1 Juan Diego Prudot y Gabriel Molina	03/08	30/08	20/09
2 Raúl Zepeda y Mario José Padilla	03/08	31/08	19/09
3 Allan Edgardo Martínez y Dennis Eduardo Rodríguez	03/08	30/08	20/09
4 Dennis Jirón y Elías Ernesto Flores	03/08	31/08	19/09
5
6
7

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.