Taller De Bases De

Datos

Investigacin
Unidad 4
Firmado digitalmente
por Irak Bernal
Fecha: 2017.11.21
23:47:44 -06'00'

Atzikan Irak Estrada Bernal

Ivn Azamar Palma

21 de noviembre de 2017
 Taller de Bases de Datos 2

Contenido

Antecedentes histricos. ................................................................................................................................ 2

Aplicaciones. .................................................................................................................................................. 2

4 Concurrencia.................................................................................................................................................... 3

4.1 Conceptos. ............................................................................................................................................... 3

4.2 Propiedades de las transacciones. .......................................................................................................... 3

4.3 Grados de consistencia. ........................................................................................................................... 4

4.4 Niveles de aislamiento. ............................................................................................................................ 4

tabla 1.1 comportamientos permitidos ....................................................................................................... 5

4.5 Commit y rollback ..................................................................................................................................... 5

Tabla 1.2 instrucciones de commit y rollback ............................................................................................ 5

Ejercicio explicado. ........................................................................................................................................ 5

Conclusin. .................................................................................................................................................... 6

Bibliografa ..................................................................................................................................................... 6

Antecedentes histricos.
Al principio de los aos setenta, los laboratorios de investigacin Santa Teresa de IBM empezaron a
trabajar en el proyecto System R. El objetivo de este proyecto era implementar un prototipo de SGBD
relacional; por lo tanto, tambin necesitaban investigar en el campo de los lenguajes de bases de
datos relacionales. A mediados de los aos setenta, el proyecto de IBM dio como resultado un primer
lenguaje denominado SEQUEL (Structured English Query Language), que por razones legales se
denomin ms adelante SQL (Structured Query Language). Al final de la dcada de los setenta y al
principio de la de los ochenta, una vez finalizado el proyecto System R, IBM y otras empresas
empezaron a utilizar el SQL en sus SGBD relacionales, con lo que este lenguaje adquiri una gran
popularidad. En 1982, ANSI (American National Standards Institute) encarg a uno de sus comits
(X3H2) la definicin de un lenguaje de bases de datos relacionales. Este comit, despus de evaluar
diferentes lenguajes, y ante la aceptacin comercial del SQL, eligi un lenguaje estndar que estaba
basado en ste prcticamente en su totalidad. El SQL se convirti oficialmente en el lenguaje
estndar de ANSI en el ao 1986, y de ISO (International Standards Organization) en 1987. Tambin
ha sido adoptado como lenguaje estndar por FIPS (Federal Information Processing Standard), Unix
X/Open y SAA (Systems Application Architecture) de IBM. En el ao 1989, el estndar fue objeto de
una revisin y una ampliacin que dieron lugar al lenguaje que se conoce con el nombre de SQL1 o
SQL89. En el ao 1992 el estndar volvi a ser revisado y ampliado considerablemente para cubrir
carencias de la versin anterior. Esta nueva versin del SQL, que se conoce con el nombre de SQL2
o SQL92.

Aplicaciones.
Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus aplicaciones ms
representativas: Banca. Para informacin de los clientes, cuentas y prstamos, y transacciones
bancarias. Lneas areas. Para reservas e informacin de planificacin. Las lneas areas fueron de

Irak Bernal
 Taller de Bases de Datos 3

los primeros en usar las bases de datos de forma distribuida geogrficamente. Universidades. Para
informacin de los estudiantes, matrculas de las asignaturas y cursos. Transacciones de tarjetas de
crdito. Para compras con tarjeta de crdito y generacin mensual de extractos.
Telecomunicaciones. Para guardar un registro de las llamadas realizadas, generacin mensual de
facturas, manteniendo el saldo de las tarjetas telefnicas de prepago y para almacenar informacin
sobre las redes de comunicaciones. Finanzas. Para almacenar informacin sobre grandes
empresas, ventas y compras de documentos formales financieros, como bolsa y bonos. Ventas. Para
informacin de clientes, productos y compras. Produccin. Para la gestin de la cadena de
produccin y para el seguimiento de la produccin de elementos en las factoras, inventarios de
elementos en almacenes y pedidos de elementos. Recursos humanos. Para informacin sobre los
empleados, salarios, impuestos y beneficios, y para la generacin de las nminas.

