ADMINISTRACIÓN DE BASES

DE DATOS MULTIUSUARIO

ÁREA DE COMUNICACIÓN Y TECNOLOGÍA

Técnico en Computación e Informática
 Tabla de contenido
Introducción ......................................................................................................................... 1
Administración de la Base de Datos ................................................................................. 2
Administración de la Estructura de la Base de Datos .................................................... 3
Control de Configuración .............................................................................................. 3
Documentación ................................................................................................................ 3
Control de Concurrencia .................................................................................................... 4
Transacciones Atómicas ................................................................................................. 5
Procesamiento de Transacciones Concurrentes .......................................................... 5
Problema de Pérdidas en la Actualización .................................................................. 7
Lock de Recursos ................................................................................................................. 8
Bloqueo Optimista y Bloqueo Pesimista .................................................................... 11
Transacciones Consistentes .......................................................................................... 11
Aislamiento de las Transacciones ............................................................................... 12
Seguridad de la Base de Datos ........................................................................................ 13
Recuperación de la Base de Datos............................................................................... 14
Recuperación mediante reprocesamiento .................................................................. 15
Recuperación mediante Rollback/RollForward ........................................................ 15
Administración del DBMS ........................................................................................... 15
Bibliografía ......................................................................................................................... 16
Introducción

Las bases de datos multiusuarios son de gran importancia en aplicaciones de alta

demanda y movimiento de información en grandes, medianas y hasta en pequeñas

empresas.

Mucha más importante que su uso, es el diseño de la misma por parte de los

analistas, debido a que manejan mucha concurrencia por parte de los usuarios y las

transacciones que realizan. Por otra parte, los requerimientos cambian con el tiempo

y estos cambios requerirán de igual manera un ajuste a nivel de la estructura de

base de datos. Estos cambios se deben manejar con sumo cuidado para que un ajuste

realizado no afecte el correcto funcionamiento de otros módulos. Se necesitará

establecer los controles necesarios para cerciorarse que el trabajo de un usuario en

la aplicación no afecte – a nivel de transacciones de datos – el quehacer de otro.

Las bases de datos se han convertido en uno de los componentes esenciales de los

procesos de una organización. Por desgracia, las bases de datos están propensas a

fallos y ocurren desastres; en estos casos contar con planes de respaldo y

recuperación, así como con técnicas y procedimientos establecidos es esencial.

1
Administración de la Base de Datos

El término “administración de la Base de Datos” se refiere a la función que es

específica para una base de datos en particular, incluyendo las aplicaciones que la

procesan.

Las bases de datos varían una de otra en cuando a tamaño y alcance, pero todas

tienen la misma función que es la del almacenamiento de la información de la

organización. Independientemente de la base de datos, cada una de ellas necesita

de una administración específica, que de manera general es brindada por una

persona al que se le denomina DBA (Database Administrator, por sus siglas en

inglés).

Para las aplicaciones de bases de datos multiusuario, esta administración se vuelve

más complicada y conlleva un mayor trabajo. Para algunas aplicaciones esta labor

es realizada por dos o más personas en tiempo parcial.

La responsabilidad del DBA es facilitar el desarrollo y el uso de la base de datos.

Por lo general, esto significa balancear las metas conflictivas de protección de la base

de datos y maximizar la disponibilidad de la misma, lo que conlleva a beneficio

para los usuarios.

En las siguientes secciones, se irán explicando algunas de las funciones más

importantes que debe tener un Administrador de Base de Datos (o entidad

encargada) para un lograr un óptimo desarrollo, operación y mantenimiento de una

base de datos y de sus aplicaciones.

2
Administración de la Estructura de la Base de Datos

Consiste en la participación inicial – junto con el equipo analista – del diseño de la

base de datos junto con la implementación de la misma; además del control y

administración de los cambios de la base de datos en todo el ciclo de vida de la

misma. El DBA debe participar en el levantamiento de requerimientos inicial y

ayude a diseñar el modelo de base datos, además de que tome decisiones

importantes como por ejemplo el DBMS que se va a utilizar.

Control de Configuración

Posterior a la implementación de la base de datos, de forma inevitable van a surgir

cambios o ajustes en los requerimientos iniciales que involucran cambios al diseño

inicial. Por lo tanto, se deben incluir en la administración, los procedimientos y

