DECLARACION JURADA - Colegio de Ingenieros del Perú

UNIVERSIDAD NACIONAL “SAN LUIS GONZAGA” DE ICA
FACULTAD DE INGENIERIA DE SISTEMAS
TESIS
PARA OPTAR EL TITULO PROFESIONAL DE:
INGENIERO DE SISTEMAS
TEMA
“Aplicación, Compilación e Intérprete de un
Lenguaje en la Realización de Consultas para
Base de Datos Múltiples”
TESISTAS:
BACHILLER: CAYO MORALES GERMAN
BACHILLER: SCHIMIT CAMACHO, HANSY
ICA – PERU
2010
DEDICATORIA:
A mis padres quienes fueron los
forjadores de mi carrera profesional, a
mis hermanos quienes me apoyaron en
todo momento para la culminación de
mi carrera profesional.
Germán
DEDICATORIA:
A mis padres y mis hermanos
por ser los ejes en mi formación
profesional.
Hansy
INDICE
Introducción
1
Resumen
4
I.
Planteamiento del Problema y Justificación
5
Antecedentes
5
Definición del Problema
5
Importancia de la Investigación
7
Objetivos
8
Objetivo General
8
Objetivos Específicos
8
Estrategia y Metodología
8
II.
III.
Capítulo I: Marco Teórico
9
1.1.
Definición de DBMS
9
1.2.
MYSQL
13
1.3.
SQLSERVER
14
1.4.
ORACLE
26
1.4.1. Programas y Archivos que componen Oracle
29
1.4.2. El PGA
30
1.4.3. El SGA
30
1.4.4. Diferentes Herramientas de Oracle
30
1.4.5. Estructura de bloqueo de código
33
1.4.6. Disparadores
34
1.4.7 Servicios de Seguridad
35
1.4.8. Administración de la Estructura de la Base de Datos
45
1.4.9. Funciones del Administrador de Base de datos
51
1.4.10. Usuarios de la Base de datos
55
Capitulo 2. Tecnologías Disponibles para la comunicación con fuentes
de datos heterogéneas.
56
2.1.
Compuertas para Base de Datos
56
2.2.
Monitores de Procesamiento de Transacciones
57
2.3.
Conectividad de Base de Datos abierto (ODBC)
58
2.4.
Conectividad de Base de Datos Java
59
2.5.
OLEDB
62
2.6.
CORBA
63
Capítulo 3. Procesamiento de consultas en un sistema de base
de datos múltiples
3.1.
3.2
65
Arquitectura de un Procesador de Consultas de base
Datos múltiple
66
3.1.1. Analizador Léxico, Sintáctico y Validación.
68
3.1.2. Descomponedor de Consultas
68
3.1.3. El Generador de Planes.
69
El Catálogo de un SBDF
69
Capítulo 4. Lenguajes de bases de datos
71
4.1.
Lenguaje de Consultas
71
4.2.
Lenguaje de Manipulación de Datos
71
4.3.
Lenguaje de Definición de Datos
72
4.4.
Construcción de Lenguajes de Bases de Datos
72
4.5.
Compiladores
73
4.5.1. Fases del un Compilador
73
4.6.
Intérpretes
74
4.7.
Lenguaje de Consultas de bases Datos múltiples
74
4.7.1. La fase de análisis de un lenguaje de consultas.
75
4.7.2. Detección e Información de Errores
76
Capítulo 5. LMBD: Un Lenguaje de Consulta Para un Sistema
Multibase de Datos
78
5.1.
Desarrollo del Analizador Léxico y Sintáctico
80
5.2.
Desarrollo del Analizador Semántico
83
5.2.1. Reglas Semánticas
84
5.3.
Desarrollo del Descomponedor de Consultas
85
5.4.
Desarrollo del Despachador de Consultas
87
5.5.
Desarrollo de la Interfaz de Usuario para la Captura
y Presentación de Información
88
5.6.
La Interface de Programación de la Aplicación de LMBD
91
Conclusiones
Bibliografía
Anexos
Apéndice A. Reglas gramaticales de LMen su forma B
Apéndice B. Tipos de conflictos de integración
Apéndice C. Ejemplos de procesamiento de consultas multibase de datos
Apéndice D. Algoritmo ordenamiento-mezcla para la operación reunión
Apéndice E. Implementación en Java de la clase Result
Apéndice F. Implementación en Java de la clase Metadatos
INTRODUCCION
La evolución de la computación ha dado origen a diversas formas de
organización de la información. Debido a que la mayoría de las bases de datos
son diseñadas e implementadas respondiendo a diferentes necesidades, en
diferentes circunstancias y con diferentes recursos, da como resultado una
amplia heterogeneidad entre los diversos depósitos de información.
La información es el recurso clave tanto en los negocios, gobierno o ambiente
académico. La forma en que la información se encuentra organizada es
diversa, múltiples métodos de acceso a paradigmas para el manejo de
información son utilizados. La necesidad de manipular información global
requiere el accesar información desde distintas fuentes de datos y no es
razonable tener que aprender distintos métodos de manipulación de datos y
aun es menos razonable pensar que las organizaciones trasladen toda su
información a un modelo de datos común y con una sola forma de
manipularlos. De esta manera es necesario disponer de sistemas de base de
datos que puedan operar sobre una red distribuida y puedan compaginar una
mezcla heterogénea de computadoras, sistemas operativos, enlace de
comunicaciones y sistemas manejadores de base de datos locales.
Muchas organizaciones tienen diferentes computadoras y sistemas de base de
datos. En la mayoría de los casos, este ambiente debe ser preservado mientras
también existe la necesidad de compartir información en una o más bases de
datos globales. La manipulación de datos global se requiere para recuperar y
actualizar información semánticamente similar en diferentes nodos y con
diferentes representaciones de datos. Las multibases de datos integran
información desde bases de datos heterogéneas locales en un ambiente
distribuido y presentan un acceso global a los usuarios con métodos
transparentes para dar la información total en el sistema. La característica
esencial es la autonomía que las bases de datos locales conservan para
atender a aplicaciones existentes e incluso nuevas.
Hay un amplio rango de soluciones para compartir información global en un
sistema distribuido y la literatura utiliza una variedad de términos para
describirlos: base de datos distribuidos, multibases de datos, bases de datos
federadas, sistemas interoperables, etc. Todos estos términos describen un
sistema distribuido que incluye un componente para acceso a la información
global y múltiples componentes locales que manejan solo la información en un
sitio. Las diferencias entre estos residen en la estructura de los componentes
globales y cómo interactúan con los componentes locales.
El objetivo de esta tesis es presentar una investigación en el campo de las
multibases de datos. Se pretende mostrar un panorama claro de la forma en
que una multibase de datos puede ser implementada y la tecnología disponible
para este propósito. Además como parte práctica de esta investigación se ha
desarrollado un prototipo capaz de integrar información desde dos bases de
datos utilizando SQL como lenguaje de consulta y lo
más importante: la
transparencia con la que la recuperación de la información se lleva a cabo.
En el capítulo I estudiaremos en qué consiste una multibase de datos, como se
clasifican, se profundizara mas en las bases de datos federadas y por último se
describirán trabajos que se han desarrollado en esta área y algunas de sus
características.
En el capítulo 2 se abordara uno de los aspectos más importantes en una
multibase de datos, es decir, la conexión con las fuentes de datos. Se
estudiaran distintas tecnologías que permitan establecer la comunicación con
fuentes de datos heterogéneas y se profundizara más en la conocida como
JDBC.
En el capítulo 3 se estudia la arquitectura de un procesador de consultas
multibase de datos, las funciones que desempeñan cada modulo, y la
información que debe contener el catalogo de una multibase de datos como
pieza clave de interacción con los distintos módulos.
En el capítulo 4 se trata lo referente a los lenguajes para bases de datos, se da
una clasificación, se describe la tecnología para el desarrollo de estos y se dan
las bases para la implementación de un lenguaje de consulta.
Por último el capitulo 5 describe la manera en cómo fue implementado el
lenguaje de consulta para una multibase de datos como parte práctica de esta
tesis. Se describen los algoritmos propuestos y se explica la implementación de
los módulos del procesador de consultas multibase de datos.
RESUMEN
El presente proyecto de tesis presentará todo lo concerniente a la aplicación,
compilación e intérprete de un Lenguaje de Consultas para base de datos
múltiple, lo cual se apoya en la utilización del SQL Server como lenguaje de
consulta integrando técnicas de manejo de sistemas Multidatos y Tecnologías
disponibles para la comunicación con fuentes de datos heterogéneas.
Así mismo se realizara todo lo concerniente al procesamiento de consultas de
base de datos múltiples basados en la arquitectura de consultas de base de
datos, desarrollando un catalogo de un SBDF
También se investigará todo lo relacionado con el Lenguaje de consultas que
pretenderá mostrar un panorama claro de la forma en que una multibase de
datos puede ser implementada y la tecnológica disponible para este fin y se
desarrollara un prototipo necesario para la integración de la información de las
2 bases de datos más utilizadas. SQL como lenguaje de consulta en la
recuperación de la información.
También se mencionarán la forma como será implementado el lenguaje de
consultas para un sistema de base de datos múltiples y se describirán los
algoritmos propuestos.
I.
PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION
En este acápite se dejara ver los diferentes motivos por los cuales se
considera necesaria la realización de la monografía a desarrollar, de la
misma
manera
se
encontrará
una
documentación,
de
algunos
antecedentes relevantes del tema central de este texto. Así mismos se
hacen públicas las diferentes limitantes a las que está sometido el trabajo
y por su puesto los objetivos que se fijaron desde el principio.
Antecedentes
A través del tiempo que han sido utilizadas las bases de datos, se han ido
incorporando diferentes elementos que tienen como tarea el hacerlas más
funcionales, robustas y amigables. Dentro de estas implementaciones se
pueden
mencionar
la
integridad
referencial,
implementación
de
transacciones, los procedimientos almacenados, actualización en cascada
así como los disparadores y otros elementos.
El tema del que trata este documento está relacionado con los
procedimientos almacenados, por lo tanto en las siguientes líneas se
describen que son éstos, así mismo se analizarán otros elementos que
son necesarios para la comprensión de este documento.
Definición del problema.
Los principales problemas que se presentan en este momento en los
proyectos referentes a bases de datos consisten en la incertidumbre que
tiene el administrador de ellas a causa de la seguridad en los datos. Es
decir, en algunos DBMS sobre todo de libre distribución, no brindan la
posibilidad de implementar seguridad a nivel de registros y es por ello que
se vuelve una verdadera pesadilla la administración de estas bases de
datos.
Uno de los problemas más palpables que solucionan los procedimientos
almacenados se refiere al hecho de que en ocasiones mediante una sola
consulta SQL(por muy elaborada que sea ésta), no es posible recuperar
el total de la información requerida, y en consecuencia sea necesario la
utilización de varias sentencias SQL para este fin. Este tipo de procesos
tienen como consecuencia un cúmulo de consultas que están viajando del
cliente al servidor y con ello contribuyendo a congestionar el tráfico de la
red.
Justificación del Problema
El presente estudio se justifica por cuanto los sistemas de bases de datos
se han ido incorporando a las diferentes empresas del país y del mundo
con muy buena aceptación, es por ello que el presente estudio de
investigación tendrá la responsabilidad de estar actualizando a las
empresas en los temas que contribuyan a ofrecer un mejor servicio en la
creación, administración y mantenimiento de estos elementos.
Tengamos en cuenta la opinión de algunos expertos en las cuestiones
informáticas que mencionan que la tendencia de todas las tecnologías
van encaminadas hacia el Internet y para ciertos procesos largos como
los
que
se
exhibirán
en
algunos
capítulos
del
documento
es
prácticamente imposible brindarlos sin la utilización de los lenguajes de
consulta.
Una de las consecuencias esperadas al seleccionar este tema fue sin
duda alguna el incrementar la calidad de los proyectos, es decir,
comenzar a incorporar algunos elementos sofisticados a las bases de
datos con la finalidad de que el rendimiento obtenido sea el óptimo.
Es imperante mencionar que desafortunadamente los textos con carácter
de novedosos en el área de la tecnología se traducen (si es que llega a
suceder) muchísimo tiempo después al español, es por ello que es difícil
encontrar referencias de ellos en este idioma, así que realizando un
esfuerzo por presentar una aportación en español se realizará
este
trabajo.
Formulación del Problema
¿En qué medida la Aplicación, Compilación e Intérprete de un Lenguaje
en la realización de consultas mejora la toma de decisiones en el manejo
de la información?
Importancia de la Investigación
La investigación la consideramos de vital importancia, ya que la principal
función de un lenguaje de consulta es la de efectuar la toma de
decisiones en el manejo de la información de toda institución que le
permitan poder competir en un mundo globalizado, y cada vez más
competitivo; es por ello que se hace importante poder mejorar los
lenguajes de consulta
II.
OBJETIVOS
Objetivo General
Hacer de conocimiento las características generales que tienen los
sistemas multibases de datos para mejorar la seguridad y velocidad en
sus bases de datos, y como utilizarlos.
Objetivos Específicos
• Que
los
usuarios
consideren
incorporar
tecnologías
para
la
comunicación de fuentes de datos heterogéneas.
• Dar a conocer la estructura principal de un procesamiento de consultas
en un sistema de base de datos múltiples.
• Que se tenga en cuenta la utilización del Lenguaje de Consultas para
un sistema de datos múltiples.
III.
Estrategia y Metodología.
Diseño de la Investigación:
Para el desarrollo del presente proyecto de investigación será de tipo:
Aplicada y naturaleza práctica.
Nivel de la Investigación
El nivel del presente proyecto de investigación a desarrollarse será de tipo
descriptivo.
CAPITULO I: MARCO TEORICO
1.1.
Definición de DBMS
Los sistemas de Gestión de Base de Datos, son aplicaciones que
permiten a los usuarios definir, crear y mantener la base de datos y
proporciona un acceso controlado a la misma. Los SGBD es la
aplicación que interactúa con los usuarios de los programas de
aplicación y la base de datos.
Algunos de los SG_BD más conocidos son: SQL, DB2, ORACLE,
INFORMIX, SYBASE, PARADOX, ACCESS, FOXPRO, MYSQL.
El sistema de gestión de bases de datos es esencial para el adecuado
funcionamiento y manipulación de los datos contenidos en la base. Se
puede definir como: "El Conjunto de programas, procedimientos,
lenguajes, etc. que suministra, tanto a los usuarios no informáticos como
a los analistas, programadores o al administrador, los medios necesarios
para describir, recuperar y manipular los datos almacenados en la base,
manteniendo su integridad, confidencialidad y seguridad".
Objetivos de un SGDB
 Definir la Base de Datos mediante el Lenguaje de Definicion de
datos, el cual permite especificar la estructura, tipo de datos y las
restricciones sobre los datos, almacenándolo todo en la base de
datos.
 Separar la descripción y manipulación de la ata, permitiendo un
mayor entendimiento de los objetos, además de flexibilidad de
consulta y actualización de los datos.
 Permitir la inserción, eliminación, actualización y consulta de los
datos mediante el Lenguaje de Manejo de Datos, lo que permite
resolver el problema que presentan los sistemas de archivos, donde
hay que trabajar con un conjunto fijo de consultas o la necesidad de
tener muchos programas de aplicaciones. Existen dos tipos de
programas de Manejo de Datos, los cuales se diferencian por la
forma en que acceden a los datos.
 Proporciona acceso controlado a la base de datos.
 Gestionar la estructura física de los datos y su almacenamiento,
proporcionando eficiencia en las operaciones de la base de datos y
el acceso al medio de almacenamiento.
 Proporciona un mecanismo de vistas, que permite a cada usuario
tener su propia vista o visión de la base de datos. El lenguaje de
defincion nos permite definir las vistas como subconjuntos de la base
de datos.
 Eliminar la redundancia de datos, establecer una mínima duplicidad
en los datos y minimizar el espacio en disco utilizado.
 Proveer
interfaces
permitiendo
la
procedimentales
manipulación
por
y
no
usuarios
procedimentales,
interactivos
y
programadores.
 Independizar la estructura de la organización lógica de los datos
(Independencia física).
 Independizar la descripción lógica de la Base de datos y las
descripciones particulares de los diferentes puntos de vistas de los
usuarios.
Actores en el entorno de una Base de Datos