4 Concurrencia
4.1 Conceptos.
Los SGBD son sistemas concurrentes, admiten la ejecucin concurrente de consultas. Por tanto, es
necesario un modelo de procesos concurrentes para admitir operaciones concurrentes que
preserven la integridad de los datos. El concepto de transaccin se desarroll para atender los casos
en los que el estado resultante de la base de datos depende del xito completo en una serie de
operaciones. Este concepto vio la luz debido a que varias operaciones sucesivas pueden modificar
el resultado de operaciones anteriores. En esos casos, si alguna operacin produce un error, el
estado resultante puede ser indeterminado. Para solucionar este problema, las transacciones
agrupan una serie de operaciones de manera que es posible garantizar la integridad del resultado
final. O todas las operaciones se ejecutan con xito y se confirman (se escriben en la base de datos),
o toda la transaccin se considera no realizada. La accin de cancelar una transaccin se denomina
deshacer la transaccin. Deshacer una transaccin permite anular los cambios y recuperar el estado
de la base de datos previo a la transaccin. Por ejemplo, en una transaccin bancaria, si un banco
transfiere dinero desde la cuenta X a la cuenta Y, la retirada de fondos de X y el depsito en Y deben
producirse con xito para procesar los fondos correctamente, de lo contrario la transaccin entera
debe cancelarse.

4.2 Propiedades de las transacciones.

Atomicidad (Atomicity).
Una transaccin tiene que ser atmica lo que significa que es indivisible; todas las operaciones
deben ejecutarse o ninguna en lo absoluto. No debe haber posibilidad de que solo una parte se
ejecute. La atomicidad se garantiza a travs de mecanismos de base de datos con los que se hace
el seguimiento de la transaccin. Si la transaccin falla por cualquier razn, las actualizaciones que
se hayan realizado hasta el momento sern deshechas.
Consistencia (Consistency).
Una transaccin mantendr la consistencia de la base de datos. Esto es, si la base de datos se
encuentra en un estado consistente antes de ejecutar la transaccin, una vez que sta termine la
consistencia de la base de datos deber conservarse.
Aislamiento (Isolation).
Se dice que un conjunto de transacciones est aislado si el efecto del sistema que las ejecuta es el
mismo que si ejecutara cada una a la vez; las transacciones se ejecutan en secuencia. La base de
datos tpicamente usa tcnicas de bloqueo y control de filas en los datos que cada transaccin
accede. El efecto de esto es hacer que la ejecucin parezca en serie, aunque, internamente, el
sistema ejecuta las transacciones en paralelo.
Durabilidad (Durability).
Cuando una transaccin termina de ejecutarse, todas susactualizaciones se graban en algn tipo de
medio de almacenamiento, tpicamente disco, en donde se asegura que las actualizaciones no se
perdern. Aun si el sistema operativo falla, los resultados de la transaccin son almacenados en
disco y podrn ser encontrados ah cuando se recupere el sistema operativo. Ms an, la
durabilidad a menudo debe mantenerse por un periodo largo.

Irak Bernal
 Taller de Bases de Datos 4

4.3 Grados de consistencia.

Consistencia es un trmino ms amplio que el de integridad. Podra definirse como la coherencia
entre todos los datos de la base de datos. Cuando se pierde la integridad tambin se pierde la
consistencia. Pero la consistencia tambin puede perderse por razones de funcionamiento.
Una transaccin finalizada (confirmada parcialmente) puede no confirmarse definitivamente
(consistencia).
Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha
efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.
La ejecucin de una transaccin debe conducir a un estado de la base de datos consistente (que
cumple todas las restricciones de integridad definidas).
Si se confirma definitivamente el sistema asegura la persistencia de los cambios que ha
efectuado en la base de datos.
Si se anula los cambios que ha efectuado son deshechos.
Una transaccin que termina con xito se dice que est comprometida (commited), una transaccin
que haya sido comprometida llevar a la base de datos a un nuevo estado consistente que debe
permanecer incluso si hay un fallo en el sistema. En cualquier momento una transaccin slo puede
estar en uno de los siguientes estados.
Activa (Active): el estado inicial; la transaccin permanece en este estado durante su
ejecucin.
Parcialmente comprometida (Uncommited): Despus de ejecutarse la ltima transaccin.
Fallida (Failed): tras descubrir que no se puede continuar la ejecucin normal.
Abortada (Rolled Back): despus de haber retrocedido la transaccin y restablecido la base
de datos a su estado anterior al comienzo de la transaccin.
Comprometida (Commited): tras completarse con xito.

4.4 Niveles de aislamiento.

