UNIVERSIDAD DE EL SALVADOR

Facultad Multidisciplinaria De Occidente

Departamento de Ingeniería y Arquitectura
Ingeniería en Desarrollo de Software/Educación En Línea
Administración de Bases de Datos
Ciclo II-2023

Unidad 02: Configuración y administración del espacio en

Disco

3.1.1 Definición de espacio de almacenamiento.

Para la gestión 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, extensión, segmento y
espacio de tablas.

Bloque: Se trata de la unidad más pequeña. Generalmente debe múltiple del tamaño
de bloque del sistema operativo, ya que es la unidad mínima que va a pedir Oracle al
sistema operativo. Si no fuera múltiple del bloque del sistema se añadiría un trabajo
extra ya que el sistema debería obtener más datos de los estrictamente necesarios.
Se especifica mediante DB_BLOCK_SIZE

Extensiones: Se forma con uno o más bloques. Cuando se aumenta el tamaño de un

objeto se usa una extensión 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 en Tablas: Formado por uno o más datafiles, cada datafile sólo puede
pertenecer a un determinado tablespace.
El almacenamiento de los objetos de la base de datos (tablas e índices
fundamentalmente) no se realiza sobre el archivo o archivos físicos de la base de
datos, sino que se hace a través de estructuras lógicas de almacenamiento que
tienen por debajo a esos archivos físicos, y que independizan por tanto las
sentencias de creación de objetos de las estructuras físicas 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 mayoría de las bases de datos se
almacenan en las llamadas memorias secundarias, especialmente discos duros,
aunque, en principio, pueden emplearse también discos ópticos, memorias flash, etc.

Definición de espacio de almacenamiento

Las razones por las cuales las bases de datos se almacenan en memorias
secundarias son:
● En general, las bases de datos son demasiado grandes para entrar en la
memoria primaria.
● La memoria secundaria suele ser más barata que la memoria primaria
(aunque esta última tiene mayor velocidad).
● La memoria secundaria es más útil para el almacenamiento de datos
permanente, puesto que la memoria primaria es volátil.
3.1.2 Definición y creación del espacio asignado para cada base de
datos.

Las bases de datos se almacenan en ficheros o archivos, existen diferentes formas

de organizaciones primarias de archivos que determinan la forma en que los
registros de un archivo se colocan físicamente en el disco y, por lo tanto, cómo se
accede a éstos.

Las distintas formas de organizaciones primarias de archivos son:

● Archivos de Montículos (o no Ordenados): esta técnica coloca los registros en
el disco sin un orden específico, añadiendo nuevos registros al final del
archivo.
● Archivos Ordenados (o Secuenciales): mantiene el orden de los registros con
respecto a algún valor de algún campo (clave de ordenación).
● Archivos de Direccionamiento Calculado: utilizan una función de
direccionamiento calculado aplicada a un campo específico para determinar
la colocación de los registros en disco.
● Árboles B: se vale de la estructura de árbol para las colocaciones de registros.
Existe una segunda forma de acceder a los datos llamada:
● Organización secundaria o estructura de acceso auxiliar: Estas permiten que
los accesos a los registros de un archivo basado en campos alternativos, sean
más eficientes que los que han sido utilizados para la organización primaria
de archivos.
El DBMS asigna espacio de almacenamiento a las bases de datos cuando los
usuarios introducen create database o alter database.
El primero de los comandos puede especificar uno o más dispositivos de base de
datos, junto con la cantidad de espacio en cada uno de ellos que será asignado a la
nueva base de datos.
Si se utiliza la palabra clave default o se omite completamente la cláusula on, el
DBMS pone la base de datos en uno o más de los dispositivos predeterminados de
base de datos especificados en master…sysdevice.

Para especificar un tamaño (en este ejemplo, 4MB) para una base de datos que se va
a almacenar en una ubicación predeterminada, utilice on default = size de esta
forma:
● create database newpubs on default = 4
Para situar la base de datos en dispositivos específicos, dé el nombre del dispositivo
o dispositivos en que desea almacenarla. Como la sintaxis indica, puede solicitar que
se almacene en más de un dispositivo de base de datos, con una cantidad de
espacio diferente en cada uno. Todos los dispositivos mencionados en create
database deben estar enumerados en sysdevices. En otras palabras, deben haberse
inicializado con disk init

