diseÑo e implementaciÓn de una base de datos …
TRANSCRIPT
DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS DISTRIBUIDA HOMOGÉNEA EN EL PROTOTIPO DE UN SISTEMA DE CONTROL DE
ACCESO
JULIÁN DAVID CAMPO ROMERO
JORGE ALFREDO CRUZ CAMELO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
INGENIERÍA TELEMÁTICA
BOGOTÁ D. C. 2019
DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS DISTRIBUIDA HOMOGÉNEA EN EL PROTOTIPO DE UN SISTEMA DE CONTROL DE
ACCESO
JULIÁN DAVID CAMPO ROMERO
20172678014
JORGE ALFREDO CRUZ CAMELO
20172678052
Proyecto presentado como requisito para optar por el título de INGENIERO EN TELEMÁTICA
PROYECTO DE INVESTIGACIÓN
Tutor ING. MIGUEL ÁNGEL LEGUIZAMÓN PAÉZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS INGENIERÍA TELEMÁTICA
BOGOTA D. C. AGOSTO 2019
NOTA DE ACEPTACIÓN
_______________________________
_______________________________
_______________________________
________________________________ Firma del Tutor
________________________________ Firma del Jurado
TABLA DE CONTENIDO
RESUMEN ............................................................................................................... 1
INTRODUCCIÓN ..................................................................................................... 3
1. FASE DE DEFINICIÓN Y PLANEACIÓN ......................................................... 4
1.1. TÍTULO DEL TRABAJO .............................................................................. 4
1.2. TEMA .......................................................................................................... 4
1.3. PLANTEAMIENTO DEL PROBLEMA ......................................................... 4
1.3.1. Descripción .......................................................................................... 4
1.3.2. Formulación del problema .................................................................... 4
1.4. JUSTIFICACIÓN ......................................................................................... 5
1.5. OBJETIVOS ................................................................................................... 6
1.5.1. Objetivo General ...................................................................................... 6
1.5.2. Objetivos específicos ............................................................................... 6
1.6. ALCANCES Y LIMITACIONES ................................................................... 7
1.6.1. Alcances ............................................................................................... 7
1.6.2. Limitaciones ......................................................................................... 7
1.7. MARCO DE REFERENCIA ........................................................................ 8
1.7.1. Marco histórico ..................................................................................... 8
1.7.1.1. Nivel local .......................................................................................... 8
1.7.1.2. Nivel nacional .................................................................................... 8
1.7.1.3. Nivel internacional ............................................................................. 8
1.7.2. Marco teórico ........................................................................................... 9
1.7.2.1. ¿Qué es Computación Distribuida? .................................................. 9
1.7.2.2. Base de datos (BD) ......................................................................... 10
1.7.2.3. Bases de datos distribuidas (BDD) ................................................. 11
1.7.2.4. Sistemas de bases de datos distribuidas ........................................ 13
1.7.2.5. Sistemas Gestores de bases de datos distribuidas (SGBDD) ........... 15
1.7.2.6. Arquitectura de una base de datos distribuida ................................ 17
1.7.3. Marco metodológico .............................................................................. 18
1.7.3.1. Recolección de información ............................................................... 18
1.7.3.2. Fase de planeación ............................................................................ 18
1.7.3.3. Diseño y construcción ........................................................................ 18
1.7. FACTIBILIDAD ......................................................................................... 21
1.7.3. Factibilidad técnica ............................................................................. 21
1.7.4. Factibilidad operativa ......................................................................... 21
1.7.5. Factibilidad económica ....................................................................... 22
1.7.6. Factibilidad legal................................................................................. 22
2. DIAGNÓSTICO, ANÁLISIS Y DISEÑO .......................................................... 23
2.1. Análisis ..................................................................................................... 23
2.2.1. Selección de herramientas .................................................................... 25
2.2.2. Diseño de la base de datos ................................................................... 27
2.2.3. Metodología de diseño de la base de datos distribuida ...................... 27
2.3. Definir método de distribución de base de datos ...................................... 37
2.4. Modelo conceptual de organización en red de la base de datos .............. 38
3. IMPLEMENTACIÓN DE LA BASE DE DATOS DISTRIBUIDA Y
CONFIGURACIÓN DE SERVIDORES .................................................................. 40
3.1. Preparación y configuración de los servidores para la base de datos ...... 40
3.2. Montaje de la base de datos en los servidores ......................................... 45
4. CONFIGURACIÓN Y VERIFICACIÓN DE LA INTERACCIÓN DEL SISTEMA
CON LA BASE DE DATOS DISTRIBUÍDA ............................................................ 47
5. VERIFICACIÓN DE CONSULTAS A LA BASE DE DATOS Y
RETROALIMENTACIÓN DEL SISTEMA ............................................................... 55
CONCLUSIONES .................................................................................................. 58
BIBLIOGRAFÍA ...................................................................................................... 60
LISTA DE TABLAS
Tabla 1. Recursos Humanos.................................................................................. 21
Tabla 2. Recursos físicos para el desarrollo del prototipo ..................................... 22
Tabla 3. Lista de identidades de la BD .................................................................. 29
LISTA DE FIGURAS
Figura 1. Motivación de los sistemas de bases de datos distribuidas .................... 10
Figura 2. Sistema Distribuido ................................................................................. 13
Figura 3. Cronograma de actividades .................................................................... 24
Figura 4. Arquitectura de una SMBDD homogéneo. .............................................. 25
Figura 5. Esquema Conceptual de Base de datos. ................................................ 28
Figura 6. Identidad usuario. ................................................................................... 29
Figura 7. Identidad auto. ........................................................................................ 30
Figura 8. Identidad Maneja .................................................................................... 30
Figura 9.Identidad opera ........................................................................................ 30
Figura 10.Identidad Tipo_Usu ................................................................................ 30
Figura 11.Identidad Operación............................................................................... 31
Figura 12. Relación Usuario-Auto-Maneja. ............................................................ 31
Figura 13. Relación Usuario, Auto, Operación – Opera ......................................... 31
Figura 14. Relación Usuario-Tipo_Usu .................................................................. 31
Figura 15. Modelo Relacional ................................................................................ 32
Figura 16. Esquema físico ..................................................................................... 35
Figura 17. Fragmentación – Asignación ................................................................ 35
Figura 18. Fragmentación Mixta ............................................................................ 36
Figura 19. Red de comunicaciones base de datos distribuida ............................... 38
Figura 20. Configuración Instancia Local ............................................................... 40
Figura 21. Creación máquina virtual ...................................................................... 41
Figura 22. Uso de VLAN para red .......................................................................... 42
Figura 23. Configuración de IP fija para VLAN, servidor remoto ........................... 42
Figura 24. Configuración de IP fija para VLAN, servidor remoto ........................... 43
Figura 25. Configuración instancia servidor virtual ................................................ 43
Figura 26. Creación Linked Server ........................................................................ 44
Figura 27. Configuración Linked Server ................................................................. 44
Figura 28. Configuración credencial SQL .............................................................. 45
Figura 29. Prueba: ping servidor local a servidor remoto ....................................... 47
Figura 30. Prueba: ping servidor remoto a servidor local ....................................... 47
Figura 31. Prueba: consulta distribuida desde servidor local al servidor remoto ... 48
Figura 32. Prueba: consulta distribuida desde servidor remoto al servidor local ... 49
Figura 33. Cadenas de conexión ........................................................................... 49
Figura 34. Conexiones con los servidores ............................................................. 50
Figura 35. Prueba: Informe de entradas y salidas desde el sistema de control ..... 51
Figura 36. Prueba: Simulación de caída del servidor de salida a las 20:06hrs. ..... 52
Figura 37. Registro de salida a las 20:21hrs., luego de caída del servidor. ........... 52
Figura 38. Comprobación de que la operación fue exitosa y su registro quedó en el
servidor de entrada. ............................................................................................... 53
Figura 39. Creación de usuario desde el sistema. ................................................. 53
Figura 40. Comprobación de registro en la base de datos distribuida. .................. 54
Figura 41. Ejemplo Consulta: Selección de todos los datos de usuarios. .............. 55
Figura 42. Ejemplo Consulta distribuida: Informe de entradas y Salidas. .............. 56
Figura 43. Inserciones distribuidas: Entrada de Usuarios. ..................................... 56
RESUMEN
Las bases de datos distribuidas ofrecen algunas ventajas clave sobre las bases de
datos centralizadas, como lo es, fiabilidad, seguridad, rentabilidad, acceso local,
crecimiento, velocidad y eficiencia de los recursos, responsabilidad y contención.
Es por ello que muchas empresas están cambiando a bases de datos distribuidas,
en las cuales como su nombre lo indica, se distribuye a través de una matriz de
servidores en varias ubicaciones.
El objetivo de este proyecto es diseñar e implementar una base de datos distribuida
en un sistema de control de acceso de acceso que utiliza tecnologías RFID y huella
digital, esto teniendo en cuenta las fases necesarias para su correcto diseño,
solucionando así la problemática que presenta el sistema actualmente que es tener
una base de datos centralizada.
ABSTRACT
Distributed databases offer some key advantages over centralized databases, such
as reliability, security, profitability, local access, growth, speed and efficiency of
resources, responsibility and containment. That is why many companies are
switching to distributed databases, in which as the name implies, it is distributed
through an array of servers in several locations.
The objective of this project is to design and implement a database distributed in an
access access control system that uses RFID and fingerprint technologies, this
taking into account the necessary phases for its correct design, thus solving the
problem presented by the system currently that is to have a centralized database.
INTRODUCCIÓN
El presente trabajo hace referencia a la problemática de las bases de datos
centralizadas y como una base de datos descentralizada puede mejorar esta
problemática de forma eficiente. Las bases de datos actualmente son muy
importantes debido a que en ellas se guarda información de suma importancia, con
los recientes avances tecnológicos en cuanto a comunicación y redes, hoy en día
es cada vez más común encontrar sistemas descentralizados cuya información se
encuentre disponible desde varias localizaciones geográficas. La necesidad de
integrar y compartir dicha información, implica el nacimiento de una nueva
tecnología capaz de conformar de manera consistente la información de las
organizaciones.
Una de las tecnologías que trabaja en el problema de integración es las Bases de
Datos Distribuidas (BDD), con lo que se busca simplificar las consultas de una base
de datos para poder acceder desde cualquier sitio, en cualquier punto de la red tal
como si todos los datos estuvieran almacenados en el mismo sitio, con esto se
puede dar una definición más formal de base de datos distribuida (BDD), como una
colección de múltiples bases de datos interrelacionadas lógicamente y distribuidas
por una red de computadores.1
Los sistemas de información basados en bases de datos distribuidas, buscan el
manejo eficiente e integrado de la información generada en cualquier tipo de entorno
productivo; los sistemas de bases de datos distribuidas, que no necesariamente
deben ser homogéneos, permiten a los usuarios obtener una visión generalizada de
la información disponible. Al diseñar un nuevo sistema de información o prolongar
la vida de uno ya existente, en cualquiera de los dos casos se debe buscar siempre
la forma de enlazar las soluciones ofrecidas por la tecnología disponible a las
necesidades de las aplicaciones de usuarios, estas soluciones deben ofrecer mayor
funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento.
1 NAVAS, Francisco Corbera; GALLEGO, Alejandro Delgado. BASE DE DATOS DISTRIBUIDAS. [Consulta 10 de Julio de 2019]
1. FASE DE DEFINICIÓN Y PLANEACIÓN
1.1. TÍTULO DEL TRABAJO
DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS DISTRIBUIDA
HOMOGÉNEA EN EL PROTOTIPO DE UN SISTEMA DE CONTROL DE
ACCESO.
1.2. TEMA
La solución planteada está orientada al diseño e implementación de una base de datos distribuida homogénea en el prototipo de un sistema de control de acceso.
1.3. PLANTEAMIENTO DEL PROBLEMA
1.3.1. Descripción
En el prototipo de un sistema de control de acceso que implementa tecnologías
RFID y lectura de huella digital, se realizan constantes consultas a la base de
datos, con el objetivo de comprobar la información recibida por los sensores, y
compararla con la que se encuentra almacenada, proceso que se realiza en
cualquier momento, teniendo en cuenta que dichos sensores se encuentran
activos durante todo el día.
Debido al alto flujo de usuarios que puede llegar a presentarse al implementar el
sistema antes descrito, la cantidad de consultas en un espacio de tiempo
determinado, es uno de los aspectos más importantes a tener en cuenta para la
mejora de la eficiencia y fiabilidad del mismo.
Para dicho propósito, se hace necesario plantear una solución que garantice una
alta disponibilidad de la información en la base de datos ya que, de no ser así,
se pueden presentar fallos de funcionamiento, demoras en el funcionamiento del
sistema y/o accesos no autorizados.
1.3.2. Formulación del problema
¿Qué solución tecnológica en el ámbito telemático podría ser implementada en
el prototipo de un sistema de control de acceso que implementa RFID y huella
digital, para garantizar una alta disponibilidad de la información?
1.4. JUSTIFICACIÓN
Las motivaciones para realizar este proyecto fueron básicamente teniendo en
cuenta dos aspectos: la tecnología y los usuarios. En el caso de los usuarios se
tiene en cuenta que, utilizando una base de datos centralizada, no todos pueden
obtener un servicio óptimo y que en algunos casos no se puede tener el control total
de la información, causando así perdida de datos y demás. En cuanto a la tecnología
se observa desde el punto de vista que, desde hace mucho tiempo existen formas
de distribuir los datos que permiten disminuir la sobrecarga de los canales de
entrada y salida ya que es mucho mejor distribuir los accesos a la información sobre
diferentes canales que concentrarlos en uno solo.
Así partiendo de lo anteriormente dicho el hacer una descentralización de la
información permite básicamente que:
• Haya una autonomía local promoviendo la evolución de los sistemas y los
cambios en los requerimientos del usuario.
• Exista una arquitectura de sistemas simple, flexible y tolerante a fallas.
• Ofrezca buenos rendimientos.
Por lo tanto, en este proyecto se decide implementar una base de datos distribuida
homogénea para el prototipo de un sistema de control de acceso que implementa
tecnologías RFID y huella digital donde el objetivo principal es convertir el modelo
de la base de datos centralizada en una base de datos distribuida donde se pueden
controlar tanto las entradas y salidas del sistema generando así una mayor
disponibilidad.
1.5. OBJETIVOS
1.5.1. Objetivo General
Diseñar e implementar una base de datos distribuida homogénea que permita
garantizar una alta disponibilidad de la información, para el prototipo de un
sistema de control de acceso que implementa tecnologías RFID y huella digital.
1.5.2. Objetivos específicos
• Planear la estructura de una base de datos homogénea, así como su
implementación, con el fin de establecer las principales necesidades que
debe suplir en cuanto al sistema de control de acceso.
• Implementar la base de datos en servidores virtuales, con el fin de tener
un contexto lo más cercano posible a un ambiente real.
• Realizar la configuración necesaria para asegurar la conexión e
interacción del sistema de control de acceso con la base de datos.
• Verificar que el sistema de control de acceso interactúa de manera
adecuada con la base de datos distribuida, y retroalimentar los posibles
fallos.
• Corregir los fallos presentados y replantear los aspectos de diseño
necesarios para asegurar la mejora continua de la implementación.
1.6. ALCANCES Y LIMITACIONES
1.6.1. Alcances
• Diseñar e implementar un base de datos distribuida homogénea
utilizando un red de comunicaciones con servidores virtuales.
• Mejorar la disponibilidad de los datos ofreciendo una mayor cobertura.
• Lo servidores para la base de datos serán de tipo virtual, con esto se
intenta hacer una simulación lo más posible a la realidad.
• Distribuir las cargas de trabajo, enfocándose en las entradas y salidas
que se hacen en el sistema de control de acceso.
1.6.2. Limitaciones
• No se cuenta con un servidor real para la base de datos, por ende se
decide utilizar una máquina local y un servidor de máquina virtual.
• El sistema en cual se realizó el montaje de la base de datos distribuida
es un prototipo, el cual en algún momento puede ser llevado a la
realidad.
1.7. MARCO DE REFERENCIA
1.7.1. Marco histórico
Las bases de datos distribuidas tienen múltiples aplicaciones, para este caso es
el uso que se le da en sistemas de control de acceso, por tanto, se ha buscado
las diferentes implementaciones que se le ha dado, tanto a nivel local, nacional
e internacional; encontrando las siguientes ejecuciones:
1.7.1.1. Nivel local
SISTEMA TELEMÁTICO BASADO EN SERVICIOS WEB,
GEORREFERENCIACIÓN Y BASES DE DATOS DISTRIBUIDAS PARA
GESTIONAR LA INFORMACIÓN DEL DEPARTAMENTO DE VENTAS DE
UNA ORGANIZACIÓN DEDICADA AL COMERCIO DE MATERIALES PARA
LA CONSTRUCCIÓN, brinda un aporte bastante amplio ya que es aplicado a un
caso real del cual se puede tomar como realizar las pruebas en cada uno de los
módulos del sistema al realizar la implementación de la base de datos distribuida
homogénea.
IMPLEMENTACIÓN DE TRANSACCIONES DISTRIBUIDAS USANDO
AGENTES INTELIGENTES, Este proyecto ofrece unas características bastante
interesantes ya que puede orientar sobre cómo resolver diferentes
problemáticas que se presentan comúnmente en los desarrollos distribuidos
para que el sistema ofrezca confiabilidad, tolerancia a fallos y seguridad.
1.7.1.2. Nivel nacional
SIADBDD: UNA HERRAMIENTA INTEGRADA DE AYUDA AL DISEÑO DE
BASES DE DATOS DISTRIBUIDAS, el artículo presenta un aporte al proyecto
con una herramienta integrada de ayudas al diseño de BDD en un contexto de
bases de datos relacionales. Estas ayudas consideran desde la modelación
conceptual de esquemas globales hasta la localización de los fragmentos de
datos a los sitios de procesamiento donde residirá la BDD objeto de diseño.
1.7.1.3. Nivel internacional
MODELADO E IMPLEMENTACIÓN DE UN SISTEMA DISTRIBUIDO PARA LA
GESTIÓN DE CONSULTAS EN LAS BIBLIOTECAS DE LA UNT, El aporte que
este proyecto para la propuesta que se va a realizar nos muestra cómo se realizó
el montaje de la base de datos distribuida desde su elaboración hasta su
implementación y de acuerdo a esto tener en cuenta los detalles necesarios para
su unificación en el sistema y evaluar su comportamiento.
AUTOMATIZACIÓN DEL DISEÑO DE LA FRAGMENTACIÓN VERTICAL Y
UBICACIÓN EN BASES DE DATOS DISTRIBUIDAS USANDO MÉTODOS
HEURÍSTICOS Y EXACTOS, Este trabajo da un aporte de diferentes
metodologías para el diseño de base de datos distribuidas, además de ello
específica cómo realizar un correcto análisis para el diseño de una base de datos
distribuida.
SISTEMA RECOMENDADOR COLABORATIVO USANDO MINERÍA DE
DATOS DISTRIBUIDA PARA LA MEJORA CONTINUA DE CURSOS E-
LEARNING, Este artículo aporta algunos algoritmos para realizar minería de
datos en sistemas distribuidos que pueden ser utilizados en algún trabajo futuro
de acuerdo a la solución que se está planteado.
BASES DE DATOS DISTRIBUIDAS PARA APLICACIONES MÉDICAS EN EL
SISTEMA NACIONAL DE SALUD, Este artículo aporta diferentes
recomendaciones para el diseño de una base de datos distribuida en este caso
su aplicación se da en el sector de la salud y como se realizó la migración de un
sistema con una base de datos centralizada a una base de datos descentralizada
haciendo su integración con un software que trabaja con arquitectura de 3 capas
utilizado en el sector de la salud.
MODELO INTELIGENTE PARA BASES DE DATOS DISTRIBUIDAS, El
artículo ofrece un gran aporte en cuanto a bases de datos distribuidas ya que
propone la utilización de ontologías para la integración de las mismas, esto a
través de esquemas ontológicos para las bases de datos. El aspecto
fundamental de este artículo es proponer un marco ontológico basado en
sentencias de lógica de primer orden (LPO) para la integración de una federación
de bases de datos de diferentes tipos (Relacionales, Orientadas a objeto,
Multimedia, Difusas e Inteligentes).
1.7.2. Marco teórico
1.7.2.1. ¿Qué es Computación Distribuida?
La computación distribuida es un sistema de administración de computadores
en los cuales un conjunto de elementos de procesamiento independiente (no
necesariamente homogéneos) se interconectan por una red de comunicaciones
y trabajan entre ellos para efectuar sus tareas asignadas. El cómputo distribuido
determina la forma como se realizan los procesos entre ellas y las funciones de
manejo de datos para el manejo de funciones distribuidas y procesamiento
distribuido de datos.
Existen muchas componentes a distribuir para realizar una tarea. En
computación distribuida los elementos que se pueden distribuir son:
• Control: Las actividades relacionadas con el manejo o administración del
sistema.
• Datos: La información que maneja el sistema.
• Funciones: Las actividades que cada elemento del sistema realiza.
• Procesamiento lógico: Las tareas específicas involucradas en una
actividad de procesamiento de información
Figura 1. Motivación de los sistemas de bases de datos distribuidas
Fuente: https://lihectortorres.files.wordpress.com/2010/09/base_de_datos_distribuidas.pdf
1.7.2.2. Base de datos (BD)
Una base de datos es un conjunto de datos relacionados entre sí. Por datos se
entienden hechos conocidos que pueden registrarse y que tienen un significado
implícito. 2 Se trata de un conjunto de datos relacionados entre sí y que tienen
un significado implícito; por tanto, constituyen una base de datos.
Una base de datos tiene las siguientes propiedades implícitas:
• Una BD representa algún aspecto del mundo real, en ocasiones llamado
universo del discurso. Las modificaciones del universo del discurso se
reflejan en la BD.
• Una BD es un conjunto de datos lógicamente coherente, con cierto
significado incoherente.
• Toda BD se diseña, construye y puebla con datos para un propósito
específico. Está dirigida a un grupo de usuarios y tiene ciertas
aplicaciones preconcebidas que interesan a dichos usuarios.
2DÍAZ, MC ALEJANDRO GUTIÉRREZ. Bases de Datos. Centro Cultural Itaca SC, 2015. [Consultado 12 de Julio 2019]
Una BD puede ser de cualquier tamaño y tener diversos grados de complejidad,
pero debe organizarse y controlarse para que los usuarios puedan buscar,
obtener y actualizar los datos cuando sea necesario.
1.7.2.3. Bases de datos distribuidas (BDD)
Una Base de Datos Distribuida (BDD) es, una base de datos construida sobre
una red de computadores. La información que estructura la base de datos esta
almacenada en diferentes sitios en la red, y los diferentes sistemas de
información que las utilizan accedan datos en distintas posiciones geográficas.3
1.7.2.3.1. Características de las Bases de datos distribuidas (BDD)
• Los datos deben estar físicamente en más de un ordenador, es decir, los
datos se encuentran almacenados en distintas sedes.
• Las sedes deben estar interconectadas mediante una red de
computadoras (cada sede será un nodo de la red). Para realizar el diseño
no se tendrá en cuenta la topología, tipo y rendimiento de la red, aunque
estas propiedades tengan relevancia en el buen funcionamiento del
sistema.
• Los datos han de estar lógicamente integrados en una única estructura o
esquema lógico global común.
• Los usuarios han de tener acceso (recuperación y actualización) a los
datos pertenecientes a la BDD, ya residan éstos en la misma sede
(acceso local) o en otra sede (acceso remoto).
• Cada nodo o emplazamiento facilita un entorno para la ejecución de
transacciones tanto locales como globales.
• En una única operación, tanto de consulta como de actualización, se
puede acceder a datos que se encuentran en más de una sede sin que el
usuario sepa la distribución de los mismos en las distintas sedes. Es decir,
que la distribución de la información sea transparente para el usuario.
1.7.2.3.2. Ventajas
• Los datos son localizados en un lugar más cercano, por tanto, el acceso
es más rápido.
• El procesamiento es rápido debido a que varios nodos intervienen en el
procesamiento de una carga de trabajo, nuevos nodos se pueden agregar
fácil y rápidamente.
• La comunicación entre nodos se mejora, los costos de operación se
reducen, son amigables al usuario, la probabilidad que una falla en un
3 Diseño de Bases de datos Distribuida (Texto Base) (2005). [Consultado 12 Julio de 2019]
solo nodo afecte al sistema es baja y existe una autonomía e
independencia entre los nodos.
• Los datos se pueden colocar físicamente en el lugar donde se accedan
más
• frecuentemente, haciendo que los usuarios tengan control local de los
datos con los que interactúan.
• Mediante la replicación de información, las bases de datos distribuidas
pueden presentar cierto grado de tolerancia a fallas haciendo que el
funcionamiento del sistema no dependa de un solo lugar como en el caso
de las bases de datos centralizadas.
• La naturaleza distribuida de algunas aplicaciones de Bases de Datos:
Muchas de estas aplicaciones están distribuidas naturalmente en
diferentes lugares. Por ejemplo, una compañía puede tener oficinas en
varias ciudades, un banco puede tener múltiples sucursales.
• Mayor fiabilidad y disponibilidad: Estas son dos de las ventajas
potenciales de las Bases de Datos Distribuidas que se citan comúnmente,
la fiabilidad se define a grandes rasgos como la probabilidad de que un
sistema esté en funciones en un momento determinado, y la
disponibilidad es la probabilidad de que el sistema esté disponible
continuamente durante un intervalo de tiempo.
• Mejor rendimiento: Cuando una base de datos grande está muy
distribuida en múltiples sitios, hay bases de datos más pequeñas en cada
uno de estos. En consecuencia, las consultas locales y las transacciones
que tienen acceso a datos a un solo sitio tienen un mejor rendimiento
porque las bases de datos son más pequeñas, además cada sitio tiene
un mejor número de transacciones en ejecución que si todas las
transacciones se enviaran a una sola base de datos centralizada.
1.7.2.3.3. Desventajas
• La principal desventaja se refiere al control y manejo de los datos. Dado
que éstos residen en muchos nodos diferentes y se pueden consultar por
nodos diversos de la red, la probabilidad de violaciones de seguridad es
creciente si no se toman las precauciones debidas.
• Asegurar la integridad de la información en presencia de fallas no
predecibles, tanto de componentes de hardware como de software, es
compleja. La integridad se refiere a la consistencia, validez y exactitud de
la información.
• Dado que los datos pueden estar replicados, el control de concurrencia y
los mecanismos de recuperación son mucho más complejos que en un
sistema centralizado.
• La distribución produce un aumento en la complejidad del diseño y en la
implementación del sistema.
1.7.2.4. Sistemas de bases de datos distribuidas
Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual
múltiples sitios de bases de datos están ligados por un sistema de
comunicaciones, de esta manera se permite que cualquier usuario pueda
acceder a los datos en cualquier parte de la red exactamente como si los datos
estuviesen almacenados en su sitio propio.
Los principales factores que distinguen un SBDD de un sistema centralizado son
los siguientes.
• Hay varios computadores, llamados sitios o nodos.
• Los sitios deben estar comunicados por medio de algún tipo de red de
comunicaciones para transmitir los datos y ordenes entre los sitios.
Figura 2. Sistema Distribuido
Fuente: http://repositorio.uta.edu.ec/jspui/handle/123456789/344
1.7.2.4.1. Características de los sistemas distribuidos
• Cada sitio es un sistema de bases de datos en sí mismo.
• Los sitios pueden trabajar juntos (si es necesario) esto con el fin de que
un usuario de cualquier sitio pueda obtener acceso a los datos de
cualquier punto de la red tal como si todos estuvieran almacenados en el
sitio propio del usuario.
1.7.2.4.2. Beneficios de los sistemas distribuidos
• La descentralización evita la sobrecarga en un sitio y elimina la
dependencia del mismo.
• Mejor tiempo de respuesta, gracias al procesamiento local en cada uno
de los nodos sobre los que se distribuye el sistema. Esto incrementa el
rendimiento a través de un alto grado de paralelismo (Transacciones al
igual que reportes más rápidos).
• Sobrecarga de comunicación reducida, con la maximización de la
localidad de las aplicaciones.
• Reducción de costos, por la minimización del uso del canal y por el hecho
que es más rentable adquirir múltiples equipos que un gran computador
central (por lo menos esto es válido en el caso de los mainframes).
• La extensibilidad en el hardware, al adicionar una estación a la red
fácilmente. En la base de datos, al permitir interconectar las bases de
datos preexistentes, conformando una base de datos distribuida. La
heterogeneidad (Diferentes tipos de bases de datos. Por ejemplo, una
base de datos en Oracle, otra en Access, etc.) es representativa aquí ya
que se rompen dependencias con un proveedor, permitiendo que el
sistema se extienda con productos diferentes.
• Disponibilidad, se logra por la redundancia del hardware, del software y
de los datos, también por la dispersión de recursos.
1.7.2.4.3. Problemas de los sistemas distribuidos
• El control del acceso a datos dispersos se vuelve inmanejable.
• La coordinación de procesos concurrentes y remotos resulta más
compleja.
• El montaje de sistemas distribuidos en ambientes heterogéneos no está
completamente resuelto. A nivel de protocolos está resuelto pero los
niveles aplicativos siguen presentando problemas.
• Asegurar el desarrollo conjunto de software es un inconveniente que tiene
que ver con la disciplina, la heterogeneidad de los grupos de trabajo y la
misma idiosincrasia y costumbres de las personas.
• Ningún sitio puede observar el estado global de todo el sistema, por lo
cual se corre con el riesgo de tomar decisiones inconsistentes en el
procesamiento.
Cuando hay una inadecuada migración hacia los sistemas distribuidos se
pueden generar problemas adicionales como los siguientes:
a. Pérdida del control gerencial.
b. Pérdida del control en el manejo de los sistemas de información.
c. Suboptimización.
d. Fallas en el aprovechamiento del SMBD (Sistema Manejador de Bases de
Datos), ya que los usuarios implementan archivos locales en otras
herramientas.
e. Problemas de mantenimiento.
1.7.2.5. Sistemas Gestores de bases de datos distribuidas (SGBDD)
Un sistema de manejo de bases de datos distribuidos (SMBDD) es aquel que se
encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace
que la distribución sea transparente a los usuarios.4 Con transparencia se hace
referencia a que la aplicación trabajaría como si una sola máquina administrara
los datos.
1.7.2.5.1. Características y arquitectura de los SGBDD
• Capacidad de acceder a sitios remotos y transmitir consultas y datos entre
diversos sitios a través de una red de ordenadores.
• Capacidad de rastrear la traza de distribución y de replicación de los datos
en el catálogo de SGBDD.
• Capacidad de elaborar estrategias de ejecución para consultas y
transacciones con acceso a datos situados en nodos diferentes.
• Capacidad de mantener la consistencia en las réplicas de un elemento de
información.
• Capacidad de decidir cuál de las copias de un elemento de información
será accedida.
• Capacidad de recuperación ante caídas de sitios individuales y fallos de
un enlace de comunicación.
4 DISEÑO DE BASES DE DATOS DISTRIBUIDA (Texto Base). [Consultado 13 de Julio de 2019]
Para que esto sea posible el SGBDD debe contar con los siguientes
componentes que permitan ofrecer las funcionalidades descritas
• Procesador de datos locales, que se encarga de la gestión local de los
datos de forma parecida al software de un SGBD centralizado, por lo que
además de ejecutar transacciones locales se encarga de la concurrencia
y la recuperación ante fallos a nivel local.
• Diccionario o directorio global, donde se guardará información acerca
de dónde y cómo se almacenan los datos, el modo de acceso y otras
características físicas. En resumen, contiene las especificaciones
necesarias para pasar de la representación externa o esquema externo
de los datos a la representación interna de los mismos.
• Procesador de aplicaciones distribuidas, que es el responsable de las
funciones distribuidas. Accede a la información sobre la ubicación de los
datos, que se encuentra en el diccionario, y se ocupa de procesar todas
las peticiones que involucran más de una sede para generar un plan de
ejecución distribuido. Es el elemento diferenciador en los sistemas
distribuidos, dada una operación se encargará de repartir el trabajo a los
distintos procesadores locales que intervienen en dicha operación.
• Software y red de comunicaciones. No forma parte estrictamente del
SGBDD, sino que provee al procesador de aplicaciones distribuidas
primitivas y servicios de comunicaciones para que éste lleve a cabo su
labor.
1.7.2.5.2. Clasificación de los SGBDD
Para realizar esta clasificación se deben tener en cuenta tres características: la
distribución, la autonomía y heterogeneidad del sistema local.
Distribución
En este aspecto se parte de que los datos pueden ser distribuidos entre múltiples
bases de datos. Estas bases de datos pueden estar almacenadas en un único
sistema o en varios, distribuidos geográficamente, pero interconectados por un
sistema de comunicación. Algunos de los beneficios de la distribución de los
datos son bien conocidos, tales como una mayor disponibilidad y fiabilidad de la
información, así como una mejora en los tiempos de acceso.
Autonomía
Se refiere a la distribución del control, no de los datos. Indica el grado en el que
los SGBD pueden actuar independientemente y es función de factores tales
como el nivel de intercambio de información entre los componentes del sistema,
la ejecución independiente de transacciones, la tolerancia a modificaciones
respectivas en los datos, etc.
Existen diferentes tipos de autonomía, entre ellos están:
• Autonomía de diseño: Cada nodo de la base de datos puede decidir los
aspectos relacionados con su diseño. El SGBD es libre de utilizar. Aquí
se debe tener en cuenta los siguientes aspectos:
✓ La representación (modelo de datos, lenguaje de consultas) y el
nombrado de los datos.
✓ La funcionalidad del sistema
✓ La asociación y compartición con otros sistemas.
• Autonomía de comunicación: es la habilidad que posee cada nodo para
decidir si comunicarse o no con otro componente de una misma
federación.
• Autonomía de ejecución: es la habilidad de un nodo para ejecutar
operaciones locales sin tener la interferencia de operaciones externas, en
el orden en que el nodo decida.
• Autonomía de asociación: cada nodo cuanto, y cuando puede compartir
su funcionalidad y recursos con otros componentes, inclusive la
capacidad de asociarse o retirarse de una o más federaciones.
1.7.2.6. Arquitectura de una base de datos distribuida
Un sistema de base de datos distribuida permite desarrollar aplicaciones para
acceder a información local y remota de una base de datos. En un sistema
homogéneo de base de datos distribuida, cada base de datos es una base de datos
SQL Server, mientras que, en un sistema heterogéneo de base de datos distribuida,
por lo menos una de las bases de datos no es una base de datos SQL Server. Las
bases de datos distribuidas usan arquitectura cliente / servidor para procesar la
información requerida.5
5 Luis Roberto Oñate Llerena, Marco Fabián Guangashi Guangasi, DISEÑO DE BASES DE DATOS DISTRIBUIDAS EMPLEANDO LA ARQUITECTURA DE REPLICACION ORACLE [Consultado 13 Julio 2019].
1.7.3. Marco metodológico
En esta parte se realizará una breve descripción sobre la metodología que se
utilizará para el desarrollo del proyecto.
1.7.3.1. Recolección de información
Esta fase consiste en reunir toda la información necesaria para el posterior análisis
y desarrollo del proyecto, el objetivo de esta fase es tener claro el estado actual del
proyecto.
1.7.3.2. Fase de planeación
Esta fase incluye el planteamiento del problema y los objetivos del proyecto con los
cuales se pretende cumplir lo planteado así mismo la justificación del por qué se
planteó el proyecto y el alcance que se le quiere dar.
1.7.3.3. Diseño y construcción
Esta fase incluye el diagnostico, análisis y diseño para la base de datos distribuida
donde se especifica un análisis de acuerdo a los requisitos y objetivos del proyecto,
en cuanto al diseño y construcción de la base de datos distribuida se incluye lo
siguiente:
1.7.3.3.1. Diseño del esquema conceptual y lógico de la base de datos:
El diseño conceptual es el proceso por el cual se construye un modelo de la
información que utilizan las empresas u organizaciones, independientemente del
Sistema Gestor de Base de Datos que se vaya a utilizar para implementar el sistema
y de los equipos informáticos o cualquier otra consideración física.
Para conseguir estos esquemas se utilizan modelos de datos. El paso entre cada
esquema se sigue con unas directrices concretas. Estas directrices permiten
adaptar un esquema hacia otro. Los dos modelos fundamentales de datos son el
conceptual y el lógico. Ambos son conceptuales en el sentido de que convierten
parámetros del mundo real en abstracciones que permiten entender los datos sin
tener en cuenta la física de los mismos.
Este esquema se realiza con el objetivo comprender:
- La perspectiva de los usuarios sobre los datos
- La naturaleza de los datos, independientemente de su representación física.
- El uso de los datos a través de las áreas de aplicación
1.7.3.3.2. Diseño físico de la base de datos:
El objetivo de esta etapa es producir una descripción de la implementación de la
base de datos en memoria secundaria. Esta descripción incluye las estructuras de
almacenamiento y los métodos de acceso que se utilizarán para conseguir un
acceso eficiente a los datos.
El diseño físico abarca varios temas. En concreto, en el diseño físico se tienen en
cuenta los siguientes pasos: 6 traducir el modelo lógico al SGBD seleccionado,
diseñar la organización de los archivos y los índices, diseñar las vistas y
mecanismos de seguridad, considerar la introducción de redundancia controlada y
monitorizar y ajustar el sistema final.
1.7.3.3.3. Diseño de la distribución
En esta parte se deben de tener en cuenta dos aspectos:
1.7.3.3.3.1. Diseño de la fragmentación
Este es uno de los aspectos más importantes en el diseño de la BDD ya que tiene
como objetivo encontrar un nivel de particionamiento adecuado en el rango que va
desde las tuplas o atributos hasta relaciones completas. La fragmentación es el
proceso de subdividir un objeto global, en nuestro caso una entidad o relación en
varias partes, llamadas fragmentos. Por su parte la asignación es el proceso de
ubicación de cada fragmento en uno o más sitios. 7
1.7.3.3.3.2. Diseño de la asignación de los fragmentos
La asignación de fragmentos puede ser redundante o no redundante. En la
asignación redundante cada fragmento es proyectado a uno o más sitios. En una
asignación redundante un fragmento es proyectado exactamente a un sitio.
1.7.3.4. Fase de verificación y evaluación
Esta fase incluye:
• Implementación de la base de datos distribuida y la configuración de los
servidores, en donde se implementa la base de dato distribuida después de
su diseño y construcción y se configuran los servidores en donde se
montarán las bases de datos para su interacción con el sistema.
6 ELIZONDO, Arturo Jaime; PÉREZ, César Domínguez. Trabajando en el laboratorio el diseño físico de bases de datos y la optimización de consultas. [Consultado 15 de Julio de 2019] 7 DÍAZ, Yambay; VINICIO, Marco. Directrices de Interoperabilidad de una Base de Datos Distribuida para la Optimización de Sistemas de Comercio Electrónico. 2004. Tesis de Maestría. Escuela Superior Politécnica de Chimborazo. [Consultado 17 de Julio de 2019].
• Configuración y verificación de la interacción del sistema con la base de datos
distribuida, en la cual se realizan las respectivas pruebas del sistema con la
base de datos distribuida y cómo se comporta este al momento de realizar la
conexión.
• Verificación de consultas a la base de datos y retroalimentación del sistema,
se hace una verificación
1.7. FACTIBILIDAD
1.7.3. Factibilidad técnica
En cuanto a la parte tecnológica se realizará una descripción a nivel de hardware
y del software que se requiere para el desarrollo y puesta en marcha del
proyecto.
Hardware: Un equipo con las siguientes características mínimas:
• Procesador de 2.0GHz, Intel® Core™ i3-4600U
• Sistema Operativo Windows 7 o superior
• Memoria RAM: 4 GB o superior
• Tarjeta gráfica: Gráficos Mobile Intel® HD
• Disco duro: 250GB
Software: Se utilizará lenguaje de programación C# y para la base de datos el
gestor SQL Server.
No solo será necesario tener en cuenta el aspecto tecnológico, sino también
contar con el recurso humano que es de vital importancia para el desarrollo del
proyecto el cual está a cargo de los ejecutores del proyecto Jorge Alfredo Cruz
Camelo y Julián David Campo Romero con el respaldo y la asesoría del
ingeniero Miguel Ángel Leguizamón Páez (Tutor del proyecto), además de ello
la primera vez que el software entre en funcionamiento puede resultar
complicado debido a que no ha sido utilizado con frecuencia pero luego de ser
dado a conocer por un tiempo será sencillo utilizarlo.
1.7.4. Factibilidad operativa
Tabla 1. Recursos Humanos
Personal Función Duración
(meses)
Valor/mes Total
Miguel Ángel Leguizamón Páez
Director de tesis
4
4000000 16.000.000
Julián David Campo Romero
Analista Desarrollador
4 500000 4.000.000
Jorge Alfredo Cruz Camelo
Analista Desarrollador
4 500000 4.000.000
TOTAL 24.000.000
Fuente: Autoría propia
1.7.5. Factibilidad económica
Teniendo en cuenta que no es necesario el pago de licencias de software, se
presentan los gastos que se deben tener en cuenta.
RECURSO DESCRIPCIÓN CANTIDAD COSTO UNITARIO
COSTO TOTAL
Equipo de desarrollo
(Computador)
1 $1.900.000 $1.900.000
Papelería Resma de Papel 2 $ 10.000 $ 20.000
Desarrollador Software
Ejecutores del proyecto (cada uno
480 horas, 30 semanales por 4
meses)
960 $7.200.000 $14.400.000
Horas Tutor Ejecutor de proyecto (6 horas semanales
por 4 meses)
48 $45.000 $2.160.000
TOTAL $18.843.000
Tabla 2. Recursos físicos para el desarrollo del prototipo
Fuente: Autoría propia
1.7.6. Factibilidad legal
El aspecto legal del proyecto se despliega bajo software que puede ser gratuito
con versiones para desarrolladores o en su defecto obtener una licencia
permanente.
2. DIAGNÓSTICO, ANÁLISIS Y DISEÑO
2.1. Análisis
Aquí se analizó el sistema, en busca de las necesidades básicas en cuanto a los
datos que se deben almacenar.
Se encontraron los siguientes aspectos como requisitos del sistema:
- Las operaciones principales son las de entrada y salida de usuarios para las
que se hace uso de 3 tablas que son cruciales para la validación y verificación
de datos. Hay otra tabla, en la que se guardan los registros de las
operaciones realizadas en un periodo de tiempo y es una de las más
importantes.
- Al ser entrada y salida las operaciones más importantes, son las que más
carga para el sistema generan, a diferencia de operaciones menos
concurrentes como la creación de usuarios, automóviles o relaciones en el
sistema.
- La tabla usuarios contiene un gran peso en cuanto a almacenamiento, debido
a que es donde se alojan las huellas digitales. Por esta razón, es necesario
encontrar la forma de reducir el espacio que puede a llegar a ocupar ésta
tabla, teniendo en cuenta que se alojará en dos servidores.
- Se debe dar prioridad a las columnas en las tablas, que son cruciales para
las consultas más recurrentes del sistema, en el momento en que se vaya a
realizar fragmentación del sistema.
En este caso se realiza una evaluación actual del sistema y el estado en el que se
encuentra con el fin de poder generar unos requisitos concretos que permitan el
desarrollo del proyecto. Además, se deben identificar todas las actividades
necesarias para alcanzar los objetivos del proyecto, así como quién las va a realizar,
teniendo como base los objetivos y requerimientos del usuario claros.
Figura 3. Cronograma de actividades
Fuente: Autoría propia
2.2. DISEÑO Y CONSTRUCCIÓN
En esta fase se hará especial énfasis en el diseño de la base de datos distribuida,
desde su modelado hasta el montaje en los servidores que harán empalme con el
sistema de control de acceso.
Desde el punto de vista funcional y de organización de datos, los sistemas de datos
distribuidos están divididos en dos clases separadas, basados en dos filosofías
diferentes y diseñadas para satisfacer necesidades diferentes:
1. Sistemas de manejo de base de datos distribuidos homogéneos
2. Sistemas de manejo de base de datos distribuidos heterogéneos
En este caso para el proyecto se quiere manejar un sistema homogéneo, ya que la
base de datos distribuida (BDD) que se pretende construir es homogénea.
Figura 4. Arquitectura de una SMBDD homogéneo.
Fuente: https://lihectortorres.files.wordpress.com/2010/09/base_de_datos_distribuidas.pdf
Los sistemas homogéneos se parecen a un sistema centralizado, pero en lugar de
almacenar todos los datos en un solo lugar, los datos se distribuyen en varios sitios
comunicados por la red. No existen usuarios locales y todos accedan a la base de
datos a través de una interfaz global.
2.2.1. Selección de herramientas
En esta parte se seleccionarán las herramientas que permitirán el diseño de la base
de datos que se implementará en el sistema de control de acceso, en este caso se
utilizará el software DB Designer para realizar tanto el modelo E/R y el modelo
relacional que permitirán llevar a cabo la construcción de la base de datos. Luego
de tener un diseño concreto de la base de datos, se hará el montaje de la misma en
SQL Server para llevar a cabo de la gestión.
El diseño e implementación de una base de datos distribuida homogénea la idea es
lograr que estas tecnologías sean lo más compatibles posibles, también teniendo
en cuenta software que se pueda obtener sin necesidad de una licencia generando
así un costo no tan elevado teniendo en cuenta que es necesario el uso de otros
materiales para el desarrollo del proyecto.
Siendo así las herramientas que se usarán el proyecto son las siguientes:
• SQL Server
Fuente: https://www.ecured.cu/Microsoft_SQL_Server
Microsoft SQL Server es un sistema de gestión de base de datos relacional,
desarrollado por la empresa Microsoft. El lenguaje de desarrollo utilizado (por
línea de comandos o mediante la interfaz gráfica de Management Studio) es
Transact-SQL (TSQL), una implementación del estándar ANSI del lenguaje
SQL, utilizado para manipular y recuperar datos (DML), crear tablas y definir
relaciones entre ellas (DDL).]
• DB Designer
Fuente: https://www.ecured.cu/DBdesigner
DBDesigner, desarrollado por FabForce, es una aplicación para el diseño
visual de bases de datos. Permite desarrollar una base de datos teniendo en
cuenta el diseño y las funcionalidades independientemente del
servidor/Sistema Gestor de Bases de Datos que se utilizará.
DBDesigner se compara con productos de diseño de Base de Datos como
Rational Rose y ERwin. Es un proyecto Open Source disponible para
Microsoft Windows NT/XP/Vista/7 y Linux KDE/Gnome. Es distribuido con
licencia GPL.
Es capaz de trabajar con MySQL, Oracle, MSSQL y cualquier ODBC, por
lo que se puede utilizar con casi todas las bases de datos existentes.
2.2.2. Diseño de la base de datos
Es importante antes de crear una base de datos distribuida planear su
distribución por medio de un diseño, este nos facilitara el acceso a la información
y tener buenas transacciones al momento de las consultas.
El problema de diseño de bases de datos distribuidos se refiere, en general, a
hacer decisiones acerca de la ubicación de datos y programas a través de los
diferentes sitios de una red de computadoras. 8
Al distribuir programas se involucran dos cosas:
• La distribución del SMBD
• La distribución de las aplicaciones que corren en el SMBD.
Cuando se diseña una BDD, todos los esfuerzos se concentran en la adecuada
distribución de los datos eso con el fin de que haya una carga de trabajo
adecuada para cada servidor.
2.2.3. Metodología de diseño de la base de datos distribuida
Para el diseño de la base de dato distribuida se utilizó una metodología
investigativa, es decir estuvo basada en proyectos y artículos relacionados. Esto
con el fin de generar un buen diseño de la base de datos distribuida.
2.2.3.1. Diseño del esquema conceptual y lógico de la base de datos
Según el esquema conceptual visto en el artículo Diseño Conceptual de Bases
de Datos, la unión de todos los datos y sus relaciones forman el llamado
esquema conceptual. 9 Mientras que el esquema físico representa el
almacenamiento de los datos y sus formas de acceso. Se propone tres niveles
de abstracción en las bases de datos, de acuerdo al siguiente esquema:
8 DISEÑO DE BASES DE DATOS DISTRIBUIDA. [Consultado 14 de Julio de 2019] 9 SÁNCHEZ, Jorge. Diseño Conceptual de Bases de Datos. Obtenido de http://www. jorgesanchez. net/bd/disenoBD. pdf, 2004. [Consultado 15 de Julio de 2019]
Figura 5. Esquema Conceptual de Base de datos.
Fuente: http://www. jorgesanchez. net/bd/disenoBD. pdf, 2004.
Esquema externo. Visión de la base de datos que ofrece cada aplicación.
Lógicamente es distinta en cada aplicación. Representan vistas concretas de la
base de datos.
Esquema conceptual. Representación teórica de los datos y de sus relaciones.
Representa la lógica de la base de datos.
Esquema físico. Representa los datos según son almacenados en el medio físico
(en los discos).
Independencia lógica/física
• Independencia física de los datos: Aunque el esquema físico cambie, el
esquema conceptual no debe verse afectado. En la práctica esto significa
que, aunque se añadan o cambien discos u otro hardware, o se modifique el
sistema operativo u otros cambios relacionados con la física de la base de
datos, el esquema conceptual permanece invariable.
• Independencia lógica de los datos: Significa que, aunque se modifique el
esquema conceptual, la vista que poseen las aplicaciones (los esquemas
externos) no serán afectados.
Para realizar un esquema conceptual y modelo lógico entendible conceptual
entendible según el artículo mencionado se deben tener en cuenta los siguientes
aspectos:
1. Identificar las entidades
ENTIDAD DESCRIPCIÓN
Usuario Esta entidad contiene los datos de los usuarios que están registrados en el sistema.
Auto La entidad auto tiene los datos del automóvil que está registrado en el sistema.
Maneja Esta entidad representa la relación entre el usuario y el automóvil.
Opera Se define esta entidad para conocer las operaciones que suceden en el sistema.
Operación La entidad hace referencia al tipo de operación que se realiza en el sistema ya sea una entrada o una salida.
Tipo_usu Representa el tipo de usuario que se puede asignar según corresponda.
Tabla 3. Lista de identidades de la BD
Fuente: Autoría propia
2. Identificar los atributos de las entidades
Figura 6. Identidad usuario.
Fuente: Autoría propia
Figura 7. Identidad auto.
Fuente: Autoría propia
Figura 8. Identidad Maneja
Fuente: Autoría propia
Figura 9.Identidad opera
Fuente: Autoría propia
Figura 10.Identidad Tipo_Usu
Fuente: Autoría propia
Figura 11.Identidad Operación
Fuente: Autoría propia
3. Identificar las relaciones
Figura 12. Relación Usuario-Auto-Maneja.
Fuente: Autoría propia
Figura 13. Relación Usuario, Auto, Operación – Opera
Fuente: Autoría propia
Figura 14. Relación Usuario-Tipo_Usu
Fuente: Autoría propia
4. Plantear modelo E/R y modelo relacional
En esta etapa se diseñará el modelo E/R y el modelo relacional de la base de
datos distribuida homogénea que se implementará en el sistema, partiendo de
haber identificado las identidades y sus respectivas relaciones.
Figura 15. Modelo Relacional
Fuente: Autoría propia
2.2.3.2. Diseño físico de la base de datos
Uno de los objetivos principales del diseño físico es almacenar los datos de
modo eficiente. Para medir la eficiencia hay varios factores que se deben tener
en cuenta:10
- Productividad de transacciones: Optimizar el tiempo de respuesta para el
usuario.
- Analizar las transacciones: Conocer las consultar y transacciones que se
van a ejecutar sobre la base de datos, además de ello tener en cuenta la
frecuencia con que se va a ejecutar.
10MORALES TRIANA, Marelis. Modelo genérico para la generación de esquemas físicos en el diseño de bases de datos distribuidas. 2011. Tesis Doctoral. Universidad Central “Marta Abreu” de Las Villas., Obtenido de: http://dspace.uclv.edu.cu/handle/123456789/9222 [Consultado 17 de Julio de 2019]
- Escoger los índices secundarios: Se puede tener en cuenta varios
aspectos como construir un índice sobre la clave primaria de cada relación
base. No crear índices sobre relaciones pequeñas. Añadir un índice sobre
los atributos que se utilizan para acceder con mucha frecuencia. Añadir
un índice sobre las claves ajenas que se utilicen con frecuencia. Evitar
índices sobre atributos que se modifican a menudo.
- Considerar la introducción de redundancias controladas: Normalizar la
base de datos pensando en que se pueden introducir redundancias de
forma controlada, con objeto de mejorar las prestaciones del sistema.
- Estimar la necesidad de espacio en disco: Tener en cuenta que el
equipamiento debe tener el espacio suficiente en disco para la base de
datos, de acuerdo al SGBD que se vaya a utilizar y el hardware.
- Diseñar los mecanismos de seguridad: Implementar la seguridad
suficiente para la base de datos.
- Diseñar vistas de los usuarios: Diseñar las vistas que el usuario podrá ver,
esto mejora la independencia de los datos.
- Diseñar las reglas de acceso: Asignar los permisos según sea el usuario
o grupo de usuarios para realizar determinadas acciones sobre los objetos
de la base de datos.
- Monitorizar y afinar el sistema: Implementar el esquema físico de la base
datos y observar su comportamiento, si este no es el deseado el esquema
deberá cambiar para intentar satisfacer las necesidades esperadas. Cada
SGDB proporciona herramientas para monitorizar el sistema mientras
está en funcionamiento.
El nivel físico es el nivel más bajo de abstracción, describe que datos son
almacenados realmente en la base de datos y las relaciones que existen
entre los mismos, así como la base de datos completa en términos de su
estructura de diseño. El diseño físico es el proceso de producir la descripción
de la implementación de la base de datos en memoria secundaria:
estructuras de almacenamiento y métodos de acceso que garanticen un
acceso eficiente a los datos. Entre el diseño físico y el diseño lógico hay una
realimentación, ya que alguna de las decisiones que se tomen durante el
diseño físico para mejorar las prestaciones, pueden afectar a la estructura
del esquema lógico.
El propósito del diseño físico es describir cómo se va a implementar
físicamente el esquema lógico. Concretamente en el modelo relacional las
relaciones entre los elementos de datos establecidos en el diseño lógico
deben reflejarse también en el diseño físico; y consiste en: 11
o Obtener un conjunto de relaciones (tablas) y las restricciones que
se deben cumplir sobre ellas.
o Determinar las estructuras de almacenamiento y los métodos de
acceso que se van a utilizar para conseguir unas prestaciones
óptimas.
o Diseñar el modelo de seguridad del sistema
Por fortuna, existen muchos SGBD que son útiles para esta actividad;
entonces solo se necesita establecer el conjunto de especificaciones
requeridas para la creación de la BDD en el SGBD elegido y los elementos
adicionales de configuración de la distribución.
En este caso para creación del esquema físico se utiliza el SGDB SQL
Server, el cual tiene tres métodos de replicación: instantánea, transaccional
y mezcla12. La tercera permite obtener copias diferidas de los datos y es la
de más potencialidades para materializar un diseño distribuido de una BD.
Entre sus características más relevantes están el permitir que varios sitios
funcionen en línea o desconectados de manera autónoma y mezclar más
adelante las modificaciones de datos realizadas en un resultado único y
uniforme.
Esquema físico
A continuación, se presenta el esquema físico que monto en el SGDB en este
caso SQL Server
11 11 MORALES TRIANA, Marelis. Modelo genérico para la generación de esquemas físicos en el diseño de bases de datos distribuidas. 2011. Tesis Doctoral. Universidad Central “Marta Abreu” de Las Villas., Obtenido de: http://dspace.uclv.edu.cu/handle/123456789/9222 [Consultado 17 de Julio de 2019].
Figura 16. Esquema físico
Fuente: Autoría propia
2.2.3.3. Diseño de la fragmentación
En la siguiente figura se puede observar un esquema de cómo funciona la
fragmentación en una base de datos, además de ello la asignación de la misma.
Figura 17. Fragmentación – Asignación
Fuente: http://dspace.espoch.edu.ec/bitstream/123456789/4218/1/20T00018.pdf
Esto sugiere que el diseño de distribución debería realizarse o al menos
considerarse al principio de la fase de diseño lógico. En ese momento, los datos y
las operaciones precisamente se describen y los primeros problemas de la
implementación se consideran.
El problema de la fragmentación se refiere al particionamiento de la información
para distribuir cada parte a los diferentes sitios de la red.
La fragmentación de datos nos permite obtener mejoras debido a: 13
- Eficiencia. Los datos se almacenan dónde van a ser utilizados y así no
existe redundancia.
- Paralelismo: Las transacciones pueden dividirse en subconsultas que
operan con fragmentos.
Existen 3 tipos de fragmentación, Fragmentación horizontal, Fragmentación vertical,
fragmentación mixta, para el caso del proyecto que se está realizando según lo
estudiado y de acuerdo al modelo de la base de datos, se decide hacer una
fragmentación mixta ya que se utilizará tanto fragmentación horizontal y vertical en
la base de datos distribuida.
En algunos casos, la fragmentación horizontal y vertical no es suficiente para
satisfacer los requerimientos de los usuarios de la aplicación. Es posible aplicar
fragmentación horizontal a un fragmento obtenido con fragmentación horizontal a
un fragmento obtenido con fragmentación vertical o viceversa14
Figura 18. Fragmentación Mixta
Fuente: https://revistas.tec.ac.cr/index.php/tec_marcha/article/view/1492/1519
13 Octavio Douglas Aguilar Mallea, BASE DE DATOS DISTRIBUIDAS, Departamento de Informática y Sistemas, Universidad Autónoma “Juan Misael Saracho” Tarija - Bolivia 14 Chinchilla-Arley, R. Fragmentación de datos en bases de datos distribuidas. Revista Tecnología En Marcha, 16(4), pág. 60-67. Recuperado a partir de https://revistas.tec.ac.cr/index.php/tec_marcha/article/view/1492 [Consultado 19 de Julio de 2019].
Para la base dato distribuido se realiza una réplica parcial de la base de datos, ya
que algunos atributos de las tablas no están en las dos bases de datos si no que
solo en una de las tablas de la base de datos.
2.2.3.4. Diseño de la asignación de fragmentos
De acuerdo al trabajo DIRECTRICES DE INTEROPERABILIDAD DE UNA BASE
DE DATOS DISTRIBUIDA PARA LA OPTIMIZACION DE SISTEMAS DE
COMERCIO ELECTRÓNICO (2004), una buena estrategia de asignación permite
mayor disponibilidad, incremento del paralelismo, menor tiempo de recuperación.
Para el caso del proyecto y de acuerdo a lo estudiado se decide hacer una
asignación redundante ya que la replicación como se mencionaba parcialmente
para los fragmentos es parcial, esto disminuye el tiempo de espera, además de que
aumenta su disponibilidad ya que en caso de que un fragmento se aísle por algún
motivo, se puede recurrir a su réplica de otro sitio.
La fragmentación horizontal en la base de datos distribuida diseñada para el
proyecto se asigna de la siguiente manera, explicando que unos registros están en
una base de datos y otros registros en otra base de datos, en este caso solo se
aplica para la tabla Opera que es donde se guardan las acciones del sistema ya sea
una entrada o una salida, esto está distribuido de manera horizontal. La
fragmentación vertical aplicaría para la tabla Usuario en la que se van a distribuir
los campos de la tabla en las dos bases de datos, en este caso dejando los campos
principales en el host y otros en el servidor virtual.
2.3. Definir método de distribución de base de datos
Para la distribución de la base de datos la idea planteada es generar dos servidores
separados que tengan la base de datos. En este caso utilizando un servidor virtual
y uno local.
Objetivos
• Procesamiento local: Para maximizar el procesamiento local de los
datos se debe tener en cuenta el simple principio de colocar los datos tan
cerca como sea posible de las aplicaciones que los utilizan. Se puede
realizar el diseño de la distribución de los datos para maximizar el
procesamiento local agregando el número de referencias locales que le
corresponden a cada fragmentación candidata y de esta forma se
seleccione la mejor solución de ellas.
• Distribución de la carga de trabajo: Esta característica es importante
en los sistemas de cómputo distribuidos. Esta distribución de la carga se
realiza con el fin de tomar ventaja de diferentes características
(potenciales) o utilizaciones de las computadoras de cada sitio y
maximizar el grado de ejecución. Sin embargo, la distribución de la carga
de trabajo puede llegar a afectar de manera negativa el procesamiento
local deseado.
• Costo de almacenamiento y disponibilidad: La distribución de la base
de datos refleja el costo y disponibilidad de almacenamiento en diferentes
sitios. Si es posible se puede tener sitios especializados en la red para el
almacenamiento de datos. El costo de almacenamiento de datos no es
tan relevante si se realiza una comparación con el del CPU, I/O y los
costos de transmisión de aplicaciones.
2.4. Modelo conceptual de organización en red de la base de datos
Figura 19. Red de comunicaciones base de datos distribuida
Fuente: Autoría propia
El concepto de redes que se usa en este caso es el de colección interconectada de
estaciones autónomas. Se dice que dos ordenadores están conectados si estos son
capaces de intercambiar información.15 Al indicar que los ordenadores son
autónomos, se excluye de esta relación a todos los sistemas organizados sobre la
arquitectura cliente/servidor, ya que un sistema constituido por una unidad central
de control y varios clientes no es propiamente una red.
Consultas remotas
Para consultar una base de datos remota, se debe crear un enlace de datos en la
base de datos en la que se origine la consulta. El enlace de Base de Datos
especifica el nombre del servicio que se va utilizar y puede especificar también el
15 Michel Rodríguez Espinosa, Integración de ayudas al diseño de Bases de Datos Distribuidas, Obtenido de: http://dspace.uclv.edu.cu/bitstream/handle/123456789/9463/Tesis%20-%20Michel%20Rodr%c3%adguez%20Espinosa.pdf?sequence=1&isAllowed=y [Consultado 22 de Julio de 2019].
nombre del usuario que se va a conectar a la Base de Datos remota. Cuando se
hace referencia a un enlace de Base de Datos en una instrucción SQL, Oracle abre
una sesión en la Base de Datos remota y ejecuta allí la instrucción SQL. Luego, los
datos son devueltos y la sesión remota permanece abierta durante toda la sesión
del usuario.
Enlaces de bases de datos
Para facilitar las consultas de las aplicaciones a Sistemas de Bases de Datos
Distribuidas, SQL Server usa database link. Un database link defne uno o más
caminos de comunicación de bases de datos de oracle a otras bases de datos. Para
crear un enlace privado de base de datos, se requiere el privilegio de sistema
CREATE DATABASE LINK y para crear un enlace público de base de datos, el
privilegio de sistema CREATE PUBLIC DATABASE LINK. Además se necesita el
privilegio CREATE SESSION en la base de datos remota de SQL Server.
Sintaxis:
CREATE [SHARED][PUBLIC] DATABASE LINK enlace_ BD CONNECT TO
nombre_usuario IDENTIFIED BY contraseña_usuario USING
‘nombre_servicio_bd’;
3. IMPLEMENTACIÓN DE LA BASE DE DATOS DISTRIBUIDA Y
CONFIGURACIÓN DE SERVIDORES
3.1. Preparación y configuración de los servidores para la base de datos
Para este proyecto se hace uso de una máquina física que tendrá el papel de
servidor host o local, en el que se va a almacenar toda la información que sea
primordial para la verificación de usuarios y operaciones adicionales no recurrentes
como consulta de información de usuarios, registro de automóviles o la relación
entre estos dos.
Por otro lado, se hace uso de una máquina virtual, la cual simulará un equipo de
soporte, donde estará la misma base de datos, pero con algunos cambios que harán
que se pueda tener el modelo adecuado de base de datos distribuida.
Más adelante en este documento, se hará la explicación de cómo estarán
organizados los datos y cómo será la estructura que se va a manejar.
En principio, se realiza la instalación de SQL Server en el equipo host y se procede
a configurar los datos de la instancia local, como se muestra a continuación.
Figura 20. Configuración Instancia Local
Fuente: Autoría propia
En este caso la instancia del equipo local es “JULIANC\SQLEXPRESS”, con el
usuario sa y asignando una contraseña. Luego se realiza el montaje de la base de
datos, con las tablas y atributos antes mencionados en el documento.
Se procede a crear la máquina virtual cuyos atributos se muestran a continuación
Figura 21. Creación máquina virtual
Fuente: Autoría propia
Se deben realizar las configuraciones siguientes, para que se utilice una red que
incluya solamente los servidores necesarios. Para ello, VMWare instala
automáticamente un driver de red, el cual debemos solamente configurar.
Como se muestra a continuación, usaremos una VLAN, llamada “VMnet8”
Figura 22. Uso de VLAN para red
Fuente: Autoría propia
Finalmente, se debe configurar una IP fija en el adaptador de red, en cada uno de
los servidores. Este proceso es el mismo en cada equipo, pero con IP diferentes.
En este caso, el servidor remoto tiene la IP 192.168.133.10 y el servidor local la
192.168.133.1, ambas máquinas con la puerta de enlace predeterminada
192.198.133.2.
Figura 23. Configuración de IP fija para VLAN, servidor remoto
Fuente: Autoría propia
En el equipo local, se realiza el mismo proceso, con su IP correspondiente.
Figura 24. Configuración de IP fija para VLAN, servidor remoto
Aquí también se realiza la instalación de SQL Server, y el montaje de la base de
datos, configurando igualmente la instancia que tendrá, que en este caso será
“SOPORTE”. Como en el caso del host, se hará uso del usuario “sa” con la
asignación de una contraseña.
Figura 25. Configuración instancia servidor virtual
Fuente: Autoría propia
Con esto terminado, se procede a realizar la configuración de uno de los elementos
esenciales para poder manejar la base de datos distribuida, y que en el caso de
SQL Server es conocido como “Linked Server”. Aquí, se muestra el proceso para
una de las máquinas, ya que es el mismo para juntas cambiando únicamente el
nombre de la instancia al que tendrá el servidor asociado.
Figura 26. Creación Linked Server
Fuente: Autoría propia
Luego, hay que configurar dos elementos importantes en el formulario. El campo
“linked server”, en donde se indica el nombre de la instancia a la que se va a
conectar (SOPORTE en este caso), y se debe especificar que es un servidor SQL.
Éste último paso es muy importante, ya que garantiza que la manera de conectarse
entre un servidor y otro sea a través de las credenciales del mismo gestor de bases
de datos, lo cual hará que no haya que lidiar con problemas relacionados
directamente con el sistema operativo Windows.
Figura 27. Configuración Linked Server
Fuente: Autoría propia
La última configuración que se realiza, es asignar las credenciales SQL. Éstas
corresponden a las que se usan en el servidor asociado al linked server.
Figura 28. Configuración credencial SQL
Fuente: Autoría propia
Los pasos anteriores deben repetirse de la misma forma en el SQL Server de la
máquina virtual, pero en ese caso reemplazando el campo “linked server” por la
instancia del host (JULIANC). Cabe aclarar que se puede dar el caso en que no se
pueda asociar usando el nombre del servidor asociado, y se debe proceder a poner
en lugar de ello la IP (que se puede consultar abriendo cmd y usando el comando
“ipconfig”).
Con esto habremos terminado con la configuración de los servidores, y el resto se
procede a realizar en el código fuente del software de control de acceso, donde se
definirán las consultas distribuidas y demás interacciones con las bases de datos.
3.2. Montaje de la base de datos en los servidores
La base de datos, en ambos servidores manejará el mismo nombre (SECURITY).
Lo que hará que se diferencien en las consultas, es que para la base de datos del
host se utiliza el prefijo “JULIANC.SECURITY.dbo” y para la máquina virtual sería
“SOPORTE.SECURITY.dbo”.
Habrá cambios que indican el tipo de fragmentación de la base de datos. A
excepción de los siguientes casos, la base de datos es estructuralmente igual en
juntos servidores:
- La tabla “usuario”, contará con dos campos adicionales en el servidor de
la máquina virtual que son cel_u y tipo_u. Dichos campos, no son
primordiales a la hora de realizar la verificación de acceso, por lo tanto,
no es necesario que ocupen espacio en los dos servidores, sino que basta
con que se encuentren alojados en uno de ellos en el momento en el que
se deseen consultar.
- La tabla “opera”, que es la encargada de alojar los datos en el momento
en que se realiza una entrada o salida en el sistema, tendrá sus registros
fraccionados, para que las cargas sean distribuidas. Cuando se registre
una entrada, esos datos irán a la base de datos del host y en el caso del
registro de una salida, los datos irán a la máquina virtual. Cabe aclarar
que en el caso en que cualquiera de estos dos servidores no esté
disponible, todos los registros se harán en el servidor restante.
Hay solamente una operación que no se podrá realizar si no se encuentran los dos
servidores activos, como es el registro de usuarios, ya que se perdería trazabilidad
teniendo en cuenta que las columnas de la tabla “usuario” se encuentran repartidas
en los dos servidores.
4. CONFIGURACIÓN Y VERIFICACIÓN DE LA INTERACCIÓN DEL SISTEMA
CON LA BASE DE DATOS DISTRIBUÍDA
Luego de que los servidores están listos, se deben realizar algunas pruebas
asegurar que el software está interactuando de manera adecuada con el sistema.
4.1. Pruebas de conexión de servidores.
Propósito
Asegurar que hay comunicación entre los dos servidores
Descripción
Ésta es una prueba sencilla inicial para saber si hay conexión entre los dos
servidores, utilizando la ventana de comandos. Para ello, debemos hacer la prueba
a través de las IP de cada servidor JULIANC y SOPORTE.
Resultados
Figura 29. Prueba: ping servidor local a servidor remoto
Fuente: Autoría propia
Figura 30. Prueba: ping servidor remoto a servidor local
Fuente: Autoría propia
4.2. Pruebas de consulta distribuida desde el motor de base de datos de
los servidores
Propósito
Comprobar que la base de datos distribuida ha sido bien implementada y que las
configuraciones fueron correctas para poder realizar consultas distribuidas.
Descripción
En la siguiente imagen, podemos observar que desde el servidor JULIANC, se hace
una consulta que trae la información de la siguiente forma: huella, id, nombres y
apellidos desde el servidor local y el celular y tipo de usuario son traídos desde el
servidor remoto. Lo anterior se hace a través de un JOIN entre la información de las
dos tablas, obteniendo el resultado de la parte inferior, donde en color rojo se rodeó
la información que es traída desde el servidor local y en color verde la que viene
remotamente.
Resultados
Figura 31. Prueba: consulta distribuida desde servidor local al servidor remoto
Fuente: Autoría propia
Luego de realizar la consulta anterior, se procede a realizar la misma prueba desde
el servidor remoto al servidor local. En este caso, cambiaría el nombre del servidor.
Figura 32. Prueba: consulta distribuida desde servidor remoto al servidor local
Fuente: Autoría propia
4.3. Prueba de consulta desde el sistema de control de acceso
Propósito
Comprobar que el sistema de control se conecta correctamente con la base de datos
distribuida y que se puede hacer una consulta distribuida desde el mismo.
Descripción
Para el manejo de la conexión del sistema con la base de datos, se usa una clase
global que maneja las conexiones con los servidores llamada “GlobalBD”. Allí, están
las dos cadenas de conexión que se usarán por todos los módulos del software.
Figura 33. Cadenas de conexión
Fuente: Autoría propia
Además, hay dos funciones que son llamadas una única vez por la ventana principal
en condiciones normales, que son las que inician la conexión con la base de datos.
En caso de que un servidor caiga, el sistema continuará trabajando normalmente,
hasta el momento en que el otro servidor tenga la capacidad de responder. Por lo
tanto, las pruebas de conexión se realizan solamente desde la ventana
“MainWindow.xaml”.
Figura 34. Conexiones con los servidores
Fuente: Autoría propia
Luego de establecido el código de conexión con la base de datos, se procede a
realizar una consulta de prueba. Esta vez, la consulta será para realizar un informe
dentro del software, con las entradas y salidas registradas. Dicho informe,
comprueba la conexión que exista entre el software y la base de datos, debido a
que los registros de entradas son traídos del servidor local y los de salida del
servidor remoto. (también puede darse el caso, en que haya registros de entrada en
el servidor remoto y de salida en el local, ya que, si uno de los servidores falla, el
registro se hace en el restante).
Resultados
Figura 35. Prueba: Informe de entradas y salidas desde el sistema de control
Fuente: Autoría propia
Aquí entonces, la conexión con la base de datos en los dos servidores está
comprobada, además de ser transparente para el usuario la localización de la
información. Los registros que indican “entrada” se traen del servidor JULIANC y los
registros que indican “salida” vienen del servidor SOPORTE.
4.4 Pruebas de disponibilidad del sistema
Propósito
Asegurar que se cumple el objetivo más importante del proyecto, que es la
disponibilidad para realizar operaciones de entrada y salida
Descripción
Ya que el objetivo principal del proyecto fue planteado como lograr una alta
disponibilidad del sistema de control a continuación se realiza una prueba simulando
la caída de uno de los servidores.
Como ya se ha explicado antes en el documento, el módulo de entrada y salida de
usuarios es el que requiere que el sistema tenga una alta disponibilidad, fue por ello
que se hizo fragmentación horizontal. También, se ha explicado que los registros de
entrada se envían al servidor “JULIANC” y los de salida al servidor “SOPORTE”.
En la siguiente prueba, se apaga el servidor SOPORTE, simulando una caída.
Luego de ello se hace una operación de salida y se comprueba que dicho registro
se envíe a la base de datos en el servidor “JULIANC”. Con ésta
Resultados
Figura 36. Prueba: Simulación de caída del servidor de salida a las 20:06hrs.
Fuente: Autoría propia
Figura 37. Registro de salida a las 20:21hrs., luego de caída del servidor.
Fuente: Autoría propia
Figura 38. Comprobación de que la operación fue exitosa y su registro quedó en el servidor de entrada.
Fuente: Autoría propia
4.5 Prueba de fragmentación de la base de datos distribuida
Propósito
Comprobar que la fragmentación realizada es correcta y está implementada
correctamente.
Descripción
Anteriormente ya se ha comprobado que los registros de entrada y salida (que son
guardados en la tabla “opera”, en la que se aplicó fragmentación horizontal), se
guardan de manera adecuada. Para la siguiente prueba entonces, se hará el
registro de un usuario para comprobar que los datos se están guardando de manera
correcta a través de una inserción distribuida para la tabla usuario.
Resultados
Figura 39. Creación de usuario desde el sistema.
Fuente: Autoría propia
Figura 40. Comprobación de registro en la base de datos distribuida.
Fuente: Autoría propia
5. VERIFICACIÓN DE CONSULTAS A LA BASE DE DATOS Y
RETROALIMENTACIÓN DEL SISTEMA
5.1. Verificación de consultas a la base de datos desde el sistema
Las solicitudes al sistema, se realizan desde los diferentes módulos del aplicativo,
y pueden ser de tipo común (las que requieren de uno de los dos servidores), o
distribuidas (en casos como el registro de usuarios o la entrada/salida de vehículos
o los informes de entradas y salidas). Para el usuario, todas estas transacciones
son totalmente transparentes.
Aquí se muestra una consulta común a la base de datos
Figura 41. Ejemplo Consulta: Selección de todos los datos de usuarios.
Fuente: Autoría propia
Ésta consulta trae de la base de datos local los datos de todos los usuarios, para
luego mostrar al usuario la información de un usuario específico.
Por otro lado, están las consultas distribuidas, para las que se muestran dos
ejemplos a continuación.
Figura 42. Ejemplo Consulta distribuida: Informe de entradas y Salidas.
Fuente: Autoría propia
En este caso, se hace una consulta que une los registros fraccionados de los dos
servidores en cuanto a las entradas/salidas del sistema, para mostrar un informe
unificado de nuevo, sin que el usuario note de dónde viene la información. Para ver
el resultado de esta consulta en el sistema, remitirse a la Figura 28.
Figura 43. Inserciones distribuidas: Entrada de Usuarios.
Fuente: Autoría propia
Como ejemplo final, aquí se muestra cómo se registra una entrada en el servidor
host como tiene asignado, pero en el caso en que el registro falle, se procede a
registrar en el otro servidor. Con esto, se asegura el correcto y constante
funcionamiento del sistema, y que se conserve además trazabilidad de los
movimientos en caso de requerir informes.
5.2. Retroalimentación
Teniendo en cuenta los requisitos iniciales, la base de datos distribuida cumple con
los objetivos planteados y requisitos de operación. A pesar de ello, se hicieron
algunas modificaciones para aportar a que el sistema fuese más efectivo a la hora
de cumplir con la verificación de usuarios.
Una de las modificaciones más destacada se realizó en las tablas “opera” y
“maneja”. En principio dichas tablas contaban con el campo “huella”, el cual ocupaba
almacenamiento de manera innecesaria, por lo tanto, se quitó de dichas tablas y su
relación se hizo por el campo “id_u”, para evitar la redundancia y ocupar espacio
innecesario en los servidores, además de permitir consultas más efectivas y con
menos probabilidad de fallo en dichas tablas.
CONCLUSIONES
- El uso de base de datos distribuidos, permite dividir las consultas para ser
realizadas a una mayor velocidad por distintas máquinas o procesadores,
incrementando enormemente el rendimiento del sistema de base de
datos.
- Es primordial conocer los requisitos del sistema al cual se implementa una
base de datos distribuida, con el fin de establecer los parámetros más
adecuados apuntando a suplir las necesidades más importantes del
sistema, y así lograr un sistema lo más óptimo posible.
- Emplear una base de datos homogénea, es una gran ventaja, ya que, al
utilizar el mismo sistema gestor de base de datos en ambos servidores,
la configuración se simplifica, y hay más opciones de compatibilidad que
minimizan el esfuerzo en la interacción entre los equipos.
- Las bases de datos distribuidas, son adaptables a las posibles
modificaciones del sistema, y específicamente las de tipo homogéneo,
son flexibles y su implementación es eficiente.
- En el caso de realzar la implementación de los servidores de manera
completamente física, el uso de servidores virtuales, como en el presente
proyecto, es una herramienta muy útil a la hora de realizar pruebas
previas de rendimiento para posteriormente hacer una inversión
adecuada en equipos.
- Es importante realizar pruebas que permitan evidenciar si hay que realizar
cambios en el sistema en cualquiera de sus aspectos.
RECOMENDACIONES
- Es recomendable cambiar de un sistema centralizado a un sistema
distribuido realizando una fragmentación adecuada para aumentar su
disponibilidad.
- El tipo de fragmentación de la base de datos ya depende como tal del
análisis realizado y que tanto se desee fragmentar.
- Si una base de datos es demasiado grande, se debe hacer un rediseño
de base de datos centralizada, para que esta sea una base de datos
distribuida ya que se pueden almacenar los datos en localidades donde
son utilizados con mayor frecuencia, de tal manera que la mayor parte de
las operaciones sean sólo locales lo cual reduce el tráfico en la red.
BIBLIOGRAFÍA
• Chaffo Aguilar, G., Mariños Urquiaga, J. (2016). Modelado de un sistema
distribuido para la gestión de consultas en las bibliotecas de la Universidad
Nacional de Trujillo. [En línea] Dspace.unitru.edu.pe. Disponible en:
http://dspace.unitru.edu.pe/handle/UNITRU/10264
• Acosta, F., Díaz García, A. (2017). Sistema Telemático Basado en Servicios
Web, Georreferenciación y Bases de Datos Distribuidas para Gestionar la
Información del Departamento de Ventas de una Organización Dedicada al
Comercio de Materiales para la Construcción. [En línea] Hdl.handle.net.
Disponible en: http://hdl.handle.net/11349/5890
• Valentin Alvarez Hilario., Rene E. Cuevas Valencia., José Mario Martinez
Castro. (2013). IMPLEMENTACIÓN DE TRANSACCIONES DISTRIBUIDAS
USANDO AGENTES INTELIGENTES Revista vínculos. [En línea]
Disponible en:
https://revistas.udistrital.edu.co/ojs/index.php/vinculos/article/view/4178
• Reyes, L. and REYES, L. (1999). Automatización del diseño de la
fragmentación vertical y ubicación en bases de datos distribuidas usando
métodos heurísticos y exactos. [En línea] Repositorio.itesm.mx. Disponible
en: https://repositorio.itesm.mx/handle/11285/628439
• Enrique García Salcines, Cristóbal Romero Morales, Sebastián Ventura Soto
y Carlos Castro Lozano (2008).
Sistema_recomendador_colaborativo_usando_mineria_de_datos_distribuid
a_para_la_mejora_continua_de_cursos_e-learning. [En línea] Disponible en:
https://www.researchgate.net/publication/220139246_Sistema_recomendad
or_colaborativo_usando_mineria_de_datos_distribuida_para_la_mejora_co
ntinua_de_cursos_e-learning
• Payá, Luis, Reinoso, Oscar, Gil, Arturo, & Jiménez, Luis M. (2007).
Plataforma Distribuida para la Realización de Prácticas de Robótica Móvil a
través de Internet. Información tecnológica, 18(6), 27-38.
https://dx.doi.org/10.4067/S0718-07642007000600005
• Paderni López, M., León, I., Cabrera Hernández, M. and Delgado Ramos, A.
(2014). Bases de datos distribuidas para aplicaciones médicas en el Sistema
Nacional de Salud. [En línea] Medigraphic.com. Disponible en:
https://www.medigraphic.com/cgi-
bin/new/resumen.cgi?IDARTICULO=54446
• Ana C. Muñoz G., Jose Aguilar., Rodrigo Martínez (2005). MODELO
INTELIGENTE PARA BASES DE DATOS DISTRIBUIDAS [En línea]
Disponible en:
https://revistas.uis.edu.co/index.php/revistagti/article/view/1562
• RODRIGUEZ MORFFI, Abel; GARCIA GONZALEZ, Carlos Ernesto;
LEMAHIEU, Wilfried and GONZALEZ GONZALEZ, Luisa Manuela (2009).
SIADBDD: An integrated tool to design distributed databases.
Rev.fac.ing.univ. Antioquia [En línea], n.47. Disponible en:
http://www.scielo.org.co/scielo.php?
• NAVAS, Francisco Corbera; GALLEGO, Alejandro Delgado (2008). BASE DE
DATOS DISTRIBUIDAS [En línea] Disponible en:
http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/BE/AM/05/Modelos_ava
nzados_de_bd.pdf
• CESAR MANUEL CASTILLO RODRÍGUEZ, RICARDO ALONSO HURTADO
MOSQUERA (2014). BASES DE DATOS DISTRIBUIDAS [En línea]
Disponible en:
http://froac.manizales.unal.edu.co/roap/scorm/472/12_qu_es_computacin_d
istribuida.html
• DÍAZ, MC ALEJANDRO GUTIÉRREZ. Bases de Datos. Centro Cultural Itaca
SC, 2015. [En línea] Disponible en:
https://www.aiu.edu/cursos/base%20de%20datos/pdf%20leccion%201/lecci
%C3%B3n%201.pdf
• Diseño de Bases de datos Distribuida (Texto Base) (2005). [En línea]
Disponible en:
https://lihectortorres.files.wordpress.com/2010/09/base_de_datos_distribuid
as.pdf
• MARTÍNEZ MARTÍN, Laura. Diseño y construcción de bases de datos
distribuidas heterogéneas sobre Oracle y SQL Server. 2010. [En línea]
Disponible en: http://hdl.handle.net/10016/11238
• ALEJANDRO GUTIÉRREZ DÍAZ, BASES DE DATOS DISTRIBUIDAS
(2010). [En línea] Disponible en:
http://cursos.aiu.edu/Base%20de%20Datos%20Distribuidas/pdf/Tema%202
• GONZÁLEZ URÍAS DAMIÁN, LÓPEZ ANGUIANO JOSÉ EVERARDO,
RIVERA JR. MONZÓN ROBERTO, SAINZ SANDOVAL ARANZA KARINA
(2015). BASES DE DATOS DISTRIBUIDAS [En línea] Disponible en:
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbW
FpbnwyMDE1MDhiZGRnb256YWxlemRhbWlhbnxneDo2OGFjNmIyOTg4N
GJhYjIz
• Montes de Oca Olguín Antonio de Jesús, Diseño de bases de datos
distribuidas [En línea] Disponible en:
https://tododistribuido.files.wordpress.com/2008/10/disdabe_design.pdf
• DAVID ANTONIO FRANCO BORRE YASMIN MOYA VILLA, SEGURIDAD
EN BASES DE DATOS DISTRIBUIDAS UTILIZANDO AGENTES MÓVILES
(2005). [En línea] Disponible en:
https://biblioteca.utb.edu.co/notas/tesis/0030676.pdf
• Luis Roberto Oñate Llerena, Marco Fabián Guangashi Guangasi, DISEÑO
DE BASES DE DATOS DISTRIBUIDAS EMPLEANDO LA ARQUITECTURA
DE REPLICACION ORACLE (2005). [En línea] Disponible en:
http://repositorio.uta.edu.ec/jspui/handle/123456789/344
• ELIZONDO, Arturo Jaime; PÉREZ, César Domínguez. Trabajando en el
laboratorio el diseño físico de bases de datos y la optimización de consultas.
[En línea] Disponible en:
http://bioinfo.uib.es/~joemiro/aenui/procJenui/Jen2008/p351_AJaime.pdf
• SÁNCHEZ, Jorge. (2004). Diseño Conceptual de Bases de Datos. [En línea]
Disponible en: http://www. jorgesanchez. net/bd/disenoBD. pdf,
• Morales Triana, M. (2011). Modelo genérico para la generación de esquemas
físicos en el diseño de bases de datos distribuidas (Doctoral dissertation,
Universidad Central “Marta Abreu” de Las Villas). [En línea] Disponible en:
http://dspace.uclv.edu.cu/handle/123456789/9222
• Díaz, Y., & Vinicio, M. (2004). Directrices de Interoperabilidad de una Base
de Datos Distribuida para la Optimización de Sistemas de Comercio
Electrónico (Master's thesis, Escuela Superior Politécnica de Chimborazo).
[En línea] Disponible en:
http://dspace.espoch.edu.ec/handle/123456789/4218
• Mallea, O. D. A. BASE DE DATOS DISTRIBUIDAS. [En línea] Disponible en:
http://www.uajms.edu.bo/revistas/wp-content/uploads/2016/06/bitabit-
art5.pdf
• Rodríguez Espinosa, M. (2009). Integración de ayudas al diseño de bases de
datos distribuidas (Doctoral dissertation, Universidad Central “Marta Abreu”
de Las Villas). [En línea] Disponible en:
http://dspace.uclv.edu.cu/bitstream/handle/123456789/9463/Tesis%20-
%20Michel%20Rodr%c3%adguez%20Espinosa.pdf?sequence=1&isAllowe
d=y