jueves, enero 26, 2006
Soluciones Prueba 1 - 26 de enero del 2006
Estimados,
Los diagramas antes expuestos, muestran las soluciones a la prueba acumulativa realizada esta mañana. Para el segundo problema, existen dos soluciones válidas (se muestran ambas).
Saludos,
Ing. Lamelas
lunes, enero 16, 2006
Proyecto de Clase
Definición General del Proyecto de Clase
El objetivo del presente proyecto es diseñar y construir una base de datos en el SGBD SQL Anywhere 9 de Sybase así como construir un aplicativo en un lenguaje visual de su elección que interactúe con dicha base de datos por medio de un driver ODBC.
Se desea una base de datos relacional y una aplicación que controle las distintas tareas de una unidad de soporte de tecnologías de información en una empresa cualquiera. La unidad cuenta con especialistas en tecnologías de la información (TI) de distinta formación, por lo que la unidad puede atender distintos tipos de solicitudes de soporte técnico. Cada tipo de solicitud puede contar con varias categorías (también parametrizables). Por ejemplo, una solicitud de soporte técnico de hardware puede contar con las siguientes categorías: impresora, cpu, monitor, ups, entre otras tantas. Una solicitud de soporte técnico de software puede contar con las categorías: sistema de información de la empresa, correo electrónico, procesador de texto, entre otras tantas.
De un especialista en TI se almacenan todos sus datos generales (nombres, apellidos, número de identidad, número de RTN (si tiene), e-mail, teléfono fijo, teléfono móvil (si tiene), pager (si tiene), dirección del domicilio, teléfono del domicilio, fecha de nacimiento, edad, sexo, y cualquier otro dato de identificación que se considere necesario). Un especialista en TI puede contar con uno o varios grados académicos superiores (secundaria técnico, técnico universitario, licenciatura, maestría, doctorado) y para cada grado, se deberá almacenar la universidad o centro técnico donde se formó, año en que se tituló y título obtenido (i.e. Ingeniero en Sistemas Computacionales, Licenciado en Informática Administrativa, Ingeniero en Ciencias de
Una solicitud de soporte técnico puede generarse desde cualquier departamento o división de la empresa. Toda solicitud, además de especificársele el tipo y la categoría, cuenta también con la siguiente información: Fecha y hora de la solicitud, nombre de la persona que hace la solicitud, breve descripción o título de la solicitud (i.e. La impresora reporta que está fuera de línea), detalle de la solicitud (una ampliación a la descripción del problema, con todos los datos que proporciona la persona que reporta el problema), estado de la solicitud (representa las distintas etapas por las que puede pasar una solicitud de soporte; por ejemplo: abierta, en proceso de solución, solucionada, no solucionada; los estados de una solicitud pueden variar de una empresa a otra por lo que los estados posibles deberían ser parametrizables).
Un especialista en TI puede ser asignado para que atienda una o varias solicitudes de soporte técnico, pero una solicitud sólo es asignada a un especialista en TI (por cada solicitud sólo hay un especialista responsable de la misma). Se deberá almacenar la fecha y hora de la asignación. Si la solicitud no ha sido resuelta, se puede cambiar el especialista en TI responsable de dicha solicitud (re-asignación de funciones) y se deberá guardar la fecha y hora de la re-asignación. Se deberá guardar en la base el motivo de la re-asignación (los motivos posibles deberán ser parametrizables). Una solicitud sólo puede ser re-asignada una vez.
Una solicitud de soporte técnico puede tener asociada una o varias soluciones. De cada solución, se deberá registrar lo siguiente: Descripción de la solución o diagnóstico, fecha y hora de la solución, nombre(s) de el(los) especialista(s) en TI que participó(aron) en la solución del problema o solicitud, recursos requeridos para la solución (si aplica). Si una solicitud de soporte técnico no se puede solucionar, se deberán almacenar los motivos de su no solución (esto para que el administrador o coordinador de los especialistas en TI pueda re-asignar una solicitud o se conozcan las causas más comunes por las que no se resuelven problemas en la unidad).
Algunas solicitudes de soporte técnico podrían requerir de ciertos recursos para su solución. Por ejemplo, si la solicitud era que el CPU no encendía y el diagnóstico o solución fue: “se requiere cambiar la fuente de poder”, entonces, dicha solicitud requiere para su solución de una nueva fuente de poder. Un especialista en TI deberá indicar los recursos requeridos para una solución; sin embargo, el administrador o coordinador de los especialistas en TI es la persona que deberá aprobar los recursos requeridos.
Se requiere que el sistema de soporte técnico que se desarrolle cuente con un sub-sistema de control de accesos. Lo anterior se requiere porque existen distintos tipos de usuarios del sistema con distintos niveles de acceso.
Existen usuarios que ingresan las solicitudes de soporte técnico al sistema.
Existen usuarios del tipo administradores de sistema que tienen acceso para asignar o re-asignar solicitudes a especialistas de TI. Igualmente, los administradores de sistema son los que tienen el acceso para generar todos los reportes y/consultas asociadas al rendimiento y carga de trabajo de todos los especialistas en TI. Un administrador de sistema podrá ver todas las solicitudes asignadas a cada especialista en TI así como los recursos requeridos para completar la solución de una solicitud.
Finalmente, existen usuarios del tipo especialista en TI que sólo tiene acceso a solucionar las solicitudes de soporte asignadas a él(o ella). Un especialista en TI podrá generar reportes y/o consultas asociados a su propio rendimiento así como a su carga de trabajo. Un especialista en TI podrá seleccionar recursos disponibles para una solución; no obstante, hasta que esos recursos sean aprobados por un administrador, entonces la solicitud podrá darse como cerrada.
Descripción del Proyecto
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).
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 (3 puntos)
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). (3 puntos)
Ejecutar en el aula de clases en la base de datos Sybase SQL Anywhere del proyecto las sentencias de llenado de las tablas antes creadas con datos de muestra de distinta índole. (2 puntos)
C. Construir un aplicativo en un lenguaje de programación visual que interactúe con el SGBD Sybase Adaptive Server Anywhere 9. (10 puntos)
Por medio del aplicativo visual se deben poder realizar las siguientes operaciones de mantenimiento en la base de datos:
a) Crear, borrar o modificar los datos generales de los especialistas en TI. (2 punto)
b) Crear, borrar o modificar tipos y categorías de solicitudes de soporte. (2 punto)
Por medio del aplicativo visual se deben poder realizar las siguientes transacciones sobre la base de datos:
c) Ingresar solicitudes de soporte técnico. (2 puntos)
d) Realizar asignaciones de solicitudes de soporte a especialistas de TI. Se requiere mostrar una re-asignación de una solicitud a otro especialista en TI indicando el motivo de la nueva asignación. (2 puntos)
e) Asociar soluciones a solicitudes de soporte técnico y mostrar una solución en donde el especialista en TI indique que se requiere de un recurso para poder solucionar el problema. Por su parte, el coordinador o administrador de especialistas en TI deberá aprobar el recurso para que el especialista pueda cerrar o dar por solucionada la solicitud. (2 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: (5 puntos)
a) Mostrar a una fecha determinada, todas las solicitudes de soporte en proceso de solución (incluyendo: identificación de la solicitud, breve descripción de la solicitud, fecha de la solicitud, hora de la solicitud, fecha de la asignación, hora de la asignación y nombre del especialista en TI responsable) y todas las solicitudes de soporte NO asignadas a algún especialista en TI (incluyendo: identificación de la solicitud, breve descripción de la solicitud, fecha de la solicitud y hora de la solicitud). (1 punto)
b) Mostrar todas las solicitudes de soporte que requieren recursos para su solución (incluyendo: identificación de la solicitud y breve descripción de la solicitud) especificando el recurso o los recursos requeridos para cada solicitud así como el especialista en TI que requirió el recurso. (1 punto)
c) Mostrar todas aquellas solicitudes de soporte (identificación de la solicitud y breve descripción de la misma) que en su solución participaron más de un especialista en TI. Incluir nombre de los especialistas en TI que participaron en la solución (incluyendo al especialista en TI responsable de la solicitud). (1 punto)
d) Mostrar el nombre completo y niveles de especialización (mayores y menores) de aquellos especialistas en TI NO asignados a solicitud de soporte alguna. (1 punto)
e) Mostrar todas las solicitudes de soporte que fueron re-asignadas, incluyendo la siguiente información: Identificación de la solicitud, breve descripción de la solicitud, f echa, hora y especialista de TI asignados originalmente y la fecha, hora y especialista de TI re-asignado así como el motivo de la re-asignación. (1 punto)
Condiciones Generales del Proyecto
· El proyecto tiene un valor total de 30 puntos ORO y deberá ser presentado por ambos integrantes del equipo el día que les corresponda (si uno de los miembros del equipo NO se presenta, perderá los puntos correspondientes a esa revisión. Si un grupo NO se presenta el día que le corresponda, perderá 5 puntos ORO por cada día de atraso). A partir de la segunda entrega de la presentación del proyecto, cada equipo deberá traer un computador desde donde le mostrará al profesor el 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á los días: 1 y 2 de febrero y comprende el punto A de la descripción del proyecto. La segunda entrega se realizará los días: 22 y 23 de febrero y comprende el punto B de la descripción del proyecto. La tercera y última entrega se llevará a cabo los días: 15 y 16 de marzo 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 y carga de datos; 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 y un CD que contenga el aplicativo desarrollado y la base de datos Sybase SQL Anywhere.
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
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. También, se deberá incluir la base de datos final con los datos de muestra.
· 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 blog site (por medio del blogger.com). En este blog site, se deberán colocar avances semanales en el desarrollo de su proyecto así como problemas con los cuales se hayan encontrado. En el blog site: flamelas.blogspot.com se encuentra una nota que contiene el directorio de los blog sites de todos los grupos de proyecto (cada grupo deberá remitir por correo electrónico su dirección para poder subir esta información al blog site antes enunciado). La idea es que cada grupo pueda visitar todos los blogs y pueda aportar ideas o soluciones a problemas detectados en el desarrollo de cada proyecto.
· 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.
Calendarios de Entregas por Grupo
| Grupo | Primera Revisión | Segunda Revisión | Tercera Revisión |
| 1 Jorge Hernández y Donaldo Amaya | 1/02 | 23/02 | 15/03 |
| 2 Saúl Villaseñor e Iván Ordóñez | 1/02 | 23/02 | 16/03 |
| 3 Luis Melgar y Elvin Carrasco | 1/02 | 23/02 | 15/03 |
| 4 Héctor Pagoaga y Léster López | 2/02 | 22/02 | 16/03 |
| 5 Denis Jirón y Ana García | 2/02 | 22/02 | 15/03 |
| 6 Román Pineda y Rony López | 2/02 | 22/02 | 16/03 |
| 7 German Aguilar y Ricardo Palma | 2/02 | 22/02 | 15/03 |
| 8 Mario Rodríguez y Arturo Barahona | 1/02 | 23/02 | 16/03 |
| 9 Geofrey Burgos y Mario Henríquez | 2/02 | 22/02 | 15/03 |
| 10 José Chajtur y Tommy Ponce | 1/02 | 23/02 | 16/03 |
viernes, enero 13, 2006
Directorio de BLOG Sites TBD 1 - Primer Semestre 2006
Adjunto a continuación los links a los primeros blog sites remitidos por los integrantes de los grupos de proyecto de Bases de Datos I:
Denis Jirón(10211183) y Ana del Carmen Olivera: djacog.blogspot.com
Iván Ordóñez y Saúl Villaseñor: villaordonez.blogspot.com
Héctor Ramiro Pagoaga:ldlbhrpm.blogspot.com
Ricardo Palma y German Aguilar: palmaaguilarbd.blogspot.com
Jorge Hernández Soto y Donaldo Amaya:2team.blogspot.com
José Chajtur y grupo: bddcp.blogspot.com
Geofrey Burgos y Mario: mario-geff.blogspot.com
Arturo Barahona y grupo: rodriguezbarahona.blogspot.com
Saludos,
Ing. Lamelas
jueves, enero 12, 2006
Ejemplo de Diseño de una Base de Datos Relacional
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.
