BDII Unidad 1

Base de Datos II
3‐2‐8 ESP ‐ 0002
(Apuntes)
L.I. Irving Santamaría Domínguez

UNIDAD I
www.irvingsd.co.cc
www.irvingsd.co.cc | ISC
BASE DE DATOS II 3.1 Definición.

3.2 Problemas que se presentan.
3 - 2 - 8 ESP – 0002
(Actualización perdida).
OBJETIVO: 3.3 Seriabilidad
Comprender los diferentes aspectos del control de concurrencia, 3.4 Mecanismos de Seguros.
aplicar estrategias de recuperación adecuada y diseñar esquemas de III Concurrencia. - Tipos de seguros.
- Protocolos,
seguridad e integridad de bases de datos:
- Dead lock.
CONTENIDO: - Técnicas para prevenirlo.
- Técnicas para deshacerlo.
UNIDAD TEMAS SUBTEMAS 3.5 Etiquetas de tiempo.
1.1 Concepto.
4.1 Concepto.
1.2 Transacciones.
4.2 Identificación y autentificación.
I Recuperación. 1.3 Fallas de transacción.
4.3 Matriz de autorización.
1.4 Fallas del Sistema.
4.4 Definición de un esquema de
1.5 Fallas en el Medio.
IV Seguridad. seguridad.
2.1 Definición.
4.5 Mecanismos de vistas para
2.2 Reglas de Integridad
implementación de seguridad.
2.3 Reglas de integridad de dominio.
4.6 Base de datos estadísticos.
II Integridad. 2.4 Reglas de integridad de relación.
4.7 Inscripción de datos.
2.5 Mecanismos de visitas para
( Codificación)
implementación de integridad.
[ Base de Datos II / Unidad I ] Página 2

BIBLIOGRAFIA:
9 Korth, Henry F. Fundamentos de bases de datos, Segunda edición ,1993, Edit. Mc. Graw Hill, España.
9 Date,C.J. Introducción a los sistemas de bases de datos, Quinta edición , 1993, Edit. Addison Wesley Iberoamericana ,S.A, México
9 Widerhold, Diseño de bases de datos, Segunda edición, 1988, Edit. Mc. Graw Hill, México
9 E.B. Fernández. R. C. Summers, C. Wood., The system programming series, data base security and integrity. Edit. Addison Wesley.
9 E. Perry William, Ensuring data base integrity, Edit. John Wiley & Sons.
9 Date C.J. An Introduction to database systems, Edit. Addison Wesley.

UNIDAD I RECUPERACION
1.1 Concepto
1.2 Transacciones
1.3 Fallas De Transacción
1.4 Fallas Del Sistema
1.5 Fallas En El Medio
UNIDAD I
RECUPERACIÓN
1.1 CONCEPTO
El objetivo del concepto de recuperación es el de proteger la BD contra fallas

lógicas y físicas que destruyan los datos en todo o en parte. Independiente de la
naturaleza de las fallas estás pueden afectar a dos aspectos del almacenamiento de la
Base de Datos, como son:
* Fallas que provocan la pérdida de memoria volátil
* Fallas que provocan la pérdida del contenido de memoria secundaria.
1.2 TRANSACCIONES
Para asegurar que la BD siempre este en un estado consistente, se crean unidades

de ejecución llamadas transacciones, que pueden definirse como una secuencia de
operaciones que han de ejecutarse en forma atómica, es decir, se realizan todas las
operaciones que comprende la transacción o no se realiza ninguna.
Ej: una transacción bancaria que saca dinero de una cuenta y lo dispone en otra.
Las transacciones o terminan con éxito y son grabadas en la base o bien fracasan y
debe ser restaurado el estado anterior de la BD.

El componente del sistema encargado de lograr la atomicidad se conoce como
administrador de transacciones y las operaciones COMMIT (comprometer) y
ROLLBACK (retroceder) son la clave de su funcionamiento.
La operación COMMIT señala el término exitoso de la transacción: le dice al

