UNIVERSIDAD DE ORIENTE

NCLEO ANZOTEGUI
ESCUELA DE INGENIERA Y CIENCIAS APLICADAS
DEPARTAMENTO DE COMPUTACIN Y SISTEMAS
ADMINISTRACION DE SISTEMAS DE BASE DE DATOS
SECCIN 01

Base de Datos Distribuidas

Profesor:
Manuel Carrasquero

Integrante:
Georgmarys Gonzlez C.I: 21.388.525
Barcelona, 27 de Julio 2015

INTRODUCCION
En la actualidad la recopilacin de datos es fundamental para que las
organizaciones e instituciones puedan mantener un control de sus actividades, tener
acceso y resguardo a esta informacin es de vital importancia. En este sentido las
bases de datos brindan las herramientas necesarias para el debido manejo y
administracin de informacin.
Las bases de datos son recursos que recopilan todo tipo de informacin, para
atender las necesidades de un amplio grupo de usuarios. Son muy variadas y se
caracterizan por una alta estructuracin y estandarizacin de la informacin.
De acuerdo a su arquitectura, las bases de datos pueden ser centralizadas o
distribuidas. La base de datos centralizada es una base de datos almacenada en su
totalidad en un solo lugar fsico, es decir, es una base de datos almacenada en una
sola mquina y en un solo CPU.
Las bases de datos distribuidas son una coleccin de datos distribuidos en
diferentes nodos de una red de computadoras. Cada sitio de la red es autnomo,
puede ejecutar aplicaciones locales y al menos una aplicacin global.

BASE DE DATOS DISTRIBUIDAS

Una Base de Datos Distribuida es, una base de datos construida sobre una red
computacional y no por el contrario en una mquina aislada. La informacin que
constituye la base de datos esta almacenada en diferentes sitios en la red, y las
aplicaciones que se ejecutan accesan datos en distintos sitios.
Una Base de Datos Distribuida entonces es una coleccin de datos que pertenecen
lgicamente a un slo sistema, pero se encuentra fsicamente esparcido en varios
"sitios" de la red. Un sistema de base de datos distribuidas se compone de un
conjunto de sitios, conectados entre s mediante algn tipo de red de comunicaciones,
en el cual:
Cada sitio es un sistema de base de datos en s mismo, pero

los

sitios

han

convenido en trabajar juntos ( si es necesario ) con el fin de que un usuario de

cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como
si todos los datos estuvieran almacenados en el sitio propio del usuario.
En consecuencia, la llamada "base de datos distribuida" es en realidad una especie
de objeto virtual, cuyas partes componentes se almacenan fsicamente en varias bases
de datos "reales" distintas ubicadas en diferentes sitios. De hecho, es la unin lgica
de esas bases de datos. En otras palabras, cada sitio tiene sus propias bases de datos
"reales" locales, sus propios usuarios locales, sus propios DBMS y programas para la
administracin de transacciones (incluyendo programas de bloqueo, bitcoras,
recuperacin, etc), y su propio administrador local de comunicacin de datos
( administrador DC ). En particular un usuario dado puede realizar operaciones sobre
los datos en su propio sitio local exactamente como si ese sitio no participara en
absoluto en el sistema distribuido ( al menos, se es uno de los objetivos ). As pues,
el sistema de bases de datos distribuidas puede considerarse como una especie de

sociedad entre los DBMS individuales locales de todos los sitios. Un nuevo
componente de software en cada sitio ( en el aspecto lgico, una extensin del DBMS
local ) realiza las funciones de sociedad necesarias; y es la combinacin de este nuevo
componente y el DBMS ya existente lo que constituye el llamado "sistema de
administracin de bases de datos distribuidas" (DDBMS, distributed database
management system ).
Ventajas
Refleja una estructura organizacional - los fragmentos de la base de datos se ubican
en los departamentos a los que tienen relacin.
Autonoma local - un departamento puede controlar los datos que le pertenecen.
Disponibilidad - un fallo en una parte del sistema solo afectar a un fragmento, en
lugar de a toda la base de datos.
Rendimiento - los datos generalmente se ubican cerca del sitio con mayor demanda,
tambin los sistemas trabajan en paralelo, lo cual permite balancear la carga en los
servidores.
Economa - es ms barato crear una red de muchas computadoras pequeas, que
tener una sola computadora muy poderosa.
Modularidad - se pueden modificar, agregar o quitar sistemas de la base de datos
distribuida sin afectar a los dems sistemas (mdulos).
Desventajas
Complejidad - Se debe asegurar que la base de datos sea transparente, se debe lidiar
con varios sistemas diferentes que pueden presentar dificultades nicas. El diseo de
la base de datos se tiene que trabajar tomando en cuenta su naturaleza distribuida, por
lo cual no podemos pensar en hacer joins que afecten varios sistemas.

 Economa - la complejidad y la infraestructura necesaria implica que se necesitar