políticas por medio de las cuales los usuarios puedan registrar sus necesidades de

cambios y se tomen decisiones en conjunto – con la administración – de si se

aplicaban o no los cambios solicitados.

En el control de la base de datos, se debe estar preparado para responder

efectivamente posterior a la ejecución de un cambio solicitado ya que es posible que

un cambio realizado a la estructura, provoque problemas o fallos inesperados. Por

eso es importante antes de cada modificación un análisis previo de lo que podría

ocasionar un cambio y pasar primero por un ambiente de pruebas que no afecte los

procedimientos en producción.

Documentación

Es responsabilidad del DBA que la base de datos esté completamente documentada,

desde el diseño inicial, así como cada uno de los cambios que vaya sufriendo la

3
misma a lo largo de su uso. Un simple ajuste a la estructura de la base de datos

podría terminar en un fallo que no se manifieste de inmediato sino hasta meses

después. Si no se cuenta con la documentación correspondiente del ajuste realizado,

encontrar el error será una tarea complicada.

Actualmente existen herramientas automatizadas que ayudan con el proceso de

documentación que, aunque a veces se torne tedioso es de gran importancia para

evitar futuros problemas en la administración de la base de datos.

Control de Concurrencia

El control de concurrencia se utiliza para asegurarse que el trabajo realizado por un

usuario, no influya de forma negativa en el trabajo de otro. De esta manera dos

usuarios no deberían poder trabajar un mismo registro de la base de datos porque

esto provocaría por ejemplo que los datos correctos no queden registrados ya que

un usuario posteriormente los haya modificado.

Actualmente ninguna técnica o mecanismo de control de concurrencia es el ideal

para todas las circunstancias. Todas implican decidir entre varias alternativas. Por

ejemplo, una alternativa es aplicar locks (boqueos) a la base de datos completa, pero

esto implica que mientras esté trabajando con ésta, nadie más podría trabajar; esta

es una protección muy eficaz, pero a muy alto precio (ya no sería una base de datos

multiusuario como tal). También hay otras medidas que permiten un rendimiento

muy eficaz, pero con un nivel bajo de concurrencia. Cuando se diseñan aplicaciones

de base de datos multiusuarios es necesario elegir alguna alternativa para el control

de concurrencia.

4
 Transacciones Atómicas

Una transacción consiste en un conjunto de acciones que se ejecutan en la base de

datos, de tal forma que todas se ejecuten con éxito o bien que ninguna se ejecute por

completo, de esta forma la base datos permanecerá sin cambios. Se denomina

transacción atómica, puesto que se ejecuta como una unidad.

Como ejemplo, la siguiente secuencia de acciones de la base de datos que pude

ocurrir cuando se registra un nuevo pedido.

1. Cambiar el registro del cliente y aumentar la cantidad que adeuda.

2. Cambiar el registro del vendedor y aumentar la comisión que se debe.

3. Ingresar el nuevo registro del pedido en la base de datos.

Suponga que falla el último paso de la secuencia, talvez porque no hay suficiente

espacio en disco para realizar el almacenamiento. En dicho caso se ejecutarían los

dos primeros procesos, pero no el tercero. Al cliente se le cobraría por un pedido

que nunca recibió y al vendedor se le pagaría una comisión por un pedido que

nunca se envió. Para solucionar este problema, se debe considerar estos tres pasos

como una transacción atómica, que se ejecuten las tres o bien que no se lleve a cabo

ninguna de ellas.

Procesamiento de Transacciones Concurrentes

Son las transacciones que se ejecutan en una base de datos “al mismo tiempo”.

Aunque parezca que se ejecutan en el mismo momento, esto no es del todo cierto

ya que al final el CPU de la máquina que está procesado la base de datos, sólo

ejecuta una instrucción a la vez. Los que sí podría pasar es que cada uno de los

procesos dentro de la transacción se puedan mezclar de manera que se ejecute los

5
procesos de diferentes transacciones en diferente orden, pero siempre ejecutando

una acción a la vez.

En la figura 1 se muestran dos transacciones concurrentes. La del usuario A lee el

artículo 100, lo cambia y lo rescribe en la base de datos. La del usuario B, lleva a

cabo las mismas acciones, pero con el usuario B. La CPU procesa los del usuario A