administrador de transacciones que se ha finalizado con éxito una unidad lógica de
trabajo, que la base de datos está o debería estar de nuevo en un estado consistente y
que se pueden comprometer, o hacer permanentes todas las modificaciones efectuadas
por ese unidad de trabajo.
La operación ROLLBACK, en cambio, señala el término no exitoso de la transacción:

le dice al administrador de transacciones que algo salió mal, que la base de datos podría
estar en un estado inconsistente y que todas las modificaciones efectuadas hasta el
momento por la unidad lógica de trabajo deben retroceder o anularse.
Las características de una transacción son:
• Atomicidad, en el sentido que hemos especificado anteriormente: se ejecutan

todas las sentencias o ninguna.
• Preservación de la consistencia: la ejecución de una transacción deja la BD en un
estado consistente.
• Aislamiento, ya que una transacción no muestra los cambios que produce hasta
que finaliza.
• Persistencia, ya que una vez que finaliza la transacción con éxito, sus efectos
perduran en la BD.
• Seriabilidad, en el sentido de que el efecto de ejecutar transacciones
concurrentemente debe ser el mismo que se produciría al ejecutarlas por
separado en un orden secuencial según van entrando en el sistema.
Para conseguir anular y recuperar transacciones, el método mas usado consiste en

utilizar un archivo de diario o log en el que va guardando toda la información necesaria
para deshacer (en caso de fracasar) o rehacer ( en caso de recuperar) las transacciones.
Este archivo consta de:
• Identificador de la transacción
• Hora de modificación
• Identificador del registro afectado
• Tipo de acción
• Valor anterior del registro
• Nuevo valor del registro
• Información adicional.
Otra alternativa es manejar 2 archivos de log, uno con la imagen anterior a las
modificaciones y otro con la imagen posterior a las modificaciones. El archivo log es

usualmente una pila que una vez llena va eliminado registros según van entrando
nuevos.
Un concepto relacionado con los archivos de log es el CHECKPOINT, que permite

manejar en forma eficiente el contenido de los archivos log, ya que permiten no tener
que recorrer todo el archivo de log, ante fallas.
El establecimiento de puntos de revisión implica:
 grabar físicamente el contenido de los buffers de datos a la base de datos física
* grabar físicamente un registro de punto de revisión especial dentro del archivo de

log o bitácora
Los puntos marcados como checkpoint, permiten la recuperación de la base de datos

en caliente, es decir, después de la caída del sistema se obtiene la dirección del registro
de recuperación más reciente y se recorre el archivo de log desde el punto marcado
como checkpoint.
La transacción t1 no se ve afectada por la falla del sistema, ni por el proceso de

recuperación, por haberse completado antes del último punto de recuperación. Las
transacciones t2 y t4, a pesar de haber terminado no han sido grabadas en la base de
datos, ya que éstas serían cometidas en un checkpoint. Las transacciones t3 y t5 deberán
rehacerse ya que no han concluido.
El procedimiento que deberá realizar el sistema al reiniciarse consiste en:
1. Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR.

igualar la lista ANULAR a la lista de todas las transacciones incluidas en el
registro de punto de revisión. Dejar vacía la lista REPETIR.
2. Examinar la bitácora hacia adelante a partir del registro de punto de revisión.
3. Si se encuentra una entrada de bitácora de "iniciar transacción" para la

transacción T, añadir T a la lista ANULAR.
4. Si se encuentra una entrada una entrada de bitácora "comprometer" para la

transacción T, pasar esa transacción de la lista ANULAR a la lista REPETIR.
5. Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR

identificarán, respectivamente, las transacciones de los tipos T3 y T5 y las de los tipos T2
y T4.

Posteriormente el sistema revisará la bitácora hacia atrás, anulando todas las

transacciones de la lista ANULAR. A continuación la revisará hacia adelante, realizando
de nuevo todas las transacciones en la lista REPETIR. Por ultimo, una vez terminada
todas las actividades de recuperación, el sistema estará listo para aceptar nuevos
trabajos.
La recuperación en frío, consiste en disponer de un backup o respaldo de la BD,