una mayor mano de obra.
Seguridad - se debe trabajar en la seguridad de la infraestructura as como cada uno
de los sistemas.
Integridad - Se vuelve difcil mantener la integridad, aplicar las reglas de integridad
a travs de la red puede ser muy caro en trminos de transmisin de datos.
Falta de experiencia - las bases de datos distribuidas son un campo relativamente
nuevo y poco comn por lo cual no existe mucho personal con experiencia o
conocimientos adecuados.
Carencia de estndares - an no existen herramientas o metodologas que ayuden a
los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
Diseo de la base de datos se vuelve ms complejo - adems de las dificultades que
generalmente se encuentran al disear una base de datos, el diseo de una base de
datos distribuida debe considerar la fragmentacin, replicacin y ubicacin de los
fragmentos en sitios especficos.

Fragmentacin
El

problema

de

fragmentacin

se

refiere

al

particionamiento

de

la informacin para distribuir cada parte a los diferentes sitios de la red

Objetivos de la fragmentacin

El objetivo de la fragmentacin consiste en dividir la relacin en un conjunto

de relaciones ms pequeas tal que algunas de las aplicaciones de usuario slo hagan
uso de un fragmento.

Sobre este marco, una fragmentacin ptima es aquella que produce un

esquema de divisin que minimiza el tiempo de ejecucin de las aplicaciones que
emplean esos fragmentos.
La unidad de fragmentacin ideal no es la tabla sino una subdivisin de sta.

Esto es debido a:

Las aplicaciones usan vistas definidas sobre varias relaciones, es decir, se

forman a partir de "trozos" de varias tablas. Si conseguimos que cada una de las
vistas est definida sobre subtablas locales (o en su defecto lo ms "cerca" posible) a
cada aplicacin, es de esperar un incremento en el rendimiento.

Si mltiples vistas de diferentes aplicaciones estn definidas sobre una tabla

no fragmentada, se tiene :

Si la tabla no est replicada entonces se produce generacin de trfico por

accesos remotos.

Si la tabla est replicada en todos o algunos de los sitios donde residen cada
una de las aplicaciones entonces la generacin de trafico innecesario es producida por
la necesidad de la actualizacin de las copias.
Ventajas

Al descomponer una relacin en fragmentos (unidades de distribucin):

Permitimos el procesamiento concurrente de transacciones ya que no se

bloquean tablas enteras sino subtablas, por lo que dos consultas pueden acceder a la
misma tabla a fragmentos distintos.

Permitimos la paralelizacin de consultas al poder descomponerlas en

subconsultas, cada una de la cuales trabajar con un fragmento diferente
incrementndose as el rendimiento.
Desventajas

Degradacin del rendimiento en vistas definidas sobre varios fragmentos

ubicados en sitios distintos (es necesario realizar operaciones con esos trozos lo cual
es costoso)

El control semntico se dificulta y el rendimiento se degrada debido que la

verificacin de restricciones de integridad (claves ajenas, uniques, etc) implican
buscar fragmentos en mltiples localizaciones.

Por lo tanto divisin y ubicacin de los fragmentos no es trivial.

Tipos de fragmentacin de datos

Existen tres tipos de fragmentacin:

Fragmentacin horizontal

Fragmentacin vertical

Fragmentacin mixta

Para que una la fragmentacin de una relacin sea correcta debe satisfacer las
siguientes condiciones:
Condicin de completitud.

La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es

completa si y solamente si cada elemento de datos en R se encuentra en alguno de los
fragmentos Ri.
Condicin de Reconstruccin.

La descomposicin de una relacin R en los fragmentos R1, R2, ..., Rn es

completa si y solamente si cada elemento de datos en R se encuentra en alguno de los
fragmentos Ri.
Condicin de Fragmentos Disjuntos.

Si la relacin R se descompone en los fragmentos R1, R2, ..., Rn, y el

dato di est en Rj, entonces, no debe estar en ningn otro fragmento Rk (k?j).
Fragmentacin horizontal

La fragmentacin horizontal de una relacin R produce una serie de

fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto de las
tuplas de R que cumplen determinadas propiedades (predicados)

Fragmentacin horizontal derivada

La Fragmentacin Horizontal Primaria (FHP) de una relacin se obtiene

usando predicados que estn definidos en esa relacin.
La Fragmentacin Horizontal Derivada (FHD) por otra parte, es el
particionamiento de una relacin como resultado de predicados que se definen en otra
relacin.
Fragmentacin vertical

La fragmentacin vertical de una relacin R produce una serie de