hasta que encuentra una interrupción de I/O o alguna otra causa de retraso;

entonces el sistema operativo cambia el control al usuario B. Ahora el CPU procesa

lo del usuario B hasta que encuentre otra interrupción, en este punto vuelve a pasar

el control nuevamente al usuario A. Para el usuario parece un proceso simultáneo,

pero en realidad está mezclado o bien es concurrente.

Ilustración 1 Ejemplo de procesamiento concurrente

6
 Problema de Pérdidas en la Actualización

En el procesamiento del ejemplo anterior, no se presenta ningún problema en la

actualización de los artículos debido a que se trabajaron dos productos diferentes,

el artículo 100 y el artículo 200.

Pero si se considera un caso en el que ambos usuarios trabajan con el mismo artículo

se podrían generar pérdidas o inconsistencias de datos en la actualización.

Vamos a considerar el ejemplo que se muestra en la figura 2.

Ilustración 2 Problema de pérdida en la actualización

En este caso, vamos a supones que cuando se realiza la lectura del usuario A, el

sistema obtiene que existen 10 unidades del artículo 100, posteriormente ingresa la

lectura del usuario B que de igual manera el sistema indica que existen 10 unidades.

El sistema ejecuta las demás acciones del usuario A, donde se reduce la cantidad en

5 (quedando sólo cinco unidades) y rescribe el artículo 100. Posteriormente para el

7
usuario B – que ya había leído la cantidad actual en 10 – se reduce en 3 unidades el

artículo 100 y rescribe la nueva cantidad que en este caso sería siete. Aquí se muestra

un error de pérdida o inconsistencia en la actualización ya que evidentemente la

cantidad de artículos restantes no debe ser 7, si se toman en cuenta las dos

actualizaciones. La solución a este tipo de problema en el procesamiento

concurrente consiste en evitar que aplicaciones múltiples obtengan copias del

mismo registro cuando se van a actualizar datos, a este proceso se le denomina Lock

de Recursos (Bloqueo de recursos).

Lock de Recursos

Para anular la posibilidad de que se presente una pérdida de información por

actualización, se debe bloquear los datos que se recuperan para la actualización.

Este proceso se le conoce como un Lock de Recursos. Con este tipo de bloqueo en

una transacción concurrente, usa acción deberá esperar a que otra haya terminado

para poder iniciar su ejecución.

8
 Ilustración 3 Procesamiento concurrente con locks

Como se ilustra la imagen 3, la transacción del usuario B debe esperar hasta que el

usuario A haya terminado con los datos del artículo 100. Usando esta estrategia, el

usuario B puede leer el registro del elemento 100 sólo después que el usuario A haya

terminado con la actualización. En este caso, la cantidad final del artículo

almacenado en la base de datos es dos.

Existen dos tipos de bloqueos o locks. Los locks implícitos los maneja el DBMS y

son colocados de forma automática. Los locks explícitos son indicados por el

usuario y se ponen mediante instrucciones.

Los locks exclusivos no permiten realizar ninguna acción sobre el registro, no se

puede ni siquiera tener acceso para lectura. Los locks compartidos impide que se

hagan modificaciones sobre los datos, pero si permiten la lectura.

9
El deadlock o “bloqueo de la muerte” ocurre cuando un conjunto de procesos o

acciones dentro de una transacción concurrente que compiten por datos o bien se

comunican entre ellos.

Ilustración 4 Ejemplo de DeadLock

Suponga que el usuario A quiere ordenar papel y si lo puede obtener también desea

obtener algunos lápices. El usuario B desea obtener algunos lápices y si los puede

obtener, entonces desea ordenar algo de papel. El orden del procesamiento se

muestra en la figura 4. En este caso los usuarios A y B están atrapados en un

DEADLOCK, cada uno está esperando un recurso que el otro bloqueó. Hay dos

maneras de evitar este problema: evitar que el deadlock ocurra o bien dejar que

ocurra y luego romperlo.

10
Casi todos los DBMS tienen algoritmos para detectar el deadlock. Cuando éste

ocurre la solución más común es revertir una de las transacciones para eliminar el

deadlock sus cambios en la base de datos.

Bloqueo Optimista y Bloqueo Pesimista