La instrucción siguiente crea la base de datos newdb y asigna 3MB en mydata y 2MB
en newdata. Como en el ejemplo anterior, la base de datos y el diario de
transacciones no se separan:
● create database newdb on mydata = 3, newdata = 2
Nota: A menos que cree una base de datos pequeña o que no sea crucial, sitúe
siempre el diario en un dispositivo de base de datos aparte.

Si la cantidad de espacio solicitada a un dispositivo específico de base de datos no

está disponible, el DBMS crea la base de datos con tanto espacio como sea posible
en cada dispositivo y muestra un mensaje informando el espacio asignado en cada
uno (Esto no se considera un error).
Si hay menos espacio del mínimo necesario para una base de datos en el dispositivo
especificado (o en el predeterminado, si no se especifica un nombre), el comando
create database falla.

3.1.3 Bitácoras.
La estructura más ampliamente usada para grabar las modificaciones de la base de
datos es la Bitácora. Cada registro de la bitácora escribe una única escritura de base
de datos y tiene lo siguiente:
1. Nombre de la transacción: Nombre de la transacción que realizó la operación 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 después de la escritura.

Existen otros registros de bitácora especiales para grabar sucesos importantes

durante el proceso de transacción, tales como:

< T1, inicio >

< T1, x, v1, v2 >

< T1, commit >

Es fundamental que siempre se cree un registro en la bitácora cuando se realice una

escritura antes de que se modifique la base de datos.

También tenemos la posibilidad de deshacer una modificación que ya se ha escrito

en la base de datos, esto se realizará usando el campo del valor antiguo de los
registros de la bitácora.

Los registros de la bitácora deben residir en memoria estable como resultado el

volumen de datos en la bitácora puede ser exageradamente grande.
Ejemplo de una bitácora de instrucciones:

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]

Ejemplo de una bitácora 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 bitácora sería 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 bitácora 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 después de la operación de insertar, otro para
después de eliminar y el último para después de modificar para cada una de las 3
tablas de la base de datos. Los nueve triggers necesarios para que funcione la
bitácora 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”)

3.1.4 Particiones.
Una partición es una división de una base de datos lógica o sus elementos
constituyentes en partes independientes. La partición de bases de datos se hace
normalmente por razones de mantenimiento, rendimiento o manejo. Cada partición
puede ser extendida hasta múltiples nodos, y los usuarios en el nodo pueden hacer
transacciones locales en la partición.
Esto aumenta el rendimiento en sitios que tienen transacciones regularmente
involucrando ciertas vistas de datos, y manteniendo la disponibilidad y la seguridad.
Esta partición puede hacerse creando bases de datos más pequeñas separadas
(cada una con sus propias tablas, índices, y registros de transacciones) o dividiendo
elementos seleccionados, por ejemplo, solo una tabla.

Partición horizontal: Consiste en poner diferentes filas en diferentes tablas. Por

ejemplo, clientes con códigos postales menores que 50000 están almacenados en la
tabla ClientesEste, mientras que los clientes con códigos postales mayores o iguales
a 50000 están almacenados en la tabla ClientesOeste. Las dos tablas de partición
son entonces ClientesEste y ClientesOeste, mientras que una vista con una unión
podría ser creada con las dos tablas para poder dar una vista completa de todos los
clientes.