Administrador de la base de datos: se encarga del diseño físico de la
base
de datos y de su implementación, realiza el control de la
seguridad y de la concurrencia, mantiene el sistema para que
siempre se encuentre operativo y se encarga de que los usuarios y
las aplicaciones obtengan buenas prestaciones. El administrador
debe conocer muy bien el que esté funcionando.

Diseñadores de la base de datos: realizan el diseño lógico de la
base de datos, debiendo identificar los datos, las relaciones entre
datos y las restricciones sobre los datos y sus relaciones. El
diseñador de la base de datos debe tener un profundo conocimiento
de los datos de la empresa y también debe conocer sus reglas de
negocio. Las reglas de negocio describen las características
principales de los datos tal y como las ve la empresa.
El diseñador de la base de datos debe implicar en el desarrollo del
modelo de datos a todos los usuarios de la base de datos, tan pronto
como sea posible. El diseño lógico de la base de datos es
independiente del SGBD concreto que se vaya a utilizar es
independiente de los programas de aplicación, de los lenguajes de
programación y de cualquier otra consideración física.

Programadores de aplicaciones: se encargan de implementar los
programas de aplicación que servirán a los usuarios finales. Estos
programas de aplicación son los que permiten consultar datos,
insertarlos, actualizarlos y eliminarlos. Estos programas se escriben
mediante lenguajes de tercera generación o de cuarta generación.

Usuarios finales: consultan, actualizan y generan reportes de la base
de datos. A los usuarios finales también se les llama clientes de la
base de datos.
La tabla adjunta muestra el funcionamiento de un DBMS.
1.2.
MYSQL
La historia del MySQL (cuya sigla en inglés se traslada a My Structured
Query Language o Lenguaje de Consulta Estructurado) se remite a
principios de la década de 1980. Programadores de IBM lo desarrollaron
para contar con un código de programación que permitiera generar
múltiples y extendidas bases de datos para empresas y organizaciones
de diferente tipo. Desde esta época numerosas versiones han surgido y
muchas de ellas fueron de gran importancia. Hoy en día MySQL es
desarrollado por la empresa Sun Mycrosystems.
Una de las características más interesantes de MySQL es que permite
recurrir a bases de datos multiusuario a través de la web y en diferentes
lenguajes de programación que se adaptan a diferentes necesidades y
requerimientos. Por otro lado, MySQL es conocida por desarrollar alta
velocidad en la búsqueda de datos e información, a diferencia de
sistemas anteriores. Las plataformas que utiliza son de variado tipo y
entre ellas podemos mencionar LAMP, MAMP, SAMP, BAMP y WAMP
(aplicables a Mac, Windows, Linux, BSD, Open Solaris, Perl y Phyton
entre otras).
Se están estudiando y desarrollando nuevas versiones de MySQL que
buscan presentar mejoras y avances para permitir un mejor desempeño
en toda aquella actividad que requiera el uso de bases de datos
relacionales. Entre estas mejoras podemos mencionar un nuevo
dispositivo de depósito y almacenamiento, backup para todos los tipos
de almacenamientos, replicación segura, planificación de eventos y otras
más.
1.3.
SQLSERVER
Microsoft SQL Server constituye un lanzamiento determinante para los
productos de bases de datos de Microsoft, continuando con la base
sólida establecida por SQL Server 6.5. Como la mejor base de datos
para Windows NT, SQL Server es el RDBMS de elección para una
amplia gama de clientes corporativos y Proveedores Independientes de
Software (ISVs) que construyen aplicaciones de negocios. Las
necesidades y requerimientos de los clientes han llevado a la creación
de innovaciones de producto significativas para facilitar la utilización,
escalabilidad, confiabilidad y almacenamiento de datos.
Objetivos del Diseño de SQL Server
Los clientes están buscando soluciones para sus problemas de
negocios. La mayoría de las "soluciones" de bases de datos solamente
traen múltiples niveles de costos y complejidad. La estrategia de
Microsoft es la de hacer que SQL Server sea la base de datos más fácil
de utilizar para construir, administrar e implementar aplicaciones de
negocios. Esto significa tener que poner a disposición un modelo de
programación rápido y sencillo para desarrolladores, eliminando la
administración de base de datos para operaciones estándar, y
suministrando
herramientas
sofisticadas
para
operaciones
más
complejas.
SQL Server 7.0 disminuye el costo total de propiedad a través de
características como administración multi-servidor y con una sola
consola; ejecución y alerta de trabajos basadas en eventos; seguridad
integrada; y scripting administrativo. Esta versión también libera al
administrador de base de datos para aspectos más sofisticados del
trabajo al automatizar las tareas de rutina. Al combinar estos poderosos
servicios
de
administración
con
las
nuevas
características
de
configuración automática, Microsoft SQL Server 7.0 es la elección ideal
de automatización de sucursales y aplicaciones de base de datos
insertadas.
Los clientes invierten en sistemas de administración de bases de datos,
en forma de aplicaciones escritas para esa base de datos y la educación
que implica para la implementación y administración. Esa inversión debe
protegerse: a medida que el negocio crece, la base de datos deberá
crecer y manejar más datos, transacciones y usuarios. Los clientes
también desean proteger las inversiones a medida que escalan
aplicaciones de base de datos hacia equipos portátiles y sucursales.
Para cumplir con estas necesidades, Microsoft ofrece un motor de base
datos único que escala desde una computadora portátil que ejecuta
Windows® 95 o Windows 98, hasta clusters de procesadores múltiples
simétricos de terabyte que ejecutan Windows NT Server Enterprise
Edition. Todos estos sistemas mantienen la seguridad y confiabilidad
que exigen los sistemas de negocios de misión crítica.
Nueva para el lanzamiento de 7.0 es una versión de rastro de baja
memoria con capacidades de replicación de multi-sitio. Se ajusta muy
bien a las necesidades cada vez mayores del mercado de la
computación móvil. Las otras características tales como bloqueo a nivel
de línea dinámico, el paralelismo intra-query, query distribuido, y mejoras
para las bases de datos muy grandes (VLDB) hacen que el SQL Server
7.0 sea la elección ideal para sistemas OLTP de alta tecnología y
sistemas de data warehousing.
Mientras los sistemas de procesamiento siguen siendo un componente
clave para las infraestructuras de bases de datos corporativas, las
compañías
también
están
invirtiendo
bastante
en
mejorar
la
comprensión que tienen de sus datos. La estrategia de Microsoft
consiste en reducir el costo y la complejidad del data warehousing
mientras hace que la tecnología sea más accesible a una mayor
cantidad de público.
Microsoft ha establecido un enfoque total a todo el proceso de data
warehousing (almacenamiento de datos) . El objetivo es facilitar la
construcción y diseño de soluciones de data warehousing costo efectivas
a través de una combinación de tecnologías, servicios y alianzas con los
proveedores.
La Microsoft Alliance for Data Warehousing es una coalición que une a
los líderes en la industria de almacenamiento de datos y aplicaciones. El
Microsoft Data Warehousing Framework constituye un conjunto de
interfaces de programación diseñadas para simplificar la integración y
administración de soluciones de data warehousing.
Las innovaciones del producto en SQL Server 7.0 mejoran el proceso de
data warehousing: Servicios de Transformación de Datos; manejo
mejorado de las consultas complejas y bases de datos muy grandes;
procesamiento analítico en línea e integrado; y el Microsoft Repository.
Otro componente esencial es el soporte extenso para integración de
terceros.
Las innovaciones permiten que SQL Server 7.0 sea el líder en varias de
las categorías de aplicación de rápido crecimiento en la industria de
base de datos. Estas incluyen comercio electrónico, computación móvil,
automatización de sucursales, aplicaciones de línea de negocios
insertadas y mercados de datos.
Las áreas de liderazgo e innovación en el Microsoft SQL Server incluyen

La primera base de datos en escalar desde la computadora portátil
hasta la empresa utilizando la misma base de código y ofrecer el
100% de compatibilidad de código

La primera base de datos en soportar la auto-configuración y autosintonización

Primera base de datos con OLAP integrado

La primera base de datos con Servicios de Transformación de Datos
integrado

El Data Warehousing Framework constituye el primer enfoque
comprehensivo al problema de metadatos

La primera base de datos en proveer administración de multiservidor para cientos de servidores

La más amplia gama de opciones de replicación de cualquier base
de datos

La mejor integración con Windows NT Server

La mejor integración con Microsoft Transaction Server

Lanzamientos SQL Server Recientes
Esta sección provee una historia concisa de los lanzamientos SQL
Server reciente. Una historia completa del desarrollo de SQL Server,
desde sus comienzos hasta el lanzamiento del 6.5 se encuentra
disponible en Dentro del Microsoft SQL Server 6.5, de Ron Soukup,
publicado por Microsoft Press, ISBN 1-57231-331-5.

El Standard Edition de SQL Server fue lanzado en abril de 1996.

El Enterprise Edition fue lanzado en diciembre de 1997. Se
incluyeron características adicionales en esta edición tales como
soporte para Microsoft Cluster Server, sintonización de 4 GB RAM,
English Query y soporte para sistemas de hasta 8 procesadores.

El Service Pack actual para SQL Server
es SP4, lanzado en
diciembre de 1997. SP3 fue lanzado en junio de 1997, SP2 en
diciembre de 1996 y SP1 en agosto de 1996.

Beta 1 fue lanzado en junio de 1997 a 200 clientes. Este grupo
incluía un número limitado de proveedores independientes de
software (ISV), autores de libros, diseñadores de materiales para
cursos, OEMs y algunas cuentas corporativas. No se pusieron
copias a disposición de la prensa o analistas. Este lanzamiento
enfocó las pruebas de funcionalidad de bajo nivel y programación de
interfaces.

Beta 2 fue lanzada a finales de diciembre de 1997 a 3000 clientes. El
cubrimiento de las cuentas corporativas y de la comunidad ISV fue
incrementado ampliamente, y se agregaron cuentas internacionales.
Se entregaron copias de Beta 2 a la prensa y a los analistas en el
Taller de Examinadores celebrado el 21 y 22 de enero.

La versión Beta de Mercadeo será lanzada el segundo trimestre del
año en curso con alta disponibilidad.

El lanzamiento a fabricantes está planeado para la segunda mitad
del año 1998. Las ediciones Standard y Enterprise de SQL Server
7.0 serán lanzadas simultáneamente.
Microsoft SQL Server revoluciona el concepto de Base de Datos para la
Empresa. Reúne en un sólo producto la potencia necesaria para
cualquier aplicación empresarial crítica junto con unas herramientas de
gestión que reducen al mínimo el coste de propiedad. Con Microsoft
SQL Server, la empresa tiene todo de serie.
Miles de Soluciones Disponibles: Tendrá libertad de elección, ya que
todas las aplicaciones de gestión del mercado corren sobre Microsoft
SQL Server

Escalabilidad: Se adapta a las necesidades de la empresa,
soportando desde unos pocos usuarios a varios miles. Empresas
centralizadas u oficinas distribuidas, replicando cientos de sites.

Potencia: Microsoft SQL Server es la mejor base de datos para
Windows NT Server. Posee los mejores registros de los benchmarks
independientes (TCP) tanto en transacciones totales como en coste
por transacción.

Gestión: Con un completo interfaz gráfico que reduce la complejidad
innecesaria de las tareas de administración y gestión de la base de
datos.

Orientada al desarrollo: Visual Basic, Visual C++, Visual J++, Visual
Interdev, Microfocus Cobol y muchas otras herramientas son
compatibles con Microsoft SQL Server.
La mejor base de datos para Internet y Extranet.

Diseñada desde su inicio para trabajar en entornos Internet e
Intranet, Microsoft SQL Server es capaz de integrar los nuevos
desarrollos para estos entornos específicos con los desarrollos
heredados de aplicaciones "tradicionales". Es más, cada aplicación
que desarrollemos para ser empleada en entornos de red local
puede ser utilizada de forma transparente -en parte o en su
totalidad- desde entornos Internet, Intranet o Extranet.

Plataforma de desarrollo fácil y abierto: integrada con las mejores
tecnologías de Internet como ActiveX, ADC y Microsoft Transaction
Server y con las mejores herramientas de gestión y desarrollo para
Internet como FrontPage97, Microsoft Office97 y Visual Interdev.

Diseñada para INTERNET: Es el único gestor de base de datos que
contiene de forma integrada la posibilidad de generar contenido
HTML de forma automática.

La Base de Soluciones Integradas: La Integración total con
BackOffice permite resolver toda las necesidades de infraestructura
de la empresa con un sólo paquete.

Potente y Escalable: Microsoft SQL Server es la única base de datos
cuyo rendimiento sobre Internet está publicado, ofreciendo registros
espectaculares.

Mínimo coste de Propiedad: La sencillez de la instalación, y la
potencia de sus herramientas de gestión y el menor coste de toda la
industria para entornos Internet, hacen de Microsoft SQL Server la
mejor opción con el menor coste.
Arquitectura RDBMS.

Arquitectura de servidor simétrico y paralelo con balanceo
automático de carga en múltiples procesadores.

Kernel multithread real para mejor rendimiento transaccional y
escalabilidad.

Soporte grandes bases de datos (VLDB) (+1 TB).

Completo proceso transaccional interactivo con rollback automático y
recuperación de roll-forward.

Optimizador de consultas mejorado basado en coste.

Checkpointing mejorado para un mejor throughput de datos y tiempo
de respuesta.

Soporte E/S asíncrono para acceso en paralelo a múltiples
dispositivos de disco para un mejor throughput.

Bloqueo a nivel fija y página con escalación de bloqueos; resolución
automática de deadlocks.
Datos distribuidos y replicación.

Llamadas
a
procedimientos
remotos
servidor-a-servidor
(procedimientos almacenados remotos).

Replicación
asíncrona
o
contínua
basada
en
registros,
o
sincronización planificada de tablas point-in-time.

Configuración de replicación gráfica y características de gestión.

Replicación de subscriptores ODBC, incluyendo IBM DB2, ORACLE,
SYBASE y Microsoft Access.

Ei Distributed Transaction Coordinator gestiona transacciones que
involucran a dos o más servidores SQL (proceso Two Phase Commit
2PC) transparente.
Integración Internet y correo electrónico.

MAPI, permitiendo aplicaciones de flujo de trabajo y notificación de
cambio de datos automática.

Compatibilidad con Microsoft Internet Information Server y otros
servidores Web populares.

SQL Web Assistant, para el retorno automático de datos en formato
HTML.

Procedimientos almacenados para generar páginas HTML o
actualizar datos en plantillas Web.
Gestión y administración centralizada de bases de datos.

SQL Enterprise Manager, una consola de gestión y motorización 32bit visual basada en Windows.

Un único punto de configuración y gestión de control de datos
remotos.

SQL Executive, planificador de trabajos y monitor para gestión
proactiva de servidores distribuidos.

DBA Assistant, para el mantenimiento automático rutinario en una
única tarea planificada.

SQL Trace, para monitorizar consultas cliente-servidor mediante
SQL almacenadas en archivos de registros.
Disponibilidad, fiabilidad y tolerancia a fallos.

Mirroring de dispositivos de base de datos con failover automático
para tolerancia a fallos de dispositivos.

Copias
de
seguridad
online
desatendidas
garantizando
la
consistencia de datos para la más alta disponibilidad.

Contextos de usuario protegidos, que pueden aislar los fallos a un
thread de un único usuario.
Mejoras en Programabilidad y Lenguaje.

Triggers, procedimientos almacenados (autoexec), disparador de
eventos antes y después de conexiones.

Procedimientos almacenados extendidos (funciones definidas por el
usuario) utilizando C/C++.

Cursores basados en el motor con scrolling hacia adelante y atrás;
posicionamiento absoluto y relativo.

Sentencias DLL permitidas dentro de transacciones.
Seguridad.

Un único ID de login tanto para red como para la DB para mejorar la
seguridad y facilitar la administración.

Password y encriptación de datos en red para mejorar la seguridad.

Encriptación de procedimientos almacenados para la integridad y
seguridad de código de aplicación.

Interoperabilidad e integración con desktops.

API estándar DB-Library totalmente soportada: estándar ODBC Nivel
2 totalmente soportado como API nativa.

Gateway Open Data Services (ODS) programable para acceso
transparente a fuentes de datos externas.