Los locks o bloqueos se pueden aplicar en dos estilos diferentes. Con el uso del lock

optimista, se debe suponer que no va a ocurrir ningún conflicto. Los datos se leen,

se procesan las transacciones y las actualizaciones y al final se realiza una

verificación para determinar si se presentó algún conflicto; en caso contrario se

termina la transacción. Si ocurrió algún fallo, la transacción se repite hasta que no

exista ningún conflicto. En el bloqueo pesimista, se debe suponer que va a existir un

conflicto. En este caso primero se aplican los locks, se procesa la transacción y al

final se liberan los bloqueos.

Transacciones Consistentes

El mejor tipo de transacción que se puede ejecutar es la conocida como transacción

ACID (Atomic, Consistent, Insolated and Durable por sus siglas en inglés) que es

aquella que es atómica, consistente, aislada y persistente. El término atómico ya se

definió anteriormente y consiste en que se ejecuta todas las acciones o bien no se

ejecuta ninguna. Una transacción persistente o durable es aquella para la que todos

los cambios confirmados son persistentes. Si la transacción es durable, el DBMS

proporcionará las facilidades para recuperar los cambios de todas las acciones

confirmadas cuando sea necesario.

Para definir los conceptos de Consistente y Aislada considere la siguiente

instrucción SQL

11
 Update cliente set codigo_area = ‘425’ where codigo_postal = ‘925’

Ahora suponga que la tabla de CLIENTES tiene 500.000 registros y que sólo 200 de

éstos tienen el código postal igual a 925. Al motor de base de datos le tomará tiempo

en ubicar estos 200 registros; durante este tiempo de procesamiento puede que otras

transacciones cambien el código de área o el código postal del cliente. Si dicha

instrucción fuera consistente, este tipo de actualizaciones estarían prohibidas. La

actualización se aplicará para indicar que los registros como éstos existen en el

momento en el que el enunciado de la instrucción SQL dio inicio. Esta consistencia

se denomina Consistencia a Nivel de Instrucción.

En la consistencia a nivel de instrucción, cada instrucción procesa de forma

independiente los registros consistentes, pero los cambios de otros usuarios de estos

registros se pueden permitir durante el intervalo entre dos instrucciones SQL.

Ahora bien, el nivel de consistencia de la transacción consiste en que todos los

registros impactados por instrucciones SQL independientes son protegidos de

cambios durante la transacción completa.

Aislamiento de las Transacciones

Los bloqueos evitan que los procesos concurrentes generen pérdida de

actualizaciones, pero existe otro problema que no pueden evitar. Se dice que existe

una lectura sucia cuando una transacción lee un registro cambiado que no ha sido

registrado en la base de datos, por ejemplo, un registro de una transacción que no

ha sido confirmado y esta posteriormente aborta. Una lectura no repetible aparece

cuando una transacción relee datos que fueron leídos con anticipación y encuentra

modificaciones o eliminaciones causadas por una transacción confirmada. Por

último, están las lecturas fantasmas que ocurren cuando una transacción relee los

12
datos y encuentra que existen nuevos registros que fueron agregados como

resultado de una transacción confirmada en una lectura anterior.

El estándar ANSI SQL define cuatro niveles de aislamientos, que especifica cuál de

estos problemas se permite que ocurra. El objetivo es que el programador de la

aplicación pueda declarar el tipo de aislamiento que requiere y entonces tener la

administración de los locks del DBMS, así como lograr el nivel de aislamiento.

Ilustración 5 Resumen de los niveles de aislamiento

Seguridad de la Base de Datos

El objetivo es asegurar que para la base de datos sólo usuarios autorizados puedan

ejecutar actividades permitidas y en momentos también definidos. Durante la fase

de especificación de requerimientos se debe especificar los derechos y

responsabilidades de todos los usuarios.

Por ejemplo, en una base de datos de una organización que tiene como

departamentos los siguientes: Recursos Humanos, Ventas y Clientes, entre otros, se

podría establecer seguridad por usuarios de manera que las personas que trabajan

en Recursos Humanos puedan consultar, modificar e insertar registros sólo en su

aplicación de Recursos Humanos y que no tengan acceso por ejemplo a borrar

13
registros ni mucho menos a realizar estos procesos en oreo departamentos como

Ventas o Clientes.