Read-uncommitted (lectura no comprometida): La ejecucin de la instruccin SELECT
se llevan a cabo sin bloqueo, puede utilizar una versin antigua de una fila que ya no existe.
Por lo tanto, el uso de este nivel no tiene aislamiento y no garantiza la transaccin, tales
lecturas no son consistentes. Esto tambin se le llama una lectura sucia.
Read-committed (lectura comprometida): Con este nivel de aislamiento se evita el
fenmeno de la lectura sucia, porque los cambios no confirmados no son visibles para
cualquier otra transaccin, hasta que se confirme el cambio. Dentro de este nivel de
aislamiento, cada SELECT utiliza su propia instantnea de los datos que se confirm
(commit) antes de la ejecucin de la instruccin SELECT. Ahora, ya que cada SELECT tiene
su propia instantnea, por lo que el mismo SELECT cuando se ejecuta varias veces durante
la misma transaccin podra regresar diferentes conjuntos de resultados. Este fenmeno se
le llama lectura no repetible.
Repeatable-read (lectura repetible): Lee todos los datos de forma coherente dentro de la
misma transaccin. Con este nivel de aislamiento se evita el fenmeno de la lectura no
repetible. Este nivel de aislamiento devuelve el mismo conjunto de resultados para diferentes
SELECT dentro de una misma transaccin. Una copia del SELECT se toma la primera vez
que se ejecuta durante la transaccin y la misma copia se utiliza dentro de la transaccin
cada vez que se ejecuta el mismo SELECT. Una transaccin que se ejecuta en este nivel
de aislamiento no tiene en cuenta los cambios de los datos realizados por otras
transacciones, independientemente de si los cambios se han confirmado (commit) o no.
Serializable: Con este nivel de aislamiento se evita el fenmeno de fantasma. Coloca un
bloqueo de rango en el conjunto de datos, cuando las transacciones se ejecuta en este nivel
de aislamiento se bloquean todos los registros y recursos que se tiene acceso, as bloquea
todo cambio, impidiendo que otros usuarios actualizar o insertar filas en el conjunto de datos
hasta que la transaccin se ha completado. Este nivel de aislamiento es el ms fuerte
posible.

Irak Bernal
 Taller de Bases de Datos 5

Comportamiento permitido
Nivel de aislamiento Lectura sucia Lectura no repetible Lectura fantasma
Lectura no comprometida S S S
Lectura comprometida No S S
Lectura repetible No No S
Serializable No No No

Tabla 1.1 comportamientos permitidos

4.5 Commit y rollback

La terminacin exitosa de una transaccin se conoce como CONFIRMADA mientras que a la falla
de una transaccin se le conoce como ABORTADA. MySQL maneja por defecto una auto-
confirmacin en cada operacin. Si se desea usar ROLLBACK y COMMIT debe desactivarse con
SET AUTOCOMMIT=0;
Instruccin Descripcin
SET TRANSACTION Establece el nivel de aislamiento de una transaccin.
ISOLATION LEVEL
COMMIT Asienta la transaccin de forma permanente.
ROLLBACK Deshace los cambios efectuados por la transaccin.
SAVEPOINT Indica un punto de referencia intermedio en una transaccin.
ROLLBACK TO Deshace las operaciones hasta el punto de referencia indicado, es
SAVEPOINT til cuando las transacciones son extensas y no se desea reiniciarla
totalmente en caso de fallo.

Tabla 1.2 instrucciones de commit y rollback

Ejercicio explicado.

Teniendo en cuenta que existen dos tablas de nombre departamento1 y departamento2, y cada
una tiene los campos de id, presupuesto, nombre. Realizaremos una transaccin de datos del
departamento2 al departamento1.

START TRANSACTION;
SELECT @B:= id, @A:= presupuesto, @C:= nombre
FROM departamento2
WHERE id=16;
INSERT INTO departamento (id, presupuesto, nombre ) VALUES (@B , @A @C);
COMMIT ;

El cdigo anterior con START TRANSACTION marcamos el inicio de la transaccin y despus

selecciona id, presupuesto y nombre del departamento2 y los guarda en las variables A, B y C, para
despus insertarlos en el departamento1. La sentencia COMMIT marca el xito de la operacin y
cierra la transaccin.

Preguntas
Qu es la concurrencia en un sistema informtico distribuido?
R.- Se refiere al hecho que los Sistemas Gestores de Bases de Datos permiten que muchas
transacciones puedan realizarse en una misma base de datos a la vez.
Cmo podemos controlar el acceso de los usuarios a un SGBD distribuido cuando todos quieren
realizar peticiones o consultas a la misma BD?
R.- Cuando dos consultas tratan de actualizar el mismo elemento de datos o si ocurre una falla
durante la ejecucin de una consulta, no se puede simplemente reactivar la ejecucin de la consulta,

