universidad de guayaquil facultad de ciencias...
TRANSCRIPT
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN LA ADMINISTRACION Y GESTION DE LA BASE DE DATOS MEDIANTE LA ALTERACIÓN DEL MODELO DE DATOS PARA
BRINDAR ESCALABILIDAD, ENFOCADO HACIA NUEVAS ENFERMEDADES A MONITOREARSE E INTEGRACIÓN
CON APLICACIONES EN ANDROID.
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERA EN SISTEMAS COMPUTACIONALES
AUTOR:
JOHANNA NATALY PARDO JARA
TUTOR:
ING. JIMMY SORNOZA MOREIRA MSG.
GUAYAQUIL – ECUADOR 2017
III
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
TÍTULO Y SUBTÍTULO:
Sistema de autogestión de la salud para pacientes con diabetes y asma, desarrollado e implementado en una plataforma Android; con monitoreo de una aplicación web en PHP dirigida a los médicos tratantes, enfocado en la administración y gestión de la base de datos mediante la alteración del modelo de datos para brindar escalabilidad, enfocado hacia nuevas enfermedades a monitorearse e integración con aplicaciones en Android.
AUTOR: Johanna Nataly Pardo Jara
REVISOR/TUTOR: Ing. Fabricio Javier Sánchez Moreno M. SC. Ing. Jimmy Ignacio Sornoza Moreira M. SC.
INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL
FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS
ESPECIALIDAD: INGENIERÍA EN SISTEMAS COMPUTACIONALES
GRADO OBTENIDO: TERCER NIVEL
FECHA DE PUBLICACIÓN:
2017 No. DE PÁGINAS 93
ÁREAS TEMÁTICAS: BASE DE DATOS
PALABRAS CLAVES / KEYWORDS:
MYSQL, WORKBENCH, SCRUM, HEALTH MONITOR, PHP, ESCALABILIDAD,
RESUMEN/ABSTRACT: La incorporación de la Metodología SCRUM en Proyectos Ágiles tiene como característica brindar una inspección y adaptación diaria de soluciones que responden a los requerimientos del cliente. Las aplicaciones de Salud creadas para Smartphone han generado una gran oportunidad para que los especialistas puedan obtener estadísticas de una población amplia que cuentan con distintas características. HealthMonitor UG es una aplicación desarrollada con tecnología Android dirigida a pacientes que padecen de diabetes y/o asma, la cual les permite llevar un control diario de su estado de salud, identificando la evolución de sus parámetros de forma práctica y eficiente. En esta nueva Versión de la aplicación se busca diversificar su funcionalidad, por este motivo propone normalizar el esquema lógico implementado en la Base de Datos de la aplicación dándole la versatilidad necesaria para almacenar nueva información del paciente, el Gestor de Base de Datos utilizado es MySql para el desarrollo de este proyecto. La respuesta de esta propuesta permitirá que el Modelo de Entidad Relación sea escalable y adaptable a soportar el registro de información de una nueva patología y almacenar datos de otras aplicaciones desarrolladas en plataforma Android, se incluye el desarrollo de APIs de procesamiento para efectuar las transacciones correspondientes controlando los eventos que se presentan durante la ejecución de los Store Procedure.
ADJUNTO PDF: SI NO
CONTACTO CON AUTOR:
Teléfono: 0960201411 E-mail: [email protected]
CONTACTO CON LA INSTITUCIÓN:
Nombre: AB. JUAN CHÁVEZ ATOCHA
Teléfono: 2307729
E-mail: [email protected]
X
II
CARTA DE APROBACION DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “Sistema de autogestión de la
salud para pacientes con diabetes y asma, desarrollado e implementado en
una plataforma Android; con monitoreo de una aplicación web en PHP
dirigida a los médicos tratantes, enfocado en la administración y gestión de
la base de datos mediante la alteración del modelo de datos para brindar
escalabilidad, enfocado hacia nuevas enfermedades a monitorearse e
integración con aplicaciones en Android” elaborado por la Srta. PARDO
JARA JOHANNA NATALY, Alumna no titulada de la Carrera de Ingeniería en
Sistemas Computacionales de la Facultad de Ciencias Matemáticas y Físicas de
la Universidad de Guayaquil, previo a la obtención del Título de Ingeniera en
Sistemas Computacionales, me permito declarar que luego de haber orientado,
estudiado y revisado, la Apruebo en todas sus partes.
Atentamente
Ing. Jimmy Sornoza M.Sc.
TUTOR
III
DEDICATORIA
Este trabajo está Dedicado a
mis padres, que me motivan
siempre a ser una mejor
persona.
Johanna Pardo Jara.
IV
AGRADECIMIENTO
Agradezco a Dios por la vida, por darme la sabiduría para cumplir esta meta. A mi familia por su apoyo incondicional que manifestaron durante todo este proceso, en especial a mis padres de quienes valoro todo el esfuerzo que realizaron para brindarme la educación. A todos quienes han sido participe de este proyecto de investigación y han aportado, con sus opiniones su granito de Arena para que este proyecto se realice. Johanna Pardo Jara
V
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo M.Sc.
DECANO DE LA FACULTAD CIENCIAS MATEMÁTICAS Y FÍSICAS
Ing. Abel Alarcón Salvatierra Mgs. DIRECTOR
CISC
Ing. Jimmy Sornoza Moreira M.Sc. PROFESOR TUTOR
DEL PROYECTODE TITULACION
Ing. Fabricio Sánchez Moreno M.Sc PROFESOR TUTOR REVISOR
DEL PROYECTODE TITULACION
Ab. Juan Chávez A. SECRETARI
VI
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”
JOHANNA NATALY PARDO JARA
VII
AUTORIA
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN LA ADMINISTRACION Y GESTION DE LA BASE DE DATOS
MEDIANTE LA ALTERACIÓN DEL MODELO DE DATOS PARA
BRINDAR ESCALABILIDAD, ENFOCADO HACIA NUEVAS
ENFERMEDADES A MONITOREARSE E INTEGRACIÓN
CON APLICACIONES EN ANDROID.
Proyecto de Titulación que se presenta como requisito para optar por el título de
INGENIERA EN SISTEMAS COMPUTACIONALES
Autor: Johanna Nataly Pardo Jara
C.I.: 0927249102 Tutor: Ing. Jimmy Sornoza
Guayaquil, Diciembre del 2017
VIII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de
Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por el/la
estudiante JOHANNA NATALY PARDO JARA, como requisito previo para optar
por el título de Ingeniero en Sistemas Computacionales cuyo problema es:
Sistema de autogestión de la salud para pacientes con Diabetes y Asma,
desarrollado e implementado en una plataforma Android; con Monitoreo de una
aplicación Web en PHP dirigida a los médicos tratantes, enfocado en la
Administración y Gestión de la Base de Datos mediante la alteración del modelo
de datos para brindar escalabilidad, enfocado hacia nuevas enfermedades a
monitorearse e integración con aplicaciones en Android.
Considero aprobado el trabajo en su totalidad.
Presentado por:
Pardo Jara Johanna Nataly Cédula de ciudadanía N° 0927249102
Tutor: Ing. Jimmy Sornoza M.Sc.
Guayaquil, Diciembre del 2017
IX
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
Autorización para Publicación de Proyecto de Titulación en Formato Digital
1. Identificación del Proyecto de Titulación
Nombre Alumno: Johanna Nataly Pardo Jara
Dirección: Cabo Rafael Pullaguari y Callejón SE N° 45
Teléfono: 0960201411 E-mail: [email protected]
Facultad: Ciencias Físicas y Matemáticas
Carrera: Ingeniería en Sistemas Computacionales
Título al que opta: Ingeniera en Sistemas Computacionales
Profesor guía: Ing. Jimmy Sornoza M.Sc.
Título del Proyecto de titulación: “Sistema de autogestión de la salud para pacientes con Diabetes y Asma, desarrollado e implementado en una plataforma Android; con Monitoreo de una aplicación Web en PHP dirigida a los médicos tratantes, enfocado en la Administración y Gestión de la Base de Datos mediante la alteración del modelo de datos para brindar escalabilidad, enfocado hacia nuevas enfermedades a monitorearse e integración con aplicaciones en Android”.
Tema del Proyecto de Titulación: Alteración del modelo de datos para brindar escalabilidad en el almacenamiento de información.
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación.
A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación. Publicación electrónica:
Inmediata X Después de 1 año
Firma Alumno: 3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF.
DVDROM x CDROM
X
ÍNDICE GENERAL
CARTA DE APROBACION DEL TUTOR ................................................... II
DEDICATORIA ......................................................................................... III
AGRADECIMIENTO ................................................................................. IV
TRIBUNAL PROYECTO DE TITULACIÓN ................................................ V
DECLARACIÓN EXPRESA ...................................................................... VI
AUTORIA ................................................................................................. VII
ABREVIATURAS ..................................................................................... XII
ÍNDICE DE CUADROS ........................................................................... XIII
ÍNDICE DE GRÁFICOS .......................................................................... XV
Resumen ............................................................................................. XVIII
INTRODUCCIÓN ....................................................................................... 1
CAPÍTULO I ............................................................................................... 4
EL PROBLEMA ...................................................................................... 4
PLANTEAMIENTO DEL PROBLEMA ................................................. 4
OBJETIVOS DE LA INVESTIGACIÓN .............................................. 11
JUSTIFICACIÓN E IMPORTANCIA .................................................. 12
METODOLOGÍA DEL PROYECTO ................................................... 13
CAPÍTULO II ............................................................................................ 17
MARCO TEÓRICO ............................................................................... 17
ANTECEDENTES DEL ESTUDIO .................................................... 17
FUNDAMENTACIÓN TEÓRICA ........................................................ 19
FUNDAMENTACIÓN LEGAL ............................................................ 49
HIPÓTESIS ....................................................................................... 53
VARIABLES DE LA INVESTIGACIÓN .............................................. 53
DEFINICIONES CONCEPTUALES ................................................... 54
CAPÍTULO III ........................................................................................... 57
METODOLOGÍA ................................................................................... 57
DISEÑO DE LA INVESTIGACIÓN .................................................... 57
CAPÍTULO IV ........................................................................................... 69
XI
PROPUESTA TECNOLÓGICA ............................................................ 69
ANÁLISIS DE FACTIBILIDAD .............................................................. 69
- FACTIBILIDAD OPERACIONAL .................................................... 70
- FACTIBILIDAD TÉCNICA .............................................................. 71
- FACTIBILIDAD LEGAL .................................................................. 73
- FACTIBILIDAD ECONÓMICA ........................................................ 73
ETAPAS DE LA METODOLOGÍA DEL PROYECTO............................ 75
RESUMEN GENERAL DEL DESARROLLO ........................................ 79
ENTREGABLES DEL PROYECTO ...................................................... 81
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ........................... 81
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO Y/O SERVICIO ..... 85
CONCLUSIONES ................................................................................. 87
RECOMENDACIONES ......................................................................... 88
BIBLIOGRAFÍA ........................................................................................ 89
ANEXOS .................................................................................................. 93
XII
ABREVIATURAS
MER: Modelo Entidad Relación.
APP: Aplicaciones con características especiales.
SGBD: Sistema Gestor Base De Datos.
BD: Base de Datos
OMS: Organización Mundial De La Salud.
FEP: Flujo Espiratorio Pico.
SO: Sistema Operativo.
API: Application Programming Interface (Interfaz De De Programación De
Aplicaciones).
TIC: Tecnologías De La Información Y La Comunicación.
PHP: Hypertext Preprocessor.
XIII
ÍNDICE DE CUADROS
CUADRO N° 1
CAUSAS Y CONSCUENCIAS DEL PROYECTO 5
CUADRO N° 2
DELIMITACION DEL PROBLEMA 6
CUADRO N° 3
VARIABLES 9
CUADRO N° 4
MODELO DE NEGOCIO 22
CUADRO N° 5
GUÍA PARA LA ENTREVISTA 60
CUADRO N° 6
DESCRIPCIÓN UNIDADES DE ANÁLISIS. 61
CUADRO N° 7
DETALLE DE VARIABLES 64
CUADRO N° 8
RESULTADO MUESTRA 64
CUADRO N° 9
ANÁLISIS DE PUBLICACIONES - PATOLOGIA 65
CUADRO N° 10
ANÁLISIS DE PUBLICACIONES – CONTEXTO 66
CUADRO N° 11
ACEPTACIÓN DE PÚBLICO 67
CUADRO N° 12
DESCRIPCIÓN DE ESTACIÓN DE TRABAJO 72
CUADRO N° 13
DESCRIPCIÓN DE ESTACIÓN DE TRABAJO 72
CUADRO N° 14
PRESUPUESTO DESARROLLO 74
XIV
CUADRO N° 15
ETAPAS DE LA METODOLOGÍA 75
CUADRO N° 16
CRITERIOS DE VALIDACION - MOVIL 82
CUADRO N° 17
CRITERIOS DE VALIDACION PORTAL WEB 83
CUADRO N° 18
CRITERIO DE ACEPTACIÓN NIVEL LÓGICO 85
CUADRO N° 19
CRITERIO ACEPTACIÓN NIVEL TÈCNICO 85
CUADRO N° 20
CRITERIO ACEPTACIÓN NIVEL SOCIAL 86
XV
ÍNDICE DE GRÁFICOS
GRÁFICO N° 1
IMPACTO DE ESCALABILIDAD .............................................................. 12
GRÁFICO N° 2
PLANIFICACIÓN ÁGIL ............................................................................ 14
GRÁFICO N° 3
SCRUM TEAM ......................................................................................... 15
GRÁFICO N° 4
TEAM BD ................................................................................................. 15
GRÁFICO N° 5
GESTOR DE TAREAS TRELLO .............................................................. 16
GRÁFICO N° 6
FORMATO DE MOELO DE NEGOCIO ................................................... 20
GRÁFICO N° 7
GRAFICA DE MODELO DE NEGOCIO ................................................... 22
GRÁFICO N° 8
ETAPAS DEL DISEÑO DE UNA BASE DE DATOS ................................ 26
GRÁFICO N° 9
ANALISIS DE REQUERIMIENTO ............................................................ 27
GRÁFICO N° 10
SISTEMA DE ADMINISTRACIÓN DE BD ............................................... 29
GRÁFICO N° 11
INTEGRIDAD ........................................................................................... 31
GRÁFICO N° 12
SEGURIDAD............................................................................................ 32
GRÁFICO N° 13
ADMINSTRADOR DE BASE DE DATOS ................................................ 33
GRÁFICO N° 14
DISEÑADOR DE LA BAS DE DATOS ..................................................... 34
XVI
GRÁFICO N° 15
USUARIOS DE LA BASE DE DATOS ..................................................... 35
GRÁFICO N°
16 NIVELES DE BD ................................................................................. 35
GRÁFICO N°
17 ELEMENTOS DE UNA TABLA ........................................................... 39
GRÁFICO N°
18 RELACION 1:N ................................................................................... 41
GRÁFICO N°
19 RELACIÓN M:N .................................................................................. 42
GRÁFICO N° 20
TRANSFORMACION MODELO ER ........................................................ 42
GRÁFICO N° 21
COMANDOS DLL .................................................................................... 43
GRÁFICO N° 22
COMANDOS DML ................................................................................... 44
GRÁFICO N° 23
CLAÚSULAS............................................................................................ 44
GRÁFICO N° 24
OPERADORES LÓGICOS ...................................................................... 45
GRÁFICO N° 25
OPERADORES DE COMPARACIÓN ...................................................... 45
GRÁFICO N° 26
TIPOS DE DATOS MYSQL ..................................................................... 46
GRÁFICO N° 27
LOGO MYSQL ......................................................................................... 47
GRÁFICO N° 28
INVESTIGACIÓN ..................................................................................... 57
GRÁFICO N° 29
MUESTREO EN INVESTIGACIÓN DESCRIPTIVA ................................. 58
XVII
GRÁFICO N° 30
NIVELES DE CONFIANZA ...................................................................... 59
GRÁFICO N° 30
MOTOR MYSQL ...................................................................................... 62
GRÁFICO N° 31
COMPARATIVO ENTIDADES ................................................................. 62
GRÁFICO N° 32
ESCALABILIDAD EN ESQUEMA BD ...................................................... 63
GRÁFICO N° 33
FÓRMULA PARA OBTENCÓN DE MUESTRA ....................................... 64
GRÁFICO N° 34
ANÁLISIS DE PUBLICACIONES – PATOLOGÍA .................................... 65
GRÁFICO N° 35
ANÁLISIS DE PUBLICACIONES – CONTEXTO ..................................... 66
GRÁFICO N° 36
ACEPTACIÓN DEL PUBLICO ................................................................. 68
GRÁFICO N° 37
INCLUSION PATOLOGIA ........................................................................ 79
GRÁFICO N° 38
ANDROID APPS ...................................................................................... 80
XVIII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN LA ADMINISTRACION Y GESTION DE LA BASE DE DATOS MEDIANTE LA ALTERACIÓN DEL MODELO DE DATOS PARA
BRINDAR ESCALABILIDAD, ENFOCADO HACIA NUEVAS ENFERMEDADES A MONITOREARSE E INTEGRACIÓN
CON APLICACIONES EN ANDROID.
Resumen
La incorporación de la Metodología SCRUM en Proyectos Ágiles tiene como caractiristica brindar una inspección y adaptación diara de soluciones, lo que permite presentar entregables paulatinamente que se se emplean para atender los requerimientos del cliente. Las aplicaciones de Salud creadas para Smartphone ha generado a los investigadores una gran oportunidad para obtener estadisticas de una poblacion amplia con distintas caracteristicas. Health Monitor UG es una aplicación desarrollada con tecnologia Android dirigia para el uso de pacientes que padecen de diabetes y/o asma, que les permite llevar un control diario de su estado de salud, identificando la evolución de sus parámetros, de forma práctica y eficiente. En la Versión actualizada de la aplicación se busca diversificar su funcionalidad, brindando nuevas opciones a sus usuarios. A través de esta propuesta se intenta mejorar el Diseño Lògico de implementado, dándole la versatilidad necesaria para almacenar nueva informacion del paciente utilizando el Gestor de Base de Datos MySql. Para Incorporar una nueva patología en el Aplicativo e integrar funcionalidades con otros App Android, es necesario rediseñar el Modelo Entidad Relación actual, Adicionar Modelo Ontológico y crear APIs de Lógica de Negocio controlando la trazabilidad de la información ingresada, de este modo podremos tener un Modelo de Informacion Escalable que soporte la nueva lógica implementada. Palabras Claves: Scrum, Android, Escalabilidad, MER, Base de Datos, Escalabilidad.
Autor: Johanna Nataly Pardo Jara Tutor: Ing. Jimmy Sornoza Msg.
XIX
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
HEALTH SELF-DIAGNOSIS SYSTEM FOR PATIENTS WITH DIABETES AND ASTHMA, DEVELOPED AND IMPLEMENTED ON AN ANDROID PLATFORM;
WITH MONITORING OF AN APPLICATION WEB IN PHP DIRECTED TO TREATING DOCTORS, FOCUSED IN THE ADMINISTRATION AND MANAGEMENT OF THE DATABASE BY MODIFYING THE DATA
MODEL TO PROVIDE SCALABILITY, FOCUSED TO NEW DISEASES TO MONITOR AND INTEGRATION
WITH ANDROID APPLICATIONS.
Abstract The incorporation of the SCRUM Methodology in Agile Projects has as a characteristic to provide an inspection and daily adaptation of solutions, which allows to present gradually deliverables that are used to meet the requirements of the client. Health applications created for Smartphone have given researchers a great opportunity to obtain statistics of a broad population with different characteristics. Health Monitor UG is an application developed with Android technology aimed at the use of patients suffering from diabetes and / or asthma, which allows them to keep a daily control of their health status, identifying the evolution of their parameters, in a practical and efficient way. In the updated Version of the application seeks to diversify its functionality, providing new options to its users. Through this proposal it is tried to improve the Logical Design of implemented, giving the necessary versatility to store new patient information using the MySql Database Manager. To incorporate a new pathology in the Application and integrate functionalities with other Android App, it is necessary to redesign the Current Relationship Entity Model, Add Ontological Model and create Business Logic APIs controlling the traceability of the information entered, in this way we can have a Model scalable information that supports the new logic implemented. Keywords: Scrum, Android, Scalability, MER, Database, Scalability.
Author: Johanna Nataly Pardo Jara Tutor: Ing. Jimmy Sornoza M.Sc.
1
INTRODUCCIÓN
El desarrollo de aplicaciones Móviles ha tenido una evolución
impresionante en los últimos 8 años, esto ha despertado la atención de diversas
áreas del sector público y privado a nivel de marketing. Las instituciones a diario
presentan infinidad de necesidades requeridas por sus clientes, por este motivo
Los ingenieros de proyectos tecnológicos presentan nuevas ideas, para
solucionar requerimientos de una forma a través de la creación de una aplicación
que cumpla con las expectativas de los usuarios haciendo dinámica su
interacción.
En la actualidad un alto porcentaje de personas cuentan con un
Smartphone, de esta manera es más fácil presentarles a los usuarios nuevas
aplicaciones de diversas áreas de estudio, las cuales pueden obtenerse a través
de los portales de descargas existentes a nivel mundial.
Las llegada de las aplicaciones virtuales –móvil desarrolladas para el
ámbito clínico han sido de gran aporte gracias al contacto inmediato con el
público en general, es por ello que las instituciones públicas y privadas han
apostado por implementar propuestas tecnológicas, con el fin de obtener
beneficios como mejorar su imagen de servicio al público o privado, optimizando
sus tiempos de respuestas, creando confianza en los usuarios. Del mismo modo
los pacientes presentan una gran acogida a las aplicaciones de Salud por su
simplicidad con características múltiples y opciones prácticas que contribuyen a
monitorizar y proponen mejorar el estado de salud bajo recomendaciones o
instrucciones.
La historia de la medicina ha evolucionado en gran magnitud en los
últimos años, sus enfoques se han basado en la imagen que muestran a sus
clientes, y la incursión de la tecnología en sus estudios actuales; lo que se ha
bautizado con el nombre de mHealth o ‘salud móvil’, deriva de la innovación y
acogida que consecuentemente han tenido los Smartphone y las tablets.
(Informe 50 mejores Apps, n.d.)
2
Las Apps han llegado para quedarse y evolucionar, favoreciendo al
cambio del prototipo de la medicina, que sin duda tiene como eje de actuación
principal el bienestar del paciente y de la sociedad en todo su contexto (Informe
50 mejores Apps, n.d.). Todo sistema recibe información, por lo tanto es implícito
e importante la existencia de una Base de Datos en todo proyecto, facilitando la
administración y gestión de la información, nos permite contar con información
sistemática y minimizando casos de redundancia, el volumen de información que
recibe será determinado según su actividad y la cantidad de usuarios registrados
en la aplicación propuesta.
HealthMonitor Ug es una aplicación desarrollada en plataforma Android
de versión libre disponible en la Tienda Play Store, orientada a pacientes que
padezcan de diabetes, permitiendo llevar un control diario de sus parámetros
clínicos básicos y exámenes especiales; además está vinculada a una
plataforma web desarrollada en lenguaje PHP en donde los resultados obtenidos
de los registros de los pacientes son visualizados y analizados por especialistas,
generando indicadores que permiten identificar evolución del estado de salud de
una población especifica.
El presente trabajo está compuesto por 4 capítulos en los cuales podrán
encontrar la información primordial para comprender la propuesta tecnología a
realizar en la App HealthMonitor Ug, enfocado a la Gestión y administración de
base de Datos.
En el capítulo I se analizará la versión actual de la Aplicación
HealthMonitor Ug, se presentará sus limitaciones, encontrando y delimitando el
problema, identificando los objetivos y el alcance de la implementación, logrando
agregar nuevas unidades de clase en el diseño lógico de la Base de Datos.
El capítulo II, se detalla el marco teórico que corresponde a todo el
esquema propuesto. La fundamentación teórica sostiene el Diseño Lógico a
implementar en la Base de Datos de la Aplicación HealthMonitor Ug, exponiendo
propiedades relevantes como los antecedentes previos a este proyecto, los
3
compendios sociales que aporta la utilización de la App dentro del Área de la
Salud, todos los beneficios a la sociedad, la fundamentación legal que respaldan
el desarrollo del proyecto. Esta información se presentará con la finalidad de dar
a conocer al lector palabras claves del desarrollo a implementar.
El capítulo III, informaremos la metodología de la investigación que se
utilizará en el desarrollo del proyecto tecnológico, modalidad y tipo.
Enunciaremos también la población seleccionada como caso de estudio, en la
que se efectuará el análisis según los resultados de la implementación, la
utilización de fórmulas permitirá conocer a la parte de la población que se
beneficiará con esta aplicación.
El capítulo IV, se detalla la propuesta tecnológica del proyecto, daremos a
conocer el Modelo Ontológico a implementar en la Aplicación, para lo cual
enunciaremos las unidades, características y factibilidad operacional indicando
con evidencia los módulos del sistema donde se reflejará los cambios
propuestos, para el correcto almacenamiento y procesamiento de la información
que se obtiene a través de las plataformas utilizadas, y ratificando el beneficio
social mencionado en el marco teórico, se validan los criterios de aceptación del
producto y/o servicio detallando su ponderación según los niveles de contexto
evaluados: Nivel Lógico, Nivel Técnico y Nivel Social en donde se desarrolla la
propuesta. Además se presentarán las conclusiones determinadas durante el
desarrollo implementado indicando sus beneficios y demostrando que la
aplicación tiene como finalidad ayudar y orientar en el progreso del estado la
salud de los usuarios registrados y en general de la población que padece las
patologías diabetes y asma. En la Sección de recomendaciones se informa que
un sistema siempre está constante renovación por lo cual tener en cuenta ciertos
puntos para futuras actualizaciones de la Arquitectura del Sistema.
4
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del problema en un contexto
Las aplicaciones desarrolladas para Smartphone, elaboradas en
plataformas Android han tenido una evolución y recepción positiva por parte de
los usuarios que demandan sistemas móviles amigables que ayuden a mejorar
su estilo de vida en tareas cotidianas, destacando sus beneficios potencialmente
en el ámbito de salud.
La App HealthMonitor Ug, es un proyecto que nació de un grupo
investigadores que pretende analizar el comportamiento de las personas que
padecen diabetes, según datos proporcionados por la OMS y presentadas en su
sitio web hasta el año 2014 el número de personas con diabetes aumentaron a
422 millones según proyecciones (Colin D Mathers, 2006), considerándose una
de las enfermedades con mayor índice de mortalidad a nivel mundial,
El proyecto comenzó su desarrollo en noviembre del 2016 entregando su
primera Versión funcional en mayo del 2017, la aplicación se desarrolló en la
Facultad de Ciencias Físicas y Matemáticas, a cargo de los estudiantes de la
Carrera de Ingeniería en Sistemas Computacionales y Networking.
5
Situación conflicto nudos Críticos
Implementar nuevas funcionalidades en la aplicación HealthMonitor UG ha sido
la visión de este proyecto desde el inicio de su desarrollo. El área problemática
surge en la necesidad de una base de datos que sea escalable y adaptable a
cubrir los nuevos requerimientos y las nuevas implementaciones que se
pretende incluir, permitiendo alimentar las estructuras con nueva información.
Se destaca que la información almacenada en base de datos contiene los
registros de diversos pacientes con diabetes que han hecho uso de la aplicación
la cual le permite al usuario llevar el control de los parámetros clínicos para
notificar en caso de algún desorden de sus niveles de azúcar. El Diseño lógico
cuenta con una limitación debido a que parte de esos parámetros que controlan
son generales y no se están reutilizando.
Causas y Consecuencias del Problema
Toda problemática es generada por múltiples motivos los cuales a corto o largo
plazo pueden desencadenar resultados poco favorables. A continuación
detallaremos las Causas y Consecuencias que presentan la Base de Datos de la
App HealthMonitor Ug.
CUADRO N° 1 CAUSAS Y CONSCUENCIAS DEL PROYECTO
CAUSAS CONSECUENCIAS
MER LIMITADO
Problemas de Escalabilidad.
Modelo Ontológico solo tolera información de
Pacientes Diabéticos
Ausencia de Módulos para interpretar datos.
INEXISTENTE
INTERACCIÓN
CON OTRAS
APP
Insuficiente promoción en el mercado tecnológico.
No se beneficia las tecnologías de la Información,
como el auge de las Redes sociales.
No se podría implementar Datamining.
6
AUSENCIA DE
APIS Y REGLAS
DE NEGOCIO
Redundancia e Inconsistencia de Datos.
Incoherencias en los registros concurrentes.
Resultados no válidos en los indicadores
presentados en la Plataforma web.
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos, Proyecto HealthMonitor UG
Delimitación del Problema
En el siguiente cuadro se identifican los sectores globales, los cuales se ven
afectados por la problemática planteada para este proyecto tecnológico
CUADRO N° 2 DELIMITACION DEL PROBLEMA
Campo: Ingeniería de Software
Área: Base de Datos
Aspecto: Administración y Gestión de Base de Datos
Tema:
Sistema de autogestión de la salud para pacientes con diabetes
y asma, desarrollado e implementado en una plataforma
Android; con monitoreo de una aplicación web en PHP dirigida a
los médicos tratantes, enfocado en la Administración y Gestión
de la base de datos mediante la Alteración del modelo de datos
para brindar escalabilidad, enfocado hacia nuevas enfermedades
a Monitorearse e integración con Aplicaciones en Android.
Demográfico Personas que padecen de Diabetes y Asma.
Espacio 2017
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
7
Formulación Del Problema
¿Qué beneficios proporcionará implementar escalabilidad en el Modelo Entidad
Relación sobre su base de datos que tiene almacenado registros previos,
considerando que la aplicación tiene como requerimiento principal la inclusión de
una nueva patología para recolectar mayor información de otro grupo de
pacientes, como también conocer la interacción con la redes sociales para poder
ser de gran aporte para la comunidad que utiliza la aplicación HealthMonitor?
Evaluación Del Problema
El Problema identificado se evaluará en base a los siguientes aspectos
Delimitado:
Se verifica el problema en la Administración de la Base de Datos de la
Aplicación HealthMonitor Ug desarrollada por la Universidad de Guayaquil en la
Facultad de Ciencias Físicas y Matemáticas bajo la responsabilidad de las
Carreras de Ingenierías Sistemas Computacionales y Networking. El problema
detectado afecta a la Base de Datos en su lógica de negocio, generando
inconvenientes a las dos plataformas que interactúan con los usuarios tanto
pacientes como doctores.
Claro:
Se presenta limitaciones en varias de las funcionalidades de la aplicación
HealthMonitor, Ug se detecta que el MER implementado y la administración de la
base de datos también tiene ciertas limitaciones en su diseño, restringiendo el
crecimiento de la información que se inserta desde de la aplicación Android,
datos que a su vez son presentados en la plataforma para Médicos, donde se
visualiza los indicadores para futuras investigaciones.
Evidente:
La versión anterior de HealthMonitor Ug instalado en dispositivos
Smartphone con SO Android, durante el análisis realizado se observó lentitud,
datos inconcurrentes, ausencia de información relevante de los pacientes, falta
8
de integridad de los datos, lo que esto reflejó es falta de información para las
investigaciones que realizan los médicos especialistas que utilizan el portal web,
donde llega la información de la aplicación, lo que permite levantar estadísticas
de lo registrado.
Relevante:
Se incrementarán las funcionalidades en la aplicación, a través de los
cambios a implementar en la Base de Datos podremos realizar operaciones
lógicas con la información de una nueva patología como es el Asma (una de las
enfermedades más comunes en nuestro entorno) adicional a la Diabetes,
agregando así una nueva población que servirá para el análisis realizados los
especialistas que utilizan la información en el portal Web.
Contextual:
Por medio de la recolección de información a través del uso de la
tecnología que aplicaremos en el campo de la Salud y también el desarrollo a
implementarse en nuestra base de datos servirá para empezar nuevas
investigaciones .tanto a nivel clínico como TI.
Factible:
La solución propuesta es Alterar el Modelo al creado para la Base de
Datos utilizada en la App HealthMonitor Ug, mejorando y adicionando su Modelo
Ontológico para la inclusión de una nueva patología y la interacción con nuevas
Aplicaciones Android, seleccionando de este grupo las Redes Sociales Twitter,
Facebook y la App Google Fit.
Identifica los productos esperados:
Modelo de Entidad Relación que proporcione escalabilidad y crecimiento
en el almacenamiento de la información que se obtiene desde la aplicación
Android HealthMonitor Ug y la presentación de datos estadísticos desde la
plataforma web que monitorean los médicos especialistas.
9
Variables:
Dentro de la Investigación se determinaron las variables que tienden a
moverse durante el desarrollo de la propuesta tecnológica.
CUADRO N° 3 VARIABLES
TIPO DE
VARIABLE DESCRIPCIÓN
VARIABLES
PRINCIPAL: Administración Y Gestión De Base De Datos
VARIABLES
SECUNDARIAS:
Modelo Entidad Relación de la plataforma
APIS para procesamiento de información
obtenida desde móvil
Elaborado por: Johanna Pardo Jara
Fuente: Datos de Investigación del Proyecto
El área donde se analizará el problema se enfocará en los beneficios que otorga
mantener un modelo de entidad relacional y la correcta implementación de la
Base de Datos siendo uno de los servicios indispensables de la aplicación que
permite la operatividad de la lógica de negocio
Se seleccionó como problemática, el Modelo de Entidad Relación implementado
en la aplicación, porque solo posee la capacidad de recibir información de los
pacientes con diabetes en sus plataformas, las versiones presentadas al público
desarrolladas en Android para pacientes, y en PHP a médicos para que
visualicen los resultados de los datos recolectados.
Los pacientes que padecen de Asma son nuestro enfoque incluyéndolos en las
nuevas funcionalidades que se presentaran en la Aplicación, cambios
desarrollados en el Gestor de Base de Datos permitiéndoles llevar un control de
su proceso clínico.
La Gestión y Administración de un modelo de datos y la introducción de nuevas
políticas en la lógica de negocio permiten el crecimiento y delimitación del
proyecto.
10
Alcances del problema.
La propuesta tecnológica implementará nuevos servicios que se
observarán en la aplicación HealthMonitor Ug desarrollada por la Universidad de
Guayaquil en la Facultad de Ciencias Físicas y Matemáticas bajo la
responsabilidad de las Carreras de Ingenierías Sistemas Computacionales y
Networking.
Los Cambios afectarán al Modelo Entidad Relación diseñado e implementado
para la Base de Datos que utiliza la App HealthMonitor Ug. Se alterará su Diseño
Lógico para la inclusión del control clínico de pacientes que padezcan la nueva
patología seleccionada (ASMA); para cubrir la interacción de la App con otras
aplicaciones desarrolladas en Android se adicionará un Modelo Ontológico en la
Base de Datos que brindará acceso a las Redes Sociales Twitter, Facebook y
también en el Módulo “Ejercicios y Dietas” el cual permitirá el Monitoreo de
actividad Física a través de la App Google Fit.
La aplicación cuenta con entidades que permiten la ejecución de un Motor de
Recomendaciones en base a la Patología que padece el paciente, por estas
características se realizarán cambios en las estructuras de la Base de Datos que
actualmente solo presenta consejos a los Pacientes con Diabetes según la
información que ingrese el paciente y la operación interna que se realiza en la
Aplicación.
Durante la recolección de los requerimientos, se definieron Reglas de Negocio
para las nuevas funcionalidades a implementarse en la Aplicación, las cuales
serán aplicadas desde los Apis de Procesamiento creados en el Sistema Gestor
de Base de Datos MySql.
Durante el desarrollo de la nueva versión de la aplicación HealthMonitor Ug, se
basó en etapas donde se realizaron un grupo determinado de tareas
planificadas, para lo cual se utilizó el gestor de tareas “Trello” , esta aplicación
nos ayudó a todos los grupos que intervinieron en el desarrollo de la nueva
versión llevar un control de eventos debidamente programado.
11
Se determinan los siguientes entregables de la propuesta tecnológica a
implementar:
Manual de Operaciones
Diseño Lógico de la Base de Datos.
Apis de Procesamiento
Base de Datos (archivo exportado .SQL)
OBJETIVOS DE LA INVESTIGACIÓN
OBJETIVO GENERAL
Normalizar el Modelo de Entidad Relación utilizado en la Plataforma
HealthMonitor UG aplicando el concepto de escalabilidad mediante cambios en
las estructuras y API de procedimiento para que soporte la inclusión de una
nueva patología y la interacción con aplicaciones Móvil.
OBJETIVOS ESPECÍFICOS
Optimizar el Modelo de Entidad Relación de la base de datos, haciendo
adaptables sus entidades permitiendo el almacenamiento de información de
una nueva patología (Asma).
Crear nuevas APIS de lógica de negocio para el procesamiento de la
información de la Nueva Patología que se receptará desde la App
HealthMonitor.
Complementar con un nuevo modelo Ontológico para Receptar Información
de otras aplicaciones con tecnología Android con las que trabajará la nueva
versión de la App HealthMonitor UG (Facebook, Google Fit, Twitter).
Controlar novedades de las Transacciones efectuadas en los Store
Procedure a través de Logs de Auditoría.
12
JUSTIFICACIÓN E IMPORTANCIA
Cuando se diseña para ofrecer escalabilidad, el principal objetivo es garantizar
una administración eficaz de los recursos. El diseño para la escalabilidad no está
limitado a ningún nivel o componente concreto de una aplicación. Los arquitectos
de aplicaciones deben considerar la escalabilidad en todos los niveles, desde la
interfaz de usuario hasta el almacén de datos. (Microsoft MSDN, n.d.)
GRÁFICO N° 1 IMPACTO DE ESCALABILIDAD
Elaborador por: Microsoft MSDN Fuente: (Microsoft MSDN, n.d.)
Casi todas las Aplicaciones desarrolladas para Android, actualizan sus versiones
constantemente mejorando sus funcionalidades, uno de los factores relevantes
para su renovación frecuente es la retroalimentación que obtiene de las
opiniones de sus usuarios.
El diseño de una Base de Datos y los componentes que la conforman deben
soportar el crecimiento de una aplicación, referente al nivel de usuarios y el
tráfico que esto implica durante la ejecución de sus transacciones.
13
La escalabilidad de una aplicación sugiere que exista un equilibrio entre dos
plataformas distintas (software y hardware). (Microsoft MSDN, s.f.)
La propuesta planteada para el proyecto en desarrollo, busca incrementar el
rendimiento de la Base de Datos abarcando un mejor Diseño estructural y
optimizando tiempos de respuesta con la creación de Apis de procesamiento
adaptados a las necesidades del cliente.
Se generará una arquitectura escalable en el Modelo Ontológico de la Base de
Datos de la aplicación, mediante la Alteración del Modelo Lógico implementado
en la Aplicación HealthMonitor Ug elaborado por medio del Sistema Gestor de
Base de Datos MySQL.
La importancia de Normalizar un Modelo de Datos es la estabilidad que nos
brinda en el manejo de la información durante la ejecución de las transacciones
desde las plataformas que utilice un Proyecto, donde utilice menos recursos pero
mantenga la misma eficiencia al responder al usuario.
METODOLOGÍA DEL PROYECTO
Para el desarrollo de esta propuesta tecnológica, se implementará Metodología
Scrum una de las más utilizadas en la actualidad para desarrollar proyectos
ágiles.
Las características que resaltan en proyectos ágiles, son la interacción durante
el desarrollo, promover la comunicación entre las áreas de desarrollo, y disminuir
interrupciones (tiempo ocio). Según Scrum Guide considera que “Scrum es un
marco para desarrollar y mantener productos complejos” ( K.Schwaber-
J.Sutherland, 2016), es un procedimiento en el que se emplean de manera
habitual un conjunto de buenas prácticas para trabajar en equipo, con el fin de
obtener el resultado más viable de una propuesta tecnológica. Estos métodos se
sustentan entre ellos y para seleccionar dependen del análisis que realicen con
14
el fin de encontrar la mejor manera de trabajar con equipos altamente
productivos (proyectosagiles.org, s.f.)
GRÁFICO N° 2 PLANIFICACIÓN ÁGIL
Elaborado por: Grupo Proyectos Agiles
Fuente: proyectosagiles.org, n.d.
La metodología Scrum está recomendado para el desarrollo de proyectos que se
desenvuelven en entornos complejos, es decir cuando requieren obtener
resultados ágiles, en este tipo de entorno los requisitos tienden a ser
constantemente volubles o en el levantamiento de requerimientos suelen ser
poco definidos por el cliente, por ello éstas características son
indispensables: innovación, competitividad, flexibilidad y productividad
(proyectosagiles.org, s.f.)
La subdivisión de Equipos de trabajo permitió delegar funciones y encontrar
soluciones a los problemas desde distintos puntos de vista de los equipos
enunciados, que permiten tener una perspectiva lo más completa posible pero a
la vez delimita los aportes de los diversos grupos. A continuación describimos
Los Scrum Team que se segmentaron para el desarrollo de la Aplicación
HealthMonitor UG son los descritos en el gráfico:
15
GRÁFICO N° 3 SCRUM TEAM
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos, Proyecto HealthMonitor UG
El Scrum Team BD se lo organizó para llevar a cabo la Gestión y Administración
de la Base de Datos, se delegaron actividades o tareas a cada uno de sus
integrantes, se clasificó el listado de requisitos del proyecto para obtener una
respuesta óptima y ágil. Permitiendo llevar un correcto flujo de procesos durante
las transacciones de la aplicación HealthMonitor.
GRÁFICO N° 4 TEAM BD
Elaborado por: Johanna Pardo Jara
16
Fuente: Team Base de Datos, Proyecto HealthMonitor UG
La metodología Scrum se emplea para obtener progresos de forma parcial y
frecuente de un producto final, su prioridad de entrega se determina según el
Backlog del cliente y su nivel de criticidad, con el fin de observar gradualmente el
beneficio que aportan al negocio.
El listado de requisitos de las nuevas funcionalidades se gestionaron en el
Scrum Taskboard Trello, donde se puede visualiza el estado de cada objetivo
designado a los integrantes de un proyecto.
GRÁFICO N° 5 GESTOR DE TAREAS TRELLO
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos, Proyecto HealthMonitor UG
17
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
Para llevar a cabo el desarrollo de este proyecto, debemos conocer cuáles son
los antecedentes que promovieron la realización de ésta propuesta científica. Es
necesario conocer que conceptos a nivel tecnológico impulsaron el desarrollo de
la Aplicación HealthMonitor Ug y cuáles son los procesos que se ejecutan
actualmente en la plataforma, es decir conocer el contexto en donde
proponemos implementar las nuevas funcionalidades.
Todas Las personas que padecen diabetes necesitan mantener un control del
nivel de azúcar que tienen en la sangre, monitorizar a diario su alimentación y
cantidad de carbohidratos, controlar su peso y su actividad física que ayudarán a
tener un buen estado de salud y alertar ante posibles complicaciones que
puedan presentarse.
MHealth es una propuesta tecnológica que en los últimos años ha surgido como
un segmento importante de la telemedicina y su objetivo principal es mejorar los
servicios de salud, integrando los beneficios de movilidad y ubicuidad, propios de
los sistemas móviles, a los tratamientos de cuidados de la salud tradicional,
tratando de brindar una nueva forma de atención a los usuarios. Las
aplicaciones de mHealth están creando mecanismos para el intercambio de
información relacionada con el cuidado de la salud, incluso en lugares remotos y
de escasos recursos, debido a la gran área de cobertura e influencia social de
18
las redes de telefonía móvil, convirtiéndose en un factor estratégico para salvar
vidas (Vital Wave Consulting, 2009)
Partiendo de este análisis y datos recolectados se desarrolló HealthMonitor Ug
aplicación que cumple con las necesidades identificadas para los usuarios, la
cuál está diseñada para Smartphone con plataforma Android, puede obtenerse
desde la App Play Store, enfocada al área de Salud específicamente a pacientes
que padecen diabetes.
La aplicación permite llevar un control diario de sus parámetros clínicos básicos
y exámenes especiales que de forma rutinaria los pacientes deben inspeccionar;
además está vinculada a un portal web desarrollado en lenguaje PHP en donde
los resultados obtenidos de los registros de los pacientes son visualizados y
analizados por especialistas, a través de esta funcionalidad les permite identificar
evolución del estado de salud de los pacientes.
Toda la información de la plataforma se almacenará en la base de datos
planteada para el proyecto, al tener el historial de salud de los usuarios
registrados en nuestra aplicación se permite el monitoreo constante de sus
parámetros clínicos. Por medio de la lógica de negocio implementada en sus
procedimientos también podemos alertar a los pacientes cuando durante el
registro de los datos se detecta algún desorden de sus niveles de azúcar u otro
parámetro clínico lo que permite a los usuarios tener una reacción, recordemos
que todos los registros se visualizan por especialistas que brindan una opinión
acertada y acorde a los resultados encontrados.
Para la implementación de la Base de Datos de la aplicación se utiliza el Modelo
Relacional para crear un Esquema con toda la lógica de negocio que se requiere
en la aplicación. Para una visualización amigable y entendible al usuario el
diseño del modelo de Entidad Relación fue plasmado en el Sistema Gestor de
Base de Datos MySQL Workbench.
El Diseño estructural de la Base de Datos de la versión inicial, puede ser
visualizado en la Sección Anexos en donde podrá constatar que el Modelo para
19
control clínico está desarrollado para cubrir el registro de una sola patología.
Para proceder con el rediseño de la Base de Datos se utilizó principios teóricos,
que permitirán fundamentar la solución a proponer, luego de analizar varios
estudios y conceptos en libros e investigaciones se adoptaron los recursos que
cumpla con los requerimientos según las especificaciones del cliente.
FUNDAMENTACIÓN TEÓRICA
ONTOLOGIA
La ontología es parte de la filosofía, está encargada del estudio del ser, la
naturaleza y organización de la entorno. En el campo de la Inteligencia Artificial,
la ingeniería, la representación del conocimiento y la lingüística computacional,
la ontología es utilizada para crear modelos de representación del conocimiento
(Lapuente, 2013).
Estructura de las Ontologías:
Conceptos: Ideas básicas que se intentan formalizar, todo lo que compone un
entorno desde los objetos hasta los eventos del mismo.
Relaciones: Simbolizan el vínculo entre los conceptos.
Funciones: Analiza varios elementos de la ontología aplicando procesamiento
de datos.
Instancias: Se utilizan para representar objetos determinados de un concepto.
Reglas de restricción: normas que se establecen sobre las relaciones que
deben cumplir los elementos de la ontología, permiten deducir discernimiento
que se encuentre propuesto claramente en la taxonomía de conceptos.
(Lapuente, 2013)
MODELO DE NEGOCIO
Un Modelo de Negocio es un esquema donde se definen los elementos
de una actividad en específico facilitando un análisis de todo su contexto con el
20
fin de generar ganancias e identificando sectores estratégicos para captar
afluencia de clientes.
El autor Osterwalder en su libro define (Osterwalder, 2004) los modelos
de Negocio como “una herramienta conceptual que permite expresar la lógica
mediante la cual una compañía intenta ganar dinero generando y ofreciendo
valor a uno o varios segmentos de clientes, la arquitectura de la firma, su red de
aliados para crear, mercadear y entregar este valor, y el capital relacional para
generar fuentes de ingresos rentables y sostenibles” (García J. F., 2010)
GRÁFICO N° 6 FORMATO DE MOELO DE NEGOCIO
Elaborado por: Osterwalder Fuente: La Metodología De Osterwalder En La Práctica, Revista Mba Eafit
Osterwalder, representa a La Ontología de modelos de negocio
segmentados en bloques Temáticos que agrupan las principales variables de un
negocio. (García J. F., 2010)
ESCALABILIDAD
Todo sistema tiene la aspiración de conseguir escalabilidad en su desarrollo,
obtener esta propiedad en sus procesos, demuestra su habilidad para ejecutar
operaciones con fluidez durante el crecimiento frecuente de trabajo,
21
salvaguardando la calidad en los servicios que ofrece a través de sus
plataformas.
La escalabilidad debe ser un complemento importante del proceso de desarrollo
porque no es una característica aislada que se pueda agregar después durante
la etapa de “estabilización” del proyecto, las decisiones que se tomen durante las
etapas iniciales del proyecto establecerán la escalabilidad de la aplicación, el
instante en que el rendimiento de un sistema es mejorado, al sumarle capacidad
de hardware y obtener respuestas favorables durante la ejecución de sus
transacciones se puede evidenciar la existencia de escalabilidad. (Revista
ARQHYS, 2017)
Escalabilidad en carga: en un sistema distribuido, podemos ampliar y reducir
los recursos con mayor facilidad sean pesadas o livianas. (Revista ARQHYS,
2017)
Escalabilidad geográfica: Cuando su utilización y beneficios se mantienen sin
que la distancia de los usuarios cause afectación. (Revista ARQHYS, 2017)
Escalabilidad administrativa: Cuando existe el incremento del número de
usuarios no debe existir afectación a pesar de que las entidades requieran de un
mismo sistema distribuido. (Revista ARQHYS, 2017)
Escalada vertical: Escala hacia arriba, se incorpora un hardware más potente
en la red, desde donde se ejecutarán los procesos. (Revista ARQHYS, 2017)
Escalada horizontal: Se adicionan más nodos a una red del sistema creando
modularidad en sus funcionalidades. (Revista ARQHYS, 2017)
Escalabilidad De Los Modelos De Negocio
Uno de los Atributos más importantes de un modelo de Negocio es la
Escalabilidad, para ello hay que identificar su impacto. (Megias)
22
CUADRO N° 4 MODELO DE NEGOCIO
NO ESCALABLE ESCALABLE
Su estructura de costes
crece de forma lineal a sus
ingresos.
Altas cantidades de recursos
y tiempo.
Más ingresos en menos tiempo
sin exceder costos de estructura.
Factores están desacoplados.
Potencial de generar beneficios
muy altos.
Elaborado por: Johanna Pardo Jara Fuente: https://javiermegias.com/
GRÁFICO N° 7GRAFICA DE MODELO DE NEGOCIO
Elaborado por: Johanna Pardo Jara Fuente: https://javiermegias.com/
23
Escalabilidad de las Bases de Datos
En una base de datos es primordial mantener la facultad de procesar solicitudes
de información de pequeño/mediano/gran volumen de datos; expandir su
capacidad de responder estas peticiones sin afectar las demás transacciones.
BASE DE DATOS
Una Base de Datos se puede denominar como un contenedor de grupos
de información compuesta por datos alfanuméricos o numéricos adecuadamente
establecidos y organizados para su correcto almacenamiento. Además nos
brindan la posibilidad de inferir en la manipulación de los componentes del
esquema lógico como sus tablas, campos, registros y datos, todo esto es posible
mediante el uso de un lenguaje de programación. (Blázquez, 2014)
Esta información por lo general se obtiene a través de alguna plataforma
digital, es almacenada en la Base de Datos mediante una estructura de datos
que cumpla con las necesidades de su modelo de negocio, “cada base de datos
ha sido diseñada para satisfacer los requisitos de información de una empresa u
otro tipo de organización”. (Marqués, 2009)
Acorde a lo indicado en los concepto anteriores una Base de Datos es un
conjunto de datos ya sea de diversos tipos, los cuales se registran o se
almacenan en tablas permitiendo realizar una acción sobre estas ya sea añadir,
eliminar, modificar o realizar consultas, la unión de estas es llamado Base De
Datos, con el objetivo de satisfacer las necesidades de los usuarios finales o el
cliente.
24
OBJETIVOS DE LA BASE DE DATOS
El objetivo principal de un sistema de base de datos es proporcionar a los
usuarios finales una visión abstracta de la información registrada en la
aplicación, esto se logra haciendo invisible el proceso de estructurar el diseño de
la BD ya que los usuarios desean que los sistemas funcionen correctamente.
1. Autonomía Lógica Y Física.: Al emplear esta característica se puede
indicar que la Base de Datos tiene la capacidad de alterar un esquema
estructural, sin que se presenten detalles que puedan afectar a los niveles
inmediatamente superior.
2. Redundancia.: La base de datos debe ser administrable, evitando la
duplicidad innecesaria, redundancias físicas, logrando así en ocasiones
responder a objetivos de eficiencia, de esta forma no puedan producirse
inconsistencias. Con esto se busca que la base de datos sea un repositorio
de información común para que puedan ser utilizadas por distintas
aplicaciones. (Frassia)
3. Acceso continúo.: Una base de datos tiene como objetivo servir a un
conjunto de usuarios, manejando los datos como un recurso de gran
importancia. La base de datos tendrá que atender múltiples peticiones de los
usuarios y de diferentes aplicaciones.
4. Distribución Geográfica.: Los datos pueden ser almacenados en un
servidor ubicado en un edificio cercano al usuario e incluso en otro país.
(Frassia)
5. Integridad.: Es importante tomar medidas de seguridad que impiden que
los datos sean alterados o se introduzcan datos erróneos que perjudique
enteramente a la Base de Datos, puede ser provocado por fallas de
hardware o actualización incompleta debido a causas externas, también
como problemas de operación. (Frassia)
25
6. Optimización de Consultas.: Permite mejorar el tiempo de respuesta
durante la ejecución de las transacciones que se realiza con la información
del usuario. (Frassia)
7. Seguridad De Acceso Y Auditoría: Permite controlar los permisos de
acceso a los datos registrados en la Base de Datos por parte de personas y
organismos.
Los sistemas de auditoría mantienen el control de acceso a la base, con el
objetivo de saber qué o quién realizó un determinado cambio y en qué
momento. (Frassia)
8. Respaldo Y Recuperación.
Esto implica a la capacidad que posee un sistema de Base de Datos de
restauración, respaldo previo a un evento inesperado de perdida de datos.
INTRODUCCIÓN AL DISEÑO DE BASES DE DATOS
La función de una Base de Datos es almacenar la información utilizada
en un sistema de información determinado. “Las necesidades y los requisitos de
los futuros usuarios del sistema de información se deben tener en cuenta para
poder tomar adecuadamente las decisiones anteriores”. (Rafael Camps Paré,
2005)
El diseño de una base de datos radica en especificar la correcta
distribución de los elementos de un sistema de información, si se utiliza un
modelo relacional debe existir se debe implementar un esquema donde se
establezcan vinculaciones de todos los atributos que correspondan.
Acorde a los conceptos anteriores enunciados, nos hace referencia que
una base de datos sirve para almacenar información determinada que es
requerida por un cliente o usuario final.
26
Etapas del diseño de bases de datos.
En esta etapa se deben tener las consideraciones necesarias para
determinar la estructura de la Base de datos, es decir bosquejar adecuadamente
la plantilla sobre la cual se va a almacenar la información, según el autor “La
complejidad de la información y la cantidad de requisitos de los sistemas de
información hacen que sea complicado, por este motivo, cuando se diseñan
bases de datos es interesante aplicar la vieja estrategia de dividir para vencer”.
(Rafael Camps Paré, 2005)
Descomponer un proceso permite identificar con mayor seguridad falencias que
pudieran presentarse durante el desarrollo de cada etapa ejecutada, la
respuesta que nos brinda esta acción es encontrar soluciones favorables para
crear una estructura lógica para almacenar los datos de un determinado
proyecto.
GRÁFICO N° 8 ETAPAS DEL DISEÑO DE UNA BASE DE DATOS
Elaborado por: Johanna Pardo Jara Fuente: http://tarrillobd.blogspot.com/
27
Análisis de Requerimientos
En la realización de una base de datos, la fase del Análisis será la más
importante a realizar porque es indispensable de entender la solicitud que indica
el cliente o usuarios, tomar esta información analizarla con detenimiento,
observar desde distintos puntos de vista con el fin de proceder a diseñar un
modelo que represente la idea del usuario a un esquema de Base de Datos.
GRÁFICO N° 9 ANALISIS DE REQUERIMIENTO
Elaborado por: Fabiana Conde Fuente: http://sobrebasededatos.blogspot.com
Etapa del diseño conceptual:
Ya determinado un buen análisis de requerimientos, en esta instancia se
construye una estructura de la información para q se moldee la base de datos,
aislada a la tecnología que se emplee en la plataforma.
No se tiene en cuenta todavía qué tipo de base de datos se utilizará –
relacional, orientada a objetos, jerárquica, etc., en consecuencia, tampoco se
tiene en cuenta con qué Sistema Gestor de Base de Datos ni con qué lenguaje
concreto se implementará la base de datos. (Rafael Camps Paré, 2005)
Hacemos referencia que en esta etapa el diseño conceptual permite
concentrarnos, analizar el requerimiento del cliente a nivel general para luego
comenzar a definir los pasos para solucionar o cumplir con la solicitud del
usuario.
28
Etapa del diseño lógico:
Luego de plantear el diseño conceptual, se procede a identificar la
tecnología que se empleará para plasmar el diseño lógico de la Base de Datos,
el modelo que se defina debe adaptarse al sistema gestor de base de datos con
el que se desea crear el prototipo final para un determinado proyecto.
Este concepto nos indica que luego de realizar un correcto análisis de la
problemática del entorno del negocio, el diseñador se podrá concentrar en el
ambiente tecnológico relacionado al modelo de Base de Datos tomando la mejor
decisión.
Etapa del diseño físico:
En esta etapa se implementa el diseño lógico planteado pero en esta
ocasión con el soporte del Sistema Gestor de Base de Datos seleccionado. Para
definir el diseño físico se debe establecer los vínculos en el esquema lógico que
representarán el entorno permitiendo con el objetivo de contar con un esquema
eficiente y que brinde seguridad a los datos que se almacenarán.
SISTEMA GESTOR DE BASE DE DATOS
Un SGBD es un sistema computarizado cuya finalidad es almacenar
información y permitir a los usuarios manipular esa información a través de
peticiones a un servidor. “La información en cuestión puede ser cualquier cosa
que sea de importancia para el individuo u organización; en otras palabras, todo
lo que sea necesario para auxiliarle en el proceso general de su administración”.
(Date, Introducción a los Sistemas de Base de Datos, 2001)
Bajo este concepto podemos determinar que un SGBD pretende mostrar
la interacción de los 4 componentes principales para el manejo de información:
datos, hardware, software y usuarios, el diseño final de la Base de Datos
plasmado a través de un Sistema Administrador seleccionado.
29
A continuación consideramos brevemente estos cuatro componentes.
(Date, Introducción a los Sistemas de Base de Datos, 2001)
GRÁFICO N° 10 SISTEMA DE ADMINISTRACIÓN DE BD
Elaborado por: Date, C. J. Fuente: (Date, Introducción a los Sistemas de Base de Datos, 2001)
Beneficios del Sistema Gestor de Base de Datos
Permite definir la base de datos mediante un lenguaje de interpretación
de datos, que describe la estructura y el tipo de los datos, así como las
limitaciones que posee. (Marqués, 2009)
Permite la manipulación de los datos: insertar, actualizar, eliminar y
realizar consultas de datos mediante un lenguaje de análisis de datos.
(Marqués, 2009)
30
Objetivos de los Sistemas Gestor de Base de Datos
Los objetivos de los sistemas Gestores de Base de Datos son los siguientes:
Flexibilidad e independencia
La Evolución de los Sistemas de Información y la necesidad de adaptar
las Bases de Datos a sus nuevos ambientes, hacen importante los SGBD
brinden flexibilidad ante las innovaciones tecnológicas, obteniendo
independencia entre los datos y procesos de los usuarios para que se ajusten a
todo tipo de cambios y variaciones que se presenten (Rafael Camps Paré, 2005).
Los Sistemas Gestores de Base de Datos, deben permitir la autonomía y
flexibilidad en el manejo de la información registrada, sin que deba renovarse en
grandes magnitudes el modo que utiliza el sistema para manipular la
información: ingresar/modificar/actualizar/eliminar/consultar datos.
Redundancia
Es importante evitar inconvenientes con la Redundancia de datos, con
hacemos referencia a un incorrecto almacenamiento de la información por existir
duplicidad de datos en distintos lugares de la BD. Es importante disminuir el
esfuerzo durante la ejecución de transacciones, aprovechando correctamente el
espacio de almacenamiento y manteniendo datos estables.
Integridad de los datos
Es necesario que los Sistemas Gestor de Base de datos aseguren y
mantengan la calidad de la información ante cualquier circunstancia, los datos
deben ser consistentes luego de las operaciones lógicas que se realizan desde
el sistema, la integridad de datos puede verse afectada por diversas situaciones
como: la redundancia, errores de programas, fallos por operación humana,
avería de discos de almacenamiento, transacciones incompletas por procesos
31
eléctricos fallidos, etc. (Rafael Camps Paré, 2005) La importancia de presentar a
los usuarios información correcta e integra generarán confiabilidad.
GRÁFICO N° 11 INTEGRIDAD
Elaborado por: Elser Tarriillo Fuente: (Blog Tarrillobd, s.f.)
Concurrencia de usuarios
Una de las características principales de un Gestor de Base de Datos es
mantener disponible el servicio para varios usuarios a la vez de manera
concurrente y poder responder a sus peticiones sin perder su calidad.
Por ejemplo: uno o más usuarios están actualizando los datos, puede existir
interferencia en el proceso y es posible que tengan como consecuencia la
obtención de datos erróneos y la pérdida de integridad de la información de la
base de datos. (Rafael Camps Paré, 2005)
Seguridad
En este campo de estudio, el término seguridad hace referencia a los temas
relativos a la confidencialidad de los datos, mencionamos a las autorizaciones,
los derechos de acceso, etc. (Rafael Camps Paré, 2005)
32
Los sistema de gestor de base de datos nos facilitan administrar las
autorizaciones validando sus niveles: al nivel global de toda la base de datos, al
nivel entidad y al nivel atributo. Para ejecutar estos mecanismos de seguridad se
necesita que el usuario que accede al sistema identifique con las credenciales
otorgadas. (Rafael Camps Paré, 2005)
GRÁFICO N° 12 SEGURIDAD
Elaborado por: Elser Tarriillo Fuente: (Blog Tarrillobd, s.f.)
EQUIPO DEL ENTORNO DE LAS BASES DE DATOS.
En el entorno de una base de datos existen 4 grupos de personas que
intervienen en cada etapa del desarrollo de la misma.
- El administrador de la base de datos
Es la persona encargada de la implementación de la Base de Datos, tiene el
deber de realizar el control de la seguridad y de la concurrencia de los datos,
debe mantener el sistema activo para los servicios de un negocio y es
responsable de que los usuarios y las aplicaciones obtengan buenas
prestaciones. (Marqués, 2009)
Quien administre la Base de Datos debe conocer muy bien el SGBD que se
utiliza para el manejo de la información, así como toda la infraestructura donde
esté funcionando. (Marqués, 2009)
33
El administrador tiene la responsabilidad de garantizar la operatividad de la Base
de Datos durante las transacciones de un sistema.
GRÁFICO N° 13 ADMINSTRADOR DE BASE DE DATOS
Elaborado por: Elser Tarriillo Fuente: https://www.mindomo.com/
- Los diseñadores de la base de datos
Son los encargados de realizar el diseño de la base de datos, tienen que
analizar e identificar los datos, relaciones entre datos y restricciones sobre los
datos y sus relaciones, una característica importante de un diseñador es tener un
profundo conocimiento de la información que maneja la empresa y considerando
sus normativas o reglas de negocio.
Las normas o reglas de negocio, nos facilitan identificar el comportamiento de los
datos acorde a la lógica de la compañía, con el fin de sacar un modelo basado
personalizado a sus necesidades como negocio.
34
El diseñador de la base de datos debe involucrar en el proceso a todos los
usuarios de la base de datos desde el inicio, para retroalimentarse de sus
opiniones y obtener mejores resultados. (Marqués, 2009)
GRÁFICO N° 14 DISEÑADOR DE LA BAS DE DATOS
Elaborado por: Elser Tarriillo Fuente: https://es.dreamstime.com
- Desarrolladores
Gestionan la creación e implementación de las aplicaciones que trabajarán
directamente con los usuarios finales, estos programas de aplicación son los que
permiten de manera dinámica y agradable a través módulos manipular los datos
(consultar/insertar/actualizar/eliminar), para el desarrollo de estos programas se
utilizan lenguajes de programación de alto nivel. (Marqués, 2009).
- Usuarios
Son los clientes que manejan la información de la Base de datos desde algún
aplicativo (escritorio/móvil/web) con las que solventa los requisitos en la gestión
de sus datos.
35
Como se indica, los usuarios son los beneficiarios para los cuales la creación de
la base de datos y el aplicativo deben funcionar con los requerimientos que se
estableció en las reglas de negocio y anteriores análisis.
GRÁFICO N° 15 USUARIOS DE LA BASE DE DATOS
Elaborado por: Johanna Pardo Jara Fuente: https://www.mindomo.com/
ARQUITECTURA DE BASE DE DATOS
NIVELES DE LA ARQUITECTURA
El Modelo ANSI/SPARC (American National Standards Institute, Standards
Planning And Requirements Committee) es utilizado como plantilla por los
Sistemas Gestores de Base de Datos, el cual se divide en tres niveles: interno,
conceptual y externo como se ilustra en el gráfico.
GRÁFICO N° 16 NIVELES DE BD
Elaborado por: Date, C. J.
Fuente: (Date, Introducción a los Sistemas de Base de Datos, 2001)
36
1. Nivel Interno:
Se refiere al nivel físico de la Base de Datos, identificando la manera como los
datos se encuentran almacenados físicamente a nivel de hardware (Ubicación de
la información).
2. Nivel Externo:
Es denominado como nivel lógico, interactúa directamente con el usuario, y la
información a la que puede acceder.
3. Nivel Conceptual:
El nivel conceptual tiene que ver con la percepción de un grupo de usuarios, se
refiere a una descripción general de los datos almacenados y como se vinculan
entre ellos.
DISEÑO CONCEPTUAL
El Modelo de Entidad Relación, es uno de los esquemas más utilizados en la
actualidad por su simplicidad y por ser entendible para quienes administran una
base de datos. Este modelado facilita un esquema estructural muy comprensivo.
Es una herramienta útil tanto para ayudar al diseñador a reflejar en un modelo
conceptual los requisitos del mundo real de interés como para comunicarse con
el usuario final sobre el modelo conceptual obtenido, con el fin de corroborar el
cumplimiento de los requerimientos del cliente (Rafael Camps Paré, 2005)
Este tipo de diseño suele ser adaptable a la mayoría de entornos tecnológicos
de las aplicaciones. Actualmente existen herramientas que permiten utilizar
alguna variante del modelo Entidad Relación para hacer el diseño conceptual.
(Rafael Camps Paré, 2005)
El Modelo de Entidad Relación está compuesto por entidades y sus
interrelaciones, este tipo de modelos “…está basado en una percepción del
37
mundo real consistente en objetos básicos llamados entidades y de relaciones
entre estos objetos” (Rafael Camps Paré, 2005) Este modelo se creó para
facilitar el diseño, permitiendo describir adecuadamente un esquema de la lógica
de negocio que se busca personalizar.
En este concepto se enuncian tres componentes básicos que se
observan en el MER (Modelo de Entidad-Relación).
Entidad:
Es todo elemento que compone el mundo real, y que tiene características
específicas que marcan la diferencia entre los demás objetos.
Colección de Entidades:
Es un grupo de entidades que coinciden en sus propiedades, los
conjuntos de entidades no son necesariamente disjuntos. (Silberschatz A. H.,
2006)
Atributo:
Son las características y/o propiedades que describen a las entidades,
con la selección de atributos apropiados se suministrará a la base de datos
información equivalente y referente a cada entidad del conjunto.
Un diagrama de Entidad Relación permite describir de forma gráfica la estructura
lógica de una base de datos, consta de los siguientes componentes:
- Los conjunto de entidades son representadas por rectángulos
- Los Atributos son simbolizados por elipses
- Los Rombos representan las relaciones que existen entre conjuntos de
entidades
- Las Líneas son utilizadas para unir los atributos con entidades y los
conjuntos de entidades con las relaciones.
38
Propiedades de las relaciones
Las relaciones tienen las siguientes características:
- Cada relación tiene un nombre y éste es distinto del nombre de todas las
demás.
- Los valores de los atributos son atómicos: en cada campo, cada atributo
toma un solo valor. Se dice que las relaciones están normalizadas.
- No hay dos atributos que se llamen igual.
- El orden de los atributos no importa: los atributos no están ordenados.
- Cada campo es distinto de las demás: no hay campos duplicados.
- El orden de los campos no importa: los campos no están ordenadas
(Marqués, 2009).
Tipos de relaciones:
En un Sistema de Gestor de Base de Datos relacional pueden existir
varios tipos de relaciones, aunque no todos manejan todos los tipos.
Relaciones base:
Son vínculos reales que tienen nombre y forman parte directa de la base
de datos almacenada, son independientes. (Ramos & Ramos, 2007)
Vistas:
Conocidas como relaciones virtuales, se representan mediante su
definición en términos de otras relaciones con nombre, las vistas no
tienen datos almacenados propios. (Ramos & Ramos, 2007)
Instantáneas:
Son relaciones con nombre y derivadas. Pero a diferencia de las vistas,
son reales, no virtuales: están representadas no sólo por su definición en
términos de otras relaciones con nombre, sino también por sus propios
datos almacenados. Son relaciones de sólo de lectura y se refrescan
periódicamente. (Marqués, 2009)
39
Claves:
En una relación no hay campos repetidos, éstas se pueden distinguir
unas de otras, es decir, se pueden identificar de modo único. La forma de
identificarlas es mediante los valores de sus atributos. (Marqués, 2009)
GRÁFICO N° 17 ELEMENTOS DE UNA TABLA
Elaborado por: Josefina Vicentiño
Fuente: http://usodeoracle.blogspot.com
Se denomina clave primaria de una relación a aquella clave candidata que se
escoge para identificar sus campos de modo único. En una relación no tiene
campos duplicados, siempre hay una clave candidata y, por lo tanto, la relación
siempre tiene clave primaria.
En el peor caso, la clave primaria estará formada por todos los atributos de la
relación, pero normalmente habrá un pequeño subconjunto de los atributos que
haga esta función. (Marqués, 2009)
Reglas de integridad:
Una vez definida la estructura de datos del modelo relacional, pasamos a
estudiar las reglas de integridad que los datos almacenados en dicha estructura
deben cumplir para garantizar que son correctos.
40
Existen dos reglas de integridad muy importantes que son restricciones que se
deben cumplir en todas las bases de datos relacionales y en todos sus estados
(las reglas se deben cumplir todo el tiempo). Estas reglas son la regla de
integridad de entidades y la regla de integridad referencial. Antes de definirlas,
es preciso conocer el concepto de nulo. (Marqués, 2009)
Nulo:
Un nulo no representa el valor cero ni la cadena vacía ya que éstos son valores
que tienen significado. El nulo implica ausencia de información, bien porque al
insertar el campo se desconocía el valor del atributo, o bien porque para dicho
campo el atributo no tiene sentido. (Marqués, 2009)
Regla de integridad de entidades:
La primera regla de integridad se aplica a las claves primarias de las relaciones
base: ninguno de los atributos que componen la clave primaria puede ser nulo.
Por definición, una clave primaria es una clave irreducible que se utiliza para
identificar de modo único los campos. (Marqués, 2009)
Regla de integridad referencial:
La segunda regla de integridad se aplica a las claves ajenas: si en una relación
hay alguna clave ajena, sus valores deben coincidir con valores de la clave
primaria a la que hace referencia, o bien, deben ser completamente nulos
(Marqués, 2009)
En el desarrollo de nuestra investigación hablaremos detalladamente sobre el
diseño Lógico, anteriormente ya se había indicado un concepto.
DISEÑO LÓGICO:
Modelo Entidad Relación:
Los elementos básicos del modelo ER son las entidades y las interrelaciones:
41
a) Las entidades, cuando se traducen al modelo relacional, originan
relaciones.
b) Las interrelaciones, en cambio, cuando se transforman, pueden dar
lugar a claves foráneas de alguna relación ya obtenida o pueden dar
lugar a una nueva relación. (Rafael Camps Paré, 2005)
En el caso de las interrelaciones, es necesario tener en cuenta su grado y su
conectividad para poder decidir cuál es la transformación adecuada:
- Las interrelaciones binarias 1:1 y 1: N dan lugar a claves foráneas.
- Las interrelaciones binarias M: N y toda la n-aria se traducen en nuevas
relaciones.
Conectividad 1: N
Partimos del hecho de que las entidades que intervienen en la interrelación 1: N
se han trasformado en relaciones con nuevos atributos. (Rafael Camps Paré,
2005)
GRÁFICO N° 18 RELACION 1:N
Elaborado por: Costa, Costal Fuente: Introducción al diseño de la base de datos
Conectividad M: N
Una interrelación M: N se transforma en una relación. Su clave primaria estará
formada por los atributos de la clave primaria de las dos entidades
42
interrelacionadas. Los atributos de la interrelación serán atributos de la nueva
relación. (Rafael Camps Paré, 2005)
GRÁFICO N° 19 RELACIÓN M:N
Elaborado por: Costa, Costal Fuente: Introducción al diseño de la base de datos
Resumen de la transformación del modelo ER al modelo relacional
La tabla que mostramos a continuación resume los aspectos más básicos de las
transformaciones que hemos descrito en las secciones anteriores, con el objetivo
de presentar una visión rápida de los mismos:
GRÁFICO N° 20 TRANSFORMACION MODELO ER
Elaborado por: Costa, Costal Fuente: Introducción al diseño de la base de datos
43
DISEÑO FISICO: SQL
Componentes de SQL:
El lenguaje SQL se compone de una serie de comandos, cláusulas,
operadores y funciones agregadas que se combinan entre ellas para formar las
instrucciones necesarias que se ejecutaran utilizando los correspondientes
métodos de los objetos de acceso a datos, de tal forma que podamos crear,
actualizar y manipular nuestras bases de datos. (URIBE, 2008)
Comandos
Los comandos son aquellas instrucciones que se pueden ejecutar
directamente, entendiendo por instrucción la expresión de consulta SQL
generada por el nombre del comando y los restantes parámetros requeridos por
el mismo. (URIBE, 2008). En las siguientes tablas se detallan las instrucciones
de las dos clases de comandos.
GRÁFICO N° 21 COMANDOS DLL
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
44
GRÁFICO N° 22 COMANDOS DML
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
Cláusulas:
Las cláusulas son condiciones de modificación que se utilizan para definir
los datos que deseamos seleccionar o manipular. (URIBE, 2008)
GRÁFICO N° 23 CLAÚSULAS
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
OPERADORES
Operadores Lógicos:
Los operadores lógicos se utilizan para evaluar expresiones, generalmente
dentro de una cláusula WHERE.
45
GRÁFICO N° 24 OPERADORES LÓGICOS
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
Operadores de Comparación:
Entre los operadores de Comparación tenemos los siguientes:
GRÁFICO N° 25 OPERADORES DE COMPARACIÓN
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
TIPOS DE DATOS:
Al igual que C y otros lenguajes de programación, MySQL dispone de distintos
tipos de datos, aplicables tanto para constantes como para variables. (URIBE,
2008)
46
GRÁFICO N° 26 TIPOS DE DATOS MYSQL
Elaborado por: Uribe Guillermo Fuente: Desarrollo e implementación informática de un sistema de ascenso
de nivel para los profesores de la ESPOL
BASES DE DATOS EN MYSQL
MySQL es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en
inglés) muy conocido y ampliamente usado por su simplicidad y notable
rendimiento. Aunque carece de algunas características avanzadas disponibles
en otros SGBD del mercado, es una opción atractiva tanto para aplicaciones
comerciales, como de entretenimiento precisamente por su facilidad de uso y
tiempo reducido de puesta en marcha. Esto y su libre distribución en Internet
bajo licencia GPL le otorgan como beneficios adicionales (no menos
importantes) contar con un alto grado de estabilidad y un rápido desarrollo.
(Santillán, Software Libre, 2005)
47
Su gran éxito se debe a su accesibilidad para implementar de pequeños a
grandes sistemas confiables y de alto rendimiento a bajo costo, se distingue por
ser un sistema rápido y robusto, fácilmente portable entre distintitos y
plataformas, especialmente eficaz en sistemas con pocos recursos, tiene
capacidad multiproceso que permite adaptarse en arquitecturas de mayor
complejidad.
Considerado uno de los Gestores de bases de datos más populares de código
abierto, su plataforma es utilizada por sitios Web como Twitter, Facebook y
YouTube gracias a su rendimiento y confiabilidad. (García J. L., 2015)
GRÁFICO N° 27 LOGO MYSQL
Elaborado por: https://www.mysql.com/ Fuente: https://www.mysql.com/
CARACTERÍSTICAS DE MYSQL
Es un SGBD que ha ganado popularidad por una serie de atractivas
características:
Está desarrollado en C/C++.
Se distribuyen ejecutables para cerca de diecinueve plataformas
diferentes.
La API se encuentra disponible en varios lenguajes de programación
como Eiffel, C/C++, Java, Python, Perl, PHP, Ruby y Tool Command
Language TCL.
48
Está optimizado para equipos de múltiples procesadores.
Es muy destacable su velocidad de respuesta.
Se puede utilizar como cliente-servidor o incrustado en aplicaciones.
Cuenta con un rico conjunto de tipos de datos.
Soporta múltiples métodos de almacenamiento de las tablas, con
prestaciones y rendimiento diferentes para poder optimizar el SGBD a
cada caso concreto.
Su administración se basa en usuarios y privilegios.
Se tiene constancia de casos en los que maneja cincuenta millones
de registros, sesenta mil tablas y cinco millones de columnas.
Sus opciones de conectividad abarcan TCP/IP, sockets UNIX y
sockets NT, además de soportar completamente ODBC.
Los mensajes de error pueden estar en español y hacer ordenaciones
correctas con palabras acentuadas o con la letra ’ñ’.
Es altamente confiable en cuanto a estabilidad se refiere. (Santillán,
Software Libre, 2005)
MySQL y su Escalabilidad.
El servidor de base de datos MySQL te proporciona lo último en escalabilidad,
luciendo la capacidad de manejar aplicaciones profundamente arraigadas con
una huella de tan sólo 1 MB a la ejecución de los almacenes de datos masivos
que llevan a cabo terabytes de información. Flexibilidad de la plataforma es una
característica incondicional de MySQL con todas las versiones de Linux, UNIX y
Windows. Y, por supuesto, la naturaleza de código abierto de MySQL permite
una personalización completa para aquellos que quieran añadir requisitos únicos
para el servidor de base de datos. ( Neothek, Sitios web, Web hosting, 2016).
49
FUNDAMENTACIÓN LEGAL
LEY DE COMERCIO ELECTRÓNICO, FIRMAS
ELECTRÓNICAS Y MENSAJES DE DATOS
TITULO PRELIMINAR
Art. 1.- Objeto de la Ley. - Esta Ley regula los mensajes de datos, la
firma electrónica, los servicios de certificación, la contratación electrónica y
telemática, la prestación de servicios electrónicos, a través de redes de
información, incluido el comercio electrónico y la protección a los usuarios de
estos sistemas.
TITULO I
DE LOS MENSAJES DE DATOS
CAPITULO 1
PRINCIPIOS GENERALES
Art. 9.- Protección de datos. –
Para la elaboración, transferencia o utilización de bases de datos,
obtenidas directa o indirectamente del uso o transmisión de mensajes de datos,
se requerirá el consentimiento expreso del titular de éstos, quien podrá
seleccionar la información a compartirse con terceros.
La recopilación y uso de datos personales responderá a los derechos de
privacidad, intimidad y confidencialidad garantizados por la Constitución Política
de la República y esta ley, los cuales podrán ser utilizados o transferidos
únicamente con autorización del titular u orden de autoridad competente. No
será preciso el consentimiento para recopilar datos personales de fuentes
accesibles al público, cuando se recojan para el ejercicio de las funciones
50
propias de la administración pública, en el ámbito de su competencia, y cuando
se refieran a personas vinculadas por una relación de negocios, laboral,
administrativa o contractual y sean necesarios para el mantenimiento de las
relaciones o para el cumplimiento del contrato. El consentimiento a que se
refiere este artículo podrá ser revocado a criterio del titular de los datos; la
revocatoria no tendrá en ningún caso efecto retroactivo.
DECRETO N° 1014 DEL GOBIERNO
ACERCA DEL USO DE SOFTWARE LIBRE
Artículo 1: Establecer como política pública para las Entidades de la
Administración Pública Central la utilización de Software Libre en sus sistemas y
equipamientos informáticos.
Artículo 2: Se entiende por Software Libre a los programas de computación
que se pueden utilizar y distribuir sin restricción alguna, que permite el acceso a
sus códigos fuentes y que sus aplicaciones pueden ser mejoradas. Estos
programas de computación tienen las siguientes libertades:
Utilización de programa con cualquier propósito de uso común.
Distribución de copias sin restricción alguna.
Estudio y modificación de programa (Requisito: código fuente disponible)
Publicación del programa mejorado (Requisito: código fuente disponible
Artículo 3: Las entidades de la administración pública central previa a la
instalación del software libre en sus equipos, deberán verificar la existencia de
capacidad técnica que brinde el soporte necesario para este tipo de software.
Artículo 4: Se faculta la utilización de software propietario (no libre) únicamente
cuando no exista una solución de software libre que supla las necesidades
requeridas, o cuando esté en riesgo de seguridad nacional, o cuando el proyecto
informático se encuentre en un punto de no retorno.
Artículo 5: Tanto para software libre como software propietario, siempre
y cuando se satisfagan los requerimientos.
51
Articulo. 6: La subsecretaría de Informática como órgano regulador y ejecutor de
las políticas y proyectos informáticos en las entidades de Gobierno Central
deberá realizar el control y seguimiento de este Decreto.
Artículo 7: Encargue de la ejecución de este decreto los señores
Ministros Coordinadores y el señor Secretario General de la Administración
Pública y Comunicación
CONSTITUCIÓN DE LA REPÚBLICA DEL ECUADOR
TÍTULO II
DERECHOS
Capítulo segundo
Derechos del buen vivir
Sección Tercera
Comunicación e Información
Art. 16.- Todas las personas, en forma individual o colectiva, tienen derecho a:
1. Una comunicación libre, intercultural, incluyente, diversa y participativa,
en todos los ámbitos de la interacción social, por cualquier medio y
forma, en su propia lengua y con sus propios símbolos.
2. El acceso universal a las tecnologías de información y comunicación.
3. La creación de medios de comunicación social, y al acceso en igualdad
de condiciones al uso de las frecuencias del espectro radioeléctrico para
la gestión de estaciones de radio y televisión públicas, privadas y
comunitarias, y a bandas libres para la explotación de redes
inalámbricas.
4. El acceso y uso de todas las formas de comunicación visual, auditiva,
sensorial y a otras que permitan la inclusión de personas con
discapacidad.
52
5. Integrar los espacios de participación previstos en la Constitución en el
campo de la comunicación.
TÍTULO VII
RÉGIMEN DEL BUEN VIVIR
Capítulo primero Inclusión y equidad
Sección primera
Educación
Art. 350.- El sistema de educación superior tiene como finalidad la formación
académica y profesional con visión científica y humanista; la investigación
científica y tecnológica; la innovación, promoción, desarrollo y difusión de los
saberes y las culturas; la construcción de soluciones para los problemas del
país, en relación con los objetivos del régimen de desarrollo.
Sección octava
Ciencia, tecnología, innovación y saberes ancestrales
Art. 385.- El sistema nacional de ciencia, tecnología, innovación y saberes
ancestrales, en el marco del respeto al ambiente, la naturaleza, la vida, las
culturas y la soberanía, tendrá como finalidad:
1. Generar, adaptar y difundir conocimientos científicos y tecnológicos.
2. Recuperar, fortalecer y potenciar los saberes ancestrales.
3. Desarrollar tecnologías e innovaciones que impulsen la producción
nacional, eleven la eficiencia y productividad, mejoren la calidad de vida y
contribuyan a la realización del buen vivir.
53
HIPÓTESIS
Si se implementa correctamente la Administración y Gestión de Base de
Datos dentro del aplicativo HelathMonitor Ug utilizado para el control y monitoreo
de pacientes con Diabetes y Asma, se pretende comprobar los siguientes
aspectos:
Se creará el Modelo Ontológico apropiado para realizar transacciones con la
información que registrarán los pacientes con Asma y Diabetes a través
desde la App y su interacción con otras aplicaciones (Twiter, Google Fit y
Facebook).
Se mejorará el procesamiento de información aplicando las reglas de
negocio definidas por el área de proceso a través de APIs (interfaz de
programación de aplicaciones).
VARIABLES DE LA INVESTIGACIÓN
VARIABLE INDEPENDIENTE:
Administración y Gestión de la Base de Datos.
VARIABLE DEPENDIENTE:
Modelo de Entidad Relación implementado en la Base de Datos de la
Plataforma.
Store Procedure que permitan el procesamiento de la información que
se obtiene desde los diversos módulos de la App.
54
DEFINICIONES CONCEPTUALES
ONTOLOGÍA: Descripción de varios conocimientos y sus relaciones en dominio
dado, proporcionan una comprensión común de un contexto, facilitan el
razonamiento automático.
MYSQL: Herramienta OpenSource utilizada para el almacenamiento de los
registros de la Aplicación HealthMonitor Ug. Es un sistema gestor de bases de
datos relacionales rápido, sólido y flexible. Es idóneo para la creación de bases
de datos con acceso desde páginas web dinámicas, así como para la creación
de cualquier otra solución que implique el almacenamiento de datos,
posibilitando realizar múltiples y rápidas consultas (COBO ÁNGEL y GÓMEZ
PATRICIA, 2005).
MODELO DE ENTIDAD RELACIONAL: herramienta conveniente para facilitar al
diseñador plasmar un modelo conceptual que permite verificar la lógica
establecida y satisfacer los requerimientos del cliente
API: Application Programming Interface,agrupación de funciones y
procedimientos o métodos que ofrece cierta librerías, funciona como una capa
de abstracción y es invocado desde otras aplicaciones.
ESCALABILIDAD: Propiedad de aumentar la capacidad de trabajo o de tamaño
de un sistema sin comprometer el funcionamiento y calidad normales del mismo.
En bases de datos se refiere a capacidad para responder a búsquedas de
información en una proporción aceptable con respecto a la cantidad de datos
que almacenan. Una base de datos es escalable en la medida que pueda
responder a diversas necesidades de manejo de datos: tamaño, distribución y
número de consultas son algunos parámetros. (Aboutespanol-Luis Castro, n.d.)
MYSQL WORKBENCH: Es una herramienta visual unificada para arquitectos de
bases de datos, desarrolladores y DBAs, proporciona una consola visual para
administrar fácilmente entornos MySQL y obtener una mejor visibilidad en las
55
bases de datos (MYSQL, n.d.)
SISTEMA GESTOR DE BASE DE DATOS: son aplicaciones para el manejo de
Bases de Datos, cuya finalidad general es almacenar información y permitir a los
usuarios recuperar y actualizar esos datos por medio de peticiones realizadas
(Date, Introducción a los Sistemas de Base de Datos, 2001)
ANDROID: reconocido como un sistema operativo con programación de código
abierto, permite que los fabricantes de dispositivos móviles compitan e innoven.
Los desarrolladores de aplicaciones pueden llegar a mayores audiencias y
construir empresas sólidas. (Lockheimer, n.d.) .Nuestra App HealthMonitor Ug
está diseñada para ser ejecutada en Smartphone con SO Android, y puede ser
descargada desde Google App Store.
APP: es un programa informático generalmente diseñado para funcionar en
dispositivos móviles, que permite que el usuario lleve a cabo una o varias
operaciones, puede ser limitada o amplia, sencilla o compleja. Las aplicaciones
son rápidas y satisfacen una demanda. (Howard Gardner, Katie Davis, 2014)
PHP: es un acrónimo recursivo para "PHP: Hypertext Preprocessor",
originalmente Personal Home Page, es un lenguaje interpretado libre, usado
originalmente solamente para el desarrollo de aplicaciones web y que actuaran
en el lado del servidor, capaces de generar contenido dinámico en la www.
(Miguel Ángel Arias, 2017). El portal web de nuestra aplicación está desarrollado
en PHP, y será utilizado por los especialistas registrados para el monitoreo de
los pacientes con diabetes y/o asma que consten en nuestra base de datos.
MHEALTH: crecimiento de la práctica de la medicina y la salud pública
soportada por los dispositivos móviles, permite interactuar directamente y/o “en
línea” con los profesionales del sector sanitario, lo que permite gestionar nuestra
propia salud a través de internet, todo ello soportado por las TIC (Ramos Lopez,
Javier, Soguero Ruiz, Cristina, Mora Jimenez, Inmaculada, Rojo Alvarez, Jose
Luis, Cabo Salvador, Javier, 2014)
56
WEBAPPS: las plataformas o aplicaciones web no tienen la necesidad de
realizar un proceso de instalación, al utilizar el navegador pueden acceder desde
un computador o teléfonos inteligentes, ingresando como un sitio web normal.
Por esta misma razón, no se distribuyen en una tienda de aplicaciones, sino que
se comercializan y promocionan de forma independiente. (Javier Cuello – José
Vittone, 2013)
DATAMINING: (Minería de datos), Conformado por técnicas y tecnologías que
facilitan la exploración de bases de datos inmensas, este proceso se realiza de
manera automática o semiautomática, tiene como objetivo identificar patrones
repetitivos, tendencias o reglas que permitan identificar el comportamiento de los
datos en un determinado contexto (Sinnexus, 2016)
PEAK FLOW: El flujo espiratorio pico (FEP) es la cantidad máxima de aire por
segundo (flujo) que puede ser expulsada de los pulmones en forma forzada
(soplando) durante la primera parte de la espiración. Es una medida que ayuda a
verificar el grado de control del asma (Fundación Argentina del Tórax, 2016).
SPRINT: Ciclo de trabajo al final del cual entregaremos un incremento
completamente funcional completamente funcional
BACKLOG: Lista de tareas que permite completar los objetivos/requisitos
seleccionados para la iteración en forma de incremento de producto preparado
para ser entregado. (proyectosagiles.org, s.f.)
57
CAPÍTULO III
METODOLOGÍA
DISEÑO DE LA INVESTIGACIÓN
MODALIDAD DE LA INVESTIGACIÓN
Para el desarrollo de nuestra propuesta nos enfocamos en la
investigación aplicada, ya que nos permite utilizar los conocimientos adquiridos
en la práctica, lo cual facilita identificar los patrones reales para otorgar
respuestas y soluciones en base a datos reales e irrefutables.
GRÁFICO N° 28 INVESTIGACIÓN
Elaborado por: Mailen Avellaneda Fuente: http://blog.elinsignia.com
TIPO DE INVESTIGACIÓN
El tipo de investigación que utilizamos en el Desarrollo de nuestro
proyecto es la Investigación Descriptiva, la cual permite detallar acontecimientos
58
reales, para justificar la necesidad de implementar un Modelo de Datos
Escalable y adaptable a nuevas funcionalidades que se deberán mostrar sobre
la App HealthMonitor Ug.
POBLACIÓN Y MUESTRA
GRÁFICO N° 29 MUESTREO EN INVESTIGACIÓN DESCRIPTIVA
Elaborado por: Johanna Pardo Jara Fuente: Datos de Investigación
POBLACIÓN:
Es el conjunto integral de sujetos, objetos o medidas que constan de
características similares que son expuestas en un lugar y en un momento
determinado. (Wigodski, 2010)
MUESTRA:
Representa una sección de la población en donde se enfocará el análisis a
realizar. El tipo de muestra que se seleccione dependerá de la calidad y que tan
específico se quiera sea el estudio de la población. (Wigodski, 2010)
Unidades de Análisis
La unidad de análisis hace referencia quienes forman parte de la población o
grupo de estudio de la investigación, en nuestro caso, pacientes, doctores u otro
elemento que presente diversas características.
59
Intervalos de Confianza:
Son límites o márgenes de variabilidad que damos al valor estimado, para poder
afirmar, bajo un criterio de probabilidad, que el verdadero valor no los rebasará:
(Montero)
GRÁFICO N° 30 NIVELES DE CONFIANZA
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
TÉCNICAS E INSTRUMENTOS DE RECOLECCION DE DATOS
TÉCNICAS:
Para la recolección de Datos de esta investigación, se utilizará la Técnica
de campo, lo que permitirá encontrar datos específicos para justificar la
implementación de la propuesta tecnológica mediante el uso de:
Entrevista:
Se utilizará para entender la visión de uno de los responsables de la Base
de Datos implementada en la Fase inicial de la App HealthMonitor UG.
Sentencias SQL:
De la Base de Datos recolectada, se analizará la influencia que tiene la
opinión de los usuarios en la Red Social Twitter a través de sus Publicaciones en
donde se enfoquen en las Patologías Diabetes/Asma, cada característica será
considerada como unidades de análisis.
60
INSTRUMENTOS
Guía para la entrevista
Para el desarrollo de la Entrevista se estipulo una guía que permitió
establecer una comunicación directa con uno de los usuarios de la Base de
Datos, con el fin de conocer la opinión precisa de su experiencia en el desarrollo
de la Versión inicial de la App.
CUADRO N° 5 GUÍA PARA LA ENTREVISTA
Día: Fecha:
Lugar: Entrevistado:
Tema: Modelo de Entidad Relación de la Base de Datos de la App
HealthMonitor UG.
Pregunta
1
¿Qué función cumplió dentro del proceso del Proyecto
HealthMonitor UG en su primera Versión?
Pregunta
2
¿Qué herramientas se utilizó para el diseño y desarrollo de la
Base de Datos implementada en la aplicación?
Pregunta
3
¿Cuál era la visión general que se planteó al inicio del proyecto?
Pregunta
4
¿En qué se fundamentaron para establecer las estructuras del
Diseño Lógico planteado?
Pregunta
5
¿Cuál fue el nivel de cumplimiento respecto al modelo de Entidad
Relación planteado versus los Requerimientos iniciales del
proyecto?
Pregunta
6
¿Qué limitaciones se presentaron durante el proceso de
desarrollo?
Pregunta
7
¿Qué novedades se presentaron durante la ejecución de Store
Procedure?
Pregunta
8
¿Qué cree Ud. que se necesite mejorar en el MER?
Elaborado por: Johanna Pardo Jara
Fuente: Datos de Investigación
61
UNIDADES DE ANÁLISIS DEL DESARROLLO
Se consideró las siguientes unidades de análisis para determinar la viabilidad de
la propuesta tecnológica a desarrollar en la App HealthMonitor Ug.
CUADRO N° 6 DESCRIPCIÓN UNIDADES DE ANÁLISIS.
Población Muestra Unidad de
Análisis Variables
Base de Datos
APP HealthMonitor
Ug.
COMPONENTES
DE LA BASE DE
DATOS MYSQL
Métricas de
Escalabilidad
Motor de
Almacenamiento
Número de Entidades
Uso de Recursos
Todas las
personas que
cuentan con un
Smartphone y
tienen asociada un
cuenta de Red
Social Twitter
Personas que
padecen
Diabetes Mellitus
Tipo 1,
Diabetes Mellitus
Tipo 2 y Diabetes
Gestacional
Publicaciones
registradas en la
BD (Fuente: Red
Social Twitter)
Contexto de
Publicaciones:
Informativo
Aporte Científico
Recomendaciones
Personas que
padecen Asma
Estado de Ánimo
Aceptación de
Público
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
1. Métricas de Escalabilidad analizadas en la Base de Datos implementada
en la App HealthMonitor Ug.
62
Cuál es el motor de Base de Datos utilizado en la el Gestor MySql para el
desarrollo del Proyecto InnoDB o MyISAM.
GRÁFICO N° 31 MOTOR MYSQL
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
Análisis:
Se utiliza en todo el esquema de la Base de Datos el Motor InnoDB lo que
brinda la integridad de la información de nuestros usuarios registrados,
soporta el aumento de número de Transacciones por las nuevas
funcionalidades implementadas.
¿En qué porcentaje ha aumentado el número de Entidades implementadas
en la Base de Datos diseñada para el proyecto en curso, en comparación a
la Versión inicial de la App HealthMonitor Ug?
GRÁFICO N° 32 COMPARATIVO ENTIDADES
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
63
Análisis:
Para mantener un esquema escalable y cumplir la propuesta realizada y se
aumentó en un 63% el número de entidades empleadas en Base de Datos.
Describir gráficamente la comparación del crecimiento vs rendimiento luego
de establecer el concepto de escalabilidad en la Base de Datos, por los
cambios aplicados en el Modelo de Entidad Relación para la las nuevas
funcionalidades implementadas en la App HealthMonitor Ug,
GRÁFICO N° 33 ESCALABILIDAD EN ESQUEMA BD
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
Análisis:
Con el rediseño estructural de la Base de Datos y el aumento del Tráfico
de Transacciones por el Crecimiento de usuarios, se optimizó la utilización
de recursos utilizados (CPU %) como podemos observar en la imagen
anterior.
2. Publicaciones registradas en nuestra Base de Datos obtenidas desde la
Red Social Twitter que estén relacionadas con el ámbito de la Salud,
enfocadas a las patologías analizadas en el Proyecto: Diabetes mellitus
Tipo 1, Tipo 2 , Gestacional y Asma.
64
En este caso la unidad de análisis es cuantificable, se recolectó información
de 300 publicaciones que estén dentro del ámbito de la salud y que los
usuarios no pertenezcan a instituciones clínicas. La fórmula para determinar
la Muestra con la que trabajaremos e identificar patrones, será la siguiente:
GRÁFICO N° 34 FÓRMULA PARA OBTENCÓN DE MUESTRA
Elaborado por: Johanna Pardo Jara Fuente: Datos de Investigación
CUADRO N° 7 DETALLE DE VARIABLES
Var Representación Valor
N PUBLICACIONES 300
Z DESVIACIÓN 1,645
E MARGEN DE ERROR 5%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
Datos de la Población analizada y tamaño de la muestra que obtuvimos bajo la
cual vamos a identificar patrones en nuestra base de Datos.
CUADRO N° 8 RESULTADO MUESTRA
MUESTRA CANTIDAD
N 116
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
65
Las siguientes son criterios que hemos analizado bajo el uso de Sentencias
SQL, la Información con la que trabajaremos es tomada de la base de datos de
la APP HEALTHMONITOR UG.
1) ¿Cuántas de las publicaciones analizadas corresponden a cada patología
que se monitoriza desde la aplicación?
CUADRO N° 9 ANÁLISIS DE PUBLICACIONES - PATOLOGIA
PATOLOGIA N° DE
PUBLICACIONES
PORCENTAJE
%
DIABETES 52 45%
ASMA 64 55%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
GRÁFICO N° 35 ANÁLISIS DE PUBLICACIONES – PATOLOGÍA
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
66
Análisis
Del 100% de las publicaciones analizadas, para la reestructuración del Modelo
de la Base de Datos, pudimos encontrar el Mayor porcentaje de interés
equivalente al 55% corresponde a la nueva patología de estudio (Asma)
mientras que el 45% pertenece a la Diabetes que se estudió y mejoró desde la
versión inicial de la App HealthMonitor Ug.
2) Identificar las publicaciones analizadas por patología según su contexto si
¿Son Informativas (Opiniones Generales), con Aportes Científicos o brindan
Recomendaciones Generales?
CUADRO N° 10 ANÁLISIS DE PUBLICACIONES – CONTEXTO
PATOLOGIA Contexto N° DE
PUBLICACIONES PORCENTAJE
%
DIABETES Informativo 22 19%
DIABETES Aporte Científico 20 17%
DIABETES Recomendaciones 10 9%
ASMA Informativo 25 22%
ASMA Aporte Científico 20 17%
ASMA Recomendaciones 14 12%
TOTAL 116 100%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
GRÁFICO N° 36 ANÁLISIS DE PUBLICACIONES – CONTEXTO
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
67
Análisis
En el Gráfico presentado, se puede evidenciar que la mayor parte de las
publicaciones consideradas como muestra son de contexto informativo, se
observa un 22% de Asma contra un 19% de Diabetes. En segundo lugar
tenemos las Publicaciones catalogadas como Aporte Científico manteniéndose
en un 17% las dos patologías estudiadas, para concluir se enuncian las
recomendaciones generales de las publicaciones un 12% de Asma contra un 9%
de Diabetes. Por ende se consideró viable rediseñar la Base de Datos para la
inclusión de una nueva patología por su alta frecuencia de interés en la
población.
3) De nuestra población analizada ¿Cuáles fueron las publicaciones más
aceptadas por el público en general?
CUADRO N° 11 ACEPTACIÓN DE PÚBLICO
PUBLICACIÓN USUARIO PATOLOGÍA
#
LIKES
De pequeña no podía dormirme con
mascotas porque tenía asma muy fuerte
ahora que tengo la cachorrita si puedo y se
siente muy bonito
GISY ASMA 12
Tengo asma y puedo dormir y estaba
respirando y me acorde del pingüino de toy
story y ahora me voy a morir de lo mucho
que me reí
MARI
GONZALEZ ASMA 14
Rafael Ramírez ala1 cuando llegaran
calmantes para el asma, soy asmático, he
recorrido varias farmacias y no se consigue
ninguno
RAMON
RAMOS EL
LIDER
ASMA 17
Simón Cowell tendría un succionador de
oxígeno en su casa que provocaría el asma
a Joel abre no paraba más chao
LU ASMA 17
3 noches consecutivas sin poder dormir
ahogada cada uno bronquitis aguda más
asma bronquial. Me parece que eso de estar
LAU ASMA 31
68
mejor es más un deseo que un hecho
Hemoglobina a1c refleja la glucemia
promedio durante aprox 3 meses y tiene un
fuerte valor predictivo las complicaciones de
la diabetes
DR ILIN
GILBERTO
DLT
DIABETES 60
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
GRÁFICO N° 37 ACEPTACIÓN DEL PUBLICO
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
Análisis
En el Gráfico analizamos las publicaciones de nuestra muestra, donde podemos
apreciar un alto grado de aceptación por parte del público ante la primera
patología analizada Diabetes.
69
CAPÍTULO IV
PROPUESTA TECNOLÓGICA
La propuesta tecnológica a efectuar en la Base de Datos creada para la App
HealthMonitor Ug, consiste en Alterar su Modelo de Entidad Relación aplicando
escalabilidad en su esquema lógico, con el fin de permitir el acoplamiento de una
nueva patología (asma) en los módulos para control regular del paciente,
también se propone adicionar un Modelo Ontológico que permitirá la interacción
del Sistema con aplicaciones (Facebook, Twitter, Google Fit) que son
compatibles con la tecnología Android.
ANÁLISIS DE FACTIBILIDAD
Al ampliar las funcionalidades de la App HealthMonitor Ug bajo el listado de
requerimientos solicitados por el cliente, implícitamente el componente que
almacena la información de nuestra aplicación debe ser adaptado a su nueva
lógica de negocio.
Se considera factible la propuesta tecnológica que se implementa en la
aplicación porque al rediseñar el Esquema Lógico de la Base de Datos se
promueve un modelo estructural escalable que permitirá el crecimiento paulatino
de la información y el correcto manejo de sus transacciones al aplicar las reglas
de negocio establecidas a través de la creación de procedimientos, manteniendo
su rendimiento efectivo durante las operaciones que se realizan con los datos
desde el aplicativo.
70
- FACTIBILIDAD OPERACIONAL
La factibilidad Operacional de la propuesta es viable, ante a la alta demanda que
presentan los usuarios por tener aplicaciones de su Smartphone que permitan
auto-gestionar sus parámetros clínicos básicos, sin perder las recomendaciones
de un profesional que monitoree su estado de salud.
El procesamiento de la información que realizó la versión inicial del proyecto, nos
facilitó identificar necesidades de los usuarios y poder realizar una
reestructuración a nivel de la Base de Datos que es parte fundamental y
funcional de la aplicación HealthMonitor UG, con la finalidad de obtener un
adecuado almacenamiento de la información que proviene de los usuarios
registrados en la aplicación,
El desarrollo propuesto tiene la facultad de cubrir las necesidades de los
pacientes con patologías como Asma y Diabetes, la cual cumple con las
indicaciones solicitadas por el cliente y que beneficiaran a muchos usuarios, a
continuación detallaremos los ambientes en la que realizamos referencia en este
proceso de cambio:
El cliente:
Mostró un gran alto grado de aceptación, ya que en nuestra nueva versión de
HealthMonitor Ug se ha logrado cubrir falencias y limitaciones de la versión
anterior, se analizaron en conjunto las solicitudes que se iban presentando
durante el desarrollo de la aplicación gracias a la Metodología Scrum utilizada
para el proyecto, gracias a esto se puedo corroborar que se obtuvo un gran
apoyo de la parte administrativa relacionado con la aplicación.
Almacenamiento y Procesamiento de la Información:
El Modelo Lógico implementado, tiene la capacidad de permitir la fluidez de las
transacciones con la información registrada durante el control de las patologías
(diabetes y asma) que padece cada paciente, al esquematizar las estructuras
(tablas) acorde a los requerimientos para las nuevas funcionalidades se puede
71
procesar nuevas operaciones lógicas y escalar consecuentemente. Esta
información podrá ser visualizada desde el portal web permitiendo que los
médicos especialistas vinculados al paciente realicen un constante monitoreo del
historial de sus parámetros clínicos, sin necesidad de que ellos asistan a algún
consultorio para que sea valorado su estado.
La innovación de utilizar las numerosas ventajas de las redes sociales más
utilizadas como Twitter y Facebook por los usuarios, hacen posible que los
pacientes nos muestren una gran cantidad de opiniones referente a las
patologías estudiadas Asma y Diabetes, esto ayuda a compartir o recomendar la
aplicación con otras personas que cumplan con este perfil de pacientes. El
acoplamiento de nuestra aplicación con la App Google Fit que monitoriza la
actividad física de los usuarios aporta en gran manera a fomentar a que nuestros
usuarios adquieran una nueva rutina en su estilo de vida y puedan llevar un
control de sus registros. La adición del Nuevo Modelo Ontológico planteado para
la interacción con las aplicaciones seleccionadas que son compatibles con la
App HealthMonitor Ug, demuestra que su desarrollo es factible al permitir el
correcto almacenamiento de la información de nuevos usuarios, facilitando la
recopilación de datos por diversos casos que se presentan en relación a las
patologías determinadas, los cuales son analizados por los médicos
especialistas, y sus resultados que servirán para enlistar nuevos requerimientos
en una futura actualización de la aplicación.
- FACTIBILIDAD TÉCNICA
Durante la evaluación de la factibilidad técnica se identificaron los escenarios
para la implementación de la propuesta, su equipo Hardware y plataforma
software para el desarrollo.
Recurso Humano:
- Un Estudiante de la Universidad de Guayaquil perteneciente Carrera de
Ingeniera en Sistemas Computacionales de la Facultad de Ciencias Físicas y
Matemáticas.
72
Recurso Hardware:
- Se describe el equipo utilizado como estación de Trabajo y sus
características técnicas que permiten el desarrollo de la Propuesta
tecnológica.
CUADRO N° 12 DESCRIPCIÓN DE ESTACIÓN DE TRABAJO
Recurso Hardware y Especificaciones
Equipo Laptop Dell Inspiron
Procesador Intel Core I5
Velocidad 2.5 GHz
Memoria RAM 4.00 GB
Sistema Operativo Microsoft Windows 8.1 Sistema Operativo de
64Bits Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
Recurso Software:
- Para el desarrollo de la propuesta se mantuvo el Sistema Gestor de Base de
Datos MySQL. Este componente es utilizado por varios portales Web, lo que
nos brinda confiabilidad en este proyecto.
CUADRO N° 13 DESCRIPCIÓN DE ESTACIÓN DE TRABAJO
Recurso Software para Desarrollo
Sistema Gestor de Base de Datos
MySQL
Versión MySQL Workbench 6.3 CE
Plataforma Windows 64Bits
Motor de Base de Datos Innodb
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
Para rediseño estructural de la Base de Datos, se utilizó la interfaz Workbench
6.3 que tiene el Sistema Gestor de Base de Datos MySql, en el cual se
implementó desarrollo todo el modelo Ontológico diseñado para cumplir las
73
expectativas del Cliente.
- FACTIBILIDAD LEGAL
En el análisis de la Factibilidad Legal se busca verificar si el planteamiento del
proyecto y desarrollo no quebranta las leyes a las que más se aproximan esta
investigación.
El Gestor de Base de Datos utilizado para el de desarrollo de la propuesta
tecnológica implementada en la aplicación es MySQL un Software Open Source
que cuenta con su Licencia Pública General (GPL), lo cual nos permite la
ejecución del proyecto sin incumplir disposiciones legales según lo estipulado en
las constitución.
- FACTIBILIDAD ECONÓMICA
Durante el análisis de realizado podemos concluir que el costo/beneficio de la
reestructuración de la Base de Datos y desarrollo para la aplicación móvil
HealthMonitor UG y su portal web es calificado factible, ya que solo se
considerará la Mano de Obra del Desarrollador y su estación de trabajo lo que
hace que sus beneficios sean convenientes económicamente y satisfactorios
ante las nuevas implementaciones en la App.
Para determinar el control de la reestructuración de la Base de datos de la
aplicación HealthMonitor UG analizaremos 4 características:
a) Flujo: Hace referencia a la propiedad que tiene la aplicación de registrar a un
usuario y al llenar su información envía estos datos al portal web.
b) Funcionalidad: Se refiere a una App móvil que se instala en un Smartphone
y una web atractiva, con navegación clara y útil para el usuario.
74
c) Retroalimentación: Es una de las características de la aplicación ya que por
este al estar conectado a las redes sociales podemos tener un mayor grado
de aceptación de los usuarios, mantener Google Fit con la finalidad de
brindar al usuario final una nueva visión de ritmo de vida mediante ejercicios
propuestos.
d) Fidelización: Establecer un diálogo personalizado con el usuario final,
tendrá un gran impacto en la aceptación de la aplicación ya que se
implementó un gran cambio a nivel de Base de Datos, diseño de la
aplicación, apariencia y la integración con las redes sociales.
Presupuesto Estimado:
El presupuesto estimado en la realización de esta propuesta tecnológica se
enuncia en la siguiente tabla, donde se detallará los costos de los recursos
considerados, a continuación el resumen:
CUADRO N° 14 PRESUPUESTO DESARROLLO
Proyecto
RUBROS Cantidad
N° VALOR TOTAL
HORAS POR HORA Subtotal
Recurso Humano 3600
Desarrollador 1 360 8 2880
Recurso Hardware 465
Estación de Trabajo 1 360 - 600
Internet 360 - 70
Logística 0
Alimentación 360 - 200
Transporte 360 - 200
Total 3950
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
75
ETAPAS DE LA METODOLOGÍA DEL PROYECTO
A través de la implementación de la Metodología Scrum utilizada para desarrollo
de Proyectos Ágiles, las etapas fueron registradas en el TaskBoard (Tablero de
Tareas) Trello para verificar los avances del proyecto a implementar.
Las etapas se dividieron en varias Iteraciones para el desarrollo del proyecto que
se describen en el siguiente cuadro:
CUADRO N° 15 ETAPAS DE LA METODOLOGÍA SPRINT TAREA REALIZADA. RESULTADOS
1
Análisis de status de versión
inicial del proyecto.
En esta Fase se Analizó la
estructura conceptual de la
Base de Datos implementada
en la primera versión de la
Aplicación HealthMonitor.
Validación de la funcionalidad
de Módulos existentes
Se hicieron pruebas, validando
los Casos de Uso planteados
para el Desarrollo de la Versión
inicial, con la finalidad de
conocer su funcionalidad.
2
Análisis de Backlog para
inclusión de nueva patología en
la BD
Las Estructuras deberán ser
modificadas para adaptarse a
las nuevas operaciones a
implementarse.
Se crearán nuevas estructuras
Se deben desarrollar Métodos
aplicando la lógica de negocio
que se decida implementar.
Se analizará el Registro FEP.
Planteamiento de modelo
ontológico para inclusión de
nueva patología: Asma.
Visualización de Planteamiento
en Anexo
76
3
Análisis de Backlog para
interacción de la App
HealthMonitor con otras
aplicaciones desarrolladas para
SO Android.
Crear nuevas estructuras
Desarrollar Métodos aplicando
la lógica de negocio que se
decida implementar.
Definir APP con las que se
interactuará:
o Facebook, Twitter, Google Fit.
Planteamiento de modelo
ontológico para interacción con
otras aplicaciones Android
Visualización de Planteamiento
en Anexo
4
Análisis para alteración de
Estructuras predefinidas en la
BD
Se actualiza Entidades:
Mensajes de
Recomendaciones
Ejercicios
Dietas
Enfermedades
Diseño lógico plasmado en
SGBD MySQL Workbench
Visualización de Planteamiento
en Anexo
Definición de reglas de negocio
para procesamiento:
Control asma – FEP
Rangos de FEP
Estados por FEP
Síntomas por cada estado
Desencadenantes por cada
estado
5
Desarrollo de Apis para registro FEP
Desarrollo de Apis para actualización FEP
Desarrollo de Api de consulta para estado según FEP
Inspección y adaptación
BD Desarrollo control Asma
APP
Se valida cada uno de los
procesos
6
Desarrollo de Api de consulta para selección de síntomas según
estado FEP
Desarrollo de Api de consulta para selección de desencadenantes
según estado FEP
Desarrollo de Api para registro de síntomas y/o desencadenantes
según estado FEP
Inspección y adaptación
BD Desarrollo control Asma
APP
Se valida cada uno de los
procesos
77
7
Registra Data en las Estructuras
Rangos FEP
Estado
Síntomas
Desencadenantes
Mensajes de
Recomendaciones
Ejercicios
Dietas
Enfermedades
Inspección y adaptación
en la aplicación de control Asma
APP – Servidor Desarrollo
Validación de todos los APIS
para control Asma
o Procesos invocados desde
Web Service.
o Visualizados en Plataforma
o Resultados Favorables.
8
Definición de reglas de negocio
para para procesamiento
Datamining:
Lógica Datamining será
visualizado desde el Portal
Web
Se analizarán Publicaciones de
Asma y Diabetes
Información será tomada desde
Red Social Twitter.
Análisis, se llevará a cabo
según su estado y Contenido
Se crean Entidades
Se desarrolla Apis de
Procesamiento
Desarrollo de Apis para registro de publicaciones
Desarrollo de Apis para actualización de publicaciones
Registra Data en las Estructuras
Publicaciones: Información
Obtenida desde Twitter
(colaboración de todo el Equipo
HealthMonitor).
Data analizada por Team PHP.
Inspección y adaptación
BD Desarrollo control
Datamining
Pruebas Data Ok
78
9
Definición de reglas de negocio
para para procesamiento:
monitoreo Google Fit
Se almacenará la información
de Calorías extraída desde
Google Fit
Se validará Rango de Fecha de
la Información.
Desarrollo de Apis para registrar de Información Google Fit
Inspección y adaptación BD Desarrollo control Google Fit
Definición de reglas de negocio
para log in con Facebook
Se almacenará Imagen para
como requisito durante su
registro.
Se debe almacenar en la Base
de Datos
Se alteró Entidad Persona
Se alteró Stored Procedure
para registro
Inspección y adaptación
BD Desarrollo control Facebook
Validación de log in Facebook –
almacenando en BD imagen de
usuario
10
Desarrollo Api de Consulta, para
control de Calorías por paciente
Información invocada desde
Portal WEB.
Desarrollo Api de Consulta, para
control de Calorías por
Monitoreo Global
Desarrollo de Api de consulta
para control alérgico por
paciente
Desarrollo de Api de consulta
para control alérgico monitoreo
global
Desarrollo de Api de consulta
para control respiratorio por
paciente
Desarrollo de Api de consulta
para control respiratorio
monitoreo global
Inspección y adaptación Pruebas realizadas en Portal
Web - Team PHP
79
11
Implementación y puesta en producción.
Retroalimentación y Ajustes
12 Motor de Recomendaciones – Adaptado a nueva lógica de negocio
Tips/Control de Paciente
12 Elaboración de documentación
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
RESUMEN GENERAL DEL DESARROLLO
En el Manual de Operaciones se detalla los procedimientos utilizados y
características técnicas de la propuesta. Sin embargo resumimos de Forma
General el Proceso según las nuevas funcionalidades a implementar.
Análisis de Nueva Patología en la App HealthMonitor Ug
Para incluir en la aplicación el control de una nueva patología, es importante que
el Diseño lógico de la Base de Datos permita almacenar registros relacionadas a
la nueva información.
GRÁFICO N° 38 INCLUSION PATOLOGIA
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
El nuevo modelo ontológico planteado debe permitir que la aplicación pueda
almacenar y analizar los registros de los parámetros respiratorios de los
pacientes que padecen Asma, patología que será añadida en el control clínico
de la App HealthMonitor Ug.
80
Interacción de HealthMonitor Ug con otras aplicaciones Android.
En la actualidad un gran porcentaje de personas poseen un Smartphone y
utilizan varias Apps que están enlazadas entre sí ya sea por recomendaciones
en las redes sociales u otro medio, permitiendo observar la funcionalidad y la
ayuda que brindan las aplicaciones en la vida de los usuarios.
Implementaremos nuevas funcionalidades en la aplicación a nivel esquemático
de Base de Datos, lo cual nos permitirá adquirir información de una población
diversa que cuenta con distinta demografía, de la cual se puede determinar
tendencias e indicadores que permita establecer las necesidades según el perfil
de los usuarios, retroalimentándose para una futura actualización de los
componentes existentes en la App HealthMonitor Ug.
GRÁFICO N° 39 ANDROID APPS
Elaborado por: Datos de Investigación Fuente: Https://Www.puntogeek.com/
La información que se utilizará se obtendrá de los nuevos módulos que se
implementarán en la aplicación HealthMonitor Ug, se almacenarán en unidades
de negocio que serán adicionadas al Modelo de Datos, lo que permite cumplir
con los requerimientos solicitados, a continuación mencionaremos en que temas
aportará la solución presentada.
81
Datamining: La versión web de la Aplicación utilizará el procesamiento de la
Minería de Datos de las publicaciones de una cantidad determinada de
usuarios que usan la Red social Twitter,
Control de Actividad Física: la Aplicación obtendrá información de la
actividad física de los usuarios que tengan instalada en su Smartphone la
App Google Fit (registro de la cuenta).
Log in: La aplicación permitirá que los usuarios puedan iniciar con su cuenta
de Red Social Facebook, obteniendo datos puntuales que se almacenarán
en la Base de Datos.
ENTREGABLES DEL PROYECTO
En la sección de Anexos podremos encontrar las especificaciones del Desarrollo
de cada una de las actividades mencionadas en las Etapas del Proyecto y que
fueron determinadas en el Alcance.
Manual De Operaciones.
Diseño Lógico De La Base De Datos.
Apis De Procesamiento.
Base De Datos (Archivo Exportado .SQL).
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Para esta propuesta tecnológica implementada en la App HealthMonitor, se
definieron criterios que fueron validados durante las pruebas realizadas en la
plataforma, lo cual permitió comprobar la funcionalidad óptima en cada uno de
los criterios planteados.
82
Bajo estos criterios se llevaron a cabo las pruebas de la implementación para los
Smartphone con sistema operativo Android, por los cambios realizados en la
base de Datos de la App HealthMonitor Ug,
Bajo los siguientes criterios que mencionaremos se llevaron a cabo las pruebas
para el portal Web, de nuestra App Salud, el cual es monitorizado por los
médicos especialistas.
CUADRO N° 16 CRITERIOS DE VALIDACION - MOVIL
CRITERIOS DE VALIDACIÓN DE
PRODUCTO
MÓDULO: APP HEALTHMONITOR UG
N° FUNCIONALIDAD
RAZÓN CRITERIOS CONTEXTO PONDERACIÓN
1 Registro FEP
Control asma
Accesibilidad
Servicio activo de App
100%
Fácil acceso a nuevos
módulos 100%
Disponibilidad Respuesta de
BD 100%
Integridad Aplicación de
reglas de negocio
100%
2 Actualización
FEP
Accesibilidad
Servicio activo de App
100%
Fácil acceso a nuevos
módulos 100%
Disponibilidad Respuesta de
BD 100%
Integridad Aplicación de
reglas de negocio
100%
3 Evaluación de factores FEP
Accesibilidad
Servicio activo de App
100%
Fácil acceso a nuevos
módulos 100%
Disponibilidad Respuesta de
BD 100%
Integridad Aplicación de
reglas de 100%
83
negocio
4 Registro
Google Fit
Control Google
Fit
Accesibilidad
Servicio activo de App
100%
Fácil acceso a nuevos
módulos 100%
Disponibilidad Respuesta de
BD 100%
Integridad Aplicación de
reglas de negocio
100%
5 Visualización
De Estadísticas
Accesibilidad
Servicio activo de App
100%
Fácil acceso a nuevos
módulos 100%
Disponibilidad Respuesta de
BD 100%
Integridad Aplicación de
reglas de negocio
100%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
Bajo los siguientes criterios que mencionaremos se llevaron a cabo las pruebas
para el portal Web, de nuestra App Salud, el cual es monitorizado por los
médicos especialistas.
CUADRO N° 17 CRITERIOS DE VALIDACION PORTAL WEB
CRITERIOS DE VALIDACIÓN
DE PRODUCTO
MÓDULO:
PORTAL WEB HEALTHMONITOR
N° FUNCIONALIDAD
RAZON CRITERIOS
CONTEXT
O PONDERACIÓN
1 Registro de
publicaciones
Datamining Accesibilidad
Servicio
activo 100%
Fácil
acceso a
nuevos
módulos
100%
84
Disponibilidad Respuesta
de BD 100%
Integridad
Aplicación
de reglas
de negocio
100%
2
Actualización
de
publicación
Accesibilidad
Servicio
activo 100%
Fácil
acceso a
nuevos
módulos
Disponibilidad Respuesta
de BD 100%
Integridad
Aplicación
de reglas
de negocio
100%
3 Publicaciones
Análisis -
publicación
datos
estadísticos
Accesibilidad
Servicio
activo 100%
Fácil
acceso a
nuevos
módulos
100%
Disponibilidad Respuesta
de BD 100%
Integridad
Aplicación
de reglas
de negocio
100%
4 FEP
Análisis -
valores FEP
resultados
estadísticos
Accesibilidad
Servicio
activo 100%
Fácil
acceso a
nuevos
módulos
100%
Disponibilidad Respuesta
de BD 100%
Integridad
Aplicación
de reglas
de negocio
100%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
85
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO Y/O
SERVICIO
La aplicación HealthMonitor UG, está orientada hacia un grupo determinados de
usuarios con la finalidad de ayudar de manera simple, sencilla y que promueva
través de las redes sociales un gran acogimiento de más usuarios que tengan
las patologías anteriormente enunciadas como el asma y la diabetes.
CUADRO N° 18 CRITERIO DE ACEPTACIÓN NIVEL LÓGICO
CRITERIOS CRITERIOS DE ACEPTACIÓN
N° FUNCIÓN RAZÓN CRITERIO RESULTADO
1 Rediseño de MER
Inclusión de nueva patología e integración con
aplicaciones para SO Android
Escalabilidad 100%
Optimización de datos 100%
Crecimiento de la base de datos
100%
Diseño delimitado 100%
3 Aplicación de reglas de negocio
Concordancia con lógica de negocio
100%
Indicadores portal web 100%
Indicadores portal Android 100%
Logs de auditoria 100%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
CUADRO N° 19 CRITERIO ACEPTACIÓN NIVEL TÈCNICO
CRITERIOS CRITERIOS DE ACEPTACIÓN
N° FUNCIÓN RAZÓN CRITERIO RESULTADO
1
GESTOR DE BASE DE DATOS MYSQL
Inclusión de Nueva Patología e Integración con Aplicaciones para
SO Android
Tolerancia de Datos 100%
Facilidad en Configuración
100%
Adaptabilidad 100%
Costos 100%
Elaborado por: Johanna Pardo Jara Fuente: Team Base de Datos Proyecto HealthMonitor UG
86
SOCIAL
CUADRO N° 20 CRITERIO ACEPTACIÓN NIVEL SOCIAL
CRITERIOS CRITERIOS DE ACEPTACIÓN
N° FUNCIÓN RAZÓN CRITERIO RESULTADO
1 Registro Digital de
Salud
Inclusión de Nueva Patología
e Integración con
Aplicaciones para SO Android
Nueva Patología 100%
Control FEP 100%
Facilidad De Uso 100%
Recomendaciones 100%
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
87
CONCLUSIONES
Tras el desarrollo e implementación del Rediseño de la Base de Datos debido a
la renovación de la App HealthMonitor UG y de análisis de los criterios de
aceptación a nivel Técnico, podemos determinar las siguientes conclusiones
obtenidas del proyecto:
Mediante los cambios efectuados en el Modelo de Entidad Relación, tanto en
sus estructuras (campos, índices) y relación entre las mismas se logró
plasmar un Diseño lógico escalable que permite llevar el control sobre los
registros de una nueva patología (Asma), donde se analiza el FEP (Flujo
espiratorio pico) que se registra desde la App HealthMonitor Ug.
Se validaron las transacciones que permiten llevar el control de la nueva
Patología desde las plataformas del proyecto (móvil/web); mediante la
creación de APIs de Procesamiento (Store Procedure) donde se
inspeccionan los datos receptados aplicando las reglas de negocio para
mantener información de calidad almacenada en la Base de Datos.
Mediante la creación de entidades y procedimientos que permiten el ingreso
de nuevos registros sobre la Base de Datos y así obtener información de
otras aplicaciones desarrolladas en plataforma Android con las que
interactúa la App HealthMonitor Ug, esto incluye el almacenamiento de
Publicaciones de Red Social Twitter que serán utilizadas para obtener
tendencias (Minería de Datos), y datos conglomerados de las calorías de
nuestro paciente de los registros se descargan desde la App Google Fit.
Para llevar un control de los eventos que se presenten al ejecutar los Apis de
procesamiento en las transacciones efectuadas para la Nueva Patología, se
envía a registrar en estructuras tipo Logs para detectar con facilidad las
novedades que se puedan presentar por errores.
88
Reducción de Costos al utilizar herramientas Open Source como el Gestor
de Base de Datos MySQL Workbench, Xampp.
RECOMENDACIONES
Un sistema siempre está presto a renovarse para lo cual ponemos en
consideraciones, las siguientes Recomendaciones que ayudarán a buscar un
futuro perfeccionamiento de la Aplicación HealthMonitor UG y sus componentes.
Fortalecer la investigación de la patología Asma para consolidar la lógica de
negocio y adaptarse a futuros cambios en las ramas que esto implica
Salud/Tecnología, para poder renovar Data con la finalidad de obtener un
alto nivel en su Motor de Recomendaciones actualizándolo bajo nuevas
opciones clínicas que surjan para las patologías afrontadas desde la
aplicación.
Se sugiere el desarrollo de un módulo Administrador desde donde se
alimenten las estructuras predefinidas para las patologías que se controlan
en la Aplicación (Asma/Diabetes), y permita mantener la actualización
constante de información en la Base de Datos.
Es importante que cada cierto tiempo se controle el crecimiento de la
información registrada en las estructuras planteadas de la Base de Datos
para la Aplicación y así permita depurar registros desactualizados.
Al registrar los eventos por errores, es necesario que se almacene un detalle
más preciso (tipo de incidente) en la Base de Datos de la Aplicación
HealthMonitor UG.
Mantener el uso de herramientas OpenSource para no incrementar costos en
el desarrollo del proyecto en una nueva versión.
89
BIBLIOGRAFÍA
K.Schwaber-J.Sutherland. (2016). The Definitive Guide to Scrum:. In K. S.
Sutherland, The Definitive Guide to Scrum:. Scrum.Org and ScrumInc.
Neothek, Sitios web, Web hosting. (2016, Junio 22). Retrieved from 10 Razones
porque elegir MySQL: https://blog.neothek.com/blog-neothek/10-razones-
porque-elegir-mysql/
Aboutespanol-Luis Castro. (n.d.). Retrieved from
https://www.aboutespanol.com/que-es-escalabilidad-157635
Blázquez, M. O. (2014, Febrero 11). Fundamentos y Diseño de Bases de Datos.
Retrieved from http://ccdoc-
basesdedatos.blogspot.com/2014/02/concepto-definicion-y-aspectos-
basicos.html
Blog Tarrillobd. (n.d.). (E. D. TORRES, Producer) Retrieved from
http://tarrillobd.blogspot.com/
Castro, L. (2016, Agosto 9). About Español. Retrieved from ¿Qué es
escalabilidad?: https://www.aboutespanol.com/que-es-escalabilidad-
157635
chuidiang.org. (n.d.). http://www.chuidiang.org/ood/metodologia/scrum.php.
COBO ÁNGEL y GÓMEZ PATRICIA. (2005). PHP y MySQL- tecnologias para el
desarrollo de aplicaciones web.
Colin D Mathers, D. L. (2006, JULIO). Projections of Global Mortality and Burden
of Disease from 2002 to 2030. Retrieved from OMS:
http://www.who.int/mediacentre/factsheets/fs312/es/
Costa, D. C. (2005, Mayo). Software Libre. Retrieved from Introducción al diseño
de la base de datos: http://www.uoc.edu/masters/oficiales/img/913.pdf
Date, C. J. (2001). Introducción a los Sistemas de Base de Datos. Retrieved from
https://unefazuliasistemas.files.wordpress.com/2011/04/introducion-a-los-
sistemas-de-bases-de-datos-cj-date.pdf
Date, C. J. (n.d.). Introducción a los sistemas de bases de datos.
Frassia, A. M. (n.d.). Introducción a las Bases de Datos. Retrieved from cursogis:
http://www.cursogis.com.ar/BasesP/Zip/Base_Clase1.pdf
90
Fundación Argentina del Tórax. (2016). ©fundaciontorax.org.ar. Retrieved from
http://www.fundaciontorax.org.ar/page/index.php/examenes-
complementarios/178-flujo-espiratorio-pico
García, J. F. (2010, Febrero 22). Innovación En Modelos De Negocio. Retrieved
from La Metodología De Osterwalder En La Práctica, Revista Mba Eafit:
http://www.eafit.edu.co/revistas/revistamba/documents/innovacion-
modelo-negocio.pdf
García, J. L. (2015). Administración y monitorización de los SGBD. IFCT0310.
Howard Gardner, Katie Davis. (2014). La generación APP: Cómo los jóvenes
gestionan su identidad, su privacidad y su imaginación en el mundo
digital. Biblioteca Howard Gardner.
Howard Gardner, Katie Davis. (2014). La generación APP: Cómo los jóvenes
gestionan su identidad, su privacidad y su imaginación en el mundo
digital. Biblioteca Howard Gardner. Retrieved from
http://es.calameo.com/read/00069604247693bdfa3ff
Informe 50 mejores Apps. (n.d.). prisadigital. Retrieved from
http://boletines.prisadigital.com/Informe-TAD-50-Mejores-Apps-de-
Salud.pdf
Javier Cuello – José Vittone. (2013). Retrieved from
http://appdesignbook.com/es/contenidos/las-aplicaciones/
Lapuente, M. J. (2013, Agosto 12). Ontologias. Retrieved from
http://www.hipertexto.info/documentos/ontologias.htm
Lockheimer, H. (n.d.). Retrieved from
https://www.android.com/intl/es_es/everyone/
Marqués, M. (2009, Enero ). Bases de Datos. Retrieved from
http://www3.uji.es/~mmarques/apuntes_bbdd/apuntes.pdf
Megias, J. (n.d.). Estrategia, Startups y Modelos de Negocio. Retrieved from
https://javiermegias.com/
Microsoft MSDN. (n.d.). Retrieved from https://msdn.microsoft.com/
Miguel Ángel Arias. (2017). Aprende Programación Web con PHP y MySQL: 2ª
Edición.
Montero, A. M. (n.d.). Apuntes de Estadística II. Retrieved from
http://www.ugr.es/~eues/webgrupo/Docencia/MonteroAlonso/estadisticaII/
tema4.pdf
91
MYSQL. (n.d.). Retrieved from https://www.mysql.com/products/workbench/
Ochando, M. B. (2014, Febrero 11). Fundamentos y Diseño de Bases de Datos.
Retrieved from http://ccdoc-
basesdedatos.blogspot.com/2014/02/concepto-definicion-y-aspectos-
basicos.html
Osterwalder. (2004). The Business Model Ontology: a Proposition in a Design
Science Approach.
Paré, R. C. (2005, Mayo). Software libre. Retrieved from
http://www.uoc.edu/masters/oficiales/img/913.pdf
proyectosagiles.org. (n.d.). proyectosagiles.org. Retrieved from
https://proyectosagiles.org/que-es-scrum/
Rafael Camps Paré, L. A. (2005, Mayo). Software Libre. Retrieved from
Introducción al diseño de la base de datos:
http://www.uoc.edu/masters/oficiales/img/913.pdf
Ramos Lopez, Javier, Soguero Ruiz, Cristina, Mora Jimenez, Inmaculada, Rojo
Alvarez, Jose Luis, Cabo Salvador, Javier. (2014). mHealth y su impacto
en la calidad asistencial.
Ramos, A., & Ramos, M. J. (2007). Operaciones con bases de datos ofimáticas y
corporativas. Editorial Paraninfo. Retrieved from Operaciones con bases
de datos ofimáticas y corporativas
Revista ARQHYS. (2017). Retrieved from La escalabilidad. Equipo de
colaboradores y profesionales de la revista ARQHYS:
http://www.arqhys.com/construcciones/escalabilidad.html
Santillán, L. A. (2005, Mayo). Retrieved from Software Libre:
http://www.uoc.edu/masters/oficiales/img/913.pdf
Santillán, L. A. (2005, Mayo). Software Libre. Retrieved from
http://www.uoc.edu/masters/oficiales/img/913.pdf
Silberschatz, A. (2002). FUNDAMENTOS DE BASES DE DATOS. Retrieved
from
https://unefazuliasistemas.files.wordpress.com/2011/04/fundamentos-de-
bases-de-datos-silberschatz-korth-sudarshan.pdf
Silberschatz, A. H. (2006). Fundamentos de bases de datos. McGraw-Hill.
Retrieved from https://books.google.com.ec/books?id=ntE0PwAACAAJ
92
Sinnexus. (2016). Retrieved from
http://www.sinnexus.com/business_intelligence/datamining.aspx
URIBE, C. G. (2008). Desarrollo e implementación informática de un sistema de
ascenso de nivel para los profesores de la ESPOL. Guayaquil. Retrieved
from
https://www.dspace.espol.edu.ec/bitstream/123456789/19249/2/TESIS%2
0COMPLETA%20CHRISTIAN%20URIBE%20FRANCO.pdf
Vital Wave Consulting. (2009). Retrieved from MHealth for Development: The
Opportunity of Mobile Technology for Healthcare in the Developing World:
http://www. globalproblems-globalsolutions-files.org/
unf_website/assets/publications/technology/mhealth/mHealth_for_Develo
pment_ full.pdf
Wigodski, J. (2010). Retrieved from blogspot.com:
http://metodologiaeninvestigacion.blogspot.com/2010/07/poblacion-y-
muestra.html
93
ANEXOS
94
ANEXO 1.- CRONOGRAMA
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
ANEXO 2.- MODELO DE ENTIDAD RELACION VERSIÓN INICIAL
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
ANEXO 3.- MODELO DE ENTIDAD RELACIÓN PROPUESTA TECNOLÓGICA
Elaborado por: Johanna Pardo Jara
Fuente: Team Base de Datos Proyecto HealthMonitor UG
ANEXO 4.- MANUAL DE OPERACIONES
ANEXO 4.- STORE PROCEDURE
PROCESAMIENTO ASMA
REGISTRO DE PEAK FLOW
MOTIVOS ASMA – (SINTOMAS O DESENCADENANTES)
CONTROL DESENCADENANTES ASMA – PORTAL WEB
CONTROL ESTADOS ASMA – PORTAL WEB
PROCESAMIENTO CALORIAS GOOGLE FIT
ESTRUCTURA INFO_GOOGLE_FIT – REGISTRO DE INFORMACIÓN
ESTRUCTURA INFO_GOOGLE_FIT – CONSULTA CALORIAS
PORTAL WEB
CONSULTAS POR PACIENTE
ESTADISTICAS GLOBALES DE TODOS LOS PACIENTES
PROCESAMIENTO PUBLICACIONES TWITTER
ESTRUCTURA PUBLICACIONES – REGISTRO DE INFORMACIÓN
ESTRUCTURA PUBLICACIONES – MODIFICACIÓN DE REGISTROS
ESTRUCTURA PUBLICACIONES – CONSULTA PARA PORTAL WEB
MANUAL DE OPERACIONES DE BASE DE DATOS IMPLEMENTADA EN LA APP
HEALTH MONITOR UG
INDICE
OBJETIVO .......................................................................................................... 2
DESARROLLO DE PROPUESTA ....................................................................... 2
MODELO ONTOLOGICO PARA CONTROLAR ENFERMEDAD
RESPIRATORIA: ASMA ..................................................................................... 4
UNIDADES DE NEGOCIO ........................................................................... 5
CONFIGURACIÓN DE OTRAS ENTIDADES .............................................. 5
ENTIDAD: ASMA_SINTOMAS (SINTOMAS POR ESTADO) .................... 8
ENTIDAD: ASMA_DESENCADENANTE ..................................................... 9
VISUALIZACION APP HEALTHMONITOR DESDE SMARTPHONE ........ 12
INTERACCIÓN DE HEALTHMONITOR UG CON OTRAS APLICACIONES
ANDROID .......................................................................................................... 16
MODELO ONTOLÓGICO PARA USO DATAMINING....................................... 17
UNIDADES DE NEGOCIO ......................................................................... 18
APIS DE PROCESAMIENTO PUBLICACIONES TWITTER ...................... 18
ANÁLISIS TENDENCIAS ........................................................................... 20
ÁRBOL DE DECISIONES DATAMINING .................................................. 21
ANÁLISIS DE SENTIMIENTOS ................................................................. 21
MONITOREO ACTIVIDAD FÍSICA CON GOOGLE FIT .................................... 22
UNIDAD DE NEGOCIO .............................................................................. 22
DISEÑO LOGICO PARA MÓDULO EJERCICIOS ..................................... 23
APIS DE PROCESAMIENTO ..................................................................... 23
VISUALIZACIÓN APP HEALTHMONITOR. ............................................... 23
VISUALIZACIÓN PLATAFORMA WEB – CONTROL DE CALORÍAS. ..... 24
MOTOR DE RECOMENDACIONES: ................................................................ 25
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
2
OBJETIVO
Describir los Procesos utilizados para el Rediseño de la Base de Datos de la
aplicación HealthMonitor, brindando un conocimiento técnico de la propuesta
realizada.
DESARROLLO DE PROPUESTA
El modelo propuesto, se preside a los requerimientos y especificaciones
inicialmente indicados por el cliente, ante los casos de uso propuestos para la
nueva versión de la Aplicación HealthMonitor.
El Diseño del MER ha sido elaborado en el SGBD MySQL, su reestructuración
lógica permitirá la inclusión de un nuevo módulo donde se registrará la Data
(información) de los pacientes que padecen Asma, recordemos que la App
HealthMonitor en un inicio fue creada únicamente para usuarios que padezcan
Diabetes.
Las nuevas configuraciones implementadas y el Modelo Ontológico plasmado en
el MER, dará libertad a la aplicación para el crecimiento de su funcionalidad,
integración de nuevos usuarios, y aporte a las futuras investigaciones ya que a
través del portal Web, los especialistas analizarán esta información y permitirá
realizar el estudios de nuevas patología. Ampliar la capacidad de admitir nueva
información en la Base de Datos promoverá la Escalabilidad y el crecimiento de
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
3
la aplicación HealthMonitor. Al efectuar cambios en la lógica de negocio que se
identificó en la versión inicial, donde se contaba con un MER limitado a ciertas
funcionalidades.
Describiremos las soluciones efectuadas sobre las variables seleccionas para el
desarrollo de este trabajo.
A continuación se presenta el Diagrama Entidad Relación del modelo propuesto
para la Base de Datos de la nueva versión.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
4
MODELO ONTOLOGICO PARA CONTROLAR
ENFERMEDAD RESPIRATORIA: ASMA
Adicionaremos un nuevo Modelo Ontológico con su análisis correspondiente
para el adecuado Control del Flujo Respiratorio de todos los pacientes
regstrados en la Aplicación HealthMonitor Ug que padecen la enfermedad del
Asma.
Dentro de la interfaz de aplicación HealthMonitor Ug se implmentó una nueva
pestaña donde el usuario podrá acceder al Control clínico de su patologia
asmatica y realizar las operaciones lógicas de control de su información o
cuando realiza un nuevo registro.
Peak Flow: El flujo espiratorio pico (FEP) es la cantidad máxima de aire por
segundo (flujo) que puede ser expulsada de los pulmones en forma forzada
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
5
(soplando) durante la primera parte de la espiración. Es una medida que ayuda a
verificar el grado de control del asma (Fundación Argentina del Tórax, 2016)
UNIDADES DE NEGOCIO
Detallaremos la funcionalidad de las Estructuras para control de Parámetros
Respiratorios.
DETALLE_PEAK_FLOW
Lleva el registro de los Valores de los FEP
que registran periódicamente en Modulo
Control Asma de la App.
ASMA_ESTADO
Su estado es definido por los rangos de
Valores:
/ Bien / Mal / Crítico
PEAK_FLOW_ASMA Estructura que enlaza los FEP Registrados y
los síntomas y desencadenantes
ASMA_SINTOMAS Sintomatología del Paciente, según su
Estado definido
ASMA_DESENCADENANTES Consecuencias de la Sintomatología
CONFIGURACIÓN DE OTRAS ENTIDADES
Se configuró la estructura de la Base de Datos utilizada para gestionar el Motor
de Recomendaciones presentados a los Pacientes con Diabetes, estas
entidades fueron previamente definidas.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
6
En la App se presenta la información de los Módulos dividida según la patología
a la que hace referencia, esto tiene el propósito de darle la oportunidad al
usuario de visualizar la información según su necesidad.
MÓDULO EJERCICIOS
Los ejercicios están definidos en
base a las características de las
patología de la cual se lleve un
control, ya que el exceso de
actividad física puede presentar
crisis emocional afectando a los
diabéticos o asmáticos
MÓDULO MEDICAMENTOS
La tabla de Medicamentos fue
configurada y divido en tres
grupos, identificados por un ID
designado, la clasificación se
realizó para optimizar el tiempo de
búsqueda al seleccionar sus
medicinas.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
7
MÓDULO RECOMENDACIONES .
En esta sección se presentan
recomendaciones que provienen
desde el portal web que trabaja
junto con la aplicación, y los tips
previamente registrados.
Se alteró la estructura para
identificar la patología a la que
hacen referencia los módulos de la
aplicación.
MÓDULO ENFERMEDADES
Se alimentó la estructura
RECOM_PATOLOGIA con más
cantidad de Data, ésta tabla
permitirá tener un sistema de
recomendación según las
enfermedades que el paciente
padezca adicional a su patología
base (Diabetes y Asma).
DESARROLLO DE APIS
Se crearon los APIs para procesamiento de la nueva lógica de Negocio, esta
implementación permite realizar las operaciones en la que incluimos una nueva
patología, en esta instancia aplicamos las Reglas de Negocio para cumplimiento
de los requerimientos solicitamos por el Cliente.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
8
ENTIDAD: ASMA_ESTADO (RANGOS DE PEAK FLOW)
Durante el registro de los valores FEP medidos en I/min, se analiza el nivel en
que se encuentra su valor registrado, esto determinará su estado y a través de la
App, se presentarán semáforos para identificar un posible estado de alto riesgo.
De este modo se incia el proceso para armar un requerimiento completo del
previo al registro del peak Flow en la BD.
ENTIDAD: ASMA_SINTOMAS (SINTOMAS POR ESTADO)
Selección de Sintomas, según estado obtenido por valor FEP, la tabla está
configurada con varios registros asociados a cada estado, la aplicación permitirá
seleccionar uno o varios síntomas a la vez.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
9
1: BIEN 2: MAL 3: CRÍTICO
ENTIDAD: ASMA_DESENCADENANTE
(CAUSAS DE CRISIS ASMATICAS SEGÚN ESTADO)
Selección de desencadenantes según estado obtenido por valor FEP, la tabla
está configurada con varios registros asociados al estado #1 los demas registros
no asociados se presentarán por los demás estados existentes.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
10
La aplicación permitirá seleccionar uno o varios desencadenantes a la vez.
API PARA REGISTRO DE PEAK FLOW
Registro de Peak Flow
La informacion se registrará en la entidad Detalle_Peak_Flow
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
11
Se evalúa que el email a través del Stored Procedure
esté registrado en nuestra base de datos
para proceder.
Se valida que el valor FEP enviado al Stored Procedure, este dentro de
los rangos establecidos en la tabla asma_estado.
Se valida las fechas de registro, desde su formato y evitando que no se
repita una nueva inserción en la tabla.
Devolvemos Id registrado en la BD para que se almacene la información
en la BD local Móvil.
Si durante el proceso se generan inconvenientes, se crean Logs que
almacenarán el historial de los errores presentados.
Registro Motivos Control Asmático
Se registran Síntomas y Desencadenantes en la tabla Peak_Flow_Asma,
se identifica por el Tipo ‘S’ ó ‘D’.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
12
Se valida que los códigos existan, en las entidades correspondientes
Estados/Síntomas/Desencadenantes
Se valida el identificador del peak flow registrado.
Se registra el Estado del paciente
Toda esta información podrá ser visualizada desde el portal android por los
pacientes y portal web a través de gráficos estadísticos.
VISUALIZACION APP HEALTHMONITOR DESDE SMARTPHONE
A continuación se describe la funcionilidad desde la app HEALTHMONITOR UG,
donde podremos visualizar el proceso completo durante Registro FEP.
AÑADIR REGISTRO
Rangos FEP
Definición de Estado del Paciente
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
13
SELECCIÓN SÍNTOMAS
SELECCIÓN DE DESENCADENANTES
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
14
APIS DE CONSULTA PARA VISUALIZACION DESDE PORTAL WEB
CONTROL DE DESENCADENANTES
Se presenta control de desencadenantes a través del registro de los valores de
FEP a través del proceso
CONTROL FEP
Se presenta control de niveles FEP registrados desde la App HealthMonitor, la
información es presentada a través del Stored Procedure
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
15
MONITOREO GLOBAL
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
16
INTERACCIÓN DE HEALTHMONITOR UG CON OTRAS
APLICACIONES ANDROID
La App HealthMonitor implementó la sincronización de su funcionalidad con
Redes Sociales, el propósito de esta integración en la aplicación es obtener una
interacción directo con los usuarios (pacientes y doctores), sus beneficios son
múltiples ya que actualmente el uso de esta tecnología es una pauta importante
para promover cualquier emprendimiento.
En el campo de la salud se comparten a menudo artículos de investigación
científica que abarcan temas relevantes que aportan para ampliar nuestro
conocimiento y permiten desarrollar nuevas propuestas de Salud Móvil.
En la Base de Datos se realizaron cambios importantes lo que permitirá dar un
paso inicial para el almacenamiento de Data que proviene de Apps desarrolladas
en Android, las cuales mencionaremos a continuación y su aplicación en el
Modelo ontológico y Procesamiento de Información,
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
17
APPS FUNCIONALIDAD PLATAFORMA
FACEBOOK REGISTRO / LOG IN ANDROID
TWITTER DATAMINING
ANALISIS DE SENTIMIENTOS
PHP
GOOGLE FIT CONTROL DE CALORÍAS ANDROID
MODELO ONTOLÓGICO PARA USO DATAMINING
Datamining (minería de datos), es el conjunto de técnicas y tecnologías que
permiten explorar grandes bases de datos, de manera automática o
semiautomática, con el objetivo de encontrar patrones repetitivos, tendencias o
reglas que expliquen el comportamiento de los datos en un determinado
contexto (Sinnexus, 2016)
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
18
La versión web de la Aplicación procesará Minería de Datos de las publicaciones
de usuarios de la red social Twitter que cuenten con información acerca de las
patologías enfoque de nuestro proyecto.
UNIDADES DE NEGOCIO
ABREVIATURAS
Estructura contiene un banco de abreviaturas que
permite interpretar las palabras que componen las
publicaciones de usuarios Twitter.
USUARIO_TWITTER Almacena los usuarios que crean publicaciones en
Twitter, con características previamente definidas
PUBLICACIONES
Se registran publicaciones con características
previamente definidas enfocadas a la patología
analizada
ESTADO_ANIMO Almacena estados de ánimo que permiten analizar
sentimientos según sus publicaciones.
Al introducir en nuestro diagrama lógico las Estructuras descritas anteriormente,
se permite almacenar data que se obtendrá a través del análisis con
herramientas Datamining.
APIS DE PROCESAMIENTO PUBLICACIONES TWITTER
Se crearon Stored procedures para realizar las operaciones DML con la
informacion de las publicaciones de la red social Twitter, data extraída desde la
herramienta datamining.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
19
FUNCION PARÁMETROS
Registro de
Publicaciones
Se emplea el
Stored Procedure
para registrar las
publicaciones
ACTUALIZACIO
N DE
REGISTROS
La informacion se registrará en la entidad “Publiaciones”.
Estructura PUBLICACIONES
La estructura Publicaciones
receptará información desde
proceso Datamining, está
configurada para captar toda la
información que compone los
Tweets.
Algunos de sus campos están
establecidos para receptar datos
con un extenso tamaño.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
20
A continuación se presenta la recolección de varios análisis aplicando
Datamining, Este proceso es realizado desde el portal web de la App
HEALTHMMONITOR UG.
ANÁLISIS TENDENCIAS
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
21
ÁRBOL DE DECISIONES DATAMINING
ANÁLISIS DE SENTIMIENTOS
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
22
MONITOREO ACTIVIDAD FÍSICA CON GOOGLE FIT
Actualmente la aplicación ya permite el control de atividad física desde el módulo
“Ejercicios y Dietas”, para ampliar esta plataforma se integró la funcioin para
obtener de manera automatica informacion desde la App Google Fit el cual
estará sincronizado con el email regsitrado en nuestra plataforma.
UNIDAD DE NEGOCIO
La Entidad INFO_GOOGLE_FIT está adaptada recibir las Actividades que se
monitoricen a través de la App Google Fit, el registro que se realiza
periodicamente captura del número de caloría que el usuario eliminó gracias a
sus actividades físicas diarias.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
23
DISEÑO LOGICO PARA MÓDULO EJERCICIOS
APIS DE PROCESAMIENTO
Los datos son enviados periódicamente los cuales son validados y registrados
en la Base de Datos a través del Stored Procedure
VISUALIZACIÓN APP HEALTHMONITOR.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
24
VISUALIZACIÓN PLATAFORMA WEB – CONTROL DE CALORÍAS.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
25
MOTOR DE RECOMENDACIONES
TÈCNICA IF
En este grupo se analizan todos los niveles de los parámetros
registrados a través de la App HealthMonitor Ug., hacemos referencias a
los grupos de control: Presión/Peso/Colesterol/Ex.
Complementarios/Glucosa/Insulina.
CONFIGURACIONES
En la Tabla Parámetros, se especifica por grupo de Control cada
parámetro configurado:
GRUPO DE CONTROL ID NOMBRE GRUPO
COLESTEROL
12 COLESTEROL
CL 14 HDL
15 LDL
13 TRIGLICERIDOS
EXAMENES
COMPLEMENTARIOS
4 CETONA EC
3 HBA1C
GLUCOSA 1 GLUCOSA GL
INSULINA 2 INSULINA IN
PRESION
17 PRESION DIASTOLICA
PR 16 PRESION SISTOLICA
18 PULSO
PESO
10 DMO
PS
7 IMC
11 MASA MUSCULAR
6 PESO
8 PORCENTAJE DE AGUA
9 PORCENTAJE DE GRASA
23 TMB
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
26
En la Tabla Rangos_Parametros se encuentran configurados límites
mínimos y máximos de los parámetros en base a investigaciones
realizadas y en la cual según los rangos establecidos se almacena un
mensaje de alerta, que será presentado al paciente como una notificación
en su teléfono.
PROCESAMIENTO
Para el procesamiento del motor de recomendaciones (Aplicando Técnica
IF), se crea el Proceso PR_RECOMIENDA_MOTOR que es invocado
desde un Shell configurado en el servidor Crontab.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
27
1. Invoca el procedimiento elim_msj_not () para eliminar las notificaciones
anteriores (libera de información la tabla mensajes_notificaciones
enviando los registros a una tabla historial hist_msj_notif).
2. Recorre todos los pacientes registrados en la App que cuenten con
código PUSH, esta información se almacena en las tablas: pacientes y
notificaciones.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
28
3. Recorre todos los pacientes obteniendo los últimos ID registrados en la
tabla control_paciente
4. Estos ID son utilizados para realizar un análisis personalizado por cada
grupo de control.
Procedimientos por grupos de Control
Cada grupo de control tiene un personalizado SP (procedimiento
almacenado) en los que se identifican todos los parámetros y además se
obtiene el último valor registrado por cada uno de ellos en la tabla donde
se almacenan.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
29
Tomamos como ejemplo el Control de Presión.
1. Obtiene la información de la Tabla Detalle_Presion
2. Obtiene los parámetros por grupo de control “PR” en la Tabla Parámetros
3. Invoca al Procedimiento RcomPaciente(), encarga de validar la información
en la tabla Rangos_Parametros y obtiene una recomendación configurada
según los rangos del parámetro que se envía a analizar Ej.: Pulso
4. Invoca al procedimiento ins_mens_notif() para registrar el mensaje de alerta
en la tabla mensajes_notificaciones. Esta será la notificación que recibirá el
paciente como notificación de la Aplicación.
MANUAL DE OPERACIONES BASE DE DATOS PROYECTO: APP HEALTHMONITOR UG V.2.0
Elaborado por: Johanna Pardo
30
TÈCNICA TIPS
Los tips son recomendaciones en relación a las 2 enfermedades
que la aplicación analiza (Diabetes-1/Asma-2. Se configuran en la Tabla
TBL_TIPS consejos generales que aportan a la actividad diaria del
paciente.
Para la ejecución de esta técnica se utiliza el procedimiento slc_tips que
obtiene los tips configurados, este procedimiento es invocado por los
métodos de WEB-Service para presentar en el módulo de
Recomendaciones de la App. Se presenta cinco tips de forma aleatoria
cada vez que se carga nuevamente el método al ingresar al Módulo
Recomendaciones de la Aplicación.
Diabetes
Asma