Siempre deberá existir un administrador del sistema que debería tener permisos

irrestrictos sobre todos los datos, esta entidad podrá crear, actualizar, leer y eliminar

cualquier información de la base de datos. También podrá otorgar permisos de

otorgar permiso a otros usuarios, así como los permisos de modificar la estructura

de la base de datos.

Los permisos se pueden otorgar por persona o usuario de forma individual o bien

se le puede otorgar a un grupo de usuarios y posteriormente se puede incluir a un

usuario dentro de un grupo específico y de forma automática tendrá acceso a todos

los permisos definidos para el grupo.

Cada motor de base de datos maneja la seguridad y la asignación de los permisos

de forma diferente. Se le insta al estudiante a buscar más información acerca de la

seguridad en diferentes DBMS que se encuentran en el mercado actualmente.

Recuperación de la Base de Datos

Ante un posible fallo de un sistema (en hardware o software) o de un procedimiento

mal ejecutado por alguno de los usuarios de la aplicación, es sumamente importante

poder restablecer o recuperar la base de datos a un estado de consistencia que

permita que los procesos vitales de la organización sigan funcionando

correctamente. Posterior a una falla, los usuarios deben saber qué hacer cuando el

sistema vuelva a estar disponible, quizá sea necesario ingresar datos nuevamente y

los usuarios necesitan saber que tanto necesitan regresar a sus procesos para la

inclusión de estos datos. Después de una falla en el sistema hay dos posibles vías

14
que se pueden tomar: recuperar a través de reprocesamiento y recuperar a través

de revertir/avanzar (rollback/rollforward).

Recuperación mediante reprocesamiento

Dado que el procesamiento no se puede reanudar en un punto exacto, lo mejor es

retornar a un punto conocido y reprocesar la carga de trabajo desde ahí. La forma

más simple de realizar este tipo de recuperación es hacer periódicamente un

respaldo de la base de datos y conservar el registro de todas las transacciones que

se han procesado desde el último respaldo. Así cuando se presenta una falla, el

personal puede restaurar la base de datos y reprocesar todas las transacciones.

Recuperación mediante Rollback/RollForward

Otra opción de recuperación ante una falla es hacer un respaldo de la base de datos

periódicamente y llevar un registro de los cambios que se hicieron y guardaron en

la base de datos con las transacciones. Si se presenta un fallo, se puede optar por

alguno de los dos métodos. Si se elige rollforward, la base de datos se restaura

usando la información que ha sido guardada y todas las transacciones válidas se

aplican nuevamente. Con el segundo método llamado rollback, se deshacen los

cambios realizados con las transacciones erróneas o parcialmente procesadas. De

esta manera, las transacciones válidas que estaban en proceso en el momento de la

falla se reinician.

Administración del DBMS

Aparte de las funciones propias del manejo de los datos y su estructura, el DBA

debe encargarse de los procesos de administración del DBMS. Le corresponde

recopilar y analizar estadísticas del desempeño de los sistemas, así como identificar

15
las áreas de posibles problemas que se puedan presentar. Hay que tener en cuenta

que al trabajar con bases de datos multiusuarios, todas las quejas, solicitudes,

formas de manejo, etc. de cada uno de los usuarios, deberá ser tomada en cuenta y

dar respuesta oportuna a cada situación.

El DBA debe monitorear constantemente la actividad de todos los usuarios de la

base de datos. Generalmente los sistemas de administración de bases de datos

(como el SQL Server o el Oracle) incluyen características para recolectar estadísticas

y hacer reportes sobre las mismas. El DEB deberá analizar las estadísticas en cuanto

a tiempo y desempeño de la base de datos y si encuentra algún fallo deberá

determinar si procede alguna modificación a la estructura de la base de datos, por

ejemplo, agregar o quitar índices, modificar tablas o vistas, etc.

Bibliografía

(22 de 09 de 2005). Obtenido de BlogSpot:

http://9271983bdaa.blogspot.com/2005/09/recuperacion-capitulo-14.html

Editorial. (14 de 05 de 2013). Conocimientos Web. Obtenido de

http://www.conocimientosweb.net/dcmt/ficha294.html

Kroenke, D. (2003). Procesamiento de Bases de Datos Fundamentos, Diseño e

implementación. Mexico: Pearson Education.

16