Irak Bernal
 Taller de Bases de Datos 6

puesto que algunos datos pueden haber sido modificados antes de la falla. Para esto existen
mtodos control de concurrencia y de los cuales tenemos: bloqueos optimistas y pesimistas y dentro
de estos existen bloqueos binarios, bloqueos de lectura/escritura, bloqueo en dos fases, algoritmos
de marcas de tiempo.

Conclusin.
En esta investigacin se conocieron los problemas que se presentan cuando la concurrencia no se
controla y algunos de los mecanismos de bloqueo que nos permiten manejar la concurrencia en las
transacciones. De esta manera, los sistemas de control de concurrencia deben garantizar la
consistencia de la informacin en la base de datos. Concurrencia se refiere al hecho de que los
Sistemas Gestores de Base de Datos permiten que muchas transacciones accedan a una misma
base de datos a la vez. El control de concurrencias en las bases de datos no solo permite mejorar la
calidad de funcionamiento de las aplicaciones, sino que incluso hacen posible que se puedan realizar
muchos de los sistemas existentes, lo que sin la existencia de estos controles no seran factibles de
realizar. El correcto control de concurrencias permite adems mantener informacin consistente en
las bases de datos, as como tambin evita la aparicin de errores en las recuperaciones y o
respaldos que se realicen de una base de datos. Cuando existen varios usuarios intentando modificar
los datos al mismo tiempo, se necesita establecer algn tipo de control para que dichas
modificaciones de un usuario no interfieran en las de los otros, a este sistema se le denomina control
de concurrencia. Al realizar una transaccin hay que tener en cuenta que apenas se realice un
INSERT, UPDATE o DELETE se genera un bloqueo sobre la tabla y que otros clientes no pueden
acceder para escribir esta tabla. Otros clientes podrn realizar SELECT sobre la tabla, pero no
podrn ver los datos del primer cliente hasta que los mismos sean confirmados. Hay que tener en
cuenta que MySQL es un gestor de datos relacional que soporta diversos motores de
almacenamiento. De estos solamente InnoDB soporta el uso de transacciones. En MySQL InnoDB
tenemos las instrucciones START TRANSACTION que marca el inicio de una transaccin.
ROLLBACK fuerza que se deshaga la transaccin en caso de haber un problema o querer
abandonarla o cierra la transaccin. COMMIT confirma el conjunto de operaciones convirtiendo los
datos en definitivos y marca el xito de la operacin de bloque y cierra la transaccin. En cuanto a
los niveles de aislamiento que nos ofrece MySQL tenemos SERIALIZABLE, REPEATABLE READ,
READ COMMITED, READ UNCOMMITTED. Dada la naturaleza de una consulta, de lectura o
actualizacin, a veces no se puede simplemente reactivar la ejecucin de una consulta, puesto que
algunos datos pueden haber sido modificados antes la falla. El no tomar en cuenta esos factores
puede conducir a que la informacin en la base de datos contenga datos incorrectos. El concepto
fundamental aqu es la nocin de ejecucin consistente o procesamiento confiable asociada con el
concepto de una consulta. El concepto de una transaccin es usado dentro del dominio de la base
de datos como una unidad bsica consistente y confiable. Es por eso que la seguridad en las bases
de datos es muy importante debido a que garantiza la integridad fsica y lgica de los datos. Un
sistema gestor de bases de datos consiste en una coleccin de datos interrelacionados y una
coleccin de programas para acceder a esos datos. Los sistemas de bases de datos se disean para
almacenar grandes cantidades de informacin. Por debajo de la estructura de datos est el modelo
de datos, una coleccin de herramientas conceptuales para describir los datos, las relaciones, la
semntica de los datos y las relaciones de los datos

Bibliografa

1.- Arias ngel. (2014). Bases de Datos con MySQL. Mlaga, Espaa: IT Campus Academy.
2.- Oppel Andy, Sheldon Robert. (2010). FUNDAMENTOS DE SQL (3 edicin). Mxico: McGraw-
Hill Inc.
3.- Garrido Miguel Angel. (2015). Manual de Supervivencia del Administrador de Bases de Datos.
(pp.109-112). Mlaga, Espaa: IT Campus Academy.
4.- Cardoso Luca. (2010). Sistemas de bases de datos II. Caracas, Venezuela: Universidad Catlica
Andrs Bello.

Irak Bernal