Gateways de Microsoft y de terceros para fuentes de datos
relacionales y no-relacionales, incluyendo IBM DB2.
1.4.
ORACLE
Oracle es básicamente una herramienta cliente/servidor para la gestión
de base de datos, es un producto vendido a nivel mundial, aunque la
gran potencia que tiene y su elevado precio hace que solo se vea en
empresas muy grandes y multinacionales, por norma general.
En el desarrollo de páginas Web pasa lo mismo como es un sistema
muy caro no está tan extendido como otras bases de datos, por ejemplo,
Access, MySQL, SQL Server etc.
Oracle como antes lo mencionamos se basa en la tecnología cliente/
servidor, pues bien, para su utilización primero sería necesario la
instalación de la herramienta servidor ( Oracle 8i ) y posteriormente
podríamos atacar a la base de datos desde otros equipos con
herramientas de desarrollo como Oracle Designer y Oracle Developer,
que son las herramientas de programación sobre Oracle a partir de esta
premisa vamos a desarrollar las principales acepciones de Oracle y sus
aplicaciones en las distintas ares de trabajo.
El manejador de Base de datos ORACLE, surgió a final de los años 70 y
principio de los años 80. George Koch y su equipo de tropas de asalto
de técnicos fue el primero en desembarcar en el terreno de Oracle en
1982, durante un proceso de evaluación de sistema de gestión de base
de datos para una importante aplicación comercial que George estaba
diseñando y construyendo.
Cuando termino, la evaluación fue descrita en Computer World como el
estudio más severo de SGBD que se había hecho nunca. El estudio fue
tan riguroso con los vendedores cuyos productos había estudiado
George, que la prensa hizo eco de sus palabras en lugares tan distantes
como Nueva Zelandia y en publicaciones muy alejadas del campo como
el Christian Sciencia Monitor.
Oracle conocida entonces como Relational Software, tenía poco más de
25 empleados en aquel tiempo y solo unos pocos clientes importantes.
Sin embargo, cuando se completo el estudio, Oracle fue declarada
vencedora. George afirmo que el SGBD Oracle era técnicamente el
mejor producto del mercado. Estas declaraciones fueron hecha en una
época en la que muy poca gente conocía el significado del término
"Relacional", y los que lo conocían (o creían conocerlo) no tenían
muchas cosas favorables que decir de él.
Oracle es una herramienta cliente/servidor para la gestión de Bases de
Datos. Es un producto vendido a nivel mundial, aunque la gran potencia
que tiene y su elevado precio hacen que sólo se vea en empresas muy
grandes y multinacionales, por norma general. En el desarrollo de
páginas Web pasa lo mismo: como es un sistema muy caro no está tan
extendido como otras bases de datos, por ejemplo, Access, MySQL,
SQL Server, etc.
Vamos ahora en centrarnos en que es Oracle exactamente y cómo
funciona la programación sobre éste. Oracle como antes he mencionado
se basa en la tecnología cliente/servidor, pues bien, para su utilización
primero sería necesario la instalación de la herramienta servidor (Oracle
8i) y posteriormente podríamos atacar a la base de datos desde otros
equipos con herramientas de desarrollo como Oracle Designe y Oracle
Developer, que son las herramientas básicas de programación sobre
Oracle.
Para desarrollar en Oracle utilizamos PL/SQL un lenguaje de 5ª
generación, bastante potente para tratar y gestionar la base de datos,
también por norma general se suele utilizar SQL al crear un formulario.
El Developer es una herramienta que nos permite crear formularios en
local, es decir, mediante esta herramienta nosotros podemos crear
formularios, compilarlos y ejecutarlos, pero si queremos que los otros
trabajen sobre este formulario deberemos copiarlo regularmente en una
carpeta compartida para todos, de modo que, cuando quieran realizar un
cambio, deberán copiarlo de dicha carpeta y luego volverlo a subir a la
carpeta.
Este sistema como podemos observar es bastante engorroso y poco
fiable pues es bastante normal que las versiones se pierdan y se
machaquen con frecuencia. La principal ventaja de esta herramienta es
que es bastante intuitiva y dispone de un modo que nos permite
componer el formulario, tal y como lo haríamos en Visual Basic o en
Visual C, esto es muy de agradecer.
1.4.1. PROGRAMAS Y ARCHIVOS QUE COMPONE ORACLE
Un RDBMS Oracle está compuesto por tres partes principales, que son:
1. El Kernel de Oracle
2. Las instancias del Sistema de Base de Datos.
3. Los Archivos relacionados al sistema de Base de Datos.
EL KERNEL DE ORACLE
El Kernel es el corazón del RDBMS Oracle, el cual maneja las siguientes
tareas:

Manejar el almacenamiento y definición de los datos.

Suministrar y limitar el acceso a los datos y la concurrencia de los
usuarios.

Permitir los backup y la recuperación de los datos.

Interpretar el SQL y PL/SQL.
1.4.2. EL PGA (Programa Global Área)
Es también llamado Proceso Global Área, consta de datos e información
de control de los procesos, asegurando el uso correcto de estos. El PGA
contiene información acerca de las conexiones y los procesos que se
realizan en Oracle, su tamaño es variable en longitud, pero no es
dinámico. El PGA se activa al conectarse un usuario.
1.4.3. EL SGA (System Global Area)
Se puede llamar Shared global área. Se podría definir como una serie de
buffers en memoria residente, a través de la cual todas las transacciones
y el almacenamiento de dato fluyen. El SGA es localizado en memoria al
iniciarse una instancia y desaparece al bajarla. Su tamaño no puede ser
cambiado, pero si puede ser visto con el comando "SHOW SGA" en el
SQL*DBA. Su longitud está definida por el parámetro del archivo de
iniciación INIT.ORA.
Está Compuesto por:

Diccionario Cache

Los Redo Log Buffers

Los Database Buffers
1.4.4. DIFERENTES HERRAMIENTAS DE ORACLE
SQLForms: es la herramienta de Oracle que permite, de un modo
sencillo y eficiente, diseñar pantallas para el ingreso, modificaciones,
bajas y consultas de registros. El usuario podrá, una vez definida la
forma, trabajar con ella sin necesidad de generar códigos, dado que
Oracle trae incorporado un conjunto de procedimientos y funciones
asociados a las teclas de funciones, como por ejemplo la tecla [F7], que
se usa para iniciar una consulta.
La herramienta fundamental de SQL es la sentencia SELECT, que
permite seleccionar registros desde las tablas de la Base de Datos,
devolviendo aquellos que cumplan las condiciones establecidas y
pudiendo presentar el resultado en el orden deseado.
Para ver el gráfico seleccione la opción "Descargar" del menú superior
SQL
(Structured
Query
Languague
=
Lenguaje
de
Consulta
estructurado).
La orden FROM identifica la lista de tablas a consultar. Si alguna de las
tablas a consultar no es propiedad del usuario, debe especificarse el
nombre del propietario antes que el nombre de la tabla en la forma
nombre_propietario.nombre_tabla.
La orden WHERE decide los registros a seleccionar según las
condiciones establecidas, limitando el número de registros que se
muestran.
La orden ORDER BY indica el orden en que aparece el resultado de la
cónsul ta.
INDICES
El índice es un instrumento que aumenta la velocidad de respuesta de la
consulta, mejorando su rendimiento y optimizando su resultado. El
manejo de los índices en ORACLE se realiza de forma inteligente, donde
el programador sólo crea los índices sin tener que especificar,
explícitamente, cuál es el índice que va a usar.
Es el propio sistema, al analizar la condición de la consulta, quien decide
qué índice se necesita. Por ejemplo cuando en una consulta se
relacionan dos tablas por una columna, si ésta tiene definido un índice
se activa, como en el caso cuando relacionamos la tabla de clientes y
ventas por la columna código para identificar al cliente (WHERE
clientes.codigo=ventas.codigo)
USO DE MEMORIA
El uso de memoria en el RDBMS Oracle tiene como propósito lo
siguiente:

Almacenar los códigos de los programas para empezar a ejecutarse.

Almacenar los datos necesarios durante la ejecución de un
programa.

Almacenar información sobre como es la transferencia entre
procesos y periféricos.
Para ver el gráfico seleccione la opción ¨Descargar trabajo¨ del
menú superior
La identificación del índice a usar está relacionada con las columnas que
participan en las condiciones de la orden WHERE. Si la columna que
forma el índice está presente en alguna de las condiciones éste se
activa.
PL/SQL: es un lenguaje portable, procedural y de transacción muy
potente
y
de
fácil
manejo,
con
fundamentales:
1. Incluye todos los comandos de SQL.
las
siguientes
características
2. Es una extensión de SQL, ya que este es un lenguaje no completo
dado que no incluye las herramientas clásicas de programación. Por
eso, PL/SQL amplia sus posibilidades al incorporar las siguientes
sentencias:
- Control condicional
- Ciclos
3. Incorpora opciones avanzadas en:
- Control y tratamiento de errores llamado excepciones.
- Manejo de cursores.
1.4.5. ESTRUCTURA DEL BLOQUE DE CÓDIGO
La organización del bloque de código de PL/SQL, compuesto por cuatro
secciones DECLARE, BEGIN, EXCEPTION y END.
MANEJO DE CURSORES
El conjunto de filas resultantes de una consulta con la sentencia
SELECT, como vimos anteriormente, puede estar compuesto por
ninguna, una o varias filas, dependiendo de la condición que define la
consulta. Para poder procesar individualmente cada fila de la consulta
debemos definir un cursor (que es un área de trabajo de memoria) que
contiene los datos de las filas de la tabla consultada por la sentencia
SELECT.
Para ver el gráfico seleccione la opción "Descargar" del menú superior
Los pasos para el manejo de cursores, tema novedoso en la
programación de Oracle con PL/SQL, son:

Definir el cursor, especificando la lista de parámetros con sus
correspondientes tipos de datos y estableciendo la consulta a
realizar con la sentencia SELECT.

Abrir el cursor para inicializarlo, siendo éste el momento en que se
realiza la consulta.

Leer una fila del cursor, pasando sus datos a las variables locales
definidas a tal efecto.
1.4.6. DISPARADORES
El
módulo
SQL*Forms
tiene
incorporado
una
colección
de
procedimientos y funciones llamados "empaquetados" que se pueden
incluir en el código de procedimientos o disparadores definidos por el
usuario.
El disparador es un bloque de código que se activa cuando se pulsa una
determinada tecla u ocurre cierto evento, como puede ser:

Mover el cursor hacia o desde un campo, registro, bloque o forma.

Realizar una consulta.

Validar un dato.

Hacer una transacción al insertar, modificar o eliminar registros de la
base de datos.
Oracle asocia a cada tecla de función un procedimiento empaquetado,
pudiendo el usuario redefinir esta asignación o capturar el disparador
para ampliarlo o modificarlo con su propio código.
A partir de la versión 7 de Oracle el usuario puede almacenar, en forma
independiente, sus funciones y procedimientos sin tener que escribirlos
repetidamente
para
cada
forma,
y
pudiendo
compilarlos
independientemente de las formas que lo usen. Pero, además, las
funciones y procedimientos se pueden agrupar en un paquete para
compartir definiciones, variables globales, constantes, cursores y
excepciones, así como garantizar y revocar los permisos a nivel de
paquete.
En el caso que sea necesario modificar el contenido del paquete, como
el mismo se encuentra almacenado separadamente, no es necesario
recompilar nada que use ese paquete, lo que facilita la gestión y
mantenimiento de todos los procedimientos almacenados como una sola
entidad para una determinada aplicación.
1.4.7. SERVICIOS DE SEGURIDAD
Existen varios servicios y tecnologías relacionadas con la seguridad.
Accede a cada una de ellas para conocer qué tecnologías son las más
interesantes:
Autenticación: Se examinan las capacidades de logon único a la red,
autenticación y seguridad. Además, se proporciona información sobre el
interfaz Security Support Provider Interface (SSPI) para obtener servicios
de seguridad integrados del sistema operativo. Kerberos es el protocolo
por defecto en Windows 2000 para autenticación en red.
Sistema de Archivos Encriptado: El Sistema de Archivos Encriptado
(Encrypted File System - EFS) proporciona la tecnología principal de
encriptación de archivos para almacenar archivos del sistema de
archivos NTFS de Windows NT encriptados en disco.
Seguridad IP: Windows IP Security, del Internet Engineering Task
Force, proporciona a los administradores de redes un elemento
estratégico de defensa para la protección de sus redes.
Servicios de seguridad en Windows 2000: se examinan los
procedimientos relacionados con la gestión de cuentas, autenticación de
red a nivel corporativo, así como el Editor de Políticas de Seguridad.
Tarjetas Inteligentes: se examinan los procesos de autenticación
utilizando
tarjetas
inteligentes
y
los
protocolos,
servicios
y
especificaciones asociadas.
Tecnologías de Clave Pública: se revisa la infraestructura de clave
pública incluida en los sistemas operativos de Microsoft y se proporciona
información sobre criptografía.
Un SMBD cuenta con un subsistema de seguridad y autorización que se
encarga de garantizar la seguridad de porciones de la BD contra el
acceso no autorizado.

Identificar y autorizar a los usuarios: uso de códigos de acceso y
palabras claves, exámenes, impresiones digitales, reconocimiento
de voz, barrido de la retina, etc.

Autorización: usar derechos de acceso dados por el terminal, por la
operación que puede realizar o por la hora del día.

Uso de técnicas de cifrado: para proteger datos en BD distribuidas o
con acceso por red o internet.

Diferentes tipos de cuentas: en especial la del ABD con permisos
para: creación de cuentas, concesión y revocación de privilegios y
asignación de los niveles de seguridad.
Discrecional: se usa para otorgar y revocar privilegios a los usuarios a
nivel de archivos, registros o campos en un modo determinado (consulta
o modificación).
El ABD asigna el propietario de un esquema, quien puede otorgar o
revocar privilegios a otros usuarios en la forma de consulta (select),
modificación o referencias. A través del uso de la instrucción grant option
se pueden propagar los privilegios en forma horizontal o vertical.
Ejemplo: grant select on Empleado to códigoUsuario
revoke select on Empleado from códigoUsuario.
Obligatoria: sirve para imponer seguridad de varios niveles tanto para
los usuarios como para los datos.
Problemas de seguridad.
La información de toda empresa es importante, aunque unos datos lo
son más que otros, por tal motivo se debe considerar el control de
acceso a los mismos, no todos los usuarios pueden visualizar alguna
información, por tal motivo para que un sistema de base de datos sea
confiable debe mantener un grado de seguridad que garantice la
autenticación y protección de los datos. En un banco por ejemplo, el
personal de nóminas sólo necesita ver la parte de la base de datos que
tiene información acerca de los distintos empleados del banco y no a
otro tipo de información.
Identificación y autentificación
En un SGBD existen diversos elementos que ayudan a controlar el
acceso a los datos.
En primer lugar el sistema debe identificar y autentificar a los usuarios
utilizando alguno de las siguientes formas:

Código y contraseña

Identificación por hardware

Características bioantropométricas

Conocimiento, aptitudes y hábitos del usuario

Información predefinida (Aficiones, cultura, etc)
Además, el administrador deberá especificar los privilegios que un
usuario

tiene sobre los objetos:
Usar una B.D.

Consultar ciertos datos

Actualizar datos

Crear o actualizar objetos

Ejecutar procedimientos almacenados

Referenciar objetos

Indexar objetos

Crear identificadores
Mecanismos de autentificación
La autentificación, que consiste en identificar a los usuarios que entran al
sistema, se puede basar en posesión (llave o tarjeta), conocimiento
(clave) o en un atributo del usuario (huella digital).
Claves
El mecanismo de autentificación más ampliamente usado se basa en el
uso de claves o passwords; es fácil de entender y fácil de implementar.
En UNIX, existe un archivo /etc/passwd donde se guarda los nombres de
usuarios y sus claves, cifradas mediante una función one-way F. El
programa login pide nombre y clave, computa F(clave), y busca el par
(nombre, F(clave)) en el archivo.
Con claves de 7 caracteres tomados al azar de entre los 95 caracteres
ASCII que se pueden digitar con cualquier teclado, entonces las 957
posibles claves deberían desincentivar cualquier intento por adivinarla.
Sin embargo, una proporción demasiado grande de las claves escogidas
por los usuarios son fáciles de adivinar, pues la idea es que sean
también fáciles de recordar.
La clave también se puede descubrir
mirando (o filmando) cuando el usuario la digita, o si el usuario hace
login remoto, interviniendo la red y observando todos los paquetes que
pasan por ella. Por último, además de que las claves se pueden
descubrir, éstas también se pueden "compartir", violando las reglas de
seguridad.
En definitiva, el sistema no tiene ninguna garantía de que quien hizo
login es realmente el usuario que se supone que es.
Identificación física
Un enfoque diferente es usar un elemento físico difícil de copiar,
típicamente
una
tarjeta con una banda magnética. Para mayor
seguridad este enfoque se suele combinar con una clave (como es el
caso
de
los
cajeros
automáticos).
Otra
posibilidad
es
medir
características físicas particulares del sujeto: huella digital, patrón de
vasos sanguíneos de la retina, longitud de los dedos. Incluso la firma
sirve.
Algunas medidas básicas:

Demorar la respuesta ante claves erróneas; aumentar la demora
cada vez. Alertar si hay demasiados intentos.

Registrar todas las entradas. Cada vez que un usuario entra,
chequear cuándo y desde dónde entró la vez anterior.

Hacer chequeos periódicos de claves fáciles de adivinar, procesos
que llevan demasiado tiempo corriendo, permisos erróneos,
actividades extrañas (por ejemplo
cuando
usuario
está de
vacaciones).
Un SMBD cuenta con un subsistema de seguridad y autorización que se
encarga de garantizar la seguridad de porciones de la BD contra el
acceso no autorizado.
Identificar y autorizar a los usuarios: uso de códigos de acceso y
palabras claves, exámenes, impresiones digitales, reconocimiento de
voz, barrido de la retina, etc.
Autorización: usar derechos de acceso dados por el terminal, por la
operación que puede realizar o por la hora del día.
Uso de técnicas de cifrado: para proteger datos en BD distribuidas o con
acceso por red o internet.
Diferentes tipos de cuentas: en especial la del ABD con permisos para:
creación de cuentas, concesión y revocación de privilegios y asignación
de los niveles de seguridad.
Manejo de la tabla de usuarios con código y contraseña, control de las
operaciones efectuadas en cada sesión de trabajo por cada usuario y
anotadas en la bitácora, lo cual facilita la auditoría de la BD.
Confidencialidad:
No mostrar datos a usuarios no autorizados.
Accesibilidad:
Que la información se encuentre disponible.
Integridad:
Permite asegurar que los datos no se han falseado.
Administrador de la base de datos
El alcance de la actividad de la Administración de Datos es la
organización completa (empresa, institución u otro organismo), mientras
que el alcance de la Administración de Bases de Datos queda restringido
a una Base de Datos en particular y a los sistemas que los procesan. La
Administración de la Base de Datos opera dentro de un marco
proporcionado por la Administración de Datos facilitándose de esta
manera el desarrollo y el uso de una Base de Datos y sus aplicaciones.
Las siglas DBA suelen utilizarse para designar tanto la función
Administración de Base de Datos como al título del puesto administrador
de Base de Datos.
En los distintos niveles y aplicaciones de Base de Datos existe la función
DBA, aunque varia en complejidad. Esta es más sencilla cuando se trata
de una Base de Datos Personal que cuando se refiere a una Base de
Datos de grupos de trabajo, y esta a su vez es más sencilla que en una
Base de Datos Organizacional. En una Base de Datos Personal
comúnmente el mismo usuario es el Administrador de la Base de Datos;
las Bases de Datos de grupos de trabajo requieren de una o dos
personas que normalmente no se dedican a esta función de tiempo
completo puesto que tienen otras responsabilidades dentro o fuera de la
organización.
En
las
Bases
de
Datos
Organizacionales,
que
comúnmente permiten el acceso a decenas e incluso centenas de
usuarios, se requiere de un administrador de Base de Datos de tiempo
completo; lo anterior debido al alto volumen de procesos que deben
desarrollarse, controlarse y supervisarse.
Un Administrador de Base de Datos de tiempo completo normalmente
tiene aptitudes técnicas para el manejo del sistema en cuestión a demás,
son cualidades deseables nociones de administración, manejo de
personal e incluso un cierto grado de diplomacia. La característica más
importante que debe poseer es un conocimiento profundo de las
políticas y normas de la empresa así como el criterio de la empresa para
aplicarlas
en
un
momento
dado.
La responsabilidad general del DBA es facilitar el desarrollo y el uso de
la Base de Datos dentro de las guías de acción definidas por la
administración de los datos.
El DBA es responsable primordialmente de:

Administrar la estructura de la Base de Datos

Administrar la actividad de los datos

Administrar el Sistema Manejador de Base de Datos

Establecer el Diccionario de Datos

Asegurar la confiabilidad de la Base de Datos

Confirmar la seguridad de la Base de Datos.
1.4.8. ADMINISTRACIÓN DE LA ESTRUCTURA DE LA BASE DE DATOS
La administración de la estructura de la Base de Datos incluye participar
en el diseño inicial de la misma y su puesta en práctica así como
controlar, y administrar sus requerimientos, ayudando a evaluar
alternativas, incluyendo los DBMS a utilizar y ayudando en el diseño
general de BD. En los casos de grandes aplicaciones de tipo
organizacional, el DBA es un gerente que supervisa el trabajo del
personal de diseño de la BD.
Una vez diseñada la BD, es puesta en práctica utilizando productos del
DBMS, procediéndose entonces a la creación de los datos (captura
inicial). El DBA participa en el desarrollo de procedimientos y controles
para asegurar la calidad y la alta integridad de la BD.
Los requerimientos de los usuarios van modificándose, estos encuentran
nuevas formas o métodos para lograr sus objetivos; la tecnología de la
BD se va modificando y los fabricantes del DBMS actualizan sus
productos. Todas las modificaciones en las estructuras o procedimientos
de BD requieren de una cuidadosa administración.
IMPLICACIONES POR LA MODIFICACION DE ESQUEMAS.
Las solicitudes de modificación son inevitables una vez que el sistema
ha entrado en operación, pueden aparecer solicitudes de nuevos
requerimientos o estos pueden resultar de una comprensión inadecuada
de los mismos. En cualquier caso, deberán efectuarse modificaciones en
relación con toda la comunidad de la BD, ya que el impacto de tales
alteraciones será resentido por más de una aplicación. En algunos
casos, pueden darse modificaciones que presentan efectos negativos
para algunos usuarios; estos casos deberán ser tratados esgrimiendo
como argumento los beneficios globales que serán obtenidos de tales
alteraciones.
Una administración eficaz de la BD debe incluir procedimientos y
políticas mediante las cuales los usuarios puedan registrar sus
necesidades de modificaciones, y así la comunidad podrá analizar y
discutir los
impactos de dichas modificaciones,
determinándose
entonces la puesta o no en práctica de tales alteraciones.
En razón del tamaño y complejidad de una BD y de sus aplicaciones, las
modificaciones pudieran tener resultados inesperados. El DBA debe
estar preparado para reparar la BD y reunir suficiente información para
diagnosticar y corregir el problema provocado por la falla. Después de un
cambio la BD es más vulnerable a fallas.
DOCUMENTACIÓN
La responsabilidad final de un DBA en la administración de la estructura
de una BD es la DOCUMENTACIÓN. Es de suma importancia saber que
modificaciones han sido efectuadas, como fueron realizadas y cuando
fueron establecidas. Una modificación sobre la estructura de la BD
pudiera ocasionar un error que no apareciera a corto plazo; una vez que
este surja, sin la documentación adecuada sobre las modificaciones
realizadas, él diagnostico resultaría extremadamente complicado. En
estos casos, se haría necesaria una secuencia de ejecuciones para
intentar detectar el punto en conflicto; el riesgo de este procedimiento
radica en que es posible afectar la información contenida en la BD. Para
identificar un cambio es de suma importancia mantener un registro de
los formatos de prueba y de las ejecuciones de las pruebas efectuadas.
Si se utilizan procedimientos de prueba formatos de pruebas y métodos
de registro estandarizados, el registro de los resultados de la prueba no
consumirá
tiempo
excesivo.
Comúnmente el tiempo de la documentación es tedioso y esto ocasiona
que algunos DBA tienden a reducir o abreviar la información que se
registra en ella e incluso llegan a desatenderla. Cuando ocurre un
siniestro, la documentación completa y organizada puede ser la
diferencia entre resolver o no un problema de extrema importancia y en
la mayoría de los casos, que implica costos cuantiosos a la empresa.
La tarea de la documentación es cada vez más ligera y precisa cuando
se utilizan DBMS que integran herramientas CASE para las tareas de
diseño, mantenimiento y documentación. Estas mismas herramientas
CASE proporcionan en la, mayoría de los casos la facilidad de generar y
mantener en forma automática el Diccionario de Datos.
ADMINISTRACIÓN DE LA ACTIVIDAD DE DATOS
Aunque el DBA protege los datos, no los procesa. El DBA no es usuario
del sistema, en consecuencia, no administra valores de datos; el DBA
administra actividad de datos. Dado que la BD es un recurso compartido,
el DBA debe proporcionar estándares, guías de acción, procedimientos
de control y la documentación necesaria para garantizar que los usuarios
trabajan en forma cooperativa y complementaria al procesar datos en la
BD.
Como es de suponerse, existe una gran actividad al interior de un
DBMS. La concurrencia de múltiples usuarios requieren de estandarizar
los procesos de operación; el DBA es responsable de tales
especificaciones y de asegurarse que estas lleguen a quienes concierne.
Todo el ámbito de la BD se rige por estándares, desde la forma como se
capture la información (tipo, longitud, formato), como es procesada y
presentada. El nivel de estandarización alcanza hasta los aspectos más
internos de la BD; como sé accesa a un archivo, como se determinan los
índices primarios y auxiliares, la foliación de los registros y demás.
Debe procurarse siempre que los estándares que serán aplicados
beneficien también a los usuarios, privilegiando siempre la optimización
en la operación del DBMS y el apego de las políticas de la empresa.
Una administración de BD efectiva deberá disponer siempre de este tipo
de estándares; entre las funciones del DBA se encuentra la de revisarlos
periódicamente para determinar su operatividad, y en su caso ajustarlos,
ampliarlos o cancelarlos. Es también su responsabilidad el que estos se
cumplan.
Cuando se definen estándares sobre la estructura de la BD, estos deben
registrarse en una sección del diccionario de datos a la que todos
aquellos usuarios relacionados con ese tipo de proceso pueden acceder.
Otro de los aspectos que el administrador debe atender es el de
coordinar las nuevas propuestas para realizar ajustes en los derechos de
acceso a datos compartidos y aplicaciones específicamente propuestas
serían analizados en conjunto con los supervisores o directivos de las
áreas involucradas para determinar si procede pudieran aparecer
problemas cuando dos o más grupos de usuarios quedan autorizados
para notificar los mismos datos. Uno de tales conflictos es el de la
actualización perdida; este ocurre cuando el trabajo de un usuario queda
sobrescrito sobre por el de un segundo usuario. El DBA queda
responsabilizado para identificar la posible ocurrencia de dichos
problemas así como de crear normas y procedimientos para su
eliminación. Se obtendrán este tipo de garantías cuando el DBMS sea
capaz de implementar las restricciones aplicables al acceso concurrente,
y este sea utilizado adecuadamente por programadores y usuarios; para
borrar lo anterior, se hace indispensable el apego a los estándares el
seguimiento de instructivos y manuales y las reglas establecidas para los
diversos procesamientos y procedimientos que se llevan a cabo.
Entre las alternativas más utilizadas por el DBA para tratar de resolver o
minimizar este problema se encuentran las siguientes:
a) Restringir el acceso a los procedimientos para ciertos usuarios.
b) Restringir al acceso a los datos para ciertos usuarios
procedimientos y/o datos.
c) Evitar la coincidencia de horarios para usuarios que comparten.
Las técnicas de recuperación son otra función esencial del DBA al
administrar la actividad de datos. A pesar de que el DBMS lleva a
cabo una parte del proceso de recuperación, los usuarios
determinan en forma critica la operatividad de esos sistemas de
protección. El DBA debe anticipar fallas y definir procedimientos
estándares de operación; los usuarios deben saber qué hacer
cuando el sistema este caído y que es lo primero que debe
realizarse cuando el sistema este puesto en marcha nuevamente.
El personal de operación deberá saber cómo iniciar el proceso de
recuperación de la BD que copias de seguridad utilizar; como
programar la ejecución del tiempo perdido y de las tareas
pendientes; es importante también establecer un calendario para
llevar a cabo estas actividades sin afectar a otros sistemas dentro
de la organización que hagan uso de los mismos recursos de
computo. Destacan por su importancia en el proceso de
recuperación y a su vez en la atención que prestan a otros
sectores de la organización. Los dispositivos de comunicación
remota, los sistemas de interconexión y otros accesorios de uso
compartido.
El DBA es el responsable de la publicación y mantenimiento de la
documentación en relación con la actividad de los datos,
incluyendo los estándares de la BD, los derechos de recuperación
y de acceso a la BD, los estándares para la recuperación de
caídas y el cumplimiento de las políticas establecidas. Los
productos DBMS más populares que se encuentran en el
mercado proporcionan servicios de utilerías para ayudar al DBA
en la administración de los datos y su actividad. Algunos sistemas
registran en forma automática los nombres de los usuarios y de
las aplicaciones a las que tienen acceso así como a otros objetos
de la BD. Incorpora también utilerías que permitan definir en el
diccionario de datos las restricciones para que determinadas
aplicaciones o módulos de ellas solo tengan acceso a segmentos
específicos de la BD.
1.4.9. FUNCIONES
DEL
ADMINISTRADOR
DE
BASES
DE
DATOS
(DATE)
DEFINIR EL ESQUEMA CONCEPTUAL: Es tarea del administrador de
datos decidir con exactitud cuál es la información que debe mantenerse
en la base de datos, es decir, identificar las entidades que interesan a la
empresa y la información que debe registrarse acerca de esas
entidades. Este proceso por lo general se denomina diseño lógico a
veces conceptual de bases de datos. Cuando el administrador de datos
decide el contenido de la base de datos en un nivel abstracto, el DBA
crea a continuación el esquema conceptual correspondiente, empleando
el DDL conceptual. El DBMS utilizará la versión objeto (compilada) de
ese esquema para responder a las solicitudes de acceso. La versión
fuente sin compilar servirá como documento de referencia para los
usuarios
del
sistema.
DEFINIR EL ESQUEMA INTERNO: el DBA debe decidir también como
se representará la información en la base de datos almacenada. A este
proceso suele llamársele diseño físico de la base de datos. Una vez
hecho esto el DBA deberá crear la definición de estructura de
almacenamiento
correspondiente
(es
decir
el
esquema
interno)
valiéndose del DDL interno. Además deberá definir la correspondencia
pertinente entre los esquemas interno y conceptual. En la práctica, ya
sea el DDL conceptual o bien el DDL interno incluirán seguramente los
medios para definir dicha correspondencia, pero las dos funciones (crear
el esquema, definir la correspondencia) deberán poder separarse con
nitidez. Al igual que el esquema conceptual, el esquema interno y la
correspondencia asociada existirán tanto en la versión fuente como en la
versión objeto.
VINCULARSE CON LOS USUARIOS: el DBA debe encargarse de la
comunicación con los usuarios, garantizar la disponibilidad de los datos
que requieren y escribir o ayudar a los usuarios a escribir- los esquemas
externos necesarios, empleando el DDL externo aplicable. Además, será
preciso definir la correspondencia entre cualquier esquema externo y el
esquema conceptual. En la práctica, el DDL externo incluirá con toda
probabilidad los medios para especificar dicha correspondencia, pero en
este caso también el esquema y la correspondencia deberán poder
separarse con claridad. Cada esquema externo y la correspondencia
asociada existirán en ambas versiones fuentes y objeto. Otros aspectos
de la función de enlace con los usuarios incluyen las consultas sobre
diseño de aplicaciones, la impetración de instrucción técnica, la ayuda
en la localización y resolución de problemas, y otros servicios
profesionales similares relacionados con el sistema.
DEFINIR LAS VERIFICACIONES DE SEGURIDAD E INTEGRIDAD: las
verificaciones de seguridad y de integridad pueden considerarse parte
del esquema conceptual. El DDL conceptual incluirá los medios para
especificar dichas verificaciones.
DEFINIR PROCEDIMIENTOS DE RESPALDO Y RECUPERACION:
cuando una empresa se decide a utilizar un sistema de base de datos,
se vuelve dependiente en grado sumo del funcionamiento correcto de
ese sistema. En caso de que sufra daño cualquier porción de la base de
datos por causa de un error humano, digamos, o una falla en el equipo o
en el sistema que lo apoya resulta esencial poder reparar los datos
implicados con un mínimo de retraso y afectando lo menos posible el
resto del sistema. En teoría, por ejemplo la disponibilidad de los datos no
dañados no debería verse afectada. El DBA debe definir y poner en
práctica un plan de recuperación adecuada que incluya, por ejemplo una
descarga o "vaciado" periódico de la base de datos en un medio de
almacenamiento de respaldo, y procedimientos para cargar otra vez la
base de datos a partir de vaciado más reciente cuando sea necesario.
SUPERVISAR EL DESEMPEÑO Y RESPONDER A CAMBIOS EN LOS
REQUERIMIENTOS: es responsabilidad del DBA organizar el sistema
de modo que se obtenga el desempeño que sea "mejor para la
empresa", y realizar los ajustes apropiados cuando cambien los
requerimientos.
FUNCIONES
DEL
ADMINISTRADOR
DE
BASE
DE
DATOS
(KORTH)
DEFINICIÓN DEL ESQUEMA: el esquema original de la base de datos
se crea escribiendo un conjunto de definiciones que son traducidas por
el compilador de DDL a un conjunto de tablas que son almacenadas
permanentemente en el DICCIONARIO DE DATOS.
DEFINICIÓN DE LA ESTRUCTURA DE ALMACENAMIENTO Y DEL
MÉTODO DE ACCESO: Estructuras de almacenamiento y métodos de
acceso adecuados se crean escribiendo un conjunto de definiciones que
son traducidas por el compilador del lenguaje de almacenamiento y
definición de datos.
MODIFICACIÓN DEL ESQUEMA Y DE LA ORGANIZACIÓN FÍSICA:
las modificaciones, tanto al esquema de la base de datos como a la
descripción de la organización física de almacenamiento, aunque
relativamente poco comunes, se logran escribiendo un conjunto de
definiciones que son usadas bien por el compilador del DDL o bien por el
compilador del lenguaje de almacenamiento y definición de datos para
generar modificaciones a las tablas internas apropiadas del sistema (por
ejemplo, el diccionario de datos).
CONCESIÓN DE AUTORIZACIÓN PARA EL ACCESO A LOS DATOS:
la concesión de diferentes tipos de autorización permite al administrador
de la base de datos regular qué partes de la base de datos van a poder
ser accedidas por varios usuarios.
ESPECIFICACIÓN DE LAS RESTRICCIONES DE INTEGRIDAD: las
restricciones de integridad se mantienen en una estructura especial del
sistema que consulta el gestor de la base de datos cada vez que tiene
lugar una actualización en el sistema.
1.4.10.USUARIOS DE LA BASE DE DATOS
Programadores de aplicaciones: No es difícil de describir a este
usuario, es aquel que realiza aplicaciones para otros usuarios,
generalmente profesionales de la computación.
Usuarios sin experiencia: son usuarios complejos que interactúan con
el sistema sin escribir programas. (Mantenimiento, tanto de base de
datos, regeneración, índices, auditores).
Capítulo 2. Tecnologías Disponibles para la Comunicación con Fuentes
de Datos Heterogéneas
Uno de los aspectos más importantes en un sistema multibase de datos es la
forma en cómo llevar a cabo la comunicación con la base de datos
componentes. En este capítulo se describen tecnologías actuales que permiten
la comunicación con fuentes de datos heterogéneas, y sus características
principales. Se describe más detalladamente la tecnología JDBC, debido a que
es la que se utilizo en el desarrollo del prototipo.
Internet ha sido en los últimos años uno de los principales medios de difusión
de información. Debido a su popularidad cada vez más software se ha
desarrollado tomando a Internet como punto de partida. Entre estos desarrollos
se encuentra una gran variedad de herramientas enfocadas a la recuperación
de información desde diversas fuentes, incluyendo base de datos relacionales y
de objetos, así como archivos planos, archivos de texto, documentos de
procesadores de palabras y páginas web.
2.1 Compuertas para Bases de Datos
Las compuertas, desde una perspectiva de base de datos, permiten la
interoperabilidad de bases de datos, habilitando aplicaciones cliente para
conectarse a múltiples fuentes de datos. Las compuertas para base de
datos son un tipo especial de middleware (software de enlace) que da a
las aplicaciones cliente una interfaz de programación de aplicación (API)
que hace que diversas fuentes de datos parezcan equivalentes.
Una compuerta de base de datos consiste de:
1.
Una biblioteca API cliente: La API del lado del cliente, la cual
determina el formato y significado de las peticiones que las
aplicaciones cliente pueden emitir.
2.
Una biblioteca API Servidor: La API en la base de datos del lado del
servidor, la cual determina los servicios de bases de datos
disponibles para los clientes.
2.2 Monitores de Procesamiento de Transacciones
Los monitoreos de procesamiento de transacciones (MPT) nacieron para
mejorar procesos y orquestar programas. Esto lo hace al romper
aplicaciones complejas en piezas de código llamadas transacciones. Los
MPT’s fueron introducidos para ejecutar clases de aplicaciones que
podrían servir a miles de clientes y servidores. Al hacer esta intercalación
entre clientes y servidores los MPT’s pueden manejar transacciones,
rutearlas a través del sistema, balancear la carga de su ejecución y
reiniciarlas después de una falla. Un MPT puede manejar recursos
transaccionales en un servidor o a través de múltiples servidores, y puede
cooperar con otros MPT’s en arreglos federados.
En el contexto de sistemas distribuidos un MPT provee un número de
funciones útiles, incluyendo multiprocesamiento automático, seguridad y
servicios de nombramiento global y resolución de nombres. Un MPT
también provee acceso síncrono o asíncrono a fuentes de datos, soporta
un gran número de usuarios, y facilita la integración de numerosos
ambientes y componentes heterogéneos.
2.3 Conectividad de Base de Datos Abierta (ODBC)
ODBC es una API abierta para acceder a bases de datos. La API
especifica un conjunto de funciones para manejar conexiones a bases de
datos, ejecutar declaraciones SQL (lenguaje de consultas estructurado) y
consultar las capacidades del sistema de base de datos. ODBC está
basado en la especificación de la interfaz a nivel de llamadas de X/Open
SQL. Microsoft desarrollo ODBC como una implementación de la
especificación de la interfaz a nivel de llamadas para proveer una API
común para la conectividad de base de datos.
ODBC provee una interfaz estándar que permite a las aplicaciones
accesar a diferentes fuentes de datos. El código fuente de las
aplicaciones no tiene que ser recompilado para cada fuente de datos. Un
controlador de base de datos conecta a la aplicación a una fuente de
datos específica. Un controlador de base de datos es una librería de
cargado dinámico que una aplicación puede invocar en demanda de
acceso a un origen de datos particular. Por lo tanto la interfaz ODBC
define lo siguiente:
 Una librería que llama a funciones ODBC que permite a una aplicación