que permitirá junto con los archivos de log, que se han ido produciendo desde el ultimo
backup, reconstruir la BD, para dejarla consistente.
1.3 FALLAS DE TRANSACCIÓN
Cuando un usuario esta ingresando datos a una computadora donde se han realizado
varias transacciones y falla el sistema, una vez que este se recupera, su estado corre el
riesgo del duplicado de transacciones.
Una transacción puede fallar por varias causas. Puede ser que los datos de entrada no
son correctos o no coinciden con la BD, también puede ser debido a faltas de recursos.
Existen 2 tipos de fases en la transacción:
1.- Adquiere todos los recursos necesarios para su ejecución.
2.- Todos los cambios restantes se colocan en la base de datos y pueden llegar a liberarse
los recursos detenidos por la transacción. Al entrar a la segunda fase la transacción debe
concluirse.
Errores de una transacción:
1.- Aborto de una transacción.
2.- Nuevo inicio de una transacción.
3.- Eliminación de una transacción.

1.4 FALLAS DEL SISTEMA
(Ejemplo: falla en el suministro eléctrico) que afectan a todas las transacciones que estén
actualmente en progreso, pero no dañan físicamente a la BD.
El puerto principal con relación a la falla del sistema es que “se pierde el contenido
de la memoria principal”. Ya no es posible conocer el estado preciso de cualquier
transacción que esta en progreso al momento de la falla y por lo tanto, tal transacción
nunca podrá terminar satisfactoriamente y deberá ser deshecha cuando el sistema
vuelva a iniciar.
Tal vez sea necesario al momento del reinicio volver a realizar determinadas
transacciones que se completaran satisfactoriamente antes de la falla pero que no
pudieran lograr que su actualización fueran transferidas desde los buffers de la BD
hacia la BD física.
Las fallas del sistema se clasifican en:
• Falla de amnesia: Cuando sé inicializa el sistema y no se conoce él estado que

se tenía antes de la falla.
• Falla de amnesia parcial: Cuando sé reinicializa el sistema y sé conoce parte
del estado que se presentaba antes de ocurrir la falla. También se predefine
un estado inicial para fallas.
• Falla de pausa: Ocurre cuando el sistema sé reinicializa al mismo estado que
se encontraba antes de la falla.
• Falla de aborto (Halting): Cuando un sistema nunca sé reinicializa.
1.5 FALLAS EN EL MEDIO
Ocurre cuando él medio de almacenamiento no puede ser accesado. Esta falla es

causada generalmente por errores en paridad, daño en cabezas lectoras, partículas de
polvo o daño en sectores del medio. Comúnmente sé utilizan medios alternos que
permiten reducir las condiciones de riesgo como: espejo de discos, arreglo de discos, etc.

TRANSACCIONES EN MYSQL
El servidor de bases de datos MySQL soporta distintos tipos de tablas, tales como
ISAM, MyISAM, InnoDB y BDB (Berkeley Database). De éstos, InnoDB es el tipo de
tabla más importante (después del tipo predeterminado, MyISAM), y merece una
atención especial.
Las tablas del tipo InnoDB están estructuradas de forma distinta que MyISAM, ya
que se almacenan en un sólo archivo en lugar de tres, y sus principales características
son que permite trabajar con transacciones, y definir reglas de integridad referencial.
El soporte de transacciones que provee MySQL no es algo nuevo en MySQL 4, ya

que desde la versión 3.23 se podía hacer uso de tablas InnoDB, la única diferencia es que
con la llegada de la versión 4.0 de MySQL, el soporte para este tipo de tablas es
habilitado por default.
Las transacciones aportan una fiabilidad superior a las bases de datos. Si

