DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS …

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


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


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


2. Identificar los atributos de las entidades

Figura 6. Identidad usuario.


Figura 7. Identidad auto.


Figura 8. Identidad Maneja


Figura 9.Identidad opera


Figura 10.Identidad Tipo_Usu


Figura 11.Identidad Operación


3. Identificar las relaciones

Figura 12. Relación Usuario-Auto-Maneja.


Figura 13. Relación Usuario, Auto, Operación – Opera


Figura 14. Relación Usuario-Tipo_Usu


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


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]

http://dspace.uclv.edu.cu/handle/123456789/9222

- 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


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


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].

http://dspace.uclv.edu.cu/bitstream/handle/123456789/9463/Tesis%20-%20Michel%20Rodr%c3%adguez%20Espinosa.pdf?sequence=1&isAllowed=y

http://dspace.uclv.edu.cu/bitstream/handle/123456789/9463/Tesis%20-%20Michel%20Rodr%c3%adguez%20Espinosa.pdf?sequence=1&isAllowed=y

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


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


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


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


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


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


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


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


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


Figura 30. Prueba: ping servidor remoto a servidor local


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


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


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


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


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


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.


Figura 37. Registro de salida a las 20:21hrs., luego de caída del servidor.


Figura 38. Comprobación de que la operación fue exitosa y su registro quedó en el servidor de entrada.


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.


Figura 40. Comprobación de registro en la base de datos distribuida.


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.


É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.


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.


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

.pdf

• 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

DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS …

Documents

Transcript of DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE DATOS …