Embed Size (px)
Citation preview
Ministerio de Educación Superior Universidad Central “Marta Abreu” de Las Villas Facultad de Matemática, Física y Computación
Licenciatura en Ciencias de la Computación
Trabajo de Diploma
Capa para la consulta de Nefrología
Autor: David García Infante
Tutor: MSc. María Elena Martínez del Busto
SANTA CLARA
- 2007-
Hago constar que el presente trabajo fue realizado en la Universidad Central Marta
Abreu de Las Villas como parte de la culminación de los estudios de la especialidad de
Ciencias de la Computación, autorizando a que el mismo sea utilizado por la
institución, para los fines que estime conveniente, tanto de forma parcial como total y
que además no podrá ser presentado en eventos ni publicado sin la autorización de la
Universidad.
________________
Firma del autor
Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según
acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que
debe tener un trabajo de esta envergadura referido a la temática señalada.
______________ ________________________
Firma del tutor Firma del jefe del Seminario
Dedicatoria A mi familia, y a mi novia que tanto me ha ayudado, a las personas que siempre
confiaron en que yo si podía, a los que nunca creyeron en mí, y en especial a DIOS que
sin el nada es posible.
Agradecimientos A mis amigos Rainer Lara, Alejandro Villa y Guillermo Abreu que fueron de gran
ayuda; a mi familia de Remedios que me dio todo su apoyo; a Daniel Castro, Arley
Vázquez y Maikel León por ser fuente de conocimientos; a mis compañeros de aula, en
especial a Darianny Figuero por estar siempre ahí; a mis compañeros de cuarto; a
Lester Núñez y Yoel Lorenzo que me ayudaron a llegar hasta aquí; a mi tutora
Marielena Martínez del Busto y su esposo Luis Felipe y a todo el que de una forma u
otra hizo posible la realización de este proyecto.
Resumen Las enfermedades renales son cada vez más comunes y de complejo seguimiento; el
trasplante es una alternativa decisiva para un gran número de pacientes. El manejo de
la información necesaria para el control de estos receptores potenciales durante y
después de una intervención quirúrgica, incluyendo donantes vivos o muertos es
voluminoso teniendo en cuenta que el tiempo resulta ser un factor crítico. Se quiere
contar con un sistema automatizado que permita gestionar la información de forma ágil
y precisa. Por esta razón y en la ausencia de sistemas similares se comenzó el desarrollo
de un software con este propósito.
Abstract Renal diseases are more and more common and also complex to pursuit. Transplant is a
decisive alternative for a great number of patients. The handling of the necessary
information for the control of these potential receivers during and after surgery,
including the information of alive or dead donors is voluminous considering that time
turns out to be a critical factor. An automated system that allows managing the
information in a fast and precise way is needed. For this reason, and due to the absence
of a similar system, the project for the development of software was carried out.
Índice
INTRODUCCIÓN .................................................................................................................................... 1
HIPÓTESIS DE LA INVESTIGACIÓN ........................................................................................................... 2 OBJETIVO GENERAL ................................................................................................................................ 3 OBJETIVOS ESPECÍFICOS ......................................................................................................................... 3
CAPÍTULO 1. EMPLEO DE TECNOLOGÍAS Y HERRAMIENTAS COMPUTACIONALES EN LA GESTIÓN Y EL CONTROL DE LOS PACIENTES CON TRASPLANTE RENAL. ............... 4
1.1 MODELO CLIENTE/SERVIDOR ............................................................................................................ 5 1.1.1 Características funcionales ...................................................................................................... 6 1.1.2 Características físicas .............................................................................................................. 7 1.1.3 Características lógicas ............................................................................................................. 8 1.1.4 Ventajas e inconvenientes ........................................................................................................ 9 1.1.5 Ambientes de desarrollo en el lado del cliente ....................................................................... 11
1.2 ESTRUCTURA DE LA ARQUITECTURA MULTICAPA ........................................................................... 11 1.3 EL GESTOR DE BASES DE DATOS MICROSOFT SQL SERVER. .......................................................... 13
1.3.1 Procedimientos almacenados. ................................................................................................ 14 1.3.2 Funciones ............................................................................................................................... 15 1.3.3 Desencadenadores ................................................................................................................. 18
1.4 EL ENTORNO DE DESARROLLO DE SOFTWARE DELPHI ..................................................................... 19 1.4.1 Componentes .......................................................................................................................... 19 1.4.2 Eventos ................................................................................................................................... 20 1.4.3 Base de datos .......................................................................................................................... 20 1.4.4 Borland database engine (bde) .............................................................................................. 21 1.4.5 Desarrollo visual .................................................................................................................... 21 1.4.6 Entorno integrado de desarrollo (EID) .................................................................................. 21 1.4.7 Depurador Integrado ............................................................................................................. 22
1.5 MODELO DE ACCESO A DATOS: ADO (MICROSOFT ACTIVEX DATA OBJECTS) ............................... 22
CAPÍTULO 2. ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DEL SISTEMA PARA EL CONTROL DE PACIENTES CON TRASPLANTE RENAL. ......................................................... 24
2.1 DISEÑO Y ANÁLISIS DEL SISTEMA .................................................................................................... 25 2.2 MODELO DEL NEGOCIO .................................................................................................................. 25 2.3 ACTORES Y CASOS DE USO .............................................................................................................. 26 2.4 DISEÑO DE LA BASE DE DATOS ........................................................................................................ 31 2.5 EJEMPLOS DE PROCEDIMIENTOS ALMACENADOS ............................................................................. 34 2.6 EJEMPLO DE FUNCIONES .................................................................................................................. 35 2.7 GENERACIÓN DE REPORTES ............................................................................................................. 35
CAPÍTULO # 3: MANUAL DE USUARIO DEL DATAR ................................................................. 37
3.1 REQUERIMIENTOS PARA LA EJECUCIÓN DEL SISTEMA ..................................................................... 38 3.2 INICIO DEL SISTEMA DATAR ........................................................................................................... 38 3.3 VISTA PRINCIPAL DEL SISTEMA ...................................................................................................... 39 3.4 MENÚ PRINCIPAL DEL SISTEMA ....................................................................................................... 39
3.4.1 Vistas de datos asociada al proceso de entrada de datos pre-operatorios del paciente receptor de órgano. ......................................................................................................................... 42 3.4.2 Vistas de datos asociada al proceso de entrada de datos pre-operatorios del paciente vivo donador de órgano. ......................................................................................................................... 48 3.4.3 Vistas de datos asociadas al proceso de entrada de datos del paciente muerto donador de órgano. ............................................................................................................................................ 50 3.4.4 Vistas de datos asociadas al proceso del acto operatorio del paciente donante vivo ............ 50 3.4.5 Vista de datos asociada al proceso de visualización de reportes ........................................... 52 3.4.6 Vista visor de reportes ............................................................................................................ 53
CONCLUSIONES .................................................................................................................................. 55
RECOMENDACIONES ........................................................................................................................ 56
REFERENCIAS ...................................................................................................................................... 57
BIBLIOGRAFÍA .................................................................................................................................... 58
1
Introducción
Cuba realiza trasplante renal desde hace 34 años, es de hecho uno de los primeros países de
nuestro continente en esta experiencia. Este tipo de trasplante es el pionero en el mundo, y
nosotros hemos logrado incrementar la tasa de realización por encima de 17 /1 000 000 de
habitantes en los últimos 3 años, cifra principal en Latinoamérica. (Duro, 2003)
De 1970 a 1979 todos los trasplantes se efectuaron con donante cadáver y en 1979 se
comenzó a emplear el donante vivo emparentado y compatible; no obstante, se ha mantenido
históricamente en todos estos años más del 90 % de estos con donante cadáver. La tasa de
donantes en Cuba oscila entre 15 y 19/1 000 000 de habitantes.
El progreso experimentado por los trasplantes en los últimos 40 años ha sido espectacular.
Las nuevas técnicas y terapias inmunosupresoras han hecho posible que esta modalidad de
tratamiento sustitutivo se haya generalizado.(2006)
Actualmente no existe un sistema en el Hospital Docente Provincial “Arnaldo Milián Castro”
que permita el adecuado procesamiento de la información relacionada con el Trasplante
Renal por lo que se propone obtener un Sistema de Bases de Datos que permita el manejo de
la información antes mencionada y sirva de base para la creación de nuevos módulos capaces
de ofrecer una visión a nivel Nacional mediante servicios de Web y que permitan además una
ayuda en la toma de decisiones.
Después de varios estudios realizados al proyecto se tomaron las decisiones pertinentes con
relación a la plataforma tecnológica que iba a ser utilizada. Se decide utilizar SQL Server
como servidor centralizado de la base de datos, por varias razones:
• Seguridad: dada la popularidad de los sistemas operativos Windows en nuestro
entorno (país), SQL Server utiliza un esquema de seguridad integra con Windows
NT, que garantiza, en gran medida la seguridad del sistema.
• Factibilidad: SQL Server es un Sistema de Gestión de Bases de Datos, que resulta
familiar para los tesiantes y tutores, además forma parte del currículo de la carrera.
• Rendimiento: SQL Server es un eficiente Sistema de Gestión de Bases de Datos.
2
También se decide utilizar Delphi como lenguaje de programación de alto nivel. Existen
múltiples experiencias satisfactorias acerca de la utilización combinada del SQL Server y
aplicaciones desarrolladas en Delphi.(Addison-Wesley)
La decisión de utilizar una base de datos centralizada, en vez de recurrir a la estrategia de
utilizar una base de datos distribuida, se debió, en lo fundamental, al criterio de la seguridad
del sistema. Entendiendo la seguridad, no solo como la limitación del acceso a los datos, sino
además como la disponibilidad y la integridad de los mismos, es un hecho innegable que es
más fácil invertir recursos necesarios (ejemplos: UPS, memorias, arreglos de discos duros en
espejo, etc.) en un solo sitio que en varios. De la misma manera, es más cómodo establecer y
revisar políticas adecuadas para el acceso a un solo sitio que a varios.
Este trabajo se presenta en tres capítulos: el primero se centra en la discusión y el análisis de
una serie de herramientas computacionales que nos han servido para la resolución del
problema planteado como son: Microsoft SQL Server 2000, las Aplicaciones Win32 usando
el entorno Delphi. Haremos referencia además a la arquitectura multicapa y a la arquitectura
Cliente Servidor analizando sus beneficios y los soportes físicos de dichos esquemas, es
decir, las redes y los dispositivos de hardware que ellas necesitan. En el capítulo dos se
aborda todo lo relacionado con el proceso de análisis e implementación del sistema,
describiendo el proceso del negocio, así como los diferentes diagramas de actividades,
actores y casos de uso. Finalmente en el último capítulo se expone una guía de cómo usar el
sistema lo que se considera un manual de usuario del mismo.
HIPÓTESIS DE LA INVESTIGACIÓN
Las herramientas anteriormente mencionadas permiten construir una base de datos lo
suficientemente robusta para soportar los requerimientos del sistema y en particular llevar el
control total de los pacientes sometidos a un trasplante renal en el Hospital “Arnaldo Milián
Castro” de Villa Clara, garantizando la adecuada seguridad del mismo.
Los módulos a realizar permiten la actualización de la base de datos, con nuevos pacientes y
su seguimiento, así como el control de flujo de generación de documentos del sistema.
3
OBJETIVO GENERAL
Desarrollar un sistema computacional para el control de la información de los pacientes con
trasplante renal realizados en el Hospital universitario “Arnaldo Milián Castro” de Villa
Clara, utilizando tecnología Cliente/Servidor y un lenguaje de programación de alto nivel,
con la asesoría de especialistas en trasplante renal, con diversas funcionalidades para mejorar
la gestión de dicho hospital, sentando las bases para la creación de un posterior sistema de
toma de decisiones. Implementar una solución basada en una arquitectura de tres capa,
centrándose básicamente en las capas de datos y presentación.
OBJETIVOS ESPECÍFICOS
1. Construir una base de datos lo suficientemente robusta para soportar los
requerimientos de sistema.
2. Desarrollar el sistema encargado de manipular toda la información almacenada en la
base de datos.
3. Desarrollar el módulo del control del flujo de generación de documentos del sistema.
4. Implementar el módulo responsable de brindar las informaciones requeridas.
4
Capítulo 1. Empleo de tecnologías y herramientas computacionales en la Gestión y el Control de los Pacientes con
Trasplante Renal.
5
En el presente capítulo se abordan los conceptos y las herramientas utilizadas para el
desarrollo del sistema DataR. Se presenta el modelo Cliente/Servidor y su arquitectura, así
como el modelo de acceso a datos ADO, y la estructura de la arquitectura multicapa.
1.1 MODELO CLIENTE/SERVIDOR
La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de información
en el que las transacciones se dividen en procesos independientes que cooperan entre sí para
intercambiar información, servicios o recursos. Se denomina cliente al proceso que inicia el
diálogo o solicita los recursos y servidor al proceso que responde a las solicitudes.(Straub,
1996)
En este modelo las aplicaciones se dividen de forma que el servidor contiene la parte que
debe ser compartida por varios usuarios, y en el cliente permanece sólo lo particular de cada
usuario.
Los clientes realizan generalmente funciones como:
• Manejo de la interfaz de usuario.
• Captura y validación de los datos de entrada.
• Generación de consultas e informes sobre las bases de datos.
Por su parte los servidores realizan, entre otras, las siguientes funciones:
• Gestión de periféricos compartidos.
• Control de accesos concurrentes a bases de datos compartidas.
• Enlaces de comunicaciones con otras redes de área local o extensa.
Siempre que un cliente requiere un servicio lo solicita al servidor correspondiente y éste le
responde proporcionándolo. Normalmente, pero no necesariamente, el cliente y el servidor
están ubicados en distintos procesadores. Los clientes se suelen situar en ordenadores
personales y/o estaciones de trabajo y los servidores en procesadores departamentales o de
grupo.(Morgenstern, 1983)
6
1.1.1 CARACTERÍSTICAS FUNCIONALES
Esta arquitectura se puede clasificar en cinco niveles, según las funciones que asumen el
cliente y el servidor, tal y como se puede ver en el siguiente diagrama:
Figura 1.1.1.1 Niveles de la arquitectura cliente/servidor.
En el primer nivel el cliente asume parte de las funciones de presentación de la aplicación, ya
que siguen existiendo programas en el servidor dedicados a esta tarea. Dicha distribución se
realiza mediante el uso de productos para el "maquillaje" de las pantallas del mainframe. Esta
técnica no exige el cambio en las aplicaciones orientadas a terminales, pero dificulta su
mantenimiento. Además, el servidor ejecuta todos los procesos y almacena la totalidad de los
datos. En este caso se dice que hay una presentación distribuida o embellecimiento.
En el segundo nivel la aplicación está soportada directamente por el servidor, excepto la
presentación que es totalmente remota y reside en el cliente. Los terminales del cliente
soportan la captura de datos, incluyendo una validación parcial de los mismos y una
presentación de las consultas. En este caso se dice que hay una presentación remota.
En el tercer nivel la lógica de los procesos se divide entre los distintos componentes del
cliente y del servidor. El diseñador de la aplicación debe definir los servicios y las interfaces
del sistema de información de forma que los papeles de cliente y servidor sean
7
intercambiables, excepto en el control de los datos que es responsabilidad exclusiva del
servidor. En este tipo de situaciones se dice que hay un proceso distribuido o cooperativo.
En el cuarto nivel el cliente realiza tanto las funciones de presentación como los procesos.
Por su parte, el servidor almacena y gestiona los datos que permanecen en una base de datos
centralizada. En esta situación se dice que hay una gestión de datos remota.
En el quinto y último nivel, el reparto de tareas es como en el anterior y además el gestor de
base de datos divide sus componentes entre el cliente y el servidor. Las interfaces entre
ambos están dentro de las funciones del gestor de datos y, por lo tanto, no tienen impacto en
el desarrollo de las aplicaciones. En este nivel se da lo que se conoce como bases de datos
distribuidas.
1.1.2 CARACTERÍSTICAS FÍSICAS
El diagrama del punto anterior da una idea de la estructura física de conexión entre las
distintas partes que componen una arquitectura cliente / servidor. La idea principal consiste
en aprovechar la potencia de los ordenadores personales para realizar sobre todo los servicios
de presentación y, según el nivel, algunos procesos o incluso algún acceso a datos locales. De
esta forma se descarga al servidor de ciertas tareas para que pueda realizar otras más
rápidamente.
También existe una plataforma de servidores que sustituye al ordenador central tradicional y
que da servicio a los clientes autorizados. Incluso a veces el antiguo ordenador central se
integra en dicha plataforma como un servidor más. Estos servidores suelen estar
especializados por funciones (seguridad, cálculo, bases de datos, comunicaciones, etc.),
aunque, dependiendo de las dimensiones de la instalación se pueden reunir en un servidor
una o varias de estas funciones.(Schlesinger, 1987)
8
Las unidades de almacenamiento masivo en esta arquitectura se caracterizan por incorporar
elementos de protección que evitan la pérdida de datos y permiten multitud de accesos
simultáneos (alta velocidad, niveles RAID, etc.).
Para la comunicación de todos estos elementos se emplea un sistema de red que se encarga
de transmitir la información entre clientes y servidores. Físicamente consiste en un cableado
(coaxial, par trenzado, fibra óptica, etc.) o en conexiones mediante señales de radio o
infrarrojas, dependiendo de que la red sea local (RAL), metropolitana (MAN) o de área
extensa (WAN).
Para la comunicación de los procesos con la red se emplea un tipo de equipo lógico
denominado middleware que controla las conversaciones. Su función es independizar ambos
procesos (cliente y servidor). La interfaz que presenta es la estándar de los servicios de red
que hace que los procesos "piensen" en todo momento que se están comunicando con una
red.
1.1.3 CARACTERÍSTICAS LÓGICAS
Una de las principales aportaciones de esta arquitectura a los sistemas de información es la
interfaz gráfica de usuario. Gracias a ella se dispone de un manejo más fácil e intuitivo de las
aplicaciones mediante el uso de un dispositivo tipo ratón. En esta arquitectura los datos se
presentan, editan y validan en la parte de la aplicación cliente.
En cuanto a los datos, cabe señalar que en la arquitectura cliente/servidor se evitan las
duplicidades (copias y comparaciones de datos), teniendo siempre una imagen única y
correcta de los mismos disponible en línea para su uso inmediato.
Todo esto tiene como fin que el usuario de un sistema de información soportado por una
arquitectura cliente/servidor trabaje desde su estación de trabajo con distintos datos y
aplicaciones, sin importarle dónde están o dónde se ejecuta cada uno de ellos.
9
1.1.4 VENTAJAS E INCONVENIENTES
Ventajas
• Aumento de la productividad:
• Los usuarios pueden utilizar herramientas que le son familiares, como hojas de
cálculo y herramientas de acceso a bases de datos.
• Mediante la integración de las aplicaciones cliente/servidor con las aplicaciones
personales de uso habitual, los usuarios pueden construir soluciones particularizadas
que se ajusten a sus necesidades cambiantes.
• Una interfaz gráfica de usuario consistente reduce el tiempo de aprendizaje de las
aplicaciones.
• Menores costos de operación.
• Permiten un mejor aprovechamiento de los sistemas existentes, protegiendo la
inversión. Por ejemplo, la compartición de servidores (habitualmente caros) y
dispositivos periféricos (como impresoras) entre máquinas clientes permite un mejor
rendimiento del conjunto.
• Proporcionan un mejor acceso a los datos. La interfaz de usuario ofrece una forma
homogénea de ver el sistema, independientemente de los cambios o actualizaciones
que se produzcan en él y de la ubicación de la información.
• El movimiento de funciones desde un ordenador central hacia servidores o clientes
locales origina el desplazamiento de los costes de ese proceso hacia máquinas más
pequeñas y por tanto, más baratas.
• Mejora en el rendimiento de la red.
• Las arquitecturas cliente/servidor eliminan la necesidad de mover grandes bloques de
información por la red hacia los ordenadores personales o estaciones de trabajo para
su proceso. Los servidores controlan los datos, procesan peticiones y después
transfieren sólo los datos requeridos a la máquina cliente. Entonces, la máquina
10
cliente presenta los datos al usuario mediante interfaces amigables. Todo esto reduce
el tráfico de la red, lo que facilita que pueda soportar un mayor número de usuarios.
• Tanto el cliente como el servidor pueden escalarse para ajustarse a las necesidades de
las aplicaciones. Las UCPs utilizadas en los respectivos equipos pueden
dimensionarse a partir de las aplicaciones y el tiempo de respuesta que se requiera.
• La existencia de varias UCPs proporciona una red más fiable: un fallo en uno de los
equipos no significa necesariamente que el sistema deje de funcionar.
• En una arquitectura como ésta, los clientes y los servidores son independientes los
unos de los otros con lo que pueden renovarse para aumentar sus funciones y
capacidad de forma independiente, sin afectar al resto del sistema.
• La arquitectura modular de los sistemas cliente/servidor permite el uso de
ordenadores especializados (servidores de base de datos, servidores de ficheros,
estaciones de trabajo para CAD, etc.).
• Permite centralizar el control de sistemas que estaban descentralizados, como por
ejemplo la gestión de los ordenadores personales que antes estuvieran aislados.
Inconvenientes
• Hay una alta complejidad tecnológica al tener que integrar una gran variedad de
productos.
• Requiere un fuerte rediseño de todos los elementos involucrados en los sistemas de
información (modelos de datos, procesos, interfaces, comunicaciones,
almacenamiento de datos, etc.). Además, en la actualidad existen pocas herramientas
que ayuden a determinar la mejor forma de dividir las aplicaciones entre la parte
cliente y la parte servidor.
• Es más difícil asegurar un elevado grado de seguridad en una red de clientes y
servidores que en un sistema con un único ordenador centralizado.
• A veces, los problemas de congestión de la red pueden degradar el rendimiento del
sistema por debajo de lo que se obtendría con una única máquina (arquitectura
centralizada). También la interfaz gráfica de usuario puede a veces ralentizar el
funcionamiento de la aplicación.
11
• El quinto nivel de esta arquitectura (bases de datos distribuidas) es técnicamente muy
complejo y en la actualidad hay muy pocas implantaciones que garanticen un
funcionamiento totalmente eficiente.
• Existen multitud de costes ocultos (formación en nuevas tecnologías, licencias,
cambios organizativos, etc.) que encarecen su implantación.
1.1.5 AMBIENTES DE DESARROLLO EN EL LADO DEL CLIENTE
Son muchas las herramientas que existen en la actualidad para el desarrollo de aplicaciones
en la plataforma Windows. Entre las más conocidas están aquellas que son distribuidas por
Microsoft aunque también existen muchas otras compañías productoras de este tipo de
software como la Borland que distribuye Delphi, CBuilder, etc. Cada una de las
herramientas antes mencionadas tiene sus especificidades por lo que el programador tiene
que ser capaz de de construir una interfaz de forma adecuada que cumpla con los requisitos
de la aplicación, brindando las mayores facilidades posibles a los usuarios.(Do Prado Leite,
1998)
1.2 ESTRUCTURA DE LA ARQUITECTURA MULTICAPA
El rápido crecimiento de la popularidad de Internet ha ocasionado el cambio en la forma de
encarar el desarrollo de aplicaciones trayendo consigo nuevas tecnologías que hacen que las
redes existentes tengan que adaptarse a esta exitosa forma de comunicación.
Implementar soluciones basadas en una arquitectura multi-capa significa crear aplicaciones
divididas en capas funcionales que se comunican entre sí. Este modelo implica definir
esquemas de comunicación, protocolos y estándares entre cada componente de este nuevo
esquema. La Error! Reference source not found. muestra una arquitectura de tres
capas.
12
Figura 0.1 Modelo de tres capas.
1 Capa de Base de Datos: Contiene clases que interactúan con la base de datos, estas
clases altamente especializadas se encuentran en la arquitectura y permiten, utilizando
los procedimientos almacenados generados, realizar todas las operaciones con la base
de datos de forma transparente para la capa de negocio.
2 Capa de negocio: Esta capa esta formada por las entidades empresariales, que
representan objetos que van a ser manejados o consumidos por toda la aplicación.
3 Capa de presentación o interface de usuario: En este caso, esta formada por los
formularios y los controles que se encuentran en los formularios. Capa con la que
interactúa el usuario.
Ventajas
• Disponibilidad: La disponibilidad se refiere a la cantidad de tiempo que una
aplicación es capaz de dar servicio confiable a las peticiones del cliente. Es
importante debido a que una aplicación solamente es útil cuando está disponible para
dar servicio a las peticiones de los clientes. A su vez, depende de elementos que están
más allá del control del desarrollador, como por ejemplo: disponibilidad de hardware,
(controlador de disco, tarjetas de red, controladores, etc.), disponibilidad de software
(servidores de web, sistemas de espera, etc.) y disponibilidad de red.
• Escalabilidad: La escalabilidad es la meta utópica del crecimiento lineal del
rendimiento al agregar recursos adicionales, y es lo que le permite a una aplicación
13
soportar desde 10 usuarios, hasta decenas de miles de usuarios, simplemente
agregando o quitando recursos como sea necesario para "escalar". Para incrementar la
escalabilidad, los desarrolladores de aplicaciones deben concentrarse en mantener los
tiempos de adquisición de recursos y de uso de recursos tan bajos como sean posibles.
Los monitores transaccionales permiten compartir recursos entre usuarios
reutilizando los ya existentes.
• Interoperabilidad: La interoperabilidad se refiere a la habilidad de una aplicación para
acceder a aplicaciones, los datos o los recursos en otras plataformas. Muchos
ambientes institucionales soportan diferentes tipos de hardware y sistemas de
software que deben trabajar juntos, por lo cual es importante que las aplicaciones
tengan la capacidad de interoperar. Para maximizar la interoperabilidad, las
aplicaciones deben utilizar estándares que permitan la conectividad entre diferentes
productos y/o aplicaciones
1.3 EL GESTOR DE BASES DE DATOS MICROSOFT SQL SERVER.
En la actualidad una de las aplicaciones de mayor aceptación en el mundo del las bases de
datos es Microsoft SQL Server con su distribución Microsoft® SQL Server™ 2000, y su
distribución más reciente de Microsoft® SQL Server™ 2005. Microsoft SQL Server
constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases de datos
como son Oracle, MySQL, etc. Este producto ha incorporado un conjunto de funcionalidades
que le proporcionan al desarrollador un cómodo ambiente de trabajo para la implementación
de una base de datos, posibilitándole realizar operaciones de inserción, actualización,
eliminación y recuperación de información una vez realizado el diseño: esquema conceptual
de la base de datos en cuestión.(Dayal, 1988)
Entre las características de Microsoft SQL Server figuran:
1. Soporte de transacciones.
2. Escalabilidad, estabilidad y seguridad.
3. Soporta procedimientos almacenados.
4. Incluye también un potente entorno gráfico de administración, que permite el uso de
comandos DDL y DML gráficamente.
14
5. Permite trabajar en modo cliente/servidor donde la información y datos se alojan en el
servidor y las terminales o clientes de la red sólo acceden a la información.
6. Además permite administrar información de otros servidores de datos.
Este sistema incluye una versión reducida, llamada MSDE con el mismo motor de base de
datos pero orientado a proyectos más pequeños, que en su versión 2005 pasa a ser el SQL
Express Edition.
1.3.1 PROCEDIMIENTOS ALMACENADOS.
Los procedimientos almacenados son unas de las funcionalidades más útiles y mas utilizadas
de SQL Server, incluso para una aplicación diseñada con N capas todas las consultas a la
base de datos se suelen hacer con procedimientos almacenados.
Una vez se halla creado un procedimiento almacenado este se puede invocar directamente
desde una aplicación ya sea para obtener datos desde la base de datos o para modificar o
insertar nuevos datos en ella. Los procedimientos almacenados permiten que se les pueda
pasar parámetros de entrada y ellos pueden retornar también ciertos valores como parámetros
de salida.
Usar los procedimientos almacenados en lugar de códigos Transact-SQL en el lado del
cliente tiene las siguientes ventajas:
• Permite una programación más modular.
• Reduce el tamaño de las aplicaciones.
• Se logra que el código sea reutilizable.
• Es más fácil el mantenimiento de la aplicación.
• Los procedimientos almacenados al ser ejecutados por el servidor:
• reducen el tráfico en la red logrando un mejor desempeño esencialmente por
parte del cliente remoto.
• Contribuyen con la seguridad del sistema.
15
1.3.2 FUNCIONES
Microsoft incorporó el uso de funciones a partir de su producto Microsoft SQL Server 2000,
lo que le permitió a los programadores crear sus propias funciones, y eliminó el problema
que existía de reutilización de código.
SQL Server utiliza 3 tipos de funciones: funciones fijas de servidor, funciones fijas de Base
de Datos, y funciones definidas por el usuario.
Funciones fijas de servidor:
Permiten al administrador de la base de datos asignar determinados grupos de permisos
administrativos. Esto posibilita que cada usuario de la base de datos tenga acceso solo a la
parte de la información que a él le compete.
Tabla 1.1 Funciones fijas de servidor de SQL Server
Función fija de servidor Descripción
sysadmin
Realiza cualquier actividad en SQL Server.
serveradmin
Configura opciones de configuración válidas en todo
el servidor y apaga el servidor.
setupadmin
Administra los servidores conectados y los
procedimientos de inicio.
securityadmin
Administra las cuentas de inicio de sesión, CREA
permisos a BASES DE DATOS, lee los registros de
errores y cambia las contraseñas.
16
processadmin
Administra los procesos que se ejecutan en SQL
Server.
dbcreator
Crea, modifica y elimina bases de datos.
diskadmin
Administra los archivos de disco.
Funciones fijas de Base de Datos
Las funciones fijas de base de datos permiten al administrador de base de datos y al
propietario asignar determinados grupos de permisos administrativos. En lugar de conceder
al usuario todos los privilegios de propietario de la base de datos, las funciones fijas de base
de datos permiten al administrador asignar sólo los permisos que él desee concederle al
usuario.
Tabla 1.2 Funciones fijas de base de datos de SQL Server
Función fija de base de datos Descripción
db_owner
Tiene todos los permisos de la base de datos.
db_accessadmin
Puede agregar o eliminar Id. de usuarios.
db_securityadmin
Puede administrar todos los permisos, todas las
propiedades de objetos, las funciones y las
17
pertenencias a funciones.
db_ddladmin
Puede emitir instrucciones ALL DDL, pero no
GRANT, REVOKE ni DENY.
db_backupoperator
Puede emitir instrucciones DBCC, CHECKPOINT y
BACKUP.
db_datareader
Puede seleccionar todos los datos de cualquier tabla
de usuario de la base de datos.
db_datawriter
Puede modificar todos los datos de cualquier tabla de
usuario de la base de datos.
db_denydatareader
No puede seleccionar ningún dato de ninguna tabla
de usuario de la base de datos.
db_denydatawriter
No puede modificar ningún dato de ninguna tabla de
usuario de la base de datos.
18
Funciones de base de datos definidas por el usuario
Las funciones fijas de base de datos definidas por el usuario permiten al administrador y al
propietario de la base de datos administrar más fácilmente grupos de permisos, modularizar
la programación en TRANSACT-SQL y por ende lograr mayor claridad en el código en el
lado del servidor.
Las funciones definidas por el usuario pueden anidarse, pero esta característica debe
utilizarse con moderación para evitar conflictos de seguridad y otros problemas.
SQL Server 2000 admite tres tipos de funciones definidas por el usuario:
• Funciones escalares.
• Funciones de valores de tabla en línea.
• Funciones de valores de tabla de múltiples instrucciones.
Las funciones escalares devuelven un tipo de los datos tal como int, money, varchar, real,
etc. Pueden ser utilizadas en cualquier lugar incluso incorporado dentro de sentencias SQL.
Las funciones de tabla en línea son las funciones que devuelven la salida de una simple
declaración SELECT. La salida se puede utilizar adentro de joins o querys como si fuera una
tabla de estándar.
Las funciones de tabla de multi sentencias son similares a los procedimientos almacenados
excepto que vuelven un tabla. Este tipo de función se usa en situaciones donde se requiere
más lógica y proceso.(2005)
1.3.3 DESENCADENADORES
Los desencadenadores no son más que un tipo especial de procedimiento almacenado que se
activa de manera automática cuando el usuario activa uno de sus estados de modificación,
que puede originarse producto a la acción de actualización en la base de datos, u otra
operación como inserción o eliminación, en determinadas tablas.
19
1.4 EL ENTORNO DE DESARROLLO DE SOFTWARE DELPHI
Delphi es un entorno de desarrollo de software diseñado para la programación de propósito
general con mayor énfasis en la programación visual. El Delphi utiliza como lenguaje de
programación el Object Pascal. Un uso habitual de Delphi (aunque no es el único) es el
desarrollo de aplicaciones visuales y de bases de datos cliente/servidor y multicapas. Debido
a que es una herramienta de propósito múltiple, se usa también para proyectos de casi
cualquier tipo, incluyendo aplicaciones de consola, aplicaciones de web (por ejemplo
servicios web, CGI, ISAPI, NSAPI, módulos para Apache), servicios COM y DCOM, y
servicios del sistema operativo.
1.4.1 COMPONENTES
Delphi dio una implementación muy buena a la idea del uso de componentes, que son piezas
reutilizables de código (clases) que pueden interactuar con el EID en tiempo de diseño y
desempeñar una función específica en tiempo de ejecución. Desde un enfoque más específico
de la herramienta, se catalogan como componentes todos aquellos objetos que heredan de la
clase TComponent, donde se implementa la funcionalidad necesaria para interactuar con el
entorno de desarrollo, la carga dinámica desde streams y la liberación de memoria mediante
una jerarquía. Una gran parte de los componentes disponibles para Delphi son controles
(derivados de TControl), que encapsulan los elementos de interacción con el usuario como
botones, menús, barras de desplazamiento, etcétera.
Delphi incluye una biblioteca de clases bien diseñada denominada VCL (Visual Component
Library, Biblioteca de Componentes Visuales) y, en sus versiones 6 y 7, una jerarquía
multiplataforma paralela denominada CLX. Ésta también se incluye en Kylix (versión de
Delphi para Linux). Estas jerarquías de objetos incluyen componentes visuales y no visuales,
tales como los pertenecientes a la categoría de acceso a datos, con los que puede establecerse
conexiones de forma nativa o mediante capas intermedias (como ADO, BDE u ODBC) a la
mayoría de las bases de datos relacionales existentes en el mercado. La VCL también está
disponible para el desarrollo en .NET.
20
Además de poder utilizar en un programa estos componentes estándar (botones, grillas,
conjuntos de datos, etc.), es posible crear nuevos componentes o mejorar los ya existentes,
extendiendo la funcionalidad de la herramienta. En Internet existe un gran número de
componentes, tanto gratuitos como comerciales, disponibles para los proyectos a los que no
les basten los que vienen ya con la herramienta.
1.4.2 EVENTOS
Delphi permite de manera sencilla ejecutar trozos de código en respuesta a acciones o
eventos (sucesos) que ocurren durante el tiempo que un programa se ejecuta. Por ejemplo,
cuando se presiona un botón, la VCL captura la notificación estándar de windows, y detecta
si hay algún método asociado al evento OnClick del botón. Si lo hay, manda ejecutar dicho
método.
Los eventos pueden generarse debido a la recepción de señales desde elementos de hardware
como el ratón o el teclado, o pueden producirse al realizar alguna operación sobre un
elemento de la propia aplicación (como abrir un conjunto de datos, que genera los eventos
BeforeOpen/AfterOpen). La VCL ha demostrado estar bien diseñada y el control que se tiene
a través de los eventos de la misma es suficiente para la gran mayoría de las aplicaciones.
1.4.3 BASE DE DATOS
Una de las principales características y ventajas de Delphi es su capacidad para desarrollar
aplicaciones con conectividad a bases de datos de diferentes fabricantes. El programador de
Delphi cuenta con una gran cantidad de componentes para realizar la conexión,
manipulación, presentación y captura de los datos, algunos de ellos liberados bajo licencias
de código abierto o gratuito. Estos componentes de acceso a datos pueden enlazarse a una
gran variedad de controles visuales, aprovechando las características del lenguaje orientado a
objeto, gracias al polimorfismo.
En la paleta de componentes pueden encontrarse varias pestañas para realizar una conexión a
bases de datos usando diferentes capas o motores de conexión.
21
Hay motores que permiten conectarse a bases de datos de diferentes fabricantes tales como
BDE o ADO, que cuentan con manejadores para los formatos más extendidos.
1.4.4 BORLAND DATABASE ENGINE (BDE)
Es un motor de conexión a bases de datos de uso bastante amplio y que permite manejar
bases de datos de escritorio como dBase, FoxPro y Paradox, además de ofrecer la capacidad
para conectarse a servidores SQL locales y remotos. Su uso, va siendo cada vez menor,
debido a la pobre gestión de memoria que realiza, sustituyéndolo por componentes más
actualizados y especializados como DOAC (Direct Oracle Access Components) o
DBExpress, esto sumado a la fiabilidad que están presentando los nuevos gestores de Datos
en especial tecnologías como RDO y ADO; los cuales son mantenidos por sus fabricantes,
forzando la compatibilidad con las versiones preliminares; liberando al programador de
actualizaciones en cuanto a gestión de datos.
1.4.5 DESARROLLO VISUAL
Como entorno visual, la programación en Delphi consiste en diseñar los formularios que
componen al programa colocando todos sus controles (botones, etiquetas, campos de texto,
etc.) en las posiciones deseadas, normalmente usando un ratón. Luego se asocia código a los
eventos de dichos controles y también se pueden crear módulos de datos, que regularmente
contienen los componentes de acceso a datos y las reglas de negocio de una aplicación.
1.4.6 ENTORNO INTEGRADO DE DESARROLLO (EID)
EID es el ambiente de desarrollo de programas de Delphi. Se trata de un editor de
formularios (que permite el desarrollo visual), un potente editor de textos que resalta la
sintaxis del código fuente, la paleta de componentes y el depurador integrado, además de una
barra de botones y un menú que nos permite la configuración de la herramienta y la gestión
de proyectos. En las ediciones Client/Server y Enterprise el EID también ofrece integración
con una herramienta de control de versiones (PVCS).
22
1.4.7 DEPURADOR INTEGRADO
Es una potente característica que nos permite establecer puntos de ruptura (breakpoints), la
ejecución paso a paso de un programa, el seguimiento de los valores de las variables y de la
pila de ejecución, así como la evaluación de expresiones con datos de la ejecución del
programa. Con su uso, un programador experimentado puede detectar y resolver errores
lógicos en el funcionamiento de un aplicativo desarrollado con Delphi. En las ediciones
Client/Server y Enterprise se añade la opción de depuración a programas corriendo en
equipos remotos (remote debugging), lo que posibilita el uso de todas las características del
depurador con un programa ejecutándose en su entorno normal de trabajo y no en el
ordenador del programador (en donde muchas veces no ocurren los errores).
1.5 MODELO DE ACCESO A DATOS: ADO (MICROSOFT ACTIVEX DATA OBJECTS)
ADO (ActiveX Data Objects) es uno de los mecanismos que usan los programas de
computadoras para comunicarse con las bases de datos, darles órdenes y obtener resultados
de ellas.
Con ADO, un programa puede leer, insertar, editar, o borrar, la información contenida en
diferentes áreas de almacenamiento dentro de la base de datos llamadas tablas. Además, se
puede manipular la propia base de datos para crear nuevas áreas para el almacenamiento de
información (tablas), como también alterar o eliminar las ya existentes, entre otras cosas.
Fue desarrollado por Microsoft y es usado en ambientes Windows por lenguajes de
programación como Visual Basic, C++, Delphi entre otros, también puede ser usado en la
web.
ADO es un intermediario entre el programa y la base de datos. El programa no ve la base de
datos directamente, sino que hace todo el trabajo a través de ADO. Usando ADO, el
programa se comunica con la base de datos, consulta, edita, inserta, borra, registros, añade
tablas, etc. ADO a su vez se comunica con la base de datos a través de un "proveedor de
datos". En la dirección contraria, la base de datos responde, comunicándose con el proveedor
de datos, éste con ADO, y al final, la información llega al programa. Una vez que el
23
programa tiene la información proveniente de la base de datos, puede hacer con ella lo que
considere.
24
Capítulo 2. Análisis, diseño e implementación del Sistema para el control de pacientes con trasplante renal.
25
2.1 Diseño y análisis del sistema
El software que se implementa tiene como objetivo principal monitorear la evolución del
paciente con falla renal. El mismo recoge los datos del individuo desde su entrada al salón de
operaciones, para realizársele un trasplante renal, y su posterior evolución que será evaluada
regularmente hasta el fallecimiento del paciente, sea o no por falla renal.
Durante la realización de este proyecto se realizaron varias entrevistas de trabajo con el
experto en el área médica de nefrología, en el que se realizó un análisis detallado del proceso
de captura de datos de los pacientes con trasplante renal realizado. Como resultado se
obtienen los casos de usos del negocio así como los del sistema. Además, en esta fase se
identifican las interfaces externas, se hace una valoración inicial de los riesgos y se evalúa el
conjunto de requisitos del sistema.
2.2 MODELO DEL NEGOCIO
Producto a las distintas secciones de trabajo realizadas con el experto en el área médica de
nefrología en que se hizo un análisis pormenorizado de la captura de datos de los pacientes
con trasplante renal realizado, se confeccionó un diagrama de actividad en el que se visualiza
el flujo de dicho proceso, describiendo así el funcionamiento del negocio.
26
Figura 2.2.1 Diagrama de Actividad del Negocio
2.3 ACTORES Y CASOS DE USO
Después de un largo análisis del modelo del negocio pasamos a identificar los diferentes
casos de usos del negocio.
Entrada de los datos en “La historia clínica del paciente receptor de órgano”.
• Datos generales.
• Interrogatorios por aparatos.
• Examen físico.
• Hoja de laboratorio.
27
• Estudios inmunológicos.
• Estudios radiológicos.
• Otros estudios.
• Validación de los datos.
Entrada de los datos del “Paciente vivo donador de órgano”.
• Datos generales.
• Interrogatorios por aparatos.
• Examen físico.
• Hoja de laboratorio.
• Estudios inmunológicos.
• Estudios radiológicos.
• Otros estudios.
• Validación de los datos.
Entrada de los datos del paciente muerto donador de órgano.
• Datos generales.
Entrada del acto operatorio de paciente vivo donador de órgano.
• Datos generales.
• Complicaciones.
• Transfusiones.
• Perfusión, características y solución.
• Características del riñón.
• Equipo de trabajo.
Entrada del acto operatorio del donante muerto.
• Datos Generales.
Entrada de datos del pareja donante - receptor.
• Donante
• Receptor
Evolución.
28
• Seguir con la evolución tanto del paciente como del receptor del órgano.
Los casos de uso del negocio son equivalentes a los siguientes casos de uso del sistema para
DataR:
• Recolección de datos del paciente receptor de órgano.
• Recolección de datos del paciente vivo donador de órgano.
• Recolección de datos de paciente muerto donador de órgano.
• Recolección de datos del par donante - receptor.
• Evolución.
• Generación de Reportes
Los actores del sistema son: el especialista en nefrología. En el sistema se controlan todas las
acciones que puede realizar el único actor que presenta nuestro sistema. El especialista es en
encargado de mantener actualizado todo el sistema. Para esto se han creado varias opciones
dentro del mismo software.
Los casos de uso del sistema para la administración se exponen a continuación:
• Actualización de hospitales.
• Actualización del equipo de trabajo médico que participa en los actos operatorios.
A continuación se muestra el diagrama de casos de uso de DataR:
Figura 2.3.1 Casos de uso de DataR
29
A continuación algunos de nuestros casos de usos refinados:
Figura 2.3.2 Refinamiento del caso de uso: Captura de Datos de los pacientes
Figura 2.3.3 Refinamiento del caso de uso: Detalles del acto operatorio
30
Figura 2.3.4 Refinamiento del caso de uso: Generar reportes
Figura 2.3.2 Refinamiento del caso de uso: Adicionar datos de los pacientes receptores de
órgano.
31
2.4 DISEÑO DE LA BASE DE DATOS
La base de datos fue implementada en SQL Server 2000 y consta de 47 tablas, una función y
varios procedimientos almacenados. Gran parte de las iteraciones de la interfaz con la base
de datos se realiza a través de esta función y de los procedimientos almacenados.
El diseño de la base de datos está dividido en tres partes fundamentales: una donde se
almacena todo lo referente al equipo médico que labora en el área de nefrología, otra donde
se guardan los datos generales referentes a los pacientes receptores de órgano, donantes vivos
y donantes muertos y una donde se guardan los tipos de estudios que se le realizaron a estos
pacientes mencionados anteriormente.
Debido al gran tamaño que presenta el modelo lógico de la base de datos, se optó por
dividirlo en tres partes, (A, B, C), para lograr una mejor comprensión.
Figura 2.4.1 Modelo lógico de la base de datos parte A
32
Figura 2.4.2 Modelo lógico de la base de datos parte B
33
Figura 2.4.3 Modelo lógico de la base de datos parte C
34
2.5 EJEMPLOS DE PROCEDIMIENTOS ALMACENADOS
Los estudios médicos realizados a los pacientes con falla renal constituyen uno de los
fundamentos principales de DataR. Para poder obtener la información de cada uno de estos
estudios se han tenido que implementar varios procedimientos almacenados.
El procedimiento almacenado que nos permite obtener los datos de los estudios
inmunológicos del paciente receptor de órganos es:
CREATE PROCEDURE EInmunologico @CI varchar(11), @ID integer AS
SELECT dbo.Paciente.CiPaciente,
dbo.EstudiosInmunologicos.FechaEstudioInmunologico,
dbo.EstudiosInmunologicos.Resultados,
dbo.TipoEstudioInmunologico.IdEstudio
FROM dbo.Paciente INNER JOIN
dbo.EstudiosInmunologicos ON dbo.Paciente.CiPaciente =
dbo.EstudiosInmunologicos.CI INNER JOIN
dbo.TipoEstudioInmunologico ON dbo.EstudiosInmunologicos.IdEstudio =
dbo.TipoEstudioInmunologico.IdEstudio
WHERE (dbo.Paciente.CiPaciente = @CI) AND
(dbo.TipoEstudioInmunologico.IdEstudio = @ID)
Se le entran como parámetros el carnet de identidad del paciente que este siendo analizado
así como un id que representa el tipo de estudio inmunológico que se desee analizar, ya sea
uno para pruebas cruzadas o dos para HLA.
Otro ejemplo de procedimiento almacenado es el que nos permite obtener los datos de los
interrogatorios por aparatos del paciente receptor de órganos:
CREATE PROCEDURE [interrogatorioPaciente] @CI varchar(11), @ID int AS
35
SELECT dbo.InterrogatorioAparatos.FechaInterregatorioAparatos,
dbo.InterrogatorioAparatos.Resultados, dbo.InterrogatorioAparatos.idaparato,
dbo.Paciente.CiPaciente
FROM dbo.InterrogatorioAparatos INNER JOIN
dbo.Paciente ON dbo.InterrogatorioAparatos.idCI = dbo.Paciente.CiPaciente
INNER JOIN
dbo.TipoAparato ON dbo.InterrogatorioAparatos.idaparato =
dbo.TipoAparato.IdTipoaparato
WHERE (dbo.InterrogatorioAparatos.idaparato = @id) AND (dbo.Paciente.CiPaciente =
@CI)
2.6 EJEMPLO DE FUNCIONES
En la obtención de los datos generales de los pacientes receptores y donadores de órganos,
fue de gran utilidad la creación de dos funciones. A continuación mostramos una de ellas.
CREATE FUNCTION [DatosPacientes] ( @CI nvarchar(11) )
RETURNS Table AS RETURN
( SELECT *
FROM dbo.Paciente
WHERE CiPaciente = @CI)
2.7 GENERACIÓN DE REPORTES
El sistema cuenta con un generador de reportes, con reportes ya predefinidos que nos da la
posibilidad de visualizar un grupo de datos agrupados por un campo determinado, el cual
puede ser guardado o impreso según desee el usuario.
36
Figura 2.7.1 Reporte de pacientes receptores
37
Capítulo # 3: Manual de usuario del DataR.
38
En este capítulo pretendemos describir las principales acciones a desarrollar por el usuario
con el propósito de que el mismo sirva como una guía en el uso del sistema.
3.1 REQUERIMIENTOS PARA LA EJECUCIÓN DEL SISTEMA
Para su ejecución, el sistema DataR necesita los siguientes requerimientos:
En la parte del cliente
▪ Una PC IBM compatible con procesador Pentium o superior.
▪ Al menos 32 MB de memoria RAM.
▪ Al menos 4 MB de espacio en disco duro.
▪ Sistema operativo Windows 95 o superior.
En la parte del servidor
▪ Una PC IBM compatible con procesador Pentium o superior.
▪ Al menos 128 MB de memoria RAM.
▪ Alrededor de 200 MB de espacio en disco duro para la instalación de Microsoft
SQL Server 2000.
▪ Sistema operativo Windows 2000 o superior.
3.2 INICIO DEL SISTEMA DATAR
Para comenzar a trabajar con el sistema lo primero que hay que hacer es ejecutarlo, para esto
diríjase a la carpeta donde tiene almacenado el software y haga doble clic en DataR.exe e
inmediatamente el sistema mostrará su pantalla de bienvenida, al mismo tiempo que
inicializa todas las conexiones a la base de datos.
Figura 3.2.1 Pantalla de bienvenida de DataR
39
3.3 VISTA PRINCIPAL DEL SISTEMA
En la figura 3.3.1 se muestra la pantalla principal del sistema, en la parte superior de la
misma podremos encontrar en menú de opciones, debajo de dicho menú, en la parte
izquierda de la pantalla se encuentra un árbol de directorios semejante al explorador de
Windows con dos directorios, donde el usuario puede elegir entre receptores y donadores. En
la parte derecha de la pantalla se visualizan los datos más generales del paciente que este
seleccionado en el árbol de directorio.
Figura 3.3.1 Ventana Principal de DataR
3.4 MENÚ PRINCIPAL DEL SISTEMA
El menú principal del sistema, figura 3.4.1, esta compuesto por 3 elementos:
1. Equipo médico
2. Centros Hospitalarios
3. Datos Donante-Receptor
4. Reportes
5. Herramientas
40
Figura 3.4.1 Menú de DataR
Mediante el submenú Equipo Médico se pueden adicionar los miembros del equipo médico
que participa en un trasplante renal:
Figura 3.4.2 Submenú Inicialización
• Enfermeras: Posibilita la entrada de nuevas enfermeras al sistema.
• Cirujanos: Posibilita la entrada de nuevos cirujanos al sistema.
• Nefrólogos: Posibilita la entrada de nuevos nefrólogos al sistema.
• Anestesistas: Posibilita la entrada de nuevos anestesistas al sistema.
• Técnico Anestesista: Posibilita la entrada de nuevos técnicos anestesistas al sistema.
El submenú Centros Hospitalarios:
• Hospitales: Posibilita la entrada de nuevos hospitales al sistema.
El submenú Datos Donante-Receptor:
Figura 3.4.3 Submenú Datos Donante – Receptor
• Receptor: Permite la entrada al sistema de los datos de los pacientes receptores de
órganos.
• Donante Vivo: Permite la entrada al sistema de los datos de los pacientes vivos
donadores de órganos.
41
• Donante Muerto: Permite la entrada al sistema de los datos de los pacientes muertos
donadores de órganos.
• Acto operatorio del donador: Permite la entrada al sistema de datos específicos
referentes al acto operatorio donde se le extrae el riñón al donante vivo.
• Evolución: Está compuesto a su vez por dos opciones más, que son:
Receptor: Este submenú nos permite la entrada al sistema de las distintas
consultas médicas realizadas al paciente que recibió el riñón para seguir la
evolución médica del mismo.
Donador: Este submenú nos permite la entrada al sistema de las distintas
consultas médicas realizadas al paciente que donó el riñón para seguir la
evolución médica del mismo.
• Asociar Donante – Receptor: Este submenú nos permite asignarle a cada paciente
receptor su donador correspondiente.
El submenú Reportes:
Figura 3.4.4 submenú Reportes
• Receptores: Permite visualizar e imprimir los datos generales de los pacientes
receptores de órganos.
• Donante vivo: Permite visualizar e imprimir los datos generales de los pacientes
donadores vivos de órganos.
• Donante Vivo – Receptor: Permite visualizar e imprimir cada receptor con su
donante.
El submenú Herramientas:
Figura 3.4.4 submenú Herramientas
• Visualizador de reportes: A través de este submenú podemos visualizar reportes
guardados con anterioridad con el fin de consultarlos o realizarles una copia impresa.
42
3.4.1 VISTAS DE DATOS ASOCIADA AL PROCESO DE ENTRADA DE DATOS PRE-
OPERATORIOS DEL PACIENTE RECEPTOR DE ÓRGANO.
Existen varias vistas para un receptor seleccionado, a continuación mostraremos gran parte
de ellas.
En la vista Generales, figura 3.4.1.1 se muestran los datos generales de un receptor de
órgano, como son nombre y apellidos, carnet de identidad, edad, domicilio, etc.
Figura 3.4.1.1 Entrada de datos de los datos del paciente receptor de órganos.
Como podemos observar esta vista contiene un botón llamado Ver por el cual podemos
acceder a una vista llamada Antecedentes patológicos personales que contiene los siguientes
datos separados en paletas, Enfermedades de la infancia, Vacunación, Transfusiones, Alergia
medicamentosa, entre otras.
43
La vista de Interrogatorio por aparatos figura 3.4.1.2, muestra las distintas pruebas por
aparatos hechas al paciente Receptor de órgano recogidas por fecha de realización, como son
Cardiovascular, Digestivo, Genito-Urinario, Respiratorio, Ginecológico, HLP, Endocrino y
Neurológico. Con opciones para agregar nuevas pruebas. Estas pruebas están ubicadas en
paletas con los nombres de los respectivos aparatos.
Figura 3.4.1.2 Interrogatorio por aparatos
La vista Examen Físico figura 3.4.1.3, muestra el examen físico realizado a los pacientes
receptores separados por la fecha de realización, también permite inserción de nuevos
exámenes. Un ejemplo de los datos que aquí se recogen son: peso, talla, piel y mucosa,
respiratorio, etc.
44
Figura 3.4.1.3 Examen Físico
La vista Hoja de Laboratorio figura 3.4.1.4, muestra y permite agregar diversos estudios
complementarios de los pacientes receptores como son: Hemoglobina, TGP, Colesterol, etc.
Cada hoja de laboratorio es identificada por la fecha de su realización.
45
Figura 3.4.1.4 Hoja de laboratorio
La vista Estudios Inmunológicos figura 3.4.1.5 recoge todos los datos de este tipo de estudio
ubicados en dos pruebas permitiéndonos ubicarlos por fecha de realización así como la
inserción de nuevas pruebas.
Las pruebas que se recogen aquí son: Prueba cruzada y HLA.
46
Figura 3.4.1.5 Estudio inmunológico
La vista Estudios Radiológicos figura 3.4.1.6 recoge todos los datos de este tipo de estudio
ubicados en siete pruebas permitiéndonos ubicarlos por fecha de realización así como la
inserción de nuevas pruebas.
Las pruebas que se recogen aquí son: Rx de tórax, Rx abdomen simple, Senos perinasales,
Ultrasonido renal y abdominal, Uretrocistografía miccional, Rx de esófago, estomago y
duodeno y Doppler vascular de la región Ileo Femoral.
47
Figura 3.4.1.6 Estudios radiológicos
La vista Otros figura 3.4.1.7 recoge otra pruebas más generales como son los EGC,
Ecocardiograma, Pruebas funcionales respiratorias, Prueba citológica o antígeno prostático.
Al igual que las vistas anteriores nos da la posibilidad de agregar nuevos resultados a las
pruebas mencionadas, separadas por fecha.
48
Figura 3.4.1.7 Otros
3.4.2 VISTAS DE DATOS ASOCIADA AL PROCESO DE ENTRADA DE DATOS PRE-
OPERATORIOS DEL PACIENTE VIVO DONADOR DE ÓRGANO.
En estas vistas se manejan los mismos datos que en las vistas analizada en el epígrafe
anterior pero referente al paciente vivo donador de órganos, solo existen pocos cambios en
algunos datos que en esta vista no se recogen como podemos ver en la figura 3.4.2.1.
49
Figura 3.4.2.1 Entrada de datos de los datos del paciente vivo donador de órganos.
La vista mostrada en la figura anterior también presenta el botón Ver para pasas a la vista
Antecedentes patológicos personales que debido a su importancia pasamos a mostrársela en
la figura 3.4.2.2.
Figura 3.4.2.2 Vista Antecedentes patológicos personales.
Como se puede apreciar esta vista es semitransparente con el objetivo de que se puedan
observar los datos que hay detrás de ella que corresponden a la misma categoría “Datos
Generales”.
50
3.4.3 VISTAS DE DATOS ASOCIADAS AL PROCESO DE ENTRADA DE DATOS DEL
PACIENTE MUERTO DONADOR DE ÓRGANO.
Solamente existe una vista en el proceso de captura de datos del paciente muerto donador de
órganos, figura 3.4.3.1, debido que ha este paciente no se le realiza un seguimiento evolutivo,
ni un posterior acto quirúrgico, solo nos interesa conocer algunos datos importantes como
son: Grupo sanguíneo, fecha y hora de recibido, los órganos que se le extrajeron, etc.
Figura 3.4.3.1 Vista Donante Muerto
3.4.4 VISTAS DE DATOS ASOCIADAS AL PROCESO DEL ACTO OPERATORIO DEL
PACIENTE DONANTE VIVO
Existen varias vistas para el proceso del acto operatorio del donante vivo, a continuación
mostraremos gran parte de ellas.
En la primera vista que observamos, figura 3.4.4.1, nos permite la entrada y modificación de
diferentes datos como son: tipo de riñón, técnica anestésica, peridural, etc., la vista
complicaciones nos permite ver las complicaciones anestésicas y quirúrgicas y modificarlas.
51
Figura 3.4.4.1 Vista inicial del acto operatorio del donante vivo
La vista Trasfusiones, figura 3.4.4.2, nos permite ver la cantidad de glóbulos y plasma que se
le suministró al paciente, también permite poner otros datos de interés referentes a este
proceso.
Figura 3.4.4.2 Vista Transfusiones
La vista Perfusión, características y solución, figura 3.4.4.3, es la encardada de mostrar los
datos específicos de la perfusión, como son el inicio, fin y tiempo total de esta.
52
Figura 3.4.4.3 Vista Perfusión, características y solución
La vista Características del riñón, figura 3.4.4.4, no permite añadir una caracterización del
riñón extraído al paciente donante vivo.
Figura 3.4.4.4 Vista Características del riñón
Cada vista aquí mostrada cuenta con una barra de herramientas ubicada en la parte superior
de la vista, dicha barra contiene las operaciones que se pueden realizar con los datos que se
muestran.
3.4.5 VISTA DE DATOS ASOCIADA AL PROCESO DE VISUALIZACIÓN DE REPORTES
Existen dos vistas para el proceso de visualización de reportes, a continuación pasamos a
mostrarles una de ellas.
53
Figura 3.4.5.1 Vista Receptores
Esta vista nos da la posibilidad de ver un resumen de los datos generales más específicos de
los pacientes receptores de órganos, cada paciente tiene sus datos en hojas independientes,
las cuales se pueden guardar, o imprimir según desee el usuario.
3.4.6 VISTA VISOR DE REPORTES
La vista visor de reportes, figura 3.4.6.1, es de una gran importancia debido a que esta
permite la visualización de reportes que hayan sido almacenados por el usuario con un
propósito especifico, ya sea su posterior impresión o para conocer en una fecha determinada
cuantos pacientes habían incluidos en el sistema.
54
Figura 3.4.6.1 Vista Visor de reportes
55
Conclusiones El presente trabajo pone a disposición del personal médico del Hospital Universitario
“Arnaldo Milián Castro” de Villa Clara una interfaz cómoda que permite manejar la
información almacenada en una base de datos referente a pacientes con trasplantes renales.
Se ha logrado obtener un diseño óptimo de la Base de Datos que sirve de apoyo para el
adecuado manejo de toda la información necesaria. Se posibilita de esta forma disponer de
información referente al seguimiento de diferentes casos para que los médicos puedan emitir
criterios que ayuden a la solución de problemáticas sin estar físicamente al lado del paciente.
Se pretende además que con sus posteriores actualizaciones llegue a constituir una
importante y útil herramienta de ayuda a la toma de decisiones para el personal médico
relacionado.
56
Recomendaciones
1. Trabajar en la Capa de Negocios que permita establecer las reglas que rigen el
negocio.
2. Crear módulos capaces de ofrecer una visión a nivel Nacional mediante servicios de
Web.
3. Ofrecer la posibilidad de ayuda en la toma de decisiones en el proceso de trasplante
renal.
57
Referencias
Microsoft SQL Server. Wikipedia. URL: http://en.wikipedia.org/wiki/ADO
(2001) Microsoft Corporation, “Libros en pantalla de MS SQL Server 2000”.
Robayna, I. ADO y Delphi. Grupo Albor. 2001. p-4. URL:
http://www.grupoalbor.com/descarga/articulos/ado/ado.pdf
58
Bibliografía (2005) Funciones en SQL Server 2000.
(2006) Trasplante renal en Cuba.
ADDISON-WESLEY Booch, Grady. Análisis y Diseño Orientado a objetos, con
aplicaciones.
DAYAL, U. B., A. P.; MCCHARTY, D. R. (1988) “Rules are Objects too: A Knowledge
Model for an Active, Object-Oriented Database Management System”. Advances in Object-
Oriented Database Systems. Berlin, K. R. Dittrich.
DO PRADO LEITE, J. L., M. C.; TEOREY,T. J. (1998) “Business rules as organizational
policies”. in Proc. of Ninth International Workshop on Software Specification and Design,.
DURO, V. (2003) Latín América Transplantation Report, The Transplantation Society of
Latin
America and the Caribbean, 2003.
MORGENSTERN, M. (1983) “Active Databases as a Paradigm for Enhanced Computing
Environments”. 9th International conference on Very Large Databases. Florence, Italy.
SCHLESINGER, M. H. H., C. (1987) “The Design of the POSTGRES Rules System”. IEEE
Inter¬national Conference on Data Engineering.
STRAUB, P. (1996) Charla sobre arquitecturas Cliente/Servidor [En línea].
59
Anexos Anexo 1: Diagrama lógico de la base de datos