disponemos de una serie de consultas SQL que deben ejecutarse en conjunto, con el uso
de transacciones podemos tener la certeza de que nunca nos quedaremos a medio
camino de su ejecución. De hecho, podríamos decir que las transacciones aportan una
característica de "deshacer" a las aplicaciones de bases de datos.
Para este fin, las tablas que soportan transacciones, como es el caso de InnoDB,
son mucho más seguras y fáciles de recuperar si se produce algún fallo en el servidor, ya
que las consultas se ejecutan o no en su totalidad. Por otra parte, las transacciones
pueden hacer que las consultas tarden más tiempo en ejecutarse.
Seguramente alguna vez hemos escuchado hablar acerca de las transacciones,

pero probablemente no entendemos bien lo que son, y como deben de ser usadas. La
idea de este artículo es presentar algunos ejemplos para mostrar que no es nada
complicado, y difícil de aprender.
En este artículo se asume que se cuenta ya con un servidor MySQL con soporte
para el tipo de tablas InnoDB. En nuestro caso haremos uso de un servidor MySQL 4.013
ejecutándose en un sistema MSWindows.
Para asegurarnos que tenemos soporte para el tipo de tablas InnoDB podemos
ejecutar la siguiente sentencia:


mysql> SHOW VARIABLES LIKE '%innodb%';
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐+
| Variable_name | Value |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐+
| have_innodb | YES |
| innodb_additional_mem_pool_size | 1048576 |
| innodb_buffer_pool_size | 8388608 |
| innodb_data_file_path | ibdata:30M |
| innodb_data_home_dir | |
| innodb_file_io_threads | 4 |
| innodb_force_recovery | 0 |
| innodb_thread_concurrency | 8 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_fast_shutdown | ON |
| innodb_flush_method | |
| innodb_lock_wait_timeout | 50 |
| innodb_log_arch_dir | .\ |
| innodb_log_archive | OFF |
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | .\ |
| innodb_mirrored_log_groups | 1 |
| innodb_max_dirty_pages_pct | 90 |
+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐+
20 rows in set (0.00 sec)
La variable más importante es por supuesto have_innodb que tiene el valor YES.
En efecto, una de las principales características de las tablas del tipo InnoDB es que
pueden trabajar con transacciones, o sentencias SQL que son agrupadas como una sola.
Un ejemplo típico de esto es una transacción bancaria. Por ejemplo, si una cantidad de
dinero es transferida de la cuenta de una persona a otra, se requerirán por lo menos dos
consultas:

UPDATE cuentas SET balance = balance ‐ cantidad_transferida WHERE cliente = persona1;
UPDATE cuentas SET balance = balance + cantidad_transferida WHERE cliente = persona2;


Estas dos consultas deben trabajar bien, ¿pero que sucede si ocurre algún imprevisto y
"se cae" el sistema después de que se ejecuta la primer consulta, pero la segunda aún no
se ha completado?. La persona1 tendrá una cantidad de dinero removida de su cuenta, y
creerá que ha realizado su pago, sin embargo, la persona2 estará enfadada puesto que
pensará que no se le ha depositado el dinero que le deben. En este ejemplo tan sencillo
se ilustra la necesidad de que las consultas sean ejecutadas de manera conjunta, o en su
caso, que no se ejecute ninguna de ellas. Es aquí donde las transacciones toman un papel
muy importante.
Los pasos para usar transacciones en MySQL son:
• Iniciar una transacción con el uso de la sentencia BEGIN.

• Actualizar, insertar o eliminar registros en la base de datos.
• Si se quieren los cambios a la base de datos, completar la transacción con el
uso de la sentencia COMMIT. Únicamente cuando se procesa un COMMIT
los cambios hechos por las consultas serán permanentes.
• Si sucede algún problema, podemos hacer uso de la sentencia ROLLBACK
para cancelar los cambios que han sido realizados por las consultas que han
sido ejecutadas hasta el momento.
Vamos a ejecutar algunas consultas para ver como trabajan las transacciones. Lo
primero que tenemos que hacer es crear una tabla del tipo InnoDB e insertar algunos
datos.
Para crear una tabla InnoDB, procedemos con el código SQL estándar CREATE TABLE,
pero debemos especificar que se trata de una tabla del tipo InnoDB (TYPE= InnoDB).
Esto es aplicable a cualquier tipo de tabla, pero cuando no se especifica nada, MySQL
supone que se trata de una tabla MyISAM.
mysql> CREATE TABLE innotest (campo INT NOT NULL PRIMARY KEY) TYPE = InnoDB;
Query OK, 0 rows affected (0.10 sec)

