3.

1 Estructuras lgicas de almacenamiento

Para la gestin del almacenamiento de una base de datos existen 4
conceptos bien definidos que deben ser conocidos para poder
comprender la forma en la que se almacenan los datos. Vamos a ver la
diferencia entre bloque, extensin, segmento y espacio de tablas.
Bloques: Se tratan de la unidad ms pequea. Generalmente debe
mltiple del tamao de bloque del sistema operativo, ya que es la
unidad mnima que va a pedir Oracle al sistema operativo. Si no fuera
mltiple del bloque del sistema se aadira un trabajo extra ya que el
sistema debera obtener ms datos de los estrictamente necesarios. Se
especifica mediante DB_BLOCK_SIZE
Extensiones: Se forma con uno o ms bloques. Cuando se aumenta
tamao de un objeto se usa una extensin para incrementar el espacio.
Segmentos: Grupo de extensiones que forman un objeto de la base de
datos, como por ejemplo una tabla o un ndice.
Espacio de tablas: Formado por uno o ms datafiles, cada datafile solo
puede pertenecer a un determinado tablespace

En general, el almacenamiento de los objetos de la base de datos (tablas

e ndices fundamentalmente) no se realiza sobre el archivo o archivos
fsicos de la base de datos, sino que se hace a travs de estructuras
lgicas de almacenamiento que tienen por debajo a esos archivos
fsicos, y que independizan por tanto las sentencias de creacin de
objetos de las estructuras fsicas de almacenamiento. Esto es til porque
permite que a esos "espacios de objetos " les sean asociados nuevos
dispositivos fsicos (es decir, ms espacio en disco) de forma dinmica
cuando la base de datos crece de tamao ms de lo previsto. Posibilita
adems otra serie de operaciones como las siguientes:

Asignar cuotas especficas de espacio a usuarios de la base de

datos.
Controlar la disponibilidad de los datos de la base de datos,
poniendo fuera de uso alguno de esos espacios de tablas
individualmente.
Realizar copias de seguridad o recuperaciones parciales de la base
de datos.

Reservar espacio para almacenamiento de datos de forma

cooperativa entre distintos dispositivos.

El administrador de la base de datos puede crear o borrar nuevos