fragmentos R1, R2, ..., Rr cada uno de los cuales contiene un subconjunto de los
atributos de R as como la clave primaria de R.

Fragmentacin Mixta
Como el mismo nombre indica es una combinacin de las dos anteriores vistas
he aqu un ejemplo a partir de una tabla fragmentada horizontalmente.

La Transparencia
La transparencia se define como la separacin de la semntica de alto nivel de
un sistema de los aspectos de bajo nivel relacionados a la implementacin del mismo.
Un nivel de transparencia adecuado permite ocultar los detalles de implementacin a
las capas de alto nivel de un sistema y a otros usuarios.
Dentro de los principales niveles de trasparencia tenemos:
Transparencia de Sistemas de gestin de base de datos SGBD
Transparencia de transaccin
Transparencia de concurrencia

Transparencia respecto a fallos

Transparencia de Sistemas de gestin de base de datos SGBD
No es necesario para el usuario saber los nombres de los fragmentos menos la
ubicacin de estos, como se hace la replicacin los nombres en cada uno de los
nodos.

Transparencia de fragmentacin. El usuario no sabe cmo estn

fragmentadas las tabla en las base de datos. El usuario no necesita
especificar el nombre de los fragmentos de las tablas.

Transparencia de la ubicacin. Puede darse el caso de que el usuario

conozca cmo se encuentran fragmentadas las tablas, pero no conoce y
no es necesario que sepa la ubicacin de etas.

Transparencia de la replicacin. El usuario no sabe que nodos que

contienen los fragmentos son replicados, tampoco es necesario que lo
sepa para poner en funcionamiento una aplicacin.

Transparencia de denominacin. Cada elemento de la base de datos

distribuida debe tener un nombre igual en cada uno de los nodos en
que se encuentra distribuida, eso hace que el usuario manipule los
elementos como si estudiaran centralizados en una sola base de datos.

Transparencia de concurrencia
Los sistemas de gestin de base de datos distribuidas brindan transparencia de
concurrencia si es que las transacciones independientes son lgicas y tienen similitud
con que se puedan hacer al mismo tiempo, es decir los resultados seran los mismos
se hiciere de una sola vez.

Esto sucede con la replicacin, por ejemplo, dado que este proceso es
asncrono.
Transparencia de transaccin
Se garantiza que todas las transacciones mantengan la integridad y coherencia
de datos de la base de datos distribuida, es decir en todos sus nodos y fragmentos. Por
ejemplo se puede utilizar todos los fragmentos de una tabla estos fragmentos
pueden estar fsicamente en diferentes ubicaciones de una sola vez.
Una transaccin internamente est dividida en sub transacciones para ocupar
cada uno de los nodos que contengan los datos que se requiere, esto no es visible para
el usuario. Este, simplemente enva una sola transaccin.
Transparencia respecto a fallos
Garantizar la atomicidad de la transaccin, es decir mostrar los resultados si es
que todas las sub transacciones no tuvieron error, o parar todo el proceso y algn
subproceso tuvo error. Por lo tanto SGBDD debe sincronizar todas las sub
transacciones mediante la transaccin global

Autonoma
Autonoma: Se puede presentar en diferentes niveles, los cuales se describen a
continuacin:
Autonoma de diseo: Habilidad de un componente del sistema para decidir
cuestiones relacionadas a su propio diseo.

Autonoma de comunicacin: Habilidad de un componente del sistema para decidir

cmo y cundo comunicarse con otros SGBD (Sistema Gestor de Bases de Datos).
Autonoma de ejecucin: Habilidad de un componente del sistema para ejecutar
operaciones locales como quiera.

Arquitectura de Tres Capas

El Patrn de arquitectura por capas es una de las tcnicas ms comunes que
los arquitectos de software utilizan para dividir sistemas de software complicados.
Al pensar en un sistema en trminos de capas, se imaginan los principales
subsistemas de software ubicados de la misma forma que las capas de un pastel,
donde cada capa descansa sobre la inferior.
En este esquema la capa ms alta utiliza varios servicios definidos por la
inferior, pero la ltima es inconsciente de la superior. Adems, normalmente cada
capa oculta las capas inferiores de las siguientes superiores a esta.
Los beneficios de trabajar un sistema en capas son:
- Se puede entender una capa como un todo, sin considerar las otras.
- Las capas se pueden sustituir con implementaciones alternativas de los mismos
servicios bsicos
- Se minimizan dependencias entre capas.
- Las capas posibilitan la estandarizacin de servicios
- Luego de tener una capa construida, puede ser utilizada por muchos servicios de
mayor nivel.

La imagen que se muestra a continuacin presenta el esquema de una arquitectura

siguiendo este patrn:
A continuacin se describen las tres capas principales de un patrn de arquitectura por
capas:

1. Capa de Presentacin: Referente a la interaccin entre el usuario y el software.

Puede ser tan simple como un men basado en lneas de comando o tan complejo
como una aplicacin basada en formas. Su principal responsabilidad es mostrar
informacin al usuario, interpretar los comandos de este y realizar algunas
validaciones simples de los datos ingresados.
2. Capa de Reglas de Negocio (Empresarial): Tambin denominada Lgica de
Dominio, esta capa contiene la funcionalidad que implementa la aplicacin.
Involucra clculos basados en la informacin dada por el usuario y datos
almacenados y validaciones. Controla la ejecucin de la capa de acceso a datos y
servicios externos. Se puede disear la lgica de la capa de negocios para uso directo

por parte de componentes de presentacin o su encapsulamiento como servicio y

llamada a travs de una interfaz de servicios que coordina la conversacin con los
clientes del servicio o invoca cualquier flujo o componente de negocio.
3. Capa de Datos: Esta capa contiene la lgica de comunicacin con otros sistemas
que llevan a cabo tareas por la aplicacin.

Estos pueden ser monitores

transaccionales, otras aplicaciones, sistemas de mensajeras, etc. Para el caso de

aplicaciones empresariales, generalmente est representado por una base de datos,
que es responsable por el almacenamiento persistente de informacin. Esta capa debe
abstraer completamente a las capas superiores (negocio) del dialecto utilizado para
comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.).

Procesamiento de Transaccin (ACID)

Una transaccin es una unidad lgica de trabajo o procesamiento (ejecucin
de un programa que incluye operaciones de acceso a la base de datos). Una
transaccin es una secuencia de operaciones que llevan la base de datos desde un
estado de consistencia1 a otro estado de consistencia, por esto suele decirse tambin
que la transaccin es una unidad lgica de integridad. Cuando mltiples transacciones
son introducidas en el sistema por varios usuarios, es necesario evitar que interfieran
entre ellas de forma tal que provoquen que la BD quede en un estado no consistente;
desde este punto de vista, podemos ver una transaccin como una unidad lgica de
concurrencia.
Cuando ocurre un fallo que provoca la cada del sistema, en el momento en el
que haba varias transacciones en curso de ejecucin, muy probablemente dejar
errneos los datos en la BD (estado inconsistente); en estas circunstancias, se debe
garantizar que la BD pueda ser recuperada a un estado en el cual su contenido sea

consistente, por esto una transaccin es considerada tambin una unidad lgica de
recuperacin. La idea clave es que una transaccin debe ser atmica, es decir, las
operaciones que la componen deben ser ejecutadas en su totalidad o no ser ejecutadas
en absoluto. Una sentencia de definicin o manipulacin de datos ejecutada de forma
interactiva (por ejemplo utilizar el SQL*Plus de Oracle para realizar una consulta)
puede suponer el inicio de una transaccin. Asimismo, la ejecucin de una sentencia
SQL por parte de un programa que no tiene ya una transaccin en progreso, supone la
iniciacin de una transaccin. Toda transaccin finaliza con una operacin de commit
(confirmar) o bien con una operacin de rollback (anular, abortar o revertir).
Tanto una operacin como la otra puede ser de tipo explcito (si la propia
transaccin (su cdigo) contiene una sentencia COMMIT o ROLLBACK) o implcito
(si dicha operacin es realizada por el sistema de forma automtica, por ejemplo tras
detectar una terminacin normal (xito) o anormal (fallo) de la transaccin).
Por defecto, una vez finalizada una transaccin, si todas sus operaciones se
han realizado con xito, se realiza un COMMIT implcito de dicha transaccin; y si
alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implcito de la
transaccin (es decir, se deshacen todas las operaciones que haba realizado hasta el
momento del fallo).
En bases de datos se denomina ACID a las caractersticas de los parmetros
que permiten clasificar las transacciones de los sistemas de gestin de bases de datos.
Cuando se dice que es ACID compliant se indica -en diversos grados- que ste
permite realizar transacciones.
En

concreto ACID

es

un

acrnimo

de Atomicity, Consistency, Isolation

and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en espaol.

Atomicidad: Si una operacin consiste en una serie de pasos, todos ellos

ocurren o ninguno, es decir, las transacciones son completas.

Consistencia: Integridad. Es la propiedad que asegura que slo se empieza

aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no
van a romper las reglas y directrices de Integridad de la base de datos. La
propiedad de consistencia sostiene que cualquier transaccin llevar a la base de
datos desde un estado vlido a otro tambin vlido. "La Integridad de la Base de
Datos nos permite asegurar que los datos son exactos y consistentes, es decir que
estn siempre intactos, sean siempre los esperados y que de ninguna manera
cambien ni se deformen. De esta manera podemos garantizar que la informacin
que se presenta al usuario ser siempre la misma."