mysql> INSERT INTO innotest VALUES(1);
Query OK, 1 row affected (0.08 sec)




mysql> SELECT * FROM innotest;
+‐‐‐‐‐‐‐+
| campo |
+‐‐‐‐‐‐‐+
| 1 |
| 2 |
| 3 |
+‐‐‐‐‐‐‐+

De acuerdo, nada espectacular. Ahora veamos como usar transacciones.

mysql> BEGIN;


+‐‐‐‐‐‐‐+
| campo |
+‐‐‐‐‐‐‐+
| 1 |
| 2 |
| 3 |
| 4 |
+‐‐‐‐‐‐‐+

Si en este momento ejecutamos un ROLLBACK, la transacción no será completada, y los
cambios realizados sobre la tabla no tendrán efecto.

mysql> ROLLBACK;

+‐‐‐‐‐‐‐+
| campo |
+‐‐‐‐‐‐‐+
| 1 |
| 2 |
| 3 |

+‐‐‐‐‐‐‐+

Ahora vamos a ver que sucede si perdemos la conexión al servidor antes de que la transacción sea
completada.

mysql> BEGIN;


+‐‐‐‐‐‐‐+
| campo |
+‐‐‐‐‐‐‐+
| 1 |
| 2 |
| 3 |
| 4 |
+‐‐‐‐‐‐‐+

mysql> EXIT;
Bye

Cuando obtengamos de nuevo la conexión, podemos verificar que el registro no se
insertó, ya que la transacción no fue completada.

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 449 to server version: 4.0.13

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
+‐‐‐‐‐‐‐+
| campo |
+‐‐‐‐‐‐‐+
| 1 |
| 2 |
| 3 |
+‐‐‐‐‐‐‐+

Otro Ejemplo
En el ejemplo anterior hemos usado únicamente sentencias INSERT, sin

embargo, sucede lo mismo con sentencias UPDATE o DELETE. Vamos a
crear una sencilla tabla llamada ventas que sea del tipo InnoDB.
mysql> CREATE TABLE ventas(id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
-> producto VARCHAR(30) NOT NULL, cantidad TINYINT NOT NULL) TYPE =
InnoDB;
Insertamos Un Registro.
mysql> INSERT INTO ventas VALUES(0,'Gansito marinela',3);

mysql> SELECT * FROM ventas;

+----+------------------+----------+
| id | producto | cantidad |
+----+------------------+----------+
| 1 | Gansito marinela | 3 |
+----+------------------+----------+
1 row in set (0.01 sec)
Ahora vamos a iniciar una transacción con la sentencia BEGIN.
mysql> BEGIN;
Actualizamos el registro.
mysql> UPDATE ventas SET cantidad=4 WHERE id=1;

Lgneas correspondientes: 1 Cambiadas: 1 Avisos: 0
Verificamos que los cambios han sucedido.

+----+------------------+----------+
+----+------------------+----------+
+----+------------------+----------+
Si queremos deshacer los cambios, entonces ejecutamos un ROLLBACK.
mysql> ROLLBACK;

Verificamos que se deshicieron los cambios.

+----+------------------+----------+
+----+------------------+----------+
+----+------------------+----------+
Vamos a actualizar el registro usando otra transacción.
mysql> BEGIN;
mysql> UPDATE ventas SET cantidad=2 WHERE id=1;

Líneas correspondientes: 1 Cambiadas: 1 Avisos: 0