Partición vertical: Consiste en crear miles de tablas con miles de columnas y crear
tablas para poner las columnas restantes. Se puede particionar una tabla de 5
maneras diferentes:
1. Por rango
2. Por listas
3. Por hash
4. Por clave
5. Compuestas
Por rango: Para construir nuestras particiones especificamos rangos de valores. Por
ejemplo, podríamos segmentar los datos en 12 particiones: una para los contratos
de 1950 a 1960, otra para los años 60, los 70, 80, 90, la década del 2000 y la década
actual
 ● ALTER TABLE contratos PARTITION BY RANGE(YEAR(fechaInicio)) (
PARTITION partDecada50 VALUES LESS THAN (1960), PARTITION
partDecada60 VALUES LESS THAN (1970), PARTITION partDecada70 VALUES
LESS THAN (1980), PARTITION partDecada80 VALUES LESS THAN (1990),
PARTITION partDecada90 VALUES LESS THAN (2000), PARTITION
partDecada00 VALUES LESS THAN (2010), PARTITION partDecada10 VALUES
LESS THAN MAXVALUE );
Por listas: Para construir nuestras particiones especificamos listas de valores
concretos.
● ALTER TABLE contratos PARTITION BY LIST(YEAR(fechaInicio)) ( PARTITION
partDecada50 VALUES IN (1950, 1951, 1952, 1953, 1954, 1955, 1956, 1957,
1958, 1959), PARTITION partDecada60 VALUES IN (1960, 1961, 1962, 1963,
1964, 1965, 1966, 1967, 1968, 1969), PARTITION partDecada70 VALUES IN
(1970, 1971, 1972, 1973, 1974, 1975, 1976, 1977, 1978, 1979), PARTITION
partDecada80 VALUES IN (1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987,
1988, 1989), PARTITION partDecada90 VALUES IN (1990, 1991, 1992, 1993,
1994, 1995, 1996, 1997, 1998, 1999), PARTITION partDecada00 VALUES IN
(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009), PARTITION
partDecada10 VALUES IN (2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019));
Por hash: MySQL se encarga de distribuir las tuplas automáticamente usando una
operación de módulo. Sólo hay que pasarle una columna o expresión que resulte en
un entero (el hash) y el número de particiones que queramos crear.
● ALTER TABLE contratos PARTITION BY HASH(YEAR(fechaInicio)) PARTITIONS
7;
Por clave: Similar a la partición por hash, pero en este caso no necesitamos pasarle
un entero; MySQL utilizará su propia función de hash para generarlo. Si no se indica
ninguna columna a partir de la que generar el hash, se utiliza la clave primaria por
defecto.
● ALTER TABLE contratos PARTITION BY KEY() PARTITIONS 7;
Compuestas: Podemos combinar los distintos métodos de particionado y crear
particiones de particiones. Por último, un pequeño ejemplo de cómo afectaría el
particionado a una consulta sencilla como obtener el número total de tuplas que
cumplen una condición. Estas son las estadísticas de la consulta sin particionado (ni
índices)

EXPLAIN SELECT COUNT(*)

FROM contratos
WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31'
Y este el resultado de añadir las particiones (nótese la palabra clave PARTITIONS
para que nos muestre también la información relativa a las particiones)

EXPLAIN PARTITIONS SELECT COUNT(*)

FROM contratos
WHERE fechaInicio BETWEEN '1950-01-01' AND '1955-12-31‘

El número de tuplas que MySQL tiene que comprobar se ve disminuido en 2 órdenes

de magnitud.

3.1.5 Espacios Privados

Un «espacio privado» permite que los administradores y redactores gestionen el
conjunto de datos del sitio. Algunas bases de datos tienen estos espacios privados
llamados comúnmente paneles de control, que son formularios que aparecen al abrir
la base de datos.

Los paneles de control sirven de "puerta principal" o "recibidor" de una base de datos
en el sentido de que dirigen a las personas hacia determinadas tareas, como
introducir o buscar datos. Sirven también para mantener alejados a los usuarios de
las tablas que contienen los datos en tiempo real.
Cuando reciba una base de datos, debe adentrarse más allá del panel de control para
averiguar cómo están estructurados los datos, pero merece la pena echar un vistazo
inicial al panel de control.

Le puede ofrecer algún indicio sobre las tareas que el diseñador de la base de datos
consideró que realizan los usuarios habitualmente con los datos. Puede hacer clic en
los vínculos del panel de control para ver qué objetos, como formularios e informes,
abren.