conectarse a una fuente de datos, ejecutar sentencias SQL, y
recuperar resultados.
 Una sintaxis SQL basada en el X/Open y el Grupo de Acceso SQL
(SAG) especificación SQL CASE.
 Un conjunto estándar de códigos de error.
 Una forma estándar para conectarse y registrarse en una fuente de
datos.
 Una representación estándar de los tipos de datos.
2.4 Conectividad de bases de datos java (JDBC)
JDBC es una API a nivel de SQL de aplicaciones Java para sistemas de
bases de datos SQL. La API JDBC define clases Java pare representar
conexiones a base de datos, declaraciones SQL, conjunto de resultados,
acceso a metadatos y más. La API JDBC puede soportar múltiples
controladores que están conectados a diferentes SMBDs. JDBC provee
una interfaz a nivel de programación para la comunicación con base de
datos de una manera uniforme similar al concepto de ODBC de Microsoft,
el cual ha llegado a ser un estándar para accesar SMBDs. El estándar
JDBC está basado en la interfaz a nivel de llamadas X/Open SQL, la
misma base de ODBC.
La API de JDBC, define una interfaz estructurada para bases de datos, la
cual es el estándar de la industria para accesarlas. Al soportar SQL,
JDBC permite a los programadores interactuar y soportar una gran
cantidad de bases de datos. Esto significa que las características
especificas de la plataforma de la base de datos se vuelven irrelevantes
cuando se accesan desde JDBC, así como la heterogeneidad de las
bases de datos al poder accesarlas desde un estándar como DQL.
¿Qué es JDBC?
JDBC es la herramienta de conectividad de base de datos para Java.
JDBC abarca varias cosas dependiendo del contexto:

JDBC es una especificación para usar fuentes de datos en applets y
aplicaciones Java.

JDBC es una API para usar controladores JDBC.

JDBC es una API para crear los controladores JDBC, los cuales
realizan la conectividad y transacciones con las fuentes de datos.

JDBC está basado en la interface a nivel de llamadas SQL X/Open
la cual define como las interacciones cliente/servidor deben ser
implementadas para sistemas de bases de datos.
JDBC define cada aspecto para manipular bases de datos desde applets
y aplicaciones Java. Los controladores JDBC ejecutan la traducción
específica de la base de datos a la interface.
JDBC. Esta interface es utilizada por el desarrollador y asi el no necesita
preocuparse por la sintaxis especifica de la base de datos cuando se
conecta y consulta diferentes bases de datos. El aspecto excitante de
JDBC es que los controladores necesarios para la conexión a sus
respectivas bases de datos no requieren alguna preinstalación en los
clientes. Un controlador JDBC puede ser descargado en el cliente junto
con el applet.
JDBC está ampliamente basado en el estándar ANSI SQL – 92. Esto no
significa que un controlador JDBC tiene que ser escrito para base de
datos SQL- 92, un controlador JDBC puede ser escrito para cualquier
sistema de base de datos y funcionara perfectamente. Aunque el
controlador no implemente cada función SQL – 92, este aun seguirá
siendo un controlador JDBC. Este es uno de los aspectos más
importantes de JDBC ya que de esta manera permite la recuperación de
información desde fuentes de datos heterogéneas.
JDBC cubre ODBC
Los diseñadores de JDBC emplearon una filosofía de diseño que cubrirá
los conceptos de ODBC (conectividad de base de datos abierta). Las dos
principales razones para modelar JDBC como ODBC son:

ODBC es ampliamente utilizado, lo cual ayudaría a que los usuarios
lo aprendieran rápidamente.

Hay implementaciones ODBC eficientes en todas las plataformas
para casi todas las bases de datos.
Los productos JDBC disponibles se clasifican en dos categorías aquellos
que comunican a un controlador ODBC existente y los que comunican a
una API de una base de datos nativa. javasoft desarrollo lo que se conoce
como el puente JDBC – ODBC para tomar ventaja de un gran número de
fuentes de datos habilitadas como ODBC. La ventaja primaria de usar el
puente JDBC – ODBC es que las llamadas JDBC son finalmente
convertidas en llamadas ODBC, así las aplicaciones pueden fácilmente
accesar bases de datos de múltiples vendedores al seleccionar el
controlador ODBC apropiado. Sin embargo el puente JDBC – ODBC
requiere preinstalación en el cliente donde requiera que el programa Java
se ejecute, debido a que el puente debe hacer llamadas a métodos
nativos para hacer la traducción de ODBC a JDBC. Solamente los
controladores JDBC 100% Java pueden ser descargados desde la red
junto con el applet, y estos no requieren preinstalación del controlador.
Un aspecto importante de JDBC es que el diseño estándar de la interface
JDBC permite cambiar entre los controladores y por tanto las bases de
datos son recodificar los programas. Java. JDBC, por tanto, emerge para
dar
solución
al
problema
de
la
neutralidad
de
plataformas
y
heterogeneidad de fuentes de datos.
2.5. OLE DB
OLE DB es un conjunto de interfaces desarrolladas por Microsoft cuya
meta es habilitar aplicaciones para tener un acceso uniforme a datos
almacenados en diversas fuentes de información de SMBDs (sistemas
manejadores de base de datos) y No-SMBDs. Las fuentes SMBDs
pueden incluir bases de datos mainframe, los servidores de base de
datos, o repositorios de datos de escritorio. Fuentes No-SMBDs pueden
incluir información almacenada en sistemas de archivos, archivos
secuenciales
indexados,
correo
electrónico,
hojas
de
cálculo,
herramientas de manejo de proyectos y muchas otras fuentes.
Las áreas funcionales de OLE DB incluyen acceso a datos y
actualizaciones, procesamiento de consultas, información del catalogo,
notificaciones, transacciones, seguridad y acceso a datos remotos. OLE
DB cubre la infraestructura OLE – COM (modelo de objetos componente),
la cual reduce la duplicidad innecesaria de servicios y provee un grado
más alto de interoperabilidad no solamente entre diversas fuentes de
información,
sino
también
entre
ambientes
y
herramientas
de
programación existentes.
2.6. CORBA
CORBA (Common Object Request Broker Architecture) es un estándar
para
la
interoperación
de
objetos
en
ambientes
cliente-servidor
heterogeneous. Los objetos CORBA pueden residir en cualquier parte de
una red. Estos están empaquetados como componentes binarios que los
clientes remotos pueden accesar vía invocación de métodos. El lenguaje
y compilador utilizado para crear los objetos servidores, son totalmente
transparentes a los clientes. Los clientes no necesitan conocer donde los
objetos distribuidos residen o en qué sistema operativo se ejecutan.
Un ORB (Object Request Broker) CORBA viene con mecanismos
estándar para generar y manejar metadatos. Los metadatos que
describen los componentes y sus interfaces se generan usando IDL
(Lenguaje de definición de la interface). El pre compilador IDL del ORB
escribe automáticamente sus metadatos definidos IDL en un repositorio
de interfaces. Desde el repositorio se pueden actualizar los metadatos
usando las operaciones de escritura y actualización del repositorio de
interfaces. Los clientes pueden consultar el repositorio de interfaces, ellos
pueden descubrir que interfaces están disponibles y como llamarlas. Se
puede utilizar el mismo repositorio de interfaces para almacenar la
descripción de componentes. Con CORBA se tiene una especificación
sólida para crear repositorios de interfaces federadas que pueden operar
a través de ORB-s y sistemas operativos heterogéneos.
Capítulo 3. Procesamiento de consultas en un sistema de base de datos
múltiples
El procesamiento de consultas en un sistema multibase de datos es la pieza
más importante para la operación del sistema. En este capítulo se describe la
arquitectura general de un procesador de consultas multibase de datos. Se
mencionan los módulos que integran un procesador de este tipo y la función
que deben llevar a cabo.
A grandes rasgos tres pasos son necesarios para procesar una consulta global.
Primero una consulta global es descompuesta en subconsulta de manera que
los datos necesitados por cada subconsulta estén disponibles desde cada
SBDC (sistema de base de datos componente). Después cada subconsulta es
trasladada a una consulta o consultas del SBDC y enviada al SBDC. Tercero,
los resultados retornados por las subconsultas son combinados para dar
respuesta a la consulta global.
El procesamiento de consultas es uno de los aspectos más complejos de un
sistema multibase de datos. Aunque esto debiera parecerse a un sistema de
base de datos distribuido existen diferencias debido a que los SBDCs de un
sistema multibase de datos normalmente son heterogéneos y poseen distintas
capacidades de procesamiento. De este manera el procesamiento y la
optimización de consultas resulta más difícil que en un sistema de base de
datos distribuido.
Las capacidades de procesamiento de consultas de los sistemas de base de
datos componentes (SBDC) pueden variar grandemente, las cuales van desde
sistemas de bases de datos orientadas a objetos y sistemas de base de datos
relacionales hasta sistemas de archivos.
El optimizador de consultas global debe descomponer una consulta global en
consultas componentes para ser procesadas por los SBDCs. Este también
debe determinar cómo y dónde ejecutar algún procesamiento de integración
que sea necesario. Para llevar a cabo cada SBDC para elegir el mejor plan de
ejecución.
3.1 Arquitectura de un Procesador de Consultas de base Datos múltiple
Un esquema global en los SBDFs fuertemente acoplados es el resultado
de la integración de los esquemas de exportación de más bases de datos
componentes. Un lenguaje de consulta global es utilizado por los usuarios
del sistema de base de datos federada para especificar consultas contra
el esquema global.
Para procesar una consulta global, la consulta primero es analizada y
después descompuesta en unidades de consulta las cuales son
representadas en la forma de un grafo de unidades de consulta. El
generador del Plan de Ejecución construye subconsultas a partir del grafo
de unidades de consulta y estima su costo de ejecución. El plan de
consulta con el costo estimado mínimo será enviado al despachador el
cual será el encargado de coordinar la ejecución de las consultas. Por
último los resultados de las consultas son combinados para construir los
resultados de la consulta global. La figura 3.1. Muestra la arquitectura de
un procesador de consultas para un SBDF.
Consulta global
Analizados sintáctico
Consulta valida
Descomponedor de Consultas
Grafo de unidades de consulta
Evaluador
De
Costo
Generador del Plan de Consulta
Plan de ejecución de la consulta
Manejador
De
Estadistica
Despachador de Subconsultas
Resultados de la subconsulta
SMBD1
SMBD2
Combinador de resultados
Resultado de la consulta global
Figura 3.1. Arquitectura de un procesador de consultas para un SBDF
3.1.1. Analizador Léxico, Sintáctico y Validación.
El
analizador
léxico
identifica
los
componentes
del
lenguaje
(componentes léxicos) en el texto de la consulta. El analizador sintáctico
revisa la sintaxis de la consulta para determinar si esta formulada de
acuerdo con las reglas sintácticas. Además la consulta se debe validar,
para lo cual ha de comprobarse que todos los nombres de atributos y de
relaciones sean validos y tengan sentido desde el punto de vista
semántico. Para llevar a cabo la validación este modulo requiere de
interactuar con el catalogo del SBDF.
3.1.2. Descomponedor de Consultas
La función del descomponedor es separar una consulta global en
unidades de consulta. Una unidad de consulta, tales como la selección,
proyección, o reunión con datos disponibles en la misma base de datos
componente. La descomposición puede ser llevada a cabo de acuerdo a
las siguientes heurísticas:
1. Selecciones y proyecciones en relaciones sencillas forman unidades
de consulta por si mismas.
2. Las operaciones de reunión y las que involucran solamente
relaciones almacenadas en la misma base de datos componente
también forman unidades de consulta.
3. Cuando una relación es la unión de relaciones en diferentes bases
de datos componentes, las unidades de consulta son formadas para
cada sitio.
4. Para una reunión (u otra operacion) que involucra dos bases de
datos diferentes, las relaciones en la condición de la reunión son
reemplazadas con unidades de consulta resultantes de las unidades
de consulta que recuperan la relación (o parte de esta) desde la
base de datos original.
El principio básico aquí es descomponer la consulta en el nivel más fino
para explorar todos los planes de ejecución posibles. La información
necesaria para poder descomponer la consulta es tomada del catalogo
del SBDF.
3.1.3. El Generador de Planes.
Dado un grafo de unidades de consulta, el generador de planes construye los
planes posibles que consisten de las subconsultas y su secuencia de
ejecución. Las unidades de consulta descompuestas son agrupadas
3.2
El Catálogo de un SBDF
El catalogo de un SBDF tiene un propósito similar al catalogo de un
sistema manejador de base de datos relacional. Los datos del catalogo
son de dos tipos:
o
Datos estructurales. Descripciones de objetos en el sistema y sus
relaciones.
o
Datos estadísticos. Principalmente estadísticas de los SBDCs
utilizados durante la optimización de consultas.
Un SBDC es descrito en el catalogo por propiedades tales como el tipo
de la fuente de datos, el modelo de datos usado y las funcionalidades
disponibles, los esquemas pueden ser representados en forma
relacional, y la información mantenida en el catalogo incluye los nombres
de las tablas en el esquema, el nombre y tipo de cada atributo en las
tablas, y los mapeos desde el esquema local de los SBDCs a su
representación relacional.
Para generar un plan de ejecución para una consulta el generador
requiere información de:

La localización de los datos que son referenciados en la consulta.

Los nombres de los datos requeridos, asi como la manera en que
son entendidos por el SBDC.

Estadísticas relacionadas al sistema de los SBDCs.
Esta información debe ser guardada en el catalogo del SBDF la cual
será accesada por el optimizador de consultas.
Capítulo 4. Lenguajes de bases de datos
4.1.
Lenguaje de Consultas
Es un lenguaje de no-programación en el cual un usuario puede formular
consultas y posiblemente también actualizar la base de datos. Noprogramación significa que el usuario no tiene que especificar un
algoritmo para obtener resultados, sino solamente definir la consulta de
una manera ordenada.
4.2.
Lenguaje de Manipulación de Datos
Es un lenguaje de programación que tiene una capacidad poderosa de
cálculo, flujo de control, entrada-salida, también tiene constructores
sintácticos para acceso a base de datos (actualización, recuperación e
intercambio dinámico de datos entre el programa y la base de datos). El
DML es utilizado por el programador de la aplicación.
Un lenguaje de manipulación de datos puede ser:

Un DML, stand-alone. En este caso el SMBD provee de un
compilador o interprete para el DML. La desventaja de este lenguaje
es que no puede ser usado para programas complejos, los cuales
ejecutan algún acceso a la base de datos, pero simultáneamente
ejecutan otras tareas, por ejemplo, cálculos numéricos.

Una Interface para llamadas al sistema. El usuario escribe un
programa en un lenguaje de programación tradicional. Elusuario
ejecuta accesos a la base de datos por llamadas a subrutinas al
SMBD. Las llamadas al sistema son interpretadas en tiempo de
ejecución del programa. Una desventaja es que si la llamada al
sistema contiene una solicitud incorrecta, el usuario no puede ser
notificado en tiempo de compilación, sino que tiene que esperar
hasta que el programa aborte.

Un DML Incrustado en un Lenguaje de Programación Anfitrión.
Este es una extensión de acceso a base de datos de un lenguaje de
programación de propósito general. El SMBD pre compila el
programa en un programa en el lenguaje anfitrión sin las sentencias
del DML. Durante la pre compilación el SMBD valida la sintaxis y la
compatibilidad con el esquema de la base de datos. El SMBD puede
también ejecutar optimización del algoritmo del usuario.
4.3.
Lenguaje de Definición de Datos
Es un lenguaje, en el cual la estructura lógica de la información puede
ser definida, junto con su interpretación pragmática para el manejo de
una base de datos, incluyendo el esquema, restricciones de integridad y
vistas de usuario.
4.4.
Construcción de Lenguajes de Bases de Datos
La tecnología de los compiladores, así como de los intérpretes ha sido
utilizada para el desarrollo de los lenguajes de bases de datos. La
compilación es ciertamente ventajosa desde el punto de vista de
desempeño, esta tiene casi siempre un mejor desempeño en tiempo de
ejecución que la interpretación. Sin embargo esto tiene una desventaja
significante: “es posible que decisiones hechas por el compilador en
tiempo de compilación no tengan validez larga en tiempo de ejecución”.
4.5.
Compiladores
Un compilador es un programa que lee un programa escrito en un
lenguaje fuente y lo traduce a un programa equivalente en otro lenguaje,
el lenguaje objeto. Como parte importante de este proceso de
traducción, el compilador informa al usuario de la presencia de errores
en el programa fuente.
En la compilación hay dos partes análisis y síntesis. Durante el análisis
se determina las operaciones que implica el programa fuente y se
registran en una estructura jerárquica llamada árbol. A menudo se usa
una clase especial de árbol llamado árbol sintáctico, donde cada nodo
representa una operación y los hijos del nodo son los argumentos de la
operación
4.5.1. Fases del un Compilador
Un compilador típicamente opera en fases, cada una lleva a cabo
una tarea sobre el programa fuente.
Las tres primeras fases suelen agruparse en una sola fase
llamada fase de análisis y las últimas tres en una llamada fase de
síntesis. La fase de análisis y el modulo de manejo de errores se
describen posteriormente en este mismo capítulo. La fase de
síntesis no es relevante en el contexto de un lenguaje multibase
de datos, ya que este sigue un enfoque diferente que el de los
lenguajes tradicionales, por esta razón solo se menciona.
Muchas herramientas de software que manipulan programas
fuente realizan primero algún tipo de análisis, entre estas se
encuentran los editores de estructuras, impresoras estéticas,
verificadores estáticos y los intérpretes.
4.6.
Intérpretes
En lugar de producir un programa objeto como resultado de una
traducción, un intérprete realiza las operaciones que implica el programa
fuente.
Muchas veces los intérpretes se utilizan para ejecutar lenguajes de
órdenes, pues cada operador que se ejecuta en un lenguaje de este tipo
suele ser una invocación de una rutina, como un editor o un compilador.
Del mismo modo algunos lenguajes de alto nivel son interpretados,
porque hay muchas cosas sobre los datos, como el tamaño y la forma de
las matrices que no se pueden deducir en el momento de la compilación.
4.7.
Lenguaje de Consultas de bases Datos múltiples
La parte de análisis de un lenguaje de consultas multibase de datos es
parecida a la de un compilador convencional. Los lenguajes de este tipo
son implementados por medio de un intérprete, un intérprete de este tipo
traduce un predicado que contiene operadores relacionales y booleanos
a órdenes para buscar en una base de datos registros que satisfagan
ese predicado.
4.7.1. La Fase de Análisis de un Lenguaje de Consultas.
El análisis consta de tres partes: análisis léxico, análisis sintáctico
y el análisis semántico.
 Análisis Léxico
La cadena de caracteres que constituye el programa fuente se
lee de izquierda a derecha y se agrupa en componentes
léxicos, que son secuencias de caracteres que tienen un
significado colectivo. El análisis léxico se encarga de hacer
esta agrupación.
 Análisis Semántico.
Implica
agrupar
los
componentes
léxicos
en
frases
gramaticales que el compilador utiliza para sintetizar la salida.
Por lo general, las frases gramaticales del programa fuente se
representan mediante un árbol de análisis sintáctico.
La división entre el análisis léxico y el análisis sintáctico es algo
arbitraria. Generalmente se elige una división que simplifique la
tarea completa del análisis. Un factor para determinar la
división es si una construcción es inherentemente recursiva o
no. Las construcciones léxicas no requieren recursión, mientras
que las construcciones sintácticas suelen requerirlas. Las
gramáticas independientes de contexto son una formalización
de reglas recursivas que se pueden usar para guiar el análisis
sintáctico.
 Análisis Semántico
La fase de análisis semántico utiliza la estructura sintáctica
determinada por la fase de análisis sintáctico para identificar
los operadores y operandos de expresiones y proposiciones.
En el caso de un intérprete de consultas se debe validar que
los nombres de atributos y de relaciones sean validos y tengan
sentido desde el punto de vista semántico.
Un componente importante del análisis semántico es la
verificación de tipos. Aquí, el intérprete verifica si cada
operador tiene operando permitidos por la especificación del
lenguaje fuente y verifica la compatibilidad de los tipos cuando
estos están involucrados, por ejemplo, en una condición.
4.7.2. Detección e Información de Errores
En cada fase se pueden encontrar errores. Después de detectar
un error cada fase debe informar del error con la descripción que
le permita al usuario o programador ubicarlo y corregirlo. Los
errores se dan con mayor frecuencia en las fases de análisis
sintáctico y semántico. La fase léxica puede detectar errores
donde los caracteres restantes de la entrada no forman ningún
componente léxico del lenguaje. Los errores donde la cadena
componentes léxicos violan las reglas de estructura del lenguaje
son detectados por la fase de análisis sintáctico. En el análisis
semántico el interprete detecta construcciones que tienen la
estructura sintáctica correcta, pero que no tienen significado para
la operación implicada, por ejemplo, si en un select se intenta
seleccionar un atributo cuya tabla no se especifica en la clausula
from.
Posterior a la fase de análisis en un lenguaje de consultas se lleva
a cabo la descomposición de la consulta global en subconsultas,
después la recuperación de la información desde las diversas
bases de datos y
global.
por último la reconstrucción de la consulta
Capítulo 5. LMBD: Un lenguaje de consulta para un sistema multibase de
datos
Este capítulo describe la forma en que fue implementado el prototipo para el
lenguaje multibase de datos. Se explica de manera general que se hizo en
cada fase del prototipo y los algoritmos que se utilizaron.
LMBD es un lenguaje de consulta para un sistema multibase de datos. La
implementación de este lenguaje comprende los siguientes módulos.

Un analizador léxico y semántico

Un analizador semántico

Un descomponedor de consultas

Un despachador de consultas

Un constructor de la consulta global

Una interfaz grafica para la captura y presentación de la información