Aislamiento: es la propiedad que asegura que una operacin no puede afectar

a otras. Esto asegura que la realizacin de dos transacciones sobre la misma
informacin sean independientes y no generen ningn tipo de error. Esta
propiedad define cmo y cundo los cambios producidos por una operacin se
hacen visibles para las dems operaciones concurrentes. El aislamiento puede
alcanzarse en distintos niveles, siendo el parmetro esencial a la hora de
seleccionar SGBDs.

Durabilidad: Persistencia. Es la propiedad que asegura que una vez realizada

la operacin, sta persistir y no se podr deshacer aunque falle el sistema y que
de esta forma los datos sobrevivan de alguna manera.

El Subsistema de Recuperacin del SGBD es el encargado de conseguir el

cumplimiento de las propiedades de atomicidad y durabilidad de las transacciones. La
conservacin de la consistencia es una propiedad cuyo cumplimiento han de asegurar,
por un lado los programadores de base de datos, y por otro el Subsistema de

Integridad del SGBD. El Subsistema de Control de Concurrencia es el encargado de

conseguir el aislamiento de las transacciones
Operaciones de una Transaccin
Para hacer posible el control de la concurrencia de las transacciones, as como la
recuperacin del sistema tras fallos o cadas del mismo, es necesario almacenar
cundo se inicia, termina, se confirma o se aborta cada transaccin, y adems qu
modificaciones de qu elementos de BD realiza cada una.
INICIO DE TRANSACCIN
Operacin que marca el momento en el que una transaccin comienza a ejecutarse.
LEER o ESCRIBIR
Operaciones de lectura/escritura de elementos de la base de datos, que se realizan
como parte de una transaccin.
FIN DE TRANSACCIN
Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si la
transaccin debe abortarse por alguna razn (si viola el control de concurrencia, por
ejemplo), o bien si los cambios realizados por la transaccin (hasta ahora en buffers
de memoria voltil) pueden aplicarse permanentemente a la base de datos en disco (es
decir, si puede realizarse una operacin de CONFIRMAR (COMMIT)).
CONFIRMAR
La transaccin termin con xito, todos los cambios que ha realizado se pueden
confirmar sin peligro en la BD y ya no sern cancelados.
ABORTAR

La transaccin termin sin xito y toda actualizacin que ha realizado se debe

cancelar.
Algunas tcnicas de recuperacin necesitan operaciones adicionales como las
siguientes:
DESHACER
Similar a ABORTAR, pero se aplica a una sola operacin y no a una transaccin
completa.
REHACER
Especfica que algunas de las operaciones realizadas por una transaccin deben
repetirse, para asegurar que todas las operaciones realizadas por una transaccin que
ha sido CONFIRMADA se hayan aplicado con xito a la BD (es decir, los cambios
hayan quedado grabados fsicamente en disco).
Estados de una Transaccin
El siguiente es el diagrama de transicin de estados para la ejecucin de
transacciones:

Una transaccin entra en el estado ACTIVA justo despus de iniciar su

ejecucin y, en este estado, puede realizar operaciones LEER y ESCRIBIR. Cuando
la transaccin finaliza, pasa al estado PARCIALMENTE CONFIRMADA. En este
punto, el Subsistema de Control de Concurrencia puede efectuar verificaciones para
asegurar que la transaccin no interfiera con otras transacciones en ejecucin.
Adems, el Subsistema de Recuperacin puede anotar qu operaciones (qu
cambios) ha realizado que la transaccin en un fichero del sistema (bitcora3), con el
objetivo de garantizar que los cambios realizados por la transaccin terminada queden
permanentes, a pesar de fallos del sistema. Una vez realizadas con xito ambas
verificaciones, la transaccin ha llegado a su punto de confirmacin4 y pasa al estado
CONFIRMADA (ha concluido su ejecucin con xito).
Si una de las verificaciones falla o la transaccin se aborta mientras est en
estado ACTIVA, pasa al estado FALLIDA. En este caso, es posible que la transaccin
deba ser cancelada (anulada, revertida, abortada) para anular los efectos de sus
operaciones ESCRIBIR sobre la BD. El estado TERMINADA indica que la
transaccin ha abandonado el sistema. Las transacciones fallidas (abortadas) pueden

ser reiniciadas posteriormente, ya sea de forma automtica por parte del sistema, o
bien sea el usuario el que las reintroduzca como si fueran nuevas transacciones

Tiggers o Disparadores (SQL)

