Base de Datos Trabajo
46
UNIVERSIDAD DE ORIENTE NÚCLEO ANZOÁTEGUI ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS ADMINISTRACION DE SISTEMAS DE BASE DE DATOS SECCIÓN 01 Base de Datos Distribuidas
-
Upload
geor-gonzalez -
Category
Documents
-
view
3 -
download
0
description
trabajo de base de datos manuel carrasquero
Transcript of Base de Datos Trabajo
UNIVERSIDAD DE ORIENTENÚCLEO ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADASDEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS
ADMINISTRACION DE SISTEMAS DE BASE DE DATOSSECCIÓN 01
Base de Datos Distribuidas
Profesor: Integrante:Manuel Carrasquero Georgmarys González C.I: 21.388.525
Barcelona, 27 de Julio 2015
INTRODUCCION
En la actualidad la recopilación de datos es fundamental para que las
organizaciones e instituciones puedan mantener un control de sus actividades, tener
acceso y resguardo a esta información es de vital importancia. En este sentido las
bases de datos brindan las herramientas necesarias para el debido manejo y
administración de información.
Las bases de datos son recursos que recopilan todo tipo de información, para
atender las necesidades de un amplio grupo de usuarios. Son muy variadas y se
caracterizan por una alta estructuración y estandarización de la información.
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 físico, es decir, es una base de datos almacenada en una
sola máquina y en un solo CPU.
Las bases de datos distribuidas son una colección de datos distribuidos en
diferentes nodos de una red de computadoras. Cada sitio de la red es autónomo,
puede ejecutar aplicaciones locales y al menos una aplicación 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 máquina aislada. La información 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 colección de datos que pertenecen
lógicamente a un sólo sistema, pero se encuentra físicamente 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 algún 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 físicamente en varias bases
de datos "reales" distintas ubicadas en diferentes sitios. De hecho, es la unión lógica
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
administración de transacciones (incluyendo programas de bloqueo, bitácoras,
recuperación, etc), y su propio administrador local de comunicación 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 lógico, una extensión del DBMS
local ) realiza las funciones de sociedad necesarias; y es la combinación de este nuevo
componente y el DBMS ya existente lo que constituye el llamado "sistema de
administración 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 relación.
• Autonomía 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,
también los sistemas trabajan en paralelo, lo cual permite balancear la carga en los
servidores.
• Economía - es más barato crear una red de muchas computadoras pequeñas, 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 demás sistemas (módulos).
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 diseño 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.
• Economía - 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 difícil mantener la integridad, aplicar las reglas de integridad
a través de la red puede ser muy caro en términos de transmisión de datos.
• Falta de experiencia - las bases de datos distribuidas son un campo relativamente
nuevo y poco común por lo cual no existe mucho personal con experiencia o
conocimientos adecuados.
• Carencia de estándares - aún no existen herramientas o metodologías que ayuden a
los usuarios a convertir un DBMS centralizado en un DBMS distribuido.
• Diseño de la base de datos se vuelve más complejo - además de las dificultades que
generalmente se encuentran al diseñar una base de datos, el diseño de una base de
datos distribuida debe considerar la fragmentación, replicación y ubicación de los
fragmentos en sitios específicos.
Fragmentación
El problema de fragmentación se refiere al particionamiento de
la información para distribuir cada parte a los diferentes sitios de la red
Objetivos de la fragmentación
El objetivo de la fragmentación consiste en dividir la relación en un conjunto
de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan
uso de un fragmento.
Sobre este marco, una fragmentación óptima es aquella que produce un
esquema de división que minimiza el tiempo de ejecución de las aplicaciones que
emplean esos fragmentos.
La unidad de fragmentación ideal no es la tabla sino una subdivisión 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 más "cerca" posible) a cada
aplicación, es de esperar un incremento en el rendimiento.
Si múltiples vistas de diferentes aplicaciones están definidas sobre una tabla no
fragmentada, se tiene :
Si la tabla no está replicada entonces se produce generación de tráfico por accesos
remotos.
Si la tabla está replicada en todos o algunos de los sitios donde residen cada una de
las aplicaciones entonces la generación de trafico innecesario es producida por la
necesidad de la actualización de las copias.
Ventajas
Al descomponer una relación en fragmentos (unidades de distribución):
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 paralelización de consultas al poder descomponerlas en subconsultas,
cada una de la cuales trabajará con un fragmento diferente incrementándose así el
rendimiento.
Desventajas
Degradación 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 semántico se dificulta y el rendimiento se degrada debido que la
verificación de restricciones de integridad (claves ajenas, uniques, etc) implican
buscar fragmentos en múltiples localizaciones.
Por lo tanto división y ubicación de los fragmentos no es trivial.
Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
Fragmentación horizontal
Fragmentación vertical
Fragmentación mixta
Para que una la fragmentación de una relación sea correcta debe satisfacer las
siguientes condiciones:
Condición de completitud.
La descomposición de una relación 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.
Condición de Reconstrucción.
La descomposición de una relación 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.
Condición de Fragmentos Disjuntos.
Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, y el
dato di está en Rj, entonces, no debe estar en ningún otro fragmento Rk (k?j).
Fragmentación horizontal
La fragmentación horizontal de una relación 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)
Fragmentación horizontal derivada
La Fragmentación Horizontal Primaria (FHP) de una relación se obtiene
usando predicados que están definidos en esa relación.
La Fragmentación Horizontal Derivada (FHD) por otra parte, es el
particionamiento de una relación como resultado de predicados que se definen en otra
relación.
Fragmentación vertical
La fragmentación vertical de una relación 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.
Fragmentación Mixta
Como el mismo nombre indica es una combinación de las dos anteriores vistas
he aquí un ejemplo a partir de una tabla fragmentada horizontalmente.
La Transparencia
La transparencia se define como la separación de la semántica de alto nivel de
un sistema de los aspectos de bajo nivel relacionados a la implementación del mismo.
Un nivel de transparencia adecuado permite ocultar los detalles de implementación 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 gestión de base de datos SGBD
Transparencia de transacción
Transparencia de concurrencia
Transparencia respecto a fallos
Transparencia de Sistemas de gestión de base de datos SGBD
No es necesario para el usuario saber los nombres de los fragmentos menos la
ubicación de estos, como se hace la replicación los nombres en cada uno de los
nodos.
Transparencia de fragmentación. El usuario no sabe cómo están
fragmentadas las tabla en las base de datos. El usuario no necesita
especificar el nombre de los fragmentos de las tablas.
Transparencia de la ubicación. Puede darse el caso de que el usuario
conozca cómo se encuentran fragmentadas las tablas, pero no conoce y
no es necesario que sepa la ubicación de etas.
Transparencia de la replicación. El usuario no sabe que nodos que
contienen los fragmentos son replicados, tampoco es necesario que lo
sepa para poner en funcionamiento una aplicación.
Transparencia de denominación. 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 gestión de base de datos distribuidas brindan transparencia de
concurrencia si es que las transacciones independientes son lógicas y tienen similitud
con que se puedan hacer al mismo tiempo, es decir los resultados serían los mismos
se hiciere de una sola vez.
Esto sucede con la replicación, por ejemplo, dado que este proceso es
asíncrono.
Transparencia de transacción
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 físicamente en diferentes ubicaciones – de una sola vez.
Una transacción 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 envía una sola transacción.
Transparencia respecto a fallos
Garantizar la atomicidad de la transacción, es decir mostrar los resultados si es
que todas las sub transacciones no tuvieron error, o parar todo el proceso y algún
subproceso tuvo error. Por lo tanto SGBDD debe sincronizar todas las sub
transacciones mediante la transacción global
Autonomía
Autonomía: Se puede presentar en diferentes niveles, los cuales se describen a
continuación:
Autonomía de diseño: Habilidad de un componente del sistema para decidir
cuestiones relacionadas a su propio diseño.
Autonomía de comunicación: Habilidad de un componente del sistema para decidir
cómo y cuándo comunicarse con otros SGBD (Sistema Gestor de Bases de Datos).
Autonomía de ejecución: Habilidad de un componente del sistema para ejecutar
operaciones locales como quiera.
Arquitectura de Tres Capas
El Patrón de arquitectura por capas es una de las técnicas más comunes que
los arquitectos de software utilizan para dividir sistemas de software complicados.
Al pensar en un sistema en términos 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 más alta utiliza varios servicios definidos por la
inferior, pero la última es inconsciente de la superior. Además, 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 básicos
- Se minimizan dependencias entre capas.
- Las capas posibilitan la estandarización de servicios
- Luego de tener una capa construida, puede ser utilizada por muchos servicios de
mayor nivel.
La imagen que se muestra a continuación presenta el esquema de una arquitectura
siguiendo este patrón:
A continuación se describen las tres capas principales de un patrón de arquitectura
por capas:
1. Capa de Presentación: Referente a la interacción entre el usuario y el software.
Puede ser tan simple como un menú basado en líneas de comando o tan complejo
como una aplicación basada en formas. Su principal responsabilidad es mostrar
información al usuario, interpretar los comandos de este y realizar algunas
validaciones simples de los datos ingresados.
2. Capa de Reglas de Negocio (Empresarial): También denominada Lógica de
Dominio, esta capa contiene la funcionalidad que implementa la aplicación.
Involucra cálculos basados en la información dada por el usuario y datos
almacenados y validaciones. Controla la ejecución de la capa de acceso a datos y
servicios externos. Se puede diseñar la lógica de la capa de negocios para uso directo
por parte de componentes de presentación o su encapsulamiento como servicio y
llamada a través de una interfaz de servicios que coordina la conversación con los
clientes del servicio o invoca cualquier flujo o componente de negocio.
3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas
que llevan a cabo tareas por la aplicación. Estos pueden ser monitores
transaccionales, otras aplicaciones, sistemas de mensajerías, etc. Para el caso de
aplicaciones empresariales, generalmente está representado por una base de datos,
que es responsable por el almacenamiento persistente de información. 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 Transacción (ACID)
Una transacción es una unidad lógica de trabajo o procesamiento (ejecución
de un programa que incluye operaciones de acceso a la base de datos). Una
transacción 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 también
que la transacción es una unidad lógica de integridad. Cuando múltiples 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 transacción como una unidad lógica de
concurrencia.
Cuando ocurre un fallo que provoca la caída del sistema, en el momento en el
que había varias transacciones en curso de ejecución, muy probablemente dejará
erróneos 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 transacción es considerada también una unidad lógica de
recuperación. La idea clave es que una transacción debe ser atómica, es decir, las
operaciones que la componen deben ser ejecutadas en su totalidad o no ser ejecutadas
en absoluto. Una sentencia de definición o manipulación de datos ejecutada de forma
interactiva (por ejemplo utilizar el SQL*Plus de Oracle para realizar una consulta)
puede suponer el inicio de una transacción. Asimismo, la ejecución de una sentencia
SQL por parte de un programa que no tiene ya una transacción en progreso, supone la
iniciación de una transacción. Toda transacción finaliza con una operación de commit
(confirmar) o bien con una operación de rollback (anular, abortar o revertir).
Tanto una operación como la otra puede ser de tipo explícito (si la propia
transacción (su código) contiene una sentencia COMMIT o ROLLBACK) o implícito
(si dicha operación es realizada por el sistema de forma automática, por ejemplo tras
detectar una terminación normal (éxito) o anormal (fallo) de la transacción).
Por defecto, una vez finalizada una transacción, si todas sus operaciones se
han realizado con éxito, se realiza un COMMIT implícito de dicha transacción; y si
alguna de ellas tuvo problemas, se lleva a cabo un ROLLBACK implícito de la
transacción (es decir, se deshacen todas las operaciones que había realizado hasta el
momento del fallo).
En bases de datos se denomina ACID a las características de los parámetros
que permiten clasificar las transacciones de los sistemas de gestión 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 acrónimo de Atomicity, Consistency, Isolation
and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español.
Atomicidad: Si una operación 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 sólo 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 transacción llevará a la base de
datos desde un estado válido a otro también válido. "La Integridad de la Base de
Datos nos permite asegurar que los datos son exactos y consistentes, es decir que
estén siempre intactos, sean siempre los esperados y que de ninguna manera
cambien ni se deformen. De esta manera podemos garantizar que la información
que se presenta al usuario será siempre la misma."
Aislamiento: es la propiedad que asegura que una operación no puede afectar a
otras. Esto asegura que la realización de dos transacciones sobre la misma
información sean independientes y no generen ningún tipo de error. Esta
propiedad define cómo y cuándo los cambios producidos por una operación se
hacen visibles para las demás operaciones concurrentes. El aislamiento puede
alcanzarse en distintos niveles, siendo el parámetro esencial a la hora de
seleccionar SGBDs.
Durabilidad: Persistencia. Es la propiedad que asegura que una vez realizada la
operación, é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 Recuperación del SGBD es el encargado de conseguir el
cumplimiento de las propiedades de atomicidad y durabilidad de las transacciones. La
conservación 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 Transacción
Para hacer posible el control de la concurrencia de las transacciones, así como la
recuperación del sistema tras fallos o caídas del mismo, es necesario almacenar
cuándo se inicia, termina, se confirma o se aborta cada transacción, y además qué
modificaciones de qué elementos de BD realiza cada una.
• INICIO DE TRANSACCIÓN
Operación que marca el momento en el que una transacción comienza a ejecutarse.
• LEER o ESCRIBIR
Operaciones de lectura/escritura de elementos de la base de datos, que se realizan
como parte de una transacción.
• FIN DE TRANSACCIÓN
Las operaciones de LEER y ESCRIBIR han terminado. En este punto se verifica si la
transacción debe abortarse por alguna razón (si viola el control de concurrencia, por
ejemplo), o bien si los cambios realizados por la transacción (hasta ahora en buffers
de memoria volátil) pueden aplicarse permanentemente a la base de datos en disco (es
decir, si puede realizarse una operación de CONFIRMAR (COMMIT)).
• CONFIRMAR
La transacción terminó con éxito, todos los cambios que ha realizado se pueden
confirmar sin peligro en la BD y ya no serán cancelados.
• ABORTAR
La transacción terminó sin éxito y toda actualización que ha realizado se debe
cancelar.
Algunas técnicas de recuperación necesitan operaciones adicionales como las
siguientes:
• DESHACER
Similar a ABORTAR, pero se aplica a una sola operación y no a una transacción
completa.
• REHACER
Específica que algunas de las operaciones realizadas por una transacción deben
repetirse, para asegurar que todas las operaciones realizadas por una transacción que
ha sido CONFIRMADA se hayan aplicado con éxito a la BD (es decir, los cambios
hayan quedado grabados físicamente en disco).
Estados de una Transacción
El siguiente es el diagrama de transición de estados para la ejecución de
transacciones:
Una transacción entra en el estado ACTIVA justo después de iniciar su
ejecución y, en este estado, puede realizar operaciones LEER y ESCRIBIR. Cuando
la transacción finaliza, pasa al estado PARCIALMENTE CONFIRMADA. En este
punto, el Subsistema de Control de Concurrencia puede efectuar verificaciones para
asegurar que la transacción no interfiera con otras transacciones en ejecución.
Además, el Subsistema de Recuperación puede anotar qué operaciones (qué
cambios) ha realizado que la transacción en un fichero del sistema (bitácora3), con el
objetivo de garantizar que los cambios realizados por la transacción terminada queden
permanentes, a pesar de fallos del sistema. Una vez realizadas con éxito ambas
verificaciones, la transacción ha llegado a su punto de confirmación4 y pasa al estado
CONFIRMADA (ha concluido su ejecución con éxito).
Si una de las verificaciones falla o la transacción se aborta mientras está en
estado ACTIVA, pasa al estado FALLIDA. En este caso, es posible que la
transacción deba ser cancelada (anulada, revertida, abortada) para anular los efectos
de sus operaciones ESCRIBIR sobre la BD. El estado TERMINADA indica que la
transacción ha abandonado el sistema. Las transacciones fallidas (abortadas) pueden
ser reiniciadas posteriormente, ya sea de forma automática 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 algún evento sobre
las tablas a las que se encuentra asociado. Los eventos que hacen que se ejecute un
trigger son las operaciones de inserción (INSERT), borrado (DELETE) o
actualización (UPDATE), ya que modifican los datos de una tabla.
La utilidad principal de un trigger es mejorar la administración 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 restricción, requerimiento, necesidad o
actividad especial que debe ser verificada al momento de intentar agregar, borrar o
actualizar la información 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 administración de la Base de datos, sin necesidad de
contar con que el usuario ejecute la sentencia de SQL. Además, pueden generar
valores de columnas, previene errores de datos, sincroniza tablas, modifica valores de
una vista, etc. Permite implementar programas basados en paradigma lógico (sistemas
expertos, deducción).
Componentes Principales
Llamada de activación: es la sentencia que permite "disparar" el código a
ejecutar.
Restricción: es la condición necesaria para realizar el código. Esta restricción
puede ser de tipo condicional o de tipo nulidad.
Acción 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 según 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 condición, su ejecución es única.
Pueden ser de sesión y almacenados; pero no son recomendables
Efectos y Características
No aceptan parámetros o argumentos (pero podrían 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 través de transacciones
autónomas)
Pueden causar errores de mutaciones en las tablas, si se han escrito de manera
deficiente.
Ejemplo:
Un sencillo ejemplo (para SQL Server) sería crear un Trigger para insertar un
pedido de algún producto cuando la cantidad de éste, en nuestro almacén, 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 sólo 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á vacía, 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 cuántas 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 próximos capítulos, 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 más
bien de una opción 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 más 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 cuántas 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 más opciones a la hora de definir columnas. Además
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']
[definición_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 más alto de privilegio, en el sentido de que su ámbito es el más general.
De base de datos: se refieren a bases de datos individuales, y por extensión, 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. Aún no hemos visto nada
sobre este tema, pero en MySQL se pueden almacenar procedimientos consistentes en
varias consultas SQL.
Crear Usuarios
Aunque en la versión 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
también los privilegios que tendrá. La sintaxis simplificada que usaremos para
GRANT, sin preocuparnos de temas de cifrados seguros que dejaremos ese tema para
capítulos 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 contraseña se debe introducir entre comillas de
forma obligatoria.
Un usuario 'anónimo' podrá abrir una sesión MySQL mediante una orden:
C:\mysql -h localhost -u anonimo -p
Pero no podrá hacer mucho más, 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 más que consultar algunas variables del
sistema debe tener algún privilegio. Lo más simple es conceder el privilegio para
seleccionar datos de una tabla concreta. Esto se haría así:
La misma sentencia GRANT se usa para añadir 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 sesión 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 sólo existe la base de datos 'prueba' y dentro de
esta, la tabla 'gente'. Además, podrá hacer consultas sobre esa tabla, pero no podrá
añadir 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 sólo se pueden conceder privilegios que se posean.
CONCLUSION
Las bases de datos distribuidas son cada vez más usadas por
las empresas y suponen una ventaja competitiva frente a los sistemas
centralizados, siempre y cuando la empresa en cuestión 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 máquina aislada.
El procesamiento en las bases de datos distribuidas, es el
procesamiento por el medio del cual la ejecución de las transacciones,
la recuperación y actualización de los datos se lleva a cabo entre dos ó
más computadoras independientes.
La fragmentación se refiere al particionamiento de la información para
distribuir cada parte a los diferentes sitios de la red
La transparencia se define como la separación de la semántica de alto
nivel de un sistema de los aspectos de bajo nivel relacionados a la
implementación del mismo.
En bases de datos se denomina ACID a las características de los
parámetros que permiten clasificar las transacciones de los sistemas de
gestión 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 edición Abraham SilberschatzEditorial: MCGRAWHILLPáginas: 463-505
http://www.monografias.com/trabajos82/base-datos-distribuidas/base-datos-
distribuidas2.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