espacios lgicos de objetos, aadir o eliminar ficheros fsicos de soporte,
utilizados como espacio temporal de trabajo, definir parmetros de
almacenamiento para objetos destinados a ese espacio de datos, todos
los gestores relacionales que venimos introduciendo como ejemplos
siguen esta filosofa. En el caso de Oracle, sobre los ficheros fsicos de
datos (datafiles) se definen los tablespaces. Por lo tanto, una base de
datos Oracle se compone lgicamente de tablcspaccs, y fsicamente de
datafilcs. Su creacin es sencilla, con la sentencia GREAT'', TABLESPACE:
CREATE TABLESPACE usuarios DATAFILE `datal.ora' SIZE 50M
Tambin es sencillo ampliar el espacio destinado a un tablespace
utilizando el comando ALTER TABLESPACE:
ALTER TABLESPACE usuarios ADD DATAFILE 'data2.ora' SIZE 25M
Cada base de datos contiene un tablespace llamado SYSTEM que es
creado automticamente al crear la base de datos. Contiene las tablas
del diccionario de datos para la base de datos en cuestin. Es
recomendable no cargar datos de usuario en SYSTEM, para dejarlos
como espacio de objetos del sistema. Si adems los datos de usuario
estn en tablespaces sitos en otros dispositivos, el rendimiento mejorar
porque las tablas del diccionario de datos se acceden frecuentemente y
por lo tanto son un cuello de botella potencial desde el punto de vista
del acceso a disco. A la hora de estimar el espacio necesario para cl
tablespace sys-nsm hay que tener en cuenta que las unidades de
programacin PL-SQL (entorno de programacin SQL proporcionado por
Oracle) almacenadas en la base de datos (procedimientos, paquetes,
disparos y funciones) almacenan sus datos en SYSTEM.
De acuerdo con lo comentado anteriormente, tablas e ndices se
ubicarn en el tablespaee indicado en el momento de su creacin con la
correspondiente sentencia CREATE. Si no se dice nada, se situarn en el
tablespace por defecto asociado al usuario creador.

3.1.1. Definicin de espacio de almacenamiento

Las bases de datos suelen ser creadas para almacenar grandes
cantidades de datos de forma permanente. Por lo general, los datos
almacenados en stas suelen ser consultados y actualizados
constantemente.
La mayora de las bases de datos se almacenan en las llamadas
memorias secundarias, especialmente discos duros, aunque, en
principio, pueden emplearse tambin discos pticos, memorias flash,
etc.
Las razones por las cuales las bases de datos se almacenan en
memorias secundarias son:
1. En cuanto al respaldo de las bases de datos (ver backup), suelen
emplearse tanto discos duros, como cintas magnticas, discos
pticos o similares.
2. Las tcnicas empleadas para almacenar bases de datos son
sumamente importantes para la velocidad de acceso y
recuperacin de datos. Las tcnicas dependen del tipo de
almacenamiento, el uso que se le da o se le dar a la base de
datos, la estructura de la misma, el SGBD empleado, etc.
Esta dependencia no significa necesariamente que haya que cambiar la
estructura de la base de datos si se cambian las tcnicas empleadas.
Las tcnicas de almacenamiento son independientes de la base de
datos, pero, de todas maneras, las mejores tcnicas muchas veces
pueden determinarse viendo la estructura de la base de datos, entre
otras caractersticas.
3.1.3. Bitcoras

La estructura ms ampliamente usada para grabar las modificaciones de

la base de datos es la Bitcora. Cada registro de la bitcora escribe una
nica escritura de base de datos y tiene lo siguiente:
1. Nombre de la transaccin: La transaccin que realiz la operacin de
escritura.
2. Nombre del dato: El nombre nico del dato escrito.
3. Valor antiguo: El valor del dato antes de la escritura.
4. Valor nuevo: El valor que tendr el dato despus de la escritura.
ACTIVIDAD INDIVIDUAL: Investigar el tema de BITACORAS.
Elementos de la investigacin:
1. Definicin.

2. Sintaxis.

3. Elementos.

4. Incluir un ejemplo de una bitcora

(sentencia para implementar una
bitcora).
6. Propiedades.

5. Caractersticas.

NOTA: El trabajo de investigacin se entregar el da martes 17 de

noviembre en formato digital junto con las pantallas de la
implementacin de la bitcora en el DBMS, entrega individual. nico da
de entrega martes 17 de noviembre en horario de clase.

INSTITUTO
TECNOLOGICO
DE MINATITLAN
NOMBRE DEL ALUMNO:
HERNANDEZ PABLO LUIS DONALDO RAI

NOMBRE DEL TRABAJO:

INSTALACION DE VMWare

PROFESOR:
VIVAS TORRES PABLO FRANCISCO.
MATERIA:
ADMINISTRACIN DE REDES

HORARIO:

1.- Definicin.
Herramienta que permite registrar, analiza, detectar y modificar eventos que
sucedan en cualquier sistema de informacin utilizado en las organizaciones. La
estructura ms ampliamente utilizada para grabar las modificaciones de la base de
datos.
Otra definicin:
La bitcora es un fichero en el que se almacena detalles sobre las operaciones
efectuadas como parte de las transacciones que afectan a los valores de los
elementos de informacin de la BD. Por ejemplo, para las actualizaciones se
puede guardar el valor que tenan los datos afectados antes de la modificacin y el
que contienen despus

2.- Sintaxis.
Cada registro almacenado en la bitcora se llama entrada, y ser de uno de los siguientes
tipos:

< INICIAR, T >

Indica que la transaccin T ha comenzado2

< ESCRIBIR, T, X, valor_anterior, valor_nuevo >

Indica que la transaccin T ha cambiado el valor del elemento X de la BD X

contena el valor anterior antes de la escritura y contendr el valor nuevo despus
de la escritura.

< LEER, T, X >

Indica que T ley el valor del elemento X de la base de datos

< COMMIT, T >

Indica que T finaliz con xito y su efecto puede ser confirmado en la base de
datos en disco; es decir, todos los cambios que ha realizado pueden ser
consolidados o asentados (quedar permanentes) en la BD.

< ROLLBACK, T >

Indica que la transaccin T ha sido anulada (abortada, cancelada), de forma que
ninguna de sus operaciones tendr efecto sobre la base de datos en disco, como
si T nunca se hubiera ejecutado: la transaccin ser revertida, todas sus
operaciones sern deshechas.

3.- Elementos.
Cada registro de la bitcora escribe una nica escritura de base de datos y tiene lo
siguiente:

Nombre de la transaccin: Nombre de la transaccin que realiz la

operacin de escritura.
Nombre del dato: El nombre nico del dato escrito.
Valor antiguo: El valor del dato antes de la escritura.
Valor nuevo: El valor que tendr el dato despus de la escritura.

Existen otros registros de bitcora especiales para grabar sucesos importantes

durante el proceso de transaccin tal como:
< T1, inicio >
< T1, x, v1, v2 >
< T1, commit >

4.- Ejemplo de una bitcora (sentencia para implementar

una bitcora).
EJEMPLO E IMPLEMENTACION DE BITACORA DE BASE DE DATOS EN
LENGUAJE DE PROGRAMACION EN SQL SERVER.
CREATE TABLE [dbo].[Bitacora] (
[BitacoraID] [int] IDENTITY (1, 1) NOT NULL ,
[EventType] [char] (14) NOT NULL ,
[Status] [int] NOT NULL ,
[EventInfo] [varchar] (1000) NOT NULL ,
[Usuario] [varchar] (20) NOT NULL ,
[Fecha] [smalldatetime] NOT NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Bitacora] WITH NOCHECK ADD
CONSTRAINT [DF_Bitacora_Usuario] DEFAULT (suser_sname()) FOR [Usuario],
CONSTRAINT [DF_Bitacora_Fecha] DEFAULT (getdate()) FOR [Fecha]

Y, por otro lado, el trigger en la tabla lo definira de la siguiente manera:

/* Trigger de Monitoreo */
CREATE TRIGGER trig_tablabitacora
ON TABLA
FOR DELETE, INSERT, UPDATE
AS
BEGIN

DECLARE @NUMERO INT

INSERT INTO Bitacora (EventType,Status,EventInfo)
exec sp_executesql NDBCC INPUTBUFFER( @i ), N@i int,
@i=@@spid
END

Enseguida plantear un ejemplo de una bitcora desarrollada para la siguiente

base de datos de MySQL, llamada proyecto, que tiene las tablas carrera,
departamento y maestros.
CREATE DATABASE proyecto;

USE proyecto

CREATE TABLE IF NOT EXISTS `carrera` (`clave_carrera` int(11) NOT NULL,

`nom_carrera` varchar(20) NOT NULL, `num_depto` int(11) NOT NULL, PRIMARY KEY
(`clave_carrera`), KEY `num_depto` (`num_depto`) ) ENGINE=InnoDB DEFAULT
CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `departamento` ( `num_departamento` int(11) NOT

NULL,`nombre_dept` varchar(20) NOT NULL, `jefe_num_tarjet` int(11) NOT NULL,
PRIMARY KEY (`num_departamento`), KEY `jefe_num_tarjet` (`jefe_num_tarjet`) )
ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `maestros` (`num_tarjeta` int(11) NOT NULL DEFAULT
0,`nombre`
varchar(50)
DEFAULT NULL,
PRIMARY KEY (`num_tarjeta`))
ENGINE=InnoDB DEFAULT CHARSET=latin1;

La estructura de la tabla bitcora sera la siguiente:

CREATE TABLE IF NOT EXISTS `bitacora` (`id` int(11) NOT NULL AUTO_INCREMENT,
`operacion` varchar(10) DEFAULT NULL, `usuario` varchar(40) DEFAULT NULL, `host`
varchar(30) NOT NULL, `modificado` datetime DEFAULT NULL, `tabla` varchar(40) NOT
NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
AUTO_INCREMENT=1 ;

La bitcora debe registrar todos los movimientos (insertar, eliminar y modificar)

que se realicen en las tablas de la base de datos. Para lograr lo anterior es
necesario crear un trigger para que se ejecute despus de la operacin de
insertar, otro para despus de eliminar y el ltimo para despus de modificar para
cada una de las 3 tablas de la base de datos. Los nueve triggers necesarios para
que funcione la bitcora son los siguientes:
DROP TRIGGER IF EXISTS `bit_carr_ins`;

DELIMITER //

CREATE TRIGGER `bitacora` AFTER INSERT ON `carrera`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), CARRERA)

//

DROP TRIGGER IF EXISTS `bit_carr_upd`;

CREATE TRIGGER `bit_carr_upd` AFTER UPDATE ON `carrera`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR,
NOW(),
CARRERA)

//

DROP TRIGGER IF EXISTS `bit_carr_del`;

CREATE TRIGGER `bit_carr_del` AFTER DELETE ON `carrera`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), ELIMINAR, NOW(), CARRERA)

//

DROP TRIGGER IF EXISTS `bit_depto_ins`;

CREATE TRIGGER `bit_depto_ins` AFTER INSERT ON `departamento`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)),
INSERTAR,
NOW(),
DEPARTAMENTO)

//

DROP TRIGGER IF EXISTS `bit_depto_upd`;

CREATE TRIGGER `bit_depto_upd` AFTER UPDATE ON `departamento`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR,
NOW(),
DEPARTAMENTO)

//

DROP TRIGGER IF EXISTS `bit_depto_del`;

CREATE TRIGGER `bit_depto_del` AFTER DELETE ON `departamento`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)),
ELIMINAR,
NOW(),
DEPARTAMENTO)

//

DROP TRIGGER IF EXISTS `bit_mae_ins`;

CREATE TRIGGER `bit_mae_ins` AFTER INSERT ON `maestros`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), INSERTAR, NOW(), MAESTROS)

//

DROP TRIGGER IF EXISTS `bit_mae_upd`;

CREATE TRIGGER `bit_mae_upd` AFTER UPDATE ON `maestros`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)),
ACTUALIZAR,
NOW(),
MAESTROS)

//

DROP TRIGGER IF EXISTS `bit_mae_del`;

CREATE TRIGGER `bit_mae_del` AFTER DELETE ON `maestros`

FOR EACH ROW INSERT INTO bitacora(host, usuario, operacion, modificado,

tabla)
VALUES
(SUBSTRING(USER(),
(INSTR(USER(),@')+1)),
SUBSTRING(USER(),1,(instr(user(),@')-1)), ELIMINAR, NOW(), MAESTROS)

Leer ms: http://proyecto359.webnode.mx/unidad3/

Crea tu propia web gratis: http://www.webnode.es

5.- Caractersticas.
La bitcora contiene un registro de las modificaciones de los datos en orden
cronolgico. Las transacciones se escriben en la bitcora, antes de su aplicacin a
la base de datos. Si el sistema se cae antes de que la transaccin haya sido
registrada y el momento en que se aplica, en el peor de los casos, existe un
registro de una transaccin no aplicada. Si las transacciones fueron aplicadas
antes de su inclusin en la bitcora, sera posible modificar la base de datos, pero
no tener registro del cambio.
Las caractersticas de una transaccin son:

Atomicidad: en el sentido que hemos especificado anteriormente: se

ejecutan todas las sentencias o ninguna. O todas las operaciones de la
transaccin se realizan adecuadamente en la base de datos o ninguna de
ellas.
Preservacin de la consistencia. La ejecucin aislada de la transaccin ( es
decir, sin otra transaccin que se ejecute concurrentemente) conserva la
consistencia de la base de datos.
Aislamiento: ya que una transaccin no muestra los cambios que produce
hasta que finaliza.
Persistencia: ya que una vez que finaliza la transaccin 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 producira al ejecutarlas por
separado en un orden secuencial segn van entrando en el sistema

6.- Propiedades.
Las bitcoras tienen propiedades las cuales se fueron describiendo en los
apartados anteriores.

FUENTES:
http://adimen.si.ehu.es/~rigau/teaching/EHU/ABD/Altres
%20cursos/mjortin/bd_t15_rec_doc.pdf
http://proyecto359.webnode.mx/unidad3/