Los Triggers o Disparadores son objetos que se asocian con tablas y se
almacenan en la base de datos. Su nombre se deriva por el comportamiento que
presentan en su funcionamiento, ya que se ejecutan cuando sucede algn evento sobre
las tablas a las que se encuentra asociado. Los eventos que hacen que se ejecute un
trigger son las operaciones de insercin (INSERT), borrado (DELETE) o
actualizacin (UPDATE), ya que modifican los datos de una tabla.
La utilidad principal de un trigger es mejorar la administracin de la base de
datos, ya que no requieren que un usuario los ejecute. Por lo tanto, son empleados
para implementar las REGLAS DE NEGOCIO (tipo especial de integridad) de una
base de datos.
Una Regla de Negocio es cualquier restriccin, requerimiento, necesidad o
actividad especial que debe ser verificada al momento de intentar agregar, borrar o
actualizar la informacin de una base de datos. Un trigger puede prevenir errores en
los datos, modificar valores de una vista, sincronizar tablas, entre otros.
Usos
Son usados para mejorar la administracin de la Base de datos, sin necesidad de
contar con que el usuario ejecute la sentencia de SQL. Adems, pueden generar
valores de columnas, previene errores de datos, sincroniza tablas, modifica valores de

una vista, etc. Permite implementar programas basados en paradigma lgico (sistemas
expertos, deduccin).

Componentes Principales
Llamada de activacin: es la sentencia que permite "disparar" el cdigo a

ejecutar.
Restriccin: es la condicin necesaria para realizar el cdigo. Esta restriccin

puede ser de tipo condicional o de tipo nulidad.

Accin a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se

han cumplido las condiciones iniciales.

Tipos
Existen dos tipos de disparadores que se clasifican segn la cantidad de
ejecuciones a realizar:

Row Triggers (o Disparadores de fila): son aquellas que se ejecutaran cada

vez que se llama al disparador desde la tabla asociada al trigger

Statement Triggers (o Disparadores de secuencia): son aquellos que sin

importar la cantidad de veces que se cumpla con la condicin, su ejecucin es
nica.

Pueden ser de sesin y almacenados; pero no son recomendables

Efectos y Caractersticas

No aceptan parmetros o argumentos (pero podran almacenar los datos

afectados en tablas temporales)

No pueden ejecutar las operaciones COMMIT o ROLLBACK porque estas son

parte de la sentencia SQL del disparador (nicamente a travs de transacciones
autnomas)

Pueden causar errores de mutaciones en las tablas, si se han escrito de manera

deficiente.

Ejemplo:
Un sencillo ejemplo (para SQL Server) sera crear un Trigger para insertar un
pedido de algn producto cuando la cantidad de ste, en nuestro almacn, sea inferior
a un valor dado.
CREATE TRIGGER TR_ARTICULO ON ARTICULOS AFTER UPDATE AS
BEGIN INSERT INTO HCO_ARTICULO (IDARTICULO, STOCK, FECHA)
SELECT ID_ARTICULO, STOCK, GETDATE() FROM INSERTED END
INSERT INTO ARTICULOS VALUES (1, 'MEMORIA', 12, '12/03/2014')
SELECT * FROM ARTICULOS
UPDATE ARTICULOS SET STOCK = STOCK - 20 WHERE ID_ARTICULO = 1
SELECT * FROM HCO_ARTICULO
</source>

Como crear una Base de datos en MYSQL

Cada conjunto de relaciones que componen un modelo completo forma una

base de datos. Desde el punto de vista de SQL, una base de datos es slo un conjunto
de relaciones (o tablas), y para organizarlas o distinguirlas se accede a ellas mediante
su nombre. A nivel de sistema operativo, cada base de datos se guarda en un
directorio diferente.
Debido a esto, crear una base de datos es una tarea muy simple. Claro que, en
el momento de crearla, la base de datos estar vaca, es decir, no contendr ninguna
tabla.
Vamos a crear y manipular nuestra propia base de datos, al tiempo que nos
familiarizamos con la forma de trabajar de MySQL.
Para empezar, crearemos una base de datos para nosotros solos, y la
llamaremos "prueba". Para crear una base de datos se usa una sentencia CREATE
DATABASE:

mysql> CREATE DATABASE prueba;

Query OK, 1 row affected (0.03 sec)
mysql>

Podemos averiguar cuntas bases de datos existen en nuestro sistema usando

la sentencia SHOW DATABASES:

mysql> SHOW DATABASES;

+--------------------+
| Database
|
+--------------------+
| mysql
|
| prueba
|
| test
|

+--------------------+
3 rows in set (0.00 sec)
mysql>

A partir de ahora, en los prximos captulos, trabajaremos con esta base de

