jueves, 30 de abril de 2015

ACTIVIDAD 3 PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS


 METODOLOGIA DE PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

Primeramente se debe de contar con heterogenidad de los datos, para que puedan ser usados para formular consultas. Tenemos los sigueintes ejemplos:

BD CENTRALIZADA



BD DISTRUIBUIDA


Asi como tambien necesitamos contar con:

-Localizacion de los datos para generar reglas heuristicas
-Descomposicion de consultas en paralelo en cada nodo
-Reducir la cantidad de datos a transferir en la red


ESTRATEGIAS DE PROCESAMIENTO DE CONSULTAS DE BASES DE DATOS DISTRIBUIDAS
Contamos con la estategia de Reformulacion de consultas, que nos sirve para encontrar q la informacion que nos va a proveer sea solo la que se le pidio por la fuente


Tambien se cuenta con la estrategia de descomposicion de las fuentes, que consiste en que segun las fuentes que pidan cierto tipo de datos sean las atentidas con mayor velocidad.


El procesamiento de consultas tiene como objetivo principal transformar una consulta escrita en un lenguaje de alto nivel en una estrategia de ejecución correcta y eficiente expresada en un lenguajede bajo nivel y ejecutar la estrategia para extraer los datos requeridos. Particularmente, para construir la respuesta a una consulta, el usuario no tiene que especificar de manera precisa elprocedimiento que se debe seguir. 


OPTIMIZACION DE CONSULTAS DISTRIBUIDAS

Para poder optimizar una consulta necesitamos tener claras las propiedades del algebra relacional para asegurar la reformulacion de la consulta, al optimizar una consulta obtenemos los siguientes beneficios:

-minimizar costos
-Reducir espacios de comunicaciones
-Seguridad en envios de informacion









El problema de optimización de consultas es altamente demandante en
tiempo de ejecución y, en el caso general, es un problema de la clase
NP. Así existen dos estrategias para su solución: búsqueda exhaustiva oel uso de heurísticas. Los algoritmos de búsqueda exhaustiva tienen una
complejidad combinatorial en el número de relaciones de la consulta.
Obtienen la transformación óptima, pero sólo se aplican a consultas
simples dado su tiempo de ejecución.


Optimización Global de Consultas
Dada una consulta algebraica sobre fragmentos, el objetivo de esta capa
es hallar una estrategia de ejecución para la consulta cercana a la
óptima. La estrategia de ejecución para una consulta distribuida puede
ser descrita con los operadores del álgebra relacional y con primitivas de
comunicación para transferir datos entre nodos. Para encontrar una
buena transformación se consideran las características de los
fragmentos, tales como, sus cardinalidades.


Optimización Local de Consultas
El trabajo de la última capa se efectúa en todos los nodos con
fragmentos involucrados en la consulta. Cada subconsulta que se ejecuta
en un nodo, llamada consulta local, es optimizada usando el esquema
local del nodo. Hasta este momento, se pueden eligen los algoritmos
para realizar las operaciones relacionales. La optimización local utiliza los
algoritmos de sistemas centralizados



viernes, 27 de marzo de 2015

Investigacion de esquema de fragmentación y distribución de una BDD

Distribución: Los componentes del sistema están localizados
en la misma computadora o en diferente computador
Los sistemas de datos distribuidos están divididos en dos clases: 

1. Sistemas de manejo de bases de datos distribuidos  homogéneos  
Los sistemas homogéneos se parece a un sistema centralizado, a
diferencia que estos sus datos se distribuyen en varios sitios
comunicados por la red. No existen usuarios locales y todos ellos
accesan la base de datos a través de una interfaz global

2. Sistemas de manejo de bases de datos distribuidos
heterogéneos 
 
 Resultado de imagen para base de datos
Un sistema multi-bases de datos tiene múltiples SMBDs, que  pueden ser de tipos diferentes, y múltiples bases de datos existentes. Existen usuarios locales y globales


El esquema de fragmentación describe la forma en que las relaciones globales se dividen entre las bases de datos locales.    

El objetivo de la fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas.
Cada relación global puede ser dividida en porciones que no se solapen llamados fragmentos. El mapa resultante se denomina esquema de fragmentación. Una relación global puede dividirse en n fragmentos y un fragmento sólo puede pertenecer a una relación global.


El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red. Inmediatamente aparece la siguiente pregunta: ¿Cuál es la unidad razonable de distribución?. Se puede considerar que una relación completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones


 Fragmentos: cada relación global puede ser dividida en porciones que no se solapen llamados fragmentos. 
El mapa resultante se denomina esquema de fragmentación. Una relación global puede dividirse en n fragmentos y un fragmento sólo puede pertenecer a una relación global. Los fragmentos se referencian por un nombre de relación global y un subíndice. Por ejemplo Ri indica el fragmento i de la relación R.
 

 El esquema de ubicación define en qué nodos un fragmento va a ser almacenado. El tipo de mapa definido en el esquema de ubicación determina si la BDD es redundante o no.

 Todos los fragmentos que corresponden a la misma relación global R y están ubicados en el mismo nodo constituyen la imagen física de una relación global R en el nodo. Las imágenes físicas se pueden referenciar por el nombre de la relación global R y un superíndice; por ejemplo, Rj indica la imagen física de la relación global R en el nodo j. se denomina copia de fragmento a la información de un fragmento en un nodo determinado en un nodo dado, y se denota usando el nombre de la relación global, un subíndice y un superíndice. Por ejemplo, R3 2 indica copia del fragmento R2 que está ubicado en el nodo 3..

http://repositorio.utn.edu.ec/bitstream/123456789/522/6/04%20ISC%20151%20CAPITULO%20IV.pdf
 

jueves, 26 de marzo de 2015

Ejericios


