• Author / Uploaded
• Geor Gonzalez

Citation preview

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

Profesor: Manuel Carrasquero

Integrante: 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

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 Silberschatz Editorial: MCGRAWHILL Páginas: 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