Una interfaz de programación de la aplicación para LMBD
De esta forma la arquitectura del procesador de consultas para LMBD es como
sigue:
Consulta
Global
Analizador léxico y sintáctico
Consulta Valida léxica y sintácticamente
Catalogo de la
BD Federeda
Analizador Semántico
Consulta Valida léxica semánticamente
Descomponedor de consultas
y generador de subconsultas
Subconsultas
Despachador de subconsultas
Resultados de las Subconsultas
SMBD1
Combinador de Resultados
Resultados de la consulta Global
Arquitectura del Procesador de Consultas de LMBD
SMBD2
5.1.
Desarrollo del Analizador Léxico y Sintáctico
El analizador léxico y sintáctico se realizo utilizando una herramienta
escrita en java conocida como JavaCC. Esta herramienta nos permite
realizar la especificación de las reglas sintácticas.
Para la especificación de las reglas sintácticas se utilizo un estilo BNF,
que es una de las formas permitidas por JavaCC.
Una consulta SQL puede constar de un máximo de 6 clausulas pero
solamente son obligatorias las dos primeras, select y from. Las clausulas
se especifican en el siguiente orden:
SELECT (Lista de atributos)
FROM (Lista de atributos)
WHERE (condicion)
GROUP BY (Atributos de agrupación)
HAVING (condición de agrupación)
ORDER BY (Lista de atributos)
En el presente prototipo se contemplaron las primeras tres clausulas:
Select, From y where. La clausula select indica que atributos se van a
obtener, la clausula from especifica todas las relaciones que se
necesitan en la consulta, pero no las que se requieren en consultas
anidadas y la clausula where especifica las condiciones para seleccionar
tuplas de esas relaciones.
Estas tres clausulas le dan la suficiente capacidad para recuperar una
gran cantidad de consultas, mas considerando que dentro de la clausula
where se permite el empleo de consultas anidadas valiéndose para esto
del operador de conjuntos In y la función exists, así como la utilización
de los operadores lógicos and y or, además de permitir la especificación
del orden de evaluación de las condiciones a través de paréntesis y la
utilización de alias en las relaciones.
Una consulta típica utilizando LMBD es:
Select apellido, nombrep from empleado where not exists (select nombre
from trabaja_en B where b.nump in (select numero from proyecto where
numd=5) and not exists (select * from trabaja_en C where nss=010223));
Durante el análisis léxico - semántico se genera el árbol de análisis
semántico (AAS), utilizando la herramienta JJTree de JavaCC. De esta
manera es creado un nodo en el árbol por cada no terminal de la
gramática, a no ser que se especifique lo contrario. El árbol se adapta
para que capture la información referente a las unidades léxicas
aceptadas por la gramática, como son los nombres de atributos y de
tablas o valores atómicos, es decir, números, cadenas y valores de
punto flotante. De esta forma una consulta como la siguiente:
Select m.nombre, superficie
From municipios m, localidades 1
Where (m.id>1) and (m.id=1.id);
Después que es aceptada queda representada por un árbol de análisis
sintáctico como el que se muestra en la figura adjunta:
Query_spec
Selection
Column ref
Column ref
From clause
Table ref
Where clause
Comp-predicaten
Árbol de análisis sintáctico
5.2.
Desarrollo del Analizador Semántico
Comp-predicaten
Después de llevar a cabo el análisis léxico y sintáctico, la consulta se
debe validar, para lo cual ha de comprobarse que todos los nombres de
atributos y de relaciones sean validos y tengan sentido desde el punto
de vista semántico.
Para poder llevar a cabo la validación semántica se repera la
información producida durante el proceso de integración de las bases de
datos, es decir, los metadatos.
En el proceso de integración se genera un esquema global a partir de las
bases de datos componentes. Así, a partir de este esquema global se
obtienen los nombres de las tablas que integran la base de datos, los
atributos de cada tabla y los tipos de datos de cada atributo. Esto se
realiza por medio de la clase Metadato. Esta información se recupera
una sola vez de la base de datos y después permanece en memoria
principal, hasta que una nueva base de datos es abierta, esto hace más
rápido el proceso de validación semántica.
El formato referente a cada tabla que compone el catalogo de la
multibase de datos es parte de un trabajo que se desarrolla al mismo
tiempo que este lenguaje, así como el proceso de integración de los
esquemas; mismo que fue diseñado en base a los requerimientos
desprendidos
del
análisis
de
las
necesidades
de
información
(metadatos) necesarias para poder procesar una consulta multibase de
datos.
5.2.1. Reglas Semánticas
Las siguientes son las reglas que se verifican en el análisis
semántico.
1. Las tablas listadas en la clausula from existan
2. Los atributos listados en el select pertenezcan a alguna de las
tablas listadas en la clausula from.
3. Los nombres de atributos no deben repetirse
4. Un nombre de atributo no debe existir en más de una tabla, a
no ser que se haga referencia al atributo anteponiendo como
prefijo el alias de la tabla o el nombre de la tabla.
5. El nombre de atributo (con o sin alias) utilizado como parte de
una condición en la clausula where debe pertenecer a alguna
de las tablas listadas en la clausula from previa.
6. Los atributos que forman parte de una condición en el where
deben tener tipos de datos compatibles. Ya se que trate de dos
atributos o de un atributo y un valor. Por ejemplo:
Where (dirección=domicilio) donde dirección y domicilio deben
tener tipos de datos compatibles.
Where (nombre= ‘Jesús’) donde nombre debe ser un tipo que sea
compatible con una cadena.
Where (numero=5) donde numero debe ser de tipo int o real.
Where (fracción=0.90) donde fracción debe ser de tipo real.
7. Verificar que los atributos que forman parte de una colección
en un where no presenten conflictos de atributo faltante o
composición. Los atributos que presentan estos conflictos no
son buenos candidatos para ser parte de una condición.
Estas mismas reglas se aplican también a las subconsultas que
aparecen dentro de un where.
En esta etapa también se modifica el AAS (árbol de análisis
sintáctico) para asociarle información que será utilizada en la
descomposición de la consulta y en la verificación de la
compatibilidad de tipos de datos. Esto se hace al agregar hijos al
AAS o bien al agregar atributos al nodo (cada nodo es instancia
de una clase que lo identifica).
5.3.
Desarrollo del Descomponedor de Consultas
Este proceso se lleva a cabo para poder obtener la información
necesaria para construir las subconsulotas que deben enviarse a cada
sitio
El algoritmo que se propuso para la descomposición y construcción de
subconsultas es como sigue:
1. Por cada atributo que aparece en la clausula select hacer:
Ir a la tabla de equivalencias del esquema auxiliar y recuperar la
tabla local, atributo local, el sitio donde se ubican y los conflictos
que presentan.
Si el atributo presenta el conflicto de atributo faltante (FA)
entonces no agregar el atributo al select
Si el atributo presenta el conflicto de composición (CMP)
entonces localizar todos los atributos que lo conforman y
agregarlos al select
Si el atributo presenta el conflicto de horizontalidad (H) entonces
agregar al atributo a ambos selects.
Si el atributo no presenta el conflicto de horizontalidad entonces.
Por cada atributo que se agrega al select también se agrega al
atributo designado para ser el atributo con el que se va a hacer la
operación reunión de las tablas, es decir el atributo común a
ambas tablas.
2. Por cada atributo que aparece como parte de una condición en el
where hacer:
Si el atributo aun no forma parte de la lista de atributos del select
agregar el atributo, para posteriormente poder verificar la
condición.
Las condiciones son guardadas en un vector para después
utilizarlas en la reconstrucción de la consulta global, estas
condiciones sirven para seleccionar las tuplas.
Este algoritmo se lleva a cabo tomando la información del
esquema auxiliar de la multibase de datos y la información
almacenada en el AAS.
5.4.
Desarrollo del Despachador de Consultas
Este modulo se encarga de enviar las subconsultas al sitio que les
corresponde y recuperar la información. Para hacer esto tiene que
conocer la ubicación del sitio, la cual se encuentra almacenada en la
tabla localización del esquema auxiliar de la multibase de datos.
La interconexión con las fuentes de datos es a través de JDBC. Asi la
información de localización del sitio está en forma de un URL
(localizador uniforme de recursos) que es lo que se encuentra
almacenado en la tabla localización del esquema auxiliar de la multibase
de datos.
La clase de BaseDatos que se implemento, permite la interconexión con
las fuentes de datos de la manera sencilla. Por ejemplo:
BaseDatos.OpenDB (“Informix”,”Municipios”);
Realiza la conexión con la base de datos municipios que se encuentra
en el servidor informix.
En el presente prototipo las bases de datos que se pretenden integrar
están almacenadas con los manejadores de base de datos Informix
Universal y Oracle RDB.
Obtener el controlador JDBC para Informix fue relativamente fácil, no así
con el controlador JDBC para Oracle RDB. Oracle RDB funciona bajo el
sistema operativo VMS lo cual implica otras operaciones propias de VMS
para cargar el controlador. También cabe mencionar que la versión de
JDBC que se utilizo es una versión comercial, por lo que si no se
compra, solo se puede descargar para que funcione durante 4 horas,
después de este tiempo el controlador se inhabilita, asi que si se desea
seguir utilizándolo hay que matar el proceso y volver a cargar el
controlador.
5.5.
Desarrollo de la Interfaz de Usuario para la Captura y Presentación
de Información
El prototipo completo se desarrollo con el lenguaje Java, de esta forma
la interfaz de usuario está construida utilizando clases del paquete AWT
de Java.
La interfaz principal de LMBD es como se muestra en la figura adjunta.
Interfaz Principal de LMBD
Esta interfaz ofrece diversos servicios los cuales se mencionan a
continuación:
1. El menú File de la barra de menus tiene las siguientes opciones
a. Open multidatabase. Realiza la apertura de una multibase
de datos seleccionándola de una lista ver figura adjunta.
b. Open Database. Realiza la apertura de una base de datos
local. En una lista como la de la figura adjunta se
despliegan las bases de datos locales y de aquí se
selecciona alguna.
Lista de la Base de Datos
Disponibles para consulta
c. Quit Sale de la aplicación
2. E menú View. Muestra el esquema de la base de datos activa en
una ventana como la de la figura siguiente. El objetivo es
presentar las tablas y atributos de la base de datos que se
consulta. Funciona de la misma manera para una multibase de
datos que para una base de datos local.
Esquema de la base de datos activa
3. El botón Excecute del área de botones inicia la ejecución de la
consulta presente en el área de captura de la consulta. Si la
consulta es correcta los resultados son mostrados en una
ventana, si algún error ocurre un mensaje es mostrado en la zona
de mensajes de error.
4. El Botón Clean del área de botones limpia el área de captura de la
consulta, así como el área de despliegue de mensajes de error.
5.6.
La Interface de Programación de la Aplicación de LMBD
LMBD puede ser manejado desde una aplicación sin necesidad de
utilizar la interfaz grafica, es decir, LMBD puede ser llamado desde un
programa Java a través de la clase MultiBD. Así, se puede llevar a cabo
la manipulación de una o más multibases de datos dentro de un mismo
programa Java. Los resultados de una consulta a una multibase de
datos son retornados como un objeto de la clase Result (ver apéndice E)
y por lo tanto pueden ser manipulados por el programador como desee.
La forma en que se utiliza una multibase de datos dentro de una
aplicación es sencilla solo son necesarios los siguientes pasos:
1. Crear un objeto de la clase MultiBD
MultiBD m=new MultiBD();
2. Abrir la multibase de datos indicando el nombre del esquema
global y el nombre del esquema auxiliar
M.open (“eg_municipios”, “ea_municipios”);
3. Someter una consulta
Result r=m.execute (“select * from municipios;”);
Para probar la funcionalidad de la clase MultiBD manejada desde un
programa Java se desarrollo una aplicación en la que se integra
información geográfica e información descriptiva. La información
geográfica que se integra esta distribución en los manejadores de base
de datos. La integración de la información geográfica se encuentra en
una multibase de datos llamada eg_espacial y la información descriptiva
en una multibase de datos llamada eg_municipios, ambas multibases de
datos son manipuladas desde un programa Java llamado consultas.
La aplicación Consultas dibuja el mapa de la ciudad de Chincha y
permite hacer consultas haciendo click sobre alguno de sus municipios.
Después de detectar el municipio seleccionado se genera una consulta
que se encarga de recuperar la información descriptiva correspondiente
a este municipio a través de la multibase de datos eg_municipios.
Finalmente la información es presentada. Esta aplicación es una
muestra de cómo se puede manipular más de una multibase de datos
desde un mismo programa Java.
La flexibilidad de LMBD de poderse manipular desde un programa Java
le da al programador una herramienta poderosa para consultar una
multibase de datos cuyo resultado puede manipularse a placer, aun mas
si consideramos que se puede manipular más de una multibase de datos
desde un mismo programa Java.
En el apéndice C se muestran ejemplos que describen de manera
sencilla como se realizan el procesamiento de una consulta, lo cual
puede ayudar a comprender mejor la implementación de este lenguaje.
Conclusiones
La importancia principal de las multibases de datos y más concretamente de
las bases de datos federadas fuertemente acopladas radica principalmente en
su bi-procesamiento. Es decir, en su capacidad de atender consultas globales,
al mismo tiempo que permite que las bases de datos componentes sigan
atendiendo a sus aplicaciones locales.
La existencia de un esquema global permite que el lenguaje implementado
para llevar a cabo las consultas sea fácil de aprender y entender (muy parecido
a SQL) debido a que este da a la multibase de datos la apariencia de que se
accesa a una base de datos sencilla y por lo tanto las operaciones de
distribución son transparentes al usuario.
El problema de la heterogeneidad de las bases de datos componentes puede
hacer que algunas tareas lleguen a ser complejas. La tarea de optimización de
consultas requiere de información como la velocidad de procesamiento del
CPU, la velocidad de entrada/salida entre otros, para cada una de las bases de
datos; así como el tamaño de los resultados intermedios de las subconsultas,
sin embargo debido a la heterogeneidad de las bases de datos componentes,
esta información es difícil de mantener principalmente por las diferentes
capacidades de procesamiento de las bases de datos componentes lo cual
hace que la optimización de consultas sea una tarea difícil de realizar.
El surgimiento de estándares y nuevas tecnologías permite crear soluciones
multibase de datos. Estándares para el desarrollo de manejadores de bases de
datos (como el estándar para SQL), así como el de tecnologías para la
conexión a múltiples bases de datos y lenguajes capaces de crear aplicaciones
que se ejecutan en cualquier plataforma (como java) permiten crear
aplicaciones
multibase
de
datos,
que
aunque
consumen
un
tiempo
considerable ofrecen una solución.
Un aspecto importante de este prototipo es que permite la operación global y
local desde la misma interfaz. Los servicios que ofrecen para una multibase de
datos también se ofrecen para una base de datos local.
El utilizar SQL como lenguaje de consulta para la multibase de datos hace que
todo parezca transparente al usuario, que da la apariencia que se accede a una
base de datos local.
Bibliografía
Alvarez, G. 1999. Integración de esquemas para una multibase de datos. Tesis.
Departamento de Sistemas Computacionales, Universidad de las Américas,
México.
Litwin, W. y Abdellalit A. 1998. An Overwiew of the multi-database manipulation
language MDSL. Procceding of the IEEE 75,5.
López, E. J. 1998 Modelación de información geográfica. Tesis. Departamento
de Sistemas Computacionales de la Universidad de las Américas, Santa
Catarina, puebla, México.
Data, C.J. 1990 Database Systems. Addison-Wesley. EU.
Nguyen, T. y Srinivasan, V. 1996. Accessing relational databases from the
world wide web. ACM Sigmod 25,2.
Paginas electrónicas
http://www.javaworld.com/javaworld/jw-05-1996/jw-05-shah.html
http://www.suntest.com/javaCC
ANEXOS
Apéndice A. Reglas gramaticales de LMen su forma B
Query_term::=”(“ <query_epec>”)”
<query_epec>::=”select” <selection> <table_exp> “;”
<selection> ::= <scalar_exp_commalist> “*”
<scalar_exp_commalist> ::= (<column_ref()> {“,”<column_ref>}*)
(“(”<column_ref>{“,”<column_ref>}*”)”)
<column_ref> ::= <identifier> “.”<identifier>
<identifier>
<table_exp> ::= <from_clause> [where_clause]
<from_clause> ::= “from” <table_ref_commalist>
<table_ref_commalist> ::= (<table_ref>{“,”<table_ref>}*)
(“(”<table_ref>{“,” <table_ref>}*”)”)
<table_ref> ::= <identifier> {<identifier>}*
<where_clause> ::= “where” <search_condiction>
<search_condiction> ::= (<predicate> “(”<search_condiction>”)”)
{(“or”; “and”) (<predicate>”(”
<search_condiction> “)”)}*
<predicate> ::= <comparasion_predicate>
<search_condiction>
<existence_test>
<comparison_predicate> ::= <scalar_exp> <operador_relacional>
<scalar_exp> (<scalar_exp> <operador_relacional> “(”<subquery>”)”)
<in_predicate> ::= <scalar_exp> [“not”] “in” “(”<subquery>”)”
<existence_test> ::= [“not”] “exists” “(”<subquery>”)”
<subquery>::= “select” <selection> <table_exp>
<operador_relacional> ::= “>” “<”“>=” “=<” “=”“<>”
<escalar_exp> ::= <literal> <column_ref>
<literal> ::= <entero> <real> <cadena>
<entero> ::= [“0” – “9”] {[“0” – “9”]}*
<real> ::= [“0” – “9”] {[“0” – “9”]}*
<cadena> ::= “’”{&[““,””,”;”,”’”
<identifier> ::= <letra> {<letra> <digito> “-” }*
<letra> ::= “A”-“Z”, “a”-“z”
<digito> ::= “0”-“9”
Reglas Gramaticales implementadas con JavaCC
Options {
JAVA_UNICODE_ESCAPE =true;
MULTI =true;
VISITOR = true;
}
PARSER_BEGIN (SQLparser)
Public class SQLParser {}
PARSER_END (SQLParser)
/*Estos caracteres serán ignorados por el parser*/
SKIP :
{
“”
“
“
“
“”
“f”
}
/*Palabras reservadas*/
TOKEN :
{
<SELECT: “select”>
<DISTINCT: “distinct”>
<FROM: “from”>
<WHERE: “wheret”>
<AND: “and”>
<OR: “or”>
<NOT: “not”>
<IN: “in”>
<EXISTS: “exists”>
<ASTERISCO: “*”>
}
/*Separadores*/
TOKEN :
{
<LPAREN: “(”>
<RPAREN: “(”>
<LBRACKET: “[”>
<RBRACKET: “]”>
<SEMICOLON: “;”>
<COMMA: “,”>
<DOT: “.”>
}
/* Operadores */
Token :
{
<GT: “>”>
<LT: “<”>
<COLON: “:”>
<EQ: “=”>
<LE: “<=”>
<LE: “>=”>
<NE: “<>”>
ASTStart Start () : {}
{
Query_term()
{ return jjtThis;}
}
Void query_term( ) # void : {}
{
Query_spec()
“(” query_spec() “)“
}
Void query_espec() : {}
{
“select” selection() table_exp (“;”)
}
Void selection () : {}
{
Scalar_exp_commalist()
“+”
}
Apéndice B. Tipos de conflictos de integración

Nombrado de tablas y nombrado de atributos. Estos requerimientos de
la tabla de equivalencias para establecer la relación semántica entre las
tablas y atributos globales con las tablas y atributos locales.

Grado de atomicidad o composición (CMP). Cuando un atributo del
esquema global puede ser representado por la composición de más de un
atributo en el esquema local de una base de datos.

Fragmentación horizontal (H). Cuando la información de una tabla se
encuentra distribuida lógicamente en los dos componentes, pero a
diferencia de la anterior los atributos globales tienen equivalencias con los
atributos locales de las dos bases de datos componentes.

Fragmentación Vertical. Cuando la información de una tabla se
encuentra distribuida lógicamente en los dos componentes pero a
diferencia de la anterior los atributos globales tienen equivalencias con los
atributos locales en alguna de las dos bases de datos componentes, pero
no en las dos, a excepción del atributo que se designe para llevar a cabo
la operación reunión.

Fragmentación Identidad. Esta se presenta cuando una tabla local (con
sus atributos) tiene una equivalencia directa con la tabla global (con sus
atributos), es decir la tabla local para a formar parte de manera directa de
una tabla en el esquema global.

Atributos Faltantes (FA). Este se presenta cuando hay fragmentación
horizontal y algún atributo que no exista en alguna de las dos bases de
datos componentes, y aun así se desea hacer una integración horizontal.

Unidades Distintas (UD). Cuando la escala de medidas utilizadas para
representar valores de atributos locales son diferentes pero compatibles.
Así que hay que determinar una función de mapeo para poder aplicarla al
atributo local y así tener una representación para el atributo global.
Una de las tablas que componen el esquema auxiliar del catalogo de la
multibase de datos y donde se encuentra la información referente a los
conflictos antes mencionados es la de equivalencias, donde por cada atributo
se define el conflicto(s) que presenta:
Equivalencias
Tabla
Atributo
Tabla
Atributo
Id
global
global
local
local
componente
Conflictos
Las siguientes tablas completan el esquema auxiliar de la multibase de
datos.
Localización
Nombre_bd
Servidor
Id_componente
atributosJoin
Id_componente
Tabla
Atributo
tipoIntegracion
Tabla
Integración
Auxiliar
Id_componente
Tabla_global
Atributo_local
Expresión
Apéndice C. Ejemplos de procesamiento de consultas multibase de datos
Supongamos que tenemos las siguientes bases de datos
Municipios
Id
Nombre
Significado
Municipios
Id
Id
Nombre
Nombre
No_habitantes
No_habitantes
Superficie
Superficie
Municipios
Id
Nombre
No_habitantes
Superficie
Presidente
Presidente
RFC
Nombre
Domicilio
Id_municipio
RFC
Nombre
Domicilio
Id_municipio
Localidades
Localidades
Localidades
Nombre
Id_municipio
Nombre
Id_municipio
Superficie
Nom_loc
Id_municipio
Superficie
Obras
Nom_localidad
Cue_obra
Des_obra
Cue_obra
Desc
Presupuesto
Inicio
Fin
En el esquema podemos observar de manera grafica como se lleva a cabo la
integración de dos bases de datos. Las flechas más gruesas indican que este
atributo es con el que se va a llevar a cabo la operación reunión de ambas
tablas, por lo cual este atributo debe estar en las dos tablas. Las flechas
delgadas indican que este atributo forma parte de la tabla global. Este tipo de
integración la denominamos integración de tipo vertical.
Tomando en cuenta este esquema global, al someter una consulta contra este
esquema como la siguiente:
Select * from municipios,localidades
Después de hacer la descomposición tendríamos las siguientes subconsultas:
Para el sitio 1 tendríamos:
o
o
Select Id,nombre
para el sitio 2 tendríamos
1. Select ID,
From municipios
No_habitantes
Select Nombre,
superficie
Id_municipio from
Localidades
2.
Select
superficie
localidades
nom_loc,
from
Después que la despachadora de subconsultas envía estas al sitio que les
corresponde y recupera los resultados obtenidos, se realiza la operación
reunión entre ambos resultados.
En los primeros selects la operación reunión se lleva a cabo por medio del
atributo, el cual es el atributo común entre las dos tablas, en los selects (2) la
reunión se lleva a cabo por medio de los atributos Nombre y Nom_loc. Después
de esta operación cada tabla del esquema global ya tiene los resultados que
les corresponde con los atributos seleccionados.
De acuerdo a la consulta global se debe realizar el producto cartesiano de las
tablas municipio y localidades y esta sería el resultado de la consulta. En el
caso de que existiera una clausula where entonces mientras se lleva a cabo la
combinación de tuplas en el producto cartesiano se va verificando que tuplas
cumplen con las condición (es) y solo las que cumplen se agregan a la tabla
resultados.
Por supuesto el número de subconsultas y operaciones realizadas para
procesar una consulta global se incrementan conforme se somete una consulta
más complicada, por ejemplo una que utilice múltiples condiciones y
subconsultas.
Ejemplo. Procesamiento de una consulta global en una integración de tipo
horizontal
Si se tiene la siguiente base de datos.
Sitio 1
BD escolar_mod
Esquema global
Sitio 2
de la multibase de datos BD Escolar_Mod
Alumnos
Alumnos
Alumnos
Matricula
Nombre
domicilio
Fecha_nac
Materias
Matricula
nombre
domicilio
Email
Fecha_nac
Materias
Clave_alumno
Nom_alumno
calle
No
Localidad
E_mail
Materias
Clave_mat
Nombre
Clave
Nombre
Clave
Nombre
Cursos
Cursos
Cursos
Matricula
Clave_materia
cedula
calif
semestre
Matricula
Clave_materia
cedula
calif
semestre
Clave_alumno
Clave_materia
Cedula_profesor
calificacion
Catedraticos
Catedraticos
Catedraticos
Cedula_prof
nombre
domicilio
telefono
Cedula
Cedula_prof
nombre
domicilio
telefono
Cedula_profesional
nombre
domicilio
telefono
Figura. Integración de los esquemas de las bases de datos escolar_m y
escolar_mod en un esquema global.
Como podemos observar en la figura la integración del esquema global
es tomando atributos de ambas tablas de los dos sitios. Este tipo de
integración la denominaremos integración horizontal. La operación
principal de este tipo de integración es la operación unión, es decir, la
información de una tabla global es una unión del sitio 1 y los datos del
sitio 2. En este tipo de integración se presentan diversos conflictos, los
cuales se mencionan en el apéndice B.
Asimismo vemos que el atributo domicilio en la tabla alumno del
esquema global está integrado por el atributo domicilio de la base de
datos escolar_m del sitio 1 por un lado, y por el otro por una
concatenación de los atributos calle, no y localidad de la base de datos
escolar_mod del sitio 2, este conflicto se conoce como composición.
Otro conflicto que se presenta es el de atributo faltante. Podemos ver
que el atributo fecha_nac de la tabla alumno del esquema global solo
tiene atributo equivalente en el sitio 1, pero no en el sitio 2, de esta
manera cuando se haga la unión de estos atributos la información del
sitio 1 si tendrá esta información la cual se verá reflejada en la tabla
correspondiente en el esquema global, pero como en el sitio 2 no existe
esta información entonces un null es el esquema global, pero como en el
sitio 2 no existe esta información entonces un null será agregado en el
lugar que le corresponde a este atributo en la tabla del esquema global.
Un conflicto más que se presenta es el de unidades distintas. El atributo
calificación de la tabla cursos está integrado por el atributo calif en el
sitio 1 y por calificación en el sitio 2. El conflicto aquí es que calif utiliza
una escala de 10 para expresar la calificación y calificación del sitio 2
utiliza una escala de 100. Como en el atributo global calificación se
desea que este expresado en escala de 100, al atributo calif local hay
que aplicarle la expresión calif*10 para que asi al formar la tabla global
los datos tengan la misma representación.
Tomando en cuenta este esquema global, veamos los siguientes
ejemplos.
Ejemplo 1:
Select * from catedráticos;
Después de hacer la descomposición tendríamos las siguientes
subconsultas:
Para el sitio 1 tendriamos
1. Select cedula_prof,
Para el sitio 2 tendriamos
1.
Select,
cedula_profesional,
Nombre, domicilio,
nombre, domicilio,
Telefono from
teléfono from
Catedráticos
catedráticos
Ya teniendo las subconsultas el despachador de consultas se encarga
de enviarlas al sitio que les corresponde y recupera los resultados
obtenidos. Después se realiza la operación unión con la información de
ambas subconsultas, aquí no hay problema porque hay una relación uno
a uno entre los atributos de las tablas locales con los atributos en la tabla
global, así que la información solamente se agrega en una estructura de
datos que contendrá la información de ambos sitios.
Ejemplo 2:
Select * from alumnos;
Después de hacer la descomposición tendríamos las siguientes
subconsultas:
Para el sitio 1 tendríamos:
Select matricula,
para el sitio 2 tendríamos:
select
clave_alumno,
Nombre,domicilio
nom_alumno,calle,
Fecha_nac from
no,localidad,
Alumnos
e_mail from alumnos
Luego que el despachador envía las subconsultas y recupera los
resultados, hay que hacer un proceso que haga coincidir los atributos de
la tabla local con los atributos de la tabla global. En este proceso se
deben resolver los conflictos que se presenten, en este ejemplo se
presenta el conflicto de composición para el atributo domicilio y los
conflictos de atributo faltante en los atributos fecha_nac, e_mail del
esquema global. Después de resolver los conflictos y hacer coincidir los
atributos locales con los globales, ya se puede llevar a cabo la operación
unión con los resultados de las subconsultas.
Al igual que en la integración vertical el procesamiento de la consulta se
hace más complejo cuando, se involucran varias tablas, condiciones y
subconsultas. Pero el objetivo de estos ejemplos es ilustrar como se
lleva a cabo el proceso para integrar la información en tablas, el resto del
procesamiento ya es similar al de una base de datos sencilla.
La diferencia entre la integración vertical y la horizontal es el tipo de
operación que se realiza para integrar una tabla, es decir para una
vertical se lleva a cabo una operación reunión y para la horizontal una
operación unión. En un esquema global pueden existir tablas integradas
de manera horizontal y tablas integradas de forma vertical si así se
desea.
Apéndice D. Algoritmo ordenamiento-mezcla para la operación reunión
El algoritmo ordenamiento-mezcla es ejecutado en dos etapas. Primero ambas
relaciones son ordenadas con los atributos con los que se hará la operación
reunión. Luego, ambas relaciones son analizadas en el orden de los atributos
de reunión y las tuplas que satisfacen la conducción de reunión son mezcladas
para formar una sola relación.
El algoritmo para ejecutar la reunión es como sigue:
Etapa 1: Proceso de ordenamiento
Ordenar R en r(a)
Ordenar S en s(b)
Etapa 2: Proceso de mezcla
Leer primera tupla de R
Leer primera tupla de S
Para cada tupla r hacer {
Mientras s(b) < r(a)
Leer la siguiente tupla de S
Si r(a) = s(b) entonces
Reunir r y s
Colocar la reunión en la relación de salida
El tiempo de procesamiento de este algoritmo depende de los algoritmos de
ordenamiento y mezcla. Si las relaciones ya están ordenadas, el costo es
solamente de mezclar las dos relaciones. En general el tiempo de ejecución
depende principalmente del tiempo de ordenamiento el cual es usualmente de
O (n log n) para cada relación, donde n es la cardinalidad de la relación. Para el
prototipo de esta tesis las relaciones se recuperan ya ordenadas desde la base
de datos.
Apéndice E. Implementación en Java de la clase Result
La clase Result es la clase utilizada para modelar la estructura en la que se
almacenan los resultados de una consulta global. El método setData introduce
un dato a la estructura por medio del nombre de la columna a la que pertenece.
El método getData recupera el dato correspondiente a una columna.
El método getTupla recupera la tupla especificada por un numero de renglón
El método include retorna true si la estructura contiene el dato que recibe como
parámetro.
El método notinclude retorna true si la estructura no contiene el dato que recibe
como parámetro.
El método isEmpty retorna true si la estructura está vacía.
Importe java.util.*;
Importe java.lang.*;
Public class result
{
Vector buf[];
Vector nombres=new vector();
Int sizes[];
Int numCols;
Results (int numcolumnas){
Buf =new vector (numcolumnas];
Sizes = new int(numcolumnas);
For (int i=0; I I (numcolumnas; i++) buf [i] =new vector ();
Numcols =numcolumnas;
}
Public void setData (String columnas, String dato) {
Dato=dato.trim();
If (!nombres,contains (columnas)) nombres.addElement(columnas);
Int col=nombres.indexOf (columnas);
Buf [col].addElement [dato];
If (dato.length () > sizes [col]) sizes [col]=dato.length();
}
Public String getData (int ren, String columnas) {
Int col=nombres.indexOf (columnas);
Return buf [col].elementat (ren). To String();
}
Public vector getTupla (int ren) {
Vector tupla=new vector();
For (int j=0; j <
numCols; j++) {
tupla.addElement (buf[j].elementAt(ren));
}
Return tupla;
}
Public Boolean include (string valor){
For (int i=0; i <buf [0].size(); i++) {
For (int j=0; j <numCols; j++){
If (!buf [j].IsEmpty())
If (valor.compareTo (buf[j].elementAt (i).toString())==
0) return true;
}
Return false;
}
Public Boolean notInclude (string valor){
For (int i=0; i <buf [0].size(); i++) {
For (int j=0; j <numCols; j++){
If (!buf [j].IsEmpty())
If (valor.compareTo (buf[j].elementAt (i).toString())==
0) return true;
}
Return true;
}
Public Boolean isEmpty(){
For (int j=0; j <numCols; j++)
If (!buf [j].IsEmpty()) return false;
Return true;
}
Public String toString(){
for (int i=0; i<nombres.size(); i++)
system.out.print (nombres.elementAt(i) +” “);
for (int i=0; i for <buf [0].size(); i++
for (int i=0; i<nombres.size(); i++)
if (!buf[j].IsEmpty())
system.out.print (buf[j].elementAt(i)+” “);
system.out.printLn (“ “);
}
Return “ “;
}
} //FIN Result
Apéndice F. Implementación en Java de la clase Metadatos
La clase metadato se utiliza para recuperar los metadatos de una base de
datos que implemente la tecnología JDBC.
El método getCatalogs obtiene los nombres de las bases de datos que existen
en un sistema manejador de base de datos, solo requiere de un objeto de la
clase Connection (clase del paquete sql de java) que este dirigido a cualquier
base de datos del manejador.
El método gettables obtiene las tablas pertenecientes a una base de datos.
Requiere como parámetros un objeto de la clase Connection y el nombre de la
base de datos.
El método getColums obtiene las columnas pertenecientes a una tabla.
Requiere como parámetro un objeto de la clase Connection dirigido a la base
de datos que contiene la tabla y el nombre de la tabla.
El método getTypes obtiene los tipos de datos de los atributos de una tabla.
Requiere como parámetro un objeto de la clase Connection dirigido a la base
de datos que contiene la tabla y el nombre de la tabla.
Import java.sql.*;
Import java.util.*;
Class Metadatos
{
Public static vector getCatalogs (connection conn) {
Boolean notnode=true;
String catalog_name;
Vector Catalog_list=new vector();
Try {
DatabaseMetadata dmd = conn.getMetadata();
ResultSet rs =dmd.getCatalogsa();
While (notnode) {
Nodnode = rs.next();
If (notnode) {
Catalog_name=rsgetString(1);
Catalog_list.addElement(catalog_name);
}
}
}
Catch (SQLException se) {
System.out.printLn (se);
}
Finally {return catalog_list;}
}
Public static vector getTables (connection conn, String database) {
Boolean notdone=true;
Vector table_list =new vector();
String
types[]
={“TABLE”,
“VIEW”,”SYSTEM
TABLE”,”GLOBAL”,”TEMPORARY”, “LOCAL TEMPORARY”}
Try {
DatabaseMetadata dmd=conn.getMetaData();
ResultSet rs =dmd.getTables (database, “&”,”&”,types);
While (notdone) {
Notdone=rs.next();
If (notdone)
Table_list.addElement (rs.getString(3));
}
}
Catch (SQLException se) {System.out.println(se);}
Finally {return Table_list;}
}
Public static vector getColumn (connection conn, String database) {
Vector Column =new vector();
String query = “select * from “ + table;
Try {
Statement stat = conn.createStatement();
ResultSet re = stat.executeQuery(query);
ResultSetmetadata metadata = re.getMetadata();
Int nresultcols = metadata.getColumnCount();
For (int i=0; I < nresultcols; i++)
Columns.addElement (metadata.getColumnLabel (i+1));
System.out.println();
}
Finally {return Columns;}
}
Public static vector getTypes (connection conn, String table) {
Vector Types =new vector();
String query = “select * from “ + table;
Try {
Statement stat = conn.createStatement();
ResultSet re = stat.executeQuery(query);
ResultSetmetadata metadata = re.getMetadata();
Int nresultcols = metadata.getColumnCount();
For (int i=0; I < nresultcols; i++)
Types.addElement (metadata.getColumnTypeName (i+1));
System.out.println();
}
Catch (SQLException se) {
System.out.print (se);
}
Finally {return Types;}
} // FIN CLASE Metadatos