Problema 1


a)  Π Centro.Codigo Empleado =0

b)Π Centro U Consulta.Hora ,  (Consulta Empleados ),Consulta.Empleado,Consulta.Especialidad



Problema 2

a)   Π Empleado , Proyecto. 
b) ΠCodigo,Nombre(Empresa)
c)Proyecto.Empresa = 0 , Π Proyecto.Empresa = NULL 





lunes, 23 de marzo de 2015

Resumen 2

SISTEMA GESTOR DE BASE DE DATOS


Se considera una BDD (base de datos distribuida) a “una colección lógicamente interrelacionada de datos compartidos (junto con una descripción de estos datos) fisicamente distribuidas por una red informática”.
Un SGBDD se compone de una única base de datos lógica, que físicamente está dividida en fragmentos ubicados en nodos distintos e interconectados mediante una red de comunicaciones. Así, existirán aplicaciones locales, que solo accederán a los datos almacenados en el mismo nodo, y aplicaciones globales, que accederán a datos de varios nodos. 
 
El SGBDD ejecutará así las funciones requeridas para dar servicio a este último tipo de aplicaciones.




Además de la fragmentación, en el contexto de BDD también se habla de replicación, que consiste en mantener réplicas de fragmentos en varios nodos, según una política de replicación que va desde una replicación mínima (un fragmento replicado en otro nodo) a una replicación total (todos los fragmentos son replicados). Nuevamente el SGBDD debe garantizar la consistencia de los fragmentos que están replicados (una actualización en un fragmento debe provocar la actualización en todas sus réplicas).


Un caso de replicación son los datawarehouse: proporcionan soporte para consultas complejas para ayuda a la decisión que recurren a numerosas fuentes de datos, ya que se crea una copia de todos los datos en un mismo emplazamiento.







Bases de datos Paralela


SGBD paralelo definido como “un SGBD que se ejecuta sobre múltiples procesadores y utilizando múltiples discos y que está diseñado para ejecutar las operaciones en paralelo”,




DIFERENCIAS DE UN SGBD A SGBDP 

A veces se confunde la arquitectura de base de datos paralela sin compartición con la distribuida. Los factores que diferencian a esta última son:
1. Las bases de datos distribuidas suelen estar en lugares geográficamente distintos.
2. Se administran de forma separada.
3. Poseen una conexión más lenta.


Existen varios productos comerciales con bases de datos distribuídas, como:
• INGRES/STAR de Relational Technology, Inc.
• SQL*STAR, de Oracle Corp.
• DB2 versión 2 Edición 2, de IBM.

CATALOGO o DICCIONARIO DE DATOS. 
Por guardar información descriptiva sobre la base de datos, también es referido como metainformación. El catálogo se usa sobretodo para optimizar consultas. En una base de datos distribuida el catálogo se usa también para hacer un seguimiento de los datos distribuidos en varios sitios.



3 . Planteamiento del problema
  • Fragmentación de la base de datos original: La fragmentación debe poder ser mixta y derivada con asignación de los fragmentos a distintos nodos. La fragmentación mixta es una combinación de horizontal y vertical.
  • Horizontal se aplica cuando se extraen fragmentos por selección de tuplas que cumplan una determinada condición.
  • Fragmentación vertical se aplica cuando se extraen fragmentos por selección de atributos de todas las tuplas.
  • Fragmentación mixta se aplica a la selección de varios atributos de las tuplas que cumplan una determinada condición.
  1.  Replicación de fragmentos de la base de datos: Se debe poder indicar los fragmentos que se replican y donde se replican.
  2. Consultas optimizadas, en la cual se puedan realizar tanto consultas locales como consulta globales a varios nodos
SENTENCIAS
  • CREATE TABLE tabla AS SELECT * FROM nom-sinonimo
Esta sentencia debe ser Introducida en el nodo que se desea que se almacene el fragmento. 
  • La sintaxis para crear un procedimiento es la siguiente
CREATE [OR REPLACE] PROCEDURE name [(param [IN|OUT|IN OUT|] datatype) . . .][IS|AS] pl/sql_subprogram
  • La sentencia SQL para replicar fragmentos es la misma que el paso previo:
    CREATE TABLE tabla AS SELECT * FROM nom-esquema.nom-tabla@dblink
  • CREATE TABLE tabla AS SELECT * FROM nom-sinonimo
    La primera sentencia sin sinónimos, la segunda con sinónimos.
    Al igual que en el caso anterior, la replicación se producirá a través de la llamada a un procedimiento almacenado con el paso de parámetros:
    1. Fragmento de origen
    2. Fragmento de destino
    3. Nodo(s) donde se va a guardar
  • La creación de un fragmento replicado actualizará el catálogo distribuido, como en la creación de cualquier otro fragmento, donde la lista de atributos es * y la condición de guarda es simplemente TRUE.

  • CREATE [OR REPLACE] TRIGGER
    {BEFORE|AFTER} {DELETE|INSERT|UPDATE [OF col1, col2, . . ., colN]
    [OR {DELETE|INSERT|UPDATE [OF col1, col2, . . ., colN]. . .]}
    ON table
    [REFERENCING OLD AS oldname, NEW as newname]
    [FOR EACH ROW [WHEN (condition)]]
    pl/sql_block
  • Para implementar este tipo de replicación se van a usar los triggers ó disparadores [WENTE 1983], que son procedimientos que se ejecutan cuando ocurre un evento. En la implementación de un trigger se deben especificar las acciones que se van a realizar y opcionalmente las condiciones
  • Para realizar una consulta distribuída sencilla (que involucra una sola tabla), la sintaxis es la siguiente:
SELECT * FROM nom-esquema.nom-tabla@dblink ó
SELECT * FROM nom-sinonimo