datos, por lo tanto la seleccionaremos como base de datos por defecto. Esto nos
permitir obviar el nombre de la base de datos en consultas. Para seleccionar una base
de datos se usa el comando USE, que no es exactamente una sentencia SQL, sino ms
bien de una opcin de MySQL:

mysql> USE prueba;

Database changed
mysql>

Crear una tabla

Veamos ahora la sentencia CREATE TABLE que sirve para crear tablas. La
sintaxis de esta sentencia es muy compleja, ya que existen muchas opciones y
tenemos muchas posibilidades diferentes a la hora de crear una tabla. Las iremos
viendo paso a paso, y en poco tiempo sabremos usar muchas de sus posibilidades.
En su forma ms simple, la sentencia CREATE TABLE crear una tabla con
las columnas que indiquemos. Crearemos, como ejemplo, una tabla que nos permitir
almacenar nombres de personas y sus fechas de nacimiento. Deberemos indicar el
nombre de la tabla y los nombres y tipos de las columnas:

mysql> USE prueba

Database changed

mysql> CREATE TABLE gente (nombre VARCHAR(40), fecha DATE);

Query OK, 0 rows affected (0.53 sec)
mysql>

Hemos creado una tabla llamada "gente" con dos columnas: "nombre" que
puede contener cadenas de hasta 40 caracteres y "fecha" de tipo fecha.
Podemos consultar cuntas tablas y qu nombres tienen en una base de datos,
usando la sentencia SHOW TABLES:

mysql> SHOW TABLES;

+------------------+
| Tables_in_prueba |
+------------------+
| gente
|
+------------------+
1 row in set (0.01 sec)
mysql>

Pero tenemos muchas ms opciones a la hora de definir columnas. Adems del

tipo y el nombre, podemos definir valores por defecto, permitir o no que contengan
valores nulos, crear una clave primaria, indexar...
La sintaxis para definir columnas es:

nombre_col tipo [NOT NULL | NULL] [DEFAULT valor_por_defecto]

[AUTO_INCREMENT] [[PRIMARY] KEY] [COMMENT 'string']
[definicin_referencia]

Niveles de Privilegios
En MySQL existen cinco niveles distintos de privilegios:
Globales: se aplican al conjunto de todas las bases de datos en un servidor. Es el
nivel ms alto de privilegio, en el sentido de que su mbito es el ms general.
De base de datos: se refieren a bases de datos individuales, y por extensin, a todos
los objetos que contiene cada base de datos.
De tabla: se aplican a tablas individuales, y por lo tanto, a todas las columnas de esas
tabla.
De columna: se aplican a una columna en una tabla concreta.
De rutina: se aplican a los procedimientos almacenados. An no hemos visto nada
sobre este tema, pero en MySQL se pueden almacenar procedimientos consistentes en
varias consultas SQL.

Crear Usuarios
Aunque en la versin 5.0.2 de MySQL existe una sentencia para crear
usuarios, CREATE USER, en versiones anteriores se usa exclusivamente la sentencia
GRANT para crearlos.
En general es preferible usar GRANT, ya que si se crea un usuario mediante
CREATE USER, posteriormente hay que usar una sentencia GRANT para concederle
privilegios.
Usando GRANT podemos crear un usuario y al mismo tiempo concederle
tambin los privilegios que tendr. La sintaxis simplificada que usaremos para

GRANT, sin preocuparnos de temas de cifrados seguros que dejaremos ese tema para
captulos avanzados, es:

GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ...

ON
TO user [IDENTIFIED BY [PASSWORD] 'password']
[, user [IDENTIFIED BY [PASSWORD] 'password']] ...

La primera parte priv_type [(column_list)] permite definir el tipo de privilegio

concedido para determinadas columnas. La segunda ON {tbl_name | * | *.* |
db_name.*}, permite conceder privilegios en niveles globales, de base de datos o de
tablas.
Para crear un usuario sin privilegios usaremos la sentencia:

mysql> GRANT USAGE ON *.* TO anonimo IDENTIFIED BY 'clave';

Query OK, 0 rows affected (0.02 sec)

Hay que tener en cuenta que la contrasea se debe introducir entre comillas de
forma obligatoria.
Un usuario 'annimo' podr abrir una sesin MySQL mediante una orden:

C:\mysql -h localhost -u anonimo -p

Pero no podr hacer mucho ms, ya que no tiene privilegios. No tendr, por
ejemplo, oportunidad de hacer selecciones de datos, de crear bases de datos o tablas,
insertar datos, etc.

Conceder privilegios

Para que un usuario pueda hacer algo ms que consultar algunas variables del
sistema debe tener algn privilegio. Lo ms simple es conceder el privilegio para
seleccionar datos de una tabla concreta. Esto se hara as:
La misma sentencia GRANT se usa para aadir privilegios a un usuario
existente.