+----+------------------+----------+
+----+------------------+----------+
+----+------------------+----------+
Vamos a confirmar que deseamos los cambios. Después de ejecutar el COMMIT los
cambios serán permanentes y definitivos.
mysql> COMMIT;

+----+------------------+----------+
+----+------------------+----------+
+----+------------------+----------+


BDII Unidad 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BDII Unidad 1

Transféré par

Droits d'auteur :

Formats disponibles

L.I. Irving Santamaría Domínguez

BASE DE DATOS II 3.1 Definición.

El objetivo del concepto de recuperación es el de proteger la BD contra fallas

* Fallas que provocan la pérdida de memoria volátil

* Fallas que provocan la pérdida del contenido de memoria secundaria.

Para asegurar que la BD siempre este en un estado consistente, se crean unidades

La operación COMMIT señala el término exitoso de la transacción: le dice al

La operación ROLLBACK, en cambio, señala el término no exitoso de la transacción:

Las características de una transacción son:

• Atomicidad, en el sentido que hemos especificado anteriormente: se ejecutan

Para conseguir anular y recuperar transacciones, el método mas usado consiste en

Un concepto relacionado con los archivos de log es el CHECKPOINT, que permite

El establecimiento de puntos de revisión implica:

 grabar físicamente el contenido de los buffers de datos a la base de datos física

* grabar físicamente un registro de punto de revisión especial dentro del archivo de

Los puntos marcados como checkpoint, permiten la recuperación de la base de datos

La transacción t1 no se ve afectada por la falla del sistema, ni por el proceso de

El procedimiento que deberá realizar el sistema al reiniciarse consiste en:

1. Comenzar con dos listas de transacciones, la lista ANULAR y la lista REPETIR.

2. Examinar la bitácora hacia adelante a partir del registro de punto de revisión.

3. Si se encuentra una entrada de bitácora de "iniciar transacción" para la

4. Si se encuentra una entrada una entrada de bitácora "comprometer" para la

5. Cuando se llegue al final de la bitácora, las listas ANULAR y REPETIR

Posteriormente el sistema revisará la bitácora hacia atrás, anulando todas las

La recuperación en frío, consiste en disponer de un backup o respaldo de la BD,

1.3 FALLAS DE TRANSACCIÓN

Existen 2 tipos de fases en la transacción:

1.- Adquiere todos los recursos necesarios para su ejecución.

Errores de una transacción:

1.- Aborto de una transacción.

2.- Nuevo inicio de una transacción.

3.- Eliminación de una transacción.

Las fallas del sistema se clasifican en:

• Falla de amnesia: Cuando sé inicializa el sistema y no se conoce él estado que

1.5 FALLAS EN EL MEDIO

Ocurre cuando él medio de almacenamiento no puede ser accesado. Esta falla es

El soporte de transacciones que provee MySQL no es algo nuevo en MySQL 4, ya

Las transacciones aportan una fiabilidad superior a las bases de datos. Si

Seguramente alguna vez hemos escuchado hablar acerca de las transacciones,

Los pasos para usar transacciones en MySQL son:

• Iniciar una transacción con el uso de la sentencia BEGIN.

En el ejemplo anterior hemos usado únicamente sentencias INSERT, sin

mysql> INSERT INTO ventas VALUES(0,'Gansito marinela',3);

mysql> SELECT * FROM ventas;

Ahora vamos a iniciar una transacción con la sentencia BEGIN.

mysql> UPDATE ventas SET cantidad=4 WHERE id=1;

Verificamos que los cambios han sucedido.

mysql> SELECT * FROM ventas;

Si queremos deshacer los cambios, entonces ejecutamos un ROLLBACK.

Verificamos que se deshicieron los cambios.

mysql> SELECT * FROM ventas;

Vamos a actualizar el registro usando otra transacción.

mysql> UPDATE ventas SET cantidad=2 WHERE id=1;

mysql> SELECT * FROM ventas;

mysql> SELECT * FROM ventas;

Vous aimerez peut-être aussi