INSTITUTO TECNOLOGICO DE

AGUASCALIENTES
22-09-2015
CARRERA:
ING. TICS

DEPARTAMENTO DE CARRERA:
SISTEMAS
TEMA:

CONSIDERACIONES PARA DISTRIBUIR LA BASE DE DATOS

MATERIA:
BASE DE DATOS DISTRIBUIDAS
ALUMNO:
Martnez Martnez Sergio Antonio

NUMERO DE CONTROL:
13151570

CONSIDERACIONES QUE SE DEBEN CONSIDERAR PARA DISEAR UNA BASE

DE DATOS

DISEO DE BASE DE DATOS DISTRIBUIDAS

Existen diversas formas de afrontar el problema del diseo de la distribucin. Las ms
usuales se muestran en la figura. En el primer caso, caso A, los dos procesos
fundamentales, la fragmentacin y la asignacin, se abordan de forma simultnea. Esta
metodologa se encuentra en desuso, sustituida por el enfoque en dos fases, caso B: la
realizacin primeramente de la particin para luego asignar los fragmentos generados. El
resto de los casos se comentan en la seccin referente a los distintos tipos de la
fragmentacin.

CONSIDERACIONES PARA DISTRIBUIR LA BASE DE DATOS

Cuando planeamos una nueva base de datos, debemos tomar en consideracin algunos
aspectos, estos son algunos de ellos. Tipo de almacenamiento de datos: Debemos pensar en
qu tipo de base de datos vamos a tener, puede ser OLTP o OLAP los cuales tienen
diferentes propsitos y por lo mismo un diferente diseo.

Nivel transaccional: Las bases de datos OLTP en lo general requieren de un alto nmero
de transacciones por minuto. Un diseo eficiente, con un apropiado nivel de normalizacin,
ndices y particiones nos pueden dar un nivel transaccional muy alto.

Crecimiento de la base de datos: Las bases de datos grandes requieren de un apropiado

hardware para soportarlo, como es memoria, CPU y espacio en disco. El estimar la cantidad
de datos que la base de datos va a almacenar en los siguientes meses y aos nos va a ayudar
a mantener un nivel adecuado de performance. Podemos configurar a que la base de datos
crezca automticamente hasta un tamao mximo especificado, pero el crecimiento
automtico degrada el rendimiento. Por esa razn debemos siempre crear la base de datos
de un tamao adecuado, monitorear el espacio y solo asignar ms espacio cuando sea
realmente necesario. Con esto debemos recordar que no solo exista la fragmentacin de las
tablas, sino de la base de datos a nivel del disco, y el estar creciendo la base de datos
continuamente, genera fragmentacin que no se elimina con reindexar los ndices, sino con
otro tipo de tareas de administracin.

Archivos de Datos: Donde nosotros alojemos los archivos de datos, pueden tener un
impacto en rendimiento. Si tenemos la posibilidad de tener varios discos en nuestro
servidor, podemos distribuir los archivos de datos en ms de un solo disco. Esto permite

que SQL Server pueda tener ms conexiones mltiples y mltiples cabezas de discos para
hacer ms eficientes las lecturas y escrituras de los datos.

PROCESAMIENTO DE CONSULTAS DISTRIBUIDAS

El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL,
las caractersticas del modelo relacional permiten que cada motor de base de datos elija su
propia representacin que, comnmente, resulta ser el lgebra relacional. La optimizacin
de consultas es, entonces, una de estas etapas.

Existen distintos mtodos para optimizar consultas relacionales, sin embargo el enfoque de
optimizacin basada en costos combinado con heursticas que permitan reducir el espacio
de bsqueda de la solucin es el mtodo mayormente utilizado por los motores de base de
datos relaciones de la actualidad, en todo caso, independiente del mtodo elegido para
optimizar la consulta, la salida de este proceso debe ser un plan de ejecucin, el cual
comnmente es representado en su forma de rbol relacional.

La optimizacin de consultas en base a costos supone la utilizacin de una medida de costo

que sea comn a lo largo del proceso, esta medida debe representar el criterio de
minimizacin en la utilizacin de recursos del sistema. Este enfoque estima un costo que
estar determinado por formulas predefinidas y por la informacin del catlogo inherente a
la consulta. Sin embargo el optimizador no siempre escoge el plan ms ptimo, ya que una
bsqueda exhaustiva de la estrategia ptima puede consumir demasiado tiempo de proceso.
Se dice entonces que el optimizador escoge una estrategia razonablemente eficiente.

El catlogo de la base de datos guarda informacin estadstica de cada una de las relaciones
como tambin de los ndices de cada una de la relaciones, estas estadsticas permiten
estimar los tamaos de los resultados de varias operaciones. Esta informacin es
particularmente til cuando se dispone de ndices para auxiliar el procesamiento de la
consulta, sin embargo, la existencia de estas estructuras influencia de manera significativa
en la eleccin del plan de ejecucin de la consulta.

Una mala administracin de la informacin que contiene el catlogo conducir

inevitablemente a una desafortunada eleccin del plan de ejecucin. Para ayudar a
solucionar este problema existen varios enfoques que conjunta o separadamente pueden
asistir al optimizador en su eleccin. Uno de estos consiste en la actualizacin automtica
de las estadsticas que algunos motores de base de datos incluyen como opcin. Otro
enfoque es la opcin de guardar en el catlogo planes de ejecucin pre calculados que
adems le ahorran al motor el tiempo de clculo del plan. Obviamente estos planes son

vulnerables a ser invalidados si se producen cambios lgicos en el esquema de la base de

datos o si hay un cambio en la distribucin de los datos a ser recuperados.

Uno de los primeros optimizadores de consultas y el que se conoce como base para la
mayora de los optimizadores tradicionales es el optimizador de System R. System R es un
optimizador basado en costos pero que utiliza heursticas para desplazar selecciones y
proyecciones hacia abajo en el rbol de la consulta, la resolucin de joins se realiza
mediante el uso de rboles de profundidad por la izquierda lo que permite el uso de
evaluaciones encauzadas cuando sea posible. La estimacin de los caminos de acceso para
ndices secundarios supone que se necesita un acceso a disco por cada tupla de la relacin
lo que supone el peor caso. Es probable que la estimacin sea precisa con tamaos de
buffer pequeos, sin embargo con un buffer de mayor tamao la pgina que contiene la
tupla podra estar todava en memoria.

Las contribuciones del optimizador de system R con respecto a otras investigaciones hechas
hasta ese entonces se basan en un mejor aprovechamiento de las estadsticas del catlogo, la
inclusin de la utilizacin de CPU en las frmulas del clculo de costos y los mtodos para
determinar ordenes de join. El concepto de factor de seleccin le permite al optimizador
estimar cuantas tuplas satisfacen los predicados de antemano, el concepto de interesting
orders agrega una importancia relativa al orden en que se solicit la salida, por lo tanto
agrega un nivel de importancia a todos aquellos ordenamientos que respondan al orden
solicitado permitiendo evitar (cuando sea posible) un reordenamiento del resultado final.

El primer paso de un optimizador de consultas es encontrar una expresin del lgebra de

relaciones que sea equivalente a la expresin dada y cuyo costo estimado de ejecucin sea
menor.

Para el caso de consultas a relaciones simples se utilizar entonces la evaluacin de cada

una de las expresiones equivalentes con su evaluacin de costos para elegir el plan de
acceso a la consulta ms barato.
http://www.r-associates.com
http://www.hpjava.org