Download IGUDES, MTD

INSTITUTO POLITECNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA
DE INGENIERÍA Y CIENCIAS SOCIALES
Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
MAESTRIA EN CIENCIAS CON ESPECIALIDAD EN INFORMÁTICA
IGUDES, MTD (Manipulación y Transferencia de Datos)
T
E
S
I
S
QUE PARA
OBTENER
EL GRADO
DE:
M A E S T R O E N C I E N C I A S C O N
ESPECIALIDAD EN INFORMÁTICA
P
R
E
S
E
N
T
A:
YRAN
JOAN
ARVIZU ESPINOSA
DIRECTOR: DR. MAURICIO PROCEL MORENO
MÉXICO, D.F.
2013
Página 1 de 190
Página 2 de 190
Página 3 de 190
Dedicatoria.
Este trabajo de tesis está dedicado a Sandra Guadalupe Espinosa Rodriguez, Rodolfo Arvizu Moreno, Jaqueline
Grisell Arvizu Espinosa y Diana Chávez García. Gracias por la inspiración y el apoyo que han brindado.
Agradecimientos.
A mi madre Sandra Guadalupe, que inyecto en mi el desdén al fracaso el hambre de triunfo, por enseñarme que se
puede ser tan grande como la mente te deje ser y transformarme de un soñador en un forjador de realidades, pero
más que nada por su infinita bondad y amor.
A mi padre Rodolfo, quien ha orientado mi camino y soportado mis decisiones e indecisiones, por su apoyo
incondicional, por su fortaleza, dignidad y por enseñarme que no solo se es ganador por haber visto tantas veces
la derrota si no por aprender a luchar y no temer al triunfo.
A mi hermana Jaqueline, Por haberme apoyado en todo momento, por sus valiosos consejos, por ser una amiga
incondicional y una triunfadora.
A Diana Chávez, quien ha impulsado mi lado científico y humanista, que ha convivido y descifrado mi estado
mental, por su magnífica fusión del lado Emocional con el Racional que da equilibrio y luz a mi ser.
A mis Familiares y Amigos. De los que he aprendido e imitado para acumular en mí una grata fusión de cualidades
y gustos, forjados por vivencias, triunfos, fracasos y sueños materializados o no materializados.
A mis maestros.Dr. Mauricio Procel, Dr. Javier García, M.C. Abel Bueno, Dr. Eduardo Gutiérrez, Dr. Fernando
Vázquez y todos mis profesores por su gran apoyo, motivación, conocimientos, experiencias y tiempo para la
culminación de mi maestría y para la elaboración de esta tesis.
Al Instituto Politécnico Nacional. Por creer en mí y brindarme la oportunidad de enriquecer mí persona.
A Dios.Por haberme permitido llegar hasta este punto, haberme dado salud para lograr mis objetivos y enseñarme
el poder de la fe.
Atrévete a visualizarte en el éxito. Hay quienes piensan
que tienen un deja vu cuando lo logran, pero no es más
que la materialización del triunfo que imaginaron.
Yran Joan Arvizu Espinosa.
Página 4 de 190
Resumen
La Interfaz Gráfica de Usuario de Sistemas Manejadores de Base de Datos descrito como IGUDES en
adelante, fue concebido como un sistema de integración de datos cuyo objetivo primordial es permitir al usuario
olvidarse de enlaces, configuraciones y dominar diversas y complejas herramientas para explotar la
información de su interés. IGUDES está diseñada como una herramienta que facilite las actividades del día a
día en las organizaciones.
Mediante IGUDES el usuario podrá crear y ejecutar consultas de información centralizada o distribuida
mediante una o varias sentencias DML (Lenguaje de Manipulación de Datos) por medio de un script, permitiendo
generar reportes integrales ejecutivos apoyando al nivel estratégico en la toma de decisiones, disminuirá los
tiempos de respuesta de consulta a bases de datos heterogéneas ya que no se requiere trasladar los datos de la
base remota a la local, evitará gastos de licencia por ser software libre, al ser un aplicación web eliminará la
necesidad de instalación en la terminal de trabajo, reducirá la cantidad requerida de espacio en disco duro,
disminuirá los costos, permitirá mejor administración al ser una arquitectura centralizada ya que se tiene
completo control de la administración de recursos porque únicamente los administradores controlan el servicio
y acceso, favorecerá el alto rendimiento de la terminal que lo utiliza por demandar muy poco al procesador y
tener un consumo mínimo de memoria RAM debido a que en la terminal del usuario solo se presentan
resultados no se procesa información, evitará que se tenga abierta distintas herramientas de explotación de
datos para cada SGBD ya que mediante la misma aplicación se puede acceder a todas las bases de datos que
permitan conexión mediante JDBC para las cuales previamente se haya configurado una conexión, podrá ser
usada sobre cualquier sistema operativo que permita ejecutar un navegador web sin restringir su ejecución a
ciertas arquitecturas ya que funciona en terminales de 32 y 64 bits.
Es importante comentar que IGUDES está pensado para usuarios intermedios, es decir, aquellos usuarios que no
son especialistas en el desarrollo de aplicaciones de base de datos y que tampoco tienen conocimientos técnicos
sobre la administración de un SMBD pero que requieren conocer la información almacenada en sus bases de datos
para proporcionar continuidad del negocio, y con tan solo un nivel básico de conocimiento en el lenguaje SQL
pueden explotar la información.
En la actualidad no existe una herramienta comercial que permita acceder mediante un navegador web a
una aplicación con fuerte control de acceso cuya función primordial sea consultar distintas bases de datos
simultáneamente en una arquitectura centralizada o distribuida, por ello se considera a IGUDES innovadora
ya que no hay una aplicación con las mismas características que permita realizar las tareas que ejecuta
IGUDES, debido a que fue diseñada en base a la integración de diversas tecnologías y concebida para satisfacer a
necesidades puntuales de alta demanda, si bien hay herramientas web o de licencia libre que manipulan sistemas
manejadores de base de datos estas únicamente se enfocan a una sola base de datos, o simplemente difieren en
las características que IGUDES provee.
Página 5 de 190
ABSTRACT
The Graphical Systems Managers Database Interface hereinafter described as IGUDES was conceived as a data
integration system whose primary objective is allow the user forgetting links, configurations and master various
complex tools to exploitinterest information. IGUDES is designed as a tool to facilitate the activities of everyday in
organizations.
By IGUDES, the user can create and execute queries in centralized or distributed information by one or more DML
(Data Manipulation Language) via a script, allowing generate comprehensive and executives reports supporting the
strategic level decision making, decrease Query response times to heterogeneous databases and is not required to
transfer data from local base to remote base, costs avoided being free software license, being a web application will
eliminate the need for installation on workstation will reduce the required amount of disk space, reduce costs,
enable better management to be a centralized architecture as it has complete control of resource management
because only administrators control access service and will favor the high performance terminal that uses very little
demand for the processor and have a minimum RAM consumption because the user terminal only present results do
not process information, prevent different data mining tools for each DBMS are open, because using the same
application can access all databases that allow for connection using JDBC which has been previously configured a
connection, can be used on any operating system that allows a web browser to run without restricting certain
architectures and implementation running on terminals 32 and 64 bits.
It is important to note that IGUDES is designed for intermediate users, ie, users who are not specialists in the
development of database applications and also have expertise in the management of a DBMS but need to know the
information stored in its databases to provide business continuity, and with only a basic level of knowledge in the
SQL language can exploit the information.
At present there is no commercial tool that allows access through a web browser to an application with strong
access control whose primary function is to consult multiple databases simultaneously in a centralized or distributed
architecture.
Therefore, considers IGUDES as an innovative tool since no application with the same features that allows running
the same IGUDES tasks, because it was designed based on the integration of various technologies and designed to
meet specific needs of high demand, while there are web tools free license or systems that manipulate database
managers this only focus to a single database, or simply differ in characteristics that IGUDES provides.
Página 6 de 190
ÍNDICE
INTRODUCCIÓN
OBJETIVO
1. CAPITULO I. MARCO TEORICO
10
11
12
1.1. Introducción
1.2. Bases de Datos y Sistemas Manejadores de Bases de Datos
1.2.1. Bases de Datos
1.2.2. Sistemas Manejadores de Bases de Datos
1.2.2.1. Estructura de un SMBD
1.2.3. Aplicaciones de los Sistemas de Bases de Datos
1.2.4. Abstracción de Datos
1.2.5. Modelos de Datos
1.2.5.1. Modelo Entidad – Relación
1.2.5.2. Modelo Relacional
1.2.6. Lenguajes de Bases de Datos
1.2.6.1. Lenguajes Estructurado de Consultas SQL
1.2.6.2. Lenguaje de Definición de Datos DDL
1.2.6.3. Lenguaje de Manipulación de Datos DML
1.2.7. Mejores Prácticas de SQL
1.2.7.1. Secuencia para nombrar tablas
1.2.7.2. Posición de JOIN en la Cláusula WHERE
1.2.7.3. Evitar uso del comodín *
1.2.7.4. Expresión de agregación COUNT
1.2.7.5. Discriminación de información a través de la cláusula WHERE en lugar de HAVING
1.2.7.6. Discriminación de información a través del comando EXISTS en lugar de IN
1.2.7.7. Utilizar IN en lugar de múltiples OR en un listado estático
1.3. Sistemas de Bases de Datos Distribuidas
1.3.1. Paradigma del Modelo Computacional
1.3.2. Alternativas para la entrega de datos
1.3.3. Ventajas de los DDBS
1.3.3.1. Gestión transparente de los datos distribuidos y duplicados
1.3.3.2. Acceso fiable a los datos a través de transacciones distribuidas
1.3.3.3. Mejora en el rendimiento
1.3.3.4. Escalabilidad
1.3.4. Las Complicaciones del paradigma de la Distribución
1.3.5. Arquitecturas de DBMS Distribuidos
1.3.5.1. Modelos Arquitectónicos para DBMS Distribuidos
1.3.6. Integración de Bases de Datos
1.3.6.1. Metodología de Diseño de Abajo hacia Arriba
1.4. Aplicaciones Web
1.4.1. Antecedente
1.4.2. World Wide Web (www)
1.4.3. HTML (Lenguaje de Marcas de Hipertexto)
1.4.4. HTTP (Protocolo de Transferencia de Hipertexto)
1.4.5. Arquitectura Web
1.4.5.1. Modelo Vista Controlador (MVC)
1.5. Tecnologías
1.5.1. Java y Java Enterprise Edition (J2EE)
1.5.1.1. JDBC
1.5.1.2. Servlets
1.5.1.3. Java Server Pages (JSP)
1.5.1.4. Diferencias entre un servlet y un JSP
1.5.2. JavaScript
1.5.3. DAO (Data Access Object)
1.5.4. Patrón de Diseño
1.6. ODBC
1.7. JDBC versus ODBC
1.8. OLE DB.
12
12
12
12
12
13
13
14
15
19
20
20
20
21
22
22
22
22
23
23
23
24
24
24
25
26
26
27
28
28
28
29
29
34
35
38
38
39
39
39
40
40
42
42
42
44
46
46
46
46
47
48
50
50
2. CAPITULO II. VENTAJAS, COMPARACIÓN Y ARQUITECTURA DE IGUDES.
52
Página 7 de 190
2.1. El objetivo de IGUDES
2.2. Ventajas de IGUDES
2.3. IGUDES vs Competidores.
2.3.1. IGUDES vs Consola de Administración Oracle XE 10g.
2.3.2. IGUDES vs Consola de Administración phpMyAdmin.
2.3.3. IGUDES vs Sql Server Management Studio.
2.3.4. IGUDES vs ETL Informatica Power Center.
2.3.5. IGUDES vs Personalcommunications DB2.
2.3.6. IGUDES vs Toad.
2.3.7. Evaluación de Ventajas de IGUDES MTD vs Competidores.
2.4. Arquitectura de IGUDES.
2.4.1. Arquitectura Cliente-Servidor.
2.4.2. Funcionalidad de la Arquitectura Cliente-Servidor C/S.
2.4.3. Razones que justifican el uso de la arquitectura Cliente/Servidor en bases de datos.
2.4.4. La consulta SQL del usuario admite dos formas de invocación diferentes.
2.4.5. Arquitecturas Web.
2.4.6. Servidor Web: URLs y Protocolo HTTP.
2.4.7. Funciones del Servidor de Aplicaciones.
2.4.8. Consultas a Datos heterogéneos en la Web.
2.4.9. Arquitectura Mediador-Wrapper.
2.4.10. Arquitectura Mediador-Wrapper en la Web de IGUDES.
52
52
53
53
55
58
60
64
67
69
72
72
72
72
72
73
74
75
75
75
77
3. CAPITULO III. DESARROLLO E IMPLEMENATCIÓN DE LA SOLUCIÓN
78
3.1.1. Descripción del Aplicativo.
3.1.2. Procedimientos Almacenados.
3.1.3. Descripción del flujo de IGUDES MTD.
3.2. Funcionalidad de los módulos de IGUDES
3.2.1. Funciones de Administrador.
3.2.1.1. Agregar Usuario a IGUDES.
3.2.1.2. Crear una nueva conexión de base de datos.
3.2.1.3. Asignación de Base de Datos por usuario.
3.2.1.4. Asignar privilegio (perfil) a usuario.
3.2.1.5. Determinar Vigencia de la cuenta.
3.2.1.6. Activar o Desactivar cuenta de Usuario.
3.2.1.7. Administrar Log de Acceso.
3.2.1.8. Administrar Log de consultas.
3.2.1.9. Cambio de contraseña.
3.2.2. Funciones de Usuario
3.2.2.1. Acceso a IGUDES.
3.2.2.2. Renovación de Contraseña.
3.2.2.3. Uso de Menú IGUDES.
3.3. Consultas Simple (sobre un SMBD).
3.4. Consultas Múltiples.
3.5. Consultas Distribuida.
3.6. Tecnologías Usadas.
3.6.1. Conexión Oracle a Oracle.
3.6.2. Conexión Oracle a Sql Server.
3.6.3. Conexión Oracle a MySql.
3.6.4. Conexión Sql Server a Sql Server
3.6.5. Conexión Sql Server a Oracle.
3.6.6. Conexión Sql Server a MySql.
3.6.7. Conexión MySql a MySql.
78
83
84
91
92
92
93
95
95
97
99
101
102
103
104
104
105
108
108
110
114
116
117
120
128
133
136
139
144
4. CAPITULO IV. EVALUACIÓN DE LA SOLUCIÓN
147
4.1.1. Consultas a la base de datos de Administración Oracle Express.
4.1.2. Consultas a la base de datos Oracle 11g ORCL.
4.2. Consulta Distribuida entre SMBD Homogéneos Oracle.
4.3. Consulta Distribuida entre SMBD Heterogéneos Oracle  SQL-SERVER.
4.4. Consulta Distribuida entre SMBD Heterogéneos Oracle  MySQL.
4.5. Consultas al Sistema Manejador de Base de Datos SQL-SERVER.
4.6. Consulta Distribuida entre SMBD Homogéneos SQL-SERVER.
4.7. Consulta Distribuida entre SMBD Heterogéneos SQL-SERVER  ORACLE.
4.8. Consulta Distribuida entre SMBD Heterogéneos SQL SERVER  MySQL.
4.9. Consultas al Sistema Manejador de Base de Datos MySQL.
147
150
151
154
156
157
159
159
161
163
Página 8 de 190
4.10. Consulta Distribuida entre SMBD Homogéneos MySQL.
4.11. Consulta Distribuida, Join entre tres Sistemas Manejadores de Bases de Datos Distintos
MYSQLSQL SERVERORACLE.
4.12. Consultas Múltiples al SMBD ORACLE.
4.13. Consultas Múltiples sobre SQL y Consulta Distribuida desde el módulo de Consultas Múltiples.
4.14. Trabajo con vistas desde IGUDES.
4.15. Pruebas de Desempeño.
4.14. Hallazgos.
163
164
CONCLUSIONES
GLOSARIO
BIBLIOGRAFÍA
185
186
189
Página 9 de 190
165
173
179
181
184
INTRODUCCIÓN
En la actualidad el complejo y creciente número de datos que una persona o entidad requiere tener a su
alcance es un elemento primordial para obtener beneficios, tomar decisiones y adquirir conocimiento. Por
ello una actividad como esta demanda un correcto manejo de la información, un sofisticado nivel de
administración, un alto grado de disponibilidad y un correcto tiempo de respuesta, elementos que dieron
origen al término base de datos, descrito como un conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemáticamente para su posterior uso. En este sentido, y a manera de ejemplo, una biblioteca puede
considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados
para su consulta, aunque actualmente y debido al desarrollo tecnológico de campos como la informática y la
electrónica, la mayoría de las bases de datos están en formato digital (electrónico), por ende se ha desarrollado y se
ofrece un amplio rango de soluciones al problema del almacenamiento de datos, dando paso al termino Sistemas
Gestores de Bases de Datos abreviado SGBD. Un SGBD es una colección de programas cuyo objetivo es servir de
interfaz entre la base de datos, el usuario y/o aplicaciones. Se compone de un lenguaje de definición de datos (DDL),
de un lenguaje de manipulación de datos (DML) y de un lenguaje de consulta (SQL). Un SGBD permite definir los
datos a distintos niveles de abstracción y los mecanismos de manipulación, garantizando la seguridad e integridad
de los mismos.
Estos antecedentes proporcionan una visión al lector para el entendimiento del objeto de estudio de esta tesis:
La Interfaz Gráfica Unificada de Sistemas Manejadores de Bases de Datos (IGUDES), que abstrae gran parte de los
conceptos mencionados anteriormente para cubrir de manera ágil la necesidad de información actual de las
organizaciones, posibilitando el acceso oportuno a la información administrada por SMBD locales o remotos,
ya sean homogéneos o heterogéneos, con el mismo comportamiento y agilidad que brindan las herramientas
comerciales.
IGUDES está conformado por dos sistemas: Modulo de Generación y Manipulación de Esquemas (GMS) y Modulo de
Manipulación y Transferencia de Datos (MTD). Particularmente el segundo es objeto de la presente tesis.
El modulo MTD es una aplicación web creada en Java que hace frente al problema de integración a través de la
implementación de una de las más comunes Arquitecturas Multi Database, el modelo Mediator-Wrapper he
implementa el modelo cliente servidor. La ventaja de esto, es que el único requerimiento de cara a los usuarios es
que cuenten con un navegador de internet.
MTD tiene como finalidad el acceder a tres SMBD Relacionales: Oracle, Microsoft SQL Server y MySQL, utilizando
SQL como lenguaje común para su manipulación, brindando las siguientes funciones:
Control de acceso a la aplicación: facilita los mecanismos de acceso, por ejemplo, desde que terminal,
que tipo y cuantas funciones están permitidas ejecutar por usuario, en relación a los permisos otorgados y
monitorear el número de veces que se ha ingresado.
Consultas Simples (centralizadas): permite ejecutar sentencias DML sobre los SMBD comentados.
Consultas Múltiples: permite ejecutar sentencias DML en conjunto, mediante un script.
Consultas Distribuidas: permite ejecutar sentencias DML sobre SMDB distribuidas homogéneas o
heterogéneas.
Cabe comentar que existen herramientas que permiten la conexión con otros SMBD homogéneos o heterogéneos,
sin embargo, estas solo permiten enlaces en los que interviene uno y solo un SMBD, contrariamente a IGUDES,
en donde las conexiones heterogéneas entre los SMBD instanciados son simultaneas.
La presente tesis se ha dividido en cuatro capítulos. El Capitulo I introduce al lector en los Antecedentes Teóricos
que fundamentan el desarrollo del sistema propuesto. Se aborda bajo dos perspectivas, la primera expone los
conceptos asociados a las bases de datos y sus ramificaciones, como lo son los Sistemas Manejadores de Bases de
Datos (Estructura, Aplicaciones, Modelos de Datos, lenguajes y Mejores Prácticas de SQL) y los Sistemas de Bases de
Datos Distribuidas (Modelos Arquitectónicos, Integración de Bases de Datos y Metodologías de Diseño). Por otra
parte, dado que el sistema es un aplicativo web, se comenta sobre el Modelo-Vista-Controlador y las tecnologías
utilizadas en la concepción de la aplicación (Java EE, JavaScript, JSP, JDBC, DAO) entre otros temas.
Página 10 de 190
El Capítulo II tiene por objetivo principal mostrar al lector el detalle de la Arquitectura cliente-servidor así como el
modelo Mediator-Wrapper y su similitud contra los nuevos paradigmas de los SGBD Distribuidos. Se menciona las
fortalezas de IGUDES, y se muestra una comparación de características puntuales contra las herramientas de
mayor demanda en el tema de las bases de datos. Finalmente, se presenta un cuadro a manera de resumen, en
donde se califican las características del MTD vs Herramientas Comerciales.
El Capítulo III se enfoca en la presentación del software desarrollado, en donde a partir de una serie de pantallas, el
lector podrá identificar tanto los flujos de ejecución y sus respectivas interfaces de usuario. Se destacan los
elementos considerados como vitales (aquellos que fueron críticos para el cumplimiento del alcance): las tablas de
control y administración de la aplicación, los procedimientos almacenados de validación y actualización de
acceso, las Java Server Pages (jsp) y su flujo de ejecución, y finalmente, la configuración de cada una de las
conexiones a las bases de datos tanto homogéneas como heterogéneas.
En el Capítulo IV, se comenta la evaluación de la solución, es decir se realizan algunos ejemplos para demostrar
cada una de las funciones y el alcance de IGUDES MTD, así como los hallazgos identificados durante el
desarrollo.
OBJETIVO
El objetivo de este trabajo de tesis es desarrollar una aplicación web, que mediante una interfaz sencilla de
manipular permita al usuario ejecutar sentencias DML sobre los distintos SMBD pre configurados, sin importar
que se encuentren en una arquitectura centralizada o distribuida, abasteciendo al usuario de todas las
configuraciones y conexiones necesarias. La aplicación desarrollada deberá contener un módulo que
proporcione el control de acceso mediante validaciones eficaces y que a su vez permita monitorear los accesos
a la aplicación, un módulo que permita ejecutar sentencias DML sobre diversos SMBD, denominado Consultas
Simples, un módulo que permita ejecutar un grupo de sentencias DML mediante un script, sobre diversos SMBD
homogéneos o heterogéneos, denominado Consultas Múltiples y finalmente un módulo que permita ejecutar
sentencias DML sin ser un script sobre diversos SMBD homogéneos o heterogéneos, denominado Consultas
Distribuidas.
Página 11 de 190
1 Marco Teórico.
IGUDES. MTD.
CAPITULO I. MARCO TEORICO
1.1. INTRODUCCIÓN
La Interfaz Gráfica Unificada de Sistemas Manejadores de Bases de Datos (IGUDES), y particularmente el módulo
para Manipulación y Transferencia de Datos (MTD), es una aplicación web que está soportada por el termino
middleware (software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones) y bajo
una arquitectura cliente – servidor (modelo de aplicación distribuida en el que las tareas se reparten entre los
proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes). Es un
middleware dado que establece la comunicación entre diversos Sistemas Manejadores de Bases de Datos
(SMBDs) proporcionando al usuario una interfaz a través de la cual se puede acceder a las bases de datos
administradas por estos SMBDs y está basada en una arquitectura cliente – servidor ya que es un sistema que
atiende solicitudes generadas por el cliente a través de un navegador y bajo un protocolo desde una
terminal remota al servidor centralizado que se encarga de distribuir y responder a las peticiones.
IGUDES (MTD) esta creado mediante Java Enterprise Edition (J2EE) sobre el IDE de Eclipse. Particularmente
empleando para su desarrollo tecnologías y patrones de diseño como: jsp(Java Server Pages), js (java script),
DAO (Data Access Object), JDBC (Java Database Connectivity), ODBC(Open Database Connectivity), administrado
con Oracle XE 10g e implementando el concepto de Bases de Datos Distribuidas mediante las siguientes
tecnologías propietarias: Oracle (DBLink), SQL Server (Linked Server) y MySQL (Federated).
De acuerdo a lo anterior, el presente captulo define los conceptos y la teoría que soporta el desarrollo de este
aplicativo, y a los que se hará referencia en los capítulos posteriores, así como también se comenta sobre las
tecnologías utilizadas.
1.2. BASES DE DATOS Y SISTEMAS MANEJADORES DE BASES DE DATOS
1.2.1. Bases de Datos
Las bases de datos juegan un papel muy importante en el mundo de los negocios, así como en el de la
investigación. A través de ellas las empresas obtienen información que les permiten tomar decisiones sobre
la elaboración, lanzamiento y distribución de sus productos o servicios así como también gestionar las
opiniones de los clientes. Ante un mundo de cambios constantes es necesario elaborar tecnologías que
permitan analizar las bases de datos al momento y de manera adecuada a fin de proporcionar soluciones
rápidas.
Una base de datos (BD) es una colección de datos tratados como una unidad. Su propósito es la de
almacenar y recuperar información relacionada (1).
1.2.2. Sistemas Manejadores de Bases de datos
Un Sistema Manejador de Bases de Datos (SMBD) consiste en una colección de datos interrelacionados y
un conjunto de programas para acceder a dichos datos (2). Los propósitos de un SMBD son:
Crear, actualizar, eliminar y desplegar objetos en dirección a los usuarios.
Proteger la integridad y seguridad de las BD.
Proporcionar una interfaz de fácil uso para los usuarios autorizados que realizan consultas
autorizadas con datos validos y precisos.
Proporcionar mensajes informativos y útiles a los usuarios autorizados que hacen consultas no
autorizadas, cometen errores o intentan procesar datos no validos.
1.2.2.1. Estructura de un SMBD
Los componentes funcionales de un SMBD se pueden dividir en:
1. Gestor de Almacenamiento: es el módulo que proporciona la interfaz entre los datos de bajo nivel en la
BD, los programas de aplicación y consultas emitidas al sistema. Es el responsable de la interacción con
el gestor de archivos. Los datos en bruto se almacenan en disco usando un sistema de archivos, que está
disponible habitualmente en un sistema operativo convencional (2).
(1)
Oracle®,“Database Concepts 11g Release 1 (11.1)”.
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p. 24.
(2)
Página 12 de 190
1 Marco Teórico.
IGUDES. MTD.
El gestor de almacenamiento traduce las diferentes instrucciones del Lenguaje de Manipulación de
Datos (DML). De esta manera el gestor de almacenamiento almacena, actualiza y recupera los datos de
la BD. Los componentes del gestor de almacenamiento son:
Gestor de autorización e integridad: comprueba que se cumplan las restricciones de integridad y la
autorización de los usuarios para acceder a los datos.
Gestor de Transacciones: asegura que la BD se encuentre en un estado consistente, a pesar de las
fallas del sistema y que las transacciones concurrentes se ejecuten sin conflictos.
Gestor de Archivos: gestiona el espacio de almacenamiento de discos y las estructuras de datos
usadas para representar la información almacenada.
Gestor de Memoria Intermedia: es el responsable de traer los datos del disco a la memoria principal
además de decir que datos deben ser tratados en memoria caché.
El gestor de almacenamiento implementa varias estructuras de datos como parte de la implementación
física del sistema:
Archivos de datos: almacenan la BD.
Diccionario de datos: almacena los metadatos de la estructura de la BD, en particular el esquema.
Índices: proporcionan acceso rápido a elementos de datos que tienen valores particulares.
2. Procesador de consultas: es importante porque ayuda al sistema de bases de datos a simplificar y
facilitar el acceso a los datos. Las vistas de alto nivel ayudan a conseguir este objetivo. Su función es la
de traducir las actualizaciones y las consultas escritas en un lenguaje no procedimental, en el nivel
lógico, en una secuencia de operaciones en el nivel físico. Los componentes del procesador de consultas
incluyen:
Interprete del Lenguaje de Definición de Datos (DDL): interpreta las instrucciones del DDL y registra
las definiciones en el diccionario de datos.
Compilador del Lenguaje de Manipulación de Datos (DML): traduce las instrucciones del DML en un
lenguaje de consultas a un nivel de evaluación que consiste en instrucciones de bajo nivel que puede
entender el motor de evaluación de consultas. Una consulta se traduce en varios planes de
ejecución alternativos que proporcionan el mismo resultado. El compilador de DML también realiza
optimización de consultas, es decir, elige el plan de evaluación de menor costo de entre todas las
alternativas.
Motor de evaluación de consultas: ejecuta las instrucciones de bajo nivel generadas por el
compilador de DML. La figura 1.1 muestra estos componentes y sus conexiones.
1.2.3. Aplicaciones de los Sistemas de Bases de Datos
Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus aplicaciones más
representativas (2):
Banca: Registro y administración de información de clientes, cuentas, préstamos y transacciones
bancarias.
Universidades: Para información de estudiantes, profesores, asignaturas, pagos, etc.
Telecomunicaciones: Guardar registro de llamadas, generación mensual de facturas, saldo,
información sobre las redes de comunicación.
Finanzas: Para almacenar información sobre grandes empresas, ventas y compras de documentos
formales financieros, como bolsa y bonos.
Producción: Para la gestión de la cadena de producción y para el seguimiento de inventarios y
pedidos.
Recursos Humanos: Información sobre empleados, salarios, impuestos, nominas, etc., entre otros.
1.2.4.
Abstracción de Datos
Uno de los propósitos principales de un SMBD, es proporcionar al usuario una visión abstracta de los datos,
es decir, el sistema oculta ciertos detalles a través de varios niveles de abstracción así como la forma de
almacenar y de mantener los datos (2):
(1)
Oracle®,“Database Concepts 11g Release 1 (11.1)”.
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p. 24.
(2)
Página 13 de 190
1 Marco Teórico.
IGUDES. MTD.
Nivel Físico: Describe como se almacenan realmente los datos, se detallan las estructuras de datos
complejas de bajo nivel así como los métodos de acceso.
Nivel Lógico: Se definen las relaciones que existen entre esos datos. Se concentra en describir
entidades, atributos, relaciones, operaciones de los usuarios y restricciones.
Nivel de Vista: Es el nivel más alto de abstracción, describe solo parte de la BD, simplifica la
interacción con el sistema. El sistema puede proporcionar muchas vistas para la misma base de
datos. Puede definirse como la forma en que el usuario aprecia la información y sus relaciones.
Figura 1.1. Estructura de un SMBD
Fuente: Silberschatz, A. Fundamentos de Bases de Datos, 2002:12.
1.2.5. Modelos de Datos
Es una colección de herramientas conceptuales para describir los datos, las relaciones, la semántica y las
restricciones de integridad(2). Se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para
describir la estructura de la base de datos.
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p. 4, 12, 24.
Página 14 de 190
1 Marco Teórico.
IGUDES. MTD.
1.2.5.1. Modelo Entidad – Relación
Este modelo está basado en una percepción del mundo real, que consta de una colección de objetos básicos
llamados entidades, y de relaciones entre estos objetos. Una entidad es un objeto del mundo real que es
distinguible de otros objetos, por ejemplo, cada persona es una entidad, o bien también lo podría ser una
cuenta bancaria. Las entidades se describen en una BD mediante un conjunto de atributos. Por ejemplo, los
atributos número_cuenta / saldo describen una cuenta particular de un banco donde cuenta es la entidad.
Análogamente, los atributos nombre_cliente / calle_cliente / ciudad_cliente pueden describir la entidad
cliente. Otro atributo podría ser el id_cliente (identificador), que se usaría para identificar unívocamente a
los clientes (ya que es posible que haya dos clientes con el mismo nombre y dirección).
Una relación es una asociación entre varias entidades. Por ejemplo una relación cliente-cuenta asocia a un
cliente con cada una de las cuentas que este tenga (2).
La estructura lógica general de una base de datos se puede expresar gráficamente mediante un diagrama ER, que consta de los siguientes componentes:
Rectángulos: representan conjuntos de entidades.
Elipses: representan atributos.
Rombos: representan relaciones entre conjuntos de entidades.
Líneas: unen los atributos con los conjuntos de entidades y los conjuntos de entidades con las
relaciones.
Elipses Dobles: representan atributos multivalorados.
Elipses Discontinuas: denotan atributos derivados.
Líneas Dobles: indican participación total de una entidad en un conjunto de relaciones.
Rectángulos Dobles: representan conjuntos de entidades débiles.
Los atributos de un conjunto de entidades que son miembros de una clave primaria están
subrayados.
CALLE_CLIENTE
NOMBRE_CLIENTE
CIUDAD_CLIENTE
NUMERO_CUENTA
SALDO
ID_CLIENTE
CLIENTE
CLIENTE CUENTA
CUENTA
Figura 1.2. Ejemplo de un Diagrama E-R
Fuente: Elaboración Propia.
Considere que la figura anterior parte de una base de datos de un sistema bancario la cual se conforma de
clientes y de cuentas que tienen esos clientes. El Diagrama E-R indica que hay dos conjuntos de entidades
CLIENTE y CUENTA, con los atributos descritos previamente y también la relación que existe entre esas dos
entidades CLIENTE-CUENTA. Además de entidades y relaciones un modelo E-R también representa ciertas
restricciones que los contenidos de la BD deben cumplir. La figura 1.3 muestra cómo se pueden representar
atributos compuestos en la notación E-R. El atributo compuesto nombre, con atributos componentes
nombre_pila, primer_apellido, segundo_apellido, reemplaza al atributo simple nombre_cliente de cliente.
También se muestra en el atributo compuesto dirección, cuyos atributos componentes son calle, ciudad,
estado y código_postal, que reemplazan a los atributos calle_cliente y ciudad_cliente de cliente.El atributo
calle es por sí mismo un atributo compuesto cuyos atributos componentes son: numero_calle,
nombre_calle, número. En la misma figura también se muestra un atributo multivaluado numero_telefono,
identificado por una elipse doble, y un atributo derivado edad, identificado por una elipse discontinua.
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.5, 6.
Página 15 de 190
1 Marco Teórico.
IGUDES. MTD.
a) Correspondencia de cardinalidades
La razón de cardinalidad, expresa el número de entidades a las que otra entidad puede estar asociada
vía un conjunto de relaciones.
Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de
cardinalidades debe ser una de las siguientes:
NOMBRE_CALLE
PRIMER_APELLIDO
NUMERO_CALLE
NUMERO
SEGUNDO_APELLIDO
NOMBRE_PILA
CALLE
CIUDAD
NOMBRE
DIRECCION
ESTADO
ID_CLIENTE
CLIENTE
CODIGO_POSTAL
EDAD
NUMERO_TELEFONO
FECHA_NACIMIENTO
Figura 1.3. Ejemplo de un Diagrama E-R con atributos compuestos, multivaluados y derivados
Fuente: Elaboración Propia.
Uno a Uno: Una entidad en A se asocia con a lo
sumo una entidad en B , y una entidad en B se
asocia a lo sumo a una entidad en A.
Uno a Varios: Una entidad en A se asocia con
cualquier número de entidades en B (ninguna o
varias). Una entidad en B, sin embargo, se
puede asociar con a lo sumo a una entidad en
A.
a1
b1
a2
b2
a3
b3
a4
b4
A
B
b1
a1
a2
b3
b4
A
Página 16 de 190
b2
B
1 Marco Teórico.
IGUDES. MTD.
a1
Varios a uno: Una entidad en A se asocia con a
lo sumo una entidad en B. Una entidad en B,
sin embargo, se puede asociar con cualquier
número de entidades (ninguna o varias) en A.
Varios a varios: Una entidad A se asocia con
cualquier número de entidades (ninguna o
varias) en B, y una entidad en B se asocia con
cualquier número de entidades (ninguna o
varias) en A.
Relación
varios a varios
*
Relación uno a
uno
1
Relación
varios a uno
*
R
R
R
a2
b1
a3
b2
a4
A
B
a1
b1
a2
b2
a3
b3
a4
b4
A
B
*
R
1
R
1
R
Figura 1.4. Notaciones de cardinalidad
Fuente: Elaboración propia con base en Silberschatz, A. Fundamentos de Bases de Datos, 2002:23.
b)
Claves
Los valores de los atributos de una entidad deben ser tales que permitan identificar unívocamente a la
entidad, es decir, no se permite que ningún par de entidades tengan exactamente los mismos valores de
sus atributos. Una clave permite identificar un conjunto de atributos para distinguir las entidades entre
sí, lo mismo sucede con las relaciones.
Superclave: es un conjunto de uno o más atributos, que tomados colectivamente, permiten
identificar de forma única una entidad en el conjunto de entidades. Retomando el ejemplo de la
figura 1.3, el atributo id_cliente del conjunto de entidades cliente es suficiente para distinguir
una entidad cliente de otras, de esta manera id_cliente es una superclave. La combinación de
nombre_cliente e id_cliente también podría ser una superclave. El atributo nombre_cliente de
cliente, por sí mismo no es una superclave ya que varias personas podrían tener el mismo
nombre.
Clave candidata: La superclave compuesta por nombre_cliente e id_cliente puede tener
atributos innecesarios. Si K es una superclave entonces también lo es cualquier subconjunto de
k, de esta manera, dada una superclave, si ésta deja de serlo quitando únicamente uno de los
atributos que la componen, entonces ésta es una clave candidata.
Clave Primaria: Denota una clave candidata que es elegida por el diseñador de la BD como
elemento principal para identificar a cada entidad dentro de un conjunto de entidades (2).
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.24.
Página 17 de 190
1 Marco Teórico.
IGUDES. MTD.
c) Especialización
Considérese el conjunto de entidades persona con atributos nombre, calle y ciudad. Una persona puede
clasificarse además como cliente o empleado. Cada uno de estos tipos de persona se describen
mediante un conjunto de atributos que incluyen los atributos del conjunto de entidades persona más
otros posibles atributos adicionales. Las entidades cliente se pueden describir además mediante el
atributo id_cliente, mientras que las entidades empleado mediante el atributo id_empleado y sueldo. El
proceso de designación de subgrupos dentro de un conjunto de entidades se denomina especialización(2)
d) Generalización
Es el proceso de diseño mediante el cual varios conjuntos de entidades se sintetizan en un conjunto de
entidades de nivel más alto basado en características comunes. El diseñador de la base de datos puede
haber identificado primero el conjunto de entidades cliente con los atributos nombre, calle, ciudad,
id_cliente, y el conjunto de entidades empleado con los atributos nombre, nombre calle, ciudad,
id_empelado y sueldo. Hay similitudes entre el conjunto de entidades cliente y empleado en el sentido
de que tienen varios atributos en común. Esta similitud puede expresarse mediante la generalización,
que es una relación entre el conjunto de entidades de nivel más alto (persona) y uno o más conjuntos de
entidades de nivel más bajo (cliente-empleado). Los conjuntos de entidades de nivel más alto y nivel
más bajo también pueden llamarse superclase y subclase respectivamente.
Para propósitos de diseño, la generalización es una inversión simple de la especialización (2).
e) Herencia
Una propiedad de las superclases y subclases creadas mediante la especialización o bien la
generalización es la herencia de atributos. Los atributos de los conjuntos de entidades de nivel más bajo
se dice que son heredados por los conjuntos de entidades de nivel más alto. Por ejemplo cliente y
empleado heredan los atributos de persona (2).
Figura 1.5. Ejemplo de Especialización y Generalización
Fuente: Silberschatz, A. Fundamentos de Bases de Datos, 2002:57
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.56,57
.
Página 18 de 190
1 Marco Teórico.
IGUDES. MTD.
1.2.5.2. Modelo Relacional
El modelo relacional se basa en representar los datos y las relaciones entre ellos a través de un grupo de
tablas. Cada tabla (entidad) está compuesta por varias columnas (atributos) y cada columna tiene un
nombre único.
La figura 1.6 muestra un ejemplo de una base de datos relacional: consiste en tres tablas, la primera
representa a los clientes de un banco (entidad), la segunda las cuentas (entidad) y la tercera las cuentas que
pertenecen a cada cliente (relación) (2).
Id_cliente
nombre_cliente calle_cliente ciudad_cliente
número_cuenta Saldo
0
González
Reforma
Distrito Federal
c-101
500
1
Guerrero
Calle 10
Cintalapa
c-215
700
2
Lima
Oriente 164
Distrito Federal
c-102
400
3
Castro
Medellín
Edo. de México
c-305
350
4
Ramirez
San Lorenzo
Distrito Federal
c-201
900
5
Santos
Sauce
Villa Hermosa
c-217
750
6
Araujo
Dibujantes
Monterrey
c-222
700
Tabla 01. CLIENTE
Tabla 02. CUENTA
Id_cliente
número_cuenta
0
c-101
0
c-215
1
c-102
2
c-305
3
c-201
4
c-217
5
c-222
Tabla 03. Tabla CLIENTE-CUENTA
Figura 1.6. Ejemplo de una Base de Datos Relacional
Fuente: Elaboración Propia.
El modelo Relacional es un ejemplo de un modelo basado en registros. Estos modelos se denominan así
porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tabla contiene
registros de un tipo en particular. Cada tipo de registro define un número fijo de campos o atributos. Las
columnas de la tabla corresponden a los atributos del tipo de registro.
El modelo relacional es el más ampliamente usado, y de la misma manera la mayoría de los SMBD actuales
se basan en este. Se encuentra a un nivel de abstracción inferior al modelo de datos E-R.
Es posible crear esquemas bajo este modelo, que tengan ciertos inconvenientes, como por ejemplo el de
información duplicada. Por ejemplo, supongamos que se almacena numero_cuenta como un atributo de la
entidad cliente, entonces para representar el hecho de que las cuentas c-101 y c-215 pertenecen al cliente
con id_cliente 0 sería necesario duplicar un registro en la tabla CLIENTE. Los valores de nombre_cliente,
calle_cliente y ciudad_cliente del cliente González estarán innecesariamente duplicados en dos tuplas (filas
de una tabla).
a) Clave Foránea
Es una limitación referencial entre dos tablas. La clave foránea identifica una columna o grupo de
columnas en una tabla (tabla referendo) que se refiere a una columna o grupo de columnas en otra
tabla (tabla referenciada). Las columnas en la tabla referendo deben ser la clave primaria u otra clave
candidata en la tabla referenciada (2).
b) Diagramas de Esquema
Un esquema de base de datos, junto con las dependencias de llave primaria y foránea se puede mostrar
gráficamente mediante los diagramas de esquema. La figura 1.7 muestra un ejemplo, cada relación
aparece como un cuadro con los atributos listados dentro de él y su nombre como encabezado. Si hay
atributos como clave primaria, una línea horizontal cruza el cuadro con las claves primarias sobre
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.53,57,58
.
Página 19 de 190
1 Marco Teórico.
IGUDES. MTD.
ella. Las dependencias de claves foráneas aparecen como flechas desde los atributos que conforman la
clave foránea de la relación referendo a la clave primaria de la relación referenciada.
No hay que confundir un diagrama de Esquema con un diagrama E-R. En particular los diagramas E-R no
muestran explícitamente los atributos de clave foránea, mientras que los diagramas de esquema sí.
Por otra
Sucursal
PK
Cuenta
CLIENTE-CUENTA
nombre_sucursal
PK
numero_cuenta
ciudad_sucursal
activos
FK1
nombre_sucursal
saldo
PK
FK2
FK1
Prestamo
PK
numero_prestamo
FK1
nombre_sucursal
importe
Cliente
nombre_cliente
numero_cuenta
nombre_cliente
calle_cliente
cliente_ciudad
CLIENTE-PRESTAMO
FK1
FK2
nombre_cliente
numero_prestamo
Figura 1.7. Ejemplo de un Diagrama de Esquema
Fuente: Elaboración Propia
1.2.6. Lenguajes de Bases de Datos
Un SMBD debe proporcionar un lenguaje de definición de datos (DDL) para definir el esquema de la BD así
como también un lenguaje de manipulación de datos (DML) con el cual se realizan las consultas y
modificaciones a la BD. En la práctica no hay una separación entre ambos lenguajes, simplemente se hace
una distinción debido a su función pero forman parte de un lenguaje único y universal: SQL (2).
1.2.6.1. Lenguaje estructurado de consultas: SQL
El lenguaje estructurado de consultas o SQL (por sus siglas en inglés Structured Query Language), es un
lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de
operaciones en ellas. Una de sus características es el manejo del algebra relacional que permite efectuar
consultas con el fin de recuperar de forma sencilla información de bases de datos, así como hacer cambios
sobre ellas.
Es un lenguaje declarativo de alto nivel o de “no procedimiento”, es decir, que especifica qué es lo que se
quiere y no cómo conseguirlo, por lo que una sentencia no establece explícitamente un orden de ejecución.
Gracias a su fuerte base teórica y su orientación al manejo de conjuntos de registros y no a registros
individuales, permite una alta productividad en codificación y orientación a objetos.
El orden de ejecución interno de una sentencia puede afectar gravemente a la eficiencia del SMBD, por lo
que se hace necesario que éste lleve a cabo una optimización antes de su ejecución. Muchas veces, el uso de
índices acelera una instrucción de consulta, pero disminuye la velocidad de la actualización de los datos (2)
1.2.6.2. Lenguaje de definición de datos: DDL
El lenguaje de definición de datos o DDL (por sus siglas en inglés Data Definition Language), es el que se
encarga de la modificación de la estructura de los objetos de la base de datos. Incluye órdenes para
modificar, borrar o definir las tablas en las que se almacenan los datos de la base de datos. Existen cuatro
operaciones básicas: CREATE, ALTER, DROP y TRUNCATE. Por ejemplo la siguiente instrucción en lenguaje
SQL define la tabla CUENTA (2):
CREATE TABLEcuenta
(
numero_cuentaVARCHAR(15),
saldoINT
)
____________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.7,58
.
Página 20 de 190
1 Marco Teórico.
IGUDES. MTD.
La instrucción ALTER permite modificar la estructura de un objeto. Se pueden agregar/quitar campos a una
tabla, modificar el tipo de un campo, agregar/quitar índices a una tabla, modificar un trigger, etc.:
ALTER TABLE cliente ADD telefono_cliente INT UNSIGNED
El comando DROP elimina un objeto de la base de datos. Puede ser una tabla, vista, índice, trigger, función,
procedimiento o cualquier otro objeto que el motor de la base de datos soporte. Se puede combinar con la
sentencia ALTER:
DROP TABLE cliente-cuenta
El comando TRUNCATE trunca todo el contenido de una tabla. La ventaja sobre el comando DROP, es que si
se quiere borrar todo el contenido de la tabla, es mucho más rápido, especialmente si la tabla es muy
grande. La desventaja es que sólo sirve cuando se quiere eliminar absolutamente todos los registros, ya que
no se permite la cláusula WHERE. Si bien, en un principio, esta sentencia parecería ser, es en realidad DDL,
ya que internamente, este comando borra la tabla y la vuelve a crear y no ejecuta ninguna transacción.
TRUNCATE TABLE cliente-cuenta
1.2.6.3. Lenguaje de manipulación de datos: DML
Un lenguaje de manipulación de datos o DML (por sus siglas en inglés Data Manipulation Language) es un
lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios llevar a cabo
las tareas de consulta (recuperación) o manipulación de los datos.
Una sentencia INSERT de SQL agrega uno o más registros a una (y sólo una) tabla en una base de datos
relacional:
INSERT INTO cliente ('nombre_cliente',
'calle_cliente','ciudad_cliente')VALUES('Ramirez', 'Camarena', 'Chiapas')
Una sentencia UPDATE de SQL es utilizada para modificar los valores de un conjunto de registros existentes
en una tabla:
UPDATE cuenta SET saldo = 450 WHERE numero_cuenta ='c-102'
Una sentencia DELETE de SQL borra uno o más registros existentes en una tabla:
DELETE FROM cliente WHERE id_cliente = 0
Una sentencia SELECT de SQL es utilizada para recuperar los valores almacenados en una tabla.
SELECT nombre_cliente, calle_cliente,ciudad_cliente FROM cliente
IGUDES está diseñado para ejecutar lenguaje DML,es decir, que está pensada como una herramienta de consulta y
de integración de información principalmente para el apoyo a la toma de decisiones a nivel táctico y estratégico.
Sintetiza las grandes funcionalidades y capacidades de un SMBD haciéndolas más practicas y accesibles a usuarios.
IGUDES MTD proporciona tres módulos para la ejecución de sentencias DML, los cuales se clasifican en Consultas
Simples que permite ejecutar sentencias DML sobre un Sistema Manejador de Base de Datos, Consultas Múltiples
que permite ejecutar sentencias DML en conjunto por medio de un script hacia un Sistema Manejador de Base de
Datos y Consultas Distribuidas en la que podemos realizar consultas distribuidas sobre Bases de Datos
Homogéneas o Heterogéneas (2).
______________________________________________________________________________________________________________________________________________________________________
(2)
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. “Fundamentos de Bases de Datos”, p.7
1.2.7.
Mejores Prácticas de SQL
.
Página 21 de 190
1 Marco Teórico.
IGUDES. MTD.
1.2.7. Mejores Prácticas de SQL
IGUDES al ser una aplicación cliente servidor requiere del uso de buenas prácticas en la creación de
sentencias SQL ya que una consulta mal estructurada puede generar demasiada carga en la
transferencia de información o simplemente disminuir el rendimiento de IGUDES, debido a esto se
considera importante echar mano a la Tesis de Edward Rodriguez Zavala “Optimización de Recursos de
Bases de Datos para obtener Sistemas de Información de Alto Desempeño” (3), en la que se profundiza en
temas como:
1.2.7.1. Secuencia para nombrar tablas
Se logra una mejor eficiencia en el uso de tablas grandes dentro del procesamiento de sentencias. El
analizador sintáctico de los SMBDs, siempre procesan los nombres de las tablas en orden de derecha a
izquierda, es decir, la tabla que se coloca inmediatamente después de la clausula FROM en una consulta SQL
es la última en ser procesada. La forma adecuada para nombrar las tablas en una sentencia que contiene
más de una, es colocar primero la de mayor número de tuplas y así consecutivamente (en forma
descendiente considerando su tamaño)(3):
Consulta poco eficiente:
SELECT nombre,id_pago
FROM ALUMNO o, PAGO c
WHERE c.nombre = ´hernandez´g
AND c.id_alumno <= 100
Consulta sugerida:
SELECT nombre,id_pago
FROM PAGO c, ALUMNO o
WHERE c.nombre = ´hernandez´g
AND c.id_alumno <= 100
-- EL NUMERO DE TUPLAS EN PAGO ES MAYOR AL NÚMERO DE TUPLAS EN ALUMNO
1.2.7.2. Posición de JOIN en la clausula WHERE
Es mucho más eficiente la recuperación de datos cuando se colocan correctamente los filtros
discriminatorios (<, >, >=, >=) en las clausulas WHERE de una sentencia SQL. Estos deben colocarse siempre
al final de las clausulas JOIN, ya que son los que discriminan la mayor cantidad de información, esto debido a
que al ejecutarse el análisis sintáctico, esta se realiza mediante un proceso “down - up”, es decir, que se
interpretan primero las sentencias que se encuentran al final de la clausula WHERE(3).
Consulta poco eficiente:
SELECT nombre,id_pago
FROM ALUMNO o, PAGO c
WHERE c.id_alumno <= 100
AND c.nombre = ´hernandez´
Consulta sugerida:
SELECT nombre,id_pago
FROM ALUMNO o, PAGO c
WHERE c.nombre = ´hernandez´
AND c.id_alumno <= 100
1.2.7.3. Evitar el uso del comodín *
Es bien sabido que el uso del * consume en exceso recursos de la BD, ya que significa que la consulta deberá
recuperar todas las columnas de una tabla o bien todas las columnas de todas las tablas involucradas en el
SELECT. Se evita recuperar información innecesaria, ya que se consumen recursos de red y el SMBD no
procesará internamente más datos(3).
Consulta poco eficiente:
SELECT *
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
AND c.nombre != ´hernandez´
(3)
Rodriguez, Edward. “Optimización de Recursos de Bases de Datos para obtener Sistemas de Información de Alto
Desempeño”, pp. 81-121
Página 22 de 190
1 Marco Teórico.
IGUDES. MTD.
Consulta sugerida:
SELECT nombre,id_pago
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
AND c.nombre != ´hernandez´
1.2.7.4. Expresión de Agregación COUNT
La sentencia SQL que incluya el comando COUNT se procesará con mayor eficiencia si su valor de entrada es
una clave primaria o bien una constante. Se sugiere evitar que la entrada sea un comodín o bien cualquier
columna de las tablas involucradas.
Consulta poco eficiente:
SELECT
nombre, COUNT(mensualidad)
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
AND c.nombre != ´hernandez´
GROUP BY c.nombre
Consulta sugerida:
SELECT
nombre, COUNT(id_pago) –donde id_pago es la PK de la tabla PAGO
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
AND c.nombre != ´hernandez´
GROUP BY c.nombre
1.2.7.5. Discriminación de información a través de la clausula WHERE en lugar de HAVING
Cuando se usa una condición HAVING en consultas que tienen funciones de agregación GROUP BY, los
registros son discriminados hasta que han sido procesados por estas funciones. Lo que se sugiere es incluir
en la clausula WHERE todas las condiciones necesarias antes de realizar el agrupamiento.
Consulta poco eficiente:
SELECT
nombre, SUM(mensualidad)
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
AND c.nombre != ´hernandez´
GROUP BY c.nombre
Consulta sugerida:
SELECT
nombre, SUM(mensualidad)
FROM ALUMNO o, PAGO c
WHERE c.id_alumno = o.id_alumno
GROUP BY c.nombre
HAVING c.nombre != ´hernandez´
1.2.7.6. Discriminación de información a través del comando EXISTS en lugar de IN
Existen consultas que están conformadas por más de una tabla y que utilizan condiciones en donde se
deben de cumplir una serie de valores de otras tablas u otras consultas. Las sentencias IN y NOT IN lo
resuelve, sin embargo la manera más eficiente de obtener el resultado es a través de las instrucciones
EXISTS y NOT EXISTS.
Consulta poco eficiente:
SELECT nombre, CP
FROM ALUMNO l
WHERE CP IN
(SELECT CP
FROM DIRECCION
WHERE colonia = ´san francisco´
Página 23 de 190
1 Marco Teórico.
IGUDES. MTD.
)
Consulta sugerida:
SELECT nombre, CP
FROM ALUMNO l
WHERE EXISTS
(SELECT CP
FROM DIRECCION
WHERE colonia = ´san francisco´
)
1.2.7.7. Utilizar IN en lugar de múltiples OR en un listado estático
Cuando es necesario aplicar una restricción sobre una consulta mediante una lista de valores estáticos, es
más eficiente utilizar la clausula IN en vez de varios OR sobre la misma columna.
Consulta poco eficiente:
SELECT nombre
FROM ALUMNO l, GRUPO o, MATERIA c
WHERE o.id_grupo = l.id_grupo
AND c.id_materia = o.id_materia
AND (c_id_profsor = 2 OR c_id_profesor = 3 OR c_id_profesor = 4)
Consulta sugerida:
SELECT nombre
FROM ALUMNO l, GRUPO o, MATERIA c
WHERE o.id_grupo = l.id_grupo
AND c.id_materia = o.id_materia
AND c_id_profsor IN (2,3,4)
1.3. SISTEMAS DE BASES DE DATOS DISTRIBUIDAS
En este apartado se abordará el tema de los sistemas de bases de datos distribuidas como un antecedente para
comprender mejor los fundamentos de los sistemas multi bases de datos (MDBS). Si bien IGUDES no cubre
totalmente las características de un MDBS, pretende ser un sistema de integración de datos que soporte la
toma de decisiones, de manera que los usuarios puedan acceder a una colección de bases de datos distribuidas.
Es una capa de software que se encuentra en un nivel superior a los DBMS individuales y que proporciona a los
usuarios el acceso a las bases de datos locales.
1.3.1. Paradigma del Modelo Computacional
Procesamiento Centralizado: Un equipo anfitrión (normalmente un mainframe –computadora central–),
abastece todo el procesamiento: entradas, salidas almacenamiento y recuperación de datos. Modelo
predominante en los años 70’s.
Procesamiento Distribuido: Cierto número de equipos (servidores, estaciones de trabajo, PC’s, etc.)
abastecen el procesamiento, están conectados físicamente a través de una red de comunicaciones.
Procesamiento Cooperativo: Es la evolución del modelo distribuido, la diferencia es que el procesamiento se
lleva a cabo a través del intercambio de recursos (datos, archivos, tiempo del CPU, dispositivos de
visualización, etc.) de forma transparente para los usuarios. Para que un proceso se realice de la mejor
manera, es preferible utilizar distintas terminales realizando la misma tarea, a centralizar los recursos
haciendo uso de más hardware/software. Con la ejecución de múltiples servidores el procesamiento es más
rápido, el tiempo de respuesta es descentralizado y se incrementa la confiabilidad(4).
Se define una base de datos distribuida como una colección de múltiples bases de datos interrelacionadas
lógicamente y distribuidas sobre una red. Por su parte un sistema de administración de bases de datos
distribuidas (DBMS Distributed Database Management System, por sus siglas en inglés), se define como el
software que permite la administración de la base de datos distribuida haciendo que esta distribución sea
transparente para los usuarios. De esta manera un DDBS (Distribute Database System, por sus siglas en
inglés) es el término que utilizamos para referir conjuntamente a la base de datos distribuida y al DBMS.
(4)
Chung, Lawrence. “Client-Server Architecture”, p. 1
Página 24 de 190
1 Marco Teórico.
IGUDES. MTD.
Un DDBS no es una colección de archivos individuales y almacenados en cada uno de los nodos de una red de
equipos. Para formar un DDBS, los archivos no solo tiene que estar interrelacionados lógicamente sino que
deben poder ser accedidos a través de una interfaz común (5).
1.3.2. Alternativas para la entrega de datos
En bases de datos distribuidas, los datos son entregados desde los sitios donde están almacenados hacia
donde la consulta fue lanzada. Caracterizamos las alternativas de entrega de datos a través de tres
dimensiones ortogonales: modos de entrega, frecuencia y métodos de comunicación.
Dentro de los modos de entrega se encuentran:
Pull-Only: La transferencia de datos desde los servidores hasta los clientes se inicia por una llamada
del cliente. Cuando una llamada del cliente es recibida en el servidor, el servidor responde mediante
la localización de la información solicitada. En este modo los servidores son interrumpidos
constantemente para hacer frente a las peticiones de los clientes. Por otra parte la información que
los clientes pueden obtener es limitada, en el sentido de que el cliente necesita conocer
exactamente que requiere obtener y cuando. Los SMBD convencionales se basan en esta modalidad.
Push-Only: La transferencia de datos desde servidores a clientes es iniciada por el servidor en
ausencia de una petición especifica del cliente. La principal dificultad de esta modalidad esta en
decidir qué datos resultarán de interés y cuando debieran ser enviados a los clientes, por tanto la
utilidad de este modo depende en gran medida de la precisión del servidor para predecir las
necesidades de los clientes.
Hibrido: Es una combinación de los mecanismos client-pull y server-push. La transferencia de
información desde los servidores hasta los clientes es iniciada por una llamada del cliente (a través
del planteamiento de una consulta) y posteriormente la transferencia de información actualizada a
los clientes es iniciada por el empuje del servidor (6).
(5)
Figura 1.8. Base de Datos Centralizada en Red
Fuente Özsu, Tamer. Principles of Distributed Database Systems, 2011:5
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 5.
Liu, L., Pu, C., Barga, R., Zhou, T. “Differential evaluation of continualqueries”, pp. 458-465
(6)
Página 25 de 190
1 Marco Teórico.
IGUDES. MTD.
(5)
Figura 1.8. Ambiente DDBS
Fuente Özsu, Tamer. Principles of Distributed Database Systems, 2011:5
1.3.3. Ventajas de los DDBS
Estas pueden resumirse en cuatro:
1.3.3.1. Gestión transparente de los datos distribuidos y replicados
Se refiere a la separación de la semántica de un sistema de las cuestiones de implementación de bajo nivel,
en otras palabras un sistema transparente oculta los detalles de implementación a los usuarios.
Supongamos una empresa con oficinas en Ciudad de México, Berlín y Los Ángeles, requiere mantener los
datos asociados a sus proyectos por cada oficina, como por ejemplo los de los empleados y otros datos
relacionados. Supongamos también que estos datos son almacenados en cuatro relaciones: EMPLEADO
(id_empleado, nombre, edad, profesion), PROYECTO (id_proyecto, nombre, presupuesto), SALARIO
(profesión, monto) y la relación EMP-PROJ (id_proyecto, id_empleado, responsable, duracion) la cual
identifica que empleados han sido asignados a que proyecto o proyectos. Si todos estos datos estuviesen
almacenados en un SMBD centralizado y quisiéramos obtener los nombres y los salarios de los empleados
que trabajaron en un proyecto por más de 12 meses, los obtendríamos con la siguiente consulta(5):
SELECT nombre, monto
FROM EMPLEADO, EMP-PROJ, SALARIO
WHERE EMP-PROJ.duracion >12
AND EMPLEADO.id_empelado = EMP-PROJ.id_empelado
AND SALARIO.profesion = EMPLEADO.profesion
Sin embargo, debido a la naturaleza de distribución de la empresa, es preferible que los datos de los
empleados, proyectos y salarios, de Ciudad de México se almacenen en Ciudad de México, los de Berlín en
Berlín y los de Los Ángeles en los Ángeles, es decir, lo que se busca es particionar las relaciones y cada
partición almacenarla en un sitio diferente, a esto se le llama proceso de fragmentación.
Por otra parte, puede ser preferible duplicar algunos de estos datos en otros sitios por temas de desempeño
y/o seguridad. El resultado de este escenario hipotético, es una base de datos distribuida fragmentada y
replicada.
Acceso totalmente trasparente significa que los usuarios de esta base de datos pueden lanzar la consulta
previamente planteada sin preocuparse de la fragmentación, la ubicación y/o la réplica de sus datos.
a) Independencia de Datos
Se refiere a la inmunidad que tienen las aplicaciones de usuario en referencia a los cambios en la
definición y la organización de los datos, es decir, que cuando ocurre un cambio en la organización de
los datos (tanto a nivel lógico como físico), las aplicaciones de usuario no deben de verse afectadas por
dichas modificaciones(5).
(5)
b)Özsu,
Transparencia
de Red
Tamer, Valduriez,
Patrick. “Principles of Distributed Database Systems”, p. 5, 8
Página 26 de 190
1 Marco Teórico.
IGUDES. MTD.
En sistemas centralizados el único recurso que necesita ser protegido del usuario son los datos, sin
embargo en un sistema distribuido la red también debe de estar debidamente protegida.
La transparencia de red ocurre cuando el usuario desconoce a detalle el funcionamiento de esta,
incluso desconoce su existencia. De esta manera no existe ninguna diferencia entre las aplicaciones de
base de datos que se ejecutan en una base de datos centralizada y las que se ejecutan en una
distribuida.
Desde la perspectiva de un SMBD, la transparencia distribuida también refiere a que los usuarios no
necesitan conocer el lugar donde se localizan los datos.
Se identifican dos tipos de transparencia distribuida: transparencia de locación y transparencia de
nombre. La primera concierne al hecho de que cualquier comando que sea ejecutado para acometer
una tarea es independiente a la localización del dato y al sistema donde se lleva a cabo dicha operación.
La segunda significa que un único nombre le corresponde a un único objeto de la base de datos, sin la
transparencia de nombre, los usuarios estarían obligados a referenciar su locación o bien incorporar un
identificador como parte del nombre del objeto (5).
c) Transparencia de Replica
Por razones de rendimiento, fiabilidad y disponibilidad, es deseable replicar los datos de manera
distribuida a través de varios equipos en red. Esto ayuda a tomar acciones rápidas en caso de desastre,
como por ejemplo un fallo en alguno de los equipos de la red (5).
d) Transparencia de Fragmentación
Es comúnmente deseable dividir cada relación de la base de datos en fragmentos más pequeños y
tratar cada fragmento como un objeto de base de datos independiente (es decir, como otra relación).
Esto se hace por razones de rendimiento, disponibilidad y fiabilidad. La fragmentación reduce efectos
negativos de replicación. Dado que cada replica no es la relación completa, sino un subconjunto de la
misma, se requiere mucho menos espacio y menos elementos de datos requieren ser gestionados.
Existen dos alternativas de fragmentación:
Fragmentación Horizontal: una relación es particionada en un subconjunto de relaciones donde
cada una contiene un subconjunto de tuplas del conjunto de tuplas de la relación original.
Fragmentación Vertical: ocurre cuando cada subconjunto de relaciones es definido como un
subconjunto de atributos del conjunto de atributos de la relación original.
Cabe comentar que el nivel de transparencia inevitablemente compromete la facilidad de uso, tal como lo
argumenta Gray: Las aplicaciones con acceso transparente a Bases de Datos Distribuidas geográficamente derivan
en poca capacidad de gestión, una pobre modularidad y poco rendimiento en el envió de mensajes. Propuso un
mecanismo de llamadas a procedimiento remoto (RPC Remote Procedure Call, por sus siglas en inglés) entre los
solicitantes (usuarios) y el servidor (DBMS), en donde los usuarios pueden dirigir sus consultas a un DBMS especifico.
Este es criterio es el comúnmente adoptado por los sistemas cliente-servidor (7).
1.3.3.2. Acceso fiable a los datos a través de transacciones distribuidas
Una transacción es una unidad básica de información consistente y fiable, consiste en una serie de
operaciones ejecutadas como una acción atómica. Transforma un estado consistente de la base de datos a
otro estado consistente incluso cuando una serie de transacciones sean ejecutadas al mismo tiempo
(transparencia de concurrencia) e incluso cuando se presenten fallas (atomicidad insuficiente). Por tanto, un
DBMS que provee un soporte completo transaccional garantiza que la ejecución concurrente de
transacciones no violará la consistencia de la base de datos, siempre y cuando las transacciones sean
correctas, es decir, que obedezcan a las reglas de integridad especificadas en la base de datos.
Supongamos que existe una aplicación (procedimiento almacenado) que sirve para actualizar el sueldo de
los empleados en un 10% anualmente, lo ideal es encapsular la consulta (o el código) que lleva a cabo esta
función, ya que esperaríamos que el DBMS fuera capaz de determinar, en caso de que ocurra alguna falla
durante la ejecución, y después de la recuperación del sistema, exactamente en qué parte del código se
trunco el proceso y continuar a partir de ese punto o bien iniciar de nuevo(5).
(7)
(5)
Gray, J. “Transparency in its place – the case against transparent access togeographically distributed data”, p. 11
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p.10,11,12,13
Página 27 de 190
1 Marco Teórico.
IGUDES. MTD.
Alternativamente supongamos que un usuario ejecuta una consulta para calcular la media del salario de los
trabajadores al mismo tiempo que la función de actualización está corriendo, en el peor de los escenarios el
cálculo de la media sería erróneo si el DBMS no fuera capaz de sincronizar la ejecución concurrente de
ambos procesos. Para encapsular una consulta (o código), es suficiente con declarar el inicio y el fin de la
transacción:
Begin transaction ACTUALIZAR_SALARIO
begin
EXEC SQL
UPDATE PAGO_SALARIO= PAG_SALARIO*1.1
end
Con un soporte completo para transacciones distribuidas, las aplicaciones de usuario pueden acceder a una
imagen única y lógica de la base de datos y se basan en el DBMS distribuido para garantizar que sus
peticiones se ejecutaran correctamente sin importar lo que ocurra en el sistema. Al decir correctamente,
significa que las aplicaciones de usuario no tienen que preocuparse por la coordinación de accesos a las
distintas bases de datos locales ni por la posibilidad de fallo en el enlace o de la comunicación durante la
ejecución de las operaciones.
1.3.3.3. Mejora en el rendimiento
El rendimiento de un DDBS se basa principalmente en dos puntos, primero, el DDBS fragmenta la base de
datos conceptual, de tal forma que los datos pueden ser almacenados en las proximidades de sus puntos de
acceso (localización de datos), esto representa dos ventajas potenciales:
Ya que cada sitio maneja solo una parte de la base de datos, disminuye la demanda de CPU de los
servicios de entrada-salida, sucede lo contrario en sistemas centralizados.
La localización reduce los retardos de los accesos remotos. Por ejemplo el retardo mínimo en la
propagación de mensajes en sistemas satelitales es de un segundo.
La mayoría de los DDBS están diseñados para obtener el mayor beneficio de la localización de datos.
El segundo punto se basa en el paralelismo inherente a los sistemas distribuidos, este puede dividirse en:
paralelismo inter-consulta: es la habilidad de ejecutar múltiples consultas al mismo tiempo.
paralelismo intra-consulta: se basa en la fragmentación de una consulta en un conjunto de sub
consultas que son ejecutadas en diferentes sitios, accediendo a diferentes partes del sistema
distribuido (5).
1.3.3.4. Escalabilidad
En un entorno distribuido, es mucho más fácil incrementar el tamaño de las bases de datos, la expansión
generalmente se basa en la adición de procesamiento y almacenamiento. Otro aspecto importante
relacionado con este punto es la economía, normalmente cuesta mucho menos construir y mantener un
sistema de equipos pequeños con la potencia equivalente a una gran y única máquina (mainframe) (5).
1.3.4. Las Complicaciones del paradigma de la Distribución
Existen tres factores que traen como consecuencia problemas en los sistemas distribuidos:
Primero, la duplicación de datos se debe principalmente a consideraciones de fiabilidad y eficiencia,
por consiguiente el DDBS es el responsable de mantener el acceso a la información en caso de
recuperaciones mediante copias de los datos.
Segundo, si uno de los sitios falla (por ejemplo un mal funcionamiento en hardware o software) o
bien alguno de los enlaces de comunicación falla (por ejemplo que alguno de los sitios no sea
localizable) mientras una operación de actualización está siendo ejecutada, el sistema debe
asegurarse de que los efectos de esta actualización se vean reflejados en los sitios de falla o que no
estuvieron localizables tan pronto como se recupere el sistema de estas fallas.
Tercero, cada uno de los sitios no puede obtener información instantánea sobre las acciones que se
están ejecutando en otros sitios. El DDBS debe ser capaz de sincronizar la actualización de
información en toda la red (5).
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 14, 15,16
Página 28 de 190
1 Marco Teórico.
IGUDES. MTD.
1.3.5. Arquitecturas de DBMS Distribuidos
La arquitectura de un sistema define su estructura en términos de datos y control de flujos, es decir, en una
arquitectura los componentes del sistema están identificados, la función de cada componente es específica
y las interrelaciones e interacciones a través de estos componentes también están bien definidas (5).
1.3.5.1. Modelos Arquitectónicos para DBMS Distribuidos
Consideremos la Figura 1.9, la cual muestra la clasificación mediante la cual los DBMs Distribuidos pueden
ser diseñados considerando tres variables: la autonomía de los sistemas locales, su distribución y la
heterogeneidad(5).
a) Autonomía
Indica el grado en el que cada DBMS puede operar independientemente. Es una función compuesta de
factores tales como: el grado en que los componentes del sistema son capaces de intercambiar
información, si son independientes al ejecutar transacciones o bien si poseen permisos de modificación.
(5)
Figura 1.9. Alternativas de Implementación de un DDBS
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:25
Los requisitos para que un sistema se considere autónomo son (8):
Las operaciones locales de los DBMS individuales no se ven afectadas por su participación en el
sistema distribuido.
La manera en que cada DBMS individual procesa y optimiza las consultas no debe verse afectada
por la ejecución de consultas globales que tienen acceso a varias bases de datos.
La consistencia y/u operación del sistema no debe verse comprometida cuando un DBMS
individual se une o bien abandona el sistema distribuido.
Por otra parte las dimensiones de la autonomía se pueden definir como (9):
Diseño: Los DBMS individuales son libres de usar modelos de datos y técnicas de gestión de
transacciones.
Comunicación: Cada DMBS individual es libre de elegir qué tipo de información enviará a otro
DBMS o al sistema que controla las ejecuciones globales.
Ejecución: Cada DBMS puede ejecutar las transacciones que le sean solicitadas de la manera en
que decida (5).
b) Distribución
Mientras que la autonomía se refiere a la descentralización de control, la distribución se enfoca a los
datos, obviamente considerando la distribución física de los datos sobre múltiples sitios, en donde el
usuario considera estos múltiples sitios como una única fuente de datos (5).
(8)
Gligor, V. Popescu-Zeletin, R.,“Transaction management in distributedheterogeneous database management systems”, pp.
287-297
(9)
Du,W. Elmagarmid, A. “Quasi-serializability: A correctness criterion for global concurrency control in interbase”, pp.347355
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 21, 25, 27.
Página 29 de 190
1 Marco Teórico.
IGUDES. MTD.
Existen varias formas en que los DBMS se distribuyen, las cuales se clasifican en dos: distribución
cliente-servidor y distribución peer-to-peer, estas en conjunto con la opción no distribuida, conforman
las tres alternativas arquitectónicas de distribución.
c) Heterogeneidad
La heterogeneidad puede presentarse en diversas formas que van desde la heterogeneidad de hardware
y diferencias en los protocolos de red a las variaciones propias de los DBMS, sin embargo las más
importantes se refieren a los modelos de datos, lenguajes de consulta y protocolos de gestión de
transacciones. La heterogeneidad de lenguajes de consulta, no solo implica los paradigmas de acceso a
datos en modelos de datos diferentes, sino que también existen diferencias de lenguajes, ya que aunque
SQL es hoy por hoy el lenguaje de consultas relacional estándar, existen muchas y diversas
implementaciones, cada vendedor implementa un SQL propio (incluso diferencias semánticas producen
resultados diferentes) (5).
d) Sistemas Cliente-Servidor
Es un tipo de arquitectura donde el procesamientose distribuye entre uno o más demandantes de
información llamados clientes y uno o más proveedores de información llamados servidores. Las
arquitecturas cliente-servidor pueden ser de dos y tres niveles. En la primera el cliente se comunica
directamente con el servidor. En la segunda, interviene un tercer componente el cual provee las
interfaces de los servicios entre ambos.
En sistemas relacionales, el servidor realiza la mayor parte de la administración de datos, esto es, todo el
procesamiento y optimización de consultas, gestión transaccional y de almacenamiento. Por su parte el
cliente, se encarga de gestionar los datos que se almacenan en caché, pero principalmente de solicitar la
ejecución de código. Es posible implementar la comprobación en la coherencia de consultas del lado del
cliente, pero esto no es muy común ya que requiere de la replicación del catalogo del sistema en cada
una de las maquinas cliente. La comunicación entre el cliente y el servidor es a nivel de declaraciones en
SQL, en otras palabras, el cliente pasa las consultas SQL al servidor sin entenderlas u optimizarlas, el
servidor hace la mayor parte de este trabajo regresando el resultado del procesamiento de la consulta al
cliente.
La arquitectura cliente-servidor ha sido extendida para proporcionar una función de distribución más
eficiente, identificamos tres tipos:
Servidores cliente: en donde se despliegan las interfaces de los usuarios (ejem. servidores web).
Servidores de aplicación: ejecutan programas de aplicación.
Servidores de bases de datos: administran funciones de bases de datos (5).
(5)
Figura 1.10. Arquitectura Cliente – Servidor
Fuente: Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:29
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 27, 28.
Página 30 de 190
1 Marco Teórico.
IGUDES. MTD.
e) Sistemas Peer-to-Peer
Consideremos en primera instancia que la organización física de los datos en cada equipo es diferente,
es decir, que se tiene una definición de esquema interno e individual en cada sitio, esta definición es
llamada esquema interno local (LIS), por otra parte, la vista global de los datos es descrita mediante el
esquema conceptual global (GCS), se dice que es global ya que describe la estructura lógica de los datos
en todos los sitios.
De cara a la fragmentación y replicación de la base de datos, es necesario contar con una tercer capa
llamada esquema conceptual local (LCS), la cual describe la organización lógica de los datos.
Finalmente las aplicaciones y los accesos de usuario a la base de datos están soportados por el esquema
externo (ES).
El modelo de esta arquitectura se detalla en la figura 1.11, el cual provee los niveles de transparencia
comentados anteriormente.
(5)
Figura 1.11. Arquitectura de Referencia de una Base de Datos Distribuida
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:33
El DDBMS traduce las consultas globales en un grupo de consultas locales, las cuales son ejecutadas y
distribuidas por los componentes del propio DDBMS sobre los distintos sitios de la base distribuida.
El detalle de los componentes de un DDBMS se muestra en la figura 1.12. Un componente maneja la
interacción con los usuarios, y el otro con el almacenamiento. El principal componente, el cual es
llamado procesador de usuario, se conforma de cuatro elementos (5):
El manejador de la interfaz de usuario: es el responsable de la interpretación de comandos que
vienen del usuario y formatear los resultados que le son enviados.
El controlador de tratamiento semántico: utiliza las restricciones de integridad y autorizaciones
que se definen como parte del esquema conceptual global para comprobar si la consulta del
usuario se puede procesar.
El optimizador de consultas globales, determina la estrategia de ejecución para minimizar el
costo de una función y por otra parte, traduce las consultas globales en locales usando los
esquemas conceptuales locales y globales así como el directorio global.
El monitor de ejecución distribuida: coordina la distribución de la ejecución de las peticiones del
usuario.
El segundo componente principal de un DDBMS es el procesador de datos y está conformado de tres
elementos:
El optimizador de consultas locales: es el responsable de elegir la mejor ruta de acceso a
cualquier dato.
El gestor de recuperación local: es el responsable de asegurar que la base de datos local
permanezca consistente aunque se presenten fallos.
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p.32.
Página 31 de 190
1 Marco Teórico.
IGUDES. MTD.
El procesador de soporte a tiempo de ejecución: es la interface con el sistema operativo y
contiene al administrador del buffer de la base de datos, el cual es el responsable de mantener la
memoria principal del buffer y el acceso a los datos.
f)
Arquitectura de sistemas Multi Bases de Datos (MDBS)
Los sistemas MDBS representan los casos donde DBMS individuales (distribuidos o no) son
completamente autónomos y no se basan en el concepto de cooperación, incluso no conocen de la
existencia el uno del otro o como entablar comunicación entre ellos. Son también llamados sistemas de
integración de datos.
La diferencia fundamental entre un MDBS distribuido y un DBMS distribuido, radica en la definición del
esquema conceptual global. En el caso de la integración de la lógica en un DBMS distribuido, el esquema
conceptual global define la vista conceptual de la base de datos entera, mientras que en el caso de un
MDBS distribuido esta representa solo una colección de algunas bases de datos locales que cada DBMS
desea compartir.
Los DBMS individuales pueden optar o no, por hacer accesibles su datos a otros DBMS a través de la
definición de un esquema de exportación (por ejemplo, arquitecturas de bases de datos federadas) (10).
De esta manera, la definición de base de datos global es diferente en el ámbito de los MDBS. En un
DBMS distribuido, la base de datos global es equivalente a la unión de las bases de datos locales,
mientras en un MDBS es solo un subconjunto de esa unión. En un MDBS el GCS (esquema intermedio),
está definido por la integración de los esquemas externos de las bases de datos locales autónomas o
bien por los esquemas conceptuales locales. Por otra parte, los usuarios de un DBMS local pueden
definir sus propias vistas sobre la bases de datos locales y no requieren hacer cambios dentro de sus
aplicaciones, si es que desean acceder a datos almacenados en otras bases de datos, este es otro
ejemplo de autonomía.
La principal diferencia entre el diseño del GCS en los MDBS distribuidos y la integración lógica en los
DBMS distribuidos, es que en el primero, el mapeo se realiza desde el esquema conceptual local a un
esquema global, esto es debido, a que en un MDBS el diseño es un proceso de abajo hacia arriba.
Una vez que se ha diseñado el GCS, las vistas del esquema global pueden ser diseñadas por los usuarios
que requieren acceso global. No es necesario que el GES y el GCS estén definidos usando el mismo
modelo de datos o el mismo lenguaje, sin embargo el hacerlo o no determina si el sistema es
homogéneo o heterogéneo.
Si la heterogeneidad existe en el sistema, entonces existen dos formas de implementación: uniligual y
multilingual. En un MDBS unilingual se requiere que los usuarios utilicen diferentes modelos de datos y
lenguajes cuando se accede tanto a la base de datos local como a la global.
En contraparte la filosofía de una arquitectura multilingual, es permitir a los usuarios acceder a la base
de datos global (datos de otra base de datos) a través de un esquema externo usando el lenguaje del
DBMS local.
La principal diferencia entre un MDBS distribuido y un DBMS distribuido es que cada DBMS gestiona
directamente las bases de datos, en cambio un MDBS proporciona una capa de software que se ejecuta
en un nivel superior a los DBMS individuales y este es quién brinda a los usuarios las facilidades de
acceso a las bases de datos, tal como se muestra en la figura 1.14 (5).
Hay que tener en cuenta que un MDBS, la capa intermediara puede ejecutarse en varios sitios o bien en
un sitio centralizado que ofrezca estos servicios. Por otra parte, hay que aclarar que esta capa es
simplemente otra aplicación que envía peticiones y recibe respuestas.
(10)
(5)
Heimbigner, D. McLeod, D.,”A federated architecture for informationmanagement”, pp. 253-27
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 35.
Página 32 de 190
1 Marco Teórico.
IGUDES. MTD.
Una de las implementaciones más comunes de la arquitectura MDBS es la mediador/envoltura
(mediator/wrapper, por sus siglas en inglés) (11).
El mediador es un modulo de software que explota conocimiento a partir de ciertos conjuntos y/o
subconjuntos de datos para posteriormente crear información en una capa superior de aplicaciones, de
esta manera cada mediador desempeña un función en particular a través de interfaces claramente
definidas. Las aplicaciones pueden construirse en capas ya que un mediador puede ser construido a
partir de otro u otros mediadores. De acuerdo a la figura 1.13, el mediador es representado por el nivel
donde se implementa el GCS, este es el nivel que se encarga de las consultas de usuario y el que realiza
en sí la funcionalidad del MDBS.
(5)
Figura 1.12. Componentes de un DBMS Distribuido
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:35
(11)
(5)
Wiederhold, G., “Mediators in the architecture of future information systems”, pp. 38-49
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 35.
Página 33 de 190
1 Marco Teórico.
IGUDES. MTD.
(5)
Figura 1.13. Arquitectura MDBS
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:36
Por su parte las envolturas (wrappers) son las que realizan el mapeo entre las vistas de los DBMS fuente
y una vista del mediador o de los mediadores, esto para hacer frente con la heterogeneidad inherente a
los distintos DBMS. Por ejemplo, si la fuente es un DBMS relacional, pero los mediadores son orientados
a objetos, el mapeo requerido entre ambos será establecido por la envoltura. El rol y funciones exactas
de los mediadores difieren de una implementación a otra. En algunos casos los mediadores no se
implementan para ninguna otra cosa que no sea únicamente el traslado de datos. En otros casos las
envolturas se hacen cargo de algunas funcionalidades de la consulta, como por ejemplo de los
ordenamientos (función sort).
(5)
Figura 1.14. Componentes de un MDBS
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:38
Se puede considerar al conjunto de mediadores como un middleware que brinda servicios en un nivel
más arriba de los DBMS origen.
1.3.6. Integración de Bases de Datos
La integración de bases de consiste en un proceso de diseño mediante el cual una serie de bases de datos
existentes se unifican en una sola. Este proceso es del tipo de abajo hacia arriba el cuál es el apropiado
para el diseño de MDBS.
En términos más formales, el proceso consiste en integrar los esquemas de las bases de datos locales en una
base de datos global con su esquema conceptual global (GCS), también llamado esquema intermedio.
La integración de bases de datos puede ser física o lógica. En el caso de la integración física, las bases de
datos fuente son integradas y la base de datos resultante es materializada, esta última es conocida como
Datawarehouse. La integración es soportada por herramientas de extracción – transformación - carga
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 36,38.
Página 34 de 190
1 Marco Teórico.
IGUDES. MTD.
(ETL, extract –transform –load, por sus siglas en inglés), las cuales permiten la extracción de datos de
diferentes fuentes, estos son transformados de tal forma que coincidan con el esquema global y
posteriormente son cargados para generar la base de datos materializada.
Extracción
Transformación
Carga
Base 1
Herramientas
Base 2
de ETL
Base de datos Global
Materializada
Base 3
Figura 1.15 Aproximación de un Datawarehouse
Fuente: Elaboración Propia
Una Integración de Aplicaciones Empresariales (EAI, Enterprise Application Integration, por sus siglas en
inglés), permite el intercambio de datos entre aplicaciones realizando operaciones de transformación,
aunque los datos no sean totalmente materializados (figura 1.15). En la integración lógica, el esquema global
(o intermedio) es enteramente virtual y no se materializa, este proceso es conocido como Integración de
Información Empresarial (EII, Enterprise Information Integration, por sus siglas en inglés). Estos dos
enfoques son complementarios y abordan diferentes necesidades:
El datawarehousing da soporte a aplicaciones diseñadas para la toma de decisiones, comúnmente
están basadas en el Procesamiento Analítico en Línea (OLAP, On-Line Analytical Processing, por sus
siglas en inglés)(12). Ejemplos de estas aplicaciones pueden ser las de análisis de tendencias o
pronósticos. Se analizan datos históricos, que reflejan el resumen de datos provenientes de bases de
datos operativas. Ejecutan consultas complejas sobre tablas potencialmente grandes.
En contraste, las aplicaciones basadas en el Procesamiento Transaccional en Línea (OLTP, On-Line
Transaction Processing, por sus siglas en inglés), como por ejemplo aplicativos para reservaciones en
línea o sistemas bancarios se consideran de alto rendimiento orientadas a transacciones, se requiere
de un gran control de datos y disponibilidad, alto rendimiento multi usuario, sus respuestas son
predecibles y rápidas.
Uno de los inconvenientes en el procesamiento OLAP es que el tiempo de respuesta puede llegar a ser
pobre dada la gran cantidad de datos que se necesitan transferir a través de la red.
1.3.6.1. Metodología de Diseño de Abajo hacia Arriba
Este diseño se refiere al proceso por medio del cual la información proveniente de las diferentes bases de
datos participantes pueden ser integradas (tanto físicamente como lógicamente) para formar una multi base
de datos coherente.
Existen dos enfoques alternativos:
Si lo que se define primero es el esquema conceptual global (GCS), el proceso de abajo hacia arriba
implica el mapeo de los esquemas locales (LCS) hacia el GCS. Como ya se ha comentado, es el caso
de los datawarehouses.
El otro caso, es definir al GCS como una integración de los LCS, en este caso el diseño de abajo hacia
arriba consiste en la generación del GCS y el mapeo de los LCS individuales hacia su GCS(5).
(12)
(5)
Cood, E., “Twelvw rules foro n-line analytical processing”, p.1.
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 133.
Página 35 de 190
1 Marco Teórico.
IGUDES. MTD.
De acuerdo a estos enfoques, las relaciones entre el GCS y los LCS, puede ser de dos tipos (13):
Local como vista (LAV, Local-as-View, por sus siglas en inglés): El GCS está previamente definido y
cada LCS es tratado como una vista del GCS. Los resultados de la consulta están restringidos a un
conjunto de objetos en los DBMS locales.
Global como vista (GAV, Global-as-View, por sus siglas en inglés): El GCS, es definido como un
conjunto de vistas de los LCS. Los resultados de las consultas se restringen a un conjunto de objetos
definidos en GAV.
El Diseño de abajo hacia arriba, en general ocurre en dos pasos:
Conversión de Esquema (o conversión simple). Los esquemas de las bases de datos son convertidos
a una representación canoníca común intermedia (InS, ver figura 1.17). El uso de una representación
canoníca facilita el proceso de conversión al reducir el número de traductores. Esta etapa solo es
necesaria si los componentes de las bases de datos son heterogéneos y si los esquemas locales han
sido definidos usando diferentes modelos de datos (modelo entidad relación/orientado a
objetos/XML, etc.).
Generación de Esquema. En este paso, los esquemas intermedios son usados para generar un GCS, y
se conforma de los siguientes procesos:
1. Correspondencia de esquemas: Se determina las correspondencias sintácticas y semánticas
entre los elementos traducidos de los LCS o entre los elementos individuales de los LCS y los
elementos pre definidos del GCS.
2. Integración de esquemas: Se refiere a la integración de los LCS en el GCS (o esquema
intermedio) si es que este aun no ha sido definido.
3. Mapeo de esquemas: Determina como deben ser mapeados los elementos de cada LCS a otros
elementos del GCS.
Los objetos son expresados
como consultas sobre los
DBMS fuente
GAV
Los objetos
son accesibles
a través del
CGS
Los objetos son expresados
como consultas sobre el CGS
LAV
DBMS
Fuente1
...
(14)
DBMS
Fuenten
Figura 1.16 Mapeos GAV y LAV
Fuente: Koch, C. Data Integration against Multiple Evolving Autonomous Schemata, 2001: 133.
(13)
Lenzerini, M., ”Data integration: a theoretical perspective”, pp. 236-246
Koch, C., ”Data Integration against Multiple Evolving Autonomous Schemata”, pp. 133-134
(14)
Página 36 de 190
1 Marco Teórico.
IGUDES. MTD.
(5)
Figura 1.17 Proceso de Integración de bases de datos
Fuente: Özsu, Tamer. Principles of Distributed Database Systems, 2011:135
De acuerdo a los conceptos descritos hasta el momento, IGUDES es en gran medida un MDBS. Es un sistema
autónomo ya que cada uno de los DBMS propuestos opera independientemente uno del otro a nivel transaccional,
es distribuido ya que es una capa superior que le permite a los usuarios despreocuparse por la localización de las
fuentes de datos siendo que todas convergen en una misma interfaz y heterogéneo ya que evidentemente cada
DBMS involucrado tiene sus propios requisitos de software y hardware y pese a que estos son modelos relacionales,
existen diferencias de lenguaje, en esta línea es una arquitectura multilingual, ya que los usuarios acceden a las
bases de datos locales usando su propio lenguaje.
Finalmente se resalta el hecho de que la comprobación de coherencia de las consultas queda del lado del servidor,
es decir, la coherencia es validada dentro de los esquemas locales y no en la capa superior de este MDBS, ya que es
una middleware dedicado a enviar y recibir peticiones.
En los capítulos subsecuentes, se hará un comparativo entre los módulos del MTD contra la arquitectura propia de
los MDBS, identificando aquellos módulos que fungen como mediador y envolturas.
Se debe ver a IGUDES como una capa intermedia que explota información de diferentes fuentes de datos
heterogéneas y distribuidas, pero no hay que perder de vista que es un aplicativo web y por ello los esfuerzos
dirigidos al desarrollo de este prototipo están asociados directamente a su arquitectura e ingeniería de software. En
el siguiente apartado se abordaran estos ámbitos.
(5)
Özsu, Tamer, Valduriez, Patrick. “Principles of Distributed Database Systems”, p. 135.
Página 37 de 190
1 Marco Teórico.
IGUDES. MTD.
1.4. APLICACIONES WEB
Las aplicaciones web se han convertido en pocos años en complejos sistemas con interfaces de usuario cada vez
más parecidas a las aplicaciones de escritorio, proporcionando servicios a los procesos de negocio de
considerable envergadura y demandando de ellas requisitos estrictos de accesibilidad y respuesta, en este
apartado se pretende dar un breve acercamiento a la arquitectura de tales aplicaciones y a los patrones de
diseño más aplicables.
En los últimos años, la rápida expansión de internet y del uso de intranets corporativas ha supuesto una
transformación en las necesidades de información de las organizaciones, en particular:
Que la información sea accesible desde cualquier lugar dentro de la organización e incluso desde el
exterior.
Que esta información sea compartida entre todas las partes interesadas, de manera que todas tengan
acceso a la información completa (o a aquella que les corresponda según su función) en cada momento.
Estas necesidades han provocado un movimiento creciente de cambio en las aplicaciones tradicionales de
escritorio hacia las aplicaciones web, que por su naturaleza, cumplen casi a la perfección con las necesidades
antes mencionadas. Por tanto, los sitios web tradicionales que se limitaban a mostrar información se han
convertido en aplicaciones sofisticadas capaces de interaccionar con los usuarios de manera casi natural.
Inevitablemente, esto ha provocado un aumento progresivo de su complejidad, y por ende, la necesidad de
buscar nuevas opciones de diseño que permitan ofrecer una arquitectura óptima que facilite la construcción de
los mismos. A continuación se definirán en términos formales los elementos comunes que conforman una
arquitectura web.
Se denomina aplicación Web a aquellas herramientas que permiten a los usuarios o clientes acceder a un
servidor web a través de internet o de una Intranet mediante un navegador. Es una aplicación de software que
se codifica en un lenguaje soportado por los navegadores Web. Se identifican dos principales ventajas de este
tipo de aplicaciones:
Independencia del sistema operativo del lado del cliente, ya que en vez de crear clientes para Windows,
Mac Os, Linux, etc., las aplicaciones web se escriben una vez y se ejecutan igual en cualquier plataforma.
Facilidad para actualizar y mantener las aplicaciones sin necesidad de distribuir o aplicar los cambios a
los cientos o miles de usuarios potenciales.
Un sitio web puede contener elementos que permiten la comunicación activa entre los usuarios y la
información, como por ejemplo el llenado y envió de formularios en una aplicación de e-banking.
1.4.1. Antecedentes
Previo al surgimiento de los sistemas web, normalmente cada aplicación tenía su propio programa cliente el
cual fungía como una interfaz de usuario, este tenía que estar instalado por separado en cada uno de los
equipos usuario. El cliente realizaba peticiones a otro programa (servidor) que le entregaba la respuesta. El
hecho de implementar una mejora en el servidor requería normalmente una serie de modificaciones en los
programa cliente, esto significaba un aumento en los costos de mantenimiento y disminución de la
productividad. A este tipo de sistemas se les conoce como aplicaciones de escritorio.
A diferencia de las aplicaciones de escritorio, los sistemas web generan una serie de páginas en un formato
estándar como HTML (Hyper Text Markup Language, por sus siglas en inglés) o XHML (Extensible Hyper Text
Markup Language, por sus siglas en inglés), soportados por los navegadores más comunes (Microsoft IE,
Mozilla Firefox, Opera, Google Chrome, etc.). Se utilizan lenguajes interpretados (lenguajes que están
diseñados para ser ejecutados mediante un intérprete) del lado del cliente para añadir elementos dinámicos
a la interfaz de usuario tales como javascript, vbscript o a través de plugins como Flash. En contraste, del
lado del servidor, se procesan las peticiones de los clientes haciendo uso de los lenguajes compilados, como
java, C#, C++, entre otros.
Página 38 de 190
1 Marco Teórico.
IGUDES. MTD.
1.4.2. World Wide Web (www)
Es un sistema de distribución de información basado en hipertexto o hipermedios enlazados y accesibles a
través de internet. Con un navegador Web un usuario puede visualizar sitios compuestos de páginas web,
que pueden contener texto, imágenes, videos u otros contenidos multimedia (15).
Dentro de una arquitectura web la www funge como una capa intermedia entre los clientes que solicitan
información y los servidores quienes responden a esas peticiones:
Figura 1.18 World Wide Web
Fuente: Elaboración propia.
1.4.3. HTML (Lenguaje de Marcas de Hipertexto)
Es el lenguaje que se utiliza para la publicación de documentos en la web. Una de sus funciones es la de
definir el contenido de dichos documentos (atributos), por ejemplo, su identificador, formato (colores,
fuentes, tamaños, bordes, etc.), tipo de objeto (tabla, frame, etiqueta, etc.), entre otros.
Es un estándar para la distribución de información a nivel mundial y está íntimamente ligado al protocolo
TCP/IP.
Propiamente no es un lenguaje de programación, ya que con HTML se generan documentos, más no
aplicaciones. Un documento HTML es un archivo de texto con instrucciones que un programa navegador
interpreta, dichas instrucciones se introducen mediante marcas denominadas etiquetas (tags).
El HTML sirve como un administrador de la presentación de información de la www, esta información esta
originalmente contenida en un servidor y es solicitada por un cliente utilizando el protocolo HTTP (15).
Un documento HTML está conformado principalmente por dos partes:
Encabezado: Indica el inicio del documento y contiene información general.
Cuerpo: Contiene los datos relevantes del documento y no es sensitivo a mayúsculas y minúsculas.
1.4.4. HTTP (Protocolo de Transferencia de Hipertexto)
En su mayoría las conversaciones entre clientes y servidores se realizan a través de este protocolo. Un
protocolo se define como una serie de reglas que determinan la manera en la que dos o más entidades
deberán comunicarse (15). Dado lo anterior la estructura de una conversación HTTP es una secuencia de dos
eventos llamados: solicitud y respuesta:
Figura 1.19 Conversación HTTP
Fuente: Elaboración propia.
(15)
León, Alberto, Indra, Widja,“Communication Networks: Fundamental Concepts and Key Architectures”.
Página 39 de 190
1 Marco Teórico.
IGUDES. MTD.
1.4.5. Arquitectura Web
El usuario interactúa con las aplicaciones web a través del navegador. Como consecuencia de la actividad del
usuario, se envían peticiones al servidor, donde se aloja el aplicativo y que normalmente hace uso de una
base de datos que almacena toda la información relacionada con la misma. El servidor procesa la
información y devuelve la respuesta al navegador que la presenta al usuario. Por tanto, se identifican tres
componentes principales:
El navegador: que presenta la interfaz al usuario.
La aplicación: que se encarga de realizar las operaciones necesarias según las acciones disparadas
por los usuarios.
La Base de Datos: donde se almacena la información relacionada con la aplicación.
Esta distribución se conoce como modelo o arquitectura de tres capas.
Figura 1.20 Arquitectura web de tres capas
Fuente: Elaboración propia.
En la mayoría de los casos el navegador, suele ser un mero presentador de información (modelo de cliente
delgado) y no lleva a cabo ningún procesamiento relacionado con la lógica del negocio. No obstante, con la
utilización de lenguaje del lado del cliente como javascript y DHTML la mayoría de los sistemas se sitúan
entre un punto intermedio entre un modelo de cliente delgado y un modelo de cliente grueso (donde el
cliente realiza el procesamiento de la información y el servidor solo es el responsable de la administración
de datos). Sin embargo en la mayoría de los casos asociados al modelo de cliente grueso, el procesamiento
suele estar relacionado a aspectos de la interfaz (como ocultar y mostrar objetos en función de
determinados eventos) y casi nunca con la lógica del negocio. Ortogonalmente a cada uno de los elementos
dispuestos en la figura 1.20, se definen los tres niveles de esta arquitectura:
1. Nivel de Presentación: es el encargado de generar la interfaz de usuario en función de las acciones
ejecutadas por el cliente.
2. Nivel de Negocio: contiene toda la lógica que modela los procesos de negocio, y es donde se realiza
todo el procesamiento necesario para atender a las peticiones de usuario.
3. Nivel de administración de datos: es el encargado de hacer persistente toda la información, almacena y
administra los datos para el nivel de negocio.
Los dos primeros y parte del tercero (en el caso del código que realiza las actualizaciones y consultas),
suelen estar en el servidor mientras que la parte restante del tercer nivel es la propia base de datos (en el
caso del uso de procedimientos almacenados en la base de datos, una parte del segundo nivel también
puede encontrarse en esta).
Teniendo en cuenta las características antes mencionadas de la arquitectura web, a continuación se
comentarán algunos patrones de diseño básicos.
1.4.5.1. Modelo Vista Controlador (MVC)
Uno de los patrones que ha demostrado ser fundamental en el diseño de aplicaciones web es el ModeloVista-Controlador. Este, propone la separación en distintos componentes: la interfaz de usuario (vistas), el
modelo de negocio y la lógica de control. Una vista es una fotografía del modelo (o una parte del mismo) en
un determinado momento. Un control recibe un evento disparado por el usuario a través de la interfaz,
accede al modelo de manera adecuada y realiza una acción en concordancia al evento recibido, y finalmente
presenta en una nueva vista el resultado de dicha acción. Por su parte, el modelo consiste en el conjunto de
objetos que modelan los procesos de negocio que se realizan a través del sistema.
Página 40 de 190
1 Marco Teórico.
IGUDES. MTD.
En términos más sencillos, las vistas serían las páginas HTML que el usuario visualiza en el navegador. A
través de estas páginas el usuario interactúa con la aplicación, enviando eventos al servidor a través de
peticiones HTTP. En el servidor se encuentra el código de control para estos eventos, que en función de un
evento en concreto actúa sobre el modelo conveniente. Los resultados de la acción se devuelven al usuario
en forma de página HTML mediante la respuesta HTTP.
Cabe comentar que un punto muy importante es la separación de la vista y el modelo. El modelo suele ser
más estable a lo largo del tiempo y menos sujeto a variaciones, mientras que las vistas pueden cambiar con
frecuencia, ya sea por cambio en el medio de presentación (por ejemplo, una página HTML, un archivo PDF
o un WAP, etc.) o por necesidades de usabilidad de la interfaz o simple renovación en la apariencia de la
aplicación. Con esta separación, se asegura que las vistas pueden verse modificadas sin afectar al modelo y
viceversa. Los controladores son los encargados de hacer el puente entre las vistas y el modelo.
Figura 1.21Patrón Modelo-Vista-Controlador
Fuente: Elaboración propia.
Si tomamos como referencia la plataforma J2EE, las vistas podrían ser los archivos JSP, los controladores
serían los servlets y el modelo podría implementarse haciendo uso de EJBs u objetos (clases) Java normales
en combinación con frameworks de persistencia (acción de preservar la información de un objeto de forma
permanente –guardarla- y así mismo poder recuperarla –leerla- para que pueda ser nuevamente utilizada)
como Hibernate, Struts o bien Spring.
Respecto al nivel de negocio, no existe ninguna receta para asegurar un buen diseño. La aplicación de
patrones de diseño conocidos como el MVC y la implementación de los principios de encapsulación de
información y distribución de responsabilidad (que cada objeto haga lo que es propio), es la mejor manera
de conseguir un diseño apropiado.
Un principio que suele resultar de bastante utilidad es agrupar en servicios las operaciones de negocio
relacionadas, por ejemplo, en una aplicación de comercio virtual, se podría tener un servicio para la gestión
de usuarios, otro para la tramitación de pedidos, etc. De esta manera, si aplicamos la estrategia descrita
anteriormente, los comandos invocarían uno o más métodos de estos servicios, que serían los que
accederían a los objetos que constituyen el modelo.
En cuanto al nivel de administración de datos, este es proporcionado por el framework de persistencia
utilizado en conjunto con la base de datos propiamente dicha. Actualmente existen diversos frameworks de
persistencia de datos como, Hibernate (herramienta de mapeo objeto-relacional, facilita el mapeo de
atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación mediante
archivos XML), JDO (Java Data Objects, por sus siglas en inglés. Es una interfaz estándar basada en la
abstracción del modelo de persistencia de java), OJB (Object Relational Bridge, por sus siglas en inglés. Es
Página 41 de 190
1 Marco Teórico.
IGUDES. MTD.
una herramienta de Apache software Foundation para mapeo objeto-relacional que proporciona
persistencia transparente de objetos de java en bases de datos relacionales), etc., que realizan
automáticamente el mapeo entre objetos de la aplicación y las tablas de la base de datos relacional o
incluso se puede optar por JDBC.
Se deberá tomar en cuenta que, normalmente en una aplicación web una petición HTTP equivale a una
transacción, es decir, que si mientras se atiende una petición ocurre un error todas las acciones ejecutadas
hasta antes del error deben deshacerse. Por tanto, en función al modelo de persistencia, habrá que actuar
de manera que los cambios a la base de datos no se hagan definitivos hasta que la petición se haya
completado. La mejor forma de gestionar esta situación es a través del controlador (servlet), pues al ser el
que finaliza la petición enviando la respuesta al cliente, es el mejor lugar para asegurarse de que el flujo es
correcto y hacer definitivos los cambios en la base de datos (24).
IGUDES MTD está desarrollado bajo una arquitectura MVC haciendo uso de JDBC para la conexión con los
DBMS.
1.5. Tecnologías
Para la construcción de este middleware, se manejaron diversas tecnologías así como lenguajes de
programación. Se eligió Java como el lenguaje que soporta el aplicativo del lado del servidor, principalmente por
la independencia del sistema operativo, por otra parte la API es robusta y está bien documentada, es una
plataforma que soporta sistemas empresariales y además es un software de distribución libre. Lo anterior
genera un área de oportunidad, dado que la concepción de IGUDES es que sea una herramienta por la que los
usuarios no tengan que invertir en costos de licenciamiento.
Del lado del cliente, se trabajo con javascript para el desarrollo de la interfaz que evita el hacer llamadas o
peticiones continúas al servidor mismas que pudiera comprometer el rendimiento del aplicativo, además de que
es una tecnología que por sus propiedades mejora la interacción con los usuarios así como la presentación de
los datos. En el servidor se identifican y procesan los metadatos de las bases que conforman el sistema haciendo
uso de JDBC, para la presentación de los resultados en el cliente.
1.5.1. Java y Java Enterprise Edition (J2EE)
Java es una tecnología orientada al desarrollo de software, la cual permite realizar cualquier tipo de
programa. Se constituye de un lenguaje de programación orientado a objetos y un programa de ejecución
llamado maquina virtual (VM, virtual machine, por sus siglas en inglés). La función de la VM es la de
interpretar los archivos .class que se generan cando se compila un archivo.java.
Por otra parte J2EE, es una plataforma de programación de Java, es considerado en la actualidad como un
estándar según la JCP (Java Commmunity Process, por sus siglas en inglés) y principalmente está orientado
al desarrollo de aplicaciones para empresas, ya que permite el desarrollo de sistemas complejos que
requieren atender a un mayor número de usuarios y soporta una mayor carga de trabajo, situaciones que
con java puro no se podrían atender (23).
1.5.1.1. JDBC
JDBC (Java Database Connectivity, por sus siglas en inglés), es una API de java que permite la ejecución de
operaciones sobre bases de datos, independientemente del sistema operativo y del DBMS donde resida la
base de datos, utilizando el lenguaje SQL del modelo de la base.
El API JDBC se presenta como una colección de interfaces Java y métodos de gestión de manejadores de
conexión hacia cada modelo específico de base de datos. Un manejador de conexiones hacia un modelo de
base de datos en particular es un conjunto de clases que implementan las interfaces Java y que utilizan los
métodos de registro para declarar los tipos de localizadores a base de datos (URL) que pueden manejar. Para
utilizar una base de datos particular, el usuario ejecuta su programa junto con la biblioteca de conexión
apropiada al modelo de su base de datos, y accede a ella estableciendo una conexión, para ello provee el
localizador a la base de datos y los parámetros de conexión específicos (16).
(16)
Domínguez, M., “Acceso a bases de datos desde aplicaciones java”, pp. 35-38
Oracle®. Java EE Reference at a Glance.
(24)
Bryan Basham, Kathy Sierra, Bert Bates., “Head First Servlets and JSP”.
(23)
Página 42 de 190
1 Marco Teórico.
IGUDES. MTD.
A partir de allí puede realizar cualquier tipo de tareas con la base de datos a las que tenga permiso: consulta,
actualización, creación, modificación y borrado de tablas, ejecución de procedimientos almacenados, etc.
JDBC se maneja a través del paquete java.sql.
JDBC posibilita hacer tres aspectos(22):
Establecer una conexión con una base de datos
Enviar sentencias SQL
Procesar los resultados
El siguiente fragmento de código nos muestra un ejemplo básico de estas tres cosas:
Connection con = DriverManager.getConnection ("jdbc:odbc:wombat", "login", "password");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");
while (rs.next()) {
int x = rs.getInt("a");
String s = rs.getString("b");
fl oat f = rs.getFloat("c");}
El API JDBC comprende dos paquetes que deben ser importados.
El paquete java.sql
El paquete javax.sql, que añade capacidades de la parte servidor.
Conceptos fundamentales de JDBC(22):
DriverManager
La clase DriverManager es la capa gestora de JDBC, trabaja entre el usuario y el controlador (driver). Se
encarga de seguir el rastro de los controladores que están disponibles y establecer la conexión entre la base
de datos y el controlador apropiado.
Connection
Un objeto Connection representa una conexión a una base de datos. Una sesión con una conexión incluye
las sentencias SQL que son ejecutadas y los resultados que son devueltos a través de dicha conexión. Una
misma aplicación puede tener una o más conexiones con una sola base de datos o puede tener conexiones
con varias bases de datos diferentes.
La forma estándar de establecer una conexión con una base de datos es llamando al método
DriverManager.getConnection. Este método toma como parámetro una cadena de caracteres que
contiene una URL. La clase DriverManage trata de localizar el driver que pueda conectar con la base de
datos representada por esa URL.
Connection conn=DriverManager.getConnection (url,user,password);
Statement
Un objeto Statement se usa para enviar sentencias SQL a una base de datos. Una vez que se ha establecido
una conexión con una base de datos particular, esa conexión puede ser usada para enviar sentencias SQL.
Un objeto Statement se crea con el método creatStatement de Connection como en el siguiente fragmento
de código:
Connection con = DriverManager.getConnection(url);
Statement stmt = con.createStatement();
PreparedStatement (Hereda de Statement)
Se usa cuando se llama “n” veces la misma instrucción, permite el manejo de parámetros dinámicos y la
sentencia solo se compila una vez.
(22)
Oracle® Getting Started with the JDBC APIJDBC Overview
PreparedStatement stmt= conn.prepareStatement(sql);
Página 43 de 190
1 Marco Teórico.
IGUDES. MTD.
CallableStatemet (Hereda de Statement)
Es usada para ejecutar StoredProcedure, proporcionando métodos para mapear los parámetros de salida del
Stored Procedure.
CallableStatement cs = conn.prepareCall("{call<StoredProc>}");
ResultSet
Un ResultSet contiene todos los registros (filas) que satisfacen las condiciones impuestas en una sentencia
SQL y proporciona acceso a los datos en dichos registros a través de un conjunto de métodos get que
permiten acceder a los diferentes campos o atributos (columnas) del registro actual. Un ResultSet mantiene
un cursor que apunta al registro actual.
Figura 1.22: Relación entre las principales clases e interface en el paquete java.sql (16)
Fuente: Domínguez, M., “Acceso a bases de datos desde aplicaciones java”, pp. 35-38
1.5.1.2. Servlets
Un servlet es un objeto java que se ejecuta dentro de un contenedor de servlets. Se utiliza para la
generación de páginas web de forma dinámica a partir de los parámetros contenidos en la petición que
envía el navegador.
Los servlets son programas capaces de extender las capacidades de un servidor web y funcionan en la mayor
parte de las plataformas comerciales. A continuación se mencionan algunas de las mejoras introducidas por
la tecnología de servlets(24) :
Creación de procesos con múltiples hilos dentro de un servidor.
Creación de procesos dentro de un hilo dentro de un servidor.
Creación de procesos con múltiples hilos dentro de múltiples servidores.
a) Contenedor Web
Un contenedor web o contenedor de servlets, es el encargado de administrar el ciclo de vida de un
servlet, dado que no cuenta con un método main() al cuál llamar para que este sea ejecutado, es decir,
necesita de ayuda para que sea instanciado y para llamar a sus métodos principales doPsot() y doGet().
De esta manera el contenedor se encarga de manejar la petición y respuesta al y del servlet(24).
(16)
Domínguez, M., “Acceso a bases de datos desde aplicaciones java”, pp. 35-38
Bryan Basham, Kathy Sierra, Bert Bates., “Head First Servlets and JSP”.
(24)
Página 44 de 190
1 Marco Teórico.
IGUDES. MTD.
Solicitud
Solicitud HTTP
Navegador
Respuesta HTTP
Servidor
Web
Contenedor Web
Solicitud
SERVLET
Respuesta
Respuesta
Base de
Datos
Figura 1.22 Contenedor de Servlets
Fuente: Elaboración Propia
Se pueden agrupar las principales funciones de un contenedor de servlets en:
Proporciona soporte a la comunicación
Maneja el ciclo de vida de los servlets
Apoyo Multithreading
Mejora la seguridad de las aplicaciones
Soporte para el manejo de JSP
En el caso de IGUDES, se eligió a Tomcat como contenedor web, que brinda soporte a servlets y JSPs, el cual
fue desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Incluye el compilador Jasper,
que compila JSPs convirtiéndolas en servlets. El motor de servlets de Tomcat a menudo se presenta en
combinación con el servidor web Apache (Apache Tomcat).
b) Ciclo de Vida de un Servlet
1. El cliente envía la solicitud a través de una URL.
2. El contenedor verifica que es una llamada al servlet.
3. El contenedor crea los objetos del tipo: HttpServletResponse/HttpServletRequest.
4. El contenedor en base a la URL de petición localiza al servlet que responde a esa solicitud.
5. El contenedor crea o asigna un thread para esa solicitud y transfiere a ese thread los objetos.
6. El contenedor hace una llamada al método service(), y dependiendo del tipo de solicitud, service()
llama a su vez al método doGet() o bien a doPost().
7. El método llamado por service() genera una página dinámica y le embebe el objeto de respuesta.
8. El thread termina.
9. El contenedor convierte el objeto de la respuesta en una respuesta HTTP y la envía de regreso al
cliente.
10. Finalmente el contenedor destruye los objetos de solicitud y de respuesta.
Inicialización de un servlet: cuando un servidor carga un servlet, ejecuta el método init() del servlet,
la inicialización se completa antes de empezar a manejar las peticiones del clientes y antes de que el
servlet sea destruido. El servidor solo invoca por única vez al método init(), al crear la instancia del
servlet, y no lo llamará nuevamente a menos que vuelva a cargarlo. El servidor no podrá recargar un
servlet sin haberlo destruido previamente. Después de la inicialización, el servlet puede manejar las
peticiones del cliente.
Destrucción de un servlet: los servlets se pueden ejecutar hasta que el servidor los destruye a través
del método destroy(), este método se ejecuta solo una vez(24) .
RESPUESTA
Se inicializa con
el método init()
EN SERVICIO
service()
PETICIÓN
Figura 1.23 Ciclo de vida de un servlet
Fuente: Elaboración Propia
(24)
Bryan Basham, Kathy Sierra, Bert Bates., “Head First Servlets and JSP”.
Página 45 de 190
Se destruye con el
método destroy()
1 Marco Teórico.
IGUDES. MTD.
1.5.1.3. Java Server Pages (JSP)
Es la tecnología orientada a crear páginas web con programación java. Las JSP están compuestas de código
HTML/XML mezclado con etiquetas especiales para programar scripts del lado del servidor con sintaxis java.
Cuando se crean archivos JSP y una vez compilados, se crea un archivo .class que es implementado por un
servlet(24).
Compilación del
JSP
RESPUESTA
Creación del
servlet
Se inicializa con
el método init()
EN SERVICIO
service()
Se destruye con el
método destroy()
PETICIÓN
Figura 1.24 Ciclo de vida de un JSP
Fuente: Elaboración Propia
1.5.1.4. Diferencias entre un servlet y un JSP
Un JSP es una página web con etiquetas especiales (scriptlets) y código java incrustado.
Un servlet es un programa que recibe peticiones y a partir de estas genera una página web.
En un JSP se separa el contenido dinámico del estático.
Es recomendable utilizar JSP cuando se diseñan las vistas de los usuarios.
1.5.2. JavaScript
Es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a
objetos(17), basado en prototipos, imperativo, débilmente tipado y dinámico. Se utiliza principalmente en su
forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la
interfaz de usuario y páginas web dinámicas. Su uso en aplicaciones externas a la web, por ejemplo en
documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo.
JavaScript se diseñó con una sintaxis similar al lenguaje C, aunque adopta nombres y convenciones del
lenguaje de programación Java. Sin embargo Java y JavaScript no están relacionados y tienen semánticas y
propósitos diferentes.
Todos los navegadores modernos interpretan el código JavaScript integrado en las páginas web. Para
interactuar con una página web se provee al lenguaje JavaScript de una implementación del DOM
(Document Object Model, por sus siglas en inglés).
Tradicionalmente se utiliza en páginas web HTML para realizar operaciones y únicamente en el marco de la
aplicación cliente, sin acceso a funciones del servidor. JavaScript se interpreta en el agente de usuario, al
mismo tiempo que las sentencias van interpretándose junto con el código HTML.
1.5.3. DAO (Data Access Object)
Es un componente de software que suministra una interfaz común entre la aplicación y uno o más
dispositivos de almacenamiento de datos, tales como una Base de datos o un archivo. El término se aplica
frecuentemente al Patrón de diseño Object.
Los Objetos de Acceso a Datos son un Patrón de Diseño Core J2EE y considerados una buena práctica. La de
usar objetos de acceso a datos es que cualquier objeto de negocio (aquel que contiene detalles específicos
(17)
Ecma International. Estándar ECMA-262. Edición 5.1. 2011
Bryan Basham, Kathy Sierra, Bert Bates., “Head First Servlets and JSP”.
(24)
Página 46 de 190
1 Marco Teórico.
IGUDES. MTD.
de operación o aplicación) no requiere conocimiento directo del destino final de la información que
manipula.
Los Objetos de Acceso a Datos pueden usarse en Java para aislar a una aplicación de la tecnología de
persistencia Java subyacente (API de Persistencia Java), la cual podría ser JDBC, JDO, Enterprise JavaBeans,
TopLink, Hibernate, iBATIS, o cualquier otra tecnología de persistencia.
Usando Objetos de Acceso de Datos significa que la tecnología subyacente puede ser actualizada o cambiada
sin cambiar otras partes de la aplicación.
Para el caso de IGUDES MTD, se emplea DAO para el acceso a datos y JDBC para realizar la
persistencia, con el objetivo de separar las capas de lógica de negocio y de persistencia, pensando que a
futuro pudiera emplearse otra tecnología de persistencia(18).
1.5.4. Patrón de Diseño
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de
software y otros ámbitos referentes al diseño de interacción o interfaces (19). Un patrón de diseño resulta ser
una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas
características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares
en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes
problemas de diseño en distintas circunstancias.
Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños
serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y
todo buen arquitecto de software debería conocerlos.
De acuerdo al libro "J2EE PATTERNS Best Practices and Design Strategies", existen 5 capas en la arquitectura
J2EE:
Cliente
Presentación
Negocios
Integración
Recurso
Se explica los 15 patrones J2EE que están divididos en 3 de las capas: presentación, negocios e integración.
Capa de Presentación(19):
Decorating
Filter
Intercepting
Filter
/ Un objeto que está entre el cliente y los componentes Web. Este procesa
las peticiones y las respuestas.
Front
Controller/
Front
Component
Un objeto que acepta todos los requerimientos de un cliente y los
direcciona a manejadores apropiados. El patrón Front Controller podría
dividir la funcionalidad en 2 diferentes objetos: el Front Controller y el
Dispatcher. En ese caso, El Front Controller acepta todos los
requerimientos de un cliente y realiza la autenticación, y el Dispatcher
direcciona los requerimientos a manejadores apropiada.
View Helper
Un objeto helper que encapsula la lógica de acceso a datos en beneficio de
los componentes de la presentación. Por ejemplo, los JavaBeans pueden
ser usados como patrón View Helper para las páginas JSP.
Service
Worker
To Es como el patrón de diseño MVC con el Controlador actuando como Front
Controller pero con una cosa importante: aquí el Dispatcher (el cual es
parte del Front Controller) usa View Helpers a gran escala y ayuda en el
manejo de la vista.
(18)
Oracle® Core J2EE Patterns
- Data el
Access
Object.
Es como
patrón
de diseño MVC con el controlador actuando como Front
Core J2EE Pattern Catalog.
(19)
Página 47 de 190
1 Marco Teórico.
IGUDES. MTD.
Dispatcher View Controller pero con un asunto importante: aquí el Dispatcher (el cual es
parte del Front Controller) no usa View Helpers y realiza muy poco trabajo
en el manejo de la vista. El manejo de la vista es manejado por los mismos
componentes de la Vista.
Capa de Negocios (19):
Business Delegate
Un objeto que reside en la capa de presentación y en beneficio de los
otros componentes de la capa de presentación llama a métodos
remotos en los objetos de la capa de negocios.
Value Object/ Data
Transfer
Object/ Un objeto serializable para la transferencia de datos sobre lar red.
Replicate Object
El uso de un bean de sesion como una fachada (facade) para
Session
Facade/
encapsular la complejidad de las interacciones entre los objetos de
Session
Entity
negocio y participantes en un flujo de trabajo. El Session Facade
Facade/ Distributed
maneja los objetos de negocio y proporciona un servicio de acceso
Facade
uniforme a los clientes.
Aggregate Entity
Value
Assembler
Un bean entidad que es construido o es agregado a otros beans de
entidad.
Object Un objeto que reside en la capa de negocios y crea Value Objets
cuando es requerido.
Value List Handler/ Es un objeto que maneja la ejecución de consultas SQL, caché y
Page-by-Page
procesamiento del resultado. Usualmente implementado como beans
Iterator/ Paged List de sesión.
Service Locator
Consiste en utilizar un objeto Service Locutor para abstraer toda la
utilización JNDI y para ocultar las complejidades de la creación del
contexto inicial, de búsqueda de objetos home EJB y recreación de
objetos EJB.
Capa de Integración:
Data
Access Consiste en utilizar un objeto de acceso a datos para abstraer y encapsular
Object Service todos los accesos a la fuente de datos. El DAO maneja la conexión con la
Activator
fuente de datos para obtener y almacenar datos.
Service
Activator
Se utiliza para recibir peticiones y mensajes asíncronos de los clientes.
Cuando se recibe un mensaje, el Service Activator localiza e invoca a los
métodos de los componentes de negocio necesarios para cumplir la
petición de forma asíncrona.
IGUDES MTD, únicamente implementa los patrones de diseño J2EE MVC y DAO, Integrados en el
Modelo Cliente Servidor.
1.6.
ODBC
Es la interfaz estratégica de Microsoft para tener acceso a datos en un entorno heterogéneo de sistemas
gestores de base de datos relacionales y no relacionales (20).
(19)
Core J2EE Pattern Catalog.
ODBC Introducción a la conexión de base de datos abierta.
(20)
Página 48 de 190
1 Marco Teórico.
IGUDES. MTD.
El objetivo de ODBC es hacer posible el acceso a cualquier dato desde cualquier aplicación, sin importar qué
sistema de gestión de bases de datos (DBMS) almacene los datos. ODBC logra esto al insertar una capa
intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, entre la aplicación y el DBMS. El propósito de
esta capa es traducir las consultas de datos de la aplicación en comandos que el DBMS entienda. Para que
esto funcione tanto la aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación
debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a ellos.
El software funciona de dos modos, como un software manejador en el cliente o bien, como una arquitectura
cliente-servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde el
API ODBC hacia el DBMS. En el segundo modo para conectarse a la base de datos se crea una DSN dentro del
ODBC que define los parámetros, ruta y características de la conexión según los datos que solicite el creador
o fabricante.
Durante el proceso, la petición ha de "traducirse" a ODBC, para que éste entienda la consulta. ODBC
determina que fuente de datos contiene los datos que se piden y transmite la petición a la siguiente capa
que es la fuente de datos ODBC (ODBC data source). La fuente de datos analiza la petición y "traduce" de
nuevo la consulta a un formato que pueda ser "comprendido" por la DBMS.
En otras palabras se podría decir que el ODBC es un intermediario entre bases de datos y aplicaciones, cuya
tarea es sostener una conversación de preguntas y respuestas entre dos "sujetos" que no hablan el mismo
idioma y que gestionan sus recursos de forma diferente (20).
Es útil conocer los siguientes términos:
Fuente de Datos (DSN): Los datos a los cuales quiere acceder (como a DBMS) e información para
localizar datos (como la ruta o dirección IP).
Driver o controlador ODBC: Un fichero DLL, conectado dinámicamente (Windows) que envía
una consulta SQL para acceder a datos almacenados en una base de datos y entregar datos a la
aplicación cliente.
(20)
Figura 1.25 ODBC .
Fuente: ODBC Introducción a la conexión de base de datos abierta
(20)
ODBC Introducción a la conexión de base de datos abierta.
Página 49 de 190
1 Marco Teórico.
1.7.
IGUDES. MTD.
JDBC versus ODBC
La API ODBC de Microsoft es probablemente la interface de programación para acceder a bases de datos
relacionales más extensamente usada. Ofrece la posibilidad de conectar a casi la totalidad de bases de datos.
Entonces, ¿Por qué no usar simplemente ODBC desde Java? La respuesta es que se puede usar ODBC desde
Java, pero esto se hace mejor con la ayuda de JDBC en la forma de un Puente JDBC-ODBC.
Por otra parte, ¿Por qué se necesita JDBC? Hay varias respuestas para esta pregunta:
• ODBC no es apropiado para su uso directo desde Java porque usa una interface en C. Las llamadas desde
Java a código C nativo tienen un número de inconvenientes en la seguridad, implementación, robustez y
portabilidad de las aplicaciones.
• Una traducción literal de la OBDC API en C a una API en Java no sería deseable. Por ejemplo, Java no tiene
punteros, por su parte, ODBC hace un fuerte uso de ellos. Se puede pensar en JDBC como ODBC traducido
aun interface orientado a objetos que es natural para programadores en Java.
• ODBC es duro de aprender. Mezcla características elementales con otras más avanzadas y tiene complejas
opciones incluso para las consultas más simples. JDBC, por otro lado, fue diseñado para mantener las cosas
simples ya que permite posibilidades más avanzadas cuando se requieren.
• Una API en Java como JDBC es necesaria para conseguir una solución “puramente Java”. Cuando se usa
ODBC, el gestor de controladores (driver manager) y los controladores (drivers) deben ser manualmente
instalados en cada máquina cliente. Sin embargo, cuando el driver JDBC está escrito totalmente en Java, el
código JDBC es automáticamente instalable, portable y seguro en todas las plataformas Java desde
computadoras en red hasta mainframes.
En definitiva, la API JDBC es una interface natural de Java para las abstracciones y conceptos básicos de SQL.
Está fundamentada en ODBC por lo que los programadores familiarizados con ODBC encontrarán fácil de
aprender JDBC. JDBC mantiene las características de diseño básicas de ODBC. La gran diferencia es que JDBC
está basada y refuerza el estilo y virtudes de Java.
1.8.
OLE DB
Algunas veces escrito como OLEDB u OLE-DB, es la sigla de Object Linking and Embedding for Databases
(Enlace e incrustación de objetos para bases de datos). Es una tecnología desarrollada por Microsoft usada
para tener acceso a diferentes fuentes de información o bases de datos, de manera uniforme. OLE DB
permite separar los datos de la aplicación que los requiere. Esto se hizo así ya que diferentes aplicaciones
requieren acceso a diferentes tipos y almacenes de datos, y no necesariamente desean conocer cómo tener
acceso a cierta funcionalidad con métodos de tecnologías específicas. OLE DB está conceptualmente dividido
en consumidores y proveedores; el consumidor es la aplicación que requiere acceso a los datos y el
proveedor es el componente de software que expone una interfaz OLE DB a través del uso del Component
Object Model (COM).
Los proveedores OLE DB pueden ser creados para tener acceso a almacenes de datos que van desde simples
archivos de texto y hojas de cálculo, hasta bases de datos complejas como Oracle, Microsoft SQL Server o
Sybase ASE. Si se utiliza el proveedor OLE DB para ODBC, las consultas distribuidas pueden obtener acceso a
todos los datos ODBC de varios orígenes de datos heterogéneos. Estos orígenes de datos pueden estar
almacenados en el mismo equipo o en equipos diferentes. Microsoft SQL Server admite consultas
distribuidas utilizando OLE DB(21).
Los usuarios de SQL Server pueden utilizar consultas distribuidas para obtener acceso a lo siguiente:
Datos distribuidos almacenados en varias instancias de SQL Server.
Datos heterogéneos almacenados en varios orígenes de datos relacionales y no relacionales a los que
se obtiene acceso mediante un proveedor OLE DB.
Los proveedores OLE DB exponen datos en objetos tabulares denominados conjuntos de filas. SQL Server
permite hacer referencia a conjuntos de filas desde proveedores OLE DB en instrucciones Transact-SQL como
si fuesen tablas de SQL Server.
Consultas distribuidas,© 2012 Microsoft.
(21)
Página 50 de 190
1 Marco Teórico.
IGUDES. MTD.
En las instrucciones SELECT, INSERT, UPDATE y DELETE de Transact-SQL, se puede hacer referencia directa a
las tablas y vistas de orígenes de datos externos. Puesto que las consultas distribuidas usan OLE DB como
interfaz subyacente, éstas tienen acceso a los sistemas DBMS relacionales tradicionales con procesadores de
consultas SQL, así como a los datos administrados por orígenes de datos de diversa capacidad y sofisticación.
Siempre que el software propietario de los datos los exponga en un conjunto de filas tabular a través del
proveedor OLE DB, los datos se podrán usar en consultas distribuidas.
La siguiente ilustración muestra las conexiones entre un equipo cliente, una instancia de SQL Server y un
proveedor OLE DB.
(21)
Figura 1.26 SQL Server y proveedor OLE DB .
Fuente: Consultas distribuidas,© 2012 Microsoft
(21)
Consultas distribuidas,© 2012 Microsoft.
Página 51 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
CAPITULO II. Ventajas,Comparación y Arquitectura de IGUDES.
En este capítulo se mencionan las fortalezas de IGUDES, se describe como se integra distintas tecnologías o
conceptos en la aplicación con el fin de simplificar actividades relevantes que se ejecutan frecuentemente
sobre una base de datos y se compará contra herramientas de características similares, Así también se
describe la arquitectura usada en IGUDES, su similitud contra los nuevos paradigmas y arquitecturas de los
SGBD Distribuidos.
2.1. El objetivo de IGUDES
IGUDES fue concebido como un sistema de integración de datos, como una herramienta mediante la cual las
organizaciones tengan acceso a su información principalmente para el soporte a la toma de decisiones, generación
de reportes integrales ejecutivos, disminución en los tiempos de consulta, disminución de los costos, disminución de
los procesos operativos y mejora en el control de acceso a los usuarios. Está dirigido a usuarios intermedios, es
decir, aquellos usuarios que no son especialistas en el desarrollo de aplicaciones de base de datos y que tampoco
tienen conocimientos técnicos sobre la administración de un SMBD pero que requieren conocer la información
almacenada en sus bases de datos para proporcionar continuidad del negocio, y con tan solo un nivel básico de
conocimiento en el lenguaje SQL pueden explotar la información.
2.2. Ventajas de IGUDES
1. Evitar gastos de licencia. Es mucho mejor implementar IGUDES como herramienta explotadora de
Bases de Datos que cualquier herramienta que requiera licencia por cada terminal que la ejecute.
2. Eliminar la necesidad de espacio en la terminal. IGUDES al distribuirse vía web no requiere ser
instalado en el disco duro local, únicamente se instala en el servidor en donde se encuentre el
servidor de aplicaciones.
3. Permite una mejor administración ya que al ser una arquitectura centralizada se tiene completo control
de la administración de recursos, siendo que únicamente los administradores de IGUDES controlan el
servicio y los accesos.
4. Fortalece la seguridad ya que permite implementar un riguroso control de acceso.
5. Favorece el alto rendimiento de la terminal que lo utiliza ya que no consume espacio en disco duro y
tiene un consumo mínimo de memoria RAM, aunado a esto, evita que se tengan abiertas distintas
herramientas de explotación de datos para cada SGBD, ya que IGUDES tiene acceso a todas las bases
de datos para las cuales se cree una conexión.
6. IGUDES puede conectar cualquier base de datos que permita el acceso por medio del java database
connector (JDBC).
7. Terminal tonta o terminal gregaria es un tipo de terminal que consiste en un teclado y una pantalla de
salida, que puede ser usada para dar entrada y transmitir datos, o desplegar datos desde una computadora
remota a la cual se está conectado. Una terminal tonta, en contraste con una terminal inteligente o una
computadora personal, no tiene capacidad de procesamiento ni capacidad de almacenamiento y no puede
funcionar como un dispositivo separado o solo. Este sistema se suele implantar en "Mini PCs" de bibliotecas,
institutos y lugares públicos. Este método también se suele usar para centros especializados en educación
vía web y Organizaciones que implementan arquitecturas WEB(55).
IGUDES, favorece la tendencia de terminal tonta ya que es ideal para implementarse en un esquema
similar, sin embargo también es posible su implementación en terminales inteligentes o computadoras
personales.
(55)
Wikipedia, Terminal Tonta. Disponible en Web:<http://es.wikipedia.org/wiki/Terminal_tonta>[Consulta: 03 de Abril del 2013]
Página 52 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
8. Aplicación Web. La mayoría de las aplicaciones o herramientas de administración de base de datos son
aplicaciones de escritorio que requieren ser instaladas por cada una de las terminales que las usará,
IGUDES posee una gran ventaja ya que es una aplicación web que no requiere instalación,
únicamente se requiere invocar la dirección del servidor web que contenga la aplicación por medio de
un navegador web.
9. IGUDES funciona sobre cualquier sistema operativo que pueda ejecutar un navegador web, ejemplo
Windows, OS X, Linux, Unix etc.
10. IGUDES opera sin importar la arquitectura del procesador que lo ejecuta sea de 32 o 64 bits.
11. Es un sistema innovador, ya que no existe una herramienta comercial con las mismas características
que permita realizar las tareas que ejecuta IGUDES.
12. Reduce el tiempo de respuesta porque no se requiere trasladar la información de la base remota a la
local ya que se puede ejecutar desde IGUDES consultas distribuidas de bases de datos homogéneas y
heterogéneas.
13. Apoya de manera importante en el diseño de almacenes de Datos (DWH), ya que al permitir consultas
distribuidas homogéneas y heterogéneas los arquitectos pueden realizar cruces de información a
manera de ejemplo y obtener la estimación del resultado deseado.
14. Permite crear reportes estáticos de información centralizada o distribuida, para apoyar al nivel
estratégico en la toma de decisiones.
15. IGUDES trabaja con un mínimo de memoria RAM ejemplo 512 MB.
2.3. IGUDES VS Herramientas Comerciales.
Es difícil realizar una comparación total de las características de IGUDES contra alguna herramienta, ya que
no se tiene un competidor directo por ser una integración de diversas tendencias y estar diseñada para
satisfacer necesidades puntuales de alta demanda. Si bien hay herramientas web o de licencia libre que manipulan
sistemas manejadores de base de datos estas únicamente se enfocan a una sola base de datos, o simplemente
difieren una o algunas de las características que IGUDES provee, sin embargo se realizará una comparación de
tareas comunes dejando claro que no es una comparación de arquitecturas o paradigmas, sino la
comparación de funciones puntuales contra herramientas robustas fuertemente acopladas como Oracle XE 10g,
Consola de Administración phpMyAdmin, Sql Server Management Studio, ETL Informatica Power Center, Personal
communications DB2 y Toad.
Con el fin de realizar tal comparación, en este capitulo solo se mencionan a grandes rasgos las funciones de
IGUDES MTD ya que en el capitulo 3 se describiran a detalle cada una de sus carcteristicas.
2.3.1. IGUDES VS Consola de Administración Oracle XE 10g.
Quizá es la interfaz web de explotación de base de datos más parecida en algunos conceptos a IGUDES.
Posee una interfaz de Acceso, para la cual es necesario crear un usuario con privilegios al momento de su
instalación, o posterior a la instalación mediante un menú especifico.
Página 53 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Figura 2.1. Pantalla de Acceso a Oracle XE.
Es posible ejecutar sentencias sql ingresando al menú “SQL” y enseguida “Comandos SQL”, en esta pantalla se
digita la consulta en el área de texto y se presiona ejecutar para obtener la respuesta a la sentencia en la
división de resultados.
Figura 2.2. Pantalla de Comandos SQL.
Para la ejecución de sentencias por lote o por medio de scripts, ingresamos de la siguiente manera. SQL
>Archivos de Comandos SQL> Cargar Archivo de Comandos y se mostrará una pantalla como la que se expone
enseguida. Para adjuntar el script es necesario presionar el botón Examinar para direccionar a la carpeta donde
se encuentra el script.
Página 54 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Figura 2.3. Pantalla de Cargar Archivo de Comandos.
Una vez cargado el script presionar el botón Cargar el cual mostrará el contenido del archivo, como se
muestra a continuación. Finalmente al presionar el botón Ejecutar se acometen las sentencias.
Figura 2.4. Pantalla de Editor de Archivo de Comandos.
2.3.2. IGUDES VS Consola de Administración phpMyAdmin.
Es la herramienta web de explotación de datos para la base de datos de MySql, observemos las características
que tiene en similitud con IGUDES.
Permite un control de acceso pero es necesario crear un usuario desde la pestaña de privilegios o bien
desde la instalación de la base.
Página 55 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Figura 2.5. Pantalla de Privilegios de MySQL.
Es posible la ejecución de sentencias SQL, misma que se realiza de las siguiente manera: seleccionar la base de
datos sobre la que se ejecutará la sentencia, enseguida presionar la pestaña de SQL como se muestra a
continuación:
Figura 2.6. Pantalla de Comandos SQL de MySQL.
Página 56 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Escribir la consulta en el área de texto y presionar “Go” para que se ejecute la sentencia.
Figura 2.7. Pantalla de Resultado a Comandos SQL de MySQL.
Para acometer sentencias en grupo a manera de script, se elige la base sobre la que se desea operar,
enseguida presionar la pestaña import y presionar el botón Browse para adjuntar el script.
Figura 2.8. Pantalla de Import para Archivo de Comandos SQL de MySQL.
Página 57 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Finalmente presionar el botón “Go” para ejecutar las sentencias.
Figura 2.9. Pantalla de Resultado para Archivo de Comandos SQL de MySQL.
2.3.3. IGUDES VS Sql Server Management Studio.
Sql Server Management Studio es la herramienta de explotación de datos para
características que tiene en similitud con IGUDES.
Sql-Server, observemos las
El control de acceso se realiza mediante usuario y contraseña, los cuales se crean durante la instalación de la
base o mediante la carpeta Logins dentro de la base de datos.
Figura 2.10. Pantalla para crear un Acceso a SQL-Server.
Página 58 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
En la carpeta Logins dar click derecho y enseguida New Login, mostrará la pantalla siguiente.
Figura 2.11. Pantalla para crear un Login a SQL-Server.
Es posible la ejecución de sentencias SQL de la siguiente forma. Elegir la base de datos en la que se
ejecutará la sentencia, presionar el botón de “Nueva Consulta” en la pantalla que nos muestra se digita la
sentencia, finalmente presionar el botón “Ejecutar” y se ejecutará la sentencia.
Figura 2.12. Pantalla para crear Consultas de SQL-Server.
Página 59 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Se pueden acometer sentencias en conjunto por medio de un script de la siguiente manera: presionar el
botón “Abrir Archivo” y enseguida elegir el script a cargar.
Figura 2.13. Pantalla para Abrir Archivo de Comandos de SQL-Server.
Una vez adjuntado el archivo se mostrará el contenido del script y finalmente presionar el botón “Ejecutar” para
acometer las sentencias.
Figura 2.14. Pantalla Resultado de Archivo de Comandos de SQL-Server.
2.3.4. IGUDES VS ETL Informatica Power Center.
Informatica PC, es la herramienta de extracción, transformación y carga (ETL) de mayor demanda actualmente.
Mediante ella podemos realizar la intersección de tablas provenientes de distintos sistemas manejadores de
base de datos y obtener los registros que crucen dos o más tablas remotas en una tabla destino.
Página 60 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
La conexión a los sistemas manejadores se realiza de la siguiente manera: entrar al menú Source y ejecutar
Import from Database.
Figura 2.15. Pantalla para Importar Tabla de Informatica PowerCenter(IPC).
Enseguida crear un Origen de Datos (DSN) al sistema gestor de base de datos deseado, mediante la ventana
que se despliega a continuación.
Figura 2.16. Pantalla para Crear un DSN para Importar Tabla de Informatica PowerCenter(IPC).
Página 61 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Ingresar los datos requeridos:
Figura 2.17. Pantalla para Crear un DSN para Importar Tabla de Informatica PowerCenter(IPC).
Probamos la conexión:
Figura 2.18. Pantalla para Probar Conexión al DSN.
Página 62 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Cuando la conexión es exitosa, al acceder despliega las tablas que se encuentra en la base:
Figura 2.19. Pantalla para Seleccionar la Tabla a Importar de Informatica PowerCenter(IPC).
Con un mapa se puede realizar, por ejemplo, un join que cruza mediante atributos en común de la tabla ORACLE
contra la tabla de DB2. Resultado del cruce se origina una tabla destino de Oracle que contendrá los atributos
que cumplieron la condición de unión de ambas tablas.
Figura 2.20. Pantalla de Mapa de Informatica PowerCenter(IPC).
Página 63 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.3.5. IGUDES VS Personal Communications DB2.
El emulador de terminal Personal Communication de DB2 permite el desarrollo y administración para las bases de
datos 390 o AS/400.
Para realizar una Consulta SQL se ingresa a la consola mediante las teclas de función (F1..Fn). Enseguida se
elige la tarea que se desea realizar. Una vez que se ha elegido la función de consulta es posible escribir la
sentencia SQL sobre el área de trabajo (zona de líneas verdes, como se muestra en la figura 2.21), dicha consulta
debe cumplir con la distribución requerida, en el apartado de select colocar únicamente los atributos que se
desea recuperar, en el apartado “biblioteca” colocar la tabla que se recupera, en el apartado de “where”
colocar las condiciones de filtro y así sucesivamente. Finalmente mediante la tecla F6 se ejecuta la sentencia.
Figura 2.21. Pantalla de AS/400.
Página 64 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
A continuación se describe el proceso para realizar una consulta sobre 390. En la pantalla de inicio digitamos
14.2:
Figura 2.22. Pantalla de Menú 390.
Presionar F6 para que permita escribir una consulta SQL.
Figura 2.23. Pantalla Menú de Consulta de 390.
Página 65 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
Escribir la Sentencia.
Figura 2.24. Pantalla de Consulta de 390.
Ejecutar la sentencia con F2.
Figura 2.25. Pantalla Resultado de Consulta de 390.
Página 66 de 190
IGUDES. MTD.
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.3.6. IGUDES VS Toad.
Toad es una de las herramienta para el desarrollo y administración de bases de datos Oracle más usada en el
mercado.
El control de acceso lo realiza en función a los usuarios registrados en la base y los parámetros de
conexión, como se muestra en la siguiente imagen.
Figura 2.26. Pantalla Control de Acceso a Toad.
Para la ejecución de sentencias SQL se requiere presionar el botón “Editor”, enseguida colocar la sentencia en
el área de texto y presionar el botón “Ejecutar Sentencia” para acometer la sentencia, como se muestra a
continuación.
Figura 2.27. Pantalla Consulta de Toad.
Página 67 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Para ejecutar sentencias SQL por script, presionar el botón “Cargar desde Archivo” , elegir el archivo a cargar
y presionar el botón “abrir”.
Figura 2.28. Pantalla para Abrir Archivo de Comandos de Toad.
Mostrará el script disponible y podrá ser ejecutado mediante el botón “Ejecutar Consulta” como se muestra
enseguida.
Figura 2.29. Pantalla de Resultado al Archivo de Comandos de Toad.
Página 68 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.3.7. Evalución de Ventajas de IGUDES MTD VS Herramientas Comerciales.
A continuación se muestra un cuadro comparativo en donde se resumen las ventajas de IGUDES MTD en referencia
a las características que posee en común con otras herramientas comerciales.
Derivado de este análisis, se le asigna una calificación, que identifica si la herramienta cubre de mejor forma la
característica comparada. El indicador de calificación será de la siguiente manera:
“Si”
“Mejorar”
“No”
significa que la característica se satisface por completo.
significa que aún hay funciones que se pueden mejorar en la característica comparada.
significa que no se cubre la función.
Es importante mencionar que se comparan todas las características contempladas en el alcance de IGUDES MTD,
contra las herramientas en cuestión y no de manera contraria.
Herramienta
Validación
Competi IGUDES
MTD
dor
Característica
Aplicación Web
Si
Si
1) La ventaja de IGUDES es que, desde su
interfaz web permite un acceso simultaneo
a los distintos sistemas manejadores de
bases de datos que estén configurados.
Requiere Licencia
No
No
2) IGUDES es software libre.
No
3)La ventaja de IGUDES es que únicamente
requiere ser instalada en el servidor WEB
y las terminales que lo acceden no
requieren instalar ningún cliente, solo
contar con un explorador web.
Mejorar
Si
4)La ventaja de IGUDES es que proporciona
un control de acceso más rigoroso y
personalizado por usuario ya que este se
realiza mediante ip.
Creación de distintos perfiles de
Usuario.
Si
Si
5) IGUDES permite
distintos privilegios.
Consultas Simples a un SGBD.
Si
Si
Mejorar
Si
Consultas Múltiples (Script)
Homogéneas.
No
Si
Consultas Múltiples (Script)
Heterogéneas.
No
Si
Consultas Distribuidas Homogéneas
No
Si
Consultas Distribuidas Heterogéneas
No
Si
Requiere Instalación de algún cliente.
Control de Acceso
Oracle XE
Consultas Múltiples (Script) a un SGBD.
Php
MyAdmin
Comentarios
Si
crear
usuarios con
6) Se obtienen los mismos resultados en
IGUDES que con este producto.
7) Se obtiene los mismos resultados en
IGUDES que con este producto.
8) Para que Oracle XE pueda ejecutar
sentencias
distribuidas Homogéneas o
Heterogéneas, se requiere implementar
una arquitectura web de bases distribuidas
y realizar la correcta configuración para los
enlaces a las bases de datos. Pero solo se
conseguiría enlaces en los que intervenga
Oracle, dando ventaja a IGUDES ya que
permite enlaces entre bases distintas a
Oracle.
Generar Resultados en Archivos .txt,
.xls.
No
Si
Aplicación Web
Si
Si
9) La ventaja de IGUDES es que el resultado
permite direccionarlo a distintos formatos
de salida como Html, .txt y .xls, sin tener
que exportarlos.
Referirse al Comentario 1
Requiere Licencia
No
No
Referirse al Comentario 2
Página 69 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
Requiere Instalación de algún cliente.
IGUDES. MTD.
Si
No
Referirse al Comentario 3
Mejorar
Si
Referirse al Comentario 4
Si
Si
Referirse al Comentario 5
Si
Si
Referirse al Comentario 6
Consultas Múltiples (Script) a un SGBD.
Si
Si
Referirse al Comentario 7
Consultas Múltiples (Script)
Homogéneas.
No
Si
Consultas Múltiples (Script)
Heterogéneas.
No
Si
Consultas Distribuidas Homogéneas
No
Si
Consultas Distribuidas Heterogéneas
No
Si
10) Para que PhpMyAdmin pueda ejecutar
sentencias distribuidas,
se
requiere
implementar una arquitectura web de
bases distribuidas y realizar la correcta
configuración para el enlace a la/las bases
de datos. Pero solo se conseguiría enlaces
homogéneos por ser los únicos que
soporta MySql, contrariamente a IGUDES,
ya que permite enlaces entre bases distintas
a MySql.
Control de Acceso
Creación de distintos perfiles de
Usuario.
Consultas Simples a un SGBD.
Generar Resultados en Archivos .txt,
.xls.
Aplicación Web
Si
Si
Referirse al Comentario 9
No
Si
Referirse al Comentario 1
Requiere Licencia
si
No
Únicamente la versión SQL-Express
requiere licencia.
Requiere Instalación
Si
No
Referirse al Comentario 3
Control de Acceso
Creación de distintos perfiles de
Usuario.
Consultas Simples a un SGBD.
Si
Si
Referirse al Comentario 4
Si
Si
Referirse al Comentario 5
Si
Si
Referirse al Comentario 6
Si
Si
Referirse al Comentario 7
No
Si
Consultas Múltiples (Script)
Heterogéneas.
No
Si
Consultas Distribuidas Homogéneas
No
Si
Consultas Distribuidas Heterogéneas
No
Si
Para que Sql Server Management Studio
pueda ejecutar sentencias distribuidas
Homogéneas o Heterogéneas, se requiere
implementar una arquitectura web de
bases distribuidas y realizar la correcta
configuración para los enlaces a las bases
de datos. Pero solo se conseguiría enlaces
en los que intervenga Sql , contrariamente
a IGUDES que permite enlaces entre bases
distintas a Sql Server.
No
Si
Referirse al Comentario 9
No
Si
Requiere Licencia
Si
No
Requiere Instalación
Si
No
Si
Si
No
Si
No
Si
No
Si
No
Si
No
Si
Si
Si
Si
Si
Consultas Múltiples (Script) a un SGBD.
Sql Server
Managemen Consultas Múltiples (Script)
Homogéneas.
t Studio
Generar Resultados en Archivos .txt,
.xls.
Aplicación Web
Control de Acceso
Creación de distintos perfiles de
Usuario.
ETL
Informatica Consultas Simples a un SGBD.
Power
Consultas Múltiples (Script) a un SGBD.
Center.
Consultas Múltiples (Script)
Homogéneas.
Consultas Múltiples (Script)
Heterogéneas.
Consultas Distribuidas Homogéneas
Consultas Distribuidas Heterogéneas
Página 70 de 190
no
IGUDES no está pensada como una
herramienta ETL pero tiene como tareas
equivalentes el poder realizar cruces entre
tablas distribuidas de distintos SMDB’s,
direccionar los resultados a un archivo
plano y apoyar en la generación de
almacenes de datos.
2| Ventajas,Comparación y Arquitectura de IGUDES.
Generar Resultados en Archivos .txt,
.xls.
Aplicación Web
Si
Si
No
Si
Requiere Licencia
Si
No
Requiere Instalación
Si
No
Control de Acceso
Creación de distintos perfiles de
Usuario.
Consultas Simples a un SGBD.
Si
Si
Si
Si
Mejorar
Si
Mejorar
Si
Mejorar
Si
Mejorar
Si
No
Si
Consultas Distribuidas Heterogéneas
Generar Resultados en Archivos .txt,
.xls.
Aplicación Web
No
Si
Si
Si
No
Si
Requiere Licencia
Si
No
Requiere Instalación
Si
No
Control de Acceso
Creación de distintos perfiles de
Usuario.
Consultas Simples a un SGBD.
si
Si
si
Si
Si
Si
Si
Si
Si
Si
No
Si
Si
Si
Personal
communicat Consultas Múltiples (Script) a un SGBD.
ions DB2. Consultas Múltiples (Script)
Homogéneas.
Consultas Múltiples (Script)
Heterogéneas.
Consultas Distribuidas Homogéneas
TOAD
IGUDES. MTD.
Consultas Múltiples (Script) a un SGBD.
Consultas Múltiples (Script)
Homogéneas.
Consultas Múltiples (Script)
Heterogéneas.
Consultas Distribuidas Homogéneas
La comparación contra estas herramientas
es muy marcada a favor de IGUDES ya
que estas bases aun se manipulan mediante
consola, msima que requiere comandos por
medio de funciones preestablecidas, tiene
una interfaz gráfica poco amigable y no
permite el uso del ratón, por ello dificultan
mucho su operación ya que son poco
intuitivas y difíciles de usar.
Este es el único software de la comparación
que no es incluido en la instalación de
alguna base de datos, aun cuando no es
nativa tiene una fuerte demanda por las
tareas que permite. Debido a ello se
incluye en la comparación para demostrar
que las características de IGUDES son
similares e incluso con ventajas que podrían
colocarla también como una herramienta
con buen nivel de aceptación.
Consultas Distribuidas Heterogéneas
No
Si
Generar Resultados en Archivos .txt,
No
Si
.xls.
Un módulo para realizar modelado de
Si
No
base de datos.
Generacion de Ingenieria Inversa y
Caracteristicas que se podría agregar a
Si
No
Adelante.
IGUDES a futuro.
Agragar
un
módulo
que
muestre
el
IGUDES MTD
Si
No
plan de ejecución de la sentencia.
Monitor de Estatus de Base de Datos
Si
No
Módulo para el desarro como PL/SQL
Si
No
o Transact-SQL
Tabla 2.1. EVALUCIÓN IGUDES MTD vs COMPETIDORES.
Fuente: Elaboración Propia
Página 71 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.4. Arquitectura de IGUDES.
A continuación se describen los enfoques que inspiraron y en los que se basa la arquitectura de IGUDES .
2.4.1. Arquitectura Cliente-Servidor.
Un Sistema Gestor de Base de Datos (SGBD) con arquitectura Cliente-Servidor funciona separando limpiamente el
papel que juega el Servidor del que desempeña el Cliente. Esta arquitectura, pensada en la distribución, organiza la
ejecución de aplicaciones entre diversas máquinas conectadas por una red (generalmente LAN) que suele alcanzar a
distintas dependencias del edificio(s) donde opera (25).
2.4.2. Funcionalidad de la Arquitectura Cliente-Servidor C/S.
La funcionalidad Cliente-Servidor se basa en un modelo de interacción entre procesos de software. Los clientes
invocan y solicitan la ejecución de procesos (requests, querys, etc.) que requieren pero no poseen. Los procesos
solicitados residen en la parte Servidora. La arquitectura genérica Cliente/Servidor se organiza de forma que un
Cliente pueda solicitar servicios a varios Servidores (26).
Este tema, dedicado a la arquitectura de un solo SGBD, parte de la hipótesis de que el Servidor de Bases de Datos es
único en este tipo de arquitectura y los Clientes quedan conectados a él mediante una red (LAN casi siempre) cuya
interacción C/S se basa en el protocolo NET. Por un lado el Cliente se dedica a atender las necesidades del usuario
final, recibiendo las aplicaciones del usuario y transformándolas en otras unidades (querys) que se envían al Servidor
para solicitar su servicio. Por tanto, el Cliente envía siempre todas sus solicitudes al Servidor, mientras que el
servidor atiende solicitudes de varios Clientes.
2.4.3. Razones que justifican el uso de la arquitectura Cliente/Servidor en bases de datos.
La arquitectura C/S permite una limpia separación de objetivos y trabajos. Por un lado, cada máquina Cliente se
dirige a optimizar determinadas aplicaciones del usuario final, conocidas de antemano por quien construye el
sistema de información. El Cliente atiende a un conjunto determinado de aplicaciones (las de un tipo de usuario) y el
programador de aplicaciones es responsable de escribir programas (aplicativos) para que cada Cliente responda a las
necesidades específicas en cada máquina. Por otro lado, el diseñador y administrador de las bases de datos,
trabajará en la capa Servidora para realizar las tareas propias y relativas a diseño y administración: asignación de
roles de usuario, permisos y privilegios, definiciones de vistas, configuración de espacios de tablas, mantenimiento
de índices para un óptimo rendimiento funcional, etc. Todo ello será compartido por todos los clientes de una
arquitectura dada. En conclusión, los trabajos del Servidor se dirigen a proporcionar óptimos servicios a todos los
procesos clientes (2).
2.4.4. La consulta SQL del usuario admite dos formas de invocación diferentes.
La primera, conocida como consulta compilada de forma estática que llega al Servidor sólo una vez, allí se compila y
se almacena para ser re-llamada tantas veces como sea necesario. De esta forma, el Servidor almacena el código
compilado de la consulta en forma parametrizada y en cada invocación del cliente (típicamente un procedimiento),
basta con pasar los valores de los parámetros que en cada caso corresponda. A menudo, el Servidor que procesa
estos procedimientos es multi-hebra (multi-threaded) y cada unidad de ejecución del proceso del Servidor, para una
transacción dada, es una hebra. Los procesos del Servidor están activos permanentemente para ir recibiendo
solicitudes de los Clientes desde la cola de entrada, y dejan en la cola de salida los resultados que el Servidor obtiene
para enviárselos a cada respectivo Cliente. El dispatcher gestiona las colas del Servidor.
La segunda forma de invocación se conoce como consulta dinámica, donde el Cliente envía al Servidor la consulta
como un string de caracteres, y allí es compilada y ejecutada cada vez.
La idea global de un Sistema de Información con arquitectura C/S es que funcione en el modo de consulta estática
(compila una vez y se guarda en el Servidor), para ser re-llamada de continuo, cuantas veces se requiera su
ejecución en el Servidor. Mientras que el modo de consulta dinámica está pensado para un tipo de consulta
esporádica o no frecuente, su rendimiento es más bajo que el de la invocación estática y por tanto con un tiempo de
respuesta mayor (26).
(25)
C.Costilla, Sistemas de Bases de Datos. Conceptos, Técnicas y Lenguajes, ISBN: 84-7402-271-1, 464páginas, Servicio de
Publicaciones, ETSI Telecomunicación.
(26)
Carmen Costilla, M. J. Bas, J. Villamor: SIRIO: A Distributed Information System over a Heterogeneous Computer Network.
ACM SIGMOD RECORD, 22(1): 28-33.
Página 72 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.4.5. Arquitecturas Web.
La espectacular evolución de Internet plantea grandes retos para mejorar su potencialidad y actual forma operativa.
La tecnología world-wide-web (www) (27(28) es el medio de interconexión actual y futuro. Su ritmo de expansión y la
diversidad de usuarios crecen de forma continua y exponencial. Se conectan a Internet desde las empresas y
gobiernos (con redes de alta velocidad) hasta los individuos desde los hogares (con modems de baja velocidad).
Muchas empresas e instituciones han desarrollado su propia Intranet conectada a Internet. Los sistemas de
información así ubicados se conocen como Sistemas de Información Web, y acoplados con un SGBD se puede
proporcionar acceso rápido e inteligente a grandes cantidades de datos estructurados, como los que existen en una
base de datos (29).
La Web empezó siendo una interfaz para el acceso a documentos distribuidos, y hoy es una plataforma para
sistemas de información de todo tipo. Se trata de un paradigma que permite difundir y adquirir cualquier tipo de
información a través de su arquitectura, configurada en capas que, en el caso de un SGBD con arquitectura Web,
serían las tres que muestra la figura 2.30.
Figura 2.30. Arquitectura Web (a tres capas) de un SGBD (29).
Fuente: D., Levy A. and Medelzon A., Database Techniques for the World Wide Web.
Capa frontal (Front End) formada por una herramienta genérica llamada navegador o browser (p.ej.:
Firefox, Google Chrome o Microsoft Internet Explorer). Constituye la interfaz de la máquina del usuario para
navegar por la Web. El browser es la parte del usuario, por tanto, es el lado Cliente (descrito en C/S como 1ª
capa) ahora llamado Cliente delgado, ligero porque son mínimas las exigencias del ordenador en el cual
funciona. Se puede entender al browser como una Interfaz Gráfica de Usuario (GUI) que reside en la
máquina cliente o máquina remota del usuario.
Capa intermedia, llamada Servidor HTTP o Servidor Web que, generalmente, contiene además al Servidor
de Aplicaciones. Se puede entender a esta capa como un conjunto de programas residentes en sitios Web.
Para el caso de IGUDES Apache Tomcat.
Capa dorsal (Back End), llamada Servidor de Información o Servidor de Bases de Datos(30).
(27)
Tim Berners-Lee, Robert Cailliau, Jean-François Groff: The World-Wide Web.
Tim Berners-Lee: World-Wide Computer.
(29)
Florescu D., Levy A. and Medelzon A., Database Techniques for the World Wide Web.
(30)
C.Costilla, Sistemas de Bases de Datos. Conceptos, Técnicas y Lenguajes.
(28)
Página 73 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.4.6. Servidor Web: URLs y Protocolo HTTP.
La arquitectura Web es una variante de Cliente/Servidor, basada en el protocolo TCP/IP, en Web se instala el
protocolo HTTP (Hyper Text Transfer Protocol). Con HTTP cualquier cliente browser puede solicitar un documento a
un servidor Web usando su URL (Uniform Resource Locator). Como se muestra en la figura 2.31, la Web trabaja con
Servidores HTTP, más conocidos por Servidores Web.
El protocolo HTTP se implementa en cuatro fases:
a) Abrir la Conexión. En ella, el browser contacta con el servidor HTTP que se indica en el URL para verificar su
disponibilidad y corrección (llamado Solicitud HTTP en la figura 2.31);
b) Establecer la Conexión. Si el servidor está disponible, éste acepta la conexión y envía una confirmación al cliente
c) Enviar Solicitud. El cliente envía un mensaje al servidor solicitando un servicio y dando el nombre del recurso
invocado y los posibles parámetros de la invocación (llamado Entrada en la figura 2.31);
d) Recibir Respuesta. El servidor devuelve al cliente el resultado del servicio requerido (llamado Respuesta HTML en
la figura 2.31), y se cierra la conexión por el servidor sin retener información alguna para ser usada en conexiones
siguientes.
Figura 2.31. Detalle de la capa 2 de la Arquitectura Web de un SGBD.
Página 74 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
En la figura se observa el flujo de mensajes (unos de petición, otros de respuesta) entre el browser, el Servidor Web
y el Servidor de Aplicaciones. La primera petición del cliente se envía al Servidor Web y éste, a su vez, envía la
solicitud al Servidor de Aplicaciones que es quien invocará al Servidor de Bases de Datos. Cuando éste último
servidor realice las acciones necesarias, enviará la respuesta con la información procesada siguiendo el camino
anterior, pero ahora recorrido en dirección contraria, hasta que la respuesta llegue al browser que lanzó la
solicitud(31)
2.4.7. Funciones del Servidor de Aplicaciones.
Gestión de Componentes: Proporcionan herramientas para controlar todos los componentes y servicios de
Ejecución como la gestión de sesiones, notificaciones síncronas / asíncronas entre clientes.
Tolerancia frente a Fallos: Capacidad de recuperación frente a fallos, evitando un único punto de ruptura,
definiendo políticas de recuperación en caso de fallo de uno o varios objetos.
Balanceo de Carga: Posibilidad de enviar las peticiones a diferentes servidores dependiendo de la carga y
capacidad de cada uno de ellos.
Gestión de Transacciones: Distribución de la transacciones.
Gestión Centralizada: Gestión centralizada a través de una consola gráfica para monitorear a los clientes y
los distintos servidores o clusters.
Seguridad: Características de seguridad y gestión de usuarios y grupos.
2.4.8. Consultas a Datos heterogéneos en la Web.
A continuación se describe una de las clasificaciones de los actuales sistemas para consultar datos heterogéneos
(estructurados, semi-estructurados o nada estructurados). La figura 2.32 muestra dicha clasificación. En ella, las
cajas sombreadas se refieren al tema que nos interesan(31).
Figura 2.32. Clasificación de los Sistemas para consultar datos heterogéneos (31).
Fuente: Domenig R. and Dittrich K.R., An Overview and Classification of Mediated Query Systems
2.4.9. Arquitectura Mediador-Wrapper
Para los Sistemas Consultivos basados en el paradigma Wrapper-Mediator (figura 2.33) se propone una arquitectura
virtual ‘al-vuelo’. Su objetivo es permitir consultas distribuidas a múltiples fuentes de datos en un entorno web y su
enfoque es algo próximo a la arquitectura Multidatabases(32)(33).
Cada wrapper exporta al diccionario de datos global información sobre su esquema fuente, sus datos y sus
posibilidades consultivas. Con ello, el Mediador centraliza la información recibida de los wrappers en una vista
unificada de todos los datos disponibles (almacenados en el Diccionario de Datos global), descompone las consultas
del usuario en pequeñas consultas (ejecutables por los wrappers) toma los resultados parciales y elabora la
respuesta a la consulta del usuario web. (34) (35)
(31)
Domenig R. and Dittrich K.R., An Overview and Classification of Mediated Query Systems.
W. Litwin and A. Abdellatif, An overview of the Multidatabases Manipulation Language – MDL.
(33)
Özsu T. and Valduriez P., Principles of Distributed Database Systems.
(34)
Gio Wiederhold (1992). Mediators in the Architecture of Future Information Systems
(35)
Gio Wiederhold: Meditation to Deal with Heterogeneous Data Sources.
(32)
Página 75 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
Como se refleja en la figura 2.32, la arquitectura Mediador-Wrapper de la figura 2.33 difiere de la de los almacenes
de datos en que en la primera los datos integrados no están materializados, son virtuales.
La ventaja de este enfoque radica en que cada wrapper atiende a un dominio de información específico y particular,
sobre el que puede conocer el nivel de estructuración de sus datos fuente, su semántica (si existe), etc.
Este tipo de arquitecturas virtuales se instancian ‘al vuelo’ (on-the-fly) y están basadas en estándares del W3c
Consortium, como J2EE o ‘web-centric’ (http://www.w3.org). Dichas arquitecturas utilizan la invocación a Servicios
Web y se implementan mediante bibliotecas de Java (36).
Figura 2.33. Arquitectura Mediador-Wrapper entorno Web (37).
Fuente: Carmen Costilla, Arquitecturas de los SGBD Distribuidos
Como se menciona la integración lógica de datos, es sólo virtual y no se materializa en ninguna base de datos Global
(ver Figura 2.34). Los datos se encuentra en las bases de datos operacionales y el esquema conceptual global (GCS)
ofrece una integración virtual para realizar consultas sobre ellos.
(5)
Figura 2.34. Arquitectura Mediador-Wrapper .}
Fuente: Özsu Tamer and Valduriez P., Principles of Distributed Database Systems
(36)
Calleja A, Rodríguez MJ, Costilla C and Fernández R., A Grid Semantic Approach for a Digital ArchiveIntegrated Architecture.
Carmen Costilla, Arquitecturas de los SGBD Distribuidos.
(5)
Özsu Tamer and Valduriez P., Principles of Distributed Database Systems, third edition.
(37)
Página 76 de 190
2| Ventajas,Comparación y Arquitectura de IGUDES.
IGUDES. MTD.
2.4.10. Arquitectura Mediador-Wrapper en la Web de IGUDES.
Como propuesta resultante de la investigación realizada en el desarrollo de IGUDES, para el acceso a múltiples
fuentes de datos Web homogéneas y heterogéneas se genero una arquitectura como la siguiente:
USUARIO
WEB BROWSER
W
GES
RESULTADO EN HTML
URL + CONSULTA
W
WEB SERVER
W
SOLICITUD DE CONSULTA
RESULTADO EN HTML
MEDIATOR
JDBC (DBPROCESO.JAVA)
WAPPER 1
(TRADUCTOR)
DB-LINK
ORACLE
WAPPER 2
(TRADUCTOR)
DRIVER ODBC SQL
HSODBC
WAPPER 3
(TRADUCTOR)
DVR ODBC MySQL
HSODBC
GCS
MAPEO
INTEGRACIÓN
VIRTUAL DE DATOS
WAPPER 4
(TRADUCTOR)
ORAOLEDB
WAPPER 5
(TRADUCTOR)
LINKED SERVER
WAPPER 6
(TRADUCTOR)
DVR ODBC MySQL
OLEDB MSDASQL
WAPPER 7
(TRADUCTOR)
FEDERATED
LCS
LIS
SQL
SERVER
MySQL
ORACLE
SQL
SERVER
MySQL
MySQL
Figura 2.35. Arquitectura IGUDES.
Fuente: Elaboración Propia
Cada Wrapper se ubica conceptualmente en la parte back-end sobre cada fuente de datos. Esta arquitectura
propone un Modelo Extractor de Datos originando el esquema conceptual local (LCS) que traduce a un lenguaje
común la información proveniente de cada fuente de datos donde se tiene el esquema interno local (LIS).
Junto a ello, en la capa mediadora de esta arquitectura Web, se propone un Modelo de Unificación Semántica
originando el esquema conceptual global (GCS), donde se realiza el mapeo de esquemas e integración, generando
la unificación semántica de los conceptos. Permitiendo así obtener el esquema externo global (GES).
GES
GCS
LCS1
LCSn
LIS1
LISn
Figura 2.36. Arquitectura IGUDES
Fuente: Özsu Tamer and Valduriez P., Principles of Distributed Database Systems
Página 77 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
CAPITULO III. Desarrollo e Implementación de la Solución
Considerando la teoría y la investigación realizada, se ha desarrollado un aplicativo que reúne las condiciones
comentadas en los capítulos previos y que hace uso de las tecnologías analizadas con el fin de facilitar las funciones
DML sobre múltiples sistemas manejadores de Base de Datos mediante una sola Interfaz web.
En este capítulo se describen algunos de los componentes fundamentales para el operar de IGUDES,
enseguida se explicará cómo funciona cada uno de sus módulos y finalmente se detalla cada uno de los
enlaces entre los sistemas manejadores de base de datos que integran IGUDES.
3.1.1. Descripción del Aplicativo
Iniciamos con la descripción de los componentes de base de Datos requeridos para administrar IGUDES.
TABLA PC_USUARIO.
Es la encargada de almacenar los usuarios que pueden acceder a IGUDES, los atributos se describen a
continuación:
"USUARIO".- Almacena la descripción del usuario.
"PASSW".- Almacena la contraseña actual.
"PASSWANT".- Almacena la penúltima contraseña registrada.
"STATUS".- Almacena el estatus que indica si la cuenta se encuentra activa o inactiva, 1 activo y 0 inactivo.
"CVEPERFIL".- Almacena el perfil de la cuenta; cveperfil igual a 1 únicamente puede realizar sentencias Select,
este perfil no puede usar consultas múltiples y cveperfil igual a 2 puede acceder a los tres tipos de consulta
de IGUDES y ejecutar sentencias Insert, Update y Delete.
"FECHA_CREACION".- Almacena la fecha en que la cuenta se creó.
"FECHA_ULTMOD".- Almacena la fecha de la última modificación a la cuenta, esta es importante para determinar
los días de vigencia de la cuenta.
"CADUCIDAD".- Almacena el estatus para saber si la cuenta tiene o no caducidad, caducidad igual a 1 tiene
vigencia y caducidad igual a 0 no tiene vigencia.
"DIASCAD".- Almacena los días que la cuenta se mantiene activa, considerando la fecha_ultmod.
"IP_CLIENTE".- Almacena la IP asignada a la cuenta del usuario, una cuenta únicamente tendrá acceso desde
la IP determinada.
"CVEPRODUCTO".- Almacena el tipo de base que se puede acceder.
Página 78 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.1.Estructura PC_USUARIO
Figura 3.2.Datos PC_USUARIO
TABLA PC_DATABASE
Es la encargada de almacenar las propiedades de las base de datos a las que IGUDES tiene acceso, sus atributos se
descirben a continuacion:
"DB_NAME" .- Almadena la descripcion de la base de datos(nombre), este atributo es la llave de la tabla.
"DB_DRIVER_CLASS_NAME".-Almacena el driver JDBC requerido para conectarse a la base de datos.
"DB_URL" .- Almacena la URL de conexion a la base de datos, requerida por JDBC.
"DB_USERNAME".-Almacena el usuario con el que se accede a la base de datos.
"DB_PASSWORD".-Almacena el password con el que se accede a la base de datos.
"DB_STATUS".-Almacena el estatus para determinar si la base se encuentra activa o no, db_status igual a 1
determina que se encuentra activa.
"DB_DESCRIPCION".- Almacena la descripcion de la conexión que se muestra en la lista desplegable, base de
datos de IGUDES.
Estructura :
Página 79 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.3. Estructura PC_DATABASE
Figura 3.4. Datos PC_DATABASE
TABLA PC_USUARIO_DATABASE
Esta almacena la relación de usuario y base de datos, es decir aquí se especifica el usuario y la/las bases de
datos a las que puede tener acceso, sus atributos se describen a continuación.
"USUARIO".- Almacena el identificador de usuario, contenido en la tabla PC_USUARIO.
"DB_NAME".-Almacena el identificador de la Base de Datos, contenido en PC_DATABASE.
Página 80 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.5. Estructura PC_USUARIO_DATABASE
Datos:
Figura 3.6. Datos PC_USUARIO_DATABASE
TABLA PC_BITACORA
Es la encargada de almacenar el registro o log de acceso a IGUDES, sus atributos se describen a continuación:
"BIT_ID".- Almacena el ID de acceso (secuencia) para identificar el registro.
"USER_ID".- Almacena el identificador del usuario que ingreso.
"PASSWORD_ID".- Almacena la contraseña del usuario que ingreso.
"IP".-Almacena la IP del usuario que ingreso.
"CVEPROD".-Almacena la clave del producto del usuario que ingreso.
"RESULTADO".-Almacena el estatus del resultado del acceso, si este es 1 significa que el acceso se dio, de lo
contrario si el valor es 2 significa que no acceso y se genero un error.
Página 81 de 190
3| Desarrollo e Implementación de la Solución.
"PERFIL".-Almacena el perfil del usuario que ejecuto la consulta.
"TIMESTP".- Almacena la fecha y hora en que se genero el registro en la tabla.
Figura 3.7. Estructura PC_BITACORA
Figura 3.8. Datos BITACORA
Página 82 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
3.1.2 Procedimientos Almacenados.
Sp_Valida Acceso.
Este procedimiento almacenado se encarga de controlar y determinar el acceso a IGUDES, lo cual realiza de la
siguiente forma:
La llamada a este procedimiento requiere de 4 parámetros de entrada y retorna 4 valores:
Parámetros de entrada
Usuario
Contraseña
IPcliente
ClaveProd (Perfil)
Parámetros de Salida
Acceso (código que indica si el acceso es permitido).
Perfil (el nivel de acceso).
Error (código de error).
CodError (Descripción del error).
El procedimiento realiza lo siguiente:
1. Valida si se coloco valores para las variables Usuario y Contraseña de lo contrario retorna el valor 0
para la variable Acceso, adicional retorna el código de error y la descripción de este.
2. Si la validación de los campos es correcta, coteja los valores insertados contra la tabla PC_USUARIO
encargada de almacenar los usuarios con acceso a IGUDES, si el valor del atributo estatus retornado
por la búsqueda es 0 el usuario aun cuando se encuentra dado de alta no está activo o no tiene
permisos para ingresar a IGUDES, por el contrario si el usuario y Contraseña es encontrado y el
atributo estatus tiene valor 1 se procede a validar la IP del usuario.
3. Si ocurre cualquier otro caso se inserta un registro en la tabla que almacena el Log de Acceso
PC_BITACORA.
4. Valida si el usuario caduca o no mediante el atributo DIASCAD:
DIASCAD con valor de 1 cuando este tenga caducidad.
DIASCAD con valor de 0 cuando la cuenta sea permanente.
5. Cuando el atributo caducidad tiene valor de 1 se realiza el cálculo de días transcurridos contra los días
de caducidad otorgados y se determina si el usuario aun puede acceder o no a IGUDES.
6. En seguida se valida el tipo de perfil correspondiente al usuario, donde:
CVEPERFIL=1 tiene el privilegio de SELECT.
CVEPERFIL=2 los privilegios de SELECT, INSERT, DELETE Y UPDATE.
Sp_Actualizaacceso.
Este procedimiento almacenado se encarga de ejecutar la función de renovación de Contraseña cuando los días
de caducidad de la cuenta se cumplen, lo cual se realiza de la siguiente forma:
La llamada a este procedimiento requiere de 4 parámetros de entrada y retorna 3 valores:
Parámetros de entrada:
Usuario
Contraseña
PasswNvo (Contraseña Nueva).
CveProd (Clave Producto).
Parámetros de Salida:
p_Resultado (Resultado del procedimiento).
p_err
Página 83 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
p_err_code
El procedimiento realiza lo siguiente:
Realiza el update al atributo Contraseña de la tabla PC_USUARIO y retorna el valor de p_Resultado el cual
origina los siguientes flujos:
Cuando p_Resultado tiene valor 1, indica que el atributo Contraseña y PasswNvo son iguales por lo tanto
no se puede actualizar el valor.
Cuando p_Resultado tiene valor 3, indica que hay un error en los datos introducidos y retorna a la jsp
de csCambiaClaveAcceso.
Cuando p_Resultado tiene valor 4, indica que la actualización es exitosa y nos regresa a la jsp de
csAccesoQuery para ingresar con la nueva Contraseña.
3.1.3
Descripción del flujo de IGUDES MTD
Se describe el flujo del MTD que se compone de 12 jsp que se describen a continuación:
Figura 3.9. JavaServer Pages de IGUDES MTD.
csAccesoQuery.jsp
Esta se encarga de la autenticación y control de acceso de los usuarios registrados en IGUDES, presenta el
Acceso a IGUDES de la forma tradicional mediante dos áreas de texto en las cuales se requiere ingresar el
usuario y la Contraseña.
Página 84 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
1. Al presionar el botón “Ingresar” se ejecuta el método java script ValidaAcceso el cual se encarga de:
Validar si se introdujeron datos en las áreas de texto y si el usuario se encuentra activo.
Recuperar los valores de usuario y Contraseña e invoca la ejecución de las jsp
csValidaAccesoApp que realizarán la validación del acceso.
Figura 3.10. csAccesoQuery.jsp
csValidaAccesoApp.jsp
La jsp csValidaAccesoApp es la encargada de crear la conexión a la base de datos de administración para
IGUDES mediante los siguientes pasos:
1. Crea la conexión al SMBD ORACLE mediante el protocolo JDBC.
2. Ejecuta la llamada a la sentencia preparada que llama el stored procedure Sp_ValidaAcceso que se
encuentra en la base de administración Oracle XE de IGUDES.
3. En seguida se invoca un bloque finally que se encarga de cerrar la conexión a la base de datos
creada.
4. Posteriormente en base al resultado del procedimiento almacenado se toma el valor de la variable
iAcceso para determinar los siguientes flujos de ejecución:
Cuando iAcceso tiene valor 0, retorna a la página de Inicio con estatus de error.
Cuando iAcceso tiene valor 1, el Ingreso fue exitoso y direcciona a la pagina del menú de IGUDES, creando
la sessión y un Objetó de Acceso a Datos (DAO).
Cuando iAcceso tiene valor 2, direcciona a la página de cambio de Clave de Acceso ya que se supera
los días de caducidad de la cuenta.
csCambiaClaveAcceso.jsp
Es la encargada de validar y cambiar la contraseña para aquellos usuarios para los que que ya caduco su
acceso, lo cual realiza mediante los siguientes pasos:
1. Ingresar los siguientes datos:
Usuario al que desea cambiar la contraseña.
Contraseña actual.
Contraseña nueva.
Rectificación de la Contraseña nueva.
2. Presionando el botón CambiaPassw se invoca la función java script que ejecuta las siguientes
acciones:
Obtiene los datos de las cajas de texto.
Valida que ninguno de los campos se encuentre vacio.
Valida la nueva contraseña.
Valida que la confirmación de la contraseña sea igual a la nueva contraseña.
Realiza la llamada a la jspcsValCambioPwd, encargada de validar el cambio de la contraseña.
3. Al presionar el botón Limpiar, se ejecuta la función java script que borra el contenido de las cajas de
texto:
Página 85 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.11. csCambiaClaveAcceso.jsp
csValCambioPwd.jsp
Es la encargada de ejecutar la actualización y validación del cambio de contraseña, lo cual se realiza de la
siguiente manera:
1. Abre una conexión a la base de datos de Administración de IGUDES y mediante una sentencia
preparada, ejecuta el procedimiento almacenado Sp_Actualizaacceso que se encuentra en la base de
administración Oracle XE de IGUDES.
2. En seguida, se invoca un bloque finally que se encarga de cerrar la conexión a la base de datos y
liberar recursos.
3. Posteriormente, en base al resultado del procedimiento almacenado, se toma el valor de la variable
iResCambioPwd para determinar los siguientes flujos de ejecución:
Cuando iResCambioPwd tiene valor 0, retorna a la página csCambiaClaveAcceso.jsp pasando el
parámetro hidMensaje con valor 1 lo que determina que se mostrará el mensaje: "EL USUARIO Y/O
PASSWORD PROPORCIONADO NO SON CORRECTOS, VUELVA A INTENTAR".
Cuando iResCambioPwd tiene valor 1, retorna a la página csCambiaClaveAcceso.jsp pasando el
parámetro hidMensaje con valor 2 lo que determina que se mostrará el mensaje: "EL NUEVO
PASSWORD Y EL ACTUAL SON IGUALES, CAPTURA OTRO PASSWORD NUEVO DIFERENTE AL ACTUAL."
Cuando iResCambioPwd tiene valor 3, se mostrará el mensaje: "HUBO UN ERROR AL TRATAR DE
ACTUALIZAR ACCESO, VUELVA A INTENTARLO" al presionar el botón aceptar nos direccionará a la
página csCambiaClaveAcceso.jsp, para repetir la acción.
Cuando iResCambioPwd tiene valor 4, se mostrará el mensaje: “ACTUALIZACION EXITOSA, VUELVA A
LOGGEARSE...". Al presionar el botón aceptar, se direccionará la página csAccesoQuery.jsp, en la que se
podrá ingresar con la nueva contraseña.
Figura 3.12. csValCambioPwd.jsp
Página 86 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.13. csValCambioPwd.jsp
MENÚ_csAccesoQuery.jsp
La jsp MENÚ_csAccesoQuery es la encargada de mostrar el menú de opciones de IGUDES, mismas que se
describen a continuación:
1. Consultas Múltiples.- Direcciona el flujo de ejecución a la jsp csQueriesMultiples encargada de la
ejecución de sentencias DML por lote.
2. Consultas_Simples.- Direcciona el flujo de ejecución a la jsp csConsultaQueryXP, desde la cual se pueden
realizar dos tareas importantes: sentencias DML sobre un SMBD o sentencias DML sobre DBMS.
3. Consultas_Distribuidas.- Direcciona el flujo de ejecución a la jsp csConsultaDistribuida, desde la que se
pueden realizar sentencias DML sobre DBMS.
Figura 3.14.csAccesoQuery.jsp
Página 87 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
csQueriesMultiples.jsp
La jsp csQueriesMultiples permite la ejecución de scripts con sentencias DML sobre un SMDB, lo cual se
realiza de la siguiente manera:
1. Lo primero que realiza es verificar si existe una sesión activa misma que se origina al momento de
firmarse, si esta validación no es satisfactoria, re direcciona a la jsp csAccesoQuery para que se
introduzca usuario y contraseña, lo que impide que se use la liga de consulta en cualquier navegador
de cualquier IP sin que este tenga privilegios de acceso a IGUDES.
2. En la Interfaz se permite adjuntar el script que se desea ejecutar mediante el botón Browse.
3. Seleccionar el tipo de sentencia que se desea realizar (Select / Insert, Delete , Update) mediante la lista
desplegable “Tipo de Sql”.
4. Elegir el SMBD sobre el cual se ejecutará el script mediante la lista desplegable “Base de Datos”.
5. Elegir el tipo de formato de la salida resultante (.txt o .xls), mediante la lista desplegable “Salida de
Resultado”.
6. Activar mediante cajas de selección (checkbox) las siguientes opciones:
Mostrar encabezados.
Mostrar separadores.
Mostrar numerador de líneas.
7. Finalmente mediante el botón“Cargar” se invocará a la función de javascript ValidaArchivo, la cual realiza
las siguientes validaciones:
Si alguna de los tres cajas de selección se encuentra activa.
Si no se eligió opción para alguna de las listas desplegables.
Enseguida valida el perfil de acceso del usuario impidiendo la ejecución de cualquier sentencia
cuando este sea 3.
Finalmente direcciona la ejecución a las jsp prUploadQueryFile y prQueriesMultiples, las cuales se
encargan del proceso de carga, generación y despliegue del archivo de resultados.
Figura 3.15.csQueriesMultiples.jsp
prUploadQueryFile.jsp
Esta jsp se encarga de cargar el archivo que se especificó mediante la ruta, lo cual se realiza mediante los
siguientes pasos:
1. Crea el archivo para el cual estará dirigida la salida con todas las propiedades requeridas en la jsp
csQueriesMultiples.
2. Adicionalmente crea las rutas en las que se almacenarán tanto el archivo de entrada cargado como el
de resultados respectivamente:
C:\\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\IGUDES\Documentos\QueriesM
ulIn
C:\\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\IGUDES\Documentos\QueriesM
ulOut\
Nota: Estas rutas pueden sufrir cambios, si se despliega el proyecto en un servidor de aplicaciones.
prQueriesMultiples.jsp
Esta jsp es la encargada de presentar el archivo creado, lo cual se realiza mediante los siguientes pasos:
Página 88 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
1. Verifica que el archivo se construya de acuerdo a los requerimientos solicitados como encabezados,
separadores e índices.
2. Adicionalmente, coloca el nombre del archivó el cual se genera de la siguiente manera:
Por ejemplo, SQLMulti_10_11_2012_104638PM, donde SQLMulti es el identificador, 10_11_2012 es el día
de ejecución en formato dd_mm_yyyy, 104638PM es la hora en la que se ejecuto la consulta en
formato hhmmss(AM/PM).
3. Al hacer doble click en el nombre, invoca el método java script DescargaArch que direcciona la ejecución
a la jsp prDownloadFile (misma que se detalla a continuación) que permite abrir o guardar el archivo.
4. Pulsando el botón Regresar, direcciona a la jsp csQueriesMultiples.
Figura 3.16.1. prQueriesMultiples.jsp
Figura 3.16.2. prQueriesMultiples.jsp
csConsultaQueryXP.jsp
Es la encargada de ejecutar sentencias DML sobre un SMBD. Esto se logra mediante los siguientes pasos:
1. Lo primero que realiza es verificar si existe una sesión activa, la cual se origina al momento de la
autenticación del usuario, si esta validación no es satisfactoria, re direcciona a la jsp csAccesoQuery
para que se introduzca usuario y contraseña. Esta validación impide que se use la liga de consulta en
cualquier navegador sobre cualquier IP, sin que este tenga privilegios de acceso a IGUDES.
2. Validado lo anterior, se muestra una interfaz sencilla en la cual se elige el SMBD que deseamos
consultar mediante una lista desplegable.
3. La Interfaz presenta un área de texto en la cual se debe escribir la sentencia DML que se desea ejecutar.
4. Se debe elegir en que formato será el tipo de salida resultante, mediante la lista desplegable. Los tipos de
salida son:
HTML.- Presenta el resultado de la consulta en pantalla mediante etiquetas (tag’s) de html.
TEXTO.- Presenta el resultado de la consulta generando un archivo el cual se puede guardar con
extensiones como .txt o .xls.
5. El enlace con la leyenda menú retorna la ejecución a la jsp MENÚ_csAccesoQuery.
6. Finalmente el botón Consulta invoca el método javascript Consulta, el cual se encarga de obtener el
tipo de salida seleccionado, la base de datos requerida, valida que el área de texto no se encuentre
en blanco (sin consulta), el tipo de perfil del usuario registrado y direcciona la ejecución a la jsp
prGenDocGenerico (misma que se detalla a continuación), la cual se encarga de ejecutar la consulta.
Página 89 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.17.csConsultaQueryXP.jsp
csConsultaDistribuida.jsp
Es importante destacar que este tipo de consultas tienen la misma lógica de ejecución que la de consultas simples,
sin embargo en esta, se muestra en la lista desplegable, la base pivote unida por una flecha a la base destino, lo
cual la hace más intuitiva y fácil de usar.
Es la encargada de ejecutar sentencias DML sobre un DBMS. Esto se logra mediante los siguientes pasos:
1. Lo primero que realiza es verificar si existe una sesión activa, la cual se origina al momento de la
autenticación del usuario, si esta validación no es satisfactoria, re direcciona a la jsp csAccesoQuery para
que se introduzca usuario y contraseña. Esta validación impide que se use la liga de consulta en cualquier
navegador sobre cualquier IP sin que este tenga privilegios de acceso a IGUDES.
2. Validado lo anterior, se muestra una interfaz sencilla en la cual se elige el SMBD que deseamos consultar
mediante una lista desplegable. Es importante destacar que esta lista presenta el nombre del par de
base de datos que se estan relacionado, es decir se muestra, por jemplo: ORCL  MySQL, lo que indica
que la Base Oracle (ORCL) realiza una conexión a la base MySQL y se pueden realizar consultas de
forma distribuida considerando la base que se encuentra a la izquierda de la flecha como la pivote.
3. Gráficamente la Interfaz presenta un área de texto en la cual se debe escribir la sentencia DML que se
desea ejecutar.
4. Se debe elegir el formato del tipo de salida resultante mediante la lista desplegable. Los tipos de salida
son:
HTML.- Presenta el resultado de la consulta en pantalla mediante etiquetas (tag’s) de html.
TEXTO.- Presenta el resultado de la consulta, generando un archivo el cual se puede guardar con
las extensiones .txt o .xls .
5. El enlace con la leyenda menú retorna la ejecución a la jsp MENU_csAccesoQuery.
6. Finalmente el botón “Consulta” invoca el método java script “Consulta”, el cual se encarga de obtener
el tipo de salida seleccionado, la base de datos requerida, valida que el área de texto no se
encuentre en blanco (sin consulta), el tipo de perfil del usuario registrado y direcciona la ejecución a la
jsp prGenDocGenerico (misma que se detalla a continuación), la cual se encarga de ejecutar la consulta.
prGenDocGenerico.jsp
Esta se encarga de ejecutar la consulta escrita por el usuario, para lo cual se realizan los siguientes pasos:
1. Obtiene de la session los parámetros:
Salida seleccionada.
Base de datos requerida
Sentencia sql
las cuales se crearon en la jsp csConsultaQueryXP.
2. Crea el objeto de conexión a la base de datos de administración de IGUDES.
3. Genera el nombre del archivo en el siguiente formato: Consulta_10_11_2012_104638PM donde, Consulta
es el identificador, 10_11_2012 es el día de ejecución en formato dd_mm_yyyy, y 104638PM es la hora
en la que se ejecutó la consulta en formato hhmmss(AM/PM).
4. Valida el perfil del usuario registrado.
5. Ejecuta la sentencia SQL.
6. Realiza alguna de las dos opciones de acuerdo al tipo de salida elegido en la jsp csConsultaQueryXP:
Página 90 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Cuándo la opción de salida es 1 el resultado de la sentencia SQL se desplegará en pantalla mediante
etiquetas html.
Cuándo la opción de salida es 2 presenta el resultado en un archivo que por defecto ya tiene
extensión .xls.
7. Al dar click en el nombre del archivo generado invoca el método javascript DescargaArch que direcciona
la ejecución a la jsp prDownloadFile (misma que se detalla a continuación), que permite abrir o guardar
el archivo.
8. Finalmente el botón “REGRESAR” muestra la jsp csConsultaQueryXP.
Figura 3.18.1.prGenDocGenerico.jsp
Figura 3.18.2. prGenDocGenerico.jsp
prDownloadFile .jsp
Se encarga del proceso de descarga, permitiendo al usuario Abrir o Guardar el archivo. Esto se realiza mediante un
flujo de caracteres de entrada (FileInputStream) sobre un objeto tipo File que recibe como parámetro la ruta
proporcionada.
3.2. Funcionalidad de los Modulos de IGUDES MTD
En esta sección, se describirá la funcionalidad de los módulos del aplicativo. Estos son cuatro, mismos que
han sido clasificados por su importancia:
I.
II.
III.
IV.
I.
Módulo de Acceso y Seguridad.
Consultas Simple (sobre un SMBD).
Consultas Múltiples.
Consultas Distribuida (sobre DBMS).
Módulo de Acceso y Seguridad
El módulo de Acceso y Seguridad se divide en tres etapas:
Funciones de Administrador.- Son todas aquellas que solo puede realizar el administrador de
IGUDES. Siendo que está es una aplicación web, no se requiere configurar ni instalar más que un
browser en la terminal del usuario. Por lo tanto las funciones que únicamente puede realizar
el administrador son:
1. Agregar cuenta de usuario.
2. Crear una nueva conexión de base de datos.
3. Asignación de Base de Datos por usuario.
4. Asignar privilegio (perfil) a usuario.
5. Determinar Vigencia de la cuenta.
6. Activar o Desactivar cuenta de Usuario.
7. Administrar Log de Acceso.
Página 91 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
8. Administrar Log de consultas (cuando se ejecutan consultas poco comunes como
insert o update)
9. Cambiar usuario y contraseña.
Funciones de Usuario.- Contempla todas las funciones contempladas en el MTD:
1. Acceso a IGUDES.
2. Renovación de Contraseña.
3. Menú IGUDES.
Seguridad de IGUDES.- Es un tema que bien vale la pena tocar por separado ya que IGUDES no
deja toda la responsabilidad de la Seguridad a la base de datos o al protocolo de comunicación,
también implementa medidas eficaces que robustecen dicha característica, como:
1. Control de acceso mediante Firma.
2. Control de acceso por IP.
3. Validación de Session (por ejemplo, cuando se intenta invocar directamente a una
jsp, sin pasar por el proceso de autencticación).
4. Manejo del tiempo de session.
3.2.1.Funciones de Administrador
Con el fin de mostrar la funcionalidad de los módulos de IGUDES se describe a continuación un ejemplo práctico.
3.2.1.1. Agregar Usuario a IGUDES.
El procedimiento para agregar un usuario consta de los siguientes pasos:
Crear un registro en la tabla PC_USUARIO.
"USUARIO" =upiicsa
"PASSW" =ipn
"PASSWANT"=null, este atributo guardará un valor distinto a null, una vez que se renueve la
contraseña.
"STATUS"=1, se puede tambien asignar el valor “0”, lo que indicaría que la cuenta se encuentra
inactiva. Para mayor detalle referirse al apartado Activar o Desactivar cuenta de Usuario.
"CVEPERFIL"=1, se puede también asignar el valor “2” para tener mayores privilegios y ejecutar
mayor número de sentencias DML. Para mayor detalle referirse al apartado Asignar privilegio
(perfil) a usuario.
"FECHA_CREACION"= 15/11/12, fecha con formato dd/mm/yy en que se crea la cuenta.
"FECHA_ULTMOD"=15/11/12, cuando se crea una cuenta se asigna manualmente la fecha en que
esta es generada, esta se actualizará cada que se actualice la contraseña.
"CADUCIDAD"=1, se puede también asignar el valor “0” para modificar el tipo de caducidad. Para
mayor detalle referirse al apartado Determinar Vigencia de la cuenta.
"DIASCAD"=3, para mayor detalle referirse al apartado Determinar Vigencia de la cuenta.
"IP_CLIENTE"= 127.0.0.1, almacena la IP asignada a la cuenta del usuario, este valor solo debería
cambiar si el usr cambia de IP.
"CVEPRODUCTO" = null, este atributo esta reservado para futuros alcances de IGUDES.
PC_USUARIO antes del Insert:
Página 92 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.19. PC_USUARIO Antes de Insert.
Sentencia:
Insert into SYSTEM.PC_USUARIO
(USUARIO,PASSW,PASSWANT,STATUS,CVEPERFIL,FECHA_CREACION,FECHA_ULTMOD,CADUCIDAD,DIASCAD,IP_CLIE
NTE,CVEPRODUCTO)
values
('upiicsa','ipn','2','1',1,to_date('14/11/12','DD/MM/YY'),to_date('14/11/12','DD/MM/YY'),'1',1,'127.0.0.1',null);
PC_USUARIO después del Insert:
Figura 3.20.PC_USUARIO después del Insert
3.2.1.2. Crear una nueva conexión de base de datos.
El procedimiento para agregar un usuario consta de los siguientes pasos:
Crear un registro en la tabla PC_DATABASE.
"DB_NAME"=ORACLE_XE
"DB_DRIVER_CLASS_NAME"=oracle.jdbc.driver.OracleDriver,driverJDBC
"DB_URL"=jdbc.oracle.thin:@10.53.210.76:1521:XE, URL JDBC.
"DB_USERNAME"=system, usuario de la base de datos.
"DB_PASSWORD"=oracle, password de la base de datos.
"DB_STATUS"=1, determina que la base de datos se encuentra activa.
"DB_DESCRIPCION"=Oracle Express, descripcion de la conexión.
Sentencia:
Insert into SYSTEM.PC_DATABASE
(DB_NAME,DB_DRIVER_CLASS_NAME,DB_URL,DB_USERNAME,DB_PASSWORD,DB_STATUS,DB_DESCRIPC
ION)
values
Página 93 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
('ORACLE_XE','oracle.jdbc.driver.OracleDriver','jdbc:oracle:thin:@10.53.210.76:1522:XE','system','oracle',
1,'OracleExpress');
PC_DATABASE después del Insert:
Figura 3.21. PC_DATABASE después del Insert
Se muestra la Base ORACLE_XE, la cual se enceuntra activa en el combo de consultas simples:
Figura 3.22. Nueva conexión de base de datos.
Desactivar una base de datos:
Para desactivarla se coloca el atributo "DB_STATUS"=0, como se observa en la pantalla:
Figura 3.23. Desactivar una base de datos
Página 94 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Después de modificar el estatus de la base de datos, se puede observar que la base ORACLE_XE ya no se
muestra en el combo de selección:
Figura 3.24. Base Desactiva.
3.2.1.3. Asignación de Base de Datos por usuario.
El procedimiento para agregar un usuario consta de los siguientes pasos:
Crear un registro en la tabla PC_USUARIO_DATABASE.
USUARIO"=upiicsa, usuario contenido en la tabla PC_USUARIO.
"DB_NAME"=ORACLE_XE,Identificador de la Base de Datos, contenido en PC_DATABASE.
Sentencia:
Insert into SYSTEM.PC_USUARIO_DATABASE
(USUARIO,DB_NAME)
values
('upiicsa','ORACLE_XE');
Figura 3.25.1.PC_USUARIO_DATABASE después del insert.
IGUDES despues del Insert:
Figura 3.25.2.IGUDES despues del Insert a PC_USUARIO_DATABASE
3.2.1.4. Asignar privilegio (perfil) a usuario.
Esta tarea se realiza con el fin de asignar privilegios a una cuenta existente. IGUDES permite ejecutar
sentencias DML, mismas que se controlan mediante dos perfiles:
CVEPERFIL=1, permite ejecutar únicamente sentencias SELECT.
Página 95 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.26.1. Usuario upiicsa con cveperfil 3.
Figura 3.26.2. Usuario upiicsa con cveperfil 3.
Respuesta correcta a la sentencia select :
Figura 3.26.3. Usuario upiicsa con cveperfil 3.
INSERT con CVEPERFIL=1, observamos cómo IGUDES identifica que el perfil es erróneo y muestra el error:
Figura 3.27. Insert con cveperfil 3.
CVEPERFIL=2, permite ejecutar sentencias SELECT, INSERT, UPDATE Y DELETE.
Sentencia:
Update SYSTEM.PC_USUARIO a
set a.CVEPERFIL = 2
where
a.usuario= 'upiicsa';
Página 96 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
PC_USUARIO, después del update a CVEPERFIL:
Figura 3.28. Update con cveperfil 2.
Ejecutamos una sentencia UPDATE:
Figura 3.29. Ejecución Update con cveperfil 2.
PC_USUARIO después del update:
Figura 3.30. Repuesta del Update a FECHA_ULTMOD.
3.2.1.5.Determinar Vigencia de la cuenta.
Está funcionalidad contempla dos tareas importantes, por un lado determina si una cuenta tendrá vigencia
y por otro lado si esta vigencia esta activa, para poder fijar los días que lo estará. Estos estatus se
controlan de la siguiente manera:
Caducidad =1, indica que la cuenta tiene caducidad.
Caducidad = 0, indica que la cuenta no tendrá caducidad.
Cuándo la cuenta tiene caducidad, será necesario fijar el valor de días de Caducidad mediante el atributo
DIASCAD.
Página 97 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
DIASCAD= 1, Indica que se tiene 1 día para que la cuenta solicite renovar contraseña.
El lector puede apreciar que el usuario upiicsa tiene asignado DIASCAD=1 y CADUCIDAD=1, lo que indica
que la cuenta tiene activa la caducidad y que su password ya expiro. La siguiente vez que intente acceder
a IGUDES, requerira cambio de password.
Figura 3.31.1. Usuario con Caducidad 3.
Intentar entrar con la cuenta de upiicsa.
Figura 3.31.2. Usuario con DIASCAD=1
Solicita cambio de contraseña.
Figura 3.32. Solicitud de cambio de contraseña.
Página 98 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Se actualiza el atributo CADUCIDAD=0 para que la cuenta no expire, y cuando esto suceda el atributo
DIASCAD no se toma en cuenta.
UPDATE PC_USUARIO
SET CADUCIDAD =0
WHERE
UPPER(USUARIO)='UPIICSA'
PC_USUSARIO después del update, muestra el atributo CADICIDAD = 0.
Figura 3.33.1. Usuario con CADICIDAD 0.
Intentar entrar con la cuenta de upiicsa:
Figura 3.33.2. Usuario con CADICIDAD 0.
Permite entrar a IGUDES:
Figura 3.33.3. Usuario con CADICIDAD 0.
3.2.1.6. Activar o Desactivar cuenta de Usuario.
Esta función permite desbloquear o bloquear una cuenta, modificando el atributo STATUS de PC_USUARIO.
Probemos STATUS=1, lo que significa que la cuanta esta activa.
Página 99 de 190
3| Desarrollo e Implementación de la Solución.
PC_USUARIO con STATUS=1
Figura 3.34. Usuario con STATUS 1
Intentar entrar con la cuenta de upiicsa:
Figura 3.35. Acceso de usuario con STATUS 3.
Permite entrar a IGUDES:
Figura 3.36. Acceso de usuario con STATUS 3.
Probemos STATUS=0, lo que significa que la cuenta esta inactiva.
Se actualiza el valor de STATUS:
UPDATE PC_USUARIO
SET STATUS=0
WHERE
UPPER(USUARIO)='UPIICSA'
Figura 3.37. Update a STATUS 0.
Intentar entrar con la cuenta de upiicsa:
Página 100 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.38.1. Acceso con STATUS 0.
La cuenta no tiene acceso:
Figura 3.38.2. Acceso con STATUS 0.
3.2.1.7. Administrar Log de Acceso.
Esta función permite consultar y monitorear el log de acceso a la aplicación. El atributo RESULTADO indica
los siguientes estatus:
Valor 1, indica que el acceso fue exitoso.
Valor 2, Indica que se solicita cambio de contraseña.
Valor 3, no se permitió el acceso.
Select * from pc_bitacora
Como se puede observar, los dos últimos registros de la BITACORA, BIT_ID =148 y 149 muestran la evidencia
del ejercicio anterior:
Figura 3.39.1. Log PC_BITACORA.
Donde el registro con BIT_ID =148 muestra el atributo RESULTADO=1, el cual indica que el acceso fue
exitoso. Si se consultará la primer pantalla de acceso del ejercicio anterior (apartado 3.2.1.6.) se ratificará la
comparación de la fecha registrada en el atributo TIMESTP de PC_BITACORA contra la fecha y hora
mostrados en la siguiente pantalla:
Página 101 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.39.2. Log PC_BITACORA.
Por otra parte, el registro con BIT_ID =149 muestra el atributo RESULTADO =3, el cual indica que el acceso fue
rechazado, si consultamos la segunda pantalla de acceso del ejercicio anterior (apartado 3.2.1.6.) lo ratificaremos
comparando la fecha registrada en el atributo TIMESTP de PC_BITACORA contra la fecha y hora mostrados en la
siguiente pantalla:
Figura 3.39.3. Log PC_BITACORA.
Observando el registro con BIT_ID =146, muestra el atributo RESULTADO =2, el cual indica que se pidió
cambio de contraseña. Si consultamos la segunda pantalla de acceso del ejercicio del apartado 3.2.1.5., lo
ratificaremos comparando la fecha registrada en el atributo TIMESTP de PC_BITACORA contra la fecha y
hora mostrados en la siguiente pantalla:
Figura 3.39.4. Log PC_BITACORA.
3.2.1.8. Administrar Log de consultas.
Esta función es muy importante para el correcto funcionamiento de IGUDES ya que permite monitorear y
depurar los archivos de consulta tanto de entrada como de respuesta que se originan en el módulo
de consultas múltiples y simples.
Archivos de Entrada:
Página 102 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
\\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\IGUDES\Documentos\Quer
iesMulIn
Figura 3.40.1.Log de entrada consultas múltiples
Archivos de Salida:
\\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\IGUDES\Documentos\Quer
iesMulOut\
Figura 3.40.2. Log de salida consultas múltiples.
Archivos de Salida consultas Simples:
\\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\IGUDES\Consultas
Figura 3.40.3. Log de salida consultas simples.
Nota: Estas rutas cambiaran de acuerdo a la arquitectura en la que se despliegue IGUDES.
3.2.1.9. Cambio de contraseña.
Esta función tiene dos vertientes para el administrador:
Puede consultar el atributo passw de PC_USUARIO y proporcionar la contraseña al usuario.
Select passw from pc_usuario
Where usuario = ‘usuario’;
Aplicar un update directo al atributo passw sobre la tabla PC_USUARIO y proporcionar al usuario la
nueva contraseña.
Update pc_usuario
Set passw = ‘nuevo_password’
Página 103 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Where usuario = ‘usuario’;
3.2.2. Funciones de Usuario
3.2.2.1.Acceso a IGUDES.
Para acceder a IGUDES se realiza los siguientes pasos:
Abrir la URL: 10.53.210.76:9050/IGUDES/csAccesoQuery.jsp en algún explorador web. Los navegadores
sobre los que se realizaron las pruebas de desarrollo fueron Internet Explorer 8 y Google Chrome 26.0.
Colocar los valores de usuario y contraseña en las áreas de texto correspondientes y presionar el botón
Ingresar.
Figura 3.41.1.Acceso a IGUDES
Figura 3.41.2.Acceso a IGUDES
A continuación se presentan los diferentes casos que pueden ocurrir en el proceso de acceso, mismos que
se validan en el sistema:
a) Cuando se omite el valor de usuario y se presiona Ingresar:
Figura 3.42.1. Validación de Acceso
b) Cuando se omite el valor de contraseña y se presiona Ingresar:
Figura 3.42.2. Validación de Acceso
c) Ingresar valores erróneos en usuario y/o contraseña y presionar Ingresar:
Página 104 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.42.3. Validación de Acceso
3.2.2.2. Renovación de Contraseña.
El proceso de renovación de contraseña se realiza de la siguiente forma:
La pantalla de cambio de contraseña se mostrará cuando el usuario intente ingresar a IGUDES y
los días de caducidad de la cuenta ya se cumplieron.
Los valores actuales son:
Usuario: upiicsa
Passw: ipn
Figura 3.43.1.Renovación de Contraseña.
Intentamos ingresar a IGUDES:
Figura 3.43.2.Renovación de Contraseña.
a) Flujo de Cambio de contraseña exitoso:
Ingresamos los datos requeridos y presionamos Aceptar.
Figura 3.43.3.Renovación de Contraseña.
Página 105 de 190
3| Desarrollo e Implementación de la Solución.
Si la actualización es exitosa nos enviará la siguiente pantalla:
Figura 3.43.4.Renovación de Contraseña.
Observar los nuevos valores:
Usuario: upiicsa
Passw: sepi
Passwant: ipn
Figura 3.43.5.Renovación de Contraseña.
Validación de errores en el cambio de contraseña:
a) Omitir el valor de usuario y presionar aceptar:
Figura 3.44.1. Validación enRenovación de Contraseña.
b) Omitir el valor de la vieja contraseña y presionar aceptar:
Página 106 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
Figura 3.44.2. Validación enRenovación de Contraseña.
c) Omitir el valor de “nuevo password” o “confirma password” y presionar aceptar:
Figura 3.44.3. Validación en Renovación de Contraseña.
Figura 3.44.4. Validación enRenovación de Contraseña.
d) Colocar un valor incorrecto en el campo de “usuario” o “viejo password”:
Figura 3.44.5. Validación en Renovación de Contraseña.
Página 107 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
e) Colocar un valor diferente en los campos “nuevo password” y “confirmar password”:
Figura 3.44.6. Validación enRenovación de Contraseña.
3.2.2.3. Uso de Menú IGUDES.
El menú de IGUDES se despliega una vez que se haya validado el acceso, esté es muy intuitivo y fácil de usar,
únicamente se debe presionar sobre el enlace deseado para dirigir el flujo al tipo de consulta seleccionado.
Figura 3.45. Menú.
Dentro de la interfaz, se dispone de un botón asociado a la figura de un candado en la esquina inferior izquierda,
que al presionarlo termina la sesión actual del usuario y direcciona el flujo de ejecución a la página de Acceso.
3.3. Consultas Simples (sobre un SMBD).
La funcinalidad de este módulo es la más básica, pero con la mayor utilidad. En este módulo es posible
ejecutar sentencias select sobre cualquier sistema manejador de base de datos (SMBD) al que el usuario
tenga acceso.
1.- Seleccionar la base sobre la que se desea consultar:
Figura 3.46.1.Consultas Simple
2.-Escribir la consulta en el área de txto:
Página 108 de 190
3| Desarrollo e Implementación de la Solución.
Figura 3.46.2.Consultas Simple
3.-Elegir el formato deseado para el Resultado
Figura 3.46.3.Consultas Simple
4.-Presionar el boton CONSULTA:
Figura 3.46.4.Consultas Simple
5.- Ahora elegimos un archivo de texto como formato de salida:
Figura 3.46.5.Consultas Simple
6.-Envia el resultado a un archivo .xls
Figura 3.46.6.Consultas Simple
Página 109 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
7.-Al dar doble click sobre el nombre del archivo, nos muestra la ventana que permite Abrir, Guardar o
Cancelar el archivo.
Figura 3.46.7.Consultas Simple
8.-Si el usuario elige la opción guardar, se muestra la ventana para proporcionar la ubicacion deseada:
Figura 3.46.8.Consultas Simple
9.-Al abrir el archivo previamente guardado, se observa que se obtienen los mismos resultados que en la
consulta donde la salida fue formato HTML:
Figura 3.46.9.Consultas Simple
Finalmente al presionar el enlace MENÚ retorna a la interfaz del Menú IGUDES. Referirse al Capítulo 4
para mayor detalle sobre este módulo.
3.4. Consultas Múltiples.
Este módulo tiene como finalidad ejecutar sentencias en grupo sobre cualquier sistema manejador de
base de datos (SMBD), mediante un script y que también permite almacenar el resultado a un archivo.
1.-Crear un archivo .txt con las sentencias que se desean ejecutar en conjunto:
Página 110 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.47.1.Consultas múltiples.
2.- Presionar el botón de Examinar para cargar el archivo de consultas creado, elegir el archivo, presionar
el botón Abrir y posteriormente mostrará la ruta del archivo cargado:
Figura 3.47.2.Consultas múltiples.
3.-Elegir el tipo de sentencia SQL:
Figura 3.47.3.Consultas múltiples.
4.-Elegir la base de datos sobre la que se ejecutará las sentencias:
Figura 3.47.4.Consultas múltiples.
5.-Elegir el formato de salida para el resultado:
Página 111 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.47.5.Consultas múltiples.
6.- Elegir si se desea que el resultado presente 1 o las 3 opciones siguientes: Encabezados, Separaciones o
Numerador de Queries
Figura 3.47.6.Consultas múltiples.
7.-Presionar el botón Cargar para que muestre el archivo de respuesta de las consultas:
Figura 3.47.7.Consultas múltiples.
8.-Al dar doble click sobre el nombre del archivo, se muestra la ventana que permite Abrir, Guardar o
Cancelar el archivo.
Figura 3.47.8.Consultas múltiples.
Página 112 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
9.-Si el usuario elige guardar, mostrará la ventana para proporcionar la ubicacion deseada:
Figura 3.47.9.Consultas múltiples.
10.-Abrir el archivo guardado:
Figura 3.47.10.Consultas múltiples.
En formato de salida .xls:
Figura 3.47.11.Consultas múltiples.
Página 113 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Finalmente al presionar el enlace MENÚ retorna a la interfaz del Menú IGUDES. Referirse al Capítulo 4
para mayor detalle sobre este módulo.
3.5. Consultas Distribuidas.
Este módulo tiene la misma funcionalidad que el de consultas simples, la diferencia es que se pueden
ejecutar consultas distribuidas entre sistemas manejadores de base de datos homogéneos y
heterogéneos.
1.- Seleccionar la base sobre la que se desea consultar:
Figura 3.48.1.Consulta distribuida.
2.-Escribir la consulta en el area de texto:
Figura 3.48.2.Consulta distribuida.
3.-Elegir el formato deseado para el Resultado:
Figura 3.48.3.Consulta distribuida.
Página 114 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
4.-Presionar el boton CONSULTA:
Figura 3.48.4.Consulta distribuida.
5.- Enviar el resultado a un archivo de texto:
Figura 3.48.5.Consulta distribuida.
6.-Enviar el resultado a un archivo .xls
Figura 3.48.6.Consulta distribuida.
7.-Al dar doble click sobre el nombre del archivo, muestra la ventana que permite Abrir, Guardar o
Cancelar el archivo.
Figura 3.48.7.Consulta distribuida.
Página 115 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
8.-Si se elige guardar, nos muestra la ventana para proporcionar la ubicación deseada:
Figura 3.48.8.Consultadistribuida.
9.-Al abrir el archivo guardado, se observa que se obtienen los mismos resultados que la consulta en
formato HTML:
Figura 3.48.9.Consultadistribuida
Finalmente al presionar el enlace MENÚ retorna a la interfaz del Menú IGUDES. Referirse al Capítulo 4
para mayor detalle sobre este módulo.
3.6. Tecnologías Usadas.
Esta sección tiene como objetivo, comentar sobre las tecnologías empleadas en el desarrollo de IGUDES y explicar
de manera detallada como se realiza las conexiones entre distintos sistemas manejadores de bases de datos,
proporcionando las bases para crear la arquitectura que se acople a las necesidades de cada usuario. IGUDES
Consultas Simples trabaja con una arquitectura como la que se muestra a continuación:
Página 116 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.49. Arquitectura IGUDES MTD.
IGUDES Consultas Distribuidas trabaja con una arquitectura como la que se muestra a continuación.
Figura 3.50.Arquitectura IGUDES MTD.
3.6.1 Conexión Oracle a Oracle:
Página 117 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.51. Diagrama Oracle a Oracle.
Para acceder desde una base de datos Oracle a objetos de otra base de datos Oracle la manera más sencilla es
utilizar un DBLink(40).Un Database Link (DBLink) en Oracle es un tipo de objeto que permite realizar una conexión
desde una base de datos a otra. Su principal objetivo es ocultar el detalle de los parámetros de conexión necesarios,
facilitándo un sencillo acceso a los recursos disponibles en otras bases de datos, independientemente de que estas
se encuentren instaladas en el mismo servidor.
Para crear un DBLINK se bederan seguir los siguientes pasos (41):
1. Se crea una entrada en el archivo tnsnames.ora de la base Oracle a la que se desee conectar:
\\product\13.3.0\db_1\NETWORK\ADMIN\tnsnames.ora
XE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL = TCP)(HOST = 10.53.210.76)(PORT = 1522))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = xe)
)
)
2. Crear el DBLINK:
a) Mediante comando:
CREATE DATABASE LINK "DB_LINK"
CONNECT TO "SYSTEM"
IDENTIFIED BY VALUES '0539DE0BA208C98EF71ACA722D504ABF58'
USING 'xe';
b) Mediate SQL-Developer:
Hacer click derecho en la opción Enlaces de Bases de Datos y posteriormente en nuevo Enlaces de Bases de
Datos:
Figura 3.52. Nuevo Enlace de Datos.
(40)
Oracle® Database SQL Reference 10g Release 1.
Oracle®Database Administrator's Guide 11g Release 1.
(41)
Página 118 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
En la pantalla que se muestra, establecer la siguiente configuración:
Público: Determina si el DBLINK será público.
Esquema: Elegir con que esquema se desea crear el dblink.
Nombre: El identificador que se usará para el dblink.
Nombre del Servicio: Nombre que se coloco en el service_name del tnsnames.ora
Usuario: usuario de la base que se desea acceder.
Contraseña: contraseña de la base que se desea acceder.
Finalmente, hacer clic en Aceptar:
Figura 3.53. Editar Enlace de Datos.
3. Probar la conexión:
Para probar la conexión, se deberá hacer click derecho sobre el dblink creado y presionar probar Enlaces de
Bases de Datos.
Figura 3.54. Probar Enlace de Datos.
Página 119 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.55. Confirmación Enlace de Datos.
Una vez creado el DBLink, la manera de referenciarlo será mediante “@” seguido del nombre del enlace que se
creó:
select * from pc_usuario_database@DB_LINK
Aunque para simplificar las sentencias se puede crear un sinónimo en la base de datos. Para el caso de IGUDES
no se crearon sinónimos pero se pueden implementar si se desea de la siguiente manera:
CREATE PUBLICSYNONYM pc_usuario_database FOR pc_usuario_database @db_productos;
De forma que pueda escribirse la sentencia:
SELECT * FROM pc_usuario_database;
3.6.2 Conexión Oracle a Sql Server:
Figura 3.56. Diagrama Oracle a Sql-Server.
Para acceder desde una base de datos Oracle a objetos de una base de datos Sql Server, se puede lograr usando los
Servicios Heterogéneos de Oracle, que permite a Oracle acceder a sistemas de base de datos no Oracle a traves de
ODBC y SQL Net Services.
En el caso de IGUDES la base Oracle reside en un equipo diferente al equipo que almacena la base de datos
Microsoft SQL-Serever, pero se podría tener Oracle en el mismo equipo que la base de datos Microsoft SQL-Serever.
Para crear la conexión seguimos los siguientes pasos:
1. En la PC-1 en donde reside la base de datos SQL-Serever, se deberá contar los siguientes requisitos:
Página 120 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
o
Cliente de Oracle Client el cual es gratuito en el sitio de Oracle y su instalación en modo
"mínimo" es sencilla.
o ODBC de SQL-Serever mismo que ya viene pre instalado con Microsoft SQL-Serever.
2. En el PC-2 donde reside Oracle, se deberá contar con los siguientes requisitos:
o Oracle correctamente instalado y el puerto 1521 abierto en el Firewall.
o Oracle debe tener instalado el paquete SQL de datos heterogéneos, el cual se encuentra en la
siguiente ruta:
C:\ \product\11.1.0\db_1\hs
3.
Definir un Data Source Name (DSN) para SQL Server sobre PC-1.(42)
Desde el menú inicio ir al Panel de Control, posteriormente a herramientas Administrativas y
orígenes de Datos ODBC:
Figura 3.57.1. DNS.
Hacer click sobre la pestaña DSN de sistema y doble click en el botón Agregar:
Figura 3.57.2. DNS.
Seleccionar el driver para SQL Server y hacer click en agregar:
Figura 3.57.3. DNS.
Colocar los siguientes parámetros
1. Nombre que se desee para el ODBC.
2. Descripción de la Base de Datos a conectar.
3. Servidor donde se encuentra la Base de Datos a conectar.
(42)
Oracle® Database SQL Reference 10g Release 1.
Página 121 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.57.4. DNS.
Elegir “AutenticaciónSql Server mediante Usuario y Contraseña“, he ingresarlos en las casillas
correspondientes:
Figura 3.57.5. DNS.
Elegir el nombre de la Base de Datos a conectar:
Figura 3.57.6. DNS.
Click en Finalizar:
Figura 3.57.7. DNS.
Página 122 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
En esta ventana se muestra la configuración establecida. Hacer click en Validar Data Souerce:
Figura 3.57.8. DNS.
La siguiente pantalla indicará si la conexión es correcta:
Figura 3.57.9. DNS.
Finalmente se muestra el DNS de sistema creado:
Figura 3.57.10. DNS.
4. Crear el archivo de Inicialización de Servicios Heterogéneos (HS) PC-1:
A continuación se crea el fichero propio del servicio HS (Heterogeneous Service u Oracle Transparent
Gateway). Para ello se crea un fichero con el nombre conformado de la siguiente manera: "init" + "nombre
del DNS" + ".ora". En el caso de IGUDES, puesto que el nombre que se le asigno al DNS es SQLEXP, el nombre
del fichero a crear será:
$ORACLE_HOME/hs/admin/initSQLEXP.ora
Figura3.58. initSQLEXP.
Página 123 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Archivo Modificado:
# This is a sample agent init file that contains the HS parameters that are needed for an ODBC Agent.
# HS init parameters
#
HS_FDS_CONNECT_INFO = SQLEXP
HS_FDS_TRACE_LEVEL = 0
HS_AUTOREGISTER = TRUE
#
# Environment variables required for the non-Oracle system
#set <envvar>=<value>
Donde:
HS_FDS_CONNECT_INFO: será el parámetro más importante, en él se indica el nombre del SID creado en el
fichero tnsnames.ora, este a su vez apunta al ODBC DNS creado en el primer paso.
HS_FDS_TRACE_LEVEL: se indica el nivel de log, con "0" (OFF) se desactiva. Solo es conveniente activarlo en
caso de depuración de errores. Para activarlo se asignará "1" o también "ON".
HS_FDS_TRACE_FILE_NAME: con este parámetro se define la ruta del archivo de log (en caso de que este se
encuente activado).
HS_AUTOREGISTER: habilita o deshabilita el registro automático de servicios heterogéneos. Si se activa
(TRUE), la información se carga de forma automática en el diccionario del servidor. Activando este
parámetro Oracle funcionará con los servicios heterogéneos de forma más rápida y eficiente.
5. Modificar el Archivo Oracle listener.ora PC-1:
Modificar el archivo listener.ora que se encuentra en la siguiente carpeta:
ORACLE_HOME/network/admin/listener.ora
Figura 3.59.1. listaner.ora.
Los cambios a realizar son (43):
1.
2.
3.
4.
Cambiar el Puerto a 1521
Cambiar el SID_NAME para el DSN (SQLEXP)
Cambiar el ORACLE_HOME
Cambiar el PROGRAM a hsodbc
(SID_DESC =
(SID_NAME = SQLEXP)
(ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = HSODBC)
)
(43)
Databasejournal. Making a Connection from Oracle to SQL Server.
Página 124 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.59.2. listaner.ora.
A continuación se detallan cada uno de los elementos del fichero listener.ora:
"ORACLE_HOME": carpeta de instalación de Oracle.
"SID_NAME = SQLEXP": es importante que en este parámetro se indique el nombre que le
hemos dado SERVICE_NAME en el fichero tnsnames.ora. En el caso de IGUDES el mismo que
el ODBC DNS "SQLEXP" (para evitar confusión).
"PROGRAM = hsodbc": con este parámetro se indica a Oracle, que para esta conexión en
particular, se deberá hacer uso del servicio Heterogeneous Services u Oracle Transparent
Gateway. De esta forma, Oracle tratará esta conexión mediante el origen de datos ODBC
indicado.
6. Modificar el archivo tnsnames.ora PC-2
Modificar el archivo tnsnames.ora que se encuentra en la siguiente
carpeta:$ORACLE_HOME/network/admin/tnsnames.ora
Figura 3.59.3.tnsnames.ora
Los cambios a realizar son:
3.
2.
3.
4.
Crear una entrada de TNS para el DNS SQLEXP.
Cambiar el Puerto a 1521.
Cambiar el SID para el DSN (SQLEXP).
Agregar OK al parámetro HS.
SQLEXP=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST =10.53.210.80) (PORT=1521)))
(CONNECT_DATA=
(SID=SQLEXP)
)
(HS=OK))
Página 125 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.59.4. tnsnames.ora
A continuación se detallan cada uno de los elementos del fichero tnsnames.ora:
"HOST": en el parámetro "HOST" se indica el nombre (hostname) o la IP del equipo con la
base de datos SQL Server.
"SERVICE_NAME ": es importante indicar en este parámetro el nombre que le hemos dado
al origen de datos (ODBC) en el paso uno.
"HS = OK": con este valor, se le indica a Oracle que para esta conexión en particular haga
uso del servicio Heterogeneous Services u Oracle Transparent Gateway. De esta forma,
Oracle tratará esta conexión mediante el origen de datos ODBC indicado.
7. Reiniciar el nuevo Listener PC-1, modificado en el punto 5.
C:\>lsnrctl start
C:\>lsnrctl status
Figura 3.60. Cmd-listener.
Página 126 de 190
3| Desarrollo e Implementación de la Solución.
Figura 3.61. DBLink SQLEXP
8. Crear un Database Link para el DNS de Sql Server PC-2.
SQL> CREATE DATABASE LINK "SQLEXP" CONNECT TO "adm"
Probar la Conexión:
Figura 3.62.1. Probar Enlace SQLEXP.
Figura 3.62.2. Probar Enlace SQLEXP.
Página 127 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
3.6.3 Conexión Oracle a MySql:
Figura 3.63.Diagrama Oracle a MySQL
Para acceder desde una base de datos Oracle a objetos de una base de datos MySql Server, se deberá hacer uso de
los Servicios Heterogéneos de Oracle, que permite a Oracle acceder a sistemas de base de datos no Oracle
através de ODBC.
Para crear la conexión, el administrador deberá ejecutar los siguientes pasos:
1. Instalar el Driver ODBC para MySQL
Figura 3.64. Driver ODBC MySQL.
2. Crear el ODBC data source para la base MySQL
Desde el menú inicio ir al Panel de Control, posteriormente a herramientas Administrativas y orígenes de Datos
ODBC:
Figura 3.65.1. DNS MySQL.
3. Ingresar los parámetros de conexión:
1. Nombre del origen de Datos “OraMysql”.
2. Ip Servidor que contiene a MySql.
3. Puerto al que escucha MySql “3306”.
4. Usuario de la base de datos MySql.
5. Identificador de la Base de Datos a la que se conectará.
Página 128 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.65.2. DNS MySQL.
Probar el Origen de Datos, presionando el botón Test.
Figura 3.65.3. DNS MySQL.
4. Crear el archivo de Inicialización de ServiciosHeterogéneos (HS)(44).
Oracle provee el archivo init de Servicios Heterogéneos en el directorio $ORACLE_HOME/hs/admin, realizar una
copia de este archivo en el mismo directorio pero renombrandolo con el alias usado para el ODBC DNS
mismo que fue creado en el paso anterior.
$ORACLE_HOME/hs/admin/initOraMysql.ora
Figura 3.66.1. initOraMySQL.
(44)
Ignacio Barrancos. DBLinks desde Oracle hacia MySQL.
Página 129 de 190
3| Desarrollo e Implementación de la Solución.
Figura 3.66.2. initOraMySQL.
Archivo Modificado:
# HS init parameters
#
HS_FDS_CONNECT_INFO = OraMysql
HS_FDS_TRACE_LEVEL = 0
HS_AUTOREGISTER = TRUE
5. Modificar el Archivo Oracle listener.ora:
Modificar el archivo listener.ora que se encuentra en la siguiente carpeta:
$ORACLE_HOME/network/admin/listener.ora
Figura 3.67.1. Listener Ora-MySQL.
Los cambios a realizar son:
1. Cambiar el Puerto a 1521
2. Cambiar el SID_NAME para el DSN (OraMysql)
3. Cambiar el ORACLE_HOME
4. Cambiar el PROGRAM a hsodbc
(SID_DESC =
(SID_NAME = OraMysql)
(ORACLE_HOME = C:\oraclexe\app\oracle\product\10.2.0\server)
(PROGRAM = HSODBC) )
Figura 3.67.2. Listener Ora-MySQL.
Página 130 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
6. Modificar el archivo tnsnames.ora
Modificar el archivo tnsnames.ora que se encuentra en la siguiente carpeta:
$ORACLE_HOME/network/admin/tnsnames.ora
Figura 3.68.1. Tnsnames Ora-MySQL.
Los cambios a realizar son:
1.
2.
3.
4.
Crear una entrada de TNS para nuestro DNS OraMysql.
Cambiar el Puerto a 1521.
Cambiar el SID para el DSN (OraMysql).
Agregar OK a el parámetro HS= OK.
OraMysql =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST =10.53.210.80) (PORT=1521)))
(CONNECT_DATA=
(SID= OraMysql)
)
(HS=OK)
)
Figura 3.68.2. Tnsnames Ora-MySQL.
7. Iniciar el nuevo Listener, modificado en el punto 5.
C:\>lsnrctl start
C:\>lsnrctl status
Página 131 de 190
IGUDES. MTD.
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.69. Cmd listener Ora-MySQL.
8. Validar la conexión al DNS
C:\>tnsping mysqlserverdsn
9. Crear un Database Link para el DNS de MySql(45).
SQL>CREATE DATABASE LINK "ORAMYSQL"
CONNECT TO "root" IDENTIFIED BY VALUES '05433463B8C87E7BAC7E054F062FE88602' USING 'OraMysql';
Figura 3.70. DBLink ORAMYSQL.
Para probar la Conexión, se deberá hacer click derecho sobre el DbLink creado y presionar “Probar Enlace
de Base de Datos”.
(45)
hs2n. Oracle: Create Database Link to MySQL Database.
Página 132 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.71. Probar DBLink ORAMYSQL.
Figura 3.72. Confirmación DBLink ORAMYSQL.
3.6.4 Conexión Sql Server a Sql Server
Figura 3.73. Diagrama SQL a SQL.
Para crear la conexión de SQL a SQL se generará un Linked Server mediante SQL Server Management Studio
(SSMS). Un Linked Server permite la conexión con otra instancia de SQL, ya sea que estén corriendo en un equipo
remoto o en el mismo equipo. Esto se usa normalmente para ejecutar consultas distribuidas, un servidor
vinculado permite obtener acceso a consultas heterogéneas distribuidas.
Para crear la conexión se deben seguir los siguientes pasos:
1. Dentro del SSMS, en el explorador de objetos, expandir la opción Server Objects, después Linked Servers hacer
click derecho cobre esta opción y seleccionar New Linked Server:
Figura3.73. LinkedServer Sql a Sql.
Página 133 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
2. Configurar el Linked Server, como se observa en la siguiente iamgen:
Figura 3.74.1. LinkedServer SQL.
Colocar un nombre que describa el Linked Server (sin espacios).
Asegurarse que en la opción“Server Type” este activada la opción “Other data source” (esto forzará
a que se asigne el nombre del Sql Server)
En la opción “Provider, elegir la opción “SQL Server Native Client 10.0”
En “Product Name”, escribir SqlServer sin espacios.
En “Datasource”, colocar el nombre del servidor \ instancia.
A la opción “ProviderString”, no se le asigna valor.
A la opción “Catalog”, no se le asigna valor valor.
3. Seleccionar del explorador de objetos la opción Security:
Figura 3.74.2. LinkedServer SQL.
Dentro de este menú se debe especificar el método de autentificación del linked Server. Para esto, se seleccionará
la opción “Using this Security context”, la cual solicitará los parámetros usuario y contraseña(46).
4. Seleccionar del explorador de objetos la opción “Server Options” (47):
La primera opción "Collation Compatible", es usada para identificar si el servidor vinculado tiene la misma
codificación que el servidor local. Sólo debería colocarse "True" si se sabe que la codificación local es la misma que
el servidor vinculado.
La opción “Data Access” se utiliza para el control de permisos sobre los datos que estén disponibles en el servidor
vinculado. Cuando esta opción está establecida en "True", el servidor vinculado se puede utilizar para acceder a los
datos en la instancia de SQL Server remota. Cuando esta opción está establecida en "False" entonces el acceso al
servidor remoto se deniega. Esta opción es una forma útil de deshabilitar un servidor vinculado temporalmente.
Por otra parte la opción “Rpc”, se utiliza para permitir llamadas de procedimientos remotos.
“Use Remote Collation”, cuando se establece a "true", significa que la configuración de codificación de las columnas
remotas se utilizará, pero cuando esta opción está establecida en "False" la configuración de codificación del
servidor local se utilizará.
(46)
(47)
Quackit. Creating a Linked Server.
Derek Dieter. How to Add a Linked Server November 21, 2010.
Página 134 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
“Collation Name”, permite especificar la configuración de codificación del servidor vinculado.
“Connection Timeout”, se utiliza para especificar la longitud máxima de tiempo que el servidor local debe esperar
para obtener una conexión a la instancia del Servidor SQL vinculado.
“Query Timeout”, sta opción es usada para especificar la cantidad de tiempo que un proceso del servidor vinculado
correrá antes de que se agote. Cuando esta opción se establece en "0", entonces al “tiempo de espera de consulta
remota" se le asigna el valor predeterminado de 10 minutos.
Figura3.75. Properties LinkedServerSQL.
5. Para probar la conexión, se deberá hacer click derecho sobre el Linked Server creado y elegir la opción
Test Connection:
Figura 3.76. Probar LinkedServer SQL.
Figura 3.77. Comprobación LinkedServer SQL.
Página 135 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
3.6.5 Conexión Sql Server a Oracle
Figura 3.78. Diagrama Sql a Oracle.
Para crear la conexión, el administrador deberá ejecutar los siguientes pasos:
1. Verificar que el proveedor para Oracle (OraOLEBD.Oracle) se encuentra instalado en el SSMS, de lo contrario
instalar el driver Oracle Provider for OLE DB, de tal forma que al desplegar el árbol de Proveedores se
visualice el driver(48):
Figura 3.79. Proveedor OraOLEDB.
2. Configurar las Propiedades del Driver OraOLEDB:
Hcer click derecho sobre el driver OraOLEDB.Oracle y seleccionar propiedades. Dentro de propiedades activar
las siguientes opciones:
Dynamic parameter
Allow inprocess
Figura 3.80. Propiedades del Driver OraOLEDB.
3. Crear el Oracle Linked Server desde el SSMS(49):
(48)
(49)
Databasejournal. Setting up a Linked Server for a Remote SQL Server Instance. July 31, 2007.
Bryansgeekspeak. SQL Server 2008R2 Linked Server to Oracle 11.2.0.2 Instance.Thursday, December 08, 2011.
Página 136 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Hacer click derecho en el folder Linked Server y posteriormente en new Linked Server
Figura 3.81. Crear LinkedServer ORCL.
Dentro de New Linked Server asignar los siguientes parámetros:
En Linked Server colocar el nombre del Linked Server “ORCL”
En Server Type elegir la opción “Other data Source”.
En provider elegir el driver Oracle Provider for OLE DB.
En Product Name asignar una descripción del conector “Oracle”.
En Data Source colocar “localhost/orcl”.
Figura 3.81.1. Propiedades LinkedServer ORCL.
Seleccionar del menú de la Izquierda la opción “Security“ (50). En esta opción se especificará el método de
autenticación para el linked Server. Seleccionar “Using this Security context”en donde se solicitará el usuario
y contraseña.
(50)
Ideaexcursion. Connecting to Oracle from SQL Server. Jan 052009.
Página 137 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.81.2. Propiedades LinkedServer ORCL.
Seleccionar del panel de la Izquierda la opción Server Options y configurar como se muestra en la
siguiente imagen y posteriormente OK:
Figura 3.81.3. Propiedades LinkedServer ORCL.
Finalmente se deberá de ejecutar una prueba de conexión haciendo click derecho sobre el Linked
Server creado y elegir la opción Test Connection:
Figura 3.81.4. Propiedades LinkedServer ORCL.
Si la conexión es correcta, se enviará el siguiente mensaje:
Figura 3.81.5. Propiedades LinkedServer ORCL.
Página 138 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
3.6.6 Conexión Sql Server a MySql
Figura 3.82. Diagrama Sql a MySql.
Se requiere tener intalada las bases de datos MySql y Sql-Server Express 2008. Para crear la conexión seguimos
los siguientes pasos:
1. Instalar el Driver ODBC de MySql: mysql-connector-odbc-5.3.11-win32:
Figura 3.83. Instalar driver mysql odbc.
2. Crear el ODBC DSN para MySQL:
Ir al Panel de Control y posteriormente a Sistema y Seguridad, Herramientas Administrativas y finalmente a
Data Sources ODBC. En la pestaña de Drivers, verificar si se encuentra el driver de MySql ODBC 5.1 Driver.
Figura 3.84. Driver mysql odbc.
Para configurar el Driver de Mysql, hacer click en la opción Add y elegir el Driver:
Figura 3.84.1. Crear DNS mysql_cd.
Página 139 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
En la ventana que se despliega, se deberán colocar los siguientes parámetros:
o Data Source Name: nombre que se le asignará a la conexión “mysql_cd”.
o Description: Descripción de la Fuente de Datos.
o TCP/IP server: Nombre del Servidor o IP en la que se encuentra la base de MySql “localhost”.
o Port: Puerto en el que escucha MySQL (3306).
o User: Usuario para acceder a la base MySql.
o Password: Contraseña para acceder a la base MySql.
o Database: Nombre de la Base de Datos que se desea acceder.
Figura 3.84.2. Crear DNS mysql_cd.
Se valida la conexión mediante el botón Test:
Figura 3.84.3. Crear DNS mysql_cd.
3.Crear el Linked Server desde SSMS:
Para la creación del Linked Server desde SMS, se deberá expandir el árbol de proveedores y seleccionar el Driver
MSDASQL(51).
Figura 3.84.4.Proveedor MSDASQL.
(51)
Wordpress. Link MySQL to MS SQL Server2008. July 22, 2010.
Página 140 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Posteriormente hacer click derecho sobre el driver y elegir propiedades:
Figura 3.84.5. Proveedor MSDASQL.
Activar las siguientes opciones:
Consultas Anidadas
Solo Nivel Cero
Permitir InProcess
Admite el operador LIKE
Figura 3.84.6. Proveedor MSDASQL.
4. Crear el Linked Server:
Para la creación delLinked Server, hacer click derecho en el folder Servidores Vinculados y después en Nuevo
Servidor Vinculado:
Figura 3.85.1. Crear LinkedServer mysql_cd.
Se deberán asignar los siguientes parámetros:
Página 141 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
En Servidor Vinculado colocar el nombre del Linked Server “MYSQL_CD”
En Tipo de Servidor, se elige la opción “Otro Origen de Datos”.
En proveedor, seleccionar el driver Microsoft OLE DB Provider for ODBC Drivers.
En Nombre del Producto asignar una descripción del conector “mysql”.
En Origen de Datos asignar “mysql_cd”.
Figura 3.85.2. Crear LinkedServer mysql_cd.
Seleccionar del panel de la Izquierda la opción Seguridad. En esta se debe especificar el método de autenticación
para el linked Server. Posteriormente, seleccionar la opción “Se establecerán usando este contexto de seguridad”,
la cual pedirá colocar usuario y contraseña.
Figura 3.85.3. Crear LinkedServer mysql_cd.
Seleccionar del panel de la Izquierda Opciones del Servidor y configurar como se muestra en la siguiente imagen:
Página 142 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.85.4. Crear LinkedServer mysql_cd.
Finalmente se ejecuta una prueba de conexión al hacer click derecho sobre el Linked Server creado y eligiendo
la opción Probar Conexión:
Figura 3.86. ProbarLinkedServer mysql_cd.
Si la conexión es correcta, el sitema enviará el siguiente mensaje:
Figura 3.87. ComprobaciónLinkedServer mysql_cd.
Página 143 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
3.6.7 Conexión MySql a MySql
Figura 3.88. Diagrama MySql a MySql.
El motor FEDERATED está disponible desde MySQL 5.0.3. Este, es un motor que accede a datos en tablas de bases de
datos remotas en lugar de tablas locales. En este escenario se identifico una limitación: MySQL sólo permite
vincular tablas entre diferentes base de datos mediante el uso de Tablas Federadas y esta funcionalidad sólo está
disponible a partir de la versión 5.0.3 y únicamente permite conectar a otras bases de datos MySQL
exclusivamente. Para saber si el servidor en cuestión soporta tablas federadas, es necesaria una conexión para
ejecutar el comando show engines:
mysql>show engines;
+------------+--------+----------------+---------+---------+
| Name
| Status | Type
| Library | License |
+------------+--------+----------------+---------+---------+
| binlog | ACTIVE | STORAGE ENGINE | NULL | GPL |
| partition | ACTIVE | STORAGE ENGINE | NULL | GPL |
| ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL |
| CSV
| ACTIVE | STORAGE ENGINE | NULL | GPL |
| FEDERATED | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL |
| InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
| MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL |
+------------+--------+----------------+---------+---------+
Si se usa phpMyAdmin al presionar el botón Engines, si la opción federated se muestra en la tabla, esto determina
que está el servicio activo:
Figura 3.89. Motores MySql.
Si no está activo este almacenamiento, se tendrá que editar el fichero de configuración del servidor
/etc/mysql/my.cnf y habilitar el soporte para tablas federadas en la sección [mysqld]. Cuando se hayan guardado los
cambios, reiniciar el servidor MySQL y volver a comprobar con show engines;
Página 144 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
Figura 3.90.1.Archivo My.cnf.
Modificar el apartado Federated de la siguiente manera:
[mysqld]
federated
= ON
Figura 3.90.2.Archivo My.cnf.
1. Generar la tabla a la que se desea tener acceso mediante la tabla FEDERATED(52):
CREATE TABLE test_table (
id int(20) NOT NULL auto_increment,
name varchar(32) NOT NULL default '',
other int(20) NOT NULL default '0',
PRIMARY KEY (id),
KEY name (name),
KEY other_key (other)
)
ENGINE=MyISAM
DEFAULT CHARSET=utf8;
2. A continuación, crear una tabla FEDERATED en un servidor remoto o base de datos distinta de donde se creó
la tabla del paso anterior
(53)
.
CREATE TABLE federated_table (
id int(20) NOT NULL auto_increment,
name varchar(32) NOT NULL default '',
other int(20) NOT NULL default '0',
PRIMARY KEY (id),
KEY name (name),
KEY other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8
CONNECTION='mysql://root@localhost:3306/cdcol/test_table';
(52)
Manual de referencia de MySQL. Cómo usar las tablas FEDERATED.
Ignacio Barrancos en sábado, abril 14, 2012 .tecnoquia. DBLinks desde MySQL hacia Oracle.
(53)
Página 145 de 190
3| Desarrollo e Implementación de la Solución.
IGUDES. MTD.
La estructura de esta tabla debe ser exactamente la misma que la de la tabla remota, excepto que la opción de tabla
ENGINE debe ser FEDERATED y la opción CONNECTION es una cadena de conexión que indica al motor FEDERATED
cómo conectar al servidor remoto. El motor FEDERATED crea sólo el fichero test_table.frm en la base de datos
federated. La información del equipo remoto define el servidor remoto al que se conecta el servidor local, y la
información de base de datos y tabla indica la tabla remota a usar como fichero de datos.
La forma general de la cadena de conexión en la opción CONNECTION es la siguiente (54):
scheme://user_name[:password]@host_name[:port_num]/db_name/tbl_name
Ejemplos:
CONNECTION='mysql://username:password@hostname:port/database/tablename'
CONNECTION='mysql://username@hostname/database/tablename'
CONNECTION='mysql://username:password@hostname/database/tablename'
Sólo se soporta mysql como scheme en este punto; la contraseña y el número de puerto son opcionales.
3. Finalmente ya que se creó la tabla FEDERATED esta se puede consultar como cualquier tabla local, ya que
internamente realiza la conexión a la tabla remota y presenta los datos como si estuvieran almacenados
en la base de datos local.
Select * from federated_table
(54)
Latindevelopers. 29 noviembre, 2011. Activar el motor FEDERATED en MySQL.
Página 146 de 190
4| Evaluación de la Solución
IGUDES. MTD.
CAPITULO IV.Evaluación de la Solución.
Este capítulo tiene como finalidad demostrar mediante ejemplos funcionales algunas de las funciones que se
pueden lograr con IGUDES. Los ejemplos se dividen en los siguientes grupos:
4.1.1 Consultas a la base de datos de Administración Oracle Express.
4.1.2 Consultas a la base de datos Oracle 11g ORCL.
4.2 Consulta Distribuida entre SMBD Homogéneos Oracle.
4.3 Consulta Distribuida entre SMBD Heterogéneos Oracle SQL-SERVER.
4.4 Consulta Distribuida entre SMBD Heterogéneos Oracle  MySQL.
4.5 Consultas al Sistema Manejador de Base de Datos SQL-SERVER.
4.6 Consulta Distribuida entre SMBD Homogéneos SQL-SERVER.
4.7 Consulta Distribuida entre SMBD Heterogéneos SQL-SERVER  ORACLE.
4.8 Consulta Distribuida entre SMBD Heterogéneos SQL SERVER MySQL.
4.9 Consultas al Sistema Manejador de Base de Datos MySQL.
4.10 Consulta Distribuida entre SMBD Homogéneos MySQL.
4.11 Consulta Distribuida, Join entre tres Sistemas Manejadores de Bases de Datos Distintos MYSQLSQL
SERVERORACLE.
4.12 Consultas Múltiples al SMBD ORACLE.
4.13 Consultas Múltiples sobre SQL y Consulta Distribuida desde el módulo de Consultas Múltiples.
4.14 Manejo de Vistas desde IGUDES.
4.15 Pruebas de Desempeño.
Los ejemplos se realizarón sobre los tres SMBD con los que actualmente se conecta IGUDES:
Oracle 11g, Oracle 10g XE.
SQL Server Express 2008.
MySQL 5.1
El lector debe recordar que las conexiones distribuidas implican el manejo básico de SQL quizá con variantes
en la sintaxis entre los distintos SMBD , pero con los mismos principios de operación. Por tanto, la lógica de
construcción de las sentencias SQL debe ser la misma, por ejemplo, si se requieren comparar dos atributos que
tengan distintos tipos de dato, será necesario transformar alguno de ellos para lograr la comparación aun
cuando se encuentren en distinta base de datos.
4.1.1 Consultas a la base de datos de Administración Oracle Express:
Figura 4.1. Logo Orcl.
Desde Oracle Express: consulta sobre tabla local de Oracle.
Select * from pc_usuario_database
Página 147 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.2. Consulta Simple 1.
Resultado:
Figura 4.3. Resultado Consulta Simple 1.
Desde Oracle Express: consulta sobre tabla local de Oracle.
select * from pc_database
Figura 4.4. Consulta Simple 2.
Resultado:
Figura 4.5. Resultado Consulta Simple 2.
Página 148 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Desde Oracle Express: consulta sobre tabla local de Oracle.
select * from pc_usuario
Figura 4.5. Consulta Simple 3.
Resultado:
Figura 4.6. Resultado Consulta Simple 3.
Desde Oracle Express: Join entre 2 tablas Oracle Express.
Select a.usuario, a.passw, a.ip_cliente, b.db_name
From pc_usuario a
Inner join
pc_usuario_database b
on
a.usuario=b.usuario
Figura 4.7. Consulta Simple 4.
Página 149 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Resultado:
Figura 4.8. Resultado Consulta Simple 4.
Desde Oracle Express: Join entre 4 tablas Oracle Express
Select a.usuario, a.passw, a.ip_cliente, b.db_name, c.db_url, d.resultado From pc_usuario a Inner join
pc_usuario_database b on a.usuario=b.usuario inner join pc_database c on b.db_name=c.db_name inner
join pc_bitacora d on a.usuario=d.user_id where upper(a.usuario)='upiicsa'
Figura 4.9. Consulta Simple 5.
Resultado:
Figura 4.10. Resultado Consulta Simple 5.
4.1.2 Consultas a la base de datos Oracle 11g ORCL
Desde Oracle orcl: consulta a tabla local de Oracle ORCL.
select * from prueba
Figura 4.11. Consulta Simple 6.
Página 150 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Resultado:
Figura 4.12. Resultado Consulta Simple 6.
4.2 Consulta Distribuida entre SMBD Homogéneos Oracle:
Figura 4.13. Logo Oracle a Oracle.
Desde Oracle orcl  Oracle xe, consulta a tabla remota Oracle xe desde Oracle orcl.
Select * from pc_usuario@DB_LINK
Figura 4.14. Consulta Distribuida 1.
Resultado:
Figura 4.15. Resultado Consulta Distribuida 1.
Desde Oracle orcl  Oracle xe, consulta a tabla remota Oracle xe desde Oracle orcl.
Select * from pc_usuario_database@DB_LINK
Figura 4.16. Consulta Distribuida 2.
Resultado:
Figura 4.17. Resultado Consulta Distribuida 2.
Página 151 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Desde Oracle orcl  Oracle xe, consulta a tabla remota Oracle xe desde Oracle orcl.
select * from pc_database@DB_LINK
Figura 4.18. Consulta Distribuida 3.
Resultado:
Figura 4.19. Resultado Consulta Distribuida 3.
Desde Oracle orcl  Oracle xe, join de dos tablas remotas desde Oracle orcl.
select * from pc_usuario_database@DB_LINK a --xe
inner join PC_DATABASE@DB_LINK b
--xe
on
a.DB_NAME=b. DB_NAME
Figura 4.20. Consulta Distribuida 4.
Resultado:
Figura 4.21. Resultado Consulta Distribuida 4.
Página 152 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Desde Oracle orcl  Oracle xe, join entre tabla local ORCL y tabla remota XE.
select * from pc_usuario_database@DB_LINK a --xe
inner join PRUEBA b
--orcl
on
a. DB_NAME=b. DB_NAME
Figura 4.22. Consulta Distribuida 5.
Resultado:
Figura 4.23. Resultado Consulta Distribuida 5.
Desde Oracle orcl  Oracle xe, join entre tabla local ORCL y tabla remota XE.
select * from pc_DATABASE@DB_LINK a
inner join PRUEBA b
on
a. DB_NAME=b. DB_NAME
--xe
--orcl
Figura 4.24. Consulta Distribuida 6.
Resultado:
Figura 4.25. Resultado Consulta Distribuida 6.
Página 153 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Desde Oracle orcl  Oracle xe, join 2 tablas remotas de XE con tabla local ORCL
select * from
pc_usuario_database@DB_LINK a
--xe
inner join PRUEBA b
--orcl
on
a.DB_NAME=b.DB_NAME
inner join PC_DATABASE@DB_LINK c
--xe
on
a.DB_NAME=c.DB_NAME
Figura 4.26. Consulta Distribuida 7.
Resultado:
Figura 4.27. Resultado Consulta Distribuida 7.
4.3 Consulta Distribuida entre SMBD Heterogéneos Oracle --> SQL-SERVER:
Figura 4.28.Logo Oracle a Sql Server.
Desde Oracle orcl --> SQL-SERVER, Consulta sobre tabla remota SQL-Server desde Oracle Orcl.
SELECT * FROM ALUMNO@SQLEXP
Figura 4.29. Consulta Distribuida 8.
Resultado:
Figura 4.30. Resultado Consulta Distribuida 8.
Página 154 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Desde Oracle orcl  SQL-SERVER, Consulta sobre tabla remota SQL-Server desde Oracle Orcl.
SELECT * FROM dbo.ALBUM@SQLEXP
Figura 4.31. Consulta Distribuida 9.
Resultado:
Figura 4.32. Resultado Consulta Distribuida 9.
Desde Oracle ORCL  SQL-SERVER, Join entre tablas remotas SQL-Server desde Oracle Orcl.
SELECT * FROM ALUMNO@SQLEXP B INNER JOIN
MATERIA@SQLEXP A ON
A.NOMBRE = B.NOMBRE
Figura 4.33. Consulta Distribuida 10.
Resultado:
Figura 4.34. Resultado Consulta Distribuida 10.
Desde Oracle orcl  SQL-Express, join entre tabla Oracle local con tabla Sql-Server remota.
SELECT a.id, a.titulo, b.*
FROM dbo.ALBUM@SQLEXP a
inner join
ARTISTA b on b.id=a.id
Página 155 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.35. Consulta Distribuida 11.
Resultado:
Figura 4.36. Resultado Consulta Distribuida 11.
Desde Oracle orcl  SQL-SERVER, join entre tabla Oracle con tabla Sql-Server
SELECT * FROM ALUMNO@SQLEXP a
inner join prueba b
on a.nombre=b.nombre
Figura 4.37. Consulta Distribuida 12.
Resultado:
Figura 4.38. Resultado Consulta Distribuida 12.
4.4 Consulta Distribuida entre SMBD Heterogéneos Oracle --> MySQL:
Figura 4.39. Logo Oracle aMySql.
Desde Oracle orcl --> MySQL, consulta tabla remota de MySQL desde ORACLE
select * from album@OraMysql
Figura 4.40. Consulta Distribuida 13.
Página 156 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Resultado:
Figura 4.41. Resultado Consulta Distribuida 13.
Desde Oracle orcl --> MySQL, consulta tabla remota de MySQL desde ORACLE
select * from ejemplo@OraMysql
Figura 4.42. Consulta Distribuida 13.
Resultado:
Figura 4.43. Resultado Consulta Distribuida 13.
Desde Oracle orcl  MySQL, Join entre tabla ORACLE y MySQL
select a.id, b.id,b.nombre,b.edad
from album@OraMysql a
inner join
artista b
on
a.id=b.id
Figura 4.44. Consulta Distribuida 14.
Resultado:
Figura 4.45. Resultado Consulta Distribuida 14.
4.5 Consultas al Sistema Manejador de Base de Datos SQL-SERVER.
Figura 4.46. Logo Sql Server.
Desde Sql neoris, Consulta a tabla Sql Local.
select * from dbo.Alumno
Página 157 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.47. Consulta Simple 7.
Resultado:
Figura 4.48. Resultado Consulta Simple 7.
Desde Sql local, Consulta sobre SQL LOCAL
select * from dbo.profesion
|
Figura 4.49. Consulta Simple 8.
Resultado:
Figura 4.50. Resultado Consulta Simple 8.
Desde Sql local, Join de tablas locales SQL.
Select * from Alumno a
Inner join Materia b
On a.nombre=b.nombre
Figura 4.51. Resultado Consulta Simple 9.
Resultado:
Figura 4.52. Resultado Consulta Simple 9
Página 158 de 190
4| Evaluación de la Solución
IGUDES. MTD.
4.6 Consulta Distribuida entre SMBD Homogéneos SQL-SERVER:
Figura 4.53. Logo Sql Server a Sql Server.
Desde Sql local  Sql Neoris, Join entre tabla sql Local con sql remota.
SELECT A.NOMBRE, A.EDAD, B.prof FROM [SQLEXPLOC].[dbo].[PROFESION] AS B
INNER JOIN
[SQL].[SQLEXP].[dbo].[ALUMNO] AS A
ON
B.Nombre=A.NOMBRE COLLATE Latin1_General_CI_AI
Figura 4.54. Consulta Distribuida 15.
Resultado:
Figura 4.55. Resultado Consulta Distribuida 15.
4.7 Consulta Distribuida entre SMBD Heterogéneos SQL-SERVER ORACLE:
Figura 4.56. Logo Sql Server a Oracle.
Desde Sql local Orcle XE, Consulta remota desde SQL a tabla Oracle.
SELECT USUARIO ,PASSW, STATUS ,CVEPERFIL, FECHA_CREACION, FECHA_ULTMOD, CADUCIDAD,DIASCAD,
IP_CLIENTE, CVEPRODUCTO FROM XE..SYSTEM.PC_USUARIO
Figura 4.57. Consulta Distribuida 16.
Página 159 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Resultado:
Figura 4.58. Resultado Consulta Distribuida 16.
Desde Sql local Orcle ORCL, Consulta remota desde SQL a tabla Oracle.
SELECT NOMBRE ,EDADA, DB_NAME FROM ORCL..SYSTEM.PRUEBA
Figura 4.59. Consulta Distribuida 17.
Resultado:
Figura 4.60. Resultado Consulta Distribuida 17.
Desde Sql local  Oracle ORCL, Join entre tabla local Sql con tabla remota ORACLE ORCL.
select a.Nombre, a.prof, b.EMPLOYEE_ID
from dbo.profesion a --sql
inner join
[ORCL]..[HR].[EMPLOYEES] b --orcl
on
a.Nombre=b.FIRST_NAME
collate Modern_Spanish_CI_AS
where
b.FIRST_NAME='Donald'
Figura 4.61. Consulta Distribuida 18.
Resultado:
Figura 4.62. Resultado Consulta Distribuida 18.
Desde Sql local  Oracle ORCL y Oracle XE, Join desde Sql-Server a dos tablas remotas Oracle en bases
distintas
Página 160 de 190
4| Evaluación de la Solución
|
IGUDES. MTD.
SELECT
a.[USUARIO] ,a.[PASSW] ,a.[STATUS] ,a.[CVEPERFIL] ,a.[FECHA_CREACION]
,a.[FECHA_ULTMOD] ,a.[CADUCIDAD] ,a.[DIASCAD] ,a.[IP_CLIENTE]
,a.[CVEPRODUCTO] ,b.[NOMBRE] ,b.[EDADA] ,b.[DB_NAME]
FROM [XE]..[SYSTEM].[PC_USUARIO] a
inner join
[ORCL]..[SYSTEM].[PRUEBA] b
on a.[USUARIO]=b.[NOMBRE]
Figura 4.63. Resultado Consulta Distribuida 19.
Resultado:
Figura 4.64. Resultado Consulta Distribuida 19.
4.8 Consulta Distribuida entre SMBD Heterogéneos SQL SERVER --> MySQL:
Figura 4.65. Logo Sql Server a MySql.
Desde Sql neoris  MySQL CDCOL, Consulta desde SQL NEORIS a MySQL
select * from openquery(mysql_cd,'select * from cdcol.cds')
Figura 4.66. Consulta Distribuida 20.
Resultado:
Figura 4.67. Resultado Consulta Distribuida 20.
Desde Sql neoris  MySQL TEST, Consulta desde SQL NEORIS a MySQL
select * from openquery(mysql_cd,'select * from TEST.federated_table')
Página 161 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.68. Consulta Distribuida 21.
Resultado:
Figura 4.69. Resultado Consulta Distribuida 21.
Desde Sql neoris  MySQL TEST, Join entre tablas remotas de MySQL
select * from openquery(mysql_cd,
'select a.id, a.name, a.other, b.titel, b.interpret, b.jahr
from test.federated_table a
inner join
cdcol.cds b
on
a.id=b.id')
Figura 4.70. Consulta Distribuida 22.
Resultado:
Figura 4.71. Resultado Consulta Distribuida 22.
Desde Sql neoris  MySQL CD, Join entre tabla local SQL con remota de MySQL
select * from
openquery(mysql_cd,'select b.id, b.titel, b.interpret, b.jahr from cdcol.cds b') as b
inner join
dbo.ALBUM as a
on
a.id=b.id
Figura 4.72. Consulta Distribuida 23.
Resultado:
Figura 4.73. Resultado Consulta Distribuida 23.
Página 162 de 190
4| Evaluación de la Solución
IGUDES. MTD.
4.9 Consultas al Sistema Manejador de Base de Datos MySQL:
Figura 4.74. Logo Mysql.
Desde MYSQL CDCOL, consulta a tabla local MySQL
select * from cds
Figura 4.75. Consulta Simple 10.
Resultado:
Figura 4.76. Resultado Consulta Simple 10.
Desde MYSQL CDCOL, consulta a tabla local MySQL
select * from test_table
Figura 4.77. Consulta Simple 11.
Resultado:
Figura 4.78. Resultado Consulta Simple 11.
4.10 Consulta Distribuida entre SMBD Homogéneos MySQL:
Figura 4.79.Logo MySql a MySql.
Desde MYSQL federated,Consulta desde MySql federated a tabla remota de MySQL CdCol
Página 163 de 190
4| Evaluación de la Solución
IGUDES. MTD.
select * from federated_table
Figura 4.80. Consulta Distribuida 24.
Resultado:
Figura 4.81. Resultado Consulta Distribuida 24.
Desde MYSQL federated, Join tabla local MYSQL federated con tabla remota MySQL CdCol
select * from test.federated_table a inner join cdcol.cds b on a.id=b.id
Figura 4.82. Consulta Distribuida 25.
Resultado:
Figura 4.83. Resultado Consulta Distribuida 25.
4.11 Consulta Distribuida, Join entre tres Sistemas Manejadores de Bases de Datos Distintos:
Desde SQL Neoris tabla local “ALBUM” join con MYSQL CdCol tabla “CDS”, Join con Oracle ORCL tabla
“ARTISTAS”:
select * from
openquery(mysql_cd,'select b.id, b.titel, b.interpret, b.jahr from cdcol.cds b') as b --mysql
inner join
dbo.ALBUM as a --sql
on
a.id=b.id
inner join
SQLNEO_ORCL..SYSTEM.ARTISTA as c --orcl
on
a.id=c.id
Figura 4.84. Consulta Distribuida 26.
Respuesta:
Página 164 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.85. Resultado Consulta Distribuida 26.
Demostramos que es correcta la respuesta anterior mediante la ejecución por separado de las consultas.
1. Consulta de la tabla CDS sobre MYSQL:
SELECT * FROM CDCOL.CDS
WHERE
ID=1
Figura 4.86. Consulta Simple 12.
Resultado 1:
Figura 4.87. Resultado Consulta Simple 12.
2. Consulta de la tabla ALBUM sobre SQL Express :
SELECT * FROM DBO.ALBUM
Figura 4.88. Consulta Simple 13.
Resultado 2:
Figura 4.89. Resultado Consulta Simple 13.
3. Consulta de la tabla ARTISTA sobre ORACLE:
SELECT * FROM ARTISTA
Figura 4.90. Consulta Simple 14.
Resultado 3:
Figura 4.91. Resultado Consulta Simple 14.
Como se muestra el resultado de las tres consultas por separado es igual a la respuesta del join entre los tres
Sistemas Manejadores de Base de Datos.
4.12 Consultas Múltiples al SMBD ORACLE:
Para ejemplificar el funcionamiento de las Consultas Múltiples, a continuación se muestran algunos ejemplos de
ejecución de sentencias DML en lotes mediante scripts sobre la tabla pc_usuario_database_r que inicialmente se
encuentra vacía tal y como se muestra a continuación:
Página 165 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.92. Resultado Consulta SQL Developer.
1. Se insertan registros (INSERT) en la tabla pc_usuario_database_r, ejecutando el siguiente script en el módulo
de Consultas Múltiples de IGUDES.
Figura 4.93. Script de Insert a Oracle.
Se ejecuta el script como se muestra enseguida:
Figura 4.94. Adjunta Script de Insert a Oracle.
Se obtiene el resultado en un archivo de texto:
Página 166 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.95. Resultado a Script de Insert a Oracle.
Figura 4.96. Archivo Respuesta del Script de Insert a Oracle.
2. Consulta (SELECT) de los registros insertados a la tabla pc_usuario_database_r:
Figura 4.97. Script de Select a Oracle.
Se ejecuta el script como se muestra enseguida:
Página 167 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.98. AdjuntaScript de Select a Oracle.
Se obtiene el resultado en un archivo de texto:
Figura 4.99. Resultado a Script de Select a Oracle.
Se observa que los registros insertados en el paso anterior son los mismos que se devuelven:
Figura 4.100. Archivo Resultado del Slect a Oracle.
3. Realizar la actualización (UPDATE) siguiente DB_NAME='X', para cada unos de los registros:
Página 168 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.101. Script de Update a Oracle.
Se ejecuta el script como se muestra enseguida:
Figura 4.102.AdjuntaScript de Update a Oracle.
Se obtiene el resultado en un archivo de texto:
Figura 4.103. Resultado a Script de Update a Oracle.
Página 169 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.104. Archivo Resultado a Script de Update a Oracle.
Se ejecuta nuevamente el script de sentencias Select para comprobar las actualizaciones:
Figura 4.105. Script de Select a Oracle.
El lector puede observar que la actualización es correcta, todos los registros presentan el atributo DB_NAME='X'.
Figura 4.106. Archivo Resultado a Script de Update a Oracle.
Página 170 de 190
4| Evaluación de la Solución
IGUDES. MTD.
4. Eliminar (DELETE) los registros de la tabla pc_usuario_database_r:
Figura 4.107. Script de Delete a Oracle.
Se ejecuta el script como se muestra enseguida:
Figura 4.108. AdjuntaScript de Delete a Oracle.
Se obtiene el resultado en un archivo de texto:
Figura 4.109. Resultado a Script de Delete a Oracle.
Figura 4.110. Archivo Resultado a Script de Delete a Oracle.
Página 171 de 190
4| Evaluación de la Solución
IGUDES. MTD.
El lector puede corroborar que el borrado se realizo mediante la ejecución del script de select:
Figura 4.111. Script de Select a Oracle.
Se observa que la consulta arroja únicamente las cabeceras sin información:
Figura 4.112. Archivo Resultado a Script de Delete a Oracle.
Finalmente, para la comprobación de la correcta ejecución de módulo de Consultas Múltiples, se ejecuta la consulta
desde
una
herramienta
comercial
de
base
de
datos:
Figura 4.113. Resultado de SqlDeveloper después delDelete a Oracle.
Página 172 de 190
4| Evaluación de la Solución
IGUDES. MTD.
4.13 Consultas Múltiples sobre SQL-Server y Consulta Distribuida desde el módulo de Consultas Múltiples.
Para ejemplificar el funcionamiento de las Consultas Múltiples, a continuación se muestra la ejecución de
sentencias DML en lotes mediante scripts sobre la tabla BASES de Sql-Server que inicialmente se encuentra
vacía como se muestra a continuación:
Figura 4.114. Select a Bases de Sql-Server.
1. Insertar (INSERT) registros en la tabla BASES, con la ejecución del siguiente script en el módulo de Consultas
Múltiples de IGUDES:
Figura 4.115. Script de Insert a Sql-Server.
Se ejecuta el script como se muestra enseguida:
Página 173 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.116. Adjunta Script de Insert a Sql-Server.
Se obtiene el resultado en un archivo de texto:
Figura 4.117. Resultado a Script de Insert a Sql-Server.
Figura 4.118. Archivo Resultado aScript de Insert a Sql-Server.
2. Consultar (SELECT) los registros insertados a la tabla BASES:
Figura 4.119. Script de Select a Sql-Server.
Se ejecuta el script como se muestra enseguida:
Página 174 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.120.AdjuntaScript de Select a Sql-Server.
Se obtiene el resultado en un archivo de texto:
Figura 4.121. Resultado a Script de Select a Sql-Server.
El lector puede observar que los registros insertados en el paso anterior son los mismos que devuelve el resultado:
Figura 4.122.Archivo Resultado aScript de Select a Sql-Server.
3. Realizar una actualización (UPDATE) para algunos de los registros:
Figura 4.123. Script de Update a Sql-Server.
Página 175 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Se ejecuta el script como se muestra enseguida:
Figura 4.124.Adjunta Script de Update a Sql-Server.
Se obtiene el resultado en un archivo de texto:
Figura 4.125. Resultado a Script de Update a Sql-Server.
Figura 4.126.Archivo Resultado aScript de Update a Sql-Server.
Se ejecutan las siguientes sentencias select sobre la tabla BASES para comprobar las actualizaciones:
Figura 4.127. SentenciaSelect a Sql-Server.
El lector puede corroborar que la actualización es correcta:
Figura 4.128.Resultado de Sentencia Select a Sql-Server.
4. Ejecutar una Consulta Distribuida desde el módulo de Consultas Múltiples de la tabla “BASES” de SQL join
con la tabla “PRUEBA” de ORACLE:
Página 176 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.129. Script de Sentencia Select Distribuida entreSql-Server y Oracle.
Se ejecuta el script como se muestra enseguida:
Figura 4.130. Adjunta Script de Select Distribuido a Oracle.
Se obtiene el resultado en un archivo de texto:
Figura 4.131. Resultado a Script de Select Distribuido a Oracle.
Figura 4.132. Archivo Resultado a Script de Select Distribuido.
5. Eliminar (DELETE) los registros que no cruzan en el join anterior de la tabla BASES.
Página 177 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.133. Script de Delet a Sql-Server.
Se ejecuta el script como se muestra enseguida:
Figura 4.134. Adjunta Script de Delete a Sql-Server.
Se obtiene el resultado en un archivo de texto:
Figura 4.135. Resultado a Script de Delete a Sql-Server.
Figura 4.136. Archivo Resultado a Script de Delete a Sql-Server.
Para comprobar el borrado se pueden ejecutar la siguiente sentencia select sobre la tabla BASES:
Página 178 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.137. Sentencia Select a Sql-Server.
Únicamente se conservan los tres registros que si cruzaron en el join.
Figura 4.138. Respuesta a Sentencia Select a Sql-Server
3.14.
Manejo de Vistas desde IGUDES.
Comprobar que la Vista existe en la Base Oracle:
Figura 4.139. Vista_Tabla_Prueba en ORCL.
Consultar una vista de Oracle.
Select * from vista_tabla_prueba
Figura 4.140. Consulta a la Vista_Tabla_Prueba en ORCL.
Respuesta:
Figura 4.141. Contenido de la Vista_Tabla_Prueba en ORCL.
Join entre una vista de Oracle y una tabla externa de Sql-Server.
SELECT * FROM ALUMNO@SQLEXP a
inner join
vista_tabla_prueba b
on
a.nombre=b.nombre
Página 179 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.142. Consulta join entre vista y tabla externa.
Respuesta:
Figura 4.143. Respuesta del Join entre la vista y la taba externa.
Consultar la vista de Oracle desde Sql_Server.
SELECT NOMBRE
,EDADA
,DB_NAME
FROM ORCL..system.vista_tabla_prueba
Figura 4.144. Consulta a la Vista de ORCL desde Sql-Server.
Respuesta:
Figura 4.145. Respuesta a Vista de ORCL desde Sql-Server.
Insertar a una Vista.
-- DESDE ORCL INSERT A LA VISTA
INSERT INTO VISTA_TABLA_PRUEBA
(NOMBRE, EDADA,DB_NAME)
VALUES
('KEKA', 60, 'SQL-SERVER')
Figura 4.146. Insert a Vista.
Página 180 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Respuesta:
Figura 4.147. Repuesta de Insert a Vista.
4.15
Pruebas de Desempeño.
Las pruebas de desempeño se realizaron sobre una arquitectura con las siguientes características: la aplicación se
publico en un servidor web TomCat 5.0, mismo que corre en una laptop Hp dv5 con procesador Intel Core I5
2.27GHz, memoria RAM 4GB, 500Gb en Disco Duro y Sistema Operativo Windows 7.
A continuación se enlistan los pasos que se ejecutaron para la realización de estas pruebas:
A.-Truncar la tabla Empleado y Empresa.
Figura 4.148.Truncado desde consultas simples.
La tabla se muestra sin registros:
Figura 4.149.Resultado al Truncado desde consultas simples.
B.- Mediante el módulo de consultas múltiples se insertaron 25,000 registros en ambas tablas. La inserción de
estos 25, 000 registros se realizó durante 10min en SQL Server:
Figura 4.150. Insert Múltiple a Empleado.
Resultado del módulo de consultas múltiples:
Figura 4.151. Resultado a Insert Múltiple de Empleado.
El Log de la aplicación demuestra que se procesaron los 25000 registros:
Figura 4.152. Log del Insert Múltiple de Empleado.
La inserción de estos registros en Oracle tardo 15 minutos:
Página 181 de 190
4| Evaluación de la Solución
IGUDES. MTD.
Figura 4.153. Insert Múltiple a Empresa.
Figura 4.154. Respuesta de Insert Múltiple a Empresa.
El Log de la aplicación demuestra que proceso los 25000 registros:
Figura 4.155. Log de Inser Múltiple a Empresa.
C.-Consultar los 25000 registros desde el módulo de consultas simples, la cual se ejecuto a las 3:44 pm del 10 de
Abril de 2013 y retorno la respectiva respuesta en 6 segundos:
Figura 4.156.Consulta a empleado.
Respuesta:
Figura 4.157.Respuesta de Consulta a empleado.
D.-Realizar un join distribuido entre las tablas Empleado en Sql-Server con 25000 registros contra Empresa en
Oracle con 25000 registros. La consulta fue lanzada desde Sql-Server. Como se observa en la imagen, esta se
ejecuto a las 3:54 pm del día 10 de Abril de 2013, y la respuesta se obtiene en segundos.
Página 182 de 190
4| Evaluación de la Solución
IGUDES. MTD.
SELECT *
FROM DBO.EMPLEADO A --SQL
INNER JOIN
[ORCL]..[SYSTEM].[EMPRESA] B --ORCL
ON
A.ID_EMPRESA=B.ID_EMPRESA
Figura 4.158.Consulta join entre orcl “empleado” y sql-server “empresa”.
Respuesta:
Figura 4.159.Respuesta de Consulta join entre orcl “empleado” y sql-server “empresa”.
E.- Mediante el módulo de consultas múltiples se insertaron 150,000 registros en la tabla Empleado:
Figura 4.160.Insert a empleado de 150000 registros.
El Log de aplicación demuestra que se insertaron los registros en 1.5 hrs, lo que reafirma que IGUDES conectado
a Oracle inserta en un orden de 25,000 registros cada 15min:
Figura 4.161. Log de Insert a empleado de 150000 registros.
Respuesta de consulta de 150,000 registros en 2.5 minutos.
Figura 4.162. Resultado de Consulta a empleado de 150000 registros.
Página 183 de 190
4| Evaluación de la Solución
4.14.
IGUDES. MTD.
Hallazgos.
Se identificaron algunos hallazgos durante el desarrollo de IGUDES que serian importantes considerar en futuras
investigaciones, mismas que se comentan a continuación:
El más importante de los hallazgos es que no se encontró un sitio o bibliografía que proporcione toda la
información integrada referente a la creación de las conexiones entre SMBD heterogéneos, uno de los
objetivos de la presente tesis fue describir paso a paso el proceso de creación de dichas conexiones.
Se encontró que el enlace entre Oracle y MySql no soporta algunos tipos de datos como String o Date. Es
posible que este problema se solucione con la adquisición de MySql por parte de Oracle.
Es importante tener en cuenta que se debe configurar o iniciar el motor Federated cuando se requiere
crear conexiones homogéneas mediante MySql.
Se deberá configurar el motor Federated en el archivo my.cnf para poder enlazar bases MySql.
El motor federated de MySql solo soporta enlaces homogéneos, por el momento, mediante este motor no
son posibles las conexiones heterogéneas, MySQL al ser un software libre carece de cierta compatibilidad
con SMBD comerciales.
Por el contrario, Oracle XE si soporta conexiones heterogéneas mediante los servicios heterogéneos
HSODBC.
Las conexiones heterogéneas desde Oracle también son posibles mediante Heterogeneous
Services haciendo uso de Transparent Gateway, sin necesidad de invertir recursos en Oracle GoldenGate.
Desde luego con esta opción se reducen las opciones que brinda el GoldenGate.
El enlace entre Oracle y MySql requiere de un driver ODBC.
Por su parte, Microsoft SQL Server implementa drivers OLE-DB para los enlaces heterogéneos.
Página 184 de 190
CONCLUSIONES
IGUDES.
D.
CONCLUSIONES
En la actualidad la demanda de información oportuna y eficaz es vital para la toma de decisiones. Aunado a
esto, la descentralización obliga a las instituciones a distribuir sus áreas de negocio y a invertir sumas importantes
en tecnología que permita mantener una comunicación ágil y eficiente. Incluso es habitual dentro de las
organizaciones la construcción de edificios en zonas geográficas de poco riesgo para alojar las bases de datos de
la organización así como los servidores del plan de recuperación ante desastres (DRP).
Ante estas tendencias y arquitecturas es necesaria la integración de distintas tecnologías para poner la información
a disposición de los usuarios, sin embargo, esto demanda configuraciones y tiempo, factores que la Interfaz Gráfica
Unificada de Sistemas Manejadores de Bases de Datos (IGUDES) cubre con su implementación, permitiendo un
acceso simultaneo y transparente a múltiples SMBD sin importar que sean homogéneos o heterogéneos y desde una
sola interfaz, la cuál es sencilla en su uso misma que se ejecuta mediante un explorador web, características que la
convierten en una aplicación muy practica y funcional ya que brindan beneficios como:
No necesita ser instalada en cada una de las terminales de los usuarios.
Consume únicamente la memoria RAM y procesador que demande una sesión del explorador.
No consume espacio en el disco duro de las terminales que la utilicen.
Reduce los costos de las organizaciones ya que es software libre.
Con este prototipo se lograron desarrollar con éxito los siguientes módulos:
Control de acceso de usuarios mediante validaciones y monitoreo.
Módulo de Consultas Simples, el cual permite la ejecución de sentencias DML sobre diversos SMBD sobre
una arquitectura centralizada.
Módulo de Consultas Múltiples, el cual posibilita la ejecución de un grupo de sentencias DML mediante un
script sobre diversos SMBD homogéneos o heterogéneos ya sea sobre una arquitectura centralizada o
distribuida.
Módulo de Consultas Distribuidas, el cual permite la ejecución de sentencias DML sobre diversos SMBD
homogéneos o heterogéneos en una arquitectura centralizada o distribuida.
Con lo anterior se demuestra que IGUDES cubre los objetivos planteados del protocolo de investigación de la
presente tesis.
IGUDES al ser una aplicación web deja al descubierto un gran número de áreas de oportunidad para futuras
investigaciones ya que por una parte se pueden enriquecer los módulos desarrollados o bien crear nuevos módulos.
A continuación se enlistan algunos elementos que podrían mejorar el diseño y arquitectura de IGUDES MTD.
Aplicar hojas de estilo para mejorar la apariencia de la Interfaz Gráfica.
Implementar Ajax para lograr una funcionalidad dinámica.
Integrar los dos subsistemas de IGUDES: GMS y MTD.
Agregar nuevas configuraciones la integración de diversos SMBD, no solo los contemplados en este
prototipo.
Crear un módulo para realizar modelado de base de datos.
Integrar una aplicación de acceso a IGUDES desde dispositivos móviles.
Crear un módulo para la generación de reportes dinámicos.
Implementar diversos patrones de diseño.
Investigar la factibilidad de insertar a una vista construida en base a tablas distribuidas, y por otra parte
si existe la posibilidad de implementarlo con los conectores de IGUDES.
Página 185 de 190
GLOSARIO
IGUDES. MTD.
GLOSARIO
A|
API. Application Programming Interface: Es el conjunto de funciones y procedimientos (o métodos, en la
programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como
una capa de abstracción. Son usadas generalmente en las bibliotecas (también denominadas vulgarmente
librerías).
B|
BD. Base de Datos:conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente
para su uso posterior.
D|
DAO. Data Access Object.
Datawarehouse: Es una colección de datos orientada a un determinado ámbito, integrado, no volátil y
variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza.
DBMS. Distributed Database Management System: Software que permite la administración de la base de
datos distribuida haciendo que esta distribución sea transparente para los usuarios.
DDBS. Distribute Database System: Es el término que se utiliza para referir conjuntamente a la base de datos
distribuida y al DBMS.
DDL. Data Definition Language: El lenguaje de definición de datos, es el que se encarga de la modificación de
la estructura de los objetos de la base de datos. Incluye órdenes para modificar, borrar o definir las tablas en
las que se almacenan los datos de la base de datos.
DML. Data Manipulation Language: Un lenguaje de manipulación de datos es el proporcionado por el
sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o
manipulación de los datos.
DRAG & DROP. Arrastrar y soltar: Es una expresión informática que se refiere a la acción de mover con el
ratón objetos de una ventana a otra o entre partes de una misma ventana.
DSN. Data Source Name.
E|
ES. Esquema Externo.
Escalabilidad:Es la propiedad deseable de un sistema, una red o un proceso, que indica su habilidad para
reaccionar y adaptarse sin perder calidad, o bien manejar el crecimiento continuo de trabajo de manera
fluida, o bien para estar preparado para hacerse más grande sin perder calidad en los servicios ofrecidos.
ETL. Extract-Transform-Load: Es el proceso que permite a las organizaciones mover datos desde múltiples
fuentes, reformatearlos y limpiarlos, y cargarlos en otra base de datos, datamart o datawarehouse para
analizarlos y apoyar un proceso de negocio.
Explorador (Navegador): Es una aplicación que opera a través de Internet, interpretando la información de
archivos y sitios web para que éstos puedan ser leídos.
G|
GCS. Esquema Conceptual Global.
GMS. Acrónimo del Módulo de Generación y Manipulación de Esquemas de la Interfaz Gráfica Unificada de
Sistemas Manejadores de Bases de Datos (IGUDES).
Página 186 de 190
GLOSARIO
IGUDES. MTD.
H|
Heterogéneo: Termino utilizado para referirse a un sistema informático, en el que sus componentes
presentan arquitecturas diferentes. En el campo de las bases de datos la heterogeneidad es inevitable
cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas.
HTML. HyperText Markup Language: Hace referencia al lenguaje de marcado predominante para la
elaboración de páginas web que se utiliza para describir y traducir la estructura y la información en forma de
texto, así como para complementar el texto con objetos tales como imágenes.
HTTP. Hypertext Transfer Protocol: Es el protocolo usado en cada transacción de la World Wide Web,
orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor.
I|
IDE. Integrated Development Environment (Entorno de Desarrollo Integrado).
IGUDES. Acrónimo de la Interfaz Gráfica Unificada de Sistemas Manejadores de Bases de Datos.
IPC. Informatica PowerCenter.
J|
J2EE. Java Enterprise Edition.
JAR. Java Archive: Es un tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java. Las
siglas están deliberadamente escogidas para que coincidan con la palabra inglesa "jar" (tarro).
JDBC. Java Database Connectivity: Es una API que permite la ejecución de operaciones sobre bases de datos
desde el lenguaje de programación Java, independientemente del sistema operativo donde se ejecute o de
la base de datos a la cual se accede, utilizando el lenguaje SQL del modelo de base de datos que se utilice.
JSP. JavaServer Pages: Es una tecnología Java que permite generar contenido dinámico para web, en forma
de documentos HTML, XML o de otro tipo.
L|
LCS. Esquema Conceptual Local
LIS. Esquema Interno Local.
M|
MDBS. Sistemas Multi Bases de Datos.
Mediator-Wrapper: Arquitectura de sistemas para la consulta de fuentes de datos heterogéneas.
MSSQL. Acrónimo del software de gestión de datos Microsoft SQL Server.
MTD. Acrónimo del Módulo de Manipulación y Transferencia de Datos de la Interfaz Gráfica Unificada de
Sistemas Manejadores de Bases de Datos (IGUDES).
Multithreading. Multihilo: En informática, un hilo de ejecución, hebra o subproceso es la unidad de
procesamiento más pequeña que puede ser planificada por un sistema. La creación de un nuevo hilo es una
característica que permite a una aplicación realizar varias tareas a la vez (concurrentemente). Los distintos
hilos de ejecución comparten una serie de recursos tales como el espacio de memoria, los archivos abiertos,
situación de autenticación, etc. Esta técnica permite simplificar el diseño de una aplicación que debe llevar a
cabo distintas funciones simultáneamente.
Página 187 de 190
GLOSARIO
IGUDES. MTD.
O|
ODBC. Open Database Connectivity: Es un estándar de acceso a las bases de datos desarrollado por SQL
Access Group en 1992. El objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier
aplicación, sin importar qué sistema de gestión de bases de datos almacene los datos.
OLAP. On-Line Analytical Processing: Es una solución utilizada en el campo de la llamada Inteligencia de
Negocios (Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para
ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases
de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes
de dirección, minería de datos y áreas similares.
OLEDB. Enlace e incrustación de objetos para bases de datos.
OLTP. On-Line Transaction Processing: Es un tipo de procesamiento que facilita y administra aplicaciones
transaccionales, usualmente para entrada de datos, recuperación y procesamiento de transacciones (gestor
transaccional). Los paquetes de software para OLTP se basan en la arquitectura cliente-servidor ya que
suelen ser utilizados por empresas con una red informática distribuida.
ORCL: Acrónimo del software de gestión de datos Oracle.
P|
PLUGIN. Un complemento es una aplicación que se relaciona con otra para aportarle una función nueva y
generalmente muy específica.
R|
RAM. La memoria de acceso aleatorio (random-access memory)
RPC.Llamadas a procedimiento remoto.
S|
Servlet: Objeto que corre dentro y fuera del contexto de un contenedor de servlets (por ejemplo Tomcat) y
extienden su funcionalidad. La palabra servlet deriva de otra, applet, que se refiere a pequeños programas
que se ejecutan en el contexto de un navegador web. El uso más común de los servlets es generar páginas
web de forma dinámica a partir de los parámetros de la petición que envíe el navegador web.
SMBD. Sistema Manejador de Bases de Datos: Es un software que funge como interfaz entre un repositorio
de bases de datos y los usuarios y/o aplicaciones que requieran explotar los datos almacenados en dichas
bases.
SQL. Structured Query Language: es un lenguaje declarativo de acceso a bases de datos relacionales que
permite especificar diversos tipos de operaciones en ellas. Una de sus características es el manejo del
álgebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar de forma sencilla
información de interés de bases de datos, así como hacer cambios en ella.
T|
Transacción: Es una unidad básica de información consistente y fiable, consiste en una serie de operaciones
ejecutadas como una acción atómica.
U|
UML. Unified Modeling Language: Es el lenguaje de modelado de sistemas software. Es un lenguaje gráfico
para visualizar, especificar, construir y documentar un sistema.
URL. UniformResource Locator.
Página 188 de 190
BIBLIOGRAFÍA
IGUDES. MTD.
BIBLIOGRAFÍA
(1)
Oracle® Database Concepts 11g Release 1 (11.1). Parte número B28318-06.
Silberschatz, Abraham, F. Korth, Henry, Sudarshan, S. Fundamentos de Bases de Datos. Cuarta Edición. Madrid: McGraw Hill,
2002.
(3)
Rodriguez Zavala, Edward. “Optimización de Recursos de Bases de Datos para obtener Sistemas de Información de Alto
Desempeño”. Tesis M. en C., Director: Javier García García, Instituto Politécnico Nacional, Unidad Profesional Interdisciplinaria
en Ingeniería y Ciencias Sociales y Administrativas, Posgrado en Ciencias de la Informática, 2009.
(4)
Chung, Lawrence. “Client-Server Architecture”. Computer Science Program. University of Texas, Dallas, 2000.
(5)
Özsu, Tamer, Valduriez, Patrick. Principles of Distributed Database Systems. Third Edition. Nueva York: Springer, 2011.
(6)
Liu, L., Pu, C., Barga, R., Zhou, T. “Differential evaluation of continualqueries”. IEEE, 1996
(7)
Gray, J. “Transparency in its place – the case against transparent access to geographically distributed data”. Technical Report
TR89.1. Cupertino, California. Tandem Computers Inc, 1989
(8)
Gligor, V. Popescu-Zeletin, R. “Transaction management in distributedheterogeneous database management systems”, 1986.
(9)
Du, W. Elmagarmid, A. “Quasi-serializability: A correctness criterion for global concurrency control in interbase”. 15th Int.
Conf. on Very Large Data Bases, 1989.
(10)
Heimbigner, D. McLeod, D., ”A federated architecture for informationmanagement”. ACM, 1985.
(11)
Wiederhold, G. “Mediators in the architecture of future information systems”, 1992.
(12)
Codd, E., “Twelve rules for on-line analytical processing”. Computerworld, 1995.
(13)
Lenzerini, M., ” Data integration: a theoretical perspective”. Symp. on Principles of Database Systems, 2002.
(14)
Koch, C., ”Data Integration against Multiple Evolving Autonomous Schemata”. Ph.D. thesis, Technical University of Vienna,
2001.
(15)
León, Alberto, Indra, Widja. Communication Networks: Fundamental Concepts and Key Architectures. Second Edition. United
(16)
States: McGraw-Hill, 2004. Domínguez Dorado, M. Acceso a bases de datos desde aplicaciones java. Madrid: Iberprensa, 2004.
(24)
By Bryan Basham, Kathy Sierra, Bert Bates., “Head First Servlets and JSP”, O'Reilly Media, Inc. Copyright.
(25)
C.Costilla, Sistemas de Bases de Datos. Conceptos, Técnicas y Lenguajes, ISBN: 84-7402-271-1, 464 páginas, Servicio de
Publicaciones, ETSI Telecomunicación.
(26)
Carmen Costilla, M. J. Bas, J. Villamor: SIRIO: A Distributed Information System over a Heterogeneous Computer Network.
ACM SIGMOD RECORD, 22(1): 28-33.
(27)
Tim Berners-Lee, Robert Cailliau, Jean-François Groff: The World-Wide Web. Computer Networks and ISDN Systems 25(4-5):
454-459 (1992)
(28)
Tim Berners-Lee: World-Wide Computer. Commun. ACM 40(2): 57-58
(29)
Florescu D., Levy A. and Medelzon A., Database Techniques for the World Wide Web: A Survey, SIGMOD RECORD, September,
1998.
(30)
C.Costilla, Sistemas de Bases de Datos. Conceptos, Técnicas y Lenguajes, Servicio de Publicaciones, ETSI Telecomunicación,
1999.
(31)
Domenig R. and Dittrich K.R., An Overview and Classification of Mediated Query Systems, in ACM SIGMOD RECORD, Vol. 28, N.
3, pp. 63-72.
(32)
W. Litwin and A. Abdellatif, An overview of the Multidatabases Manipulation Language - MDL, Proc. IEEE, Vol. 75, Nº 5, pp.
621-631, May 1987.
(33)
Özsu T. and Valduriez P., Principles of Distributed Database Systems, 2nd edition, Prentice Hall, 1999.
(34)
Gio Wiederhold (1992). Mediators in the Architecture of Future Information Systems. IEEE Computer, 25(3):38–49.
(35)
Gio Wiederhold: Meditation to Deal with Heterogeneous Data Sources. INTEROP 1999: 1-16
(36)
Calleja A, Rodríguez MJ, Costilla C and Fernández R., A Grid Semantic Approach for a Digital Archive Integrated Architecture, in
The Third International Conference on Information Technology and Applications (ICITA'05), Session: Agent, Datamining and
Ontologies, ADO'05, Sydney, Australia, http://attend.it.uts.edu.au/icita05/, ISBN: 0-7695-2316-1, IEEE Computer Society, Los
Alamitos, California, USA, pp. 227-232, July 2005.
(37)
Carmen Costilla, Arquitecturas de los SGBD Distribuidos, modelo Mediator-Wreapper.pdf, Madrid, Diciembre de 2010.
(2)
BIBLIOGRAFÍA ELECTRÓNICA
(17)
Ecma International. Estándar ECMA-262. Edición 5.1. 2011, http://www.ecma-international.org/publications/files/ECMAST/ECMA-262.pdf
(18)
Oracle®
Core
J2EE
Patterns
Data
Access
Object.
Disponible
en
Web:
<http://www.oracle.com/technetwork/java/dataaccessobject-138824.html> [Consulta: 15 de Diciembre del 2012]
(19)
Core J2EE Pattern Catalog. Disponible en Web: <http://www.corej2eepatterns.com/index.htm> [Consulta: 16 de Diciembre del
2012]
(20)
ODBC
Introducción
a
la
conexión
de
base
de
datos
abierta.
Disponible
en
Web:
<http://support.microsoft.com/kb/110093> [Consulta: 16de Diciembre del 2012]
Página 189 de 190
BIBLIOGRAFÍA
IGUDES. MTD.
Consultas
distribuidas,©
2012
Microsoft.Disponible
en
Web:
<http://msdn.microsoft.com/eses/library/ms188721%28v=sql.105%29.aspx> [Consulta: 16 de Diciembre del 2012]
(22)
Oracle®
Getting
Started
with
the
JDBC
API
JDBC
Overview.
Disponible
en
Web:
<http://docs.oracle.com/javase/6/docs/technotes/guides/jdbc/getstart/GettingStartedTOC.fm.html>[Consulta: 19 de Febrero
del 2013]
(23)
Oracle®.
Java
EE
Reference
at
a
Glance.
Disponible
en
Web:
<http://www.oracle.com/technetwork/java/javaee/documentation/index.html>[Consulta: 19 de Febrero del 2013]
(40)
Oracle®
Database
SQL
Reference
10g
Release
3.
Disponible
en
Web:
<http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_5005.htm> [Consulta: 10de Diciembre del
2012]
(41)
Oracle®Database
Administrator's
Guide
11g
Release
3.Disponible
en
Web:
<http://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm>[Consulta:10de Diciembre del 2012]
(42)
Oracle®
Database
SQL
Reference
10g
Release
3.Disponible
en
Web:
<http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/statements_5005.htm> [Consulta: 10de Diciembre del
2012]
(43)
Databasejournal.
Making a Connection from Oracle to SQL Server.
Disponible en Web:
http://www.databasejournal.com/features/oracle/article.php/3442661/Making-a-Connection-from-Oracle-to-SQL-Server.htm [
Consulta:10de Diciembre del 2012]
(44)
Ignacio
Barrancos.
DBLinks
desde
Oracle
hacia
MySQL.
Disponible
en
Web:
<http://tecnoquia.blogspot.com.es/2012/04/dblinks-desde-oracle-hacia-mysql.html>[Consulta:10de Diciembre del 2012]
(45)
hs2n. Oracle: Create Database Link to MySQL Database. Disponible en Web: <http://hs2n.wordpress.com/2012/04/03/oraclecreate-database-link-to-mysql-database/>[Consulta:10de Diciembre del 2012]
(46)
Quackit.
Creating
a
Linked
Server.
Disponible
en
Web:
<http://www.quackit.com/sql_server/sql_server_2008/tutorial/linked_servers.cfm>[Consulta:10de Diciembre del 2012].
(47)
Derek Dieter. How to Add a Linked Server November 21, 2010. Disponible en Web:< http://sqlserverplanet.com/dba/how-toadd-a-linked-server>[Consulta:10de Diciembre del 2012].
(48)
Databasejournal. Setting up a Linked Server for a Remote SQL Server Instance. July 31, 2007. Disponible en Web:<
http://sqlserverplanet.com/dba/how-to-add-a-linked-server>[Consulta:10de Diciembre del 2012]
(49)
bryansgeekspeak. SQL Server 2008R2 Linked Server to Oracle 13.2.0.2 Instance. Thursday, December 08, 2013. Disponible en
Web: <http://www.bryansgeekspeak.com/2011/12/sql-server-2008r2-linked-server-to.html>[Consulta:10de Diciembre del 2012]
(50)
ideaexcursion. Connecting to Oracle from SQL Server. Jan 052009. Disponible en Web:
<http://www.ideaexcursion.com/2009/01/05/connecting-to-oracle-from-sql-server/>[Consulta:10de Diciembre del 2012]
(51)
ideaexcursion. HOWTO: Setup SQL Server Linked Server to MySQL. Feb 252009. Disponible en Web:
<http://www.ideaexcursion.com/2009/02/25/howto-setup-sql-server-linked-server-to-mysql/>[Consulta:10 de Diciembre del
2012]
(52)
Manual de referencia de MySQL.
Cómo usar las tablas FEDERATED. Disponible en Web:
<http://dev.mysql.com/doc/refman/5.0/es/federated-use.html>[Consulta:10de Diciembre del 2012]
(53)
Ignacio Barrancos en sábado, abril 14, 2012 .tecnoquia. DBLinks desde MySQL hacia Oracle. Disponible en Web:
<http://tecnoquia.blogspot.com.es/2012/04/dblinks-desde-mysql-hacia-oracle.html>[Consulta:10de Diciembre del 2012]
(54)
Latindevelopers. 29 noviembre, 2013. Activar el motor FEDERATED en MySQL. Disponible en Web:
<http://www.latindevelopers.com/ivancp/2011/11/activar-federated-mysql/>[Consulta:10de Diciembre del 2012]
(21)
(55)
Wikipedia, Terminal Tonta. Disponible en Web:<http://es.wikipedia.org/wiki/Terminal_tonta>[Consulta:03 de Abril del 2013]
Página 190 de 190