mysql> GRANT SELECT ON prueba.gente TO anonimo;

Query OK, 0 rows affected (0.02 sec)

Esta sentencia concede al usuario 'anonimo' el privilegio de ejecutar

sentencias SELECT sobre la tabla 'gente' de la base de datos 'prueba'.
Un usuario que abra una sesin y se identifique como 'anonimo' podr ejecutar
estas sentencias:

mysql> SHOW DATABASES;

+----------+
| Database |
+----------+
| prueba
|
+----------+
1 row in set (0.01 sec)
mysql> USE prueba;
Database changed
mysql> SHOW TABLES;
+------------------+
| Tables_in_prueba |
+------------------+
| gente
|
+------------------+
1 row in set (0.00 sec)
mysql> SELECT * FROM gente;

+----------+------------+
| nombre
| fecha
|
+----------+------------+
| Fulano
| 1985-04-12 |
| Mengano | 1978-06-15 |
| Tulano
| 2001-12-02 |
| Pegano
| 1993-02-10 |
| Pimplano | 1978-06-15 |
| Frutano | 1985-04-12 |
+----------+------------+
6 rows in set (0.05 sec)
mysql>

Como se ve, para este usuario slo existe la base de datos 'prueba' y dentro de
esta, la tabla 'gente'. Adems, podr hacer consultas sobre esa tabla, pero no podr
aadir ni modificar datos, ni por supuesto, crear o destruir tablas ni bases de datos.
Para conceder privilegios globales se usa ON *.*, para indicar que los privilegios se
conceden en todas las tablas de todas las bases de datos.
Para conceder privilegios en bases de datos se usa ON nombre_db.*,
indicando que los privilegios se conceden sobre todas las tablas de la base de datos
'nombre_db'.
Usando ON nombre_db.nombre_tabla, concedemos privilegios de nivel de
tabla para la tabla y base de datos especificada. En cuanto a los privilegios de
columna, para concederlos se usa la sintaxis tipo_privilegio (lista_de_columnas),
[tipo_privilegio (lista_de_columnas)].
Otros privilegios que se pueden conceder son:
ALL: para conceder todos los privilegios.
CREATE: permite crear nuevas tablas.
DELETE: permite usar la sentencia DELETE.

DROP: permite borrar tablas.

INSERT: permite insertar datos en tablas.
UPDATE: permite usar la sentencia UPDATE.
Para ver una lista de todos los privilegios existentes consultar la sintaxis de la
sentencia GRANT. Se pueden conceder varios privilegios en una nica sentencia. Por
ejemplo:
mysql> GRANT SELECT, UPDATE ON prueba.gente TO anonimo IDENTIFIED
BY 'clave';
Query OK, 0 rows affected (0.22 sec)
mysql>

Un detalle importante es que para crear usuarios se debe tener el privilegio

GRANT OPTION, y que slo se pueden conceder privilegios que se posean.

CONCLUSION

Las bases de datos distribuidas son cada vez ms usadas por

las empresas y suponen una ventaja competitiva frente a los sistemas
centralizados, siempre y cuando la empresa en cuestin tenga
necesidad de usar una base de datos de este tipo.

Una Base de Datos Distribuida es, una base de datos construida sobre
una red computacional y no por el contrario en una mquina aislada.

El procesamiento en las bases de datos distribuidas, es el

procesamiento por el medio del cual la ejecucin de las transacciones,
la recuperacin y actualizacin de los datos se lleva a cabo entre dos
ms computadoras independientes.

La fragmentacin se refiere al particionamiento de la informacin para

distribuir cada parte a los diferentes sitios de la red

La transparencia se define como la separacin de la semntica de alto

nivel de un sistema de los aspectos de bajo nivel relacionados a la
implementacin del mismo.

En bases de datos se denomina ACID a las caractersticas de los

parmetros que permiten clasificar las transacciones de los sistemas de
gestin de bases de datos (Atomicidad, Consistencia, Aislamiento y
Durabilidad).

Los Triggers o Disparadores son objetos que se asocian con tablas y se

almacenan en la base de datos.

BIBLIOGRAFIA
FUNDAMENTOS DE BASES DE DATOS
Cuarta edicin
Abraham Silberschatz
Editorial: MCGRAWHILL
Pginas: 463-505

http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datosdistribuidas2.shtml#ixzz3h3B7FY5W
http://amazonasopina.blogspot.com/2012/09/la-transparencia-en-las-bases-de
datos.html
http://wwwefrainguerrero.blogspot.com/2012/06/arquitectura-en-tres-capas.html
http://www.grch.com.ar/docs/bd/apuntes/BDTema06.pdf
http://mysql.conclase.net/curso/?cap=013#
http://mysql.conclase.net